Model air terjun - Riwayat revisi

Maintenance script: Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

2026-08-23T14:07:50Z

Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

← Revisi sebelumnya		Revisi per 23 Agustus 2026 14.07
Baris 1:		Baris 1:
	'''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]]).		'''Model ''waterfall''''' atau sering kali disebut sebagai ''classic life cycle'' adalah model pengembangan perangkat lunak yang menekankan fase-fase yang berurutan dan sistematis,<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref> 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]]).<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Sejarah ==		== 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]].		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]].<ref>United States, Navy Mathematical Computing Advisory Panel (29 June 1956), ''Symposium on advanced programming methods for digital computers'', [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738</ref> 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]].<ref>Herbert D. Benington. [http://dx.doi.org/10.1109/mahc.1983.10102 Production of Large Computer Programs]. ''IEEE (Computing)''. 1983-10. Vol. 5 (4). hlm. 350–361. doi:10.1109/mahc.1983.10102.</ref>

	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.		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.<ref>Conrad Weisert, Waterfall methodology: there's no such thing!</ref> Penggunaan awal dari istilah ''waterfall'' mungkin dalam makalah tahun [[1976]] oleh Bell and Thayer.<ref>Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? ''Proceedings of the 2nd international conference on Software engineering.'' IEEE Computer Society Press, 1976.</ref>

	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"''.		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"''.<ref>Military Standard Defense System Software Development</ref>

	== Model ==		== Model ==
			Dalam model ''waterfall'' Royce, fase-fase berikut diikuti secara berurutan:<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>

	~~Dalam~~ model ''~~waterfall~~'' Royce, ~~fase-fase berikut diikuti secara berurutan~~:		# ''System and software requirements'' : ditangkap dalam [[dokumen kebutuhan produk]]<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>
			# ''Analysis'': menghasilkan model, skema, dan aturan bisnis<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>
			# ''Design'': menghasilkan [[arsitektur perangkat lunak]]<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>
			# ''Coding'': pengembangan, pembuktian, dan integrasi perangkat lunak<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>
			# ''Testing'': penemuan dan ''debugging'' cacat yang sistematis<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>
			# Operations: instalasi, migrasi, dukungan, dan pemeliharaan sistem yang lengkap<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref>

	~~# ''System and software requirements'' : ditangkap dalam [[dokumen kebutuhan produk]]~~		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.<ref>Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), ''Proceedings of IEEE WESCON'', '''26''' (August): 1–9</ref> Adapun di dalam buku Software Engineering: A practitioners approach, fase model waterfall terbagi menjadi Communication, planning, modeling, construction, dan deployment.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>
	~~# ''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 ==		== 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.		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)<ref>McConnell, Steve, 1962-. [http://worldcat.org/oclc/951344627 Rapid development : taming wild software schedules]. Microsoft Press. 2014. ISBN 9781556159008.</ref>.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.<ref>[https://www.oxagile.com/article/the-waterfall-model/ Waterfall Software Development Model].</ref>

	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.		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.<ref>[http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-LifeCycle-SDLC.pdf Arcisphere technologies].</ref> 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.<ref>Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.</ref>

	== Kekurangan ==		== 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.		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.<ref>David Lorge Parnas. [http://dx.doi.org/10.1109/tse.1986.6312991 Correction to “a rational design process: How and why to fake it”]. ''IEEE Transactions on Software Engineering''. 1986-08. Vol. SE-12 (8). hlm. 874–874. doi:10.1109/tse.1986.6312991.</ref> 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.<ref>McConnell, Steve. [https://www.worldcat.org/oclc/27035508 Code complete : a practical handbook of software construction]. Microsoft Press. 1993. ISBN 1556154844.</ref> 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.<ref>[http://dx.doi.org/10.7551/mitpress/8033.003.0002 The Computer Boys Take Over]. The MIT Press. 2010. ISBN 9780262289351.</ref>

	~~== Referensi ==~~

	== Pranala luar ==		== 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.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.business-esolutions.com/islm.htm Project lifecycle models: how they differ and when to use them]
Baris 38:		Baris 34:
	* [http://www.ibm.com/developerworks/rational/library/3012.html CSC and IBM Rational join to deliver C-RUP and support rapid business change]		* [http://www.ibm.com/developerworks/rational/library/3012.html CSC and IBM Rational join to deliver C-RUP and support rapid business change]

			== Referensi ==
			<references />

	== Sumber dan atribusi ==		== 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.		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.

			<!-- WIKI_UNISSULA_PRESENTATION_V4 -->

Maintenance script: Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 25364919; atribusi sumber disertakan.

2026-08-23T13:46:20Z

Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 25364919; atribusi sumber disertakan.

Halaman baru

'''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.