Model COCOMO Dijelaskan: Rumus, Jenis, dan Estimasi Biaya Perangkat Lunak

Pernahkah Anda ditanya berapa lama sebuah proyek perangkat lunak akan selesai dan menyadari bahwa jawaban terbaik Anda pada dasarnya hanyalah tebakan?

Begitulah sebagian besar tim mendekati estimasi biaya rekayasa perangkat lunak pada 1970-an. Proyek sering melampaui anggaran dan tenggat waktu, dan metode yang digunakan—kebanyakan penilaian ahli dan analogi kasar—tidak bertahan ketika sistem menjadi lebih besar dan kompleks.

COCOMO dibangun untuk memperbaikinya. Singkatan dari COnstructive COst MOdel. Barry W. Boehm memperkenalkannya dalam buku tahun 1981 berjudul Software Engineering Economics, dengan mendasarkan rumus pada data proyek nyata, bukan intuisi. Ini menjadi salah satu model estimasi algoritmik yang paling banyak diajarkan di bidang tersebut. Boehm, yang wafat pada Agustus 2022, menghabiskan puluhan tahun menyempurnakan gagasan di baliknya.

Dalam tutorial ini, saya akan memandu Anda memahami cara kerja model, apa arti berbagai jenis dan tingkatannya, serta menjalankan contoh numerik lengkap agar angka-angkanya masuk akal dalam praktik.

Apa Itu Model COCOMO dalam Rekayasa Perangkat Lunak?

COCOMO adalah model estimasi biaya perangkat lunak parametrik. Model ini mengambil satu masukan utama, yaitu perkiraan ukuran proyek perangkat lunak yang diukur dalam ribuan baris kode (KLOC), dan menggunakannya untuk memprediksi tiga hal: total upaya dalam person-month (PM), waktu pengembangan dalam bulan, dan jumlah orang yang dibutuhkan.

Model ini mengasumsikan bahwa ukuran proyek adalah prediktor utama upaya. Boehm membangun konstanta model dengan menjalankan analisis regresi pada data proyek historis yang nyata.

Perlu dicatat, COCOMO tidak memperkirakan biaya moneter secara langsung. Model ini memperkirakan upaya. Untuk mengonversi person-month menjadi dolar, Anda mengalikan dengan biaya tenaga kerja rata-rata per person-month di organisasi Anda. Model memberi Anda upaya; Anda yang menyediakan tarifnya.

Alasan Model COCOMO Dikembangkan

Boehm bekerja sebagai Director of Software Research and Technology di TRW Aerospace, dan frustrasinya bersifat langsung dan praktis. Menurut sebuah tribut yang kemudian diterbitkan oleh National Academy of Engineering, seorang wakil presiden TRW mengatakan kepada Boehm setelah meninjau penawaran perangkat lunak kompetitif: "Saya tidak ingin lagi harus menyetujui penawaran perangkat lunak hanya berdasarkan keyakinan. Pergi dan ciptakan cara yang kredibel untuk memperkirakan biaya pengembangan produk perangkat lunak."

Permintaan itu menjadi COCOMO. Boehm mempelajari 63 proyek yang telah selesai di TRW, mencakup perangkat lunak dari 2.000 hingga 100.000 baris kode, ditulis dalam bahasa mulai dari assembly hingga PL/I, semuanya dibangun dengan model waterfall. Analisis regresi pada dataset tersebut menghasilkan konstanta yang digunakan dalam COCOMO I, dan model tersebut dipublikasikan pada 1981.

Rumus Model COCOMO dan Cara Kerjanya

Matematika di balik Basic COCOMO I sederhana begitu Anda memahami apa yang diwakili setiap istilah.

Rumus upaya adalah:

Di sini, upaya diukur dalam person-month, KLOC adalah perkiraan ukuran perangkat lunak dalam ribuan baris kode, dan a serta b adalah konstanta yang bergantung pada jenis proyek yang Anda kerjakan.

Rumus waktu pengembangan mengikuti dari estimasi upaya:

Konstanta d bervariasi menurut mode, sedangkan c tetap 2,5 di ketiga mode. Banyak tutorial yang keliru dengan menyiratkan keempat konstanta berubah. Setelah Anda memiliki Effort dan , Anda dapat memperkirakan jumlah orang rata-rata yang diperlukan:

