Yazılım efor tahmini, yeni bir yazılımın geliştirilmesi, mevcut bir yazılıma özellikler eklenmesi ya da mevcut bir yazılıma bakım çalışmalarının yapılması için gerekecek zaman/maliyet değerini, proje başlangıç aşamasında ya da planlama aşamalarında, eksik, belirsiz ya da hata ihtimali olan veri üzerinde hesaplamak olarak tanımlanmaktadır. Tanımdaki önemli nokta, tahmin sürecinin proje başlangıç aşamalarında yapıldığı gerçeğidir. Bu nedenle, ihtiyaçlar ve geliştirme detaylarının kestiriminin zor olduğu bir aşamada tahmin için kullanılan veriler de eksik/belirsiz olmaktadır.
Tahmin işleminin doğası gereği, eksik veriyi anlamlı bir yapıya kazandırmak ve buna göre çıkarımlarda bulunmak önemlidir. Bu bakış açısıyla, yazılım efor tahmininde farklı yöntemler ve yaklaşımlar geliştirilmiştir. Bu yaklaşımlar, bir önceki yazıda da ifade edildiği gibi, temelde 3 grubu ayrılabilir:
- Uzman görüşüne dayalı modeller
- Parametrik/formal modeller
- Hibrit/kombinasyon tabanlı modeller
Uzman Görüşe Dayalı Model
Uzman görüşüne dayalı modellerde yazılımın bir uzman kişi ya da ekipler aracılığıyla, belli standartlar ve/veya araçlar kullanılarak değerlendirme sürecinden geçirilmesi yaklaşımı vardır. Bu model altında örnek olarak iş kırılım yapısı (WBS) üzerinde tahminleme işlemi verilebilir. WBS, projenin belli bir seviyede belli mantıksal ve yapısal dilimlere bölünmesi işlemidir. WBS çıkarılırken aşağıdan yukarıya ya da yukarıdan aşağıya yaklaşımlarından biri tercih edilebilir. Her iki durumda da neticede yapılacak iş için gerekli olası alt parçalar bulunur. Bu parçaların ihtiyaç duyduğu efor değerleri toplanarak bir bütün oluşturulabilir. WBS, PMI tarafından standart planlama süreçlerine dahil edilen bir yöntemdir Sadece tahminleme için değil, iş parçalarını planlama ve yönetme için de aktif olarak kullanılmaktadır.
Parametrik/Formal Model
Parametrik ya da formal modeller, temelde bir matematiksel formül ya da eşitlikler kümesine göre tahminleme yapmayı ifade eder. Bu yaklaşımda yapılacak geliştirmenin birtakım standart ölçek ve ölçülere göre değerlendirilmesi ve bu değerlerin birleştirilmesi işlemleri vardır. Örnek olarak COCOMO verilebilir. Öncelikle yazılımın karakteristiği, ortam özellikleri, personel profili gibi birkaç ana başlık altında değerlendirmeler yapılmaktadır. Her bir başlık ve alt başlık için standart değer aralıkları vardır. Projeye göre bu değer aralıklarından uygun olanlar seçilir. Sonuçla bir katsayılar kümesi oluşturulur (EAF). Bu değer daha sonra yazılım için ihtiyaç duyulacak satır sayıyla (LOC) oransal olarak çarpılır ve neticede ihtiyaç duyulan efor değeri sayısal olarak çıkarılır. Bir diğer örnek olarak function point analysis (FPA) verilebilir. COCOMO da satır sayısı üzerinden bir büyüklük hesaplanıyorken bu modelde geliştirilmesi gereken iş kuralı parçaları ve değerleri üzerinden hesaplama yapılır.
Hibrit/Kombinasyon Tabanlı Model
Kombinasyon tabanlı modellerde ise adından da anlaşılabileceği gibi, diğer iki yaklaşımın belli bir düzenle birleştirilerek kullanılması esası vardır. Örneğin WBS ile oluşturulan parçalar üzerinden, parametrik bir model seçerek tahminler üretilebilir. WBS ile çıkarılan iş parçaları FPA ile değerlendirip bir tahmin üretilebilir.
Her bir yaklaşımda birçok farklı yöntem, bu yöntemlerin uygulanmasında da bazı araçlar mevcuttur. Her teknik için birtakım avantaj ve dezavantajlar vardır. Ancak, genel olarak değerlendirildiğinde, amacın tahmin değerini mümkün olan en gerçekçi verilerle çıkarılmaya çalışıldığı anlaşılacaktır.
Efor tahmininde yaklaşımlar literatürde yukarıdaki gibi standart bir çerçeve oluşturmakla beraber, tahmin sürecini daha efektif gerçekleştirme ve daha da önemlisi tahmin değerini daha tutarlı hesaplayabilmek için bu yaklaşım ve modeller sürekli geliştirilmektedir.
Barry Boehm
Örneğin, COCOMO B.Boehm tarafından 1981 yılında ortaya atılmış bir yöntemdir. Yöntem, ilgili tarihte gerçekleşen projelerin akademik seviyede incelenmesi, irdelenmesi ve karşılaştırılması sonucunda ortaya çıkmıştır. Model içerisinde geçen nitelikler ve aralık değerleri de bu ölçümlerin sonucunda üretilmiştir. Ancak, önerildiği tarihteki yazılım geliştirme teknolojileri, beklentileri ve projelerin türleri, kendisinden sonra değişmiş, çeşitlenmiştir. Bu nedenle model üzerinde güncellemeler yapılmış, hesaplamada eklemeler ve yeni aralıklar düzenlenmiştir. Bu şekilde modern zamanlarda daha makul kabul edilebilecek bazı parametrelerin de kullanılması imkanı oluşmuştur. FPA düşünüldüğünde de benzer bir durum vardır. A.Albrecht tarafından 1979 yılında tanımı yapılan function point ifadesi, yine dönemin yazılım geliştirme çerçevesine göredir. İş ihtiyacı kavramı zamanla değişmeye başlamış, kompleksliğin ne ölçüde olacağı, FP olarak ifade edilecek birimlerin ne kadar kapsamlı ya da daraltılmış olacağı tartışılmıştır.
Efor tahmininde tüm modeller için geçerli olan bir diğer unsur da, geçmiş verilerden faydalanma tercihidir. Her bir şirket/organizasyon, geçmişte kendilerinin yaptığı projelerden ya da diğer firma ve kuruluşların yaptığı projelerden çıkarımlar yapmıştır. Projeler kendilerinden öncekilere benzetilmeye çalışılmış ve bu şekilde daha doğru tahminlerin üretilmesi sağlanmıştır. Dolayısıyla, geçmiş verinin ilgili modellere uygun şekilde entegre edilmesi önem arz etmektedir. Her bir yaklaşım ve model içerisinde, eski verileri girdi olarak kullanmak, modelin kendi yapısına dahil etmek demek olmakla beraber, bir süredir veri madenciliği ve makine öğrenmesi yaklaşımları da efor tahminine dahil edilmiştir. Bu yöntemler doğrudan bir yaklaşım altına alınmayı gerektirmeyecek, herhangi bir modele karar destek sistemi olabilecek ya da girdi sağlayabilecek seviyededir. Her modelin değişen yazılım şartlarından dolayı zamanla ihtiyaç duyduğu girdiler, bu tip yöntemlerde daha etkin olarak sağlanabilmektedir. Özellikle veri madenciliği, tahmin süreçlerine ayrı bir boyut katmaktadır ve bu konu ayrıca detaylandırmayı gerektirecek kadar ehemmiyetlidir.
Efor tahmini, neticede bir tahmin süreci olduğundan ve eksik veri üzerinden anlamlı bir sonuç çıkarılmaya çalışıldığından dolayı bazı sorunları da içermektedir. Yukarıda örneklendirilen herhangi bir model için sorunlu olan ya da eleştirilen birtakım durumlar olduğu açıktır. COCOMO örneğinden gidecek olursak, LOC değerinin hesaplanması ve hatta model içerisinde böyle bir değerin kullanılması en temel eleştiri maddesidir. Tahmin sürecinde yazılımla ilgili bu kadar net bir değerin kullanılması problem teşkil etmektedir. Yazılacak satır sayısını hesap etmek başlı başına bir problemdir. Aynı zamanda satır sayısı kavramı da tartışmalıdır. LOC değeri, yazılımdaki her bir satırı mı ifade eder yoksa işletilecek satırları mı? Kullanılan metoda göre herhangi bir olabilir. Peki, seksenli yıllarda programlama dilleri ve kütüphanelerin görece azlığıyla günümüz yazılım dünyasındaki frameworkler, üst seviye diller ve hatta servis tabanlı entegrasyonlar ne tür bir satır satısı hesaplamasına girecektir? FPA için temel sorun ise, iş kuralı kavramının içini doldurmaktır. Projenin karakteristiğine ve hatta geliştirmenin yapılacağı ortama göre bu değer değişebilir. Proje genelinde iş ihtiyacı olarak denkliği olmayan maddeler nasıl bir oranlamaya tabi tutulacaktır? COCOMO da olduğu gibi, iş ihtiyacı kırılımı, hesaplama yapılabilecek ölçü ve ölçekte planlama sürecinde sağlanabilecek midir? Tüm bu ve benzeri soru ve sorunlar, modeller için eleştiriler olmakla beraber, dikkat edilmesi, geliştirilmesi gereken noktalar olarak da öne çıkmaktadır. Kullanılan modeldeki eksik ya da olası sorunlu noktalar bilinerek hareket edilmeli, tahmin sonucuna buna göre yorumlar eklenmelidir.
Tahmin süreçlerinde önemli bir durum da tek bir model ile yetinmemek, mümkün ölçüde destek sağlayacak sayıda model ve yöntemleri kullanmaktır. Bu şekilde tahminler karşılaştırılır ve doğrulama sağlanmış olur. Aynı zamanda, tahmin değerlerinin sayısal bir ifade olduğu düşünülmeli, olası üst ve alt limitler değerlendirilmelidir. Neticede her bir model, bir tahmin çıktısı üretmektedir ve bu çıktı, belli bir yüzdede geçerlenmiş olacaktır. Dolayısıyla olası değerler kümesiyle hareket etmek akıllıca bir tercih olacaktır. Bu noktada, modellerin başarı oranları konusunu değerlendirmeye almak gerekmektedir. Her bir modelden elde edilen tahmin ve bu tahminlenen projenin gerçek değerleri karşılaştırılmalı ve model için bir sonraki süreçte veri olarak kullanılmalıdır. Bu işlem neticesinde de bir hata yüzdesi değeri çıkmaktadır. Örneğin uzman görüşüne dayalı bir model seçildiğinde, gerçekleşen ile tahmin edilen arasında %15 lik bir fark varsa, sonraki tahminlerde de benzer oranların oluşabileceği düşünülmelidir. Hata oranı ve yüzdesi konuları bu yazıda değerlendirilmiyor olsa da, ölçümlere dahil edilmesi gerektiği hatırlatılmalıdır.
Bu yazıda yazılım efor tahmini ile ilgili tanımsal çatı oluşturulmuştur. Bir sonraki yazıda modellerin özellikleri, artı-eksi yönleri, tahmin değerlerinin tutarlılığının analizi ve proje yönetiminde hangi aşamada nasıl kullanılabileceği konuları değerlendirilecektir.