Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü

Yazılım Kestirimi / Tahmini (Software Estimation) Tam Olarak Nedir?

Yazılım kestirimi ya da diğer ifadeyle yazılım tahmin işlemi çeşitli yöntemlerle yazılım projelerinin planlaması ve kontrolü için yapılan bir dizi aktivitedir. Bu çalışmalar yazılım geliştirmedeki en zorlu çalışmalardan biridir.

Bu çalışma aşağıdaki gibi projeyle ilgili bazı temel soruları çalışma sonunda cevaplamayı amaçlar:

• Yazılımı geliştirmek ne kadar zaman gerektirecek?
• Yazılımı geliştirmek ne kadar efor ve maliyet gerektirecek?
• Kaç geliştiriciye ihtiyaç var?
• Geliştirme için doğru harcamayı yapıyor muyuz?
• Hâkim maliyet faktörleri nelerdir?
• Önemli risk faktörleri nelerdir?
• Projelerimiz için nasıl güvenilir tahminler elde edebiliriz?
• Tahminlerimiz güvenilir mi?
• Uygulama canlıya çıkabilmek için yeterince test edildi mi?

Bu konuların netleştirilmesiyle yazılım proje yönetimi somut planlamaları yapabilir duruma gelecektir.

Bu sorulara cevap vermek kolay olmasa da proje yönetiminin yazılım geliştirme eforunu ve takvimini tahmin ederek kontrol etmek için birçok yazılım kestirim yöntemleri geliştirilmiştir. Bunları konu başlıklarında ayrı ayrı göreceğiz.

Yazılımda Kestirim / Tahmin Neden Yapılır?

Yazılım projelerinin planlanması ve kontrolü için yazılım kestirimi ya da tahmini önemli bir yere sahiptir. Kestirim yapmak yani doğru tahminler proje planlamasında sağlam temel oluşturur. Proje yaşam döngüsünün planlandığı gibi ilerleyebilmesi için efor, takvim ve maliyet kestirimi çok önemli paya sahiptir.

Ayrıca yazılım çalışmalarının etkin yönetimi ve ölçümü çoğu modern kuruluş için kritik öneme sahiptir. Yazılım boyutunun bilinmesi, yazılımın oluşturulması ve yürütülebilmesine yönelik çalışmaların yönetilebilmesi açısından önemlidir. Etkili ölçüm sayesinde kuruluşlar yazılım işlerini daha etkili bir şekilde tahmin edebilir, kontrol edebilir, planlayabilir ve yapmayı öğrenebilir.

Yazılım kestiriminin ana amacı bir projenin sonucunu tahmin etmek değildir! Bir projenin hedefleri, projenin bunları karşılamak için kontrol edilmesine izin verecek kadar gerçekçi mi bunu belirlemektir. Ana amaç proje yönetiminin kaliteyi zaman, maliyet ve kapsam kısıtlarını yöneterek yakalayabilmesidir.

Kuruluşların kendi ortaya çıkardığı raporlara veya bulgulara bakıldığında yazılım projelerinde genelde geliştirme için harcanan efor belirlenen tahmini aşar. Bu durum da yazılımın planlanan tarihten sonra teslim edilmesiyle sonuçlanır. Yazılım kestirim aktiviteleri aslında bundan dolayı projelerde önemli bir paya sahiptir. Yani projelerde geliştirilmesi gereken ürün, geliştirme süreci, geliştirme araçları, geliştirme ekibi ve organizasyon hakkında bilgi sahibi olmak önemlidir. Dolayısıyla bir dizi tahmin yöntemi ve tekniğinin mevcut olması gereklidir.

Peki yazılım ölçümlerinden kimler yararlanır?

