24 Ocak 2017 Salı

COCOMO (Constructive Costing Model)



COCOMO, Barry Boehm tarafından geliştirilmiş algoritmik bir yazılım maliyet kestirim yöntemidir.

Bu yöntem, geçmiş proje verileri ve mevcut proje özelliklerinden türetilen parametreler ile beraber temel bir regresyon formülü kullanır.

Yapılacak hesapların kapsamları açısından basit, orta ve detaylı olmak üzere üç değişik modelden oluşur. Ayrıca bu modellerde kullanılacak problemler, “organik, yarı ayrık ve gömülü sınıflar” altında toplanmıştır.

Gereken emeğin, program büyüklüğünün bir üssel değerine bağlı olması prensibi ve endüstriden toplanan bilgiler ışığı altında bir emek kestirim metodu olarak 1981’de Boehm tarafından COCOMO (Constructive Costing Model) geliştirilmiştir.

COCOMO göreceli olarak dosdoğru bir modeldir.

Yapılacak hesapların kapsamları açısından;  basit, orta ve detaylı olmak üzere üç değişik modelden oluşur.

Orijinal COCOMO modeli yaygın bir merak konusu uyandırdı.
Herkese açık bir modeldir. Bunun anlamı denklemlerin, varsayımların, tanımların herkese açık olmasıdır.
Orijinal COCOMO modeli 63 proje çalışmasına ve kestirme modelleri sıradüzeni temellerine dayanır.
COCOMO bir parametrik model örneğidir. Çünkü maliyet veya süre gibi bağımlı değişkenler kullanır.
COCOMO ile kestirim süreci, projenin tipinin saptanması ile başlar. Proje tiplerinin nasıl sınıflandırıldığını bir sonraki slaytta göreceğiz.


COCOMO - Proje Sınıfları

Ayrık Projeler;
Boyutları küçük,
Deneyimli personel tarafından gerçekleştirilmiş,
LAN üzerinde çalışan, insan kaynakları yönetim sistemi gibi projeler...

Yarı Ayrık Projeler:
Hem bilgi boyutu, hem donanım sürme boyutu olan projeler…

Gömülü Projeler:
Donanım sürmeyi hedefleyen projeler (pilotsuz uçağı süren yazılım - donanım kısıtları yüksek)


Ayrık projeler; küçük boyuttaki programcı takımlarının, iyi bildikleri bir ortamda uygulamalar geliştirmesidir. İletişim problemi azdır ve elemanlar çabucak işlerini halledebilecek durumdadırlar.

Yarı ayrık projelerde ise ekipte tecrübeli ve tecrübesiz elemanlar bulunabilir. İlgili sistemler konusunda deneyimleri sınırlı olabilir ve geliştirilen sistemin her şeyini bilmeyebilirler.

Gömülü projelerde ise geliştirilecek yazılım, sistemin donanım, kurallar, işletim süreçleri veya yazılım gibi diğer bileşenleri ile çok kuvvetli bağlantılar oluşturur. Gereksinim değişiklikleri ile problemleri halletmek olanaksızlaşmıştır. İhtiyaç belirtiminin geçerlilik irdelemesi çok pahalıdır. Elemanların her şeyi bilme olasılığı iyice azalmıştır.

COCOMO bu model ve proje sınıfı saptamalarından sonra ortaya çıkan formüllerle tahmin hesaplama yolunu önerir.

Basit COCOMO Modeli İçin Emek ve Süre Formülleri





Basit COCOMO modeli, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır.


Kullanılacak ayrıntı düzeyine göre Basit, Orta ve Detaylı olmak üzere üç temel model vardır. Basit COCOMO modeli, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır.

Avantajı: Hesap makinesi ile kolaylıkla hesaplanabilir.
Dezavantajı: Yazılım projesinin geliştirileceği ortam ve yazılımı geliştirecek ekibin özelliklerini dikkate almaz.

