Analisis PBO BAB III ALAT PERMODELAN SISTEM

Ada beberapa perangkat permodelan sistem yang digunakan dalam merancang sistem, yaitu :

·       SYSTEM PROCEDURE DIAGRAM (FLOWMAP)

Digunakan untuk mendefinisikan hubungan antara bagian (pelaku proses), proses (manual atau berbasis komputer) dan aliran data (dalam bentuk dokumen masukan dan keluaran).

System Procedure Diagram menggunakan simbol – simbol sebagai berikut :

Aturan Membuat Flowmap

Untuk membuat sebuah analisis menggunakan flowmap seorang analis dan programmer memerlukan beberapa tahapan, diantarnya:

Ø   Flowmap digambarkan dari halaman atas ke bawah dan dari kiri ke kanan.

Ø  Aktivitas yang digambarkan harus didefinisikan secara hati-hati dan definisi ini harus dapat dimengerti oleh pembacanya.

Ø    Kapan aktivitas dimulai dan berakhir harus ditentukan secara jelas.

Ø  Setiap langkah dari aktivitas harus diuraikan dengan menggunakan deskripsi kata kerja, misalkan MENGHITUNG PAJAK PENJUALAN.

Ø    Setiap langkah dari aktivitas harus berada pada urutan yang benar.

Ø  Lingkup dan range dari aktifitas yang sedang digambarkan harus ditelusuri dengan hati – hati.

Ø  Percabangan yang memotong aktivitas yang sedang digambarkan tidak perlu digambarkan pada flowchart yang sama. Simbol konektor harus digunakan dan percabangannya diletakan pada halaman yang terpisah atau hilangkan seluruhnya bila percabangannya tidak berkaitan dengan system.

·       ENTITY RELATIONAL DIAGRAM (ERD)

Merupakan jaringan yang menggunakan susuanan data yang disimpan dari sistem secara abstrak. Tujuan dari Entity Relational ini adalah untuk menunjukkan obyek data dan relationship yang ada pada obyek tersebut. Di sampng itu Model ER ini merupakan salah stau alat untuk perancangan dalam basis data.

Ø  Komponen Komponen ERD

Ø  Derajat Relationship 

a)  Unary (Derajat Satu): satu buah relationship menghubungkan satu buah entity.

b)  Binary (Derajat Dua): satu buah relationship menghubungkan dua buah entity.

c)  Ternary (Derajat Tiga): satu buah relationship menghubungkan tiga buah entity.

Ø  Cardinality Rasio

Yaitu menjelaskan batasan pada jumlah entity yang berhubungan melalui suatu relationship. Jenis – jenis Cardinality Rasio:

a.  Satu ke satu (One to one) 1:1, yaitu perbandingan antara entity pertama dengan entity kedua berbanding satu berbanding satu atau hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B.

b. Satu ke banyak (One to many) 1:M, yaitu perbandingan antara entity pertama dengan entity kedua berbanding satu berbanding banyak atau setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A.

c.  Banyak ke satu (Many to one) M:1, yaitu perbandingan antara entity pertama dengan entity kedua berbanding banyak berbanding satu.

d.   Banyak ke banyak (Many to many) M:M, yaitu perbandingan antara entity pertama dengan entity kedua berbanding banyak berbanding banyak atau Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.

Ø  Langkah – langkah membuat ERD

a)    Mengidentifikasi dan menetapkan seluruh entity ynag terlibat

b)    Menentukan atribut – atribut key dari masing – masing entity

c)  Menetapkan relationship antara satu entity dengan entity lainnya beserta foreign – keynya

d)    Menentukan derajat dan cardinality rasio untuk setiap relationship

e)    Melengkapi himpunan relasi dengan atribut – atribut yang bukan kunci (non key)

Ø  Contoh kasus

Suatu perguruan tinggi mempunyai banyak mahasiswa. Setiap mahasiswa biasanya mengikuti beberapa mata kuliah. Setiap mata kuliah diajarkan oleh seorang dosen dan seorang dosen bisa mengajar beberapa mata kuliah. Pada entitas Mahasiswa diperlukan informasi tentang NIM, Nama_Mhs, Alamat_Mhs dan Jurusan sedangkan Mata Kuliah diperlukan informasi Kd_MK, Nm_MK, SKS, Semester sedangkan Dosen diperlukan juga informasi tentang Kd_Dosen, Nm_Dosen.