Tabel di bawah ini menunjukkan konstanta terverifikasi untuk Basic COCOMO I:

Variabel kunci di sini adalah b. Untuk proyek Organic, b = 1,05, yang berarti upaya bertambah hampir linear dengan ukuran proyek. Untuk proyek Embedded, b = 1,20, yang menciptakan diseconomy of scale yang signifikan: melipatgandakan ukuran proyek embedded lebih dari melipatgandakan upaya yang diperlukan.

Jenis Model COCOMO (COCOMO I)

COCOMO I mengategorikan proyek perangkat lunak ke dalam tiga mode pengembangan. Setiap mode mencerminkan kombinasi berbeda dari pengalaman tim, kompleksitas proyek, dan kendala operasional. Mode yang Anda pilih menentukan konstanta mana yang digunakan dalam rumus Anda.

Perlu dicatat sejak awal: tiga mode ini hanya berlaku untuk COCOMO I. COCOMO II, pembaruan tahun 2000, menggantinya dengan pendekatan berbeda.

Tiga mode COCOMO I dibandingkan secara visual. Gambar oleh Penulis.

Ketiga mode berada pada skala peningkatan kompleksitas dan kendala. Jenis proyek dan konteks tim Anda biasanya akan membuatnya jelas mana yang berlaku.

Mode Organic

Mode Organic mencakup proyek kecil hingga menengah di mana tim memiliki pengalaman yang solid dengan domain aplikasi, persyaratan relatif mudah dipahami, dan tidak ada tekanan eksternal signifikan dari kendala perangkat keras atau persyaratan regulasi. Sistem penggajian, aplikasi pemrosesan data, atau alat manajemen inventaris umumnya termasuk di sini.

Karena tim berpengalaman dan domainnya familier, beban komunikasi tetap rendah bahkan saat proyek berkembang. Itulah mengapa eksponen b adalah yang terkecil dari ketiga mode.

Mode Semi-detached

Mode Semi-detached berada di tengah. Tim dalam kategori ini memiliki pengalaman campuran: beberapa anggota sangat memahami domainnya, sementara yang lain tidak. Proyek memiliki kompleksitas sedang, dan mungkin ada interaksi dengan perangkat keras baru atau sistem eksternal.

Pengembangan compiler, sistem pemrosesan transaksi, dan aplikasi bisnis tingkat menengah adalah contoh umum. Diseconomy of scale lebih terasa di sini, dengan b = 1,12.

Mode Embedded

Mode Embedded berlaku untuk proyek dengan kendala operasional ketat: persyaratan perangkat keras yang kaku, tuntutan pemrosesan real-time, standar regulasi, atau persyaratan kedirgantaraan dan pertahanan. Tim mungkin besar dan terampil secara teknis, tetapi kompleksitas integrasi, pengujian, dan validasi mendorong upaya meningkat tajam seiring bertambahnya ukuran proyek.

Dengan b = 1,20, proyek embedded memiliki diseconomy of scale paling curam dari ketiga mode. Mode Embedded juga bukan tentang ukuran proyek. Bahkan sistem embedded yang relatif kecil termasuk jika beroperasi di bawah kendala yang berat.

Basic vs. Intermediate vs. Detailed COCOMO

Di luar tiga mode proyek, COCOMO I memiliki tiga tingkat detail estimasi. Mode memberi tahu Anda konstanta mana yang digunakan; tingkat memberi tahu Anda seberapa dalam pemodelan proyek. Setiap tingkat dibangun di atas yang sebelumnya dengan menambahkan lebih banyak faktor ke perhitungan, yang meningkatkan akurasi dengan biaya kebutuhan data masukan yang lebih banyak.

Bayangkan sebagai spektrum: Basic COCOMO memberi Anda perkiraan cepat, sementara Detailed COCOMO memungkinkan perencanaan presisi di tingkat fase.

Tingkat COCOMO I berdasarkan kedalaman detail estimasi. Gambar oleh Penulis.

Semakin ke bawah piramida menambah lebih banyak faktor ke perhitungan, yang meningkatkan akurasi tetapi juga memerlukan lebih banyak data input untuk memulai.

Basic COCOMO

