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.

İşlev Puanı (Function Points)

Bu yaklaşım, verimliliğin üretilen işlev puanına göre adam-ay olarak belirlenmesini öngörür.

Eğer proje ile ilgili girdi çıktı gibi özellikler tahmin edilebiliyorsa, bunlar kullanılarak geliştirilecek sisteme ait bir İşlev Puanı (Function Points) hesabı yapılabilir ve sonuçlar Satır Sayısına (LOC) çevrilebilir. Bu satır sayısından maliyet, emek ve süre tahmini yapılabilir.
İşlevsellik doğrudan ölçülemeyeceğine göre, bir yazılım projesinde işlevselliğe etkisi olan birçok etken bir arada incelenerek ürüne olan yansımaları ağırlıklandırılır. Sonuçta bir rakam ortaya çıkar ve bu rakam değişik projeleri göreceli olarak değerlendirmede yararlı olur.

UFP = Dış Girdiler x W(1) + Dış Çıktılar x W(2) + Dış Sorgular x W(3) + 
            İç Dosyalar  x W(4) + Dış Arayüz Dosyaları x W(5)

İşlev Puanında sistemin işlevselliği 5 ayrı bileşenle incelenmektedir.

1. Dış Girdiler: Veri giriş ekranları, mantıksal dâhili dosyalar.
2. Dış Çıktılar: Ekran çıktıları, raporlar.
3. Dış Sorgular: Kullanıcı isteği doğrultusunda alınan hızlı veri çıkışları.
4. İç Dosyaları: Dâhili kullanıcı verileri, saklanan veriler.
5. Dış Arayüz Dosyaları: Başka bir sistemle paylaşım.

Her bir bileşenin zorluk derecesi basit, orta ve karmaşık gibi Tablo’da verilen rakamsal değerlere bağlı olarak ölçülebilmektedir. Bu ölçülen değerler toplanarak Düzeltilmemiş İşlev Puanı’nı (Unadjusted Function Points - UFPs) oluşturmaktadır.

14 Genel Sistem Özelliğine göre sistemin beklenilen uygulama zorluğu için ilave bir teknik karmaşıklık faktörü hesaplanır.

0: hiç yok ya da etkisiz,
1: önemsiz etki,
2: az etkili ,
3:orta düzeyde etkili 
4: önemli düzeyde etkili,
5: güçlü etki

İşlev Puanı aşağıdaki formül ile hesaplanır:
FP = UFP x TCF

İşlev Puanı’nı, Satır Sayısına dönüştürmek için aşağıdaki formülden yararlanılır.
LOC = İşlev Puanı x  Programlama Dili LOC Katsayısı

Kan tahlili yapan bir laboratuarın aynı şehir içerisinde 5 şubesi vardır. Her şubede yaklaşık 10 adet veri giriş operatörü bulunmaktadır.
Sistem laboratuardaki tahlillerin fiyatlarını tutacaktır.
Hasta bilgileri kaydedilecektir.
Yeni tahliller eklenebilecek, güncelleme yapılabilecektir.
Tahlil sonuçları laboratuar yetkilisi tarafından onaylandıktan sonra görüntülenebilecektir.
İstenen laboratuar tahlillerinin tutarı hesaplanacak ve  faturası basılacaktır.
Sonuç raporları basılacaktır. Eğer müşterinin daha önceki kayıtları varsa rapor önceki sonuçları da içerecektir.
Müşteriler sisteme web üzerinden verilecek şifrelerle  bağlanarak tahlil no ile sonuçlarını öğrenebileceklerdir.
Sistemin kan analiz cihazıyla arayüzü olacak, sonuçlar direkt olarak cihazdan sisteme aktarılacaktır.
Sistem malzeme yönetimi yapacak, malzeme stok bilgilerini tutacaktır. Her laboratuar ana depodan haftalık malzeme isteği yapacaktır.  Laboratuarlardan birinde ana malzeme deposu yer alacak, depoya girişler  ve  birimlere çıkışlar kaydedilecektir. Her malzeme için kritik stok seviyesinin altına düşen  malzemeler için sistem uyarı verecek ve rapor yayınlayacaktır. Birim bazında aylık malzeme raporu yayınlanacaktır.
Laboratuarın ana sunucusu şubelerden birinde yer alacak ve herhangi bir arıza olduğunda sistem diğer şubedeki yedek sunucuya  bağlanacak ve oradan işleme kesintisiz devam edecektir. İletişim altyapısında leased line kullanılacaktır.
Sistemi geliştirecek ekip, Java konusunda ve analiz konularında orta deneyimdedir.  İşlevsellik konusunda çok fazla deneyimi yoktur.  Bir kaç benzer yönetim bilgi sistemi geliştirmiştir. CASE aracı kullanılacaktır.

Örnek Proje – Üst Düzey Sistem Mimarisi