NORMALISASI

Adalah proses pengelompoan data kedalam bentuk tabel atau relasi atau file  untuk menyatakan entitas dan hubungan mereka sehingga terwujud satu bentuk database yang mudah untuk dimodifikasi.

Jenis – jenis key :

1.    Super Key : merupakan satu atau lebih atribut yang dapat membedakan setiap baris data dalam sebuah table secara unik.

2.    Candidate Key : kumpulan atribut minimal yang membedakan setiap baris data dalam sebuah table secara unik.

3.    Alnternative key :candidate key yang tidak dijadikan primary key.

Langkah – langkah pembentukan normalisasi

1.    Bentuk Tidak Normal (Unnormalized Form)

Pada bentuk ini merupakan kumpulan data yang tidak adakeharusan mengikuti format tertentu, dapat saja data tidak lengkap atau terduplikasi.

2.    Bentuk Normal Satu (1 NF)

Yaitu bila relasi tersebut mempunyai nilai data yang automatic, artinya tidak ada lagi kerangkapan data.

3.    Bentuk Normal Dua (2 NF)

Yaitu bila relasi tersebut merupakan 1NF dan setiap atribut tergantung penuh pada primary key.

4.    Bentuk Normal Ketiga (3 NF)

Yaitu bila relasi merupakan 2 NF  dan tidak tergantung secara transitif pada primary key.

·         Unified Modelling Language ( UML )

UML merupakan singkatan dari “Unified Modelling Language” yaitu suatu metode permodelan secara visual untuk sarana perancangan sistem berorientasi objek, atau definisi UML yaitu sebagai suatu bahasa yang sudah menjadi standar pada visualisasi, perancangan dan juga pendokumentasian sistem software. Saat ini UML sudah menjadi bahasa standar dalam penulisan blue print software.

Tujuan atau fungsi dari penggunaan UML

®  Dapat memberikan bahasa permodelan visual kepada pengguna dari berbagai macam pemerograman maupun proses rekayasa.

®    Dapat menyatukan praktek-praktek terbaik yang ada dalam permodelan.

® Dapat memberikan model yang siap untuk digunakan, merupakan bahasa permodelan visual yang ekspresif untuk mengembangkan sistem dan untuk saling menukar model secara mudah.

® Dapat berguna sebagai blue print, sebab sangat lengkap dan detail dalam perancangannya yang nantinya akan diketahui informasi yang detail mengenai koding suatu program.

® Dapat memodelkan sistem yang berkonsep berorientasi objek, jadi tidak hanya digunakan untuk memodelkan perangkat lunak (software) saja.

® Dapat menciptakan suatu bahasa permodelan yang nantinya dapat dipergunakan oleh manusia maupun oleh mesin.

Jenis-Jenis diagram UML 

a.    Use case diagram

Use case diagram yaitu salah satu jenis diagram pada UML yang menggambarkan interaksi antara sistem dan aktor, use case diagram juga dapat mendeskripsikan tipe interaksi antara si pemakai sistem dengan sistemnya.

b.    Activity Diagram

Activity diagram atau diagram aktivitas yaitu salah satu jenis diagram pada UML yang dapat memodelkan proses-proses apa saja yang terjadi pada sistem.

c.    Sequence diagram

Sequence diagram yaitu salah satu jenis diagram pada UML yang menjelaskan interaksi objek yang berdasarkan urutan waktu, sequence diagram juga dapat menggambarkan urutan atau tahapan yang harus dilakukan untuk dapat menghasilkan sesuatu seperti pada use case diagram.

d.    Class diagram

Class diagram yaitu salah satu jenis diagram pada UML yang digunakan untuk menampilkan kelas-kelas maupun paket-paket yang ada pada suatu sistem yang nantinya akan digunakan. Jadi diagram ini dapat memberikan sebuah gambaran mengenai sistem maupun relasi-relasi yang terdapat pada sistem tersebut.

e.    State diagram

