Perbedaan Model Pengembangan Sistem

64 karena memakan waktu yang lama. Prototype oleh Eleanor Rosch 1938-N pada tahun 1970 Metode ini cukup efektif dengan mendapatkan kebutuhan dan aturan yang jelas dan pelanggan bisa langsung melihat sistem yang sebenarnya. Pengembangan kadang-kadang membuat implementasi sembarangan, karena ingin working version selesai dengan cepat. Prototyping dapat bekerja dengan baik jika kerja sama yang baik antara pengembang dan pelanggan. Rapid Application Development RAD oleh James Martin 1933-N pada tahun 1991 Metode ini lebih cepat dari waterfall jika kebutuhan dan batasan proyek sudah diketahui dengan baik, bisa untuk dimodularisasi. Karena proyek dipecah menjadi beberapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim karena komponen- komponen yang sudah ada, fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya sehingga fasilitas program bisa menurun. RAD cocok untuk aplikasi yang tidak mempunyai resiko teknis yang tinggi. RAD cocok untuk proyek yang memiliki SDM yang baik dan sudah berpengalaman. Incremental oleh Schlimmer, et all. Pada tahun 1986 Fleksibel dan mudah untuk dikelola dan pengujiannya mudah. Semua kebutuhan tidak dikumpulkan pada tahap awal sehingga menimbulkan masalah serta sulit untuk mengukur progress karena tidak ada milestone. Cocok untuk aplikasi yang kebutuhan telah di- identifikasi dengan baik. 65 Iterative Fase desain pengkodean dan pengujian lebih cepat. Butuh waktu yang banyak untuk menganalisis dan terlalu banyak langkah yang dibutuhkan model. Hanya cocok untuk skala besar. Spiral oleh Barry W. Boehm 1933- N pada tahun 1986 Model ini digunakan untuk sistem skala besar, membutuhkan konsiderasi langsung terhadap resiko teknis, sehingga dapat mengurangi resiko besar. Resiko utama tidak ditemukan, maka masalah bisa timbul kemudian sehingga membutuhkan managemen dan perkiraan resiko risk assessment yang cukup tinggi. Hanya cocok untuk software skala besar. Concurrent oleh C.A.R. Hoare, et all pada tahun 1960 Peningkatan aplikasi yang sudah selesai pada umumnya satu periode. Sangat memperhatikan pada input- output dari aplikasi. Dapat dieksekusi secara pararel. Tidak bisa mendeteksi error pada sub-program fungsi-fungsi program. Membutuhkan waktu lama. Cocok untuk aplikasi yang membutuhkan ketelitian dalam proses input-output program. Component-Based Development oleh Malcolm Douglas Mcllroy 1932-N pada tahun 1998 Komponen- komponen program dijadikan satu set paket sehingga dapat memudahkan para pengembang dalam Cukup menyulitkan dalam membuat paket-paket program yang dibutuhkan dalam mengembangkan aplikasi. Baik digunakan untuk aplikasi yang banyak menggunakan program-program yang pernah dibuat. 66 pengkodeaan dan penggunaan kembali kode program tersebut. Model Metode Fomral Sistem diekspresikan dengan teori matematika sehingga mudah di pahami. Sulit di pahami bagi orang yang tidak mengerti ekspresi matematika dan logikanya. Baik digunakan untuk pengembangan aplikasi matematika atau perhitungan. Aspect Oriented Software Development oleh Gregor Kiczales et all. Mendukung modularisasi perhatiannya sejak dari pembuatan kode program. Waktu pengerjaan kode program akan lebih lama karena lebih memperhatikan modul-modul program yang tersusun rapi. Baik digunakan untuk proyek skala besar. Aplikasi yang berbasis object oriented. Unified Process oleh Ivar Hjalmar Jacobson et all 1939-N pada tahun 1990 Team proyek fokus pada alamat yang memiliki banyak resiko paling tinggi lebih awal. Sehingga dapat meminimalisir resiko pada saat aplikasi sudah jadi. Waktu pengerjaan proyek lebih lama karena menggabungkan konsep iterative dan incremental. Baik digunakan untuk aplikasi yang dibuat berbasis object oriented dengan notasi rational rose. Extreme Programming XP oleh Kent Beck 1943-N pada tahun 1999 Peningkatan kualitas software dan memfokuskan pada perubahan- perubahan yang diminta oleh pelanggan. Para pengembang tidak bisa mengembangkan kualitas software karena tidak ada feedback dari pelanggan. Baik untuk software yang sudah ada tetapi masih dibutuhkan pengembangan kualitas karena kebutuhan- kebutuhan dari pelanggan. 67

3.2.2 Pemilihan Model Pengembangan Sistem

Model waterfall biasa disebut juga dengan The Classic Life Cycle, menyarankan sistematik, pendekatan berurutan untuk pengembangan software yang memulai dengan spesifikasi pelanggan terhadap syarat- syarat dan perkembangan melewati planning, modeling, construction, dan deployment menaik dalam mendukung terhadap kelengkapan software Pressman 2005:79. Dalam penelitian ini penulis menggunakan model waterfall karena dalam model waterfall pengembangan perangkat lunak disusun secara berurutan dimana hal ini akan memudahkan penulis dalam pembuatan perangkat lunak sehingga model waterfall tepat untuk digunakan karena tahap-tahapnya jelas dan berurutan dan yang lebih penting adalah perangkat lunak yang dikembangkan oleh penulis tidak terlalu kompleks atau kecil. Dan berikut ini merupakan gambar dari model waterfall. Communication Project initiation Requirement Gathering Planning Estimating Schedjuling Tracking Modeling Analisys Design Construction Code Test Develoyment Delivery Support Feedback Gambar 3.1 Model Waterfall 68 1. Komunikasi Communication Tahapan pertama untuk mengembangkan perangkat lunak pada model waterfall adalah komunikasi, komunikasi ini merupakan pembicaraan awal antara pengembangan perangkat lunak dan pelanggan. Dalam tahap komunikasi ini ada beberapa point yang perlu di perhatikan yaitu : a. Nama projek Project Initiation Pembicaraan awal mengenai pembuatan suatu perangkat lunak harus dilakukan karena menentukan perangkat lunak apa yang akan dibuat. Pada penulisan skripsi ini penulis telah menentukan perangkat lunak apa yang akan dibuat untuk penelitian ini. Perangkat lunak yang akan dikembangkan dalam penelitian ini adalah perangkat lunak sampling frekuensi file audio. b. Syarat-syarat atau kebutuhan Requirement Telah disebutkan diatas nama perangkat lunak yang akan dibuat adalah perangkat lunak sampling frekuensi file audio. Langkah selanjutnya dalam bagian dari komunikasi ini adalah mendefinisikan syarat-syarat atau kebutuhan-kebutuhan yang dibutuhkan dalam pengembangan perangkat lunak ini. Dalam penelitian ini penulis mendefinisikan kebutuhan berdasarkan studi pustaka dan studi literatur.