Basic COCOMO hanya menggunakan ukuran proyek dalam KLOC dan mode proyek. Anda memasukkan KLOC, menerapkan konstanta untuk mode yang dipilih, dan mendapatkan estimasi upaya. Ini berguna untuk penilaian kelayakan awal ketika Anda belum memiliki informasi rinci tentang tim atau lingkungan pengembangan.

Intermediate COCOMO

Intermediate COCOMO memperkenalkan Effort Adjustment Factor, biasanya ditulis sebagai EAF. Daftar lengkap pengali penggerak biaya didokumentasikan dalam COCOMO II Model Definition Manual. Rumus upaya menjadi:

Nilai EAF adalah hasil kali dari 15 penggerak biaya, masing-masing dinilai pada skala dari Very Low hingga Extra High. Penggerak tersebut terbagi dalam empat kategori: atribut produk (keandalan, kompleksitas, ukuran basis data), atribut perangkat keras (kendala waktu eksekusi dan penyimpanan), atribut personel (pengalaman dan kapabilitas tim), dan atribut proyek (alat, tekanan jadwal, dan praktik pengembangan).

Satu hal yang perlu diketahui tentang Intermediate COCOMO: konstanta a berubah dari nilai Basic. Untuk mode Organic, a menjadi 3,2 (bukan 2,4). Untuk mode semi-detached, tetap 3,0. Untuk mode Embedded, turun menjadi 2,8. Eksponen b, c, dan d tetap sama di kedua tingkat Basic dan Intermediate.

Penggerak biaya personel bersifat terbalik: kapabilitas yang lebih tinggi berarti pengali yang lebih kecil, yang menurunkan estimasi upaya. Tim programmer berpengalaman memang tidak membutuhkan person-month sebanyak tim pemula untuk menyelesaikan proyek.

Detailed COCOMO

Detailed COCOMO, kadang disebut Advanced COCOMO, menerapkan pengali upaya pada tingkat fase individual, bukan di seluruh proyek. Ini berarti penggerak biaya untuk analisis kebutuhan, desain terperinci, pengodean, serta integrasi dan pengujian dievaluasi secara terpisah.

Ini adalah tingkat yang paling akurat, dan juga paling memakan waktu untuk digunakan. Masuk akal untuk proyek besar di mana tim berbeda menangani fase berbeda dan distribusi upaya lintas fase penting untuk perencanaan.

COCOMO II: Versi Modern

Pada pertengahan 1990-an, COCOMO I mulai ketinggalan zaman. Pengembangan perangkat lunak telah bergeser dari proyek waterfall di mainframe ke pemrograman berorientasi objek, pustaka komponen yang dapat digunakan ulang, pembuatan prototipe cepat, dan sistem desktop terdistribusi. Menerapkan data proyek 1970-an ke lingkungan perangkat lunak 1990-an menghasilkan estimasi yang tidak andal.

Boehm dan rekan-rekannya di USC Center for Software Engineering menghabiskan beberapa tahun membangun ulang model dari nol. Hasilnya adalah COCOMO II, diterbitkan pada 2000 dalam buku Software Cost Estimation with COCOMO II, yang dikalibrasi terhadap dataset berisi 161 proyek, lebih dari dua kali lipat 63 proyek dari model asli.

Motivasi di balik COCOMO II adalah pengembangan berbasis objek dan komponen, penggunaan ulang perangkat lunak dan integrasi produk komersial siap pakai, model pengembangan iteratif dan spiral, serta perangkat modern. Satu kesalahpahaman umum yang perlu diluruskan: COCOMO II tidak dibangun untuk Agile. Agile seperti yang kita kenal sekarang hampir belum ada saat model ini dikembangkan dari 1995 hingga 2000.

Tiga sub-model COCOMO II

COCOMO II menawarkan tiga sub-model, masing-masing cocok untuk fase berbeda dalam siklus hidup proyek.

Application Composition Model dirancang untuk pembuatan prototipe awal, khususnya ketika tim menggunakan pembuat GUI dan pustaka komponen. Alih-alih KLOC, model ini menggunakan Object Points: layar, laporan, dan komponen bahasa generasi ketiga yang diberi bobot berdasarkan kompleksitas dan disesuaikan untuk penggunaan ulang yang diharapkan. Ini adalah model linear tanpa faktor skala atau penyesuaian eksponensial.