State diagram yaitu salah satu jenis diagram pada UML yang menggambarkan transisi maupun perubahan keadaan suatu objek pada sistem.

Read More

Analisis PBO BAB II DESAIN SISTEM

Setelah tahap analisis sistem selesai dilakukan, maka analis sistem telah mendapatkan gambaran dengan jelas apa yang harus dikerjakan. Tiba waktunya sekarang bagi analis sistem untuk memikirkan bagaimana membentuk system tersebut. Tahap ini disebut dengan desain sistem. Desain system dapat dibagi dalam dua bagian, yaitu desain sistem secara umum dan desain sistem terinci.

Menurut George M. Scott: Adalah Desain sistem menentukan bagaimana suatu sistem akan menyelesaikan apa yang mesti diselesaikan; tahap ini menyangkut mengkonfiguras dari komponen- komponen perangkat Lunak dan perangkat keras dari suatu sistem sehingga setelah instalasi dari sistem akan benar-benar memuaskan rancang bangun yang telah di tetaplan pada akhir tahap analisis sistem).

Sedangkan Menurut John Burch & Gary Grudnitski: Desain sistem dapat didefinisikan sebagai penggambaran,dan pembuatan sketsa atau pengaturan dari beberapa terpisah ke daIam satu kesatuan yang utuh dan berfungsi.

·         Tahap setelah analis dari siklus pengembangan system

·         Pendefinisian dari kebutuhan-kebutuhan fungsional

·         Persiapan untuk rancang bangun implementasi

·     Menggambarkan bagaimana system terbentuk yang dapat berupa penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa elemen yang yang terpisah kedalam satu kesatuan yang utuh dan berfungsi

·     Termasuk menyangkut mengkonfigurasi dari komponen-komponen perangkat lunak dan perangkat keras dari suatu system.

Tujuan Desain Sistem

Tahap desain sistem mempunyai dua maksud atau tujuan utama. yaitu sebagai berikut ini.

Ø   Untuk memenuhi kebutuhan kepada pemakai sistem.

Ø  Untuk memberikan gambaran gambaran yang jelas dan rancang bangun yang lengkap kepada pemograman computer dan ahli-ahli teknik lainnya yang terlibat

Tujuan kedua ini lebih condong pada desain sistem yang terinci, yaitu pembuatan rancang bangun yang jelas dan lengkap untuk nantinya digunakan sebagai pembuatan program komputernya. Untuk mencapai tujuan ini. analis sistem hurus dapat mencapai sasaran-Sasaran sebagai berikut :

·        Desain sistem harus berguna, mudah dipahami dan nantinya mudah digunakan. Ini berarti bahwa data harus mudah ditangkap, metode-metode baru mudah diterapkan dan informasi harus mudah dihasilkan serta mudah dipahami dan digunakan.

·     Desain system harus dapat mendukung tujuan perusahaan sesuai dengan yang telah didefinisikan pada tahap perencanaan system yang dilanjutkan pada analisi syste

·    Desain system harus efisien agar dapat mendukung pengolahan transaksi, pelaporan manajemen dan mendukung keputusan yang akan dilakukan oleh manajemen, termasuk tugas-tugas yang lainnya yang tdak dilakukan oleh computer

·       Desain system harus dapat mempersiapkan rancang bangun yang terinci untuk masing-masing komponen dari system informasi yang meliputi data dan informasi simpanan data, metode, prosedur-prosedur, orang-orang, perangkat keras perangkat lunak dan pengendalian intern

Personil yang terlibat

Pekerjaan desain sistem dilakukan oleh analis sistem dan personil-personil teknik lainnya, seperti misalnya spesialis pengendalian , personil penjamin kualitas , Spesialis komunikasi dan lain sebagainya.

Bagaimana dengan pemakai-pemakai system (user)! Apakah pemakai sistem juga harus terlibat dalam tahap ini? Banyak orang yang setuju bahwa keterlibatan pemakai system sangat penting selama tahap analisis sistem.

Akan tetapi bagaimana di tahap desain sistem ini? Banyak analis sistem yang mendisain sistem ini tanpa partisipasi yang berarti dari pemakai sistem. Hasil dari ketidak-terlibatan pemakai sistem ini akan mengakibatkan kurang puasnya pemakai sistem terhadap cara sistem berkerja (bahkan sistem tidak dapat memenuhi kebutuhan pemakai).

