Waterfall Development Model
Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Berikut ini ada dua gambaran dari waterfall model. Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama dalam intinya.
Fase-fase dalam Waterfall Model menurut referensi Pressman:
Fase-fase dalam Waterfall Model menurut referensi Sommerville :
a. Requirements analysis and definition
Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.
b. System and software design
Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
c. Implementation and unit testing
Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.
d.Integration and system testing
Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
e.Operation and maintenance
Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah dengan waterfall :
- Perubahan sulit dilakukan karena sifatnya yang kaku.
- Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
- Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
Spiral Development Model
Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
Objective settings (menentukan tujuan)
Menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
Risk assessment and reduction (Penanganan dan pengurangan resiko)
Setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
Development and Validation (Pembangunan dan pengujian):
Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
Planning
Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.
Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:
Customer communication
Membangun komunikasi yang baik dengan pengguna/customer.
Planning
Mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek
Risk analysis
Identifikasi resiko managemen dan teknis
Engineering
Pembangunan contoh-contoh aplikasi, misalnya prototype
Construction and release
Pembangunan, test, install dan support.
Customer evaluation
Mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
Incremental Development Model
Kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan.
Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
Mampu mengakomodasi perubahan secara fleksibel.
Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.
Masalah dengan Incremental model:
cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment
Evolutionary Development Model
- Pengembangan yang berdasarkan penyidikan
Tujuannya untuk mengaktifkan pengguna dan memperolah model final berasal dari initial spesifikasi awal. Seharusnya diawali dengan kebutuhan yang sudah dimengerti.
Throw-away prototyping
Tujuannya adalah untuk memahami kebutuhan sistem. Biasanya diawali dengan pemahaman kebutuhan yang minim.
Permasalahan dalam model pengembangan yang berevolusi:
Kekurangan visibilitas proses
Model sistem biasanya tidak terstruktur
Membutuhkan kemampuan khusus (mis.: bahasa pemrograman untuk rapid prototyping).
Pemakaian model pengembangan yang berevolusi:
Untuk sistem interaktif yang kecil atau menengah
Untuk salah satu bagian dari sistem yang besar (mis. User Interface)
Untuk sistem yang digunakan tidak terlalu lama (short lifetime).