• Büyük ticari yazılım üreticileri rutin olarak yazılım boyutlarını ölçmekte ve bunları yeni proje efor tahmini ve proje verimliliği ölçümü için kullanmaktadır. Yaptıkları ölçümler, riski yönetmek ve karlılığı korumak için önem taşımaktadır.
• Yazılımın müşterileri, kapsamda oluşabilecek kaymaları ve yazılımı tedarik ettikleri firmaların fiyat/performans, kalite ve benzeri özelliklerini kontrol etmek için bu ölçümlerden faydalanabilir.
• Proje yöneticileri, projelerinin eforunu yazılım boyutuna göre tahmin edebilir veya kendi efor tahminleriyle karşılaştırmak için efor tahminlerini kullanabilir.
• Yönetim, efor tahminlerini yazılım tedarikçisinin teklifleriyle karşılaştırmak veya bir proje yöneticisinin tahminini değerlendirmek için kullanabilir.

Yazılım Projelerinde Hangi Alanlarda Kestirim Yapılır?

Yazılım projelerinde tahmin yapılacak 4 ana kıstas bulunur:

1. Yazılım Büyüklük Tahmini / Kestirimi (Size Estimation)
2. Yazılım Efor Tahmini / Kestirimi (Effort Estimation)
3. Yazılım Takvim Tahmini / Kestirimi (Schedule Estimation)
4. Yazılım Maliyet Tahmini / Kestirimi (Cost Estimation)

Bunları ayrı ayrı inceleyelim.

Yazılımda Büyüklük Kestirimi (Size Estimation)

Yazılım boyutunun ne olacağının doğru bir şekilde tahmin edilebilmesi etkili bir planlama ve kontrol için ilk adımdır. Yazılım geliştirme proje yöneticilerinin karşılaştığı büyük zorluklardan bazıları yeni projeler için maliyet ve zamanlama için kestirimde bulunmak ve yapılan bu tahmine göre planlama yapmaktır. Maliyet ve zamanlamayı tahmin için kullanılan modellerde çoğunlukla yazılım büyüklüğü kullanılır çünkü yazılımın büyüklüğü yazılımın en temel özelliklerinden biridir. Yazılım büyüklüğü yazılım projeleri için gereken maliyet ve çaba için önemli bir faktör olarak kabul edilmektedir. Yani bir projede sağlanacak geliştirme eforunun ne olacağı, ne kadar bütçe ayrılması gerektiği ve ne zaman tamamlanacağına dair bazı tahminler yapılarak planlama oluşturulur.

Geliştirilecek yazılım ürününün boyutunu ortaya çıkarmak önemlidir. Yazılım proje yönetimi faaliyetlerini uygulayabilmek için ve yazılım kalitesi ile ilgili gereken aksiyonların alınması için geliştirilecek yazılım uygulamasının büyüklüğünü gösterebilmek gerekir. Yazılım kalitesi için de önemli bir değerdir. İnsanların bir proje hakkında temelde bilmek istedikleri yazılım boyutu ile ilgilidir:

• Yazılım ne kadar büyük?
• Diğer projelere göre ne kadar büyük?
• Bunu ortaya çıkarabilmek için ne kadar çaba / efor gerekmektedir?
• Yazılımın kalitesi diğer projelere göre nasıl?

Yazılım Büyüklüğü Nasıl Ölçülür?

Yapılan araştırmalar, yazılım boyutunun maliyet tahmini için ana faktör olduğunu ortaya koymuştur. Bunun için yazılım boyutunu hesaplamak için kullanılan bazı teknikler veya yöntemler geliştirilmiştir.

Bununla birlikte yazılımın büyüklüğünü ölçmek için evrensel bir standart yoktur. Bir fiziksel nesnenin hacmini, alanını ölçmek için belirli ölçüm standartlarının olduğu gibi yazılımda bu şekilde belirli bir kural olmadığı için yazılımın büyüklüğünü ölçmek gerçekten zordur. Dolayısıyla sektörde yazılım büyüklüğünü ölçebilmek için bazı yöntemler geliştirilmiştir.

Yazılımda büyüklüğü ölçmek için kullanılan bu teknikler temelde ikiye ayrılmaktadır:

1. Fiziksel yazılım nesnelerini kullanarak hesaplama (örn. kod satır sayısını kullanma.)
2. Ürünün işlevsel kısımlarını hesaplama.

