WaterFall Model

Model air terjun (Waterfall Model) adalah pendekatan klasik dalam pengembangan perangkat lunak yang menggambarkan metode pengembangan linier dan berurutan. Ini terdiri dari lima hingga tujuh fase, setiap fase didefinisikan oleh tugas dan tujuan yang berbeda, di mana keseluruhan fase menggambarkan siklus hidup perangkat lunak hingga pengirimannya. Setelah fase selesai, langkah pengembangan selanjutnya mengikuti dan hasil dari fase sebelumnya mengalir ke fase berikutnya.

Pengertian Waterfall Model

Model air terjun (Waterfall Model) adalah metode pertama yang banyak digunakan dalam industri perangkat lunak. model ini merupakan pendekatan tradisional, dan jauh kurang fleksibel daripada metodologi gesit dengan pengembangan dipecah menjadi sprint tunggal, tetapi dapat dilengkapi dengan loop umpan balik dan loopback. Saat ini masih digunakan dalam berbagai versi jika persyaratan dan karakteristik suatu perangkat lunak dapat didefinisikan dengan jelas selama fase konseptual.

Apa Itu Waterfall Model

Penyebutan pertama dari model bertahap kembali ke Winston Royce. Dalam esainya “Mengelola Pengembangan Sistem Perangkat Lunak Besar” ia menggambarkan metode pengembangan untuk proyek perangkat lunak besar, yang dibagi menjadi beberapa fase pada awal tahun 1970. Dia mengkritik pendekatan ini, dan mengusulkan alternatif yang menyerupai prototyping. Royce mengacu pada “Model Tahap-Wise Sembilan Fase” oleh Herbert Benington, yang diterbitkan pada tahun 1956. Sementara Benington membayangkan sembilan fase, Royce mengurangi mereka menjadi tujuh. Istilah “model air terjun” tidak digunakan oleh mereka berdua. Penggunaannya didasarkan pada buku dari tahun 1976, yang terutama membahas tentang persyaratan untuk perangkat lunak.

Bagaimana cara kerja Waterfall Model

Model air terjun Waterfall Model pada dasarnya terdiri dari tujuh fase berturut-turut:

1. Persyaratan sistem: Tahap pertama berkaitan dengan persyaratan yang tidak terkait dengan produk digital itu sendiri melainkan dengan aspek yang relevan dengan bisnis seperti harga dan ketersediaan. Aspek dokumentasi dan keselamatan juga ditentukan di sini. Secara umum, persyaratan non-fungsional disebutkan di sini.
2. Persyaratan perangkat lunak: Persyaratan fungsional untuk perangkat lunak didefinisikan pada fase kedua. Pertanyaan tentang apa yang harus dapat dilakukan oleh perangkat lunak dijawab di sini dan diklarifikasi dalam “spesifikasi,” yang juga mencakup hasil tahap pertama.
3. Analisis persyaratan: Pada fase analisis persyaratan, fungsi-fungsi perangkat lunak dibedah dan disusun sedemikian rupa sehingga elemen-elemen fungsional individu dan unit-unit fungsional dapat dipisahkan satu sama lain. Analisis persyaratan dimaksudkan untuk menguji fungsi untuk kelayakan dan kepentingannya. Hasil dari fase ini adalah spesifikasi yang berisi persyaratan yang perlu dikembangkan.
4. Desain program: Desain teknis sekarang diimplementasikan dengan bantuan spesifikasi persyaratan ini. Komponen fase ini juga termasuk keputusan tentang arsitektur informasi dan teknologi terapan seperti bahasa pemrograman, perpustakaan kelas, dan urutan program. Hasil desain program biasanya direkam dalam diagram yang menggambarkan perilaku teoritis perangkat lunak.
5. Implementasi: Selama implementasi, struktur dan alur kerja dilaksanakan dengan mempertimbangkan kondisi dan tujuan kerangka kerja sistemik. Desain perangkat lunak menjadi program yang terkait langsung dengan sistem operasi, satu atau lebih bahasa pemrograman, dan infrastruktur. Hasilnya biasanya berupa perangkat lunak operasional, seringkali sebagai versi beta.
6. Pengujian: Tahap implementasi diikuti oleh pengujian semua komponen perangkat lunak, modul, dan seluruh sistem. Integrasi ke dalam sistem operasi spesifik juga diperiksa. Jika kesalahan dan konflik terjadi, mereka harus segera diperbaiki. Hal ini dapat menyebabkan peningkatan biaya keseluruhan karena kesalahan yang mungkin dapat dikaitkan dengan fase yang berbeda dan tidak selalu disebabkan pada fase sebelumnya.
7. Peluncuran: Perangkat lunak diimplementasikan setelah penerimaan oleh klien. Pembaruan dan pemeliharaan mungkin diperlukan sebelum produk memasuki toko atau dikirim ke pelanggan.