Early Design Model digunakan sebelum arsitektur ditetapkan. Model ini mengambil Unadjusted Function Points sebagai masukan, mengonversinya ke baris kode sumber ekuivalen menggunakan tabel spesifik bahasa, dan menerapkan tujuh penggerak biaya. Model ini memberikan estimasi yang masuk akal ketika Anda tahu apa yang harus dilakukan sistem tetapi belum tahu bagaimana cara membangunnya.

Post-Architecture Model adalah yang paling ketat di antara ketiganya. Model ini digunakan setelah arsitektur perangkat lunak ditetapkan, menggunakan Thousands of Source Lines of Code (KSLOC) atau function points sebagai masukan, 17 penggerak biaya, dan lima faktor skala. Rumus upayanya adalah:

Di mana E adalah eksponen dinamis yang dihitung sebagai:

Dan rumus jadwal adalah:

Di mana:

Konstanta 2,94, 0,91, 3,67, dan 0,28 berasal dari kalibrasi COCOMO II.2000. Beberapa sumber lama menyebutkan 2,5 alih-alih 2,94; itu adalah nilai kalibrasi pra-2000 dan tidak boleh digunakan dengan model saat ini. USC COCOMO II Web Tool di softwarecost.org adalah implementasi gratis dan langsung dari model Post-Architecture jika Anda ingin menjalankan estimasi tanpa menghitung manual.

Penggerak Biaya dan Faktor Skala dalam COCOMO

Dua mekanisme membuat COCOMO II bekerja berbeda dari COCOMO I: faktor skala dan penggerak biaya. Berikut fungsi masing-masing.

Dalam COCOMO I, eksponen b ditetapkan berdasarkan mode: Anda memilih Organic, semi-detached, atau Embedded, dan mendapatkan angka preset. COCOMO II menggantinya dengan lima faktor skala yang dinilai secara kontinu yang menghitung eksponen berdasarkan cara Anda menilai masing-masing.

Kelima faktor skala dalam COCOMO II adalah precedentedness (PREC), fleksibilitas pengembangan (FLEX), arsitektur dan resolusi risiko (RESL), kohesi tim (TEAM), dan kematangan proses (PMAT). Masing-masing dinilai pada skala dari Very Low hingga Extra High, dan jumlah gabungannya menentukan E dalam rumus upaya. Jumlah yang lebih tinggi berarti proyek yang kurang matang, kurang familier, lebih berisiko, yang berarti eksponen lebih tinggi dan upaya lebih besar.

Faktor skala memengaruhi bentuk kurva upaya. Sebaliknya, penggerak biaya adalah penyesuaian multiplicative yang diterapkan pada upaya dasar. COCOMO II memiliki 17 penggerak biaya dalam model Post-Architecture, dibandingkan 15 pada Intermediate COCOMO I. Penambahan dalam COCOMO II mencakup faktor untuk kebutuhan reusability (RUSE), persyaratan dokumentasi (DOCU), volatilitas platform (PVOL), kontinuitas personel (PCON), pengalaman aplikasi (APEX), pengalaman platform (PLEX), pengalaman bahasa dan alat (LTEX), dan pengembangan multisitus (SITE).

Satu penggerak biaya yang patut disorot adalah SCED, yang mencakup jadwal pengembangan yang dibutuhkan. Jika Anda memperpendek jadwal secara signifikan, pengali upaya naik di atas 1,0, yang berarti Anda justru membutuhkan person-month lebih banyak untuk menyelesaikan lebih cepat. Ini sejalan dengan sesuatu yang sudah diketahui sebagian besar insinyur dari pengalaman: memaksa tim untuk sprint menimbulkan beban koordinasi, kesalahan, dan pengerjaan ulang yang sering kali biayanya lebih besar daripada waktu yang dihemat.

Keunggulan Model COCOMO

Kekuatan utama model ini adalah transparansi. Tidak seperti alat estimasi proprietari, COCOMO memublikasikan semua persamaan, konstanta, dan metodologi kalibrasinya. Siapa pun dapat mengaudit input dan memverifikasi output. Ini membuatnya berguna dalam pengadaan pemerintah, pertahanan, dan kedirgantaraan, di mana keterauditan matematis sering menjadi persyaratan hukum atau kontraktual.