Orta COCOMO modeli sistemin (güvenilirlik, veri tabanı büyüklüğü, işletme ve kayıt sınırlandırmaları, personel özellikleri ve kullanılan yazılım araçları gibi) diğer özelliklerinin hesaba katılması amaçlanmıştır.

Orta COCOMO Modeli İçin Emek Formülleri


Belirli bir dizi özelliğin, proje açısından etkileri ayrı ayrı ağırlandırılarak katsayılar ortaya çıkarılır.
Bu faktörler, ilgili özellik için düşük (<1), nominal (1) veya yüksek (>1) olarak saptanırlar.

Katsayılar birbiri ile çarpıldığında Emek Ayarlama Faktörü (EAF) (Effort Adjustment Factor) bulunur. Bu katsayı 0.9 ile 1.4 arasında bir değer alır ve Tabloda gösterilen Orta COCOMO modeli formülleri kullanılarak emek hesaplaması sonuçlandırılır. Süre hesaplaması ise Basit COCOMO modelinde olduğu gibi yapılır.


Emek Ayarlama Faktörü için sözü geçen etkenleri dört grupta toplayarak, yandaki tabloda görüldüğü gibi sıralayabiliriz.

EAF (Emek Ayarlama Faktörü) orta ve detaylı seviyede kullanılır.

Detaylı COCOMO modeli projenin evrelerine bağlı olarak süreç içinde değişiklikleri hesaba katarak arada bir kestirim hesaplamasını önerir.

Bu modelde zamana bağlılık temel değişikliktir. Projenin farklı evrelerinde çaba yoğunluğu ve yapılacak işin karmaşıklığı değişecektir.

Detaylı COCOMO modeli, basit ve orta COCOMO modeline ek olarak iki özellik taşır. Aşama ile ilgili işgücü katsayıları: her aşama için (planlama, analiz, tasarım, geliştirme, test etme) farklı katsayılar, karmaşıklık belirler. Yazılım maliyet kestiriminde; Modül, Altsistem, Sistem sıra düzenini dikkate alır.

1981’de Boehm tarafından ortaya konan COCOMO modeli daha sonra geliştirilmiş ve COCOMO II adını almıştır.




COCOMO – Emek Ayarlama Faktörü

Ürün Özellikleri
RELY: Yazılımın güvenirliği.
DATA: Veritabanının büyüklüğü.
CPLX: Karmaşıklığı.

Bilgisayar Özellikleri
TIME: İşletim zamanı kısıtı.
STOR: Ana bellek kısıtı
VIRT: Bilgisayar platform değişim olasılığı. Örn; bellek ve disk kapasitesi artırımı, CPU upgrade…
TURN: Bilgisayar iş geri dönüş zamanı. Örn; hata düzeltme süresi.


Personel Özellikleri
ACAP: Analist yeteneği. Deneyim, birlikte çalışabilirlik.
AEXP: Uygulama deneyimi. Proje ekibinin ortalama tecrübesi.
PCAP: Programcı yeteneği.
VEXP: Bilgisayar platformu deneyimi. Proje ekibinin geliştirilecek platformu tanıma oranı.
LEXP: Programlama dili deneyimi.

Proje Özellikleri
MODP: Modern programlama teknikleri. Örn; Yapısal programlama, görsel programlama, yeniden kullanılabilirlik.
TOOL: Yazılım geliştirme araçları kullanımı. Örn; CASE araçları, metin düzenleyiciler, ortam yönetim araçları
SCED: Zaman kısıtı.


Ürün Özellikleri
RELY: Yazılımın güvenirliği.
DATA: Veritabanının büyüklüğü.
CPLX: Karmaşıklığı.

Bilgisayar Özellikleri
TIME: İşletim zamanı kısıtı.
STOR: Ana bellek kısıtı
VIRT: Bilgisayar platform değişim olasılığı. Örn; bellek ve disk kapasitesi artırımı, CPU upgrade…
TURN: Bilgisayar iş geri dönüş zamanı. Örn; hata düzeltme süresi.


