COCOMO (Cost Constructive Model)

Sejarah Singkat Cocomo

COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W. ’s Book ekonomi Software engineering sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyek-proyek ukuran mulai dari 2.000 sampai 100.000 baris kode, dan bahasa pemrograman mulai dari perakitan untuk PL / I. Proyek-proyek ini didasarkan pada model pengembangan perangkat lunak waterfall yang merupakan proses software umum pembangunan di 1981.
Referensi untuk model ini biasanya menyebutnya COCOMO 81. Pada tahun 1997 COCOMO II telah dikembangkan dan akhirnya diterbitkan pada tahun 2000 dalam buku Estimasi Biaya COCOMO II Software dengan COCOMO II. adalah penerus dari COCOMO 81 dan lebih cocok untuk mengestimasi proyek pengembangan perangkat lunak modern. Hal ini memberikan lebih banyak dukungan untuk proses pengembangan perangkat lunak modern, dan basis data proyek diperbarui. Kebutuhan model baru datang sebagai perangkat lunak teknologi pengembangan pindah dari batch processing mainframe dan malam untuk pengembangan desktop, usabilitas kode dan penggunaan komponen software off-the-rak. Artikel ini merujuk pada COCOMO 81.

Pengertian Cocomo

COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasar estimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rincian tambahan COCOMO account untuk pengaruh fase proyek individu.

Estimasi biaya dan waktu
  • Top down (analogi histori dan informasi): dari analisa bisnis sampai ke detail.
  • Bottom up: dari estimasi masing-masing aktivitas proyek dikumpulkan secara total.
  • Model matematis.
  • Software tools.

Perlu diingat dalam SW metodologi bahwa:
Biaya (cost) tidak sebanding linear dengan jumlah code yang akan diprogram (size).

Dasar perhitungan:
effort = C x sizeM 

  • Dikenal sebagai Constructive Cost Model (COCOMO), model konstruksi biaya. 
  • C dan M adalah koefisien konstanta ( > 1 ), targantung pada tipe proyek dan organisasi, dengan cara melihat Tabel Konstanta (sudah tersedia dari penelitian).
  • Ditentukan pula oleh: application experience, leadership capability, new environment and tools, requirements uncertainty, software reuse. 

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
1. Proyek organik (organic mode) Adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.
2. Proyek sedang (semi-detached mode)Merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda
3. Proyek terintegrasi (embedded mode)Proyek yang dibangun dengan spesifikasi dan operasi yang ketat

Model Jenis Cocomo

Ada tiga model cocomo, yaitu :

  • Basic (COCOMO I 1981), Menghitung dari estimasi jumlah FP dan LOC; FP = suatu unit pengukuran untuk keterhubungan dan keterkaitan antar prosedur, fungsi dan lingkungan SW
  • Intermediate (COCOMO II 1999), Menghitung dari besarnya program dan “cost drivers” (faktor-faktor yang berpengaruh langsung kepada proyek), spt: hardware, personnel, dan atribut-atribut proyek;
  • Advanced, Memperhitungkan semua karakteristik dari “intermediate”  di atas dan “cost drivers” dari setiap fase (analisis, design, implementation, etc) dlm SW life cycles; 

Basic COCOMO

* (E = effort ) = Ca x (size=KLOC=kilo line of code) Ma
(satuan: ManMonth (Person Month) = 152 jam kerja) 
* (D = duration) = Cb x E Mb
(satuan: Month)

* Productivity = size / E (satuan: KLOC/Man Month)

* Average staffing = E / D (satuan: FTE = Full Time Employees  jumlah orang yang bekerja penuh dalam 1 hari kerja ~ 8 jam )

1: Menghitung estimasi informasi nilai domain  count total;
2: Menyesuaikan kompleksitas proyek berdasarkan faktor pemberat  dan “cost drivers” kemudian menghitung estimasi jumlah Function Points  unit of measure that represent functions required by the user.  
    FP = count total * [0.65 + 0.01 * ∑ Fi];
3: Menghitung estimasi LOC (Line of Code). Tekniknya sama dengan PERT Calculation (three points estimation);
EV = (Sopt + 4 Sm + Spess) / 6;
Atau menghitung LOC / FP dari tabel berdasar pada bahasa pemrograman;
4: Memilih kompleksitas proyek (menentukan C dan M), dari organic, embedded atau semi-detached system mode.
5: Menghitung E dan D  estimasi biaya dan waktu.

  • Input pemakai: setiap input data dari user yang dipakai untuk menjalankan aplikasi.
  • Output pemakai: setiap hasil output dari proses yang ditampilkan kepada user.
  • Inquiry pemakai: setiap on-line input yang menghasilkan responsi software secara langsung.
  • Jumlah file: setiap master file yang menjadi bagian dari aplikasi.
  • Eksternal interface: setiap interface (sarana) eksternal yang menyalurkan informasi dari sistem satu ke sistem lainnya.


Ada 14 pos kompleksitas faktor (cost drivers), yaitu:
  1. Backup dan recovery
  2. Komunikasi data
  3. Proses terdistribusi
  4. Kepentingan performa
  5. Keberadaan lingkungan operasi
  6. Online data entry
  7. Input melalui bbrp tampilan/operasi
  8. Peng-update-an file master secara online
  9. Kompleksitas nilai ‘domain’ (tahap1) diatas
  10. Kompleksitas proses internal aplikasi
  11. Perulangan (reuse) penggunaan code
  12. Ketersediaan rancangan untuk konversi dan instalasi
  13. Rancangan untuk pengulangan instalasi di lingkungan yg berbeda
  14. Fleksibiltas bagi pemakai

Kesemuanya ini dihitung berdasarkan nilai dari 0-5 menunjukkan perkiraan nilai kepentingan 
(No Influence, Incidental, Moderate, Average, Significant, Essential)

Software Project    Ca    Ma     Cb     Mb 
Organic                   2.4    1.05   2.5    0.38      
Semi-detached       3.0    1.12   2.5    0.35      
Embedded               3.6    1.20   2.5    0.32
Organic = kecil, sederhana (co, pembuatan situs mandiri untuk perusahaan);
Semi-detached = menengah (co. transaksi sistem pada database sebuah bank);
Embedded = kompleksitas tinggi, ketergantungan pada lingkungan aplikasi lainnya (co. aplikasi pengontrolan pada pesawat terbang). 

Source :

Created by : Rizka Hasmulyawan 16110104 (4 KA 20)

Tidak ada komentar:

Posting Komentar