CodeGym/Java Course/Modul 3/Air Terjun - Model Air Terjun

Air Terjun - Model Air Terjun

Level 15, Pelajaran 1
Tersedia

Perangkat model kaskade

Model air terjun, juga dikenal sebagai Air Terjun, adalah salah satu pendekatan pengembangan perangkat lunak yang paling terkenal. Penulis modelnya adalah Winston Royce. Pada tahun 1970, ia menggambarkan inti dari inovasinya dalam sebuah artikel yang merinci kelebihan dan kekurangannya. Di tempat yang sama, beliau menjelaskan bagaimana model ini dapat disempurnakan menjadi model iteratif. Awalnya, dalam model air terjun, tahapan pengembangan berjalan dengan urutan sebagai berikut:

  • Definisi dan koordinasi persyaratan;
  • Persetujuan proyek;
  • Pengodean;
  • Pembuatan versi kerja dari produk perangkat lunak;
  • Pengujian dan debug;
  • Instalasi perangkat lunak;
  • Mendukung.

Menurut model air terjun, eksekusi tindakan oleh pengembang terjadi secara berurutan - titik demi titik. Untuk memulainya, pekerjaan sedang diselesaikan untuk menentukan dan menyepakati persyaratan perangkat lunak dalam bentuk daftar yang harus diselesaikan.

Setelah itu, ada transisi ke pembuatan dan persetujuan proyek, sebagai akibatnya dokumentasi ditulis dengan menjelaskan bagaimana mengimplementasikan persyaratan perangkat lunak yang telah disepakati sebelumnya.

Jika desain selesai, pengembang melakukan implementasi. Berikutnya adalah penggabungan kode - integrasi masing-masing bagian proyek, yang dikerjakan oleh berbagai anggota tim.

Langkah selanjutnya adalah menguji dan men-debug produk. Kesalahan yang ditemukan sebelumnya diperbaiki di sini.

Akhirnya, program diinstal dan didukung. Ini melibatkan membuat, jika perlu, mengubah fungsionalitas dan menghilangkan kesalahan yang ditemukan.

Model kaskade mengasumsikan bahwa Anda dapat pindah ke tahap pengembangan berikutnya secara berurutan - hanya setelah menyelesaikan tugas sebelumnya. Kemungkinan rollback atau ketidakkonsistenan dalam fase tidak disediakan.

Keuntungan dan kerugian

Dari waktu ke waktu, model air terjun dikritik karena kurangnya fleksibilitas. Banyak yang tidak menyukainya karena tujuan manajemen proyek berlaku di dalamnya, sementara memenuhi tenggat waktu, biaya dan kualitas pembangunan jauh lebih penting.

Namun, jika menyangkut proyek besar, manajemen seringkali lebih penting di dalamnya, karena ini mengurangi risiko proyek dan meningkatkan transparansi dalam pekerjaan.

Terlepas dari kekurangannya, versi PMBOK 3 secara formal hanya menetapkan metodologi "model kaskade". Opsi lain, termasuk manajemen proyek berulang, tidak ditawarkan.

Keuntungan dari model air terjun:

  • Pengembangan tim lebih mudah dikendalikan. Pelanggan mengetahui apa yang sedang dikerjakan oleh programmer, dia dapat mengubah tenggat waktu dan anggaran proyek.
  • Biaya pengembangan disetujui pada tahap pertama. Setelah menyetujui semua tahapan implementasi, produk perangkat lunak ditulis terus menerus.
  • Penguji berpengalaman tidak diperlukan. Untuk tahap pengujian, Anda dapat menggunakan dokumentasi program.

Kekurangan model air terjun:

  • Karena pengujian dimulai pada tahap penyelesaian pengembangan, jika bug ditemukan, biaya untuk memperbaikinya akan lebih mahal daripada tahap awal. Bagaimanapun, penguji akan menemukan kesalahan hanya ketika pengembang telah selesai menulis kode, dan copywriter - dokumentasinya.
  • Pelanggan berkenalan dengan produk jadi setelah pengembangan selesai. Karenanya, dia dapat mengevaluasi produk hanya jika hampir sepenuhnya siap. Jika dia tidak menyukai hasilnya, biaya anggaran proyek akan meningkat tajam karena perlu koreksi.
  • Semakin banyak dokumentasi teknis, semakin lama waktu yang dibutuhkan untuk menyelesaikan pekerjaan. Dokumentasi semacam itu membutuhkan lebih banyak perubahan dan persetujuan.

"Waterfall" sering digunakan dalam proyek-proyek di industri medis dan kedirgantaraan, di mana sudah ada basis dokumen yang luas, yang memungkinkan untuk menyusun persyaratan untuk perangkat lunak baru.

Saat menggunakan model air terjun, hal utama adalah menulis persyaratan terperinci. Selama pengujian, seharusnya tidak ada bug di suatu tempat yang berdampak buruk pada keseluruhan proyek.

Komentar
  • Populer
  • Baru
  • Lama
Anda harus login untuk memberikan komentar
Halaman ini belum memiliki komentar