2.

7 Resiko dan aspek dari iteration dan incrementation

Cara lain melihat iterasi dan incrementation proyek secara keseluruhan dibagi menjadi proyek kecil (atau
increment) untuk memperluas persyaratan artefak, analisis, desain, implementasi, dan pengujian yang
menghasilkan produk perangkat lunak yang lengkap. Hal ini untuk memeriksa bahwa alur kerja tesnya benar dan
membuat sebuah perubahan yang diperlukan pada artefak yang relevan. Proses pemeriksaan dan modifikasi dicek
kembali dan memodifikasi, hal ini berlanjut hingga tim pengembangan puas dengan semua artefak dari proyek mini
saat ini. Ketika hal tersebut terjadi, tim pengembang membandingkan gambar 2.3 (model waterfall) dengan
gambar 2.5 (melihat iterasi dengan increment B) yang menunjukkan bahwa setiap iterasi bisa dilihat sebagai bagian
kecil namun melengkapi model waterfall. Oleh karena itu, selama tiap iterasi tiap anggota tim pengembangan
menggunakan persyaratan klasik, analisis, desain, dan pelaksanaan pada bagian tertentu dari produk perangkat
lunak.
Model iterative dan incre mental (tambahan) memiliki banyak kelebihan :
1. Beberapa tujuan ditawarkan untuk memeriksa bahwa produk perangkat lunak benar.
2. Kekokohan dasar arsitektur yang mendasari dapat ditentukan relative awal dalam siklus hidup.
3. Model iterative dan incremental menyediakan untuk mengurangi resiko awal yang selalu terlibat dalam
pengembangan perangkat lunak dan pemeliharaan.
4. Kami memiliki versi kinerja perangkat lunak. Hal ini berguna apabila pengguna dank lien dapat melakukan
percobaan pada versi tersebut dan menentukan perubahan yang diperlukan untuk memastikan
implementasi yang memenuhi kebetuhan mereka.
5. Ada bukti empiris bahwa berulang-dan tambahan merupakan karya siklus hidup.

2.8 Mengatur Iterasi dan Incrementation
Pengembang produk perangkat lunak menggunakan model waterfall berturut-rutur melakukan
persyaratan, analisis, desain, dan tahapan pelaksanaan (dalam urutan itu) pada produk perangkat lunak secara
keseluruhan. Jika masalah ditemukan, loop umpan balik pada gambar 2.3 (panah putus-putus) yang diikuti; yaitu,
iterasi dilakukan. Namun, jika produk perangkat lunak dikembangkan dengan model interactive dan
incrementation, produk perangkat lunak diperlakukan sebagai set bertahap. Untuk setiap kenaikan pada gilirannya,
persyaratan, analisis, desain, dan tahapan pelkasanaan (Dalam urutan itu) berulang kali dilakukan pada kenaikan itu
sampai jelas bahwa tidak ada iterasi lebih lanjut yang diperlukan) sebagai set bertahap. Untuk setiap kenaikan
pada gilirannya, persyaratan, analisis, desain, dan tahapan pelaksanaan dalam urutan itu berulang kali dilakukan
pada kenaikan tersebut hingga jelas tidak ada iterasi lebih lanjut yang diperlukan. Dengan kata lain, proyek secara
keseluruhan adalah dipecah menjadi serangkaian proyekwaterfall mini. Selama setiap proyek iterasi mini adalah
sesuai kebutuhan seperti pada gambar 2.5. oleh karena itu, alasan paragfraf sebelumnya menyatakan bahwa model
iterative dan incrementation adalah waterfall yang diterapkan berturut-turut.