Personel Özellikleri
ACAP: Analist yeteneği. Deneyim, birlikte çalışabilirlik.
AEXP: Uygulama deneyimi. Proje ekibinin ortalama tecrübesi.
PCAP: Programcı yeteneği.
VEXP: Bilgisayar platformu deneyimi. Proje ekibinin geliştirilecek platformu tanıma oranı.
LEXP: Programlama dili deneyimi.

Proje Özellikleri
MODP: Modern programlama teknikleri. Örn; Yapısal programlama, görsel programlama, yeniden kullanılabilirlik.
TOOL: Yazılım geliştirme araçları kullanımı. Örn; CASE araçları, metin düzenleyiciler, ortam yönetim araçları
SCED: Zaman kısıtı.


Emek = 3.0 x (KLOC)1.12 x EAF

Emek = 3.0 x (7816)1.12  x 1,23 = 36,9 adam-ay

Takvim= 2.5 x Emek 0,38= 2.5 x 36,90,38 = 9,84 ay (Geliştirme Zamanı)

N = Emek  / Geliştirme Zamanı › (N: ortalama personel sayısı)

N = 36,9 / 9,84 = 3,75 – 4 kişi

Algoritmik Kestirim Yöntemleri



Bu yöntemler, emek kestirimi için matematiksel modeller (matematiksel formüller) kullanılırlar.

Bu tür modellerde geçmişe ait veriler, kod satır sayısı, fonksiyon sayısı vb. istatistikler ile yazılım projelerine doğrudan etki eden çevresel ve teknik faktörler girdi olarak verilir. Model belirli  bir doğruluk aralığında sonuç üretir.

Bu tür modellerin içinde bulunan ortama göre bazı parametrelerinin "kalibre" edilmesi gerekmektedir.

Emek Kestirimi



Emek (işgücü) genelde adam-saat, adam-gün ya da adam-ay cinsinden ölçülür.

10 adam-ay:
10 kişi 1 ay
1 kişi 10 ay
2 kişi 5 ay anlamına gelebilir.

Emek kestirimi, bir yazılım projesini geliştirmek için kaç kişi ve ne kadar zaman gerektiğini tahmin etmek için kullanılmaktadır.  Bir yazılım projesinde emek yatırımı, son yıllarda proje yönetim süreci içindeki en önemli analiz değişkenlerinden biridir. Yazılım projeleri başlatılırken bu değişken değerinin bilinmesi, yazılım yöneticilerinin gelecek faaliyetleri gerektiği gibi planlamasını sağlar.  Emek kestiriminde iyi sonuçlar elde etmek için önceki projeleri dikkate almak önemlidir.





Emek kestirim yöntemleri algoritmik ve algoritmik olmayan kestirim yöntemleri olmak üzere iki şekilde sınıflandırılmaktadır.

Algoritmik kestirim yöntemleri
COCOMO (Constructive Costing Model)
Use-Case Points
Class Points
UML Points

Algoritmik olmayan kestirim yöntemleri
Uzman kararı,
Benzerlik ile kestirim,
Büyüklük verisi kullanarak kıyaslama.


Yazılım emek kestiriminde kullanılan yöntemler, algoritmik ve algoritmik olmayan kestirim yöntemleri olarak sınıflandırılmaktadır.

COSMIC Tam İşlev Puanı




Uluslararası Ortak Yazılım Ölçüm Birliği, işlevsel yazılım büyüklük ölçümüne yönelik yeni bir metot geliştirmek amacıyla 1998’de kurulmuştur. IFPUG, Mark II ve NESMA gibi mevcut yazılım büyüklük kestirim yöntemlerinin en iyi karakteristik özellikleri alınarak, yeni bir işlev büyüklük ölçüm yöntemi olarak COSMIC FFP’yi Kasım 1999’da yayınlamıştır.