Berbagai tim dan pakar bekerja pada tahap ini. Kontraktor, manajemen proyek, dan pengembang senior biasanya terlibat hingga tahap implementasi. Setelah implementasi, pengembang melakukan pekerjaannya, di mana pengujian perangkat lunak sering ditangani secara terpisah, misalnya oleh laboratorium pengujian independen. Ahli pemasaran dan layanan sebagian terlibat dengan peluncurannya. Di perusahaan dan perusahaan besar, metode SDLC yang dimodifikasi dan lebih terstruktur (siklus pengembangan sistem) digunakan, yang didasarkan pada model air terjun. Ada juga versi lain dari model ini yang, misalnya, memperkenalkan elemen berulang dalam bentuk loop untuk mendeteksi dan memperbaiki kesalahan dan bug dalam fase sebelumnya.

Manfaat / Kerugian

Beberapa keuntungan dan kerugian dari model air terjun:

Keuntungan Waterfall Model

• Karena struktur logis dari model, kesalahan konseptual seringkali dapat dihindari.
• Model ini mengarah pada dokumentasi teknis yang luas, yang merupakan kelegaan bagi programmer dan pengembang baru dan juga berguna dalam tahap pengujian.
• Kemajuan proyek dapat dipantau menggunakan tonggak sejarah.
• Total biaya dapat diperkirakan dengan akurasi relatif jika tidak ada konflik.

Kekurangan Waterfall Model

• Konflik, bug, dan kesalahan program terkadang menyebabkan kenaikan biaya dan waktu yang cukup lama. Hal yang sama berlaku jika klien tidak puas.
• Spesifikasi yang awalnya dibuat seringkali sulit untuk dipahami oleh klien karena lebih abstrak daripada apa yang seharusnya dilakukan oleh perangkat lunak. Terutama dalam proyek-proyek outsourcing, ini bisa menjadi kerugian yang menentukan, karena tanggal rilis harus ditunda dan pasar mungkin telah berubah selama waktu ini.
• Pengiriman perangkat lunak membutuhkan waktu lebih lama karena departemen tidak bekerja secara bersamaan dan setiap fase hanya dapat dimulai ketika fase sebelumnya selesai.

Signifikansi untuk pemrograman

Model air terjun (Waterfall Model) adalah salah satu model proses paling terkenal dalam pengembangan perangkat lunak. Ini telah berhasil digunakan selama beberapa dekade, tetapi sekarang hanya untuk proyek-proyek kecil di mana spesifikasinya jelas. Namun, kelemahan yang disebutkan di atas, juga membuat analis dan pengembang merancang model alternatif yang disebut pengembangan perangkat lunak gesit. Masalah utama dari model air terjun adalah bahwa perubahan dan revisi belum tentu disediakan oleh urutan logis. Umpan balik dari pelanggan, penguji, dan insinyur selama pengembangan sebagian hilang dan integrasi perangkat lunak ke dalam sistem yang ada berlangsung sekaligus. Kelemahan ini dapat dihindari dengan memodifikasi fase proyek, seperti halnya dengan model spiral. Tetapi untuk beberapa tahun sekarang, metode gesit yang menggunakan elemen struktural lainnya jauh lebih populer (misalnya, peran dan sprint dengan Scrum atau prinsip-prinsip pemrograman ekstrim). Sebagai aturan, mereka lebih ekonomis, mengarah pada hasil yang lebih cepat dan lebih transparan bagi pelanggan. Sebagai aturan, mereka lebih ekonomis, mengarah pada hasil lebih cepat dan lebih transparan bagi pelanggan.