2.9 Model Siklus Hidup lain
2.9.1 Code dan Fix model Life-Cycle Model
Produk ini dilaksanakan tanpa persyaratan atau peringatan spesifik atau upaya desain. Sebaliknya
parang pengembang hanya membuang kode bersama-sama dan ulang sebanyak yang diperlukan untuk
memenuhi klien. Pendekatan ditunjukkan pada gambar 2.8 dengan jelas menampilkan adanya
persyaratan, perignatan spesifik, dan desain. Meskipun pendekatan ini bekerja dengan baik pada
pemrograman pendek 100 atau 200 bari, model code and fix benar-benar memuaskan untuk produk dari
berbagai ukuran yang wajar. Pada gambar 1.6 menunjukkan biaya perubahan perangkat lunak relative
kecil perubahan dibuat selama persyaratan, analisis, atau fase desain tapi tumbu terlampau besar jika
dibuat setelah produk dikodeakn atau lebih buruk jika telah dikirim dan diinstal pada komputer klien. Oleh
karena itu, biaya pendekatan code-and fix lebih besar dariapa biaya produk yang ditentukan dan dirancang
dengan cermat. Pemeliharaan produk sangat sulit tanpa spesifikasi atau desain dokumen, dan
kemungkinan kesalahan regresi terjadi lebih besar. Pendekatan code and fix penting sebelum
pengembangan produk dimulai, model siklus hidup yang tepat dipilih.
Terlalu banyak proyek menggunakan model code and fix. Mengakibatkan pengembang perangkat
lunak mengubah-ubah banyak baris kode. Model code and fix merupakan model yang paling mudah dan
merupakan pengembangan perangkat lunak yang paling mudah.

2.9.2 Model Waterfall Life-Cycle
Pertama kali ditemukan pertama kali oleh Royce. Menunjukkan umpan balik loop untuk
pemeliharaan sementara produk yang dikembangkan. Umpan balik loop untuk pemeliharaan sementara
produk sedang dikembangkan, untuk pemeliharaan sementara yang sedang dikembangkan. Titik kritis
model waterfall adalah bahwa ada fase selesai sampai dokumentasi untuk fase yang selesai dan produk
dari fase yang telah disetujui oleh jaminan kualitas perangkat lunak SQA kelompok yang membawa lebih
ke dalam modifikasi; jika produk dari fase sebelumnya telah diubah sebagai konsekuensi umpan balik
berikutnya bahwa fase sebelumnya selesai hanya jika dokumentasi untuk fase telah dimodifikasi kation
modifikasi sudah diperiksa SQA. Pengujian tidak terpisah yang dilakukan hanya setelah produk dibangun,
jika tidak dilakukan hanya pada akhir setiap tahap. Secara khusus, selama pemeliharaan perlu memastikan
bahwa versi yang dimodifikasi masih melakukan versi sebelumnya dan masih melakukan dengan benar
(pengujian regresi) tapi masih memenuhi setiap baru persyaratan yang dikenakan oleh klien.
Kelebihan model waterfall termasuk disiplin yang ditegakkan. Pendekatan ketentuan
dokumentasi yang diberikan pada setiap fase dan persyaratan bahwa semua produk dari setiap fase
(termasuk dokumentasi) menjadi cermat diperiksa SQA, faktanya model waterfall adalah dokumentasi di
dorong menjadi kelemahan.
2.9.3 Rapid Prototyping Life Cycle Model
Rapid prototype adalah Model kerja yang secara fungsional setara dengan subset dari produk.
Misalnya, jika produk target adalah untuk menangani hutang, piutang, dan pergudangan, maka prototipe
cepat mungkin terdiri dari produk yang melakukan layar penanganan untuk menangkap data dan
mencetak laporan, tetapi tidak melakukan update file atau kesalahan penanganan. Sebuah prototipe cepat
untuk produk target itu adalah untuk menentukan konsentrasi enzim dalam larutan mungkin melakukan
perhitungan dan menampilkan jawabannya, tapi tanpa melakukan apapun validasi atau kewajaran
pengecekan data input. Langkah pertama dalam cepat-prototyping siklus hidup modeldepicted pada
Gambar 2.10 adalah untuk membangun prototipe cepat dan membiarkan klien pengguna dan masa depan
berinteraksi dan bereksperimen dengan prototipe cepat. Setelah klien satisfi ed bahwa prototipe cepat
memang melakukan sebagian besar.
Pelaksanaan datang berikutnya. Dalam model waterfall, pelaksanaan desain kadang-kadang
menyebabkan merancang kesalahan datang ke cahaya. Dalam model cepat-prototyping, fakta bahwa versi
kerja awal dari produk perangkat lunak telah dibangun cenderung mengurangi kebutuhan untuk
memperbaiki desain selama atau setelah implementasi. Prototipe telah memberikan beberapa wawasan
kepada tim desain, meskipun mungkin mencerminkan fungsi hanya sebagian dari produk target yang
lengkap. Bisnis:Perangkat PenerjemahPenerjemah Situs WebPeluang Pasar Global Matikan terjemahan
instan. Tentang Seluler Komunitas Privasi Bantuan Kirim masukan. Klik untuk mengedit dan melihat
terjemahan