MN232 - Manajemen Proyek Piranti Lunak
Pertemuan : 08 - 09
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. Softwa Conce Requireme Analys is Architectu Desig n Detaile Desig n Coding Debuggi ng Syste Testin g Gambar 7.1 BINA NUSANTARA
Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ •
Pertemuan : 08 - 09
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
MN232 - Manajemen Proyek Piranti Lunak
•
Pertemuan : 08 - 09
Spiral model. Cumulative cost Determine objectives, alternatives, and constraints
Identify and resolve risks
Risk Analysis Risk Analysis Cimmot to an approach for the next iteration
Risk Analysis Risk Analysis
Review
STAR Development
Operational prototype
Evaluate alternatives
Prototype 3 Prototype 2
Prototype 1
Simulations models, benchmarks Software requirements Software Detailed Development Requirements product design plan validation design Code Integration and Design validation Unit test plan and verification test
Partition
plan, lifecycle plan
Plan the next iteration
Concept of operation
Integration and test Acceptance Test Release
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. BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
∗ ∗ ∗
∗ ∗ ∗ ∗ ∗ •
Pertemuan : 08 - 09
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).
Software Requirements Architectural Detailed Design Coding and Debugging System Testing 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. BINA NUSANTARA
Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
Pertemuan : 08 - 09
2. Waterfall dengan sub proyek. Software Concept Requireme nts Analysis
Detailed Design
Architectura l Design
Coding and Debugging Detailed Design
Subsystem Testing Coding and Debugging
Detailed Design
Subsystem Testing Coding and Debugging
Detailed Design
Subsystem Testing Coding and Debugging
System Testing Subsystem Testing
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.
BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
Pertemuan : 08 - 09
3. Waterfall dengan reduksi resiko.
Software Concept Requirements Analysis Architectural
Design Detailed
Design Coding and
Debugging System
Testin g § § § •
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.
Initial concept
Design implemen initial prototyp
Refine prototyp until
Complet and prototyp
BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
Gambar 7.8
MN232 - Manajemen Proyek Piranti Lunak
∗ ∗ ∗ ∗ ∗ ∗
∗ ∗ ∗ •
Pertemuan : 08 - 09
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. 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 Gambar 7.9 ∗ ∗
Memperlihatkan kemajuan proyek kepada pelanggan. Pengembang tahu persis apa yang harus dibuat. BINA NUSANTARA
Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
Pertemuan : 08 - 09
∗
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. Software Concept Requireme nts Architectur al Design High Priority : Detailed design, code, debug,test Medium High Priority : Detailed design, code, debug, test Run out of time
Medium Priority : Detailed design, code, debug, test
Or money here
Release
Medium Low Priority : Detailed design, code, debug, test Low Priority : Detailed design, code, debug, test
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. BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
Pertemuan : 08 - 09
∗
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.
Softwar eConcep t Preliminar Requiremen y ts Analysi s Design Architectu of and re Core System
Delive r Final Versio n Develop aVersio n
Repeat this cycle until outrun of time, you run you money, out of you complete number of iterations the or the customer is planned, satisfied.
Incorporat eCustome rFeedbac k
Delive r the Versio n Elicit Custome rFeedbac k
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.
BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
•
Pertemuan : 08 - 09
Design to tools.
Functionality supported by the tools
Functionality that will not be in the product
Functionality that will be built
Ideal functionality
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. BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
MN232 - Manajemen Proyek Piranti Lunak
∗ •
Pertemuan : 08 - 09
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?
BINA NUSANTARA Edisi :
1
Revisi :
2
Sept - 1999
