Lihat sumber Model air terjun

'''Model ''waterfall''''' atau sering kali disebut sebagai ''classic life cycle'' adalah model pengembangan perangkat lunak yang menekankan fase-fase yang berurutan dan sistematis, dimulai dari spesifikasi kebutuhan [[konsumen]] dan berkembang melalui proses perencanaan (''planning''), pemodelan (''modelling''), pembangunan (''construction''), dan penyebaran (''deployment''), yang berujung pada dukungan terus menerus untuk sebuah [[perangkat lunak]] yang utuh. Model ini dapat digunakan pada saat kebutuhan untuk sebuah masalah telah dipahami dengan baik, dan pekerjaan dapat mengalir secara linear dari proses komunikasi hingga penyebaran (''deployment''). Situasi ini ditemui saat adaptasi atau perpanjangan dari sistem yang ada sudah terdefinisi dengan baik. Adapun model ini juga dapat digunakan pada situasi di mana dibutuhkan usaha yang terbatas untuk pengembangan perangkat lunak, tetapi [[Teknik kebutuhan perangkat lunak|kebutuhan perangkat lunak]] sudah terdefinisi dengan baik dan cenderung stabil. Namun, dalam pengembangan perangkat lunak, model ini cenderung menjadi salah satu pendekatan yang kurang iteratif dan fleksibel, karena proses mengalir satu arah ("ke bawah" seperti [[air terjun]]).

== Sejarah ==
Presentasi pertama yang menggambarkan penggunaan fase dari model ''waterfall'' dalam [[rekayasa perangkat lunak]] diberikan oleh [[Herbert D. Benington]] di ''Symposium on Advanced Programming Methods for Digital Computers'' pada tanggal [[29 Juni]] [[1956]]. Presentasi ini adalah tentang pengembangan [[perangkat lunak]] untuk [[:en:Semi-Automatic Ground Environment|SAGE]]. Pada tahun [[1983]], makalah ini diterbitkan kembali dengan kata pengantar oleh Benington yang menjelaskan bahwa fase-fase tersebut sengaja disusun sesuai dengan spesialisasi tugas, dan menunjukkan bahwa proses tersebut sebenarnya tidak dilakukan dengan cara ''top-down'' yang ketat, tetapi tergantung pada [[prototipe]].

Deskripsi formal pertama dari model ''waterfall'' sering dikutip sebagai artikel tahun [[1970]] oleh [[Winston W. Royce]], meskipun Royce tidak menggunakan istilah ''waterfall'' dalam artikel itu. Royce menyajikan model ini sebagai contoh model cacat yang tidak bekerja; itulah istilah yang umumnya digunakan dalam penulisan tentang pengembangan perangkat lunak — untuk menggambarkan pandangan kritis praktik pengembangan perangkat lunak yang umum digunakan. Penggunaan awal dari istilah ''waterfall'' mungkin dalam makalah tahun [[1976]] oleh Bell and Thayer.

Pada tahun [[1985]], [[Departemen pertahanan amerika serikat|Departemen Pertahanan Amerika Serikat]] menangkap pendekatan ini dalam [[DOD-STD-2167A]], standar mereka untuk bekerja dengan kontraktor pengembangan perangkat lunak, yang menyatakan bahwa "kontraktor harus menerapkan siklus pengembangan perangkat lunak yang mencakup enam fase berikut: ''Preliminary Design, Detailed Design, Coding and Unit Testing, Integration,'' dan''Testing"''.

== Model ==

Dalam model ''waterfall'' Royce, fase-fase berikut diikuti secara berurutan:

# ''System and software requirements'' : ditangkap dalam [[dokumen kebutuhan produk]]
# ''Analysis'': menghasilkan model, skema, dan aturan bisnis
# ''Design'': menghasilkan [[arsitektur perangkat lunak]]
# ''Coding'': pengembangan, pembuktian, dan integrasi perangkat lunak
# ''Testing'': penemuan dan ''debugging'' cacat yang sistematis
# Operations: instalasi, migrasi, dukungan, dan pemeliharaan sistem yang lengkap