Model ini juga dapat dikalibrasi ulang. Organisasi yang mengumpulkan data riwayat proyeknya sendiri dapat menyesuaikan konstanta agar mencerminkan lingkungan spesifik mereka, komposisi tim, dan tumpukan teknologi. Ini penting karena konstanta default berasal dari dataset yang kini sudah beberapa dekade berlalu.

Struktur tiga tingkat (Basic → Intermediate → Detailed) adalah manfaat praktis lainnya. Di awal proyek, ketika sedikit yang diketahui, Anda menggunakan Basic untuk perkiraan kasar. Seiring proyek matang dan lebih banyak dipahami tentang tim dan lingkungan, Anda beralih ke Intermediate atau Detailed untuk perencanaan yang lebih terperinci.

Keterbatasan Model COCOMO

Keterbatasan terbesar adalah ketergantungan COCOMO pada KLOC. Untuk menggunakan COCOMO, Anda perlu memperkirakan ukuran proyek dalam baris kode sebelum menulis kode apa pun. Pada tahap awal proyek—tepat saat estimasi paling penting—ini terkenal sulit dilakukan secara akurat.

Bahkan ketika KLOC dapat diperkirakan, konstanta dalam COCOMO I berasal dari 63 proyek yang dibangun dengan model waterfall antara 1968 dan 1979. Konstanta dalam COCOMO II berasal dari 161 proyek dari 1990-an. Tidak satu pun dataset tersebut mencakup sistem cloud-native, aplikasi seluler, arsitektur microservices, atau pipeline DevOps modern. Menerapkan konstanta ini langsung ke proyek modern tanpa kalibrasi lokal menghasilkan estimasi yang tidak andal.

Sebuah studi tahun 2025 memberikan angka untuk ini. Basic COCOMO yang tidak dikalibrasi diterapkan pada dataset proyek NASA menghasilkan rata-rata kesalahan relatif sekitar 100%, tanpa ada prediksi yang berada dalam 25% dari upaya aktual. Itu bukan margin kesalahan kecil; itu mencerminkan model yang digunakan di luar kondisi tempat model tersebut dibangun.

Model ini juga tidak menangani pengembangan iteratif dengan baik. COCOMO mengasumsikan siklus hidup yang cukup berurutan. Tim Agile yang bekerja dalam sprint pendek dengan backlog yang berkembang tidak sesuai dengan asumsi waterfall yang tertanam dalam struktur COCOMO.

Ada juga masalah yang lebih dalam. Sebuah makalah yang diterbitkan di Frontiers in Artificial Intelligence pada Maret 2026 berargumen bahwa COCOMO II pada dasarnya tidak selaras dengan pengembangan perangkat lunak yang dibantu AI, bukan hanya soal kalibrasi tetapi secara struktural. Ketika alat pengodean AI menghasilkan porsi substansial dari basis kode, KLOC sebagai proksi untuk upaya manusia menjadi menyesatkan. Upaya kini berpusat pada verifikasi, tata kelola arsitektur, dan tinjauan keamanan, yang tidak dirancang untuk ditangkap oleh kerangka penggerak biaya COCOMO.

Model COCOMO vs. Teknik Estimasi Lain

COCOMO bukan satu-satunya opsi. Mengetahui alternatif membantu Anda memilih pendekatan yang tepat untuk situasi tertentu.

Function Point Analysis (FPA) mengukur kompleksitas sistem dari masukan dan keluaran yang menghadap pengguna, terlepas dari bahasa pemrograman. Ini bekerja dengan baik ketika Anda memiliki persyaratan yang solid tetapi belum ada estimasi KLOC. Model Early Design COCOMO II menerima function point sebagai masukan, sehingga keduanya dapat digunakan bersama.

Story Point adalah standar di lingkungan Agile. Tim menilai user story berdasarkan kompleksitas relatif, lalu melacak velocity untuk memproyeksikan progres. Ini cepat dan spesifik untuk tim, tetapi tidak menghasilkan baseline total biaya yang diperlukan pengadaan dan perencanaan jangka panjang. COCOMO dan story point melayani tujuan yang berbeda.

