Pokok bahasan Water fall model. Code and fix model. Spiral model. Modified model. Evolutionary prototyping. Staged delivery. to schedule. to tools. Commercial off the shelf software. Memilih model yang cocok. PERENCANAAN DAUR HIDUP 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 Gambar 7.1 Detaile Desig n Coding Debuggi ng Syste Testin g
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.
Spiral model. Cumulative cost Determine objectives, alternatives, and constraints Identify and resolve risks Cimmot to an approach for the next iteration Review Partition Plan the next iteration STAR Development plan, lifecycle plan Development plan Integration and test plan Risk Concept of operation Risk Prototype 1 Requirements validation validation and verification Release Risk Prototype 2 Risk Prototype 3 Simulations models, requirements product design Unit test Integration and test Acceptance Test Operational prototype benchmarks design Code Evaluate alternatives Source: Adapted from A Spiral Model of 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.
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). Requirements Architectural Gambar 7.5 System 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.
2. Waterfall dengan sub proyek. Concept Requireme nts Architectura l Subsystem Subsystem Subsystem Subsystem System 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.
3. Waterfall dengan reduksi resiko. Concept 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. Requirements Architectural System Testin g Initial concept implemen initial prototyp Refine prototyp until Complet and prototyp Gambar 7.8
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. Concept Requirement s Architectur al Stage 1 : design, code, debug, test, and delivery Stage 2 : design, code, debug, test, and delivery Stage n : design, code, debug, test, and delivery Gambar 7.9 Memperlihatkan kemajuan proyek kepada pelanggan. Pengembang tahu persis apa yang harus dibuat.
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. to schedule. Concept Requireme nts Architectur al High Priority : design, code, Run out of time Or money here Medium High Priority : design, code, debug, test Medium Priority : design, code, debug, test Release Medium Low Priority : design, code, debug, test Low Priority : 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.
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 Architectu of reand System Core Delive rfinal Versio n Repeat this cycle until you out run of time, you run out money, of you complete number the of iterations planned, or the customer is satisfied. Incorporat ecustome rfeedbac k Gambar 7.11 Develop aversio n Elicit Custome rfeedbac k Delive r the Versio n 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.
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.
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?