Sınıf Puanı (Class Points - CP)

Nesneye dayalı geliştirmede sınıf diyagramları, büyük ölçüde tasarım dokümanını temel alan niceliksel bilgilere sahip diyagramlardır.

Sınıf Puanı (Class Point), tasarım dokümanını temel alarak nesne-tabanlı yazılım ürünlerinin büyüklüğünü tahmin etmek için tasarlanmış bir yaklaşımdır. Özellikle, CP1 ve CP2 olarak adlandırılan iki ölçüm ortaya atılmaktadır. CP1 yazılım geliştirme sürecinin başında bir ön büyüklük tahmini yürütmek için kullanılmaktadır. Bu CP1, daha sonra geliştirilecek sistemle ilgili daha fazla bilgi elde edildiğinde CP2 uygulanarak iyileştirilir.
Sınıf diyagramları, geliştirilen sistemin mantıksal blokları olan sınıf hiyerarşini ve hedef sistemin yapısal işlevselliğini içerir.

Sınıf Puanı yaklaşımı, 1998’de ortaya atılmıştır. Bu yaklaşım,  sayısal hesaplamaya dayanarak bir sistemin iç niteliklerini temsil eden işlev puanı analiz yaklaşımını temel almaktadır.


CP1 ve CP2 olmak üzere iki ölçüm ortaya atılmıştır.

Kullanıcı Sınıflarının Belirlenmesi ve Sınıflandırılması
Tasarım dokümanı analiz edilirken 4 tür sistem bileşeni kullanılır:
Problem Alan Türü (Problem Domain Type – PDT),
İnsan Etkileşim Türü (Human Interaction Type – HIT),
Veri Yönetim Türü (Data Management Type),
Görev Yönetim Türü (Task Management Type – TMT).

Sınıfların Karmaşıklık Düzeylerinin Belirlenmesi
CP1 içinde her bir sınıfın karmaşıklık düzeyi iki ölçüt ile belirlenmektedir:
Dış Metotların Sayısı (Number of External Methods – NEM),
Servis İsteklerinin Sayısı (Number of Services Requested – NSR)
CP2 içinde, her bir sınıfın karmaşıklık düzeyini değerlendirmek üzere Niteliklerin Sayısı (Number Of Attributes – NOA) dikkate alınmaktadır.

Sınıf Puanı büyüklük kestirim süreci, FP yaklaşımındaki safhalara benzer olarak dört temel aşamada yapılandırılmıştır.

İlk adımda, kullanıcı sınıflarını belirlemek ve sınıflandırmak için tasarım dokümanı analiz edilir. Tasarım dokümanı analiz edilirken, Problem Alan Türü (Problem Domain Type – PDT), İnsan Etkileşim Türü (Human Interaction Type – HIT), Veri Yönetim Türü (Data Management Type), Görev Yönetim Türü (Task Management Type – TMT) olmak üzere dört tür sistem bileşeni kullanılır.

İkinci adımda, sınıflar içersindeki yerel metotlar üzerinden belirlenmiş olan her bir tanımlı sınıfa bir karmaşıklık düzeyi atanır. Bu OO sınıflar için uygun ölçümlerin kullanımı ile sağlanır.

NEM ölçüsü, genel olan yerel metotların sayısı ile verilen ve nesne-tabanlı bir sistemde tek bir sınıfın arayüz büyüklüğünü tahmin etmemize olanak sağlamaktadır.

NSR sistem bileşenlerinin ara bağlantıları için bir ölçüm sağlar. Bu ölçütte tek bir sınıf için geçerlidir ve diğer sınıflar için farklı servis isteklerinin sayısı ile belirlenmektedir.

Problem Alan Türü (Problem Domain Type – PDT),
İnsan Etkileşim Türü (Human Interaction Type – HIT),
Veri Yönetim Türü (Data Management Type),
Görev Yönetim Türü (Task Management Type – TMT).

Teknik Karmaşıklık Faktörünün (Technical Complexity Factor – TCF) Hesaplanması

Use-Case Puanı (Use-Case Points - UCP)

