BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
PERENCANAAN DAUR HIDUP
• Pokok bahasan
∗ Water fall model.
∗ Code and fix model.
∗ Spiral model.
∗ Modified model.
∗ Evolutionary prototyping.
∗ Staged delivery.
∗ Design to schedule.
∗ Design to tools.
∗ Commercial off the shelf software.
∗ Memilih model yang cocok.
• Pengertian dan gunanya daur hidup.
Daur hidup adalah model yang mengindikasikan apa yang akan terjadi antara saat awal pembuatan sampai sistem tersebut tidak dapat berfungsi lagi.
Fungsi utama model daur hidup (lingkup bahasan ini) adalah menentukan urutan spesifikasi proyek, prototip, rancangan, implementasi, telaah, uji, dan kegiatan lain yang diperlukan.
Juga kriteria yang dipergunakan untuk menentukan apakah suatu kegiatan sudah boleh beranjak ke kegiatan berikutnya.
Karena merupakan rencana induk (master plan) maka ia akan mempengaruhi keberhasilan atau kegagalan proyek.
• Water fall model.
Gambar 7.1 Softwa
Conce
Requireme Analys is
Architectu Desig n
Detaile Desig n
Coding Debuggi ng
Syste Testin g
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Model paling kuno.
∗ Banyak mengandung masalah.
∗ Menjadi basis model lainnya.
∗ Kemajuan proyek dilakukan langkah demi langkah.
∗ Pada setiap akhir langkah dilakukan telaah.
∗ Document driven, artinya hasil utama adalah dokumen yang dialirkan ke kegiatan berikutnya.
∗ Pada water fall murni, kegiatan tidak tumpang tindih.
∗ Cocok untuk sistem yang stabil definisinya, metodologi yang difahami secara matang.
∗ Dapat mengindikasikan error di awal proyek.
∗ Biayanya murah.
∗ Mengurangi biaya perencanaan.
∗ Tidak segera menghasilkan produk yang tangible kecuali dokumen.
∗ Cocok untuk tim yang kurang pengalaman dan keterampilan.
∗ Sangat sulit untuk mespesifikasikan kebutuhan di awal proyek, sebelum rancangan dibuat bahkan sebelum program mulai dilakukan.
∗ User sering tidak tahu kebutuhannya sendiri.
∗ Tidak luwes menangani kebutuhan user yang sering berubah.
∗ Tidak mudah melakukan iterasi.
∗ Tools, metodologi sukar untuk mengakomodasi rentang fase kegiatan yang panjang.
∗ Terlalu banyak dokumen, sehingga butuh waktu yang banyak.
• Code and fix model.
Gambar 7.2
∗ Model yang bisa digunakan, tetapi tidak lazim.
∗ Tidak membutuhkan perencanaan proyek.
∗ Bila dikombinasikan dengan jadwal yang singkat bisa menjadi code-like-hell.
∗ Dimulai dengan ide umum/kasar.
∗ Bisa memiliki, bisa juga tidak punya spesifikasi formal.
∗ Tidak ada overhead, yaitu tidak diperlukan waktu untuk perencanaan, dokumentasi, pengendalian mutu, standarisasi.
∗ Tidak membutuhkan pengalaman, setiap pemrogram dapat langsung mengerjakan program dengan bahasa yang dikuasainya.
∗ Kecuali untuk proyek skala kecil, model ini berbahaya untuk digunakan.
∗ Tidak ada alat untuk memantau kemajuan.
∗ Bila sudah diketahui ada error sebesar 75%, lebih baik buang program untuk memulai yang baru.
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
• Spiral model.
Source: Adapted from “A Spiral Model of Software Development and Enhancement”
(Boehm 1988)
Figure 7-4. The spiral model. In the spiral model, you start small and expand the scope of the project in increments. You expand the scope only after you’ve reduced the risks for the next increment to an acceptable level.
Evaluate alterna- tives
Review
Risk Analysis
Risk Analysis
Risk Analysis
Risk Analysis
Prototype 1 Prototype 2
Prototype 3
Operational prototype
models, Simulations
benchmarks
STAR
Concept of operation
Software require- ments Requirements validation
Software product design Design validation
and verification
Detailed design
Code Unit
test
Release
Acceptance Test
Integration and test
Integration and test plan Development plan
Development plan, lifecycle plan
Cumulative cost
Identify and resolve risks
Partition
Determine objectives, alternatives, and constraints
Cimmot to an approach for the next iteration
Plan the next iteration
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Adalah model yang berorientasi resiko dan menguraikan proyek S/W ke dalam beberapa proyek mini.
∗ Setiap proyek mini mengandung 1 atau lebih resiko besar sedemikian rupa sehingga semua resiko dapat dicakup.
∗ Setiap iterasi terdiri dari 6 langkah :
- Tentukan obyektif,pilihan dan kendala.
- Pecahkan resiko.
- Evaluasi pilihan.
- Kembangkan serahan dari iterasi,verifikasi apakah sudah betul.
- Rancang iterasi berikutnya.
- Melakukan pendekatan untuk iterasi berikutnya.
∗ Biaya di awal proyek murah.
∗ Dapat dikombinasikan dengan model yang lain.
∗ Bila biayanya menaik maka resiko menurun.
∗ Sedikit membutuhkan kendali manajemen.
∗ Cukup rumit karena butuh kecermatan , perhatian dan pengetahuan manajemen.
• Modified models.
Ada beberapa jenis :
1. Sashimi(Waterfall dengan fase yang berlapis).
Gambar 7.5
§ Mengijinkan untuk berlapis (overlap) cukup banyak.
§ Mengurangi jumlah dokumen yang dihasilkan.
§ Tenggat waktu (milestones) menjadi tidak jelas.
§ Sulit untuk menjejak kemajuan proyek.
§ Dapat menyebabkan salah komunikasi, salah asumsi dan berakibat tidak efisien.
§ Paling cocok untuk proyek kecil, terdefinisi dengan baik.
Software
Requirements Architectural
Detailed Design
Coding and Debugging
System Testing
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
2. Waterfall dengan sub proyek.
Gambar 7.6
§ Tidak nampak keterkaitan antar fasa.
§ Sistem memiliki beberapa ‘kejutan’ rancangan.
§ Bila rancangan arsitektur gagal,maka masing-masing sub proyek dapat dilanjutkan secara tersendiri.
Software Concept
Requireme nts Analysis
Architectura l Design
System Testing
Detailed Design
Coding and Debugging
Subsystem Testing Detailed
Design
Coding and Debugging
Subsystem Testing Coding and
Debugging
Coding and Debugging Detailed
Design
Detailed
Design Subsystem
Testing
Subsystem Testing
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
3. Waterfall dengan reduksi resiko.
Gambar 7.7
§ Membuat risk-reduction spiral di awal proyek untuk mengurangi resiko atas ketidak jelasan kebutuhan.
§ Dapat memanfaatkan prototip.
§ Requirement analysis dan architectural design ikut dibebani untuk mengurangi resiko.
• Evolutionary prototyping.
Software Concept
Require- ments Analysis
Architec- tural
Design
Detailed
Design
Coding and
Debugg- ing
System
Testin g
Initial concept
Design implemen
initial prototyp
Refine prototyp until
Complet and prototyp
Gambar 7.8
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Memungkinkan pengembangan sistem bergerak dengan mudah di setiap tahap pengembangan.
∗ Dimulai dari aspek yang paling terlihat / terdefinisi dengan baik.
∗ Lanjutkan dengan prototip, demokan ke user, minta umpan balik.
∗ Setelah selesai, lanjutkan dengan aspek/bagian lain yang perlu digarap.
∗ Demikian seterusnya.
∗ Cocok untuk prototip yang kebutuhannya sering berganti dengan cepat, atau pemakai sering menolak sekumpulan kebutuhan yang telah ditetapkan, atau kedua belah pihak (user & pengembang) sama-sama belum yakin atas kebutuhan sebenarnya.
∗ Tidak mungkin tahu berapa lama proyek ini akan berlangsung.
∗ Tidak mungkin tahu berapa banyak iterasi yang dilakukan.
∗ Pelanggan bisa cemas melihat kemajuan proyek seakan tiada akhir sementara dia harus mengeluarkan uang terus menerus.
• Staged delivery.
Gambar 7.9
∗ Memperlihatkan kemajuan proyek kepada pelanggan.
∗ Pengembang tahu persis apa yang harus dibuat.
Software Concept
Requirement s
Architectur al
Stage 1 : Detailed design, code, debug, test, and delivery
Stage 2 : Detailed design, code, debug, test, and delivery
Stage n : Detailed design, code, debug, test, and delivery
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Penyerahan produk dapat dilakukan sesuai tahapannya sehingga pelanggan dapat memanfaatkannya.
∗ Jadwal proyek mudah dikelolanya.
∗ Tidak berfungsi tanpa perencanaan yang seksama baik di tingkat manajemen maupun teknis.
∗ Penundaan pelaksanaan setiap tahap akan berakibat fatal.
• Design to schedule.
Gambar 7.10
∗ Mirip dengan Staged delivery.
∗ Tidak perlu mengetahui di awal proyek mana yang perlu dibuat pada tahap akhir.
∗ Strategi yang cocok untuk menjamin bahwa sebuah produk dapat dihasilkan pada tanggal tertentu.
∗ Berfokus pada tahapan / produk yang ada pada lintasan kritis. Yang bukan fokus dikerjakan tahap berikutnya.
∗ Produk yang merupakan fungsi utama sistem yang jadi prioritas.
Software Concept
Requireme nts
Architectur al Design
High Priority : Detailed design, code, debug,test
Medium High Priority : Detailed design, code, debug, test
Medium Priority : Detailed design, code, debug, test
Release
Medium Low Priority : Detailed design, code, debug, test
Low Priority : Detailed design, code, debug, test
Run out of time
Or money here
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Bila tidak bisa mendapatkan hasil apa-apa pada setiap tahap, maka hanya menghamburkan waktu untuk melakukan spesifikasi arsitektur dan merancang saja.
Jika hal ini terjadi, fokuskan pada 1 atau 2 fungsi saja.
∗ Tergantung pada kemampuan manajemen dan teknisi pembuat jadwal
• Evolutionary delivery.
Gambar 7.11
∗ Menjembatani model Evolutionary prototyping dengan staged delivery.
∗ Mengembangkan versi sistem produk tertentu, tampilkan ke pelanggan, perbaiki sesuai umpan balik. Kemudian dihasilkan produk akhir.
∗ Jumlah iterasi sesuai kebutuhan.
Softwar e Concep t
Preliminar Requiremeny ts Analysi
s
Design Architectuof re and
System Core
Delive r Final Versio n Develop
a Versio n Incorporat e Custome
r Feedbac k
Delive r the Versio n Elicit
Custome r Feedbac k
Repeat this cycle until you run out of time, you run
out of money, you complete number of iterations the planned, or the customer is
satisfied.
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
• Design to tools.
Gambar 7.12
∗ Adalah model yang radikal, dan dipergunakan pada lingkungan yang peka terhadap waktu.
∗ Bila menggunakan tools yang lentur dan berdaya guna (dilengkapi berbagai kerangka aplikasi, pemrograman visual, mampu mendukung semua kemampuan yang ada pada pemrograman database) maka jumlah proyek yang mampu dihasilkan akan bertambah.
∗ Bisa saja fungsi-fungsi tertentu pada sistem yang ingin dibuat tidak didukung oleh tools tsb.
∗ Dapat dikombinasikan dengan model lain yang juga lentur.
∗ Dapat kehilangan kendali selama proyek berlangsung.
∗ Tidak dapat mengimplementasikan semua fungsi yang diinginkan.
∗ Tidak cocok untuk membuat sistem yang mendukung bisnis yang berjangka panjang.
• Commercial off-the-shelf-software.
∗ Beli software yang sudah jadi.
∗ Jarang bisa memenuhi kebutuhan seutuhnya.
∗ Pelanggan dapat mempelajari S/W tersebut, sambil menunggu versi yang baru.
Functionality
supported by the tools
Functionality that will be built
Ideal functionality Functionality that
will not be in the product
BINA NUSANTARA
Edisi : 1 Revisi : 2 Sept - 1999
∗ Pengembang dapat membuat S/W yang sesungguhnya diperlukan setelah pelanggan tahu persis apa yang diinginkan.
• Memilih model yang cocok.
Dengan menjawab pertanyaan-pertanyaan berikut :
∗ Seberapa baik tingkat pemahaman user dan pengembang terhadap kebutuhan?
∗ Apakah kebutuhan sering berubah?
∗ Seberapa baik pemahaman terhadap arsitektur sistem?
∗ Seberapa banyak/tinggi keandalan yang diinginkan?
∗ Apakah perlu menyajikan kemajuan proyek pada pelanggan?
∗ Apakah perlu menyajikan kemajuan proyek pada manajemen?
∗ Seberapa canggih yang dibutuhkan agar proyek ini berhasil?
∗ Apakah mampu dikoreksi ditengah jadwal?
∗ Apakah ada kendala untuk membuat jadwal di awal proyek?
