PEMODELAN WATERFALL UNTUK PENGEMBANGAN PERANGKAT LUNAK

Ini dianggap sebagai model siklus hidup pengembangan perangkat lunak yang paling dasar dan merupakan pendekatan linear dan sekuensial untuk mengembangkan perangkat lunak. Dalam model ini, setiap proses membutuhkan persyaratan untuk diselesaikan sebelum lanjut ke fase berikutnya. Sesuai Penamanya, model waterfall seperti air terjun alami di mana setelah air telah mengalir melalui tepi tebing dan mulai mengalir ke bawah tidak pernah berbalik kembali untuk mencapai puncak bukit. Begitupula proses yang terjadi pada model waterfall, setiap proses yang dilaksanakan pada satu fase tidak dapat kembali ke fase sebelumnya. Model waterfall hanya memiliki satu opsi dan itu bergerak maju. Dalam model waterfall, biasanya sebuah dokumen adalah output dari setiap fase yang berfungsi sebagai input ke fase berikutnya. Dengan demikian diperlukan mekanisme yang memastikan bahwa proses dilakukan secara terkendali tanpa mempengaruhi produknya. Perusahaan seperti Toyota menggunakan model ini untuk pengembangan. Secara umum model waterfall memiliki lima (5) tahan utama, yaitu: 1) Analisis, 2) Perancangan, 3) Implementasi, 4) Integrasi dan Pengujian, dan 5) Tahap Operasi dan Pemeliharaan. Masing-masing tahap akan dijabarkan sebagai berikut:

1. Analisis. Tahap awal ini mungkin yang paling rawan kesalahan, memakan waktu dan fase yang paling mahal. Fase ini bertujuan untuk memahami, mengumpulkan, dan mendokumentasikan persyaratan pengguna. Persyaratan pengguna adalah alasan utama untuk pengembangan perangkat lunak dan karenanya perlu diperhatikan dengan tepat. Kebutuhan elisitasi adalah upaya bersama dari klien dan pengembang karena tujuannya adalah untuk mendokumentasikan semua fungsi, kinerja dan persyaratan antarmuka dari produk perangkat lunak. Fase ini mengarah pada pengembangan dokumen besar yang ditulis dalam bahasa alami dan yang berisi "Apa" sistem tanpa menjelaskan "Bagaimana". Dokumen yang dihasilkan ini disebut dokumen spesifikasi kebutuhan perangkat lunak/software requirements specification (SRS). SRS dapat bertindak sebagai kontrak antara pengembang dan klien. Jika pengembang mengalami kegagalan untuk memenuhi persyaratan dalam SRS, secara langsung produk dapat disebut sebagai produk gagal.
2. Perancangan. Dokumen SRS yang diproduksi pada tahap sebelumnya berfungsi sebagai input fase ini. Persyaratan harus diubah menjadi struktur yang cocok untuk desain dan implementasi dalam beberapa bahasa pemrograman yang sesuai. Arsitektur keseluruhan didefinisikan dan pekerjaan tingkat tinggi yang terperinci dan dirancang dilakukan. Proses didokumentasikan dan dikenal sebagai dokumen deskripsi desain perangkat lunak/Software Design Descryption (SDD). SDD mungkin berisi jargon teknis dan memberi tahu juga tentang "Bagaimana" dari perangkat lunak. Informasi yang disediakan dalam SDD harus cukup untuk memulai perancangan. 
3. Implementasi. Berdasarkan informasi yang disediakan oleh SDD para perancang harus mulai membangun/mengembangkan perangkat lunak. Jika SDD berisi semua informasi yang diperlukan dan lengkap, konsisten dan akurat maka fase ini harus berjalan lancar. Pengujian berfokus pada pemeriksaan, koreksi dan modifikasi kode. Dalam pengujian unit perangkat lunak diuji satu modul pada waktu yang independen dari yang lain. Biasanya, proses integrasi dan pengujian sistem ini membutuhkan pengerjaan ulang modul dan penulisan kode baru untuk memperbaiki masalah dalam operasi atau interaksi potongan karena masalah tak terduga serta kesalahan, miskomunikasi, atau perubahan yang merayap ke dalam desain bagian-bagian. selama proyek. Jika integrasi ini berjalan dengan baik, tim akan mengirimkan produk ketika tidak ada bug serius (kesalahan atau cacat) yang tersisa.
4. Integrasi dan Pengujian Sistem. Pada fase ini, fungsi yang sudah dibangun pada aplikasi akan diintegrasikan dengan fungsi lain. Penggabungan ini kerap menimbulkan masalah, salah satunya adalah  bagaimana fungsi yang berbeda berinteraksi satu sama lain. Pengujian sistem mengatasi masalah ini dengan menguji perangkat lunak secara keseluruhan. Pengujian yang efektif akan memastikan kualitas yang lebih tinggi dari perangkat lunak kami, pengguna yang lebih puas, biaya perawatan yang lebih rendah dan hasil yang lebih akurat dan dapat diandalkan. Fase ini adalah aktivitas yang sangat mahal dan menghabiskan hingga setengah biaya total anggaran perangkat lunak.
5. Tahap Operasi dan Pemeliharaan. Ini adalah fase yang muncul setelah perangkat lunak dirilis, dipasang, dan beroperasi. Fase pemeliharaan dimulai dengan rilis perangkat lunak dan berlanjut sepanjang siklus hidup perangkat lunak. Perawatan perangkat lunak termasuk koreksi kesalahan, peningkatan fungsi dan kemampuan, pengenalan fungsi baru, penghapusan yang sudah tidak terpakai dan optimalisasi perangkat lunak.

Waterfall merupakan model pengembangan perangkat lunak dengan pendekan linear dan skuensial. Dengan pendekatannya ini, waterfall memberikan beberapa keunggulan, yaitu:

1. Menyediakan struktur untuk mengatur dan mengendalikan proyek pengembangan perangkat lunak. Setiap tahan yang dijalankan harus menunggu tahap sebelumnya selesai.
2. Mempermudah pembuatan dokumen teknis sehingga mempermudah komunikasi dengan klien untuk mengetahui apa yang mereka harapkan dari perangkat lunak yang akan dikembangkan. Dokumentasi juga membantu dalam proses pemeliharaan.
3. Jika prosedur diikuti dengan benar maka estimasi biaya dan waktu dapat diprediksi secara akurat.
4. Karena sifatnya yang berurutan dan kesalahan linear dalam satu fase dapat dideteksi sebelum pindah ke tahap yang lain.
5. Semakin mudah dokumentasi yang dibuat memungkinkan setiap pekerja baru yang bergabung dengan tim pengembangan akan lebih cepat beradaptasi dan memahami proses yang dilaksanakan.
6. Untuk proyek yang lebih kecil, ini adalah model terbaik untuk digunakan. Juga membutuhkan lebih sedikit sumber daya dibandingkan dengan yang lain.
7. Unggul dalam metode departemenalisasi dan kontrol manajerial. Ini memungkinkan produk selesai tepat waktu dengan menetapkan jadwal untuk setiap fase. 

Sama seperti model-model pengembangan yang lain, waterfall juga memiliki beberapa kelemahan, antara lain sebagai berikut: 

1. Membutuhkan semua persyaratan yang harus ditentukan pada awal, sudah tentu tidak mungkin untuk proyek-proyek jangka pendek dan dengan pengguna yang menginginkan perubahan yang tiba-tiba. 
2. Karena input sudah ditentukan berdasarkan hasil dari fase sebelumnya, dan tidak ada perubahan syarat, pada proses pengembangannya membutuhkan team yang professional agar mampu mengestimasi waktu dan biaya yang dibutuhkan.
3. Karena modelnya linear dan skuensial, sangat tidak memungkinkan mengakomodasi perubahan. 
4. Banyak waktu dan tenaga terbuang sembari menunggu satu fasa selesai. Misalnya, ketika desainer sibuk merancang perangkat lunak, tim pengembangan menjadi menjadi menganggur. 
5. Waterfall akan mengalami kegagalan untuk perangkat lunak atau teknologi yang berumur pendek. Dengan kata lain perangkat lunak-perangkat keras yang sering mendapat perubahan baik dari segi konten maupun fungsi. Misalnya perangkat lunak dan perangkat keras PC dimana kebutuhan konsumen berubah dengan sangat cepat. Kondisi ini menuntuk persyaratan klien berubah sangat cepat. Dalam situasi seperti itu, menganalisis spesifikasi proyek di awal sangat sulit. Akibatnya, perkembangan tidak dapat terjadi secara linier. Setiap perubahan pada bagian apa pun dari produk misal karena umpan balik dari klien, evolusi dalam perangkat keras atau teknologi perangkat lunak tertentu, atau bahkan hanya untuk menambahkan fitur yang baru, resiko terbesar adalah perangkat tidak lagi compatible dengan perangkat lainnya.

Dari pemaparan di atas, akan memunculkan satu pertanyaan, kapan sebaiknya menggunakan model waterfall dalam mengembangkan suatu produk?. Berikut akan dijabarkan pertimbangan-pertimbangan jika akan menggunakan model waterfall.

1. Ada prototip dari produk yang dikembangkan.
2. Ketika minat pada produk akhir yang akan dikembangkan sedang menjadi perhatian/tren saat itu.
3. Ketika persyaratan didefinisikan dengan baik dan dipahami bahwa persyaratan tidak dapat berubah.
4. Model waterfall berkerja dengan baik jika perubahan hanya terbatas pada penambahan fitur tanpa mengubah struktur sistem.
5. Ketika kualitas lebih penting dari waktu dan biaya.
6. Ini juga skala baik untuk proyek-proyek di mana perubahan dalam desain dapat diperkenalkan dengan cara yang terkontrol dan pengembangan dapat dilanjutkan tanpa persyaratan klien atau pesaing. 

Sumber:

Balaji, S., dan  Murugaiyan, M.Sundararajan. 2012. Waterfall vs V-Model vs Agile: A Comparative Study on SDLC. International Journal of Information Technology and Business Management. Vol.2 No. 1

Kannan, Vaishnavi, Jhajharia, Smita, dan Verma, Seema. 2014. Agile vs waterfall: A Comparative Analysis. International Journal of Science, Engineering and Technology Research (IJSETR). Volume 3. Issue 10.

Alshamrani, Adel, & Bahattab, Abdullah, 2015. A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental/Iterative Model. International Journal of Computer Science Issues (IJCSI). Volume 12, Issue 1, No 1.