MANAJEMEN PROYEK PERANGKAT LUNAK
3.7 COMO—TEKNIK ESTIMASI HEURISTIS
Model estimasi biaya konstruktif (COCOMO) diusulkan oleh Boehm [1981]. COCOMO menetapkan proses tiga tahap untuk estimasi proyek. Pada tahap pertama, perkiraan awal tiba. Selama dua tahap berikutnya, perkiraan awal disempurnakan untuk sampai pada perkiraan yang lebih akurat. COCOMO menggunakan model estimasi tunggal dan multivariabel pada tahap estimasi yang berbeda. Tiga tahapan teknik estimasi COCOMO adalah—COCOMO dasar, COCOMO intermediate, dan COCOMO lengkap.
Model COCOMO Dasar
Boehm mendalilkan bahwa setiap proyek pengembangan perangkat lunak dapat diklasifikasikan ke dalam salah satu dari tiga kategori berikut berdasarkan kompleksitas pengembangan-organik, semi-terpisah, dan tertanam. Berdasarkan kategori proyek pengembangan perangkat lunak, ia memberikan serangkaian rumus yang berbeda untuk memperkirakan upaya dan durasi dari perkiraan ukuran.
Tiga kelas dasar proyek pengembangan perangkat lunak
Untuk mengklasifikasikan proyek ke dalam kategori yang diidentifikasi, Boehm mengharuskan kita untuk mempertimbangkan tidak hanya karakteristik produk tetapi juga karakteristik tim pengembangan dan lingkungan pengembangan. Secara kasar, tiga kelas pengembangan produk sesuai dengan pengembangan aplikasi, utilitas, dan perangkat lunak sistem. Biasanya, program pemrosesan data1 dianggap sebagai program aplikasi. Compiler, linker, dll, adalah program utilitas. Sistem operasi dan program sistem waktu nyata, dll. adalah program sistem. Program sistem berinteraksi langsung dengan perangkat keras dan kompleksitas pemrograman juga muncul dari persyaratan untuk memenuhi batasan waktu dan pemrosesan tugas secara bersamaan.
Brooks [1975] menyatakan bahwa program utilitas kira-kira tiga kali lebih sulit untuk ditulis sebagai program aplikasi dan program sistem kira-kira tiga kali lebih sulit daripada program utilitas. Jadi menurut Brooks, tingkat relatif kompleksitas pengembangan produk untuk tiga kategori (aplikasi, utilitas dan program sistem) produk adalah 1:3:9. Definisi Boehm [1981] tentang perangkat lunak organik, semi-terpisah, dan tertanam diuraikan sebagai berikut:
Organik: kita dapat mengklasifikasikan proyek pengembangan menjadi tipe organik, jika proyek tersebut berkaitan dengan pengembangan program aplikasi yang dipahami dengan baik, ukuran tim pengembangan cukup kecil, dan anggota tim berpengalaman dalam mengembangkan jenis proyek serupa.
Semidetached: Sebuah proyek pengembangan dapat diklasifikasikan menjadi tipe semidetached, jika tim pengembangan terdiri dari campuran staf yang berpengalaman dan tidak berpengalaman. Anggota tim mungkin memiliki pengalaman yang terbatas pada sistem terkait tetapi mungkin tidak terbiasa dengan beberapa aspek dari sistem yang sedang dikembangkan.
Embedded: Sebuah proyek pengembangan dianggap tipe tertanam, jika perangkat lunak yang dikembangkan sangat digabungkan dengan perangkat keras, atau jika ada peraturan ketat tentang prosedur operasional. Anggota tim mungkin memiliki pengalaman yang terbatas pada sistem terkait tetapi mungkin tidak terbiasa dengan beberapa aspek dari sistem yang sedang dikembangkan.
Perhatikan bahwa dalam menentukan kategori proyek pengembangan, selain mempertimbangkan karakteristik produk yang dikembangkan, kita perlu mempertimbangkan karakteristik anggota tim. Dengan demikian, program pemrosesan data sederhana dapat diklasifikasikan sebagai semi-terpisah, jika anggota tim tidak berpengalaman dalam pengembangan produk serupa.
Untuk tiga kategori produk, Boehm menyediakan rangkaian ekspresi yang berbeda untuk memprediksi upaya (dalam satuan orang-bulan) dan waktu pengembangan dari estimasi ukuran yang diberikan dalam kilo baris kode sumber (KLSC). Tapi, berapa banyak usaha satu orang-bulan? Satu orang per bulan adalah upaya yang biasanya dilakukan seseorang dalam sebulan. Perkiraan orang-bulan secara implisit memperhitungkan kerugian produktivitas yang biasanya terjadi karena hilangnya waktu di hari libur, libur mingguan, rehat kopi, dll.]
Gambar 3.3 Kurva orang-bulan.
Apa itu Person-Month?
Orang-bulan (PM) adalah unit populer untuk pengukuran usaha. Person-month (PM) dianggap sebagai unit yang tepat untuk mengukur upaya, karena developer biasanya ditugaskan ke sebuah proyek selama beberapa bulan tertentu. Perlu dicatat bahwa perkiraan upaya 100 PM tidak berarti bahwa 100 orang harus bekerja selama 1 bulan. Juga tidak berarti bahwa 1 orang harus dipekerjakan selama 100 bulan untuk menyelesaikan proyek. Estimasi usaha hanya menunjukkan area di bawah kurva orang-bulan (lihat Gambar 3.3) untuk proyek tersebut. Plot pada Gambar 3.3 menunjukkan bahwa jumlah personel yang berbeda dapat bekerja pada titik yang berbeda dalam pengembangan proyek. Jumlah personel yang bekerja pada proyek biasanya bertambah atau berkurang dengan jumlah yang tidak terpisahkan, menghasilkan tepian yang tajam di plot.
Bentuk umum dari ekspresi COCOMO
Model COCOMO dasar adalah model heuristik variabel tunggal yang memberikan perkiraan perkiraan parameter proyek. Model estimasi COCOMO dasar diberikan oleh ekspresi dari bentuk-bentuk berikut:
Usaha = a1 × (KLOC)a2 PM Tdev = b1 × (Usaha)b2 bulan di mana,
• KLOC adalah perkiraan ukuran produk perangkat lunak yang dinyatakan dalam Kilo Lines Of Code.
• a1, a2, b1, b2 adalah konstanta untuk setiap kategori produk perangkat lunak.
• Tdev adalah perkiraan waktu untuk mengembangkan perangkat lunak, dinyatakan dalam bulan.
• Upaya adalah upaya total yang diperlukan untuk mengembangkan produk perangkat lunak, dinyatakan dalam person-months (PM)
Menurut Boehm, setiap baris teks sumber harus dihitung sebagai satu LOC terlepas dari jumlah instruksi sebenarnya pada baris itu. Jadi, jika satu instruksi mencakup beberapa baris (katakanlah n baris), itu dianggap sebagai nLOC. Nilai a1, a2, b1, b2 untuk berbagai kategori produk seperti yang diberikan oleh Boehm [1981] diringkas di bawah ini. Dia memperoleh nilai-nilai ini dengan memeriksa data historis yang dikumpulkan dari sejumlah besar proyek aktual. Estimasi upaya pengembangan: Untuk tiga kelas produk perangkat lunak, rumus untuk memperkirakan upaya berdasarkan ukuran kode ditunjukkan di bawah ini:
Organik : Upaya = 2,4(KLOC)1,05 PM Semi-terpisah : Upaya = 3.0(KLOC)1.12 PM Tertanam : Upaya = 3.6(KLOC)1.20 PM
Estimasi waktu pengembangan: Untuk ketiga kelas produk perangkat lunak, rumus untuk memperkirakan waktu pengembangan berdasarkan upaya diberikan di bawah ini:
Organik : Tdev = 2.5(Effort)0.38 Bulan Semi-terpisah : Tdev = 2.5(Effort)0.35 Bulan Tertanam : Tdev = 2.5(Effort)0.32 Bulan
Kita dapat memperoleh beberapa wawasan tentang model COCOMO dasar, jika kita memplot perkiraan nilai upaya dan durasi untuk ukuran perangkat lunak yang berbeda.
Gambar 3.4 menunjukkan plot perkiraan upaya versus ukuran produk untuk berbagai kategori produk perangkat lunak.
Pengamatan dari plot ukuran usaha Dari Gambar 3.4, kita dapat mengamati bahwa usaha adalah beberapa yang superlinear (yaitu, kemiringan kurva>1) dalam ukuran produk perangkat lunak.
Gambar 3.4 Upaya versus ukuran produk.
Hal ini karena eksponen dalam ekspresi usaha lebih dari 1. Dengan demikian, usaha yang dibutuhkan untuk mengembangkan produk meningkat pesat dengan ukuran proyek.
Namun, perhatikan bahwa peningkatan upaya dengan ukuran tidak seburuk yang digambarkan dalam Bab 1. Alasannya adalah karena COCOMO mengasumsikan bahwa proyek
dirancang dan dikembangkan dengan hati-hati dengan menggunakan prinsip-prinsip rekayasa perangkat lunak.
Pengamatan dari waktu pengembangan—ukuran plot
Waktu pengembangan versus ukuran produk di KLOC diplot pada Gambar 3.5. Dari Gambar 3.5, kita dapat mengamati hal berikut:
• Waktu pengembangan adalah fungsi sublinier dari ukuran produk. Artinya, ketika ukuran produk meningkat dua kali lipat, waktu untuk mengembangkan produk tidak berlipat ganda tetapi meningkat secara moderat. Misalnya, untuk mengembangkan produk dua kali lebih besar dari produk ukuran 100KLOC, peningkatan durasi mungkin hanya 20 persen. Mungkin tampak mengejutkan bahwa kurva durasi tidak meningkat secara superlinear—seseorang biasanya mengharapkan kurva berperilaku serupa dengan yang ada di plot ukuran usaha. Anomali yang tampak ini dapat dijelaskan oleh fakta bahwa COCOMO mengasumsikan bahwa pengembangan proyek tidak dilakukan oleh satu orang tetapi oleh tim pengembang.
• Dari Gambar 3.5 kita dapat mengamati bahwa untuk proyek dengan ukuran tertentu, waktu pengembangan kira-kira sama untuk ketiga kategori produk.
Misalnya, program 60 KLOC dapat dikembangkan dalam waktu sekitar 18 bulan, terlepas dari apakah itu jenis organik, semi-terpisah, atau tertanam.
(Harap verifikasi ini menggunakan rumus dasar COCOMO yang dibahas di bagian ini). Namun, menurut rumus COCOMO, program yang disematkan membutuhkan upaya yang jauh lebih tinggi daripada program aplikasi atau utilitas. Kita dapat mengartikannya bahwa ada lebih banyak ruang untuk kegiatan paralel untuk program sistem daripada di program utilitas atau aplikasi.
Gambar 3.5 Waktu pengembangan versus ukuran.
Perkiraan biaya
Dari estimasi tenaga, biaya proyek dapat diperoleh dengan mengalikan estimasi tenaga (dalam man-month) dengan biaya tenaga kerja per bulan. Tersirat dalam perhitungan biaya proyek ini adalah asumsi bahwa
seluruh biaya proyek dikeluarkan karena biaya tenaga kerja saja. Namun, selain biaya tenaga kerja, suatu proyek akan dikenakan beberapa jenis biaya lain yang akan kita sebut sebagai biaya overhead. Biaya overhead akan mencakup biaya karena perangkat keras dan
perangkat lunak yang diperlukan untuk proyek dan biaya overhead perusahaan untuk administrasi, ruang kantor, listrik, dll. Tergantung pada nilai yang diharapkan dari biaya overhead, manajer proyek harus meningkatkan skala yang sesuai biaya tiba dengan menggunakan rumus COCOMO.
Implikasi dari upaya dan perkiraan durasi
Implikasi implisit penting dari perkiraan COCOMO adalah jika Anda mencoba menyelesaikan proyek dalam waktu yang lebih singkat dari perkiraan durasi, maka biayanya akan meningkat secara drastis. Namun, jika Anda menyelesaikan proyek dalam jangka waktu yang lebih lama dari perkiraan, maka hampir tidak ada penurunan nilai perkiraan biaya.
Dengan demikian, kita dapat mempertimbangkan bahwa COCOMO upaya dan nilai durasi untuk menunjukkan berikut ini. Nilai upaya dan durasi yang dihitung oleh COCOMO adalah nilai untuk menyelesaikan pekerjaan dalam waktu singkat tanpa terlalu meningkatkan biaya tenaga kerja.
Sekarang mari kita uraikan pernyataan di atas. Ketika tim proyek terdiri dari satu anggota, anggota tersebut tidak akan pernah menganggur karena kekurangan pekerjaan, tetapi proyek akan memakan waktu terlalu lama untuk diselesaikan. Di sisi lain, ketika ada terlalu banyak anggota, proyek akan selesai dalam waktu yang jauh lebih singkat, tetapi seringkali selama durasi proyek beberapa anggota harus menganggur karena kekurangan pekerjaan.
Durasi proyek seperti yang dihitung oleh model COCOMO, semua developer tetap sibuk dengan pekerjaan selama seluruh periode pengembangan. Setiap kali proyek harus diselesaikan dalam waktu yang lebih pendek dari perkiraan durasi dengan menggunakan COCOMO, beberapa waktu menganggur di pihak developer akan ada. Waktu menganggur seperti itu akan menghasilkan peningkatan biaya pengembangan. Sebuah tim berukuran optimal untuk sebuah proyek adalah tim di mana setiap developer setiap saat selama pengembangan tidak duduk diam menunggu pekerjaan, tetapi pada saat yang sama terdiri dari anggota sebanyak mungkin untuk mengurangi waktu pengembangan. Kita bisa menganggap durasi yang diberikan oleh COCOMO disebut sebagai durasi optimal. Disebut durasi optimal, jika proyek diupayakan selesai dalam waktu yang lebih singkat, maka upaya yang dibutuhkan akan meningkat dengan cepat. Ini mungkin tampak sebagai paradoks— bagaimanapun juga, ini adalah produk yang sama yang akan dikembangkan, meskipun dalam waktu yang lebih singkat, lalu mengapa upaya yang diperlukan harus meningkat dengan cepat? Hal ini dapat dijelaskan dengan fakta bahwa untuk setiap produk pada titik mana pun selama pengembangan proyek, ada batasan jumlah aktivitas paralel yang dapat diidentifikasi dan dilaksanakan secara bermakna. Jadi, jika lebih banyak developer dikerahkan daripada ukuran optimal, beberapa developer harus menganggur, karena pada titik tertentu dalam pengembangan atau lainnya, tidak mungkin untuk menugaskan mereka pekerjaan sama sekali. Waktu menganggur ini akan muncul sebagai upaya yang lebih tinggi dan biaya yang lebih besar.
Estimasi ukuran staf
Mengingat estimasi untuk upaya pengembangan proyek dan waktu pengembangan nominal, dapatkah tingkat staf yang dibutuhkan ditentukan dengan pembagian sederhana dari estimasi upaya dengan estimasi durasi? Jawabannya adalah tidak". Ini akan menjadi resep yang sempurna untuk penundaan proyek dan kelebihan biaya.
Contoh 3.2 Asumsikan bahwa ukuran produk perangkat lunak tipe organik telah diperkirakan 32.000 baris kode sumber. Asumsikan bahwa gaji rata-rata seorang developer perangkat lunak adalah Rp. 15.000.000 per bulan. Tentukan upaya yang diperlukan untuk mengembangkan produk perangkat lunak, waktu pengembangan nominal, dan biaya untuk
mengembangkan produk. Dari rumus dasar estimasi COCOMO untuk perangkat lunak organik:
Upaya = 2,4 × (32)1,05 = 91 PM. Waktu pengembangan nominal = 2,5 × (91)0,38 = 14 bulan Biaya staf yang dibutuhkan untuk mengembangkan produk = 91 × Rp. 15.000.000 = Rp.
1.465.000.000
COCOMO Menengah
Model dasar COCOMO mengasumsikan bahwa usaha dan waktu pengembangan adalah fungsi dari ukuran produk saja. Namun, sejumlah parameter proyek lain selain ukuran produk mempengaruhi upaya serta waktu yang dibutuhkan untuk mengembangkan produk.
Misalnya upaya untuk mengembangkan suatu produk akan bervariasi tergantung pada kecanggihan lingkungan pengembangan. Oleh karena itu, untuk mendapatkan estimasi yang akurat dari upaya dan durasi proyek, efek dari semua parameter yang relevan harus diperhitungkan. Model COCOMO perantara mengakui fakta ini dan menyempurnakan perkiraan awal. Model COCOMO perantara menyempurnakan perkiraan awal yang diperoleh dengan menggunakan ekspresi COCOMO dasar dengan meningkatkan atau menurunkan perkiraan berdasarkan evaluasi serangkaian atribut pengembangan perangkat lunak.
Model COCOMO perantara menggunakan satu set 15 driver biaya (pengganda) yang ditentukan berdasarkan berbagai atribut pengembangan perangkat lunak. Penggerak biaya ini dikalikan dengan perkiraan biaya dan upaya awal (diperoleh dari COCOMO dasar) untuk menaikkan atau menurunkannya secara tepat. Misalnya, jika praktik pemrograman modern digunakan, perkiraan awal diperkecil dengan perkalian dengan pemicu biaya yang memiliki nilai kurang dari 1. Jika ada persyaratan keandalan yang ketat pada produk perangkat lunak, perkiraan awal ditingkatkan. Boehm mengharuskan manajer proyek untuk menilai 15 parameter yang berbeda untuk proyek tertentu pada skala satu sampai tiga. Untuk setiap penilaian parameter proyek seperti itu, dia telah menyarankan pemicu biaya (atau pengganda) yang sesuai untuk menyempurnakan perkiraan awal. Secara umum, pemicu biaya yang diidentifikasi oleh Boehm dapat diklasifikasikan sebagai atribut dari item berikut:
• Produk: Karakteristik produk yang dipertimbangkan meliputi kompleksitas yang melekat pada produk, persyaratan keandalan produk, dll.
• Komputer: Karakteristik komputer yang dipertimbangkan termasuk kecepatan eksekusi yang dibutuhkan, ruang penyimpanan yang dibutuhkan, dll.
• Personil: Atribut personel pengembangan yang dipertimbangkan meliputi tingkat pengalaman personel, kemampuan pemrograman mereka, kemampuan analisis, dll.
• Lingkungan pengembangan: Atribut lingkungan pengembangan menangkap fasilitas pengembangan yang tersedia untuk pengembang. Parameter penting yang diperhatikan adalah kecanggihan alat otomatisasi (CASE) yang digunakan untuk pengembangan perangkat lunak.
Kita hanya membahas ide-ide dasar di balik model COCOMO perantara. Sebuah diskusi rinci tentang model COCOMO menengah berada di luar cakupan buku ini dan pembaca yang tertarik dapat merujuk [Boehm81].
COCOMO Lengkap
Kelemahan utama dari model COCOMO dasar dan menengah adalah bahwa mereka menganggap produk perangkat lunak sebagai satu kesatuan yang homogen. Namun, sebagian besar sistem besar terdiri dari beberapa sub-sistem yang lebih kecil. Sub-sistem ini seringkali memiliki karakteristik yang sangat berbeda. Sebagai contoh, beberapa sub-sistem dapat dianggap sebagai tipe organik, beberapa semi-terpisah, dan beberapa bahkan tertanam. Tidak hanya kompleksitas pengembangan yang melekat pada subsistem yang berbeda, tetapi untuk beberapa subsistem persyaratan keandalan mungkin tinggi, untuk beberapa tim
pengembangan mungkin tidak memiliki pengalaman pengembangan serupa sebelumnya, dan seterusnya.
Model COCOMO yang lengkap mempertimbangkan perbedaan karakteristik subsistem ini dan memperkirakan upaya dan waktu pengembangan sebagai jumlah perkiraan untuk masing-masing subsistem. Dengan kata lain, biaya untuk mengembangkan setiap sub-sistem diperkirakan secara terpisah, dan biaya sistem yang lengkap ditentukan sebagai biaya subsistem. Pendekatan ini mengurangi margin kesalahan dalam estimasi akhir. Mari kita perhatikan proyek pengembangan berikut sebagai contoh penerapan model COCOMO yang lengkap. Produk sistem informasi manajemen terdistribusi (MIS) untuk organisasi yang memiliki kantor di beberapa tempat di seluruh negeri dapat memiliki sub-komponen berikut:
• Bagian basis data
• Bagian antarmuka pengguna grafis (GUI)
• Bagian komunikasi
Dari jumlah tersebut, bagian komunikasi dapat dianggap sebagai perangkat lunak tertanam. Bagian database dapat berupa perangkat lunak semi-terpisah, dan bagian GUI perangkat lunak organik. Biaya untuk ketiga komponen ini dapat diperkirakan secara terpisah, dan dijumlahkan untuk memberikan biaya keseluruhan sistem.
Untuk lebih meningkatkan akurasi hasil, nilai parameter yang berbeda dari model dapat disesuaikan dan divalidasi terhadap database proyek historis organisasi untuk mendapatkan estimasi yang lebih akurat. Model estimasi seperti COCOMO tidak sepenuhnya akurat dan tidak memiliki justifikasi ilmiah yang lengkap. Namun, model estimasi biaya perangkat lunak seperti COCOMO diperlukan untuk pendekatan rekayasa untuk manajemen proyek perangkat lunak. Perusahaan menganggap perkiraan biaya yang dihitung memuaskan, jika ini berada dalam kisaran sekitar 80 persen dari biaya akhir. Meskipun perkiraan ini adalah perkiraan kasar — tanpa model seperti itu, seseorang hanya memiliki penilaian subjektif untuk diandalkan.