1. Fiziksel Yazılım Nesnelerini Kullanarak Benzer Projelerle Kıyaslanması (Analoji)

Geçmişte benzer bir proje yapmış ve büyüklüğünü bilerek, yeni projenin her bir ana parçasını, önceki projenin benzer bir parçasının büyüklüğünü baz alarak kestirebilirsiniz. Parçaların her birinin tahmini boyutlarını toplayarak yeni projenin toplam boyutunu tahmin edebilirsiniz. Önceki projeler için doğru boyut değerleri mevcutsa ve yeni proje bir öncekine yeterince benzerse, benzetme yoluyla makul derecede iyi boyut tahminleri üretebilir. Yani geçmiş verilerek tutularak kestirim yapılabilir. Burada işlemler fiziksel yazılım nesnelerine dayanır.

Burada kullanılan en yaygın metrik: kaynak kod satır sayısı (source lines of code – SLOC)

Çoğu yerde LOC yani kod satır sayısı olarak de geçmektedir. Ek olarak KLOC da “kilo lines of code” yani 1000 satırlık kod anlamına gelmektedir.

Bu kısımla ilgili yaygın olarak bilinen yazılım kestirim yöntemleri şunlardır:

• • Wideband Delphi süreci
  • COCOMO modeli
  • User story points – Planning Poker

2. Ürün Özelliklerini Sayarak ve İşlev Puanları (Function Points) gibi Algoritmik Bir Yaklaşım Kullanma

Makro düzeyden bakacak olursak yazılım ürününün özellikleri; alt sistemlerin, sınıfların/modüllerin, yöntemlerin/fonksiyonlarının sayısını içerebilir. Hatta ekranların, diyalogların, dosyaların, veri tabanı tablolarının, raporların, mesajların vb. sayısını içerebilir.

Burada kullanılan en yaygın metrik: işlev puanı (function point)

Bu yöntemlerin avantajı olduğu kadar da dezavantajları olduğu için şartlara göre en iyi yöntemi seçmek gerekir.

Fonksiyonel kullanıcı gereksinimlerine göre yaygın olarak bilinen ve kullanılan yazılım kestirim yöntemleri şunlardır:

• • IFPUG (ISO/IEC 20926)
  • Mark II (ISO/IEC 20968)
  • NESMA (ISO/IEC 24570)
  • FISMA (ISO/IEC 29881)
  • COSMIC (ISO/IEC 19761)

COSMIC işlevsel boyut ölçüm yöntemini ayrı bir yazıda inceleyeceğiz.

Kod Boyutu (SLOC, LOC) İle Yazılım Büyüklüğü Ölçmek

Yazılım proje yönetimi faaliyetlerini (izleme, iyileştirme gibi) uygulayabilmek için bir yazılım uygulamasının veya bileşeninin boyutunu tahmin etmek için kullanılır. Bir proje hakkında en başta sorulan kilit sorulardan biri de yazılımın büyüklüğüdür. Yani yazılımın ne kadar büyük olduğu, diğer projelere nazaran ne kadar büyük olduğu, ne kadar çaba/efor harcanacağı, yazılım kalitesinin diğer projelere göre nasıl olduğu başlıca açıklığa kavuşturulması istenen noktalardır.

Yazılım büyüklüğü uzunluk veya işlevsellikle tanımlanır. Uzunluk ürünün kendi teknik uzunluğu; işlevsellik de ürün tarafından kullanıcıya sağlanan işlevlerin bir ölçüsüdür. Yazılımın teknik boyutu (uzunluğu) kod satır sayısı, bileşen sayısı, modül sayısı alt sistem sayısı gibi özellikler göz önüne alınarak yazılım ürünlerini geliştirici perspektifinden ölçmek için kullanılır. Bir programın en sık kullanılan ölçüsü kod satırı sayısıdır. SLOC (source lines of code) veya LOC (lines of code) olarak ifade edilir. Bu da NCLOC ve CLOC olmak üzere ikiye ayrılır:

