27
Nov
07

Estimasi Biaya Perangkat Lunak

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 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:        

g4.jpg

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 ;

  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 (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.    

About these ads

0 Responses to “Estimasi Biaya Perangkat Lunak”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: