MODEL SIKLUS HIDUP PERANGKAT LUNAK
2.2 MODEL AIR TERJUN DAN PERLUASANNYA
mengatakan berapa banyak perkembangan telah berkembang. Ketika kriteria masuk dan keluar fase tidak didefinisikan dengan baik, developer mungkin menutup aktivitas fase jauh sebelum mereka benar-benar selesai, memberikan kesan palsu tentang kemajuan pesat.
Dalam hal ini, menjadi sangat sulit bagi manajer proyek untuk menentukan status pasti pengembangan dan melacak kemajuan proyek. Ini biasanya mengarah pada masalah yang biasanya diidentifikasi sebagai sindrom lengkap 99 persen. Sindrom ini muncul ketika manajer proyek perangkat lunak tidak memiliki cara yang pasti untuk menilai kemajuan suatu proyek, anggota tim yang optimis merasa bahwa pekerjaan mereka 99 persen selesai bahkan ketika pekerjaan mereka jauh dari penyelesaian—membuat semua proyeksi yang dibuat oleh proyek. manajer tentang waktu penyelesaian proyek menjadi sangat tidak akurat.
Gambar 2.1 Model air terjun klasik.
Fase model air terjun klasik
Fase yang berbeda dari model air terjun klasik telah ditunjukkan pada Gambar 2.1.
Seperti yang ditunjukkan pada Gambar 2.1, fase yang berbeda adalah—studi kelayakan, analisis dan spesifikasi kebutuhan, desain, pengkodean dan pengujian unit, integrasi dan pengujian sistem, dan pemeliharaan. Fase mulai dari studi kelayakan hingga integrasi dan fase pengujian sistem dikenal sebagai fase pengembangan. Perangkat lunak dikembangkan selama fase pengembangan, dan pada penyelesaian fase pengembangan, perangkat lunak dikirimkan ke pelanggan. Setelah pengiriman perangkat lunak, pelanggan mulai menggunakan perangkat lunak yang menandakan dimulainya fase operasi. Ketika pelanggan mulai menggunakan perangkat lunak, perubahan menjadi perlu karena perbaikan bug dan ekstensi fitur, menyebabkan pekerjaan pemeliharaan harus dilakukan. Oleh karena itu, fase terakhir juga dikenal sebagai fase pemeliharaan siklus hidup.
Perlu diingat bahwa beberapa buku teks memiliki nomor dan nama fase yang berbeda.
Aktivitas yang mencakup semua fase pengembangan perangkat lunak adalah manajemen proyek. Karena mencakup seluruh durasi proyek, tidak ada fase khusus yang dinamai menurut namanya. Manajemen proyek, bagaimanapun, merupakan kegiatan penting dalam siklus hidup dan berhubungan dengan pengelolaan pengembangan perangkat lunak dan kegiatan pemeliharaan. Dalam model air terjun, fase siklus hidup yang berbeda biasanya memerlukan jumlah upaya yang relatif berbeda untuk dilakukan oleh tim pengembangan. Jumlah relatif dari upaya yang dihabiskan pada fase yang berbeda untuk perangkat lunak yang khas telah ditunjukkan pada Gambar 2.2. Perhatikan dari Gambar 2.2 bahwa di antara semua fase siklus hidup, fase pemeliharaan biasanya membutuhkan upaya maksimal. Rata-rata, sekitar 60 persen dari total upaya yang dilakukan oleh tim pengembangan di seluruh siklus hidup dihabiskan untuk kegiatan pemeliharaan saja.
Gambar 2.2 Distribusi usaha relatif di antara berbagai fase produk tipikal.
Namun, di antara fase pengembangan, fase integrasi dan pengujian sistem memerlukan upaya maksimal dalam proyek pengembangan yang khas. Bagian selanjutnya adalah kegiatan yang dilakukan dalam fase yang berbeda dari model air terjun klasik.
Studi kelayakan
Fokus utama dari tahap studi kelayakan adalah untuk menentukan apakah akan layak secara finansial dan teknis untuk mengembangkan perangkat lunak. Studi kelayakan melibatkan pelaksanaan beberapa kegiatan seperti pengumpulan informasi dasar yang berkaitan dengan perangkat lunak seperti item data yang berbeda yang akan dimasukkan ke sistem, pemrosesan yang harus dilakukan pada data ini, data keluaran yang diperlukan untuk diproduksi. oleh sistem, serta berbagai kendala dalam pengembangannya. Data yang dikumpulkan ini dianalisis untuk melakukan hal-hal berikut:
Pengembangan pemahaman masalah secara keseluruhan: Pertama-tama perlu dikembangkan pemahaman menyeluruh tentang apa yang dibutuhkan pelanggan untuk dikembangkan. Untuk ini, hanya persyaratan penting pelanggan yang perlu dipahami dan rincian berbagai persyaratan seperti tata letak layar yang diperlukan dalam antarmuka pengguna grafis (GUI), formula atau algoritma khusus yang diperlukan untuk menghasilkan hasil yang diperlukan, dan basis data skema yang akan digunakan diabaikan.
Perumusan berbagai kemungkinan strategi untuk memecahkan masalah: Dalam kegiatan ini, berbagai kemungkinan skema solusi tingkat tinggi untuk masalah tersebut ditentukan. Misalnya, solusi dalam kerangka klien-server dan kerangka aplikasi mandiri dapat dieksplorasi.
Evaluasi strategi solusi yang berbeda: Skema solusi yang diidentifikasi berbeda dianalisis untuk mengevaluasi manfaat dan kekurangannya. Evaluasi semacam itu seringkali
memerlukan perkiraan perkiraan sumber daya yang dibutuhkan, biaya pengembangan, dan waktu pengembangan yang diperlukan. Solusi yang berbeda dibandingkan berdasarkan estimasi yang telah dikerjakan. Setelah solusi terbaik diidentifikasi, semua kegiatan di fase selanjutnya dilakukan sesuai solusi ini. Pada tahap ini, juga dapat ditentukan bahwa tidak ada solusi yang layak karena biaya tinggi, kendala sumber daya, atau beberapa alasan teknis.
Skenario ini tentu saja mengharuskan proyek tersebut ditinggalkan.
Kita dapat meringkas hasil dari fase studi kelayakan dengan mencatat bahwa selain memutuskan apakah akan mengambil sebuah proyek atau tidak, pada tahap ini keputusan tingkat yang sangat tinggi mengenai strategi solusi didefinisikan. Oleh karena itu, studi kelayakan merupakan tahap yang sangat penting dalam pengembangan perangkat lunak.
Berikut ini adalah studi kasus studi kelayakan yang dilakukan oleh suatu organisasi. Hal ini dimaksudkan untuk memberikan nuansa kegiatan dan isu-isu yang terlibat dalam tahap studi kelayakan proyek perangkat lunak yang khas.
Studi Kasus 2.1
Sebuah perusahaan pertambangan bernama Galaxy Mining Company Ltd. (GMC Ltd.) memiliki tambang yang berlokasi di berbagai tempat di India. Ini memiliki sekitar lima puluh lokasi tambang berbeda yang tersebar di delapan negara bagian. Perusahaan mempekerjakan sejumlah besar penambang di setiap lokasi tambang. Pertambangan sebagai profesi berisiko, perusahaan bermaksud untuk mengoperasikan dana cadangan khusus, yang akan ada di samping dana cadangan standar yang sudah dinikmati para penambang. Tujuan utama dari adanya dana khusus (SPF) adalah untuk segera mendistribusikan sejumlah kompensasi sebelum jumlah PF dibayarkan.
Menurut skema ini, setiap lokasi tambang akan memotong angsuran SPF dari setiap penambang setiap bulan dan menyetorkannya ke komisioner dana khusus pusat (CSPFC).
CSPFC akan menyimpan semua detail mengenai cicilan SPF yang dikumpulkan dari para penambang. GMC Ltd. meminta vendor perangkat lunak terkenal Adventure Software Inc.
untuk melakukan tugas mengembangkan perangkat lunak untuk mengotomatisasi pemeliharaan catatan SPF semua karyawan. GMC Ltd. telah menyadari bahwa selain menghemat tenaga kerja pada pekerjaan pembukuan, perangkat lunak ini akan membantu penyelesaian kasus klaim dengan cepat. GMC Ltd. mengindikasikan bahwa jumlah yang paling bisa ia beli adalah Rp. 1 juta untuk software ini untuk dikembangkan dan diinstal.
Adventure Software Inc. menugaskan manajer proyek mereka untuk melakukan studi kelayakan. Manajer proyek berdiskusi dengan manajer puncak GMC Ltd. untuk mendapatkan gambaran umum proyek. Dia juga berdiskusi dengan petugas PF lapangan di berbagai lokasi tambang untuk menentukan detail pasti dari proyek tersebut. Manajer proyek mengidentifikasi dua pendekatan luas untuk memecahkan masalah. Salah satunya adalah memiliki database pusat yang akan diakses dan diperbarui melalui koneksi satelit ke berbagai lokasi tambang. Pendekatan lainnya adalah memiliki database lokal di setiap lokasi tambang dan memperbarui database pusat secara berkala melalui koneksi dial-up. Pembaruan berkala ini dapat dilakukan setiap hari atau setiap jam tergantung pada penundaan yang dapat diterima oleh GMC Ltd. dalam menjalankan berbagai fungsi perangkat lunak. Dia menemukan bahwa pendekatan kedua sangat terjangkau dan lebih toleran terhadap kesalahan karena lokasi tambang lokal dapat beroperasi bahkan ketika hubungan komunikasi untuk sementara gagal. Dalam pendekatan ini, ketika tautan gagal, hanya pembaruan basis data pusat yang tertunda. Sedangkan pada pendekatan pertama, semua pekerjaan SPF terhenti di situs tambang selama seluruh durasi kegagalan tautan. Manajer proyek dengan cepat menganalisis keseluruhan fungsionalitas basis data yang diperlukan, masalah antarmuka pengguna, dan perangkat lunak yang menangani komunikasi dengan lokasi tambang. Dari analisis ini, ia
memperkirakan perkiraan biaya untuk mengembangkan perangkat lunak. Dia menemukan bahwa solusi yang melibatkan pemeliharaan database lokal di lokasi tambang dan secara berkala memperbarui database pusat layak secara finansial dan teknis. Manajer proyek mendiskusikan solusi ini dengan presiden GMC Ltd., yang menunjukkan bahwa solusi yang diusulkan dapat diterima oleh mereka.
Analisis dan spesifikasi persyaratan
Tujuan dari fase analisis dan spesifikasi kebutuhan adalah untuk memahami kebutuhan yang tepat dari pelanggan dan untuk mendokumentasikannya dengan benar. Fase ini terdiri dari dua aktivitas yang berbeda, yaitu pengumpulan dan analisis kebutuhan, dan spesifikasi kebutuhan. Berikut ini adalah gambaran umum tentang dua kegiatan:
• Pengumpulan dan analisis persyaratan: Tujuan dari aktivitas pengumpulan persyaratan adalah untuk mengumpulkan semua informasi yang relevan mengenai perangkat lunak yang akan dikembangkan dari pelanggan dengan maksud untuk memahami persyaratan dengan jelas. Untuk ini, persyaratan pertama dikumpulkan dari pelanggan dan kemudian persyaratan yang dikumpulkan dianalisis. Tujuan dari aktivitas analisis kebutuhan adalah untuk menghilangkan ketidaklengkapan dan inkonsistensi dalam persyaratan yang dikumpulkan ini. Perhatikan bahwa persyaratan n tidak konsisten adalah persyaratan di mana beberapa bagian dari persyaratan bertentangan dengan beberapa bagian lainnya.
Di sisi lain, persyaratan n tidak lengkap adalah persyaratan di mana beberapa bagian dari persyaratan aktual telah dihilangkan.
• Spesifikasi persyaratan: Setelah pengumpulan persyaratan dan kegiatan analisis selesai, persyaratan yang diidentifikasi didokumentasikan. Ini disebut dokumen spesifikasi persyaratan perangkat lunak (SRS). Dokumen SRS ditulis menggunakan terminologi pengguna akhir. Hal ini membuat dokumen SRS dapat dimengerti oleh pelanggan. Oleh karena itu, pemahaman terhadap dokumen SRS merupakan hal yang penting. Dokumen SRS biasanya berfungsi sebagai kontrak antara tim pengembangan dan pelanggan. Setiap perselisihan di masa depan antara pelanggan dan developer dapat diselesaikan dengan memeriksa dokumen SRS. Oleh karena itu, dokumen SRS merupakan dokumen penting yang harus dipahami secara menyeluruh oleh tim pengembangan, dan ditinjau bersama dengan pelanggan. Dokumen SRS tidak hanya menjadi dasar untuk melakukan semua kegiatan pengembangan, tetapi beberapa dokumen seperti manual pengguna, rencana pengujian sistem, dll disiapkan langsung berdasarkan itu. Dalam Bab 4, kita akan memeriksa aktivitas analisis kebutuhan dan berbagai isu yang terlibat dalam mengembangkan dokumen SRS yang baik secara lebih rinci.
Desain
Tujuan dari fase desain adalah untuk mengubah persyaratan yang ditentukan dalam dokumen SRS menjadi struktur yang cocok untuk implementasi dalam beberapa bahasa pemrograman. Dalam istilah teknis, selama fase desain rancangan roftware berasal dari dokumen SRS. Dua pendekatan desain yang sangat berbeda sedang populer digunakan saat ini—pendekatan desain prosedural dan berorientasi objek.
• Pendekatan desain prosedural: Pendekatan desain tradisional digunakan dalam banyak proyek pengembangan perangkat lunak saat ini. Teknik desain tradisional ini didasarkan pada pendekatan desain berorientasi aliran data. Ini terdiri dari dua kegiatan penting;
analisis terstruktur pertama dari spesifikasi persyaratan dilakukan di mana struktur rinci masalah diperiksa. Ini diikuti oleh langkah desain terstruktur di mana hasil analisis terstruktur ditransformasikan ke dalam desain perangkat lunak.
Selama analisis terstruktur, persyaratan fungsional yang ditentukan dalam dokumen SRS didekomposisi menjadi subfungsi dan aliran data di antara subfungsi ini dianalisis dan
direpresentasikan secara diagram dalam bentuk DFD. Teknik DFD dibahas pada Bab 6.
Desain terstruktur dilakukan setelah aktivitas analisis terstruktur selesai. Desain terstruktur terdiri dari dua aktivitas utama—desain arsitektur (juga disebut desain tingkat tinggi) dan desain detail (juga disebut desain tingkat rendah). Desain tingkat tinggi melibatkan penguraian sistem ke dalam modul, dan mewakili antarmuka dan hubungan doa di antara modul. Desain perangkat lunak tingkat tinggi kadang-kadang disebut sebagai rancangan roftware. Selama aktivitas desain terperinci, internal modul individual seperti struktur data dan algoritma modul dirancang dan didokumentasikan.
• Pendekatan desain berorientasi objek: Dalam teknik ini, berbagai objek yang terjadi di domain masalah dan domain solusi pertama kali diidentifikasi dan hubungan berbeda yang ada di antara objek-objek ini diidentifikasi. Struktur objek lebih disempurnakan untuk mendapatkan desain detail. Pendekatan OOD dikreditkan memiliki beberapa manfaat seperti waktu dan upaya pengembangan yang lebih rendah, dan pemeliharaan perangkat lunak yang lebih baik. Teknik desain berorientasi objek dibahas dalam Bab 7 dan 8.
Tujuan dari fase pengkodean dan pengujian unit adalah untuk menerjemahkan desain perangkat lunak ke dalam kode sumber dan untuk memastikan bahwa masing-masing fungsi bekerja dengan benar. Fase pengkodean juga kadang-kadang disebut fase implementasi, karena desain diimplementasikan ke dalam solusi yang bisa diterapkan dalam fase ini. Setiap komponen desain diimplementasikan sebagai modul program.
Produk akhir dari fase ini adalah satu set modul program yang telah diuji unit secara individual. Tujuan utama dari pengujian unit adalah untuk menentukan kerja yang benar dari masing-masing modul. Kegiatan khusus yang dilakukan selama pengujian unit termasuk merancang kasus uji, pengujian, debugging untuk memperbaiki masalah, dan pengelolaan kasus uji. Kita akan membahas teknik pengkodean dan pengujian unit di Bab 10.
Integrasi dan pengujian sistem Integrasi modul yang berbeda dilakukan segera setelah mereka dikodekan dan diuji unit. Selama fase integrasi dan pengujian sistem, modul yang berbeda diintegrasikan secara terencana. Berbagai modul yang menyusun perangkat lunak hampir tidak pernah terintegrasi dalam satu bidikan (dapatkah Anda menebak alasannya?). Integrasi berbagai modul biasanya dilakukan secara bertahap melalui beberapa langkah. Selama setiap langkah integrasi, modul yang direncanakan sebelumnya ditambahkan ke sistem yang terintegrasi sebagian dan sistem yang dihasilkan diuji. Akhirnya, setelah semua modul berhasil diintegrasikan dan diuji, sistem kerja penuh diperoleh. Pengujian sistem dilakukan pada sistem yang berfungsi penuh ini. Pengujian integrasi dilakukan untuk memverifikasi bahwa antarmuka di antara unit yang berbeda bekerja dengan memuaskan. Di sisi lain, tujuan pengujian sistem adalah untuk memastikan bahwa sistem yang dikembangkan sesuai dengan persyaratan yang telah ditetapkan dalam dokumen SRS.
Pengujian sistem biasanya terdiri dari tiga jenis aktivitas pengujian yang berbeda:
• Developer-testing: Ini adalah pengujian sistem yang dilakukan oleh tim pengembang.
• customer-testing: Ini adalah pengujian sistem yang dilakukan oleh sekelompok pelanggan yang ramah.
• Pengujian penerimaan: Setelah perangkat lunak dikirimkan, pelanggan melakukan pengujian sistem untuk menentukan apakah akan menerima perangkat lunak yang dikirimkan atau menolaknya.
Kita membahas berbagai integrasi dan teknik pengujian sistem secara lebih rinci di Bab 10.
Pemeliharaan
Upaya total yang dihabiskan untuk pemeliharaan perangkat lunak biasa selama fase operasinya jauh lebih banyak daripada yang diperlukan untuk mengembangkan perangkat lunak itu sendiri. Banyak penelitian yang dilakukan di masa lalu mengkonfirmasi hal ini dan menunjukkan bahwa rasio upaya relatif untuk mengembangkan produk perangkat lunak yang khas dan total upaya yang dihabiskan untuk pemeliharaannya kira-kira 40:60.
Pemeliharaan diperlukan dalam tiga jenis situasi berikut:
• Pemeliharaan korektif: Jenis pemeliharaan ini dilakukan untuk memperbaiki kesalahan yang tidak ditemukan selama fase pengembangan produk.
• Perawatan sempurna: Jenis perawatan ini dilakukan untuk meningkatkan kinerja sistem, atau untuk meningkatkan fungsionalitas sistem berdasarkan permintaan pelanggan.
• Pemeliharaan adaptif: Pemeliharaan adaptif biasanya diperlukan untuk mem-porting perangkat lunak agar berfungsi di lingkungan baru. Misalnya, porting mungkin diperlukan agar perangkat lunak dapat bekerja pada platform komputer baru atau dengan sistem operasi baru.
Kekurangan model air terjun klasik
Model air terjun klasik adalah model yang sangat sederhana dan intuitif. Namun, ia menderita beberapa kekurangan. Mari kita identifikasi beberapa kekurangan penting dari model air terjun klasik:
Tidak ada jalur umpan balik: Dalam model air terjun klasik, evolusi perangkat lunak dari satu fase ke fase berikutnya dianalogikan dengan air terjun. Sama seperti air di air terjun setelah mengalir ke bawah tidak dapat mengalir kembali, setelah fase selesai, aktivitas yang dilakukan di dalamnya dan semua artefak yang dihasilkan dalam fase ini dianggap final dan ditutup untuk pengerjaan ulang. Ini mengharuskan semua aktivitas selama fase dilakukan dengan sempurna.
Model air terjun klasik adalah idealis dalam arti mengasumsikan bahwa tidak ada kesalahan yang pernah dilakukan oleh developer selama salah satu fase siklus hidup, dan oleh karena itu, tidak memasukkan mekanisme untuk koreksi kesalahan. Berlawanan dengan asumsi mendasar yang dibuat oleh model air terjun klasik, dalam lingkungan pengembangan praktis, developer melakukan banyak kesalahan di hampir setiap aktivitas yang mereka lakukan selama berbagai fase siklus hidup. Bagaimanapun, programmer adalah manusia dan seperti pepatah lama mengatakan untuk berbuat salah adalah manusiawi. Penyebab kesalahan bisa banyak—pengawasan, interpretasi yang salah, penggunaan skema solusi yang salah, kesenjangan komunikasi, dll. Cacat ini biasanya terdeteksi jauh di kemudian hari dalam siklus hidup. Misalnya, cacat desain mungkin tidak diketahui sampai tahap pengkodean atau pengujian. Setelah cacat terdeteksi di lain waktu, developer perlu mengulang beberapa pekerjaan yang dilakukan selama fase itu dan juga mengulang pekerjaan fase selanjutnya yang terpengaruh oleh pengerjaan ulang. Oleh karena itu, dalam setiap proyek pengembangan perangkat lunak non-sepele, menjadi hampir tidak mungkin untuk secara ketat mengikuti model pengembangan perangkat lunak air terjun klasik.
Sulit untuk mengakomodasi permintaan perubahan: Model ini mengasumsikan bahwa semua persyaratan pelanggan dapat didefinisikan secara lengkap dan benar di awal proyek. Ada banyak penekanan pada pembuatan serangkaian persyaratan yang jelas dan lengkap. Namun, sulit untuk mencapai ini bahkan dalam skenario proyek yang ideal.
Persyaratan pelanggan biasanya terus berubah seiring waktu. Namun, dalam model ini menjadi sulit untuk mengakomodasi permintaan perubahan kebutuhan yang dibuat oleh pelanggan setelah fase spesifikasi persyaratan selesai, dan ini sering menjadi sumber ketidakpuasan pelanggan.
Koreksi kesalahan yang tidak efisien: Model ini menunda integrasi kode dan tugas pengujian sampai sangat terlambat ketika masalah lebih sulit untuk diselesaikan.
Tidak ada fase yang tumpang tindih: Model ini merekomendasikan agar fase dilakukan secara berurutan—fase baru dapat dimulai hanya setelah fase sebelumnya selesai. Namun, jarang mungkin untuk mematuhi rekomendasi ini dan itu menyebabkan sejumlah besar anggota tim menganggur untuk waktu yang lama. Misalnya, untuk pemanfaatan tenaga kerja yang efisien, tim pengujian mungkin perlu merancang kasus uji sistem segera setelah spesifikasi persyaratan selesai. (Kita akan membahas dalam Bab 10 bahwa kasus uji sistem dirancang hanya berdasarkan dokumen SRS). Dalam hal ini, kegiatan fase desain dan pengujian tumpang tindih. Akibatnya, aman untuk mengatakan bahwa dalam skenario pengembangan perangkat lunak praktis, daripada memiliki titik waktu yang tepat di mana transisi fase terjadi, fase yang berbeda perlu tumpang tindih untuk alasan biaya dan efisiensi.
Apakah model air terjun klasik berguna?
Sulit untuk menggunakan model air terjun klasik dalam proyek nyata. Dalam lingkungan pengembangan praktis apa pun, saat perangkat lunak mulai terbentuk, beberapa iterasi melalui tahapan air terjun yang berbeda menjadi perlu untuk koreksi kesalahan yang dilakukan selama berbagai fase. Oleh karena itu, model air terjun klasik hampir tidak dapat digunakan untuk pengembangan perangkat lunak. Tapi, seperti yang disarankan oleh Parnas [1972] dokumen akhir untuk produk harus ditulis seolah-olah produk dikembangkan menggunakan air terjun klasik murni. Terlepas dari model siklus hidup yang sebenarnya diikuti untuk pengembangan produk, dokumen akhir selalu ditulis untuk mencerminkan model pengembangan air terjun klasik, sehingga pemahaman dokumen menjadi lebih mudah bagi siapa pun yang membaca dokumen.
Alasan di balik penyusunan dokumen berdasarkan model air terjun klasik dapat dijelaskan dengan menggunakan metafora Hoare tentang teorema matematika [1994]
membuktikan — Seorang ahli matematika menyajikan bukti sebagai satu rantai deduksi, meskipun buktinya mungkin berasal dari satu set berbelit-belit upaya parsial, jalan buntu dan mundur. Bayangkan betapa sulitnya untuk memahami, jika seorang ahli matematika menyajikan bukti dengan mempertahankan semua backtracking, koreksi kesalahan, dan perbaikan solusi yang dia buat saat mengerjakan bukti.
Gambar 2.3 Model air terjun iteratif.
Model Air Terjun Berulang
Dibagian sebelumnya saya sudah menunjukkan bahwa proyek pengembangan perangkat lunak praktis, model air terjun klasik sulit digunakan. Model air terjun klasik sebagai model idealis. Dalam konteks ini, model air terjun berulang dapat dianggap menggabungkan perubahan yang diperlukan pada model air terjun klasik agar dapat digunakan dalam proyek pengembangan perangkat lunak praktis. Perubahan utama yang dibawa oleh model air terjun iteratif ke model air terjun klasik adalah dalam bentuk memberikan jalur umpan balik dari setiap fase ke fase sebelumnya.
Jalur umpan balik yang diperkenalkan oleh model air terjun berulang ditunjukkan pada Gambar 2.3. Jalur umpan balik memungkinkan untuk mengoreksi kesalahan yang dilakukan oleh programmer selama beberapa fase, ketika dan ketika ini terdeteksi di fase selanjutnya.
Misalnya, jika selama fase pengujian kesalahan desain diidentifikasi, maka jalur umpan balik memungkinkan desain untuk dikerjakan ulang dan perubahan tersebut tercermin dalam dokumen desain dan semua dokumen berikutnya lainnya. Harap perhatikan bahwa pada Gambar 2.3 tidak ada jalur umpan balik ke tahap kelayakan. Hal ini karena setelah sebuah tim menerima untuk mengambil sebuah proyek, tidak mudah menyerah proyek karena alasan hukum dan moral. Hampir setiap model siklus hidup yang kita bahas bersifat iteratif, kecuali model air terjun klasik dan model V—yang sifatnya sekuensial. Dalam model sekuensial, setelah fase selesai, tidak ada produk kerja dari fase itu yang diubah kemudian.
Fase penahanan kesalahan
Tidak peduli seberapa berhati-hatinya seorang programmer, dia mungkin akan melakukan beberapa kesalahan atau lainnya saat melakukan aktivitas siklus hidup. Kesalahan ini mengakibatkan kesalahan (juga disebut kesalahan atau bug) dalam produk kerja. Adalah menguntungkan untuk mendeteksi kesalahan ini dalam fase yang sama di mana mereka terjadi, karena deteksi dini bug mengurangi upaya dan waktu yang diperlukan untuk