• NCLOC (Non-comment Lines Of Code): Yorumlanmamış, yorum olarak değerlendirilmeyen kaynak kod satırı, etkili kod satırları, mantıksal kod satırları.
• CLOC (Comment Lines Of Code): Yorum verilmiş kaynak kod satırı, fiziksel kod satırları.

Yorum Satırları Dâhil Edilmeli mi?

Çalıştırılan kodların arasında dokümantasyon amacıyla yorum satırları yazmak da zaman ve çaba gerektirir. Ayrıca yorum miktarı geliştiricilerin program stili, bir kuruluşun dokümantasyon kuralları veya kullanılan dil nedeniyle değişebilir. Dolayısıyla kod boyutunu hesaplamak için öncelikle yorum satırlarının sayılıp sayılmayacağına karar verilmelidir.

Yorum satırlarını sayıp saymama kararının yazılan kod üzerinde bir etkisi olabileceğini bilmek önemlidir. Yorum satırlarını sayarsanız geliştiriciler üretkenlik oranlarını artırmak için gerekenden çok daha fazla yorum satırı yazma eğilimine girebilir. Öte yandan yorum satırlarını saymazsanız, geliştiricinin daha verimli görünmesi açısından yorum yazmama durumu olacağından eksik dokümantasyon nedeniyle bakım ve geliştirme maliyeti artacak ve toplam maliyet geliştiricinin kaynak koduna yorum eklemek için zaman ayırdığı durumdan daha yüksek olacaktır.

NCLOC alt sistemleri, bileşenleri ve uygulama dillerini karşılaştırmak için kullanışlıdır. NCLOC’nin başka bir kullanımı, zaman içindeki sistemlerin büyümesini değerlendirmektir. Örneğin Linux sisteminin ve alt sistemlerin sürümlerdeki büyümesini analiz edilebilir. NCLOC, toplam program boyutunun geçerli bir ölçüsü değildir; yorumlanmamış boyutun bir ölçüsüdür. Yani sonuç olarak yorumlanmamış boyut, yalnızca uygun soruları ve hedefleri ele aldığında ölçmek için makul ve yararlı bir özellik olarak kullanılabilir.

Burada önerilen çalıştırılan kod satır sayısı ile yorum dâhil tüm satır sayısının ayrı ayrı hesaplanmasıdır. Yani;

Toplam boyut (LOC) = NCLOC + CLOC

Yorum yoğunluğu = CLOC / LOC

LOC İle İlgili Problemler

Kod satır sayısını yazılım büyüklüğü ölçmek için kullanmak aslında bazı problemleri de barındırmaktadır. Metin tabanlı uzunluk tanımı ile ilgili sorunlardan biri, yazılım geliştirme otomatik araçlar kullanıldıkça kod ölçüm hattının giderek daha az anlamlı olması. Yani yazılım büyüklüğünü ölçmede gereksinimlerden otomatik kod üreten araçlar, görsel programlama araçları veya kütüphane, repository, tasarım kalıpları (design patterns)veya kalıtsal fonksiyonlar kullanıldığı takdirde kod satır sayısını kullanmak çok anlamlı olmayabilir. Buna ek olarak tek satır yazılabilen kodlar birden fazla satıra yazılmış olablir. Örneğin aşağıdaki for döngüsü aşağıdaki gibi de yazılabildiği gibi tek satırda da yazılabilir.

for(i=0; i<10; ++i)

{

printf(“Hello World!”);

}

LOC yazılım büyüklüğü ölçmede yaygın bir şekilde kullanılsa da bu şekilde değerlendirmeye açık noktaları bulunmaktadır. Peki, LOC’nin avantajları ve dezavantajları nelerdir?

LOC’nin Avantajları

» Basittir ve otomatik olarak ölçülebilme imkânı vardır.

» Yaygın olarak kullanılır ve evrensel olarak kabul edilmiştir.

» Nihai ürünle direkt ilişkilidir. Ürün tamamlandıktan sonra LOC kolayca hesaplanabilir.

» Farklı geliştirme grupları arasındaki boyut ve verimlilik metriklerinin karşılaştırılmasına olanak tanır. Geliştiricilerin tam olarak ne yaptığı görülebilir.