Oleh karena alasan ini, maka pemakai sistem seharusnya juga terlibat dalam tahap desain sistem. Pemakai sistem paling tidak dapat mengkaji ulang komponen-komponen sistem informasi yang didesain. Misalnya pemakai sistem seharusnya mengkaji ulang tata letak (layout) dari semua laporan-laporan dan bentuk-bentuk tampilan di layar terminal. Pemakai sistem juga seharusnya menilai arus percakapan dari dialog di layar terminal.

Pemakai sistem juga seharusnya menilai cara penangkapan data, pengolahan dari data tersebut dan disrtibusi informasinya.

Tekanan-tekanan desain

Tekanan-tekanan desain adalah tekanan-tekanan yang harus dipertimbangkan dalam mendesain suatu sistem informasi supaya dapat mengenai sasarannya. Supaya sukses, analis sistem harus mempertimbangkan tekanan-tekanan desain (design forces) yang ada dan bagaimana tekanan-tekanan ini mempengaruhi proyek sistem informasi. Ambillah contoh desain suatu mobil sebasai analoginya. Semua mobil terdiri dari blok blok bangunan yang sama yaitu sebuah bodi mobil, interiornya, instrumen-instrumtnnya. kendali kemudii (kemudi, pedal rem,pedal gas dan lain sebagainya). Roda-roda, gandar-gandar dan suatu mesin yang terbentuk dari suatu unit tenaga, sumber energi, transmisi-transmisi dan gear-gear. Akan tetapi karena adanya sejumlah tekanan-tekanan desain, bentuk dan isi dari blok-blok bangunan mobil ini telah berubah dari waktu ke waktu. misalnva, pengendalian polusi, keamanan yang ditingkatkan dan pemakaian bahan bakar yang harus lebih hemat memaksa mobil untuk didesain kembali keseluruhannya. Beberapa industri mobil beberapa tahun yang lalu kurang mempcrhatikan pada pemenuhan selera pasar dan banyak yang merancang mobil yang tidak dapat diterima oleh konsumen. Setelah pabrik-pabrik mobil ini berhenti merancang mobil tersebut dan mulai merancang kembali dengan memperhatikan desain forces mereka mendapatkan kembali jalur pemasarannya. Kesadaran akan desain forces ini mengikuti dengan pasti telah mengembalikan pabrik-pabrik mobil ini kepada operasi yang menguntungkan. Perancang sistem informasi juga harus memperhatikan sejumlah desain forces yang mempengaruhi kerjanya, yaitu:

–        integrasi (intagration),

–        jalur pemakai/sistem (user/system intarface),

–        tekanan-tekanan persaingan

–        kualitas dan kegunaan informasi

–        kebutuhan-kebutuhan sistem

–        kebutuhan-kcbutuhan pengolahan data

–        faktor-faktor organisasi

–        kebutuhan-kebutuhan biaya efektifitas

–        kebutuhan-kebutuhan kelayakan

A. Desain Secara Umum Dan Desain Secara Terinci

     Desain Sistem Secara Umum ( General System Design )

Tujuan dari system secara umum adalah untuk memberikan gambaran secara umum kepada user tentang system yang baru. Desain system secara umum merupakan persiapan dari desain terinci. Desain secara umum mengindentifikasikan komponen-komponen system informasi yang akan didesain secara rinci. Desain terinci dimaksudkan untuk pemograman komputer dan ahli teknik yang mengimplementasikan sistem. Untuk lebih detail materi tentang Desain Sistem Secara Umum  dapat dilihat melalui Link tersebut 

Desain Sistem Secara Rinci ( Detailed System design) 

Komponen desain sistem secara terinci :

·       Desain input terinci

masukan (input) merupakan awal dimulainya proses informasi. bahan mentah dari informasi adalah data yang terjadi dari transaksi-transaksi yang dilakukan oeh organisasi . data dari hasil transaksi merupakan masukan untuk sistem informasi.

dokumen dasar merupakan formulir yang digunakan untuk menangkap (capture) data yang terjadi. data yang sudah dicatat di dokumen dasar kemudian dimasukkan sebagai input ke sistem informasi untuk diolah.