Alat parametrik seperti SEER-SEM dan SLIM menggunakan basis data kalibrasi proprietari dan himpunan parameter yang lebih luas. Studi menemukan bahwa alat tersebut mengungguli COCOMO II yang tidak dikalibrasi dalam hal akurasi. Keunggulan COCOMO adalah transparansi dan ketersediaan terbuka, yang penting dalam konteks akademik atau yang dapat diaudit.

Estimasi berbasis machine learning adalah area riset yang aktif. Sebuah studi Januari 2026 menemukan bahwa model ensemble yang menggabungkan random forest, support vector regression, dan neural network mengungguli model keluarga COCOMO pada data proyek Agile di keempat metrik evaluasi standar. Pendekatan ini beradaptasi dengan data latihannya alih-alih bergantung pada konstanta yang ditetapkan beberapa dekade lalu.

Contoh Model COCOMO (Perhitungan Lengkap)

Mengetahui posisi COCOMO relatif terhadap metode lain berguna, tetapi cara terbaik untuk memahami bagaimana model ini benar-benar bekerja adalah dengan menjalankan angkanya. Mari kita telusuri perhitungan Basic COCOMO I lengkap menggunakan mode Organic dan proyek yang diperkirakan sebesar 50 KLOC.

Konstanta untuk mode Organic adalah: a = 2,4, b = 1,05, c = 2,5, d = 0,38.

Langkah 1: Hitung upaya

Untuk menghitung 50^1.05, gunakan fakta bahwa .

Langkah 2: Hitung waktu pengembangan

Langkah 3: Hitung jumlah orang yang dibutuhkan

Ringkasan:

Ada dua hal yang patut dicatat. Person-month dan bulan kalender adalah satuan yang berbeda: 145,8 person-month selama 16,6 bulan kalender berarti kira-kira 9 orang bekerja secara paralel. Dan karena ini adalah Basic COCOMO, model ini hanya menggunakan ukuran dan mode. Menambahkan penilaian penggerak biaya nyata melalui EAF akan menggeser estimasi upaya naik atau turun dari sana.

Model COCOMO dalam Wawancara Rekayasa Perangkat Lunak

COCOMO muncul dalam mata kuliah akademik, ujian universitas, dan wawancara untuk peran di pemerintahan, pertahanan, dan rekayasa sistem. Model ini jarang muncul di perusahaan teknologi konsumen yang agile.

Pertanyaan yang paling umum adalah COCOMO I versus COCOMO II: mode tetap dan konstanta preset dari 63 proyek versus lima faktor skala kontinu pada dataset modern yang lebih besar. Mengetahui perbedaan itu, rumus dasar, dan tiga nama mode mencakup sebagian besar skenario. Pewawancara sesekali meminta contoh perhitungan, jadi contoh kerja di atas layak untuk dilatih.

Kesimpulan: Apakah Model COCOMO Masih Relevan?

COCOMO tetap berguna di tempat asumsi-asumsinya berlaku: pengembangan berurutan, pengadaan formal, dan kajian akademis. Di tempat perangkat lunak modern menyimpang dari kondisi tersebut, model ini tidak lagi memadai.

Gunakan Basic COCOMO untuk pemeriksaan cepat skala ordo awal proyek. Gunakan Intermediate COCOMO ketika Anda memiliki data tim dan lingkungan untuk dikerjakan. Kalibrasikan ke riwayat proyek Anda sendiri sebelum mengandalkan keluaran apa pun dalam penawaran atau rencana nyata. Seperti yang saya bahas di bagian Keterbatasan, menerapkan konstanta default ke proyek modern tanpa kalibrasi menghasilkan kesalahan yang terlalu besar untuk dijadikan dasar tindakan.

COCOMO III telah dikembangkan di Boehm CSSE sejak sekitar 2015, tanpa rilis publik per Maret 2026. Versi asli 1981 dan pembaruan 2000 tetap menjadi tolok ukur.

Ingin melangkah lebih jauh dengan pengembangan perangkat lunak? Kami memiliki kursus tentang Prinsip Rekayasa Perangkat Lunak di Python, Pengembangan Perangkat Lunak dengan Cursor, dan Pengembangan Perangkat Lunak dengan GitHub Copilot untuk membantu Anda membangun keterampilan yang telah Anda pelajari di sini.