Rekayasa Perangkat Lunak

Irvan 2021

Waterfall Model
Waterfall Model Diagram

Requirements

Design

Implementation

Testing

Maintenance
History Waterfall Model
• Penggunaan metode waterfall pertama kali diperkenalkan oleh Herbert D.
Benington di Symposium on Advanced Programming Method for Digital
Computers pada tanggal 29 Juni 1956. Presentasi tersebut menjelaskan tentang
pengembangan perangkat lunak untuk SAGE (Semi Automatic Ground
Environment).

• Pada tahun 1983, dipresentasikan kembali oleh Benington dan menjelaskan

tentang fase – fase dalam proses pengembangannya. Dan pada tahun 1985,
Departemen Pertahanan Amerika Serikat juga menggunakan metode ini dengan
beberapa tahapan yang digunakan, terdiri dari 6 fase, yaitu: Preliminary design,
Detailed design, Coding and unit testing, Integration, dan Testing.
• Winston W. Royce
• Barry Boehm (1987)
• “Makalah Royce tahun 1970 umumnya dianggap sebagai makalah yang mendefinisikan
model “waterfall" dari proses perangkat lunak. Tetapi cukup mengejutkan untuk melihat
bahwa makalah Benington dan Hosier sebelumnya memiliki perkiraan yang baik untuk
model waterfall, dan bahwa makalah Royce sudah memasukkan pembuatan prototipe
sebagai langkah penting yang kompatibel dengan model waterfall”.
• Faktanya, Royce mendemonstrasikan bahwa meskipun pengembangan
sistem perangkat lunak yang besar membutuhkan pendekatan yang
lebih menyeluruh, terdapat risiko yang melekat pada pendekatan
sekuensial satu jalur. Dia mengusulkan pendekatan berulang dan
menganjurkan bahwa proyek harus melewati ini setidaknya dua kali.
Karakteristik Waterfall Model
• setiap fase dijalankan secara berurutan
• keluaran yang dihasilkan oleh satu fasa menjadi masukan untuk fasa
berikutnya
• fase baru tidak dimulai hingga fase saat ini berakhir
• dalam praktiknya, mungkin ada sedikit tumpang tindih antar fase
• Dalam praktiknya, hubungan berulang antara fase yang berdekatan tidak bisa
dihindari
• eksekusi melanjutkan ke fase baru saat
• Dokumentasi yang diperlukan untuk fase saat ini telah selesai
• kriteria keluar untuk fase saat ini telah selesai
• kriteria masuk untuk tahap selanjutnya telah selesai
Keuntungan
• Sederhana / mudah untuk dipahami dan diterapkan
• setiap fase dijalankan dalam urutan yang ditetapkan, satu demi satu
• sekuensial, fase langkah demi langkah mudah dipahami
• setiap fase membutuhkan kriteria masuk dan keluar yang spesifik untuk dipenuhi
• Proven and well-known
• proses tersebut telah digunakan dengan sukses selama bertahun-tahun
• banyak orang telah menjadi bagian dari proyek pengembangan perangkat lunak
yang menggunakan proses tersebut
• mudah dikelola
• karena model proses sangat kaku, manajemen proses mudah
• Penyampaian untuk setiap fase jelas
• Alokasi sumber daya yang mudah
• urutan fase secara berurutan membuatnya mudah untuk menetapkan dan
mengelola sumber daya
• karena setiap fase memiliki kebutuhan spesifiknya sendiri, individu dengan
keterampilan khusus tersebut dapat dengan mudah ditugaskan ke fase yang
berbeda
• bagus untuk proyek kecil
• proses ini mengasumsikan bahwa semua persyaratan dipahami dengan jelas
di awal proses
• dalam proyek yang lebih kecil, persyaratan biasanya lebih kecil dan lebih
mudah
Kerugian
• persyaratan yang jelas, lengkap dari awal
• sangat sulit untuk secara akurat dan lengkap menangkap semua persyaratan
di awal proyek.
• Biasanya, sebuah proyek dimulai tanpa pemahaman lengkap tentang semua
persyaratan.
• seiring kemajuan proyek, lebih banyak persyaratan ditemukan dan proyek
diubah sesuai dengan itu.
• umpan balik (feedback) tertunda
• Stakeholder tidak dapat memberikan umpan balik sampai setelah tahap
pengujian.
• karena prosesnya tidak berulang, ini tidak mudah memberikan Stakeholder
versi perantara dari sebuah produk.
• Seringkali diinginkan dan perlu untuk memberikan kepastian kemajuan
kepada stakeholder, serta memberi mereka konfirmasi bahwa apa yang
dikembangkan memenuhi persyaratan mereka.
• masalah ditemukan terlambat
• menurut proses ini, masalah ditemukan selama tahap pengujian.
• Tergantung pada jumlah dan sifat masalah yang ditemukan, dampaknya dapat
berdampak buruk pada proyek, baik dari segi biaya maupun jadwal.
• sulit untuk diperkirakan
• tanpa proses berulang, sulit untuk mengukur kecepatan tim.
• beberapa aspek yang lebih berisiko dari proyek mungkin memerlukan
pembuatan prototipe untuk mendapatkan pemahaman yang lebih baik
tentang tantangan yang ditimbulkannya.
• Tidak ada proses parallel
• setiap fase dijalankan secara berurutan, dan selesai sebelum melanjutkan ke
tahap berikutnya.
• pada kenyataannya, dimungkinkan untuk menjalankan beberapa fase secara
paralel, bukan secara berurutan.
• misalnya, produk yang sedang dibangun mungkin terdiri dari subsistem yang
relatif tidak berhubungan. subsistem yang terpisah ini dapat dikembangkan
secara paralel
• Penggunaan sumber daya yang tidak efisien
• karena fase harus dijalankan secara berurutan, beberapa anggota tim
mungkin menganggur sambil menunggu fase tertentu selesai.
• meskipun keinginannya adalah untuk memindahkan individu yang
menganggur ke fase aktif saat ini, kenyataannya adalah bahwa individu-
individu ini mungkin tidak memenuhi syarat untuk tugas dalam fase itu.
kesimpulan
• model lama, terkenal, fundamental untuk pengembangan perangkat
lunak, mudah dipahami dan mudah digunakan
• ini berfungsi baik untuk proyek kecil dan sederhana
• sayangnya, ia hanya memiliki terlalu banyak kerugian untuk digunakan
untuk proyek-proyek pembangunan yang kompleks
Next V-Model