» Programlama efor ve maliyeti ile direkt ilişkilidir.

» Tahmin teknikleri için sürekli iyileştirme faaliyetleri mevcuttur.

LOC’nin Dezavantajları

» Yeni bir ürünün ilk safhalarında LOC’yi ölçmek zordur. Yani erken planlama için uygun değildir.

» Kod satırlarını standartlaştırmak zordur. Her geliştiricinin kendi beceri düzeyine göre veya yorumuna göre kod satır sayısı değişebilir. Hatta geliştirici LOC’yi artırmanın üretkenlik anlamına geldiğini düşünerek sayıyı artırabilir.

» Sayım kıstaslarını standartlaştırmak zordur. Örneğin yorumlar veya bildirimler (declarations) dâhil edilmeli mi?

» Ortaya çıkan kod ile gerçekte yazılan kod miktarı arasında önemli ölçüde fark olabilir.

» Programlama dil bağımlılığı bulunmaktadır. Her dile göre sonuç değişebilir.

Çalışan Kod ve LOC Sayısı Nasıl Değerlendirilmeli?

Bazen programların gerçekte yürütülen çok az kod ile oluşturulduğu bilinmektedir. Yazılım kalitesi için de önemli olan kısım ne kadar çalıştırılabilir kod üretildiğidir. Yorum satırlarının, veri bildirimlerinin ve başlıkların dışarıda tutulduğu ve aynı fiziksel satırdaki ayrı ifadelerin ayrı olarak sayıldığı çalıştırılabilir ifadelere executable statements (ES) yani çalıştırılabilir ifadeler denir ve ölçüm hedefine yönelik kullanılabilir. Buna benzer şekilde delivered source instructions (DSI) da kullanılabilir. DSI, ES’ten farklı olarak veri bildirimlerini ve başlıkları dâhil eder.

Sonuç olarak kod satır sayısı yüksek olan bir yazılımın testi daha zor olacak, bakım maliyeti daha yüksek olacak, yazılım kalitesi etkilenecek ve muhtemelen büyük yazılımda küçük bir yazılıma göre daha fazla hata olacaktır.

İşlev Puanı (Function Point) ile Yazılım Büyüklüğü Ölçmek

Bu kısımda yazılımın fonksiyonel yani işlevsel boyutu hesaplanarak yazılım kestirimi yapılır. Yazılımın işlevsel boyutu, yazılım ürünlerini bir kullanıcının bakış açısından ölçmek için kullanılır. Teknik geliştirme ve uygulama kararlarından bağımsız olmalıdır.

Kullanıcı perspektifinden ürünün işlevselliğine göre yapılan bu büyüklük ölçümleri için kullanılan metrikleri şu şekildedir:

• İşlev Puanı (Function Point)
• Özellik Puanı (Feature Point)
• Nesne Puanı (Object Point)
• Kullanım Durumu Puanı (Use Case Point)

Biz yaygın olarak kullanılan işlev noktalarını göreceğiz. A.J.Albrecht tarafından tanımlanan işlev puanı özet olarak kullanıcı gereksinimleriyle ilgili aşağıdaki beş farklı faktörün ağırlıklı toplamıdır:

1. Girdiler
2. Çıktılar
3. Logic Dosyaları
4. Sorgular
5. Arayüzler

İşlev puanı kullanılarak yapılan ölçümü uygulamalı olarak COSMIC yazısında göreceğiz. İşlev puanı tanımlarıyla ilgili The International Function Point Users Group (IFPUG) adına bir grup bulunmaktadır. Detaylı incelemeleri buradan da yapabilirsiniz.

SLOC ve Function Point’i (FP) kısaca karşılaştıracak olursak; FP spesifikasyon tabanlı, SLOC analoji tabanlıdır. FP yazılım dili bağımsız, SLOC yazılım dili bağımlıdır. FP kullanıcı odaklıdır, SLOC tasarım odaklıdır.

Yazılım Efor Kestirimi (Effort Estimation)

