Model Siklus Hidup produk pengembangan

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

Mulai dari awal
Kebutuhan
Analisa
Desain Kebutuhan
Implementasi
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.

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
Studi kasus yang digunakan adalah model waterfall dari siklus hidup [Royce, 1970]; versi sederhana
dari model Water Fall digambarkan dalam gambar diatas. Model klasik siklus hidup dapat
dipandang sebagai model linier dari Gambar 2.1 dengan loop umpan balik. Kemudian, jika terdapat kesalahan

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 evolusi-pohon Gambar 2.2, tidak dapat menunjukkan urutan peristiwa. Model evolusipohon
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 terusmenerus 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:
1. ini harus dimodifikasi untuk menangani kawasan penjualan tambahan.

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].
Aspek kedua dari pengembangan perangkat lunak dunia nyata adalah pembatasan yang dikenakan
pada kita oleh Hukum Miller. Pada tahun 1956, George Miller, seorang profesor psikologi, menunjukkan bahwa,
di salah satu waktu, kita manusia mampu berkonsentrasi pada hanya sekitar tujuh potongan (unit informasi)
[Miller, 1956]. Namun, perangkat lunak khas memiliki jauh lebih dari tujuh potongan. Sebagai contoh, sebuah
artefak kode cenderung memiliki jauh lebih dari tujuh variabel, dan dokumen persyaratan cenderung memiliki

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.
Tiga anak panah melesat dari evolusi-model pohon menunjukkan bahwa setiap kenaikan merupakan
pemeliharaan kenaikan sebelumnya. Dalam contoh ini, kenaikan kedua dan ketiga adalah contoh dari
pemeliharaan korektif. Itu adalah, setiap kenaikan mengoreksi kesalahan dalam kenaikan sebelumnya. Seperti
sebelumnya menjelaskan, Kenaikan B (Episode 2) mengoreksi workfl pelaksanaan ow oleh mengganti variabel
presisi ganda dengan variabel presisi tunggal biasa. Kenaikan C (Episode 3) engoreksi aliran desain workfl
dengan menggunakan gambar yang lebih cepat algoritma pengakuan, sehingga memungkinkan persyaratan
waktu respon untuk menjadi bertemu. Perubahan yang sesuai maka harus dibuat untuk workfl pelaksanaan
ow. Akhirnya, di Kenaikan D (Episode 4) persyaratan berubah menjadi menetapkan meningkatkan akurasi

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.

2.8 Mengelola Iterasi dan incrementation

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 ini pertama dikemukakan oleh royce(1970). poin penting pada model waterfall adalah tidak
ada fase yg selesai samapai dokumentasi pada fase itu selesai dan produk pada fase tersebut sudah
diterima oleh tim penjamin kualitas software. pengetesan harus dilakukan terus menerus selama
pengembangan software. kadang, dalam proses perawatan perlu dipastikan bahwa versi yang sudah
dimodifikasi masih memiliki fitur dari versi sebelimnya, namun juga memuasakn kebutuhan baru yang
diminta oleh klien.

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.
Setiap organisasi pengembang software harus memutuskan model life-cycle mana yang cocok
digunakan untuk organisasinya.

Dokumen yang terkait

Dokumen baru

Model Siklus Hidup produk pengembangan