63
3.2 Metode Pengembangan Sistem
Dalam sebuah perancangan perangkat lunak diperlukan model- model proses atau paradigm rekayasa perangkat lunak berdasarkan sifat
aplikasi dan proyeknya, metode dan alat bantu yang dipakai dan kontrol serta penyampaian yang dibutuhkan. Pressman 2005:79 ada beberapa
proses model diantaranya Sequential linier, Prototype, Rapid Application Development RAD, Incremental, Iterative, Spiral, Concurrent,
Component-Based Development, Model Metode Fomral, Aspect Oriented Development, Unified Process, dan Extreme Programming XP.
3.2.1 Perbedaan Model Pengembangan Sistem
Untuk menyelesaikan masalah didalam sebuah sistem harus dilakukan strategi pengembangan yang melingkupi proses, metode, dan
alat bantu serta fase-fase generik. Berikut tabel perbedaan model-model pengembangan sistem.
Tabel 3.1 Perbedaan Pengembangan Sistem
Metode Kelebihan
Kekurangan Penggunaan
secara umum
Sequential Linier Waterfall oleh
Winston W. Royce 1929-1995 pada
tahun 1970 Metode ini baik
digunakan untuk kebutuhan yang
sudah diketahui dengan baik.
Iterasi yang sering terjadi
menyebabkan masalah baru.
Bagi pelanggan sulit menentukan
kebutuhan secara eksplisit dan
harus bersabar Waterfall bekerja
dengan baik pada proyek skala kecil.
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.
Kategori