Dengan demikian model ''waterfall'' menyatakan bahwa tim proyek harus pindah ke fase lainnya hanya ketika fase sebelumnya ditinjau dan diverifikasi. Namun, berbagai model ''waterfall'' yang dimodifikasi (termasuk model akhir Royce) dapat mencakup sedikit variasi utama dalam proses ini. Variasi ini termasuk kembali ke siklus sebelumnya setelah cacat ditemukan di hilir, atau kembali ke fase desain jika fase hilir dianggap tidak cukup. Adapun di dalam buku Software Engineering: A practitioners approach, fase model waterfall terbagi menjadi Communication, planning, modeling, construction, dan deployment.

== Kelebihan ==
Waktu yang dihabiskan di awal siklus pengembangan perangkat lunak dapat mengurangi biaya pada tahap selanjutnya. Misalnya, masalah yang ditemukan pada tahap awal (seperti spesifikasi kebutuhan) lebih murah untuk diperbaiki daripada ''bug'' yang sama yang ditemukan kemudian dalam proses (dengan faktor 50 hingga 200).Dalam praktik umum, model ''waterfall'' menghasilkan jadwal proyek dengan 20–40% dari waktu yang diinvestasikan untuk dua fase pertama, 30–40% dari waktu untuk pengkodean, dan sisanya didedikasikan untuk pengujian dan implementasi. Organisasi proyek yang sebenarnya perlu sangat terstruktur. Sebagian besar proyek menengah dan besar akan mencakup serangkaian prosedur dan kontrol terperinci, yang mengatur setiap proses pada proyek.

Argumen lebih lanjut untuk model ''waterfall'' adalah bahwa ia menekankan pada dokumentasi (seperti dokumen kebutuhan dan dokumen desain) serta kode sumber. Dalam metodologi yang dirancang dan didokumentasikan secara kurang teliti, pengetahuan akan hilang jika anggota tim pergi sebelum proyek selesai, dan mungkin sulit bagi proyek untuk pulih dari kehilangan. Jika ada dokumen desain yang berfungsi penuh, maka anggota tim baru atau bahkan tim yang sama sekali baru harus dapat membiasakan diri dengan membaca dokumen. Model ''waterfall'' memberikan pendekatan terstruktur; model itu sendiri berkembang secara linier melalui fase-fase yang terpisah, mudah dimengerti dan dapat dijelaskan sehingga dengan demikian mudah dipahami; hal itu juga memberikan tonggak yang mudah diidentifikasi dalam proses pengembangan. Mungkin karena alasan inilah model ''waterfall'' digunakan sebagai contoh awal dari model pengembangan dalam banyak teks dan kursus rekayasa perangkat lunak.

== Kekurangan ==
Klien mungkin tidak tahu persis apa kebutuhan mereka sebelum mereka melihat perangkat lunak yang berfungsi dan karenanya mengubah kebutuhan mereka, yang mengarah ke pendesainan ulang, pengembangan kembali, dan pengujian ulang, dan peningkatan biaya. Desainer mungkin tidak menyadari kesulitan di masa depan ketika merancang produk atau fitur perangkat lunak baru, dalam hal ini lebih baik untuk merevisi desain daripada bertahan dalam desain yang tidak memperhitungkan kendala, kebutuhan, atau masalah yang baru ditemukan. Organisasi dapat berupaya untuk mengatasi kurangnya kebutuhan konkret dari klien dengan menggunakan analis sistem untuk memeriksa sistem manual yang ada dan menganalisis apa yang mereka lakukan dan bagaimana mereka dapat diganti. Namun, dalam praktiknya, sulit untuk mempertahankan pemisahan yang ketat antara analisis dan pemrograman sistem.

== Referensi ==

== Pranala luar ==

* [http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/ Understanding the pros and cons of the Waterfall Model of software development]
* [http://www.business-esolutions.com/islm.htm Project lifecycle models: how they differ and when to use them]
* [http://www-128.ibm.com/developerworks/rational/library/4626.html Going Over the Waterfall with the RUP] by [[Philippe Kruchten]]
* [http://www.ibm.com/developerworks/rational/library/3012.html CSC and IBM Rational join to deliver C-RUP and support rapid business change]



== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Model+air+terjun&oldid=25364919 Wikipedia bahasa Indonesia], revisi 25364919 (2024-02-25T08:10:59Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.