Sebuah proyek dikatakan berhasil apabila sistem tersebut bisa diserahkan tepat waktu, sesuai antara biaya dan kualitas yang diinginkan. Hal tersebut menandakan bahwa apa yang ditargetkan manajer proyek telah bisa dicapat. Meski target yang dibuat manajer proyek masuk akal, tapi tidak memperhitungkan catatan level produktivitas timnya, kemungkinan tidak akan bisa memenuhi deadline dikarenakan estimasi awal yang salah. Oleh karenanya, perkiraan yang realistik menjadi kebutuhan yang sangat krusial bagi seorang manajer proyek. Beberapa kendala estimasi sangat dipengaruhi oleh karakteristik perangkat lunak (software), khususnya kompleksitas dan hal-hal lain yang tidak kasat mata. Juga kegiatan SDM yang terlibat dalam pengembangan sistem tidak bisa diperhitungkan secara pasti dengan menggunakan cara-cara yang mekanistik. Belum lagi kesulitan lain yang menghalangi keberhasilan proyek perangkat lunak, sepert :
- Aplikasi perangkat lunak yang diusulkan : beberapa proyek mirip biasanya dikembangkan berdasarkan pengalaman sebelumnya. Padahal proyek perangkat lunak memiliki sifat yang unik sehingga sering ada hal-hal yang tidak terduga dan penuh ketidakpastian.
- Perubahan teknologi : perubahan bahasa pemrograman yang digunakan bisa menghambat waktu selesainya proyek.
- Kurang homoginnya pengalaman proyek : estimasi akan efektif bila dibuat berdasarkan proyek-proyek sebelumnya, hanya saja banyak perusahaan yang menyembunyikan data proyek-proyek sebelumnya dari para staf.
- Subyektifitas estimasi : orang cenderung berlaku under-estimate terhadap kesulitan dari pekerjaan-pekerjaan kecil dan ber bertindak over-estime pada proyek-proyek besar yang dianggap lebih komplek dan sulit.
- Implikasi Politik : kelompok berbeda dalam sebuah organisasi bisa memiliki tujuan berbeda. Manajer pengembang sistem informasi mungkin akan menekan pada bagian ‘estimator’ untuk mengurangi estimasi harga berdasarkan anjuran atasannya. Sedangkan pada bagian pemeliharaan berharap tidak terjadi pembengkaan biaya dan keterlambatan waktu penyerahan agar citranya tidak jelek. Sebagai jalan tengahnya, estimasi sebaiknya dibuat oleh tim khusus yang bersifat independen dari penngguna maupun tim proyek.
A. Dimana Estimasi Dilakukan ?
Estimasi bisa dilakukan pada tahapan yang berbeda dalam proyek perangkat lunak. Namun setiap tahap memiliki alasan dan metode estimasi yang berbeda-beda. Adapun tahapan dimana estimasi bisa dilakukan, antara lain :
- Perencanaan Strategis (strategic planning)
- Studi kelayakan (feasibility study)
- Spesifikasi Sistem (system specification)
- Evaluasi proposal supplier (evaluation of supplier’ proposals)
- Perencanaan Poyek (project planning)
Dua hal yang perlu diperhatikan :
- Karena proyek sedang berjalan, akurasi estimasi harus bisa memperbaiki pengetahuan tentang peningkatan proyek aslinya.
- Pada awal proyek, kebutuhan user merupakan hal yang sangat penting, sehingga pertimbangan yang tergesa-gesa pada implementasi fisik harus dihindari.
B. Problema ‘Over-Estimate’ Dan ‘Under-Estimate’
Estimasi yang berlebihan bisa menyebabkan waktu penyelesaian proyek molor dari biasanya. Hal ini bisa dijelaskan menggunakan hukum :
- Parkinson’s Law : ‘work expands to fill the time available’. Bila staf diberi target yang mudah akan bekerja kurang keras.
- Hukum Brooks’ Law : ‘ Putting more people on a late job makes it later’. Biaya yang diperlukan untuk mewujudkan sebuah proyek akan meningkat secara tidak proporsional terhadap jumlah staf yang dipekerjakan. Bila estimasi biaya yang diperlukan berlebihan menyebabkan jumlah staf yang dialokasikan lebih banyak dari yang diperlukan dan overhead manajemen akan meningkat.
C. Dasar Estimasi Perangkat Lunak
- Kebutuhan data historis : memerlukan informasi bagaimana proyek yang telah diimplementasikan sebelumnya, terutama bahasa pemrograman dan tool yang digunakan, standar yang dipakai dan pengalaman staf.
- Metrik pekerjaan: biasanya tidak mungkin menghitung langsung harga aktual atau waktu yang diperlukan untuk merealisasikan proyek. Waktu yang dipakai untuk menulis program bisa berbeda sesuai kompetensidan pengalaman software developer. Secara praktis, untuk mengukur volume pekerjaan didasarkan pada jumlah source lines of code (SLOC) atau function points.
- Kompleksitas : Telah banyak usaha yang dilakukan untuk mengukur kompleksitas secara obyektif, namun seringkali akan tergantung penilaian subyektif estimatornya.
D. Teknik-Teknik Estimasi Biaya Perangkat Lunak
- Algorithmic models : menggunakann ‘effort driver’ yang menggambarkan karakteristik dari sistem target dan lingkungan implementasi untuk memprediksi biaya.
- Expert judgement : dimana nasehat staf yang memiliki kemampuan sangat diharapkan
- Analogy : kemiripan, kelengkapan, proyek diidentifikasi dan biaya aktualnya digunakan sebagai dasar estimasi proyek baru.
- Parkinson : mengidentifikasi kelayakan biaya staf untuk mengerjakan proyek dan menggunakannya sebagai estimasi (bukan merupakan metode prediksi biaya yang sebenarnya).
- Price to win : estimasi harus kelihatan cukup rendah untuk memenangkan kontrak.
- Top-down: keseluruhan estimasi diformulasikan untuk keseluruhan proyek yang kemudian dipecah ke dalam usaha yang diperlukan untuk komponen-komponen tugas.
- Bottom-up : komponen-komponen tugas diidentifikasi, diukur dan dilakukan estimasi sendiri-sendiri untuk kemudian dijumlahkan
Estimasi Bottom-Up
Pendekatan bottom-up memecah proyek ke dalam komponen-komponen tugasnya dan kemudian menghitung berapa banyak biaya yang diperlukan untuk menyelesaikan setiap tugas tersebut. Untuk proyek besar, proses pemecahan akan berulang hingga mendapatkan komponen yang bisa dieksekusi oleh satu orang selama 1 hingga 2 minggu. Setiap komponen tugas dianalisa hingga komponen sub tugasnya, yang menghasilkan Work Breakdown Schedule (WBS). Bagian bottom-up muncul ketika terjadi penjumlahan biaya yang dihitung dari setiap aktifitas untuk memperoleh estimasi keseluruhan. Pendekatan ini lebih cocok digunakan di bagian akhir tahap perencanaan proyek. Jika digunakan pada awal siklus proyek, beberapa karakteristik sistem final harus diasumsikan.
Pendekatan Top-Down dan Model Parametrik
Pendekatan top-down normalnya dihubungkan dengan dengan model parametric (algoritma). Biaya yang diperlukan untuk implementasi proyek akan dikaitkan terutama dengan variabel yang berhubungan karakteristik sistem final. Bentuk dari model parametrik biasanya berupa satu atau lebih formula dalam bentuk :
Effort = (system size) x (productivity rate) …….(1)
Suatu model untuk memperkirakan biaya pengembangan perangkat lunak memiliki 2 komponen utama. Pertama, metode untuk menaksir ukuran pekerjaan pengembangan perangkat lunak (software) dan menaksir laju pekerjaan yang berhasil dikerjakan. Beberapa model parametrik (seperti Function Point ) berfokus pada sistem maupun ukuran pekerjaan, sementara metode lain (seperti COCOMO) lebih berkonsentrasi pada faktor produktifitas.
E. Experd Judgement
Metode ini digunakan ketika melakukan estimasi biaya yang diperlukan untuk mengubah sebagian software yang masih eksis. Estimator akan memberikan beberapa analisis dampak berdasarkan pendapat yang proporsional dengan kode yang ditambahkan. Seseorang yang telah terbiasa dengan software tersebut yang lebih tepat untuk mengerjakannya.
F. Estimasi Dengan Analogi
Penggunaan analogi disebut juga case-based reasoning. Estimator mencari proyek-proyek yang telah selesai dikerjakan (sumber) yang memiliki karakteristik hampir sama untuk referensi proyek baru (target). Biaya yang telah dilaporkan yang sesuai dengan kasus sumber dapat dijadikan pijakan estimasi proyek target. Estimator kemudian melakukan identifikasi perbedaan sistem target dengan sumber, selanjutnya menetapkan estmasi dasar untuk menghasilakan estimasi biaya proyek baru. Masalahnya adalah bagaimana mengidentifikasi kemiripan dan perbedaan yang sesungguhnya pada aplikasi yang berbeda, khususnya bila ada banyak proyek masa lampau sebagai gambaran. Untuk mengidentifikasi sumber yang paling dekat dengan target biasanya menggunakan ukuran jarak Euclidian :
Distance = square-root of ((target_parameter1 – source_parameter1)2 + …. + (target _parametern – source_parametern)2) …….(2)
G. Albrecht Function Point Analysis
Albrecht telah melakukan investigasi terhadap produktifitas pemrograman dan diperlukan beberapa cara menghitung ukuran fungsional program yang independen terhadap bahasa pemroghraman yang telah dikodekan. Ide yang dikembangkan disebut function pont (FP). Dasar analisa function point adalah lima komponen utama (external user type) :
- External input type : transaksi input untuk meng-update file komputer internal.
- External output type : transaksi data yang di-outputkan ke user, khususnya print-out laporan dan tidak termasuk yang di-displaykan ke layar monitor (termasuk external inquiry type)
- Logical internal file type : file yang dipakai oleh sistem, berupa grup data yang biasanya dipakai bersama-sama.
- External interface file type : mengikuti input dan output yang melewatkan aplikasi dari dan ke komputer lain.
- External inquire type : transaksi yang diajukan oleh user yang memberikan informasi tetapi tidak meng-update file internal.
Analis harus mengidentifikasi setiap external user type dalam sistem yang diproyekkan. Setiap komponen kemudian diklasifikasi kompleksitasnya dalam high, average ataupun low. Setiap external user type kemudian dikalikan dengan bobot tertentu (tabel 1) untuk mendapatkan skor function point (FP) yang dijumlahkan dengan keseluruhan FP yang mengindikasikan ukuran pemrosesan informasi. Problema FP versi Albrecht bahwa pengelompokan external user type bersifat subyektif sehingga The International FP User Group (IFPUG) perlu merumuskan aturan penilaian seperti dalam tabel 2, 3 dan 4.
| No | External User Type | Multiplier | ||
| Low | Average | High | ||
| 1 | External input type | 3 | 4 | 6 |
| 2 | External output type | 4 | 5 | 7 |
| 3 | Logical internal file type | 7 | 10 | 15 |
| 4 | External interface file type | 5 | 7 | 10 |
| 5 | External inquiry type | 3 | 4 | 6 |
Tabel 1. Bobot Kompleksitas Albrecht
| No | Number of record types | Number of data types | ||
| < 20 | 20 – 50 | > 50 | ||
| 1 | 1 | Low | Low | Average |
| 2 | 2 to 5 | Low | Average | High |
| 3 | > 5 | Average | High | High |
Tabel 2 Kompleksitas Tipe File IFPUG
Eksternal IFPUG
| No | Number of file type accessed | Number of data types | ||
| < 5 | 5 to 15 | > 15 | ||
| 1 | 0 or 1 | Low | Low | Average |
| 2 | 2 | Low | Average | High |
| 3 | > 2 | Average | High | High |
Tabel 3 Kompleksitas Input
| No | Number of file type | Number of data types | ||
| < 6 | 6 – 19 | > 19 | ||
| 1 | 0 or 1 | Low | Low | Average |
| 2 | 2 or 3 | Low | Average | High |
| 3 | > 3 | Average | High | High |
Tabel 4 Kompleksitas Output Eksternal IFPUG
H. Function point Mark II
Metode Mark II mengadakan perbaikan dan penggantian metode Albrect (IFPUG). Sama seperti Albrecht, ukuran pemrosesan informasi pertama-tama diukur dalam Unadjusted Function Point (UFP) yang mana Technical Complexity Adjusment (TCA) dapat diaplikasikan. Diasumsikan bahwa, sebuah sistem informasi terdiri dari transaksi yang mempunyai struktur dasar sbb:
Gambar 1. Model Suatu Transaksi
Jika sebuah sistem informasi terdiri dari transaksi-transaksi yang memiliki struktur dasar seperti gambar 1, maka setiap transaksi UFP dihitung sbb : Wi x (number of input data element types) + We x (number of entity types referenced) +Wo x (number of output data element types) …….(3) Dimana Wi, We dan Wo adalah bobot yang diperoleh dari permintaan developer yang proporsional dengan biaya yang telah dikeluarkan proyek pengembangan software sebelumnya pada bagian tersebut yang sepakat dengan pemrosesan input, akses, modifikasi penyimpanan data dan pemrosesan output. Jika metode FP ‘Original Albrecht’ mengidentifikasi 14 faktor pengaturan kompleksitas secara teknis, Mark II menambah 5 faktor lagi, yaitu :
- Interface to other applications
- Special security features
- Direct acces for third parties
- User training features
- Documentation requirements
Jika ada gambaran besarnya biaya yang dikeluarkan pada proyek sebelumnya dan juga ukuran sistemnya (FP), maka besarnya laju produktifitas bisa dipecahkan dengan menggunakan rumus :
Productivity = size/ effort …….(4)
Untuk proyek baru , besarnya FP dapat dihitung dan kemudian biaya dapat diproyeksikan menggunakan laju produktifitas sbb :
Effort = size / productivity …….(5)
Lebih bagus lagi, jika digunakan metode statistik yang disebut least squares regression dengan menggunakan persamaan :
Effort = constant1 + (size x constant2) …….(6)
I . COSMIC Full Function Points
Penggunaan pendekatan FP efektif digunakan pada organisasi yang mempunyai akses informasi historis tentang proyek-proyek masa lampau, khusus perihal FP untuk setiap proyek dan biaya aktual yang diperlukan. Metode pendekatan seperti IFPUG cocok untuk sistem informasi, tetapi kurang membantu untuk aplikasi ukuran real-time atau aplikasi yang telah canggih, maka the Common Software Measurement Consorsium (COSMIC) memasukkan tidak hanya versi originalnya tetapi juga versi lain menjadi the COSMIC FFP method. COSMIC sepakat dengan kebutuhan analis untuk memecah arsitektur sistem ke dalam hirarki lapisan software. Komponen software diukur dan menerima permintaan layanan dari lapisan diatasnya dan bisa meminta layanan di bawahnya. Di saat yang sama, ada juga komponen software terpisah yang berada dalam level sama yang dihubungkan dalam peer-to-peer communication. Hal ini membantu identifikasi batas komponen software yang diakses, jumlah input yang diterima dan transmisi output. Input dan output dikumpulkan dalam data-group, dimana setiap group membawa item data bersama yang berkaitan dengan obyek yang sama. Grup data dapat dipindahkan lewat 4 cara ;
- Entri (E) : dipengaruhi oleh sub-proses yang memindahkan grup data ke dalam komponen software atas permintaan user di luar lingkupnya, bisa dari lapisan lain atau komponen software terpisah yang lain dalam lapisan yang sama lewat peer-to-peer communication.
- Exit (X) : dipengaruhi oleh subproses yang memindahkan grup data dari komponen software ke user yang berada di luar batasan.
- Read (R) : gerakan data yang memindahkan group data dari storage tetap ke dalam komponen software.
- Write
: Perpindahan data yang mentransfer group data dari komponen software ke dalam storage tetap.
Jumlah keseluruhan FFP diperoleh dari penjumlahan sederhana keempat tipe perpindahan data. Unit yang dihasilkan disebut Cfsu (COSMIC functional size units). Metode ini tidak menghitung lagi pemrosesan data yang pernah dipindahkan sekali ke komponen software.
J. Procedural Code-Oriented Approach
Pendekatan yang dibahas sebelumnya berguna pada tahap desain proyek dimana bahasa pemrograman prosedural tidak merupakan sarana utama untuk pengembangan. Bagaimanapun biaya pengembangan modul software individual bisa diestimasi menggunakan pendekatan bahasa prosedural, dengan step-step sebagai berikut :
1. Pertimbangkan jumlah dan tipe modul software dalam sistem final.
Yang paling mudah, dimana merupakan sistem konvensional yang telah dipahami secara baik. Semua sistem informasi dibangun dari satu set operasi kecil seperti Insert, Amend, Update, Display, Delete, Print. Prinsip yang sama bisa diterapkan pada sistem terintegrasi (embedded), walaupun fungsi primitifnya berbeda.
2. Estimasikan jumlah SLOC setiap program teridentifikasi.
Estimator harus memilih bahasa implementasi tertentu. Untuk menaksir jumlah instruksi menggunakan bahasa tersebut, dengan cara menggambar diagram struktur program dan memvisualisasikan berapa banyak instruksi yang diperlukan untuk implementasi setiap prosedur teridentifikasi. Estimator mungkin harus melihat program eksisting yang mempunyai kemiripan deskripsi fungsional untuk membantu proses ini.
3. Estimasikan isi pekerjaan yang dimasukkan dalam perhitungan kompleksitas dan kesulitan modul.
Prakteknya dengan mengalikan estimasi SLOC dengan faktor kompleksitas dan kesulitan teknik. Faktor ini sangat tergantung pada penilaian subyektif estimator. Pembobotan diperlukan ketika ada hal-hal yang tak bisa dipastikan, namun jangan berlebihan.
4. Hitung biaya hari kerja
Data historis dapat digunakan untuk memberi rasio bobot biaya SLOC. Faktor konversi sering didasarkan produktifitas ‘standard programmer’ (kira berpengalaman 15 – 18 bulan)
K. COCOMO (Sebuah Model Parametrik)
COnstructive COst MOdel (COCOMO) diperkenalkan oleh Boehm di akhir tahun 70-an hasil kajian dari 63 proyek. Model yang diusulkan bisa digunakan untuk aplikasi lain (selain sistem informasi). Model dasar yang digunakan mendekati persamaan berikut :
Effort = c (size)k …(7)
Dimana :
Effort : jumlah ‘person-month’ (pm)
Size : thousands of delivered source code instructions (kdsi)
COCOMO mengelompokkan sistem dan lingkungan pengembangannya menjadi 3 :
- Organic mode: apabila software dikembangkan oleh tim yang relatif kecil dalam lingkungan yang sangat familier dan ketika sistem akan dikembangkan sedikit, kebutuhan interface yang diperlukan cukup fleksibel.
- Embedded-mode : produk yang dikembangkan harus beroperasi dengan spesifikasi yang tepat dan bila terjadi perubahan sistem sangat memakan biaya.
- Semi-detached mode: kombinasi elemen organik dan embedded-mode dan memiliki karakteristik antara keduanya.
Tabel 5. Konstanta COCOMO
| System Type | c | k |
| Organic | 2,4 | 1,05 |
| Semi-detached | 3,0 | 1,12 |
| Embedded | 3,6 | 1,20 |
Karena versi pertama dianggap kurang bagus, Boehm mengembangkan COCOMO versi intermediate dengan memasukkan 15 cost driver seperti tabel 6.
| Driver Type | Code | Cost Driver |
| Product attributes | RELY | Required software reliability |
| DATA | Database size | |
| CPLX | Product complexity | |
| Computer attributes | TIME | Execution time constraints |
| STOR | Main storage constraints | |
| VIRT | Virtual machine volatile-degree to which the operating system changes | |
| TURN | Computer turnaround time | |
| Personnel attributes | ACAP | Analyst capability |
| AEXP | Application experience | |
| PCAP | Programmer capability | |
| VEXP | Virtual machine volatility (missal : OS) experience | |
| LEXP | Programming language experience | |
| Project attributes | MODP | Use of modern programming practices |
| TOOL | Use of software tools | |
| SCED | Required development schedule |
Tabel 6. COCOMO81 Intermediate Cost Drivers Pada model intermediate, estimasi biaya nominal (pmnom) diturunkan sama dengan pada model dasar (basic). Sedangkan estimasi nominal kemudian diatur dengan pengali biaya pengembangan (dem) sehingga rumus pmest menjadi :
(pmest) = (pmest) x (dem) ….(8)
dimana dem dihitung dari bobot pengali berdasarkan biaya effort driver (tabel 6). Model COCOMO sendiri terus dikembangkan, yang terbaru disebut model COCOMO II. Mengingat estimasi diperlukan pada tahapan yang berbeda-beda dalam siklus hidup sistem, maka COCOMO II telah didesain untuk mengakomodasi hal tersebut dengan menyiapkan model untuk tiga tahapan yang berbeda :
- Komposisi Aplikasi (application composition)
Fitur eksternal dari sistem yang diperlukan oleh pengguna didesain. Prototipe yang khas akan digunakan untuk mengerjakannya. Dengan aplikasi kecil yang dapat dibangun menggunakan application building tool, pengembangan dapat berhenti pada poin ini.
- Desain awal (early design)
Struktur software dasar didesain. Dengan meluasnya permintaan, misalnya adanya peningkatan volume transaksi dan unjuk kerja menjadi penting, perhatian yang cermat perlu diberikan untuk arsitektur yang diadopsi.
- Arsitektur akhir (Post architecture)
Struktur software mendekati struktur final, modifikasi dan pengaturan untuk memperbaiki sistem seperti yang diinginkan masih dimungkinkan.
Estimasi biaya untuk komposisi aplikasi, jumlah poin obyek direkomendasi oleh pengembang COCOMO II. Hal ini mengikuti pendekatan function point dari perhitungan fitur nyata eksternal dari software. Hal ini berbeda dengan fokus pada fitur aplikasi fisik, seperti layar dan laporan dari pada fitur logikal seperti tipe-tipe entitas. Pada tahap desain awal, function point direkomendasi sebagai cara pengukuran ukuran sistem dasar. Sebuah FP mungkin dikonversikan ke dalam ekuivalen LOC dengan mengalikan FP dengan sebuah faktor untuk bahasa pemrograman yang diogunakan. Model berikut dapat digunakan untuk menghitung estimasi person-month :
Pm = A (size) (sf) x (em1) x (em2) x … x (emn) ……(9)
Dimana :
pm : biaya dalam ‘person-month’
A : konstanta
Size : jumlah FP (kdsi)
sf : eksponen faktor skala
Sedangkan faktor skala diturunkan dari rumus berikut :
sf = 1,01 + 0,01 x ∑ (exponent driver ratings) ……(10)
Kenyataannya bahwa faktor-faktor yang digunakan untuk menghitung sebuah eksponen menunjukkan rendahnya kualitas akan meningkatkan biaya yang diperlukan tidak proporsional lebih besar pada proyek yang lebih luas.
- Precedentedness : Menunjukkan derajat lebih diutamakan, mirip dengan kasus masa lalu, untuk proyek yang sedang direncanakan. Makin banyak hal-hal baru pada sistem baru, makin besar ketidakpastian dan semakin tinggi nilai yang diberikan exponent driver.
- Development flexibility : Menunjukkan derajat dimana kebutuhan dapat ditentukan dalam banyak cara yang berbeda. Hal ini kurang fleksibel dan semakin tinggi nilai exponent driver.
- Architecture/risk resolution : Berkaitan dengan derajat ketidakpastian tentang kebutuhan. Jika ada yang tidak meyakinkan (tidak tepat) dan dimungkinkan berubah maka besarnya exponent driver bernilai tinggi.
- Team cohesion : Memperlihatkan kondisi dimana semakin banyak tim yang dibubarkan karena bertentangan dengan tim yang yang kaitannya erat sekali.
- Process maturity : Makin terstruktur dan terorganisasi software yang dihasilkan, makin rendah ketidakpastian dan makin rendah pula rating untuk exponent driver. Dalam model COCOMO II, pengali biaya (em) sama dengan pengali biaya pengembangan (dem) yang digunakan dalam original-COCOMO. Ada 7 pengali yang relevan dengan desain awal dan kemudian menjadi 16 yang dapat digunakan pada arsitektur akhirnya.
Tabel 7. COCOMO II Early Design Effort Multipliers
| No | Code | Effort Modifier |
| 1 | RCPX | Product reliability and complexity |
| 2 | RUSE | Required reusability |
| 3 | PDIF | Platform difficulty |
| 4 | PERS | Personnel capability |
| 5 | PREX | Personnel experience |
| 6 | FCIL | Facilities available |
| 7 | SCED | Schedule pressure |
Tabel 8. COCOMO II Post Architecture Effort Multipliers
| Modifier Type | Code | Effort Modifier |
| Product Attributes | RELY | Required software reliability |
| DATA | Database size | |
| DOCU | Documentation match to life-cycle needs | |
| CPLX | Product complexity | |
| REUSE | Required reuseability | |
| Platform Attributes | TIME | Execution time constraint |
| STOR | Main storage constraint | |
| PVOL | Platform volatility | |
| Personnel Attributes | ACAP | Analyst capabilities |
| AEXP | Application experience | |
| PCAP | Programmer capabilities | |
| PEXP | Platform experience | |
| LEXP | Programming language experience | |
| PCON | Personnel continuity | |
| Project Attributes | TOOL | Use of software tools |
| SITE | Multisite development | |
| SCED | Schedule pressure |
Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa digunakan untuk aplikasi tertentu pada kondisi very low, low, manual, nominal, high maupun very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1 menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database.
Yayuk05's Weblog 