Use-Case Points (UCP) yaklaşımı, bir yazılım proje emek kestirim yöntemi olarak Karner tarafından ortaya atılmıştır.

Nesneye-tabanlı yazılım üretiminde, use-case’ler işlevsel gereksinimleri tanımlar.
Use-Case diyagramları, gereksinimlerin analiz edilmesi aşamasında belirlenmiş hedef sistemin işlevsel davranışlarını incelerler.

Use-Case Points, use-case sayısına dayanan bir yazılım emek kestirim metodudur ve ilk olarak 1993 yılında Gustav Karner tarafından geliştirilmiştir.
Bu yöntem İşlev Puanı Analizi (Function Point Analysis) ve Mark II İşlev Puanı Analizi (Mk II Function Point Analysis)’nin bir uzantısıdır ve bu yöntemler gibi aynı felsefeyi temel almaktadır. Nesneye-tabanlı yazılım üretiminde, use-case’ler işlevsel gereksinimleri tanımlar.

Use-Case Points ile, use-case’lerin aktörleri, senaryoları ile birçok teknik ve çevresel faktörlerü analiz ederek, emek kestirimi için bir büyüklük tahmini oluşturmuş oluyoruz.

Use-Case Puanı (UCP) sistemin use-case analizi ile elde edilebilir:
Use-case analizinin birinci adımı aktörlerin sınıflandırılmasıdır.
Use-case puanı, sistemin use-case analizinden sayılabilir. İlk adım, aktörleri basit, orta ve karmaşık tipte sınıflandırmaktır.

Basit tipte bir aktör, tanımlı bir Uygulama Programı Arayüzüne (Application Programming Interface - API) sahip başka bir sistemi temsil eder.

Orta tipte bir aktör, TCP/IP gibi bir protokol aracılığıyla haberleşen başka bir sistemi temsil eder.

Karmaşık tipte bir aktör ise, bir Web sayfası veya bir Grafik Kullanıcı Arayüzü (Graphical User Interface - GUI) aracılığıyla karşılıklı etkileşen bir kullanıcıyı temsil eder.

Her bir aktör tipine bir ağırlık faktörü atanmıştır.

 Her use-case, ikinci senaryo da dâhil, use-case açıklamasındaki işlemlerin sayısına bağlı olarak basit, orta veya karmaşık olarak tanımlanır.

Bir işlem ya tamamen gerçekleştirilmiş ya da hiç gerçekleştirilmemiş faaliyetler kümesidir. İşlem sayısını sayma, use-case adımlarını sayarak yapılabilir.

Düzeltilmemiş Aktör Ağırlığı ile Düzeltilmemiş Use-Case Ağırlığının toplanması sonucu Düzeltilmemiş Use-Case Puanı (Unadjusted Use-Case Points - UUCP) elde edilir.

Yazılım geliştiren takım teknik faktörleri değerlendirir ve etki derecesine her bir faktöre 0 ile 5 arasında bir karmaşıklık değeri atanır. 0 değeri o faktörün projede etkisinin olmadığı, 3 değeri orta derecede etkili olduğu, 5 değeri ise yüksek derecede etkili olduğu anlamına gelir.

Use-case puanı hesaplanırken, teknik faktörlerin yanında çevresel faktörlerinde göz önünde bulundurulması gerekir. Use-case puanı hesaplanırken, programcı motivasyonu, kullanım kolaylığı gibi işlevsel olmayan gereksinimleri ölçmek amacıyla çevresel faktörler çarpanı kullanılır. Yazılım geliştiren takım çevresel faktörleri değerlendirir ve her bir faktöre etki derecesine göre 0 ile 5 arasında bir etki değeri atar. 0 değeri o faktörün projede etkisinin olmadığı, 1 değeri yüksek derecede negatif etkili olduğu, 3 değeri orta derecede etkili olduğu, 5 değeri ise yüksek derecede pozitif etkili olduğu anlamına gelir.

Üretkenlik Faktörü, geçmiş projelerde harcanan adam-saat sayısının Use-Case Puanı (UCP) oranıdır. Gustav Karner, bir projedeki ortalama Üretkenlik Faktörü (ÜF) için 20 adam-saat önermektedir.

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.