COSMIC - Common Software Measurement International Consortium

Yeni bir işlevsel büyüklük ölçüm yöntemi olarak COSMIC FFP Kasım 1999’da yayınlamıştır.

COSMIC FFP yöntemi, geliştirici ve son kullanıcı bakış açıları olmak üzere birçok ölçüm bakış açısına sahiptir.

Yazılımın işlevsel büyüklüğü, dört İşlevsel Tabanlı Bileşeni temel alarak ölçülmektedir.  İşlevsel Tabanlı Bileşenler; Giriş (Entry), Çıkış (Exit), Okuma (Read) ve Yazma (Write) dır.

Nesma İşlev Puanı



Netherlands Software Metrics Users Association – NESMA, 1989.

NESMA, Avrupa’daki en büyük FPA kullanıcı grubudur.

İşlev Puanı Analizinin uygulanması ile ilgili tanımlar ve ölçüm kılavuzunun ilk versiyonu 1990’da yayınlanmıştır.

Bu yöntem, IFPUG FPA yönteminin ilkelerini temel almaktadır. IFPUG FPA’a benzer olarak işlevselliğin büyüklüğü için, Dış Giriş, Dış Çıkış, Dış Sorgu, İç Mantıksal Dosya ve Dış Arayüz Dosyası gibi işlev türlerini kullanmaktadır.



1989’da, Hollanda Yazılım Ölçüt Kullanıcıları Birliği (Netherlands Software Metrics Users Association - NESMA), Hollanda İşlev Puanı Kullanıcıları Grubu (Netherlands Function Point Users Group - NEFPUG) olarak kuruldu.

Mark II İşlev Puanı



Charles Symons’a göre;
Bir uygulamanın bileşenlerinin belirlenmesi Albrecht’in FPA’sında zordur,
Albrecht yaklaşımı iç karmaşıklıkla ilgili hiçbir düşünceye sahip değildir,
On dört ayarlama faktörü yeterli değildir.

1980’lerde İngiltere’de MKII İşlev Puanı geliştirildi.

MK II, kullanıcıya sağlanan işlevselliğin değerinden çok işlevselliği üretmek için gerekli emeğe odaklamak için tasarlanmış bir yöntem.

MK II, uygulamayı mantıksal işlem gruplarına ayrıştırmaktadır. Symons mantıksal bir işlemi; “bilgi almak için bir gereksinim ya da kullanıcıyı ilgilendiren bir olay ile tetiklenen benzersiz bir girdi/işlem/çıktı birleşimi” olarak tanımlar.


Symons, Albrecht’in FPA yönteminde gördüğü bu eksiklikleri çözmek için 1980’lerde İngiltere’de MKII İşlev Puanını geliştirdi.

Düzeltilmemiş İşlev Puanı (Unadjusted Function Points - UFP), girdi, çıktı ve işlemlerin toplam sayılarının bir fonksiyonudur.

IFPUG İşlev Puanı Analizi


IFPUG - International Function Point Users Group (1984)
IFPUG uygulama yazılımı geliştirme ve bakım faaliyetlerinin yönetiminde FPA’nın kullanımını teşvik etmektedir.
Resmi IFPUG Ölçüm Uygulama Kılavuzları sırasıyla 1986, 1988, 1990, 1994, 1999, 2004 ve 2009’da yayınlanmıştır.
IFPUG FPA en yaygın olarak kullanılan FSM yöntemidir.

Orjinal FPA yöntemini sürdürmek için 1984’te Uluslar Arası İşlev Puanı Kullanıcıları Grubu (International Function Point Users Group - IFPUG) oluşturuldu. IFPUG yazılımın işlevselliğini ölçmek için, FPA yönteminin kullanımını teşvik eden, kar amacı olmayan ve üyeleri tarafından idare edilen bir örgüttür


FPA’yı yazılım büyüklüğü için standart metodoloji olarak kabul etmektedir.