·         Desain output terinci

pada tahap desain output secara umum, desain output ini hanya dimaksudkan untuk menentukan kebutuhan output dari sistem baru.

·        Desain dialog layar terminal

merupakan rancang bangun dari percakapan antara pemakai sistem (user) dengan komputer. percakapan ini dapat terdiri dari proses memasukkan data ke sistem, menampilkan output informasi kepada user atau dapat keduanya.

·        Desain database terinci

Ditahap desain secara umum sebelumnya, desain database hanya dimaksudkan untuk mengidentifikasi kebutuhan file-file database yang diperlukan oleh sistem informasi saja. Pada tahap desain terinci ini, desain database dimaksudkan untuk mengidentifikasi isi atau struktur dari tiap-tiap file yang telah diidentifikasi didesain secara umum.

Elemen-elemen data disuatu file database harus dapat digunakan untuk pembuatan suatu output. Demikian juga dengan input yang akan direkam di database, file-file database harus mempunyai elemen-elemen untuk menampung input yang dimasukkan. Untuk dapat merancang database terinci digunakan teknik normalisasi

·         Desain teknologi terinci

Pada desain teknologi secara umum telah ditentukan jenis dan jumlah dari teknologi yang akan digunakan. Yang belum didefinisikan secara pasti pada tahap ini adalah kapasitas dari teknologi simpanan luar yang akan digunakan. Kapasitas simpanan luar yang telah didefinisikan pada tahap desain secara umum hanya ditaksir secara kira-kira terlebih dahulu berdasarkan pengalaman analis sistem.

Setelah file-file database berhasil didesain secara rinci, kebutuhan kapasitas simpanan luar sekarang dapat dihitung dengan lebih tepat. Besarnya kapasitas simpanan luar yang dibutuhkan oleh sistem informasi dapat dihitung berdasarkan besarnya file-file database yang akan menimpan data untuk satu periode tertentu.

Untuk materi tentang Desian Sistem Secara Rinci lebih Detailnya anda bisa klik Link berikut

B. Desain Sistem Terstruktur Dan Desain Sistem  Berorientasi Objek

Pendekatan perancangan sistem Terstruktur merupakan metode yang pendekatannya pada proses, karena metode ini mencoba melihat sistem dari sudut pandang logical dan juga melihat data sebagai sumber proses. Di dalam penggambaran datanya, metode ini menggunakan Data Flow Diagram (DFD), Normalisasi, E-R Diagram(ERD) dan lainnya.

Pendekatan perancangan system berorientasi Objek menekankan pada data dan proses dan dapat membantu memudahkan dalam memecahkan permasalahan karena hal ini sangat baik untuk deskripsi dari setiap entitas. Karena informasi dari encapsulation, perancangan berorientasi objek umumnya mengarah ke sistem dimana sistem data yang kurang atau mungkin rusak dalam hal error program.

Pendekatan terstruktur lebih dikenal dengan Structured Analisys and Design (SSAD), sedangkan pendekatan berorientasi objek disebut dengan Object-oriented Analysis and Design (OOAD).

Pendekatan terstruktur lebih mengarah pada pendekatan fungsional. Pada pendekatan berorientasi objek lebih melakukan pendekatan pada objek. Objek merupakan identitas berarti bahwa data diukur mempunyai nilai tertentu yang membedakan entitas.

Beberapa keunggulan pendekatan terstruktur dibandingkan dengan pendekatan berorientasi objek adalah pendekatan terstruktur tidak fokus pada koding, sedangkan pendekatan berorientasi objek cenderung fokus terhadap koding. Keunggulan yang lain adalah pada pendekatan terstruktur lebih menekankan pada kinerja tim, sedangkan pendekatan berorientasi tidak.

METODE TERSTRUKTUR

Kelebihan

·         Milestone diperlihatkan dengan jelas yang memudahkan dalam manajemen proyek

·     SSAD merupakan pendekatan visual, ini membuat metode ini mudah dimengerti oleh pengguna atau programmer.

·     Penggunaan analisis grafis dan tool seperti DFD menjadikan SSAD menjadikan bagus untuk digunakan.

