Model Siklus Hidup Software
2.1 Pengembangan Software dalam teorinya
Dalam kenyataannya, pengembangan software dimulai dari titik awal. Analisa diperlukan untuk memenuhi kebutuhan spesifikasi client yang diinginkan dan dengan standar yang dibutuhkan. Masalah yang dihadapi banyak dari masalah pengembangan dari titik awal dan dalam proses pembuatannya hingga proses yang hampir selesai, tetapi kebutuhan client dapat berubah ubah sewaktu waktu yang menjadikan perubahan tujuan pengembangan pembuatan software. Saat kebutuhan client sudah terpenuhi, software tersebut baru akan di terapkan di komputer client.
Skema dalam pengembangan software
Gambar 2.1 Pemikiran pengembangan software.
Namun, dalam pengembangan software jauh berbeda dengan praktiknya dikarenakan dua hal. Hal tersebut yaitu yang pertama dikarenakan ahli pemrogram juga merupakan manusia yang sering terdapat kesalahan dalam prosesnya. Masalah kedua terdapat pada keinginan dari client yang dapat berubah sewaktu waktu. Kedua masalah ini dibahas secara mendalam, akan dibahas dalam ilustrasi studi kasus yang ada sebagai berikut.
2.2 Studi Kasus Kecil di Winburg
Tujuan dari studi kasus ini untuk mengurangi kemacetan pada lalu lintas pada pusat kota Winburg, Indiana. Dengan konsep dari wali kota yaitu dengan menyediakan transportasi bus dengan tarif 1 dolar per perjalanan. Agar para penumpang mau menggunakannya, kendaraan akan diparkirkan di pinggiran kota dan melanjutkan perjalanan dengan bus. Masalah yang ada adalah scanner uang yang harus akurat untuk mendeteksi uang asli dengan waktu yang singkat. Jika lama, pengguna akan sedikit, Jika dapat menggunakan uang palsu, dapat mengurangi pendapatan. Masalah ini memerlukan scanner dan algoritma yang bagus dan benar.
Mulai dari awal
Kebutuhan
Analisa
Desain Kebutuhan
Gambar 2.2 Diagram pohon pengembangan model soklus hidup Studi kasus mini di Winburg.
Saat pengembangan yang pertama masih terdapat kesalahan saat melakukan pengembangan softwarenya.
Pengembangan berikutnya terdapat masalah terhadap waktu yang terjadi yaitu mencapai 10 detik untuk mendapatkan hasil respon. Setelah diketahui penyebabnya, manajer meminta programer untuk menggunakan 2 presisi matematis supaya dapat lebih berkembang.
Setelah itu pengembangan yang masih belum memenuhi target yaitu 1 detik belum tercapai, sehingga ditetapkan menggunakan Algoritma pengembangan Algoritma cepat kompleks terbaru, sehingga dapat tercapai target waktunya.
Wali kota yang sebagai pengusaha cerdik, mengupayakan dapat memproduksi lebih mesin uang ini untuk dapat menutup biaya dan dapat mengembangkan dalam versi perangkat lunak dalam versi produknya.
Perangkat keras semakin lama akan semakin tertinggal dan harus diupgrade dan dikembangkan lagi dengan tujuan untuk mengambil keuntungan. Mereka merencanakan reimplementasi perangkat lunak dengan bahasa pemrograman yang berbeda. Terdapat masalah seperti keterlambatan waktu selama 6 bulan dan kekurangan biaya 25%. Tujuan dari pengembangan ini supaya terdapat kelebihan dalam kualitas dan terdapat perbedaan walau dalam hal yang kecil.
Gambar 3. Water Fall
yang ditemukan selama desain yang disebabkan oleh kesalahan dalam persyaratan, maka akan menggunakan panah menuju ke atas, pengembang perangkat lunak dapat mundur dari desain hingga analisis dan karenanya dengan persyaratan dan membuat koreksi yang diperlukan di sana. Kemudian, mereka pindah ke analisa, diperlukan perbaikan sehingga sesuai dengan spesifikasinya, dan pada gilirannya, memperbaiki dokumen desain. Desain kegiatan sekarang dapat melanjutkan di mana mereka dihentikan saat kesalahan ditemukan. Keterangannya, tanda panah yang tersambung (tidak putus-putus) menunjukkan pembangunan. Tanda panah putus-putus menunjukkan pemeliharaan.
Model Water Fall tentu dapat digunakan untuk mewakili studi kasus kecil Winburg, tapi, tidak seperti model pohon Gambar 2.2, tidak dapat menunjukkan urutan peristiwa. Model evolusi-pohon memiliki keuntungan lebih jauh atas model Water Fall. Pada akhirnya setiap episode kita memiliki dasar, yaitu, satu set lengkap artefak (ingat bahwa artifactis komponen penyusun produk software). Ada empat baseline pada Gambar 2.2. mereka
Pada akhir Episode 1: Persyaratan, Analisis, Desain, Implementasi
Pada akhir Episode 2: Persyaratan, Analisis, Desain, Implementasi
Pada akhir Episode 3: Persyaratan, Analisis, Desain, Implementasi
Pada akhir Episode 4: Persyaratan, Analisis, Desain, Implementasi
Keadaan awal (Base awal) adalah pengimplementasi awal; keadaan kedua merupakan perngubahan yang tidak terselesaikan dari Implementasi dari Episode 2, bersama-sama dengan tidak berubahnya persyaratan, analisis, dan desain dari Episode 1 Baseline. Ketiga adalah sama dengan dasar pertama, tetapi dengan desain dan implementasi berubah. Baseline keempat adalah kerangka lengkap yang baru, ditunjukkan pada Gambar 2.2.
2.3 Lessons of the Winburg Mini Case Study
Studi kasus mini Winburg menggambarkan perkembangan produk perangkat lunak yang berjalan serba salah untuk sejumlah penyebab tidak terkait, seperti strategi implementasi miskin (tidak perlu menggunakan nomor presisi ganda) dan keputusan untuk menggunakan algoritma yang terlalu lambat. Pada akhirnya, proyek ini sukses. Namun, pertanyaan yang jelas adalah, adalah pengembangan perangkat lunak benar-benar kacau dalam praktek? Pada kenyataannya, studi kasus mini jauh kurang traumatis daripada banyak, jika tidak sebagian besar, proyek perangkat lunak. Dalam studi kasus mini Winburg, ada hanya dua versi baru dari perangkat lunak karena kesalahan (penggunaan yang tidak tepat menggunakan nomor presisi ganda ; pemanfaatan algoritma yang tidak bisa memenuhi persyaratan waktu respon), dan hanya satu versi baru karena perubahan yang dibuat oleh klien (kebutuhan untuk meningkatkan ketepatan).
Mengapa ada perubahan begitu banyak produk perangkat lunak yang diperlukan?
Pertama, seperti yang dinyatakan sebelumnya, profesional software manusia dan karena itu membuat kesalahan. Kedua, adalah produk perangkat lunak model dunia nyata, dan dunia nyata terus-menerus berubah. Hal ini dibahas panjang lebar dalam bagian 2.4.
2.4 Teal Tractors Mini Case Study
Teal traktor, Inc, Perusahaan yang menjual traktor di sebagian besar wilayah di Amerika Serikat. Perusahaan telah meminta Divisi perangkat lunak untuk mengembangkan produk baru yang dapat menangani seluruh aspek bisnisnya. Misalnya, produk harus mampu menangani penjualan, persediaan, dan Komisi dibayar untuk staf penjualan, serta menyediakan semua fungsi akuntansi yang diperlukan. Sementara produk perangkat lunak ini sedang dilaksanakan, traktor Teal membeli sebuah perusahaan traktor Kanada. Pengelolaan Teal traktor memutuskan bahwa, untuk menghemat uang, operasi Kanada adalah akan diintegrasikan ke dalam operasi AS. Itu berarti bahwa perangkat lunak harus berubah sebelum selesai:
2. ini harus diperluas untuk menangani aspek-aspek dari bisnis yang berbeda ditangani di Kanada, seperti pajak.
3. ini harus diperluas untuk menangani dua mata uang yang berbeda, dolar AS dan dollar Kanada.
Teal traktor adalah perusahaan yang berkembang pesat dengan prospek masa depan yang sangat baik. Pengambil alihan perusahaan traktor Kanada adalah perkembangan positif, yang dapat juga mengakibatkan bahkan lebih besar profits di masa depan. Tapi, dari sudut pandang Divisi perangkat lunak, pembelian perusahaan Kanada bisa menjadi bencana. Kecuali persyaratan, analisis, dan desain telah dilakukan dengan tujuan untuk menggabungkan ekstensi masa depan, pekerjaan yang terlibat dalam menambahkan wilayah penjualan Kanada mungkin begitu besar, mungkin hal itu lebih efektif untuk membuang segala sesuatu yang dilakukan mulai dari awal. Alasannya adalah bahwa mengubah produk pada tahap ini serupa dengan mencoba untuk memperbaiki produk perangkat lunak di akhir siklus kehidupan (Lihat gambar 1,6). Memperluas perangkat lunak untuk menangani aspek untuk pasar Kanada, serta Penukaran Valuta Kanada, mungkin akan sama sulit.
Bahkan jika perangkat lunak telah dipikirkan dengan baik dan desain asli memang extensible, desain produk tambalan bersama-sama yang dihasilkan tidak dapat kohesif seperti jika itu telah dikembangkan dari awal untuk melayani Amerika Serikat dan Kanada. Ini dapat memperparah implikasi bagi pemeliharaan masa depan.
Divisi software Teal traktor adalah korban dari masalah target bergerak. Itu adalah, sementara perangkat lunak sedang dikembangkan, persyaratan berubah. Tidak peduli bahwa alasan perubahan sebaliknya sangat berharga. Faktanya adalah bahwa pengambil alihan perusahaan Kanada juga bisa merusak kualitas perangkat lunak yang sedang dikembangkan.
Dalam beberapa kasus, alasan untuk target bergerak tidak berbahaya. terkadang manajer senior kuat dalam sebuah organisasi terus mengubah pikirannya mengenai fungsi produk perangkat lunak yang dikembangkan. Dalam kasus lain, ada fitur creep, suksesi dari kecil, hampir sepele, penambahan persyaratan. Tapi apa pun alasannya mungkin, perubahan sering, tidak peduli seberapa kecil mereka mungkin tampak, berbahaya bagi kesehatan produk perangkat lunak. Penting bahwa produk perangkat lunak yang dirancang sebagai satu set komponen yang sebagai independen mungkin, sehingga perubahan ke salah satu bagian dari perangkat lunak tidak menyebabkan kesalahan di bagian yang tampaknya tidak terkait dalam kode, kesalahan disebut regresi. Ketika berbagai perubahan yang dibuat, efeknya adalah untuk menginduksi dependensi dalam kode. Akhirnya, ada begitu banyak dependensi bahwa hampir setiap perubahan menginduksi satu atau lebih regresi kesalahan. Pada waktu itu, satu-satunya hal yang dapat dilakukan adalah untuk merancang produk perangkat lunak seluruh dan reimplement itu.
Sayangnya, belum ada solusi untuk masalah target bergerak. Berkaitan dengan perubahan positif persyaratan, perusahaan berkembang selalu akan berubah, dan perubahan ini harus reflected dalam misi-kritis software produk perusahaan. Untuk perubahan negatif, jika individu panggilan untuk perubahan tersebut memiliki pengaruh yang cukup, tidak ada yang dapat dilakukan untuk mencegah perubahan yang sedang dilaksanakan, lebih lanjut akan merugikan produk perangkat lunak.
2.5 Pengulangan dan Peningkatan
Model perangkat lunak sebenarnya menyerupai model evolusi pohon dan juga air terjun. Pertimbangan dari perkrmbangan versi-versi ini pada dasarnya beulang. Artinya dari hsil revisi versi pertama menghasilkan versi kedua dan seterusnya. Iterasi merupakan aspek intrinsik rekayasa perangkat lunak, dan model siklus hidup berulang telah digunakan selama lebih dari 30 tahun [Larman dan Basili, 2003].
lebih banyak dari tujuh persyaratan. salah satu cara kita manusia menangani pembatasan ini pada jumlah informasi yang kami dapat menangani salah satu waktu adalah dengan menggunakan bertahap refi nement. Artinya, kita berkonsentrasi pada aspek-aspek yang saat ini yang paling penting dan menunda sampai nanti aspek-aspek yang saat ini kurang kritis. Pertimbangan aspek lebih lanjut dari masalah dan menambahkan dihasilkan tersebut potongan baru untuk artefak yang ada. Sebagai contoh, kita mungkin membangun dokumen persyaratan dengan mempertimbangkan tujuh persyaratan yang kami anggap paling penting. Kemudian, kan mempertimbangkan tujuh persyaratan yang paling penting berikutnya, dan seterusnya. Ini adalah proses yang bertahap. Incrementation juga merupakan aspek intrinsik rekayasa perangkat lunak; software tambahan pembangunan adalah lebih dari 45 tahun [Larman dan Basili, 2003].
Pada awal siklus hidup, pengembang perangkat lunak mengekstrak awal mengatur persyaratan. Dengan kata lain, pada awal kehidupan berulang dan ambahan siklus, persyaratannya bersifat lebih dominan. Persyaratan ini artefak diperluas dan modifi ed selama sisa siklus hidup. Selama waktu itu, empat lainnya mengalir workfl (analisis, desain, implementasi, dan uji) mendominasi. Dengan kata lain, persyaratan workfl ow adalah workfl utama ow pada awal siklus hidup, namun relatif pentingnya menurun setelahnya. Sebaliknya, pelaksanaan dan uji workfl mengalir menempati lebih dari saat anggota tim pengembangan perangkat lunak terhadap akhir siklus hidup daripada yang mereka lakukan di awal.
Kegiatan perencanaan dan dokumentasi dilakukan di seluruh berulang-andincremental siklus hidup. Selain itu, pengujian adalah aktivitas utama selama setiap iterasi, dan terutama pada akhir setiap iterasi. Selain itu, perangkat lunak secara keseluruhan adalah benar-benar diuji setelah telah selesai; pada waktu itu, pengujian dan kemudian memodifikasi pelaksanaan dalam terang hasil dari berbagai tes hampir satu-satunya aktivitas tim software.
2.6 Peninjauan Ulang Studi Kasus Winburg
Evolusi-model pohon siklus hidup untuk studi kasus Mini Winburg (Gambar 2.2) ditumpangkan pada
model siklus hidup berulang-dan-tambahan.
Dari sudut pandang model berulang-dan-tambahan, dua dari kenaikan tidak mencakup semua empat mengalir workfl. Model tidak mengharuskan setiap workfl ow dilakukan pada setiap kenaikan.
keseluruhan, sebuah contoh pemeliharaan perfektif. sesuai perubahan tersebut kemudian dibuat untuk analisis aliran workfl, desain workfl ow, dan implementasi workfl ow.
2.7 Risiko dan Aspek lain dari Iterasi dan incrementation
Untuk melihat iterasi dan incrementation adalah proyek secara keseluruhan ,dibagi menjadi proyek Mini lebih kecil (atau increment). Setiap proyek Mini memperluas persyaratan, analisis, desain, implementasi, dan pengujian artefak. Akhirnya, yang dihasilkan set artefak merupakan produk perangkat lunak yang lengkap. Bahkan, setiap proyek Mini terdiri dari lebih dari sekedar memperluas artefak. Hal ini penting untuk memeriksa bahwa setiap artefak yang benar dan membuat perubahan yang diperlukan dengan artefak yang relevan. Proses pemeriksaan dan memodifikasi, kemudian mengecek kembali dan remodifying, dan sebagainya, jelas berulang di alam. Ini berlanjut sampai anggotatim pengembangan ed satisfi dengan semua artefak dari proyek Mini saat ini (atau kenaikan). Ketika itu terjadi, mereka melanjutkan ke kenaikan berikutnya.
Model iteratif-dan-tambahan memiliki banyak kekuatan yaitu :
1. Beberapa peluang yang ditawarkan untuk memeriksa bahwa produk perangkat lunak benar. Setiap iterasi menggabungkan tes work flow, sehingga setiap iterasi adalah kesempatan lain untuk periksa semua artefak yang dikembangkan sampai saat ini.
2 Ketahanan arsitektur yang mendasari dapat ditentukan relatif awal siklus hidup. Arsitektur produk perangkat lunak meliputi berbagai komponen artefak dan bagaimana mereka cocok bersama.
3 Model iteratif-dan-tambahan memungkinkan kita untuk mengurangi risiko awal. Risiko yang selalu terlibat dalam pengembangan perangkat lunak dan pemeliharaan.
4. Produk ini selalu memiliki versi kerja perangkat lunak. Misalkan produk software dikembangkan
menggunakan model siklus hidup klasik . Hanya di akhir dari proyek ini adalah ada versi kerja produk perangkat lunak.
5. Ada bukti empiris bahwa siklus hidup berulang ulang dan-tambahan bekerja. bagan Gambar 1.1 menunjukkan hasil laporan dari Standish Group pada proyek-proyek selesai pada tahun 2006 [Rubenstein, 2007]. Bahkan, laporan ini (yang disebut CHAOS diproduksi setiap 2 tahun. Gambar menunjukkan hasil untuk tahun 1994 sampai 2006 Persentase produk yang sukses meningkat terus dari 16 persen pada tahun 1994 menjadi 34 persen pada tahun 2002, tetapi kemudian menurun menjadi 29 persen pada 2004 Dalam kedua 2002 [Softwaremag.com, 2004] dan 2004 [Hayes, 2004] laporan, salah satu faktor yang terkait dengan proyek yang berhasil adalah penggunaan proses berulang-ulang.
sekilas pertama, model berulang-dan-tambahan terlihat benar-benar kacau. Alih-alih perkembangan tertib dari persyaratan untuk pelaksanaan air terjun nampak bahwa pengembang melakukan apapun yang mereka suka, . Sebaliknya, model berulang-dan-tambahan adalah sebagai perintah sebagai waterfall , karena seperti sebelumnya menunjukkan, pengembangan perangkat lunak produk dengan menggunakan model interaktif dan tambahan tidak lebih atau kurang dari mengembangkan serangkaian produk perangkat lunak yang lebih kecil, semua menggunakan model waterfall.Secara lebih rinci, mengembangkan produk perangkat lunak menggunakan model waterfall berarti berturut-turut melakukan persyaratan, analisis, desain, dan tahapan pelaksanaan (dalam urutan itu) pada produk perangkat lunak secara keseluruhan. Jika masalah ditemui, loop (panah putus-putus) yang diikuti yaitu, iterasi (maintenance) dilakukan. Namun, jika produk perangkat lunak yang sama dikembangkan menggunakan model interaktif-dan-tambahan, produk perangkat lunak diperlakukan sebagai set bertahap. Untuk setiap kenaikan pada gilirannya, persyaratan, analisis, desain, dan tahapan pelaksanaan (dalam urutan itu) berulang kali dilakukan pada kenaikan itu sampaijelas bahwa tidak ada iterasi lebih lanjut diperlukan. Dengan kata lain, proyek secara keseluruhan adalah dipecah menjadi serangkaian proyek air terjun mini. Selama setiap proyek mini iterasi adalah dilakukan sesuai kebutuhan. Oleh karena itu, alasan paragraf sebelumnya menyatakan bahwa model berulang-dan-tambahan adalah sebagai ketat sebagai air terjun Model karena model berulang-dan-tambahan adalah model air terjun, diterapkan berturut-turut.
2.9 Model Siklus Hidup Yang Lain
Sekilas,model pengembangan software secara berulang dan bertambah terlihat tidak teratur. namun ini bukanlah suatu permasalahan, sebaliknya, model pengembangan iterative-and-incremental sama teraturnya dengan model pengembangan waterfall, karena seperti sudab dijelaskan, mengembangkan software dengan model berulang dan bertambah adalah seperti mengembangkan serangkaian produk prodyk software yang lebih kecil, yg keseluruhannya menggunakab model waterfall
Secara terperinci, mengembangkab software dengan model waterfall berarti berhasil melakukan fase kebutuhan,analisa,desain dan inplementasi (secara urut) pada produk software secara keseluruhan. namun, apabila produk software yang sama dikembngkan dengab model iterative-and-incremental, maa produk software diperlakukan sebagai kumpulan bagian yang bertambah. Untum setiap tahap pertambahan, fase kebutuhan,analisa,desain, dan inplementasi dilakukan secara berulang pad tahap itu sampai dirasa bahwa proses perulangan sudah tidak dibutuhkan lagi. Dalam setiap mini project, perulanganbdilakukan secukupnya. jadi proses pengembangan software secara iterative-and-incremental dianggap sama teraturnha dengan modl waterfall karena model ini sendiri adlah model waterfall yang berhasil dilaksanakan.
Model siklus hidup lain
1. Model siklus code-and-fix
Sayangnya, banyak sekali produk yang dikembangkan menggunakan model ini dima a produk diimolementasikan tanpa kebutuhan atau spesifikasi, atau usaha daam mendesain. sebaliknya pengembang menulis keseluruhan code dan merevisinya bdrulang kali sampai kloen mersa puas. walaupun model ini mungkin efektif untuk program yabg hanya mmiliki 100-200 baris kode, model ini sebenarnya benar benar tidak meenghasilkan produk yang memuaskan. biaya untuk model ini lebih besar dari model yang lebih teratur. seain itu proses pemeliharaan produk akan sngat sulit tanpa dikumen desain atau spesifikasi sert kemungkinan kesalahn regresif menjadi lebih besar.
masalah ini biasanya terjadi oada organisasi yang melihat kemajuan dari jumlah baris code sehingga para anggota tim pengembang mendapatkan tekanan untuk menulis kode sebanyak mungkin dimulai daru hari pertama. mode ini adlah paling mudh, nmub yg paling buruk.
2. Model siklus waterfall
model waterfall memiliki banyak kelebihan termasuk pendekatan yang harus terartur. Namun kenyataan bahwa midel ini terpaku pada dokumentasi juga bisa menjadi kelemahan yang disebabkan perbedaan pemahaman antara pengembang dan klien. maka perlu diperjelas bahwa hanya arsitek yang dapat membantu klien memahami apa yang akan dibuat. Masalahnya terkadang penjelasan arsitek tidak menjelaskan bagaiman produk dapat bekerja. solusinya adalah model rapid-prototyping.
3. model rapid-prototyping
Adalah model yang secara fungsional sama dengan bagian pada produk. tahap pertama pada model ini adalah dengan membuat prototype singkat dan membiarkan klien untuk berinteraksi dan bereksperimen dengan prototype itu. setelah klien puas maka pengembang dapat menulis dokumen spesifikasi yang diinginkan klien.
kelebihan dari model ini adalah pengembangan produk benar benar linear. proses perulangan umpan balik tidak terlalu dibutuhkan. Selanjutnya adalah proses implementasi. karena versi awal sudah dibuat maka proses perbaikan tidak terlalu dibutuhkan . setelah produk diterima klien maka pemeliharaan pasca pengiriman dimulai. aspek paling penting pada model ini adalah kecpeatan. struktur internal dari rapid prototype tidaklah penting, yang penting adalah prototype dibuat dan dimodifikasi secara cepat sesuai keinginan klien.
4.Model open-source
Mempunyai kelebihan dapat berjalan dengan baik di instansi kecil, dan mempunyai kelemahan pengaplikasian yang terbatas sering tidak dapat berjalan
5. Agile Processes
Kelebihannya adalah dapat bekerja dengan baik saat persyaratan client tidak jelas dan kelemahannya adalah hanya dapat bekerja dalam skala projek yang kecil .
6. Synchronize-and-stabilize life - cycle model
Kelebihannya yaitu pengguna berikutnya dapat menemukan kecocokan dengan komponen tersebut, sedangkan kelemahannya yaitu tidak dapat bekerja lebih besar dari microsoft
7. Spiral life-cycle model
Kelebihan, resiko berbasis. Kelemahan, hanya dapat digunakan di produk scala besar dalam produk rumahan dan pengembang harus berkompetent dalam analisa resiko dan resolusi resiko.
2.10 Perbandingan dari model life cycle
Sembilan software life-cycle yang berbeda sudah diperiksa dan diketahui kelebihan dan kekurangannya. Model code-and-fix harus dihindari. Model waterfall kuantitasnya tidak diragukan, kekuatannya dapat diketahui brgitu pula kelemahannya. Model rapid-prototyping dikembangakn atas kelemahan waterfall model. Tetapi tidak ada cukup bukti bahwa model ini lebih superior daripada model waterfall. Model lifecycle open-source sangat sukses di beberapa kasus ketika digunakan untuk mengkonstruksi infrastruktur software. Proses agile adalah sebuah set pendekatan contoversial baru yang sejauh ini terlihat berhasil, tetapi hanya untuk software berskala kecil. Model synchronize-and-stabilize sudah digunakan dengan sangat sukses oleh Microsoft, tetapi tidak ada perbandingan bahwa perusahaan lain yang menggunakannya terbukti sukses.Alternatif lainnya adalah menggunakan model spiral tetapi hanya jika pengembanganya terbiasa terlatih dengan analisis resiko dan resolusi resiko. Model evolution-tree dan model iterative dan incremental adalah cara terdekat untuk memproduksi software di dunia nyata.