Yazılımın büyüklüğü hakkında bir kestirim yaptığımızda ikinci adım olarak efor kestirimi de yapabiliriz.

Yazılım efor tahmininin başlangıç noktası şudur:

Tahmini efor = Tahmini boyut / verimlilik (productivity)

Verimliliği geçmiş verilerden faydalanılarak tamamlanmış projelerden elde edebiliriz veya ISBSG gibi proje dışı kıyaslama yapılabilecek kaynaklardan faydalanabiliriz.

Bir yazılım projesinde sadece yazılımı geliştirmek değil ayrıca analiz, tasarım, test, belgelerin hazırlanması, prototiplerin uygulanması gibi birçok efor bulunur. Projenin efor kestirimi de gerçekleştirmemiz gereken tüm faaliyetleri belirleyip tahminlerini toplayarak ortaya çıkar.

Efor kestirimi ya geçmiş verileri kullanarak yeni proje hakkında tahminler gerçekleştirilerek yapılır ya da deneyim sahibi kişilerin rehberliğinde tahminler ortaya çıkarılır.

Bu yöntem ile ilgili kullanılan yaygın olarak bilinen yazılımda efor kestirimi (effort estimation) modelleri de şunlardır:

• Wideband Delphi süreci
• COCOMO modeli
• User story points – Planning Poker

Efor kestirimini bu yöntemler üzerinden detaylı inceleyeceğiz. Literatürde yazılım geliştirme takvim ve maliyetlerini tahmin etmek için geliştirilen teknikleri iki yaklaşımda gruplandırabiliriz: top-down estimation (yukarıdan aşağıya yaklaşım, tümdengelim) ve bottom-up estimation (aşağıdan yukarıya yaklaşım, tümevarım.)

Yukarıdan Aşağıya Tahmin Yaklaşımı (Top-Down Estimation)

Yukarıdan aşağıya yaklaşımda, genel projenin tahmini, ürünün bütününden başlanarak türetilir. Toplam tahmini maliyet; farklı proje fazlarına ve farklı modüllere bölünerek hesaplanır. Buradaki modeller yazılımın verilen özelliklerine göre efor, maliyet ve zamanlamayı tahmin etmeye yardımcı olan modellerdir.

Bu yaklaşım aynı zamanda adım adım iyileştirme veya ayrıştırma olarak da bilinir çünkü bu yaklaşım tüm yazılım sistemini tek bir varlık olarak alır ve bazı özelliklere dayalı olarak birden fazla alt sistem elde etmek için ayrıştırır.

Bu yöntemde kullanılan yazılımın 2 temel özelliği vardır: birincisi yazılımın boyutu (software size) diğeri yazılımın karmaşıklığıdır (software complexity).

Normalde, problemin nasıl çözüleceği konusunda benzer projelerden edinilen deneyimlere dayanarak çok az bilginin olduğu planlama aşamasında kullanılır. Proje kontrolüne çok uygun değildir. Bazı yaygın maliyet/takvim modelleri şunlardır:

• COCOMO — Bununla ilgili inceleyebileceğiniz örnek araç (tool): Costar, Revic, Softcost
• Putnam’s Model — Bununla ilgili örnek araç: SLIM
• Shen and Conti — Bununla ilgili örnek araç: COPMO
• Lockheed/Martin — Bununla ilgili örnek araç: Price-S

Bu yaklaşım sistem mimarisi ve sistemin parçası olabilecek bileşenler hakkında bilgi sahibi olmadan kullanılabilir. Entegrasyon, konfigürasyon yönetimi ve dokümantasyon gibi maliyetleri dikkate alır. Zor ve düşük seviyeli teknik sorunları çözmenin maliyetini göz ardı edebilir veya tahminini düşük tutar.

Aşağıdan Yukarıya Tahmin Yaklaşımı (Bottom-Up Estimation)

Bu yaklaşım en temel bileşenlerin tasarlanmasıyla başlar ve bu alt düzey bileşenleri kullanan daha üst düzey bileşenlere doğru ilerler.