·         SSAD merupakan metode yang diketahui secara umum pada berbagai industry.

·     SSAD sudah diterapkan begitu lama sehingga metode ini sudah matang dan layak untuk digunakan.

·         SSAD memungkinkan untuk melakukan validasi antara berbagai kebutuhan

·         SSAD relatif simpel dan mudah dimengerti.

Kekurangan

·         SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional.

·         Sedikit sekali manajemen langsung terkait dengan SSAD

·    Prinsip dasar SSAD merupakan pengembangan non-iterative (waterfall), akan tetapi kebutuhan akan berubah pada setiap proses.

·     Interaksi antara analisis atau pengguna tidak komprehensif, karena sistem telah didefinisikan dari awal, sehingga tidak adaptif terhadap perubahan (kebutuhan-kebutuhan baru).

·      Selain dengan menggunakan desain logic dan DFD, tidak cukup tool yang digunakan untuk mengkomunikasikan dengan pengguna, sehingga sangat sliit bagi pengguna untuk melakukan evaluasi.

·    Pada SAAD sliit sekali untuk memutuskan ketika ingin menghentikan dekomposisi dan mliai membuat sistem.

·         SSAD tidak selalu memenuhi kebutuhan pengguna.

·    SSAD tidak dapat memenuhi kebutuhan terkait bahasa pemrograman berorientasi obyek, karena metode ini memang didesain untuk mendukung bahasa pemrograman terstruktur, tidak berorientasi pada obyek (Jadalowen, 2002).

METODE BERORIENTASI OBYEK

Kelebihan

·     Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan dalam pembangunan sistem

·   Dibandingkan dengan SSAD, waktu pengembangan, level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000).

·    Tidak ada pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi antara user dan developer dari awal hingga akhir pembangunan sistem.

·     Analis dan programmer tidak dibatasi dengan batasan implementasi sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai lingkungan eksekusi.

·      Relasi obyek dengan entitas (thing) umumnya dapat di mapping dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem. Hal ini memudahkan dalam mehami desain (Sommerville, 2000).

·    Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi terhadap kebernaran software yang membantu untuk mengurangi resiko pada pembangunan sistem yang kompleks (Booch, 2007).

·      Encapsliation data dan method, memungkinkan penggunaan kembali pada proyek lain, hal ini akan memperingan proses desain, pemrograman dan reduksi harga.

·      OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan memahami desain dan mengurangi resiko pelaksanaan proyek.

·     Dekomposisi obyek, memungkinkan seorang analis untuk memcah masalah menjadi pecahan-pecahan masalah dan bagian-bagian yang dimanage secara terpisah. Kode program dapat dikerjakan bersama-sama. Metode ini memungkinkan pembangunan software dengan cepat, sehingga dapat segera masuk ke pasaran dan kompetitif. Sistem yang dihasilkan sangat fleksibel dan mudah dalam memelihara.

Kekurangan

·         Pada awal desain OOAD, sistem mungkin akan sangat simple.

·         Pada OOAD lebih fockus pada coding dibandingkan dengan SSAD.

·         Pada OOAD tidak menekankan pada kinerja team seperti pada SSAD.

·         Pada OOAD tidak mudah untuk mendefinisikan class dan obyek yang dibutuhkan sistem.

·      Sering kali pemrogramam berorientasi obyek digunakan untuk melakukan anlisisis terhadap fungsional siste, sementara metode OOAD tidak berbasis pada fungsional sistem.

·     OOAD merupakan jenis manajemen proyek yang tergolong baru, yang berbeda dengan metode analisis dengan metode terstruktur. Konsekuensinya adalah, team developer butuh waktu yang lebih lama untuk berpindah ke OOAD, karena mereka sudah menggunakan SSAD dalam waktu yang lama ( Hantos, 2005).

·  Metodologi pengembangan sistem dengan OOAD menggunakan konsep reuse. Reuse merupakan salah satu keuntungan utama yang menjadi alasan digunakannya OOAD. Namun demikian, tanpa prosedur yang emplisit terhadap reuse, akan sangat sliit untuk menerapkan konsep ini pada skala besar (Hantos, 2005).

Read More