Önceki yazılarda genel olarak efor tahmini tanımı yapılmış, ne tür bir kapsamın söz konusu olduğu üzerinde giriş mahiyetinde durulmuştur. Bu yazıda efor tahmininde kullanılan bazı yöntemler üzerinde durulacak, bu yöntemlerin özellikleri, eksik/güçlü yönleri değerlendirilecektir. Aynı zamanda proje yönetimi süreçlerinde, iş geliştirmede hangi aşamalarda bu modellerin nasıl entegre olabileceğine dair fikirler sunulacaktır.
Daha önce de ifade edildiği gibi, efor tahmininde üç ana yaklaşım vardır. Parametrik/fonksiyonel modellerde; COCOMO, function point, uzman görüşünde WBS tabanlı ya da grup ölçeğinde karşılaştırmalı tahminleme modelleri daha çok bilinen modellerdir. Kombinasyon tabanlı modeller de diğer iki yaklaşımdaki modellerin belli sistematiğe göre kurgulanması şeklinde olduğu için kombinasyon tabanlı modellere doğrudan bir örnek verilmeyecektir. Aynı zamanda, efor tahmininde geçmiş verilerin kullanılması (şirket içi/dışı) tahmin başarısını etkileyeceği için, bu modellerle beraber veri madenciliği ve makine öğrenmesi yöntemleri de değerlendirilecektir.
Fonksiyonel modelde seçilen örnekler COCOMO ve Function Point olmuştur çünkü bu iki model genel itibariyle en çok bilinenlerdendir. Bu modeller üzerinden yapılacak yaklaşım seviyesindeki çıkarımlar, diğer olası modeller için de sağlanmış olacaktır. Buna rağmen her bir modelin kendi karakteristik özelliklerinde bazı farklılıklar olduğu da unutulmamalıdır.
COCOMO
COCOMO, bir hesaplama fonksiyonu olarak görülebilir. Basit bir fomül şeklide verilmiş, belli parametreleri ve bu parametrelerin bazı çevresel değişkenlere bağlı alabileceği değer aralıkları belirlenmiştir. Efor tahmini sürecinde, dolayısıyla, COCOMO kullanıldığında birkaç durum göze çarpar: ilki, modelin kendisi basit bir matematiksel denklem olduğundan hesaplanması kolaydır. Hesaplanılan değerleri fuzzy algoritmaları içermediği için tahmin değeri kesin sayı olacaktır. Ancak, hesaplamada kullanılacak parametrelerin geçerli aralıkta hangi değerleri alacağını belirlemek önemlidir. Örneğin modelde verilen personel profili için yetkinlik seviyesi ne derece yüksek belirlenecektir ya da entegrasyon ihtiyacı/karmaşıklığı nasıl belirlenecektir? Bu tip sorular, COCOMO içerisinde ön çalışma ihtiyacının, çoğunlukla her projede tekraren yapılması gerekliliğini ortaya çıkarmaktadır. Ancak, kurumsal hafıza kapsamında şirketler/organizasyonlar kendileri, geliştirme ortamları ve ekipleri için belirledikleri değerleri saklayıp, her bir efor tahmin sürecinde tekrar kullanabilirler (düzenli revize edilmesi şartıyla). Burada bir başka konu ortaya çıkmaktadır. İlgili parametrelerin doğru değerlerde olduğu nasıl anlaşılacaktır? Bunun için de aslında yazılım kalite, yetkinlik ve olgunluk modellerine başvurulabilir. Her ne kadar süreçler içiçe geçip çok katmanlı bir yapıya dönüşüyor gibi gözükse de, planlamanın temel şartı olan zaman ve maliyet hesapları söz konusu olduğunda, iş yapış süreçlerine bu tip eklentilerin dahil edilmesi önem arz etmektedir.
COCOMO içerisinde satır sayısı (LOC) kavramı, belki de fonksiyonun en önemli parçasıdır. Bir önceki yazıda da ifade edildiği gibi, satır sayısı ifadesi tartışmalı bir konudur. Özellikle modern yazılım geliştirme ortamları, kütüphaneleri, servislerinin olduğu bir zamanda işlenecek satır sayısının hesabı zorlaşmaktadır. Nasıl ki modeldeki parametrelerin alacağı değerleri hesaplamada tutarlı bir yaklaşıma ve ön çalışmaya ihtiyaç varsa, satır sayısını da hesaplamada bu tür bir işleme ihtiyaç vardır. Bir yazılım geliştirme projesinin en temel unsuru, neticede, geliştirilen kod olacağı için, aslında süreç sonundaki temel çıktılardan biri de yazılan kod olacaktır. Bu bakış açısıyla, sonuçta ortaya çıkacak ve fakat asli unsur olan satır sayısının tahmini çok kolay olmamaktadır. İşlenecek satır sayısı, 1000 satır başına maliyet gibi farklı yaklaşımlar olsa da neticede bir noktada yazılacak kod miktarı sayısal olarak hesaplanacak ve bu hesaplama doğrudan satır adedine bağlı olacaktır. Modelin ortaya atıldığı yıllarda kullanılan programlama dilleri için belki satır sayısı tahmini daha anlamlıdır ancak günümüzde gelişmiş programlama dillerinde bu işlemi yapmak zordur. COCOMO nun en sorunlu noktası da bu satır sayısı hesaplamasıdır.
FUNCTION POINT
Genel itibariyle, COCOMO için yazılanlar, Function Point için de geçerlidir. Ancak burada bazı farklılıklar vardır. Önceki modelde satır sayısı tabanlı, daha düşük seviye bir tahmin parametresi varken, FP içinde iş kuralı seviyesinde yani daha üst bir parametre vardır. Bununla beraber, FP için temel sorun, bu iş kurallarının ne ölçü ve ölçekte olacağıdır. Yine tutarlılık prensibine göre iş kurallarının ne ölçüde detaylı ya da genelleştirilmiş olacağı belirlendikten sonra kurum/şirket genelinde yapılan tahminler birbirini destekleyecek seviyede olacaktır ancak, iş kuralı ayrımları da ciddi bir ön çalışma gerektirmektedir. COCOMO içerisindeki sayısal çarpanlar yerine burada biraz daha ihtiyaçlar seviyesine yakın hesaplar devreye girecektir ancak yine de hesaplama için model içerisinde bazı parametreler devreye girecektir. İş kuralının girdi/çıktı etkileri, özellik ekleme/geliştirme etkileri gibi farklı parametrelerle bu model daha verimli hale gelmektedir. Satır sayısı ifadesinden kurtulduğu için de model bir bakıma daha avantajlı ve esnek tahminleme sunmaktadır.
Uzman görüşüne göre tahminlemede WBS ve grup tahminleri örnekleri verilmişti. Grup tahminleri denildiğinde de ilk akla gelen, son dönemin güncel yazılım geliştirme metodolojisi üzerinden gidersek, planning poker olacaktır. Agile süreçlerde her bir sprint içerisinde hangi backlog nesnesinin alınabileceği, ağırlıklı olarak puanlandırılmış kartlarla yapılmaktadır. Burada doğrudan ilgili iş için bir fonksiyonel tahmin, sayısal bir efor değeri çıkmaz ancak işin büyüklüğü, karşılaştırma yöntemiyle ortaya konur. Grup içerisinde yani agile ekip içerisindeki ilgili kişiler, o iş için gerekecek zamanı oransal olarak tahminler ve grup tu tahminleri karşılaştırarak ortak bir paydada buluşur. Tahmini gerçekleştiren her birey, aynı zamanda agile ekipte o işin geliştirmesinden birinci derecede sorumlu olduğu için uzman sayılabilir. Ekipte nispeten tecrübesiz ya da ilgili domain hakkında tecrübesiz olanlar da grup ölçeğindeki tahmin sürecinde eğitilmiş olur ve olası yanlış tahmin etkisi de minimize edilmiş olur. Bu noktada agile süreçlerin daha küçük parçaların çıktı olarak üretilmesine odaklandığı, dolayısıyla tahmin edeceği eforun çok daha yönetilebilen parçalar için olacağı unutulmamalıdır. Bu nedenle karşılaştırmalı tahminler sorun çıkarmamaktadır. Bir diğer örnek, WBS ise daha klasik bir yöntem olarak düşünülebilir. Yapılacak işleri belli bir sistematikle alt parçalara bölerek (birbirine bağlı fonksiyonlar, birbirini etkileyen özellikler vs..) tahmin edilecek payın küçültülmesi sağlanır. Bu şekilde her bir blok ya da parça için verilen tahmin değerleri toplamı da ilgili proje için gerekli efor değerini verecektir. İş kırılımlarının çıkarılması, agile örneğinden farklı olarak daha kapsamlı ve maliyetli olacaktır. Ek olarak, yapısal bir bütün çıkarılacağı için ihtiyaç duyulan uzmanlık daha fazladır. Bu tecrübedeki kişilerin ortaya koyacağı değerlendirmeler ve sayısal karşılıkları, neticede efor tahmini olacaktır.
Tüm yaklaşım ve modellerde, dikkat edilirse bir geçmiş bilgi/tecrübe kullanımı vardır. Bu bilgi, şirketin önceden yaptığı projeler, devam eden benzer projeler, farklı şirketlerin yaptığı ve bu tip bilgilerin paylaşıldığı projeler, danışmanlık alınan kişilerin tecrübeleri gibi birçok farklı kaynaktan gelebilir. Aynı zamanda şirket içinde birtakım ölçümler, standartlarla da tahmin süreci daha efektif hale getirilebilir. Örneğin, geliştirme ortamı sık değişen bir durum değildir. Buna bağlı tahminlerde standart bir ölçek verilebilir. Benzer şekilde, iş kurallarının öncekilerle mukayesesi neticesinde bazı sınıflandırmalar verilebilir. Bu tip işlemlerin yapılabilmesi için de, efor tahmininin sadece projenin ilgili safhasında yapılıp bitirilmemesi, plan-do-check-act yaklaşımına da uyarak, öncelikle tahmin ile gerçekleşen arasındaki ilişkinin takibinin sağlanması ve daha doğru tahminler için de sürekli geri bildirim olacak şekilde, geliştirme akışının ana unsurlarından biri olması sağlanmalıdır. Zaten yazılım geliştiriciler her bir iş için ihtiyaç duyacakları zamanı kabaca hesaplamaktadır ve iş akışına bu tip standartların getirilmesi, muhalefet edilecek bir durum olmayacaktır. Ancak, sürecin içerisinde, sadece tahminleme için gerekli ve yeterli miktarda yük oluşturmak, buna göre veri toplamak önemlidir. Aksi durumda tahminlerin başarı oranı değişkenlik arz edecektir. Ek olarak, her tahminin ve gerçekleşen değerin ilgili paydaşlara iletilmesi ve değerlendirilmesinin yapılabilmesinin sağlanması, her bireyin kendi sorumluluğu ölçüsünde tahminlemeye artı değer katacaktır.
İş akışlarına efor tahmini adımları eklenmesi sadece bir süreç maddesi olarak değil, ay
nı zamanda geri besleme de sağlayacak ölçüde, mümkünse standart bir yapıda, projeler ile ilgili bazı verileri de içermelidir. Bu durum, seçilen modele göre tespit edilmeli, modelin ihtiyaç duyacağı parametrelerin sağlandığı ve gerekiyorsa destek parametrelerinin de yer aldığı bilgiler projenin ilgili aşamalarında saklanmalıdır. Daha sonra bu bilgiler üzerinde yapılabilecek analiz çalışmaları, tahmin sürecine katkı sağlayacağı gibi, geliştirme ile tahmin arasında ortaya çıkacak farklılıkların kaynağı, nerede daha tutarlı olunduğu ve nerede saplamaların daha çok yaşandığı gibi, kalite ve iyileştirme adımlarına da ciddi bir girdi olacaktır.
Sonuç olarak, efor tahmini sadece bir görece sayısal değer üretimi olarak düşünülmemeli, şartlara göre en uygun model seçilmeli (kurum, kültür, proje türü, alan vs..) ve bu model temel yapı kabul edilerek, iyileştirmelerle tahmin işlemi bir içselleştirilmiş süreç haline getirilmelidir. Basit bir tahminleme adımından , daha sistematik ve takip edilebilir sürece dönüldüğünde, hem planlama/takip, hem de kalite anlamında ciddi getirilerin olduğu görülecektir.
