ISU-ISU PENTING PENGEMBANGAN SECARA CEPAT

Ukuran: px

Mulai penontonan dengan halaman:

Download "ISU-ISU PENTING PENGEMBANGAN SECARA CEPAT"

Sucianty Kusumo
7 tahun lalu
Tontonan:

1 ISU-ISU PENTING PENGEMBANGAN SECARA CEPAT Pokok Bahasan Apakah perangkat lunak dapat memenuhi semua kebutuhan? Jenis pengembangan cepat yang dibutuhkan. Bagaimana memenuhi jadwal. Persepsi dan kenyataan. Alokasi waktu. Faktor-faktor lainnya pada pengembangan. Pola penjadwalan. Apakah perangkat lunak dapat memenuhi semua kebutuhan? Pada umumnya, sistem yang didistribusikan dan digunakan secara luas membutuhkan pengembangan yang lebih seksama dibandingkan sistem yang punya tujuan spesifik. Produk yang harus punya keandalan tinggi juga harus seksama dikembangkan dibanding yang kurang keandalannya. Jadi banyak variasi dalam pengembangan sistem, sehingga tidak ada solusi yang cocok untuk semua situasi. Gambar 6.1 Jenis pengembangan cepat yang dibutuhkan. Isu pokok yang perlu diketahui dalam memilih pengembangan secara cepat apakah kecepatan, kemudahan untuk melihat kemajuan, biaya rendah, mudah menduga adanya katastrofi, atau dikembangkan dengan cepat berapapun biayanya. Untuk itu pertanyaan dibawah ini perlu dijawab: Berapa besar kendala jadwal kerja yang ada? Apakah proyek menekankan penjadwalan? Apakah proyek dibatasi oleh berbagai kelemahan yang menghambat penggunaan pengembangan secara cepat?

2 Ciri-ciri pengembangan secara cepat. Mencegah terjadinya lewat-jadwal dan lewat-anggaran. Mampu memberikan prediksi di awal proyek. Biaya agak tinggi padahal lazimnya pelanggan meminta jadwal singkat dan biaya murah. Mengurangi biaya lembur. Fixed drop-dead date, menurunnya nilai produk seiring berlalunya waktu dan sampai titik tertentu menurun dengan tajam. Time Frame 1 Time Frame 2 Drop-dead Value of Product Time Gambar 6.4 Memenuhi jadwal. Banyak proyek yang cenderung lambat kemajuannya. Estimasi proyek dinampakkan seperti gambar dibawah ini. n 100 percent of completing planned on Gambar 6.5

3 Probabili Comple Exactly Gambar 6.6 Banyak faktor yang dapat mempengaruhi kemajuan jadwal untuk dapat tepat memenuhi target. completing on before the completion of after the completion on Gambar /50 "breakschedul Rapidzon Efficientzon Slowzon on Impossibl development Gambar 6.8

4 Persepsi dan kenyataan. Sering kali terjadi perbedaan persepsi antara pengembang dengan user dalam menginterpretasikan jadwal rencana dan aktual kemajuan proyek. Harapan user yang tidak realistik juga bisa menjadi hambatan dalam mencapai kecepatan pengembangan proyek. Banyak proyek yang kurang baik perencanaan dan komitmen terhadap sumber daya untuk dapat mencapai target yang sudah dijadwalkan. Most projects scheduled in these Most projects completed in these on Gambar 6.9 Mengatasi lambatnya kecepatan pengembangan. Bila memang kenyataannya pengembangan berjalan lambat. Buat jadwal yang lebih pendek dan ubah cara membuatnya dari efficient development ke rapid development. Bila ada persepsi bahwa pengembangan berjalan lambat. Buat jadwal yang lebih realistik dengan memperpanjang jadwal mendekati tanggal Penyelesaian aktual. Alokasi waktu. Salah satu strategi untuk mencapai pengembangan secara cepat adalah menemukan area dimana saja sebagian besar waktu di pergunakan pada proyek-proyek yang sejenis.usahakan kurangi / perpendek waktu tersebut. Approximate Activity Breakdown by size of Project Small Project Large Project Activity (2,500 lines of code) (500,000 lines of code) Architecture/design 10% 30% Detailed design 20% 20% Dcode/debug 25% 10% Unit test 20% 5% Integration 15% 20% System test 10% 15% Tabel 6.1

5 Kelemahan yang dijumpai. Dari survei atas 4000 proyek, peneliti CAPERS JONES melaporkan hanya 35% yang dikerjakan efisien, 65% lainnya sangat boros waktu dan tidak produktif. Ketidak-efisienan terutama karena: - Menggunakan tools yang tidak bekerja sempurna. - Terlalu banyak perbaikan pada modul. - Kurangnya kendali konfigurasi sehingga banyak pekerjaan yang sia-sia. Beberapa area dimana waktu dapat dihemat : - Pekerjaan ulang (Rework). Mengulangi pekerjaan karena cacad pada saat definisi kebutuhan, rancangan dan pemrograman biasanya membutuhkan 40-50% dari total biaya pengembangan. Perbaiki cacad seawal mungkin. - Pendefinisian kemampuan sistem yang belum mapan. Definisi feature sistem yang belum mapan akan membutuhkan tambahan waktu 25% dari total proyek. - Spesifikasi kebutuhan. Membutuhkan 10 s/d 30% dari total proyek. Faktor-faktor lain : Schedule, cost and product trade-offs. Dasar-dasar manajemen umum biasanya menekankan pada 3 hal: jadwal, biaya dan kualitas. Pada proyek S/W kualitas kurang mendapat perhatian, karena bila fokus pada kualitas bisa berakibat terjadi penurunan biaya dan waktu di suatu bagian pekerjaan tetapi pada bagian lain biaya dan waktu justru menaik. Karena itu perhatian diberikan seimbang pada jadwal, biaya dan produk. Quality trade-offs. Produk S/W memiliki 2 jenis kualitas : 1. Kualitas untuk produk yang bercacad rendah. Tidak perlu trade-off dengan jadwal. 2. Kualitas untuk produk yang berpeluang cacad tinggi. (S/W yang mudah dipakai, efisien, kokoh, dsb) bisa membutuhkan waktu yang lebih banyak.bila perlu tambah orang. Pola penjadwalan. Kurva pengembangan pada umumnya. Sulit untuk mencapai target tepat waktu. Planned 50/50 n on Gambar 6.11

6 Kurva pengembangan yang efisien. Lebih panjang dari jadwal proyek sejenis, tetapi kenyataannya lebih pendek. n Planned 50/50 schedule are same on Gambar 6.12 Kurva pengembangan cepat yang ideal. Bila semua berjalan lancar, dapat diduga sebelumnya akan mencapai kecepatan yang diharapkan. on Gambar 6.13

dokumen-dokumen yang mirip

MN232 - Manajemen Proyek Piranti Lunak Pertemuan : ESTIMASI

MN232 - Manajemen Proyek Piranti Lunak Pertemuan : ESTIMASI Pokok Bahasan Sejarah estimasi. Proses estimasi. Ukuran estimasi. Estimasi usaha. Estimasi jadwal. Sulitnya estimasi usaha. Penghalusan estimasi. ESTIMASI Sejarah estimasi. Isu - Beberapa estimasi dilakukan