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]
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,
dan
Testing"
.
[7]
Model
waterfall
yang belum dimodifikasi. Proses berjalan dari atas ke bawah seperti waterfall.
Dalam model
waterfall
Royce, fase-fase berikut diikuti secara berurutan:
[1]
- System and software requirements
: ditangkap dalam
dokumen kebutuhan produk
[1]
- Analysis
: menghasilkan model, skema, dan aturan bisnis
[1]
- Design
: menghasilkan
arsitektur perangkat lunak
[1]
- Coding
: pengembangan, pembuktian, dan integrasi perangkat lunak
[1]
- Testing
: penemuan dan
debugging
cacat yang sistematis
[1]
- 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]
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]
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]
- ^
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
- ^
a
b
Pressman, Roger S. (2015).
Software engineering : a practitioner's approach
. McGraw-Hill Education.
ISBN
9781259253157
.
OCLC
949696534
.
- ^
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
- ^
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
.
- ^
Conrad Weisert, Waterfall methodology: there's no such thing!
- ^
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.
- ^
Military Standard Defense System Software Development
- ^
McConnell, Steve, 1962- (2014).
Rapid development : taming wild software schedules
. Microsoft Press.
ISBN
9781556159008
.
OCLC
951344627
.
- ^
"Waterfall Software Development Model"
.
- ^
"Arcisphere technologies"
(PDF)
. Diarsipkan dari
versi asli
(PDF)
tanggal 2019-02-17.
- ^
Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri ? St. Louis. Retrieved 11 August 2014.
- ^
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
.
- ^
McConnell, Steve. (1993).
Code complete : a practical handbook of software construction
. Redmond, Wash.: Microsoft Press.
ISBN
1556154844
.
OCLC
27035508
.
- ^
The Computer Boys Take Over
. The MIT Press. 2010.
ISBN
9780262289351
.
|
---|
Bidang
| |
---|
Konsep
| |
---|
Orientasi
| |
---|
Model
| Model pengembangan
| |
---|
Model lain
| |
---|
Bahasa pemodelan
| |
---|
|
---|
Teknisi
Perangkat lunak
| |
---|
Bidang terkait
|
|
---|
|