Aşağıdan yukarıya yaklaşımda her bir bileşenin maliyeti, bileşenin geliştirilmesinden sorumlu olacak kişi tarafından tahmin edilir. Projenin genel maliyet tahminini elde etmek için bireysel tahmini maliyetler toplanır. Burada proje ekibi üyeleri görevleri tanımlar ardından bunları belirli gruplar halinde düzenler. Tüm proje ekibi gerekli tüm görevler üzerinde beyin fırtınası yapar. Dolayısıyla ayrıntılı bir programla sonuçlanır. Ancak aynı zamanda zaman alan bir yaklaşımdır.

Kısaca, mümkün olan en düşük seviyedeki görevler için efor tahmini yapılır. En önemli işleve ulaşana kadar tahminler toplanır. Efor da üretkenliğe göre büyüklük bulunarak yani efor = büyüklük / verimlilik oranı ile ortaya çıkarılır.

Bu yaklaşım sistemin mimarisi bilindiğinde ve bileşenleri tanımlandığında kullanılabilir. Sistem ayrıntılı olarak tasarlandığı takdirde bu doğru bir yöntem kullanılabilir. Entegrasyon ve dokümantasyon gibi sistem düzeyindeki faaliyetlerin maliyetlerini olduğundan az gösterebilir.

Yazılım Takvim Kestirimi (Schedule Estimation)

Yazılım geliştirme projesini değerlendirmenin, tahmin etmenin üçüncü adımı da efor tahmini üzerinden proje takvimini belirlemektir. Bu genellikle proje üzerinde çalışacak kişilerin sayısını, ne üzerinde çalışacaklarını, proje üzerinde çalışmaya ne zaman başlayacaklarını ve ne zaman bitireceklerini kestirme işlemidir.

Bu bilgilere sahip olduğumuzda, bunu bir takvim planına yerleştirebiliriz. Kuruluşun geçmiş projelerinden veya sektör veri modellerinden elde edilen geçmiş veriler, belirli bir büyüklükteki bir proje için ihtiyaç duyacağımız kişi sayısını ve işin bir programa nasıl bölünebileceğini tahmin etmek için kullanılabilir. Takvimde planlama yapılırken burada kestirim yapılan esas alan geliştirmenin ne kadar süreceğidir.

Yazılım Maliyet Kestirimi (Cost Estimation)

Bir projenin maliyetini değerlendirirken dikkate alınması gereken birçok faktör vardır. Burada bizi ilgilendiren kısım aslında yazılım geliştirme maliyeti yani sağlanacak efor olduğu için bu kısmı efor kestirimi ile birlikte değerlendirebiliriz.

Yazılım Kestirimi ile İlgili Bazı Öneriler

» Uygun yazılım projesi kestirimi yapmak için yeterli zamanı ayırma gerekir. Hatta büyük geliştirme projeleri için yazılım tahmin adımı küçük bir proje olarak değerlendirilebilir.

» Geliştiriciler üzerinden kestirime odaklanın. İşin içindeki çalışanların daha fazla faydası olacaktır.

» Geçmiş verileri mümkün olduğunca kullanmaya çalışın. Bu veriler doğruluk oranını artıracaktır.

» Projeyi yaşam döngüsü boyunca bir değil birkaç kez kestirim işlemi yapın. Ürünü daha ayrıntılı belirtildikçe tahminleriniz de projeyi tamamlamak için gerçekte kullanacağınız değere yaklaşmaya başlamalıdır.

» Yazılım kestirim araçlarından faydalanabilirsiniz. Bu araçlar manuel olarak çok fazla zaman alacak karmaşık modelleri çok daha kolay uygulayabilirler.

» Farklı yazılım kestirim yöntemlerini kullanın ve sonuçları karşılaştırın.

» Standart kestirim prosedürü oluşturun veya var olanı kullanın.

» Yazılım projesi kestirimi için mevcut sürecin iyileştirilmesi için de efor harcayın. Örneğin her proje tamamlandığında gerçekleşenlerle yapılan kestirimleri karşılaştırın.