DESIGN TERSTRUKTUR

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 :

1. 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.
2. Perubahan teknologi : perubahan bahasa pemrograman yang digunakan bisa menghambat waktu selesainya proyek.
3. 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.
4. 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.
5. 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 :

1. Perencanaan Strategis (strategic planning)
2. Studi kelayakan (feasibility study)
3. Spesifikasi Sistem (system specification)
4. Evaluasi proposal supplier (evaluation of supplier’ proposals)
5. 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

1. Kebutuhan data historis : memerlukan informasi bagaimana proyek yang telah diimplementasikan sebelumnya, terutama bahasa pemrograman dan tool yang digunakan, standar yang dipakai dan pengalaman staf.
2. 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.    
3. 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 jarakEuclidian  : 

Distance = square-root of ((target_parameter₁ – source_parameter₁)² + …. + (target _parameter_n – source_parameter_n)²)                                                   …….(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.
 Tabel 1.  Bobot  Kompleksitas Albrecht

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 2 Kompleksitas Tipe File IFPUG  Eksternal IFPUG

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

        

  

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

Untuk proyek baru , besarnya FP dapat dihitung dan kemudian biaya dapat diproyeksikan menggunakan laju produktifitas sbb :       

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 : W_i x (number of input data element types) + W_e x (number of entity types referenced) +W_o x (number of output data element types)                                …….(3)  Dimana W_i, W_e dan W_o 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) 

Effort =          size / productivity                                                   …….(5) 

Lebih bagus lagi, jika digunakan metode statistik yang disebut least squares regression dengan menggunakan persamaan :

Effort  =         constant₁ + (size x constant₂)                             …….(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 ;

1. 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.
2. Exit (X) : dipengaruhi oleh subproses yang memindahkan grup data dari komponen software ke user yang berada di luar batasan.
3. Read (R) : gerakan data yang memindahkan group data dari  storage tetap ke dalam komponen software.
4. Write (W) : 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 (pm_nom) diturunkan sama dengan pada model dasar (basic). Sedangkan estimasi nominal kemudian diatur dengan pengali biaya pengembangan (dem)  sehingga rumus pm_est  menjadi :                  

(pm_est)  =  (pm_est)  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 (em₁) x (em₂) x … x (em_n)                               ……(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. 

Posted in: