Lompat ke isi

Model air terjun

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
(Dialihkan dari Proses air terjun)
Versi yang bisa dicetak tidak lagi didukung dan mungkin memiliki kesalahan tampilan. Tolong perbarui markah penjelajah Anda dan gunakan fungsi cetak penjelajah yang baku.

Model waterfall atau sering kali disebut sebagai classic life cycle adalah model pengembangan perangkat lunak yang menekankan fase-fase yang berurutan dan sistematis,[1] 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 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).[2]

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.[3] Presentasi ini adalah tentang pengembangan perangkat lunak untuk 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.[4]

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.[5] Penggunaan awal dari istilah waterfall mungkin dalam makalah tahun 1976 oleh Bell and Thayer.[6]

Pada tahun 1985, 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, danTesting".[7]

Model

Model waterfall yang belum dimodifikasi. Proses berjalan dari atas ke bawah seperti waterfall.

Dalam model waterfall Royce, fase-fase berikut diikuti secara berurutan:[1]

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

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.[1] Adapun di dalam buku Software Engineering: A practitioners approach, fase model waterfall terbagi menjadi Communication, planning, modeling, construction, dan deployment.[2]

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)[8].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.[9]

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.[10] 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.[11]

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.[12] 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.[13] 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.[14]

Referensi

  1. ^ a b c d e f g h i Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
  2. ^ a b Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534. 
  3. ^ 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
  4. ^ Benington, Herbert D. (1983-10). "Production of Large Computer Programs". IEEE (Computing). 5 (4): 350–361. doi:10.1109/mahc.1983.10102. ISSN 1058-6180. 
  5. ^ Conrad Weisert, Waterfall methodology: there's no such thing!
  6. ^ 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.
  7. ^ Military Standard Defense System Software Development
  8. ^ McConnell, Steve, 1962- (2014). Rapid development : taming wild software schedules. Microsoft Press. ISBN 9781556159008. OCLC 951344627. 
  9. ^ "Waterfall Software Development Model". 
  10. ^ "Arcisphere technologies" (PDF). Diarsipkan dari versi asli (PDF) tanggal 2019-02-17. 
  11. ^ Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.
  12. ^ Parnas, David Lorge; Clements, Paul C. (1986-08). "Correction to "a rational design process: How and why to fake it"". IEEE Transactions on Software Engineering. SE-12 (8): 874–874. doi:10.1109/tse.1986.6312991. ISSN 0098-5589. 
  13. ^ McConnell, Steve. (1993). Code complete : a practical handbook of software construction. Redmond, Wash.: Microsoft Press. ISBN 1556154844. OCLC 27035508. 
  14. ^ The Computer Boys Take Over. The MIT Press. 2010. ISBN 9780262289351. 

Pranala luar

Wikimedia Commons memiliki media mengenai Model Waterfall.
Diperoleh dari "https://wiki-indonesia.club/w/index.php?title=Model_air_terjun&oldid=25364919"