COCOMO Modeli Açıklandı: Formül, Türler ve Yazılım Maliyet Tahmini

Hiç bir yazılım projesinin ne kadar süreceği sorulduğunda, verebileceğiniz en iyi yanıtın aslında bir tahminden ibaret olduğunu fark ettiniz mi?

1970’lerde çoğu ekip yazılım mühendisliği maliyet tahminine böyle yaklaşıyordu. Projeler düzenli olarak bütçeyi ve teslim tarihlerini aşıyor; kullanılan yöntemler—çoğunlukla uzman görüşü ve kabaca benzetimler—sistemler büyüyüp karmaşıklaştıkça yetersiz kalıyordu.

COCOMO bunu düzeltmek için geliştirildi. Açılımı COnstructive COst MOdel’dir. Barry W. Boehm, 1981 tarihli Software Engineering Economics adlı kitabında modeli tanıttı ve formülleri sezgiye değil gerçek proje verilerine dayandırdı. Bu, alandaki en yaygın öğretilen algoritmik tahmin modellerinden biri haline geldi. Ağustos 2022’de vefat eden Boehm, modelin ardındaki fikirleri onlarca yıl boyunca geliştirdi.

Bu eğitimde, modelin nasıl çalıştığını, farklı tür ve seviyelerin ne anlama geldiğini adım adım anlatacağım ve rakamların pratikte anlam kazanması için tam bir sayısal örnek yapacağım.

Yazılım Mühendisliğinde COCOMO Modeli Nedir?

COCOMO, parametrik bir yazılım maliyet tahmin modelidir. Birincil olarak bir girdi alır: bir yazılım projesinin tahmini büyüklüğü (Bin Satır Kod, KLOC). Bunu kullanarak üç şeyi öngörür: toplam efor (kişi-ay, PM), geliştirme süresi (ay) ve gereken kişi sayısı.

Model, eforun başlıca belirleyicisinin proje büyüklüğü olduğunu varsayar. Boehm, modelin sabitlerini gerçek tarihsel proje verileri üzerinde regresyon analizi yaparak oluşturdu.

Bununla birlikte, COCOMO parasal maliyeti doğrudan tahmin etmez. Eforu tahmin eder. Kişi-ayı dolara çevirmek için, kuruluşunuzdaki kişi-ay başına ortalama işçilik maliyetiyle çarparsınız. Model size eforu verir; ücreti siz belirlersiniz.

COCOMO Modelinin Geliştirilme Nedeni

Boehm, TRW Aerospace’te Yazılım Araştırma ve Teknoloji Direktörü olarak çalışıyordu ve sorun hem acil hem de pratikti. Ulusal Mühendislik Akademisi’nin daha sonra yayımladığı bir anı yazısına göre, TRW’de bir başkan yardımcısı, rekabetçi bir yazılım teklifi incelendikten sonra Boehm’e şunu söylemiş: "Sırf inanca dayanarak bir yazılım teklifini bir daha onaylamak zorunda kalmak istemiyorum. Bir yazılım ürününü geliştirmenin maliyetini güvenilir şekilde tahmin edecek bir yöntem icat et."

Bu talep COCOMO’ya dönüştü. Boehm, TRW’de tamamlanmış 63 projeyi inceledi; 2.000’den 100.000’e kadar kod satırı içeren, assembly’den PL/I’a kadar farklı dillerde yazılan ve tamamı şelale modeline göre geliştirilmiş yazılımlardı. Bu veri kümesi üzerinde yapılan regresyon analizi, COCOMO I’de kullanılan sabitleri üretti ve model 1981’de kamuya açıldı.

COCOMO Modeli Formülü ve Nasıl Çalışır

Temel COCOMO I’in arkasındaki matematik, her terimin neyi temsil ettiğini anladığınızda basittir.

Efor formülü şöyledir:

Burada efor kişi-ay cinsindendir, KLOC yazılım büyüklüğünün bin satır kod olarak tahminidir ve a ile b çalıştığınız proje türüne bağlı sabitlerdir.

Geliştirme süresi formülü, efor tahmininden türetilir:

d sabiti moda göre değişir, c ise üç modun tamamında 2.5 olarak sabittir. Birçok eğitim kaynağı, dört sabitin de değiştiğini ima ederek bunu yanlış aktarır. Efor ve değerlerini elde ettiğinizde, gereken ortalama kişi sayısını tahmin edebilirsiniz:

Aşağıdaki tablo, Temel COCOMO I için doğrulanmış sabitleri gösterir:

Buradaki temel değişken b’dir. Organik projelerde b = 1,05 olup eforun proje büyüklüğüyle neredeyse doğrusal arttığı anlamına gelir. Gömülü projelerde b = 1,20 olup belirgin bir ölçek ekonomisi kaybı yaratır: bir gömülü projenin büyüklüğünü ikiye katlamak, gereken eforu iki kattan fazla artırır.

COCOMO Modeli Türleri (COCOMO I)

COCOMO I, yazılım projelerini üç geliştirme moduna ayırır. Her mod, ekip deneyimi, proje karmaşıklığı ve operasyonel kısıtların farklı bir kombinasyonunu yansıtır. Seçtiğiniz mod, formüllerde kullanacağınız sabitleri belirler.

Şunu baştan belirtmekte fayda var: Bu üç mod yalnızca COCOMO I için geçerlidir. 2000 güncellemesi olan COCOMO II, bunların yerine farklı bir yaklaşım getirdi.

Üç COCOMO I modu görsel olarak karşılaştırıldı. Görsel: Yazar.

Bu üç mod, artan karmaşıklık ve kısıt ölçeğinde yer alır. Proje türünüz ve ekip bağlamınız genellikle hangisinin uygulanacağını netleştirir.

Organik mod

Organik mod, ekibin uygulama alanında sağlam deneyime sahip olduğu, gereksinimlerin nispeten iyi anlaşıldığı ve donanım kısıtları ya da düzenleyici gerekliliklerden ciddi bir dış baskının olmadığı küçük ve orta ölçekli projeleri kapsar. Bordro sistemi, veri işleme uygulaması veya envanter yönetim aracı genellikle bu kategoriye girer.

Ekip deneyimli ve alan tanıdık olduğundan, proje büyüse bile iletişim yükü düşük kalır. Bu yüzden b üssü üç modun en küçüğüdür.

Yarı-bağımsız mod

Yarı-bağımsız mod orta noktadadır. Bu kategorideki ekipler karışık deneyime sahiptir: Bazı üyeler alanı iyi tanır, bazıları tanımaz. Projenin karmaşıklığı ortadır ve yeni donanım ya da harici sistemlerle bir miktar etkileşim olabilir.

Derleyici geliştirme, işlem işleme sistemleri ve orta katman ticari uygulamalar yaygın örneklerdir. Ölçek ekonomisi kaybı burada daha belirgindir; b = 1,12.

Gömülü mod

Gömülü mod, sıkı operasyonel kısıtları olan projelere uygulanır: katı donanım gereksinimleri, gerçek zamanlı işlem talepleri, düzenleyici standartlar veya havacılık ve savunma gereklilikleri. Ekip büyük ve teknik olarak yetkin olabilir; ancak entegrasyon, test ve doğrulamanın karmaşıklığı, proje büyüdükçe eforu keskin şekilde artırır.

b = 1,20 ile gömülü projeler üç mod arasında en dik ölçek ekonomisi kaybına sahiptir. Gömülü mod, proje büyüklüğüyle de ilgili değildir. Nispeten küçük bir gömülü sistem bile ağır kısıtlar altında çalışıyorsa bu kategoriye girer.

Temel vs. Orta vs. Ayrıntılı COCOMO

Üç proje modunun ötesinde, COCOMO I’in üç ayrıntı düzeyi vardır. Modlar hangi sabitleri kullanacağınızı söyler; seviyeler projeyi ne kadar derinlikte modelleyeceğinizi belirler. Her seviye, hesaba daha fazla faktör ekleyerek bir öncekini temel alır; bu da doğruluğu artırırken daha fazla girdi verisi gerektirir.

Bunu bir yelpaze gibi düşünün: Temel COCOMO hızlı bir yaklaşık değer verirken, Ayrıntılı COCOMO aşama bazlı hassas planlamaya imkân tanır.

Tahmin ayrıntı derinliğine göre COCOMO I seviyeleri. Görsel: Yazar.

Piramitten aşağı indikçe hesaba daha fazla faktör eklersiniz; bu doğruluğu artırır ancak başlamak için daha fazla girdi verisi gerektirir.

Temel COCOMO

Temel COCOMO yalnızca KLOC cinsinden proje büyüklüğünü ve proje modunu kullanır. KLOC’u girer, seçtiğiniz modun sabitlerini uygular ve bir efor tahmini elde edersiniz. Bu, henüz ekibiniz veya geliştirme ortamınız hakkında ayrıntılı bilgiye sahip olmadığınız erken fizibilite değerlendirmeleri için yararlıdır.

Orta (Intermediate) COCOMO

Orta düzey COCOMO, genellikle EAF olarak yazılan bir Efor Ayarlama Faktörü (Effort Adjustment Factor) tanıtır. Maliyet sürücü çarpanlarının tam listesi COCOMO II Model Tanım Kılavuzu’nda belgelenmiştir. Efor formülü şu hale gelir:

EAF , her biri Çok Düşük’ten Aşırı Yüksek’e kadar derecelendirilen 15 maliyet sürücüsünün çarpımından oluşur. Sürücüler dört kategoriye ayrılır: ürün öznitelikleri (güvenilirlik, karmaşıklık, veritabanı boyutu), donanım öznitelikleri (çalışma zamanı ve depolama kısıtları), personel öznitelikleri (ekip deneyimi ve yetkinliği) ve proje öznitelikleri (araçlar, zamanlama baskısı ve geliştirme uygulamaları).

Orta düzey COCOMO hakkında bilinmesi gereken bir nokta: a sabiti, Temel düzeydeki değerlerinden değişir. Organik mod için a 3,2 olur (2,4 değil). Yarı-bağımsız modda 3,0 olarak kalır. Gömülü modda ise 2,8’e düşer. b, c ve d üsleri ise Temel ve Orta düzeylerde aynıdır.

Personel maliyet sürücüleri ters yönde işler: daha yüksek yetkinlik daha küçük bir çarpan demektir; bu da efor tahminini düşürür. Deneyimli bir programcı ekibi, acemi bir ekibe kıyasla bir projeyi tamamlamak için doğal olarak daha az kişi-aya ihtiyaç duyar.

Ayrıntılı COCOMO

Ayrıntılı COCOMO, bazen Gelişmiş COCOMO olarak da anılır; efor çarpanlarını tüm proje yerine tek tek aşama düzeyinde uygular. Bu, gereksinim analizi, ayrıntılı tasarım, kodlama ve entegrasyon/test aşamaları için maliyet sürücülerinin ayrı ayrı değerlendirilmesi anlamına gelir.

Bu, en doğru düzeydir ve kullanımı en çok zaman alanıdır. Farklı ekiplerin farklı aşamalardan sorumlu olduğu ve aşamalar arası efor dağılımının planlama açısından önemli olduğu büyük projeler için anlamlıdır.

COCOMO II: Modern Sürüm

1990’ların ortalarına gelindiğinde COCOMO I yaşını belli ediyordu. Yazılım geliştirme, ana bilgisayarlardaki şelale projelerinden nesne yönelimli programlamaya, yeniden kullanılabilir bileşen kütüphanelerine, hızlı prototiplemeye ve dağıtık masaüstü sistemlerine kaymıştı. 1970’lerin proje verilerini 1990’ların yazılım ortamlarına uygulamak güvenilir olmayan tahminler üretiyordu.

Boehm ve USC Yazılım Mühendisliği Merkezi’ndeki meslektaşları modeli baştan inşa etmek için birkaç yıl harcadı. Sonuç, 2000 yılında yayımlanan Software Cost Estimation with COCOMO II kitabıyla duyurulan COCOMO II oldu; orijinal modeldeki 63 projeye kıyasla 161 projelik bir veri kümesine kalibre edildi.

COCOMO II’nin arkasındaki motivasyonlar; nesne yönelimli ve bileşen tabanlı geliştirme, yazılımın yeniden kullanımı ve hazır paket entegrasyonu, yinelemeli ve spiral geliştirme modelleri ile modern araçlamaydı. Yaygın bir yanılgıyı netleştirelim: COCOMO II, Agile geliştirme için oluşturulmadı. 1995–2000 arasında model geliştirilirken, bugün bildiğimiz anlamda Agile neredeyse yoktu.

COCOMO II’nin üç alt modeli

COCOMO II, bir projenin yaşam döngüsünün farklı aşamalarına uygun üç alt model sunar.

Uygulama Bileşimi Modeli, özellikle GUI oluşturucular ve bileşen kütüphaneleri kullanan ekiplerde erken prototipleme için tasarlanmıştır. KLOC yerine Nesne Puanları (Object Points) kullanır: ekranlar, raporlar ve karmaşıklıkla ağırlıklandırılmış, beklenen yeniden kullanım için ayarlanmış üçüncü nesil dil bileşenleri. Bu, ölçek faktörü veya üstel ayarlama içermeyen doğrusal bir modeldir.

Erken Tasarım Modeli, mimari belirlenmeden önce kullanılır. Girdi olarak Ayarlanmamış Fonksiyon Puanlarını alır; dil bazlı tablolardan eşdeğer kaynak kod satırlarına dönüştürür ve yedi maliyet sürücüsü uygular. Sistemin ne yapması gerektiğini bildiğiniz, fakat nasıl inşa edileceğini henüz bilmediğiniz durumda makul bir tahmin verir.

Mimari Sonrası Model, üçünün en kapsamlısıdır. Yazılım mimarisi netleştikten sonra kullanılır; girdi olarak Bin Kaynak Kod Satırı (KSLOC) veya fonksiyon puanlarını, 17 maliyet sürücüsünü ve beş ölçek faktörünü kullanır. Efor formülü şöyledir:

Burada E , şu şekilde hesaplanan dinamik bir üsttür:

Ve zamanlama (takvim) formülü şöyledir:

Burada:

2,94; 0,91; 3,67 ve 0,28 sabitleri, COCOMO II.2000 kalibrasyonundan gelir. Bazı eski kaynaklar 2,94 yerine 2,5 değerini verir; bu, 2000 öncesi kalibrasyon değeridir ve güncel modelle kullanılmamalıdır. USC COCOMO II Web Aracı softwarecost.org üzerinde, el ile hesap yapmadan Mimari Sonrası modelle tahmin yürütmek için ücretsiz ve canlı bir uygulamadır.

COCOMO’da Maliyet Sürücüleri ve Ölçek Faktörleri

COCOMO II’yi COCOMO I’den farklı kılan iki mekanizma vardır: ölçek faktörleri ve maliyet sürücüleri. İşte her birinin rolü.

COCOMO I’de b üssü modla sabittir: Organik, Yarı-bağımsız veya Gömülü’yü seçersiniz ve önceden ayarlanmış bir değer elde edersiniz. COCOMO II, bunu her birini nasıl derecelendirdiğinize bağlı olarak üstü hesaplayan, sürekli derecelendirilen beş ölçek faktörüyle değiştirir.

COCOMO II’deki beş ölçek faktörü: öncül olma düzeyi (PREC), geliştirme esnekliği (FLEX), mimari ve risk çözümü (RESL), ekip uyumu (TEAM) ve süreç olgunluğu (PMAT). Her biri Çok Düşük’ten Aşırı Yüksek’e kadar derecelendirilir ve toplamları efor formülündeki E’yi belirler. Daha yüksek toplam, daha az olgun, daha az tanıdık ve daha riskli bir proje demektir; bu da daha yüksek bir üs ve daha fazla efor anlamına gelir.

Ölçek faktörleri, efor eğrisinin şeklini etkiler. Buna karşılık maliyet sürücüleri, temel efora uygulanan çarpımsal ayarlamalardır. COCOMO II, Mimari Sonrası modelde 17 maliyet sürücüsüne sahiptir; COCOMO I’in Orta düzeyindeki 15’e kıyasla. COCOMO II’deki eklemeler arasında gerekli yeniden kullanılabilirlik (RUSE), dokümantasyon gereksinimleri (DOCU), platform oynaklığı (PVOL), personel sürekliliği (PCON), uygulama deneyimi (APEX), platform deneyimi (PLEX), dil ve araç deneyimi (LTEX) ve çoklu konumda geliştirme (SITE) bulunur.

Öne çıkarmaya değer bir maliyet sürücüsü SCED’dir; gerekli geliştirme zamanlamasını kapsar. Bir zamanlamayı önemli ölçüde sıkıştırırsanız, efor çarpanı 1,0’ın üzerine çıkar; bu da daha hızlı bitirmek için aslında daha fazla kişi-aya ihtiyaç duyacağınız anlamına gelir. Bu, çoğu mühendisin deneyimden bildiği bir şeyi doğrular: Ekipleri sürekli koşturtmak, koordinasyon yüküne, hatalara ve yeniden işe yol açar; bu da çoğu zaman kazanılan süreden daha pahalıya mal olur.

COCOMO Modelinin Avantajları

Modelin başlıca gücü şeffaflıktır. Mülki araçların aksine, COCOMO tüm denklemlerini, sabitlerini ve kalibrasyon metodolojisini yayımlar. Herkes girdileri denetleyebilir ve çıktıları doğrulayabilir. Bu, matematiksel denetlenebilirliğin yasal ya da sözleşmesel bir gereklilik olduğu kamu, savunma ve havacılık tedarikinde kullanışlıdır.

Model yeniden kalibre edilebilir. Kendi proje geçmişi verilerini toplayan kuruluşlar, sabitleri kendi özgül ortamlarını, ekip bileşimlerini ve teknoloji yığınlarını yansıtacak şekilde ayarlayabilir. Bu önemlidir; çünkü varsayılan sabitler artık onlarca yıl öncesine uzanan veri kümelerinden gelir.

Üç seviyeli yapı (Temel → Orta → Ayrıntılı) bir diğer pratik faydadır. Projenin başında, çok az şey bilinirken kabaca bir tahmin için Temel düzeyi kullanırsınız. Proje olgunlaştıkça ve ekip ile çevre hakkında daha çok şey anlaşıldıkça, daha rafine planlama için Orta veya Ayrıntılı düzeye geçersiniz.

COCOMO Modelinin Sınırlamaları

En büyük sınırlama, COCOMO’nun KLOC’a bağımlılığıdır. COCOMO’yu kullanmak için, herhangi bir kod yazmadan önce bir projeyi kod satırı cinsinden tahmin etmeniz gerekir. Projenin erken aşamalarında—tahminin en çok önem taşıdığı anda—bunu doğru yapmak ünlü derecede zordur.

KLOC tahmin edilebildiğinde bile, COCOMO I’deki sabitler 1968–1979 arasında şelale modeline göre inşa edilen 63 projeden gelir. COCOMO II’deki sabitler ise 1990’lardan 161 projeye dayanır. Bu veri kümelerinin hiçbiri bulut-yerel sistemleri, mobil uygulamaları, mikro hizmet mimarilerini veya modern DevOps hatlarını içermez. Bu sabitleri yerel kalibrasyon yapmadan doğrudan modern bir projeye uygulamak güvenilmez tahminler üretir.

2025 tarihli bir çalışma buna rakam kattı. Kalibre edilmemiş Temel COCOMO’nun bir NASA proje veri kümesine uygulanması, yaklaşık %100 ortalama göreli hata üretti; tahminlerin hiçbiri gerçek eforun %25’i içinde kalmadı. Bu küçük bir hata payı değildir; modelin, tasarlandığı koşulların dışında kullanıldığını gösterir.

Model yinelemeli geliştirmeyi de iyi ele almaz. COCOMO makul ölçüde ardışık bir yaşam döngüsü varsayar. Agile ekipler, kısa sprintlerle ve evrilen backlog’larla çalıştıkları için COCOMO’nun yapısına gömülü şelale varsayımlarına uymazlar.

Daha derin bir sorun da var. Mart 2026’da Frontiers in Artificial Intelligence dergisinde yayımlanan bir makale, COCOMO II’nin kalibrasyon meselesinin ötesinde, yapısal olarak da yapay zekâ destekli yazılım geliştirme ile temelden uyumsuz olduğunu savundu. Yapay zekâ kodlama araçları bir kod tabanının önemli bölümlerini ürettiğinde, insan eforunun vekili olarak KLOC yanıltıcı hale gelir. Efor artık doğrulama, mimari yönetişim ve güvenlik incelemesi üzerinde yoğunlaşır; bunların hiçbiri COCOMO’nun maliyet sürücü çerçevesi tarafından yakalanmak üzere tasarlanmamıştır.

COCOMO Modeli ve Diğer Tahmin Teknikleri

COCOMO tek seçenek değildir. Alternatifleri bilmek, belirli bir durum için doğru yaklaşımı seçmenize yardımcı olur.

Fonksiyon Puanı Analizi (FPA), sistem karmaşıklığını programlama dilinden bağımsız şekilde, kullanıcıya dönük giriş ve çıkışlardan ölçer. Sağlam gereksinimlere sahip olup henüz KLOC tahmini olmayan durumlarda iyi çalışır. COCOMO II’nin Erken Tasarım modeli giriş olarak fonksiyon puanlarını kabul eder; bu nedenle ikisi birlikte kullanılabilir.

Story Point’ler Agile ortamlarda standarttır. Ekipler kullanıcı hikâyelerini göreli karmaşıklığa göre derecelendirir ve ilerlemeyi projekte etmek için hızlarını takip eder. Hızlıdırlar ve ekibe özgüdürler; ancak tedarik ve uzun vadeli planlamanın gerektirdiği toplam maliyet temelini üretmezler. COCOMO ve story point’ler farklı amaçlara hizmet eder.

SEER-SEM ve SLIM gibi parametrik araçlar, mülki kalibrasyon veritabanları ve daha geniş parametre setleri kullanır. Çalışmalar, kalibre edilmemiş COCOMO II’ye kıyasla doğrulukta daha iyi performans gösterdiklerini bulmuştur. COCOMO’nun avantajı şeffaflık ve açık erişilebilirliktir; bu da akademik ya da denetlenebilir bağlamlarda önem taşır.

Makine öğrenimi tabanlı tahmin aktif bir araştırma alanıdır. Ocak 2026 tarihli bir çalışma, rasgele ormanlar, destek vektör regresyonu ve sinir ağlarını birleştiren topluluk modellerinin, dört standart değerlendirme metriğinin tamamında Agile proje verilerinde COCOMO ailesi modellerini geride bıraktığını buldu. Bu yaklaşımlar, onlarca yıl önce belirlenmiş sabitlere güvenmek yerine eğitim verilerine uyum sağlar.

COCOMO Modeli Örneği (Çözümlü Hesaplama)

COCOMO’nun diğer yöntemlere göre konumunu bilmek faydalıdır; ancak nasıl çalıştığını anlamanın en iyi yolu rakamları koşmaktır. Organik mod ve 50 KLOC olarak tahmin edilen bir proje üzerinden, tam bir Temel COCOMO I hesabını birlikte yürütelim.

Organik mod için sabitler: a = 2,4; b = 1,05; c = 2,5; d = 0,38.

Adım 1: Eforu hesaplayın

50^1,05’i hesaplamak için şu gerçeği kullanın: .

Adım 2: Geliştirme süresini hesaplayın

Adım 3: Gerekli kişi sayısını hesaplayın

Özet:

İki şeye değinmeye değer. Kişi-ay ile takvim ayı farklı birimlerdir: 16,6 takvim ayı boyunca 145,8 kişi-ay, paralel çalışan yaklaşık 9 kişi demektir. Ve bu Temel COCOMO olduğundan yalnızca büyüklük ve modu kullanır. EAF üzerinden gerçek maliyet sürücüsü derecelendirmeleri eklemek, efor tahminini buradan yukarı veya aşağı kaydırır.

Yazılım Mühendisliği Mülakatlarında COCOMO Modeli

COCOMO, akademik derslerde, üniversite sınavlarında ve kamu, savunma ile sistem mühendisliği rollerine yönelik mülakatlarda gündeme gelir. Agile tüketici teknoloji şirketlerinde nadiren karşınıza çıkar.

En yaygın soru COCOMO I ile COCOMO II arasındaki farktır: 63 projeden sabit modlar ve ön ayarlı sabitler ile, daha büyük ve modern bir veri kümesi üzerinde beş sürekli ölçek faktörü. Bu ayrımı, temel formülleri ve üç modun adını bilmek çoğu senaryoyu karşılar. Mülakat yapanlar ara sıra örnek bir hesaplama da isteyebilir; bu yüzden yukarıdaki çözümlü örneği pratik etmek faydalıdır.

Sonuç: COCOMO Modeli Hâlâ Geçerli mi?

COCOMO, varsayımlarının geçerli olduğu yerlerde kullanışlıdır: ardışık geliştirme, resmi tedarik ve akademik çalışma. Modern yazılım bu koşullardan saptığında model zayıflar.

Bir projenin başında hızlı bir mertebe kontrolü için Temel COCOMO’yu kullanın. Ekip ve ortam verilerine sahip olduğunuzda Orta düzeyi kullanın. Gerçek bir teklif ya da planda herhangi bir çıktıya güvenmeden önce kendi proje geçmişinize göre kalibre edin. Sınırlamalar bölümünde ele aldığım gibi, varsayılan sabitleri kalibrasyon yapmadan modern bir projeye uygulamak, üzerine hareket edilemeyecek kadar büyük hatalara yol açar.

COCOMO III, Boehm CSSE’de yaklaşık 2015’ten beri geliştiriliyor; Mart 2026 itibarıyla halka açık bir sürüm yok. 1981’deki orijinal ve 2000 güncellemesi ölçüt olmaya devam ediyor.

Yazılım geliştirmede daha ileri gitmek ister misiniz? Burada öğrendiklerinizi pekiştirmenize yardımcı olacak Python ile Yazılım Mühendisliği İlkeleri, Cursor ile Yazılım Geliştirme ve GitHub Copilot ile Yazılım Geliştirme kurslarımız var.