Yazılım çaba tahmini

**Yazılım çaba tahmini**, bir yazılım projesi veya içindeki belirli görevleri tamamlamak için gereken zamanı, çabayı ve kaynakları tahmin etme sürecidir. Doğru tahmin, proje başarısızlığına yol açabilecek zamanlama ve bütçe sorunlarını önlemeye yardımcı olur. Maliyet tahmini, çaba tahmini ile birlikte, eksik, belirsiz ve gürültülü girdilere dayanarak bir yazılımı geliştirmek veya sürdürmek için gereken en gerçekçi çaba miktarını (kişi-saat veya maliyet olarak) tahmin etme sürecidir. Bu tahminler, proje planları, yineleme planları, bütçeler, yatırım analizleri, fiyatlandırma süreçleri ve teklif aşamalarında önemli bir girdi olarak kullanılır. Ayrıca yazılım geliştirme çaba tahmini, yöneticilerin bir yazılım bakım projesini planlamalarına ve maliyet-fayda analizi yapmalarına yardımcı olan değerli ve önemli bir görevdir.

## Yazılım Çaba Tahmini Önemi
Çaba tahmini, projeyi planlamak için gereken zaman ve kaynaklar konusunda hem proje ekibine hem de ürün sahibine güven sağlar, bu da projenin başarılı bir şekilde yürütülmesi için çok önemlidir. Ayrıca, tüm yazılım projeleri zaman ve kaynak bazlı sözleşmelerle yönetilmez; bazı projeler sabit maliyetli olabilir. Bu tür projelerde, yapılan tahminler, proje maliyetini müzakere etmek ve doğru bir bütçe oluşturmak için temel bir referans olarak kullanılır.

* Risk yönetimi ve aksiyonlar
* Ekip içi iletişim
* Doğru kaynak tahsisi
* Takım psikolojisi
* Paydaş beklentilerinin yönetimi
* Ürün kalitesi ve teknik borç gibi nedenlerin netlik kazanması adına çaba tahmini yapılması önemlidir. Kafa karışıklığı ve belirsizlikleri gidererek daha uygun bir çalışma ortamı sağlanmalıdır.

## Tahminlerin Belirsizliği ve Varsayımlar
Yazılım çaba tahminler yapılırken parametrelerin belirsizliği nedeni ile tahminlerin bazı kısımlarında belirsizlikler ortaya çıkabilir. Bu belirsizliklerin en büyük sebeplerinden biri yazılım teknolojilerinin hızla gelişmesidir. Tahminlerdeki belirsizlikler iki ana başlık altında ele alınabilir:

# **Bilinen bilinmeyenler:**
#* Doğal Afetler
#* Salgınlar
#* Zamanla yetenek kaybı, kodlamanın unutulması
#* Güncel olmayan ve güvenlik açığı bulunan kod
# **Bilinmeyen bilinmezler:⇒**Tahmin etmek daha zordur.
#* Kullanıcı isteklerinde oluşan değişiklikler
#* Kullanıcıların kullanamadıkları yeni teknolojiler

## Psikolojik Sorunlar
Aşırı iyimser çaba tahminlerine yönelik güçlü eğilimi açıklayan birçok psikolojik faktör vardır. Bu faktörler, resmi tahmin modelleri kullanılırken bile dikkate alınması gereken temel faktörlerdir, çünkü yazılım çaba tahmin modellerine girdinin çoğu yargıya dayalıdır. Önemli olduğu gösterilen faktörler arasında hayalperest düşünce, düşüncelere bağlanma, planlama yanılgısı ve bilişsel uyumsuzluk bulunur. Unutulmamalıdır ki;

* Bilinenleri tahmin etmek kolaydır.
* Bilinen şeyin bilinmediğini tahmin etmek zordur. (bilinen bilinmeyenler)
* Bilinmeyenin bilinmediğini tahmin etmek çok zordur. (bilinmeyen bilinmeyenler)

## Tahmin Teknikleri
Yazılım geliştirmenin sürekli değişen yapısı dikkate alındığında, yazılım tahmini yapmak oldukça zordur ama geliştiriciler güvenilir ve tutarlı tahminler elde etmek için çeşitli teknikler kullanırlar. Bu teknikler üzerine yapılan anketler, yazılım geliştirme çabası tahmininde en çok tercih edilen yöntemin  uzman tahmini olduğun göstermektedir. Tahminler yapılırken bazı teknikler kullanılır. Tahmin yaklaşımlarını kategorize etmenin birçok yolu vardır, örneklendirmeler için bkz. Bu teknikleri aşağıdaki gibi sıralanabilir:

* **Uzman Kararı:**  Yukarıda belirtildiği gibi, bu teknik deneyim ve bilgiye dayalı tahminler sağlamak için deneyimli kişilere danışmayı içerir. Bu kişilerden alınan süreç bilgileri ile tahminler oluşturulur. En çok tercih edilen yöntemlerdendir.
* **Aşağıdan Yukarıya Tahmin:** Bu teknikte, proje daha küçük ve yönetilebilir bileşenlere parçalanır ve her bir bileşenin tamamlanması için gereken çaba tahmin edilir.
* **Üç Nokta Tahmini:** Bu teknikte, beklenen çaba, üç tahminin ağırlıklı ortalaması kullanılarak hesaplanır: en iyimser, en kötümser ve en olası. Her olasılık göz önüne alındığından gerçeğe yaklaşılabilme ihtimali yüksektir.
* **Planlama Pokeri(Planning Poker):** Üç nokta tahmininin bir varyasyonu olan bu teknik, ekip üyelerinin kullanıcı hikâyelerine veya özelliklere göreceli büyüklükler atamak için kart oyunu oynadığı bir süreçtir.
* **[[Çevik öğrenme|Çevik Hikâye]] Puanları(Agile Story Points):** Bu teknikte, kullanıcı hikâyelerine veya özelliklere, mutlak saatler veya günler yerine, karmaşıklık ve gereken çabaya göre göreceli bir büyüklük atanır.
* Resmi Tahmin Modeli: Nicelleştirme adımı mekanik süreçlere dayanır, örneğin geçmiş verilerden türetilen bir formülün kullanımı.
* **Kombinasyona Dayalı Tahmin:** Nicelleştirme adımı, farklı kaynaklardan gelen tahminlerin yargısal ve mekanik bir kombinasyonuna dayanır.

Her tekniğin avantajları ve dezavantajları vardır ve hangi tekniğin seçileceği genellikle projenin özel gereksinimlerine ve ekibin uzmanlık düzeyine bağlıdır. Günümüzde ise problemler, en iyi sonuçlara ulaşmak ve süreçleri optimize etmek amacıyla genellikle matematiksel modellere dönüştürülmekte ve her biri makine öğrenmesi kapsamında yenilikler getirilerek çözülmeye çalışılmaktadır.

## Tarihsel Gelişimi
Yazılım geliştiricileri, en azından 1960'lardan beri yazılım geliştirme projeleri için çaba tahmini sorunlarını ele alıyorlar. Bu konuda ilk çalışan insanlardan örnek verilecek olursa Farr and Nelson ile örneklendirebiliriz.

Araştırmaların büyük çoğunluğu, yazılım geliştirmede çaba tahmin modellerinin oluşturulmasına odaklanmıştır. İlk tahmin modelleri, genellikle regresyon analizine dayanıyor veya diğer disiplinlerdeki teorilerden matematiksel olarak türetiliyordu. Bu yaklaşımlar, yazılım projelerinin karmaşıklığını anlamak ve tahmin yapmak için ilk adımları oluşturdu. O zamandan beri, vaka tabanlı akıl yürütme, sınıflandırma ve regresyon ağaçları, simülasyon, sinir ağları, Bayes istatistikleri, gereksinim özelliklerinin sözcüksel analizi, genetik programlama, doğrusal programlama, ekonomik üretim modelleri, yumuşak hesaplama, bulanık mantık modelleme, istatistiksel önyükleme gibi birçok modelleme yaklaşımı değerlendirilmiştir. Ayrıca, bu tekniklerin ikisinin veya daha fazlasının kombinasyonları, daha karmaşık ve uyarlanabilir modellerin geliştirilmesine yol açmıştır.

Ayrıca, işlevselliğe dayalı boyut ölçümlerine dayanan tahmin yaklaşımları, örneğin işlev noktaları, 1970'ler ve 1980'lerdeki araştırmalardan türemiştir. Ancak, bu yaklaşımlar zamanla gelişerek, kullanım durumu noktaları, nesne noktaları ve 1990'lardaki COSMIC İşlev Noktaları gibi farklı sayma teknikleri ile yeniden kalibre edilmiştir. Günümüzde bu ölçüm yöntemleri, modern yazılım geliştirme projelerinde karmaşıklığın daha doğru bir şekilde tahmin edilmesi için yaygın olarak kullanılmaktadır

Son yıllarda, **[[Yapay zekâ|yapay zeka]]** ve **[[Makine öğrenimi|makine öğrenmesi]]** tekniklerinin tahmin süreçlerine entegrasyonu da önemli bir yenilik olarak ortaya çıkmıştır. Özellikle, büyük veri setlerinden öğrenme yeteneği sayesinde, makine öğrenimi tabanlı modeller yazılım projelerinde daha doğru tahminler sağlamaktadır. Bu gelişmeler, yazılım çaba tahminlerinin doğruluğunu artırmayı ve projelerin başarı oranlarını yükseltmeyi hedeflemektedir.

## Tahmin İçin Kullanılan En Yaygın Modeller
Yazılım geliştirme çabasını ve maliyetlerini tahmin etmek için birçok model bulunmaktadır. COCOMO (Yapıcı Maliyet Modeli)  en yaygın kullanılan modeldir.

### Yapıcı Maliyet Modeli ( COCOMO )
Barry W. Boehm tarafından geliştirilen bir yazılım maliyet tahmin yöntemi olarak bilinir ve belirli adımlar içerir. Bu model, yazılımın boyutunu, kaynak kod satırlarının (KLOC) binlerce satır olarak ölçülmesiyle değerlendirir. COCOMO, geliştirme çabasını ve süresini tahmin etmek için kullanılır. COCOMO modeli, üç farklı yazılım projesi türüne uygulanabilir.

* **Organik projeler**: Daha az katı gereksinimlerle çalışabilen, küçük ve deneyimli ekipler tarafından yönetilen projeler.
* **Yarı bağımsız projeler**: Katı ve esnek gereksinimlerin bir arada bulunduğu projeler olup, karışık deneyime sahip orta büyüklükteki ekipler tarafından yürütülür.
* **Gömülü projeler**: Katı kısıtlamalar altında geliştirilen projelerdir ve organik ve yarı bağımsız projelerin birleşimi olarak düşünülebilir. (donanım, yazılım, operasyonel gereksinimler gibi farklı unsurları içerir).

Tahmin yaklaşımlarını kategorize etmenin birçok yolu vardır. &nbsp;En üst düzey kategoriler ve her kategorideki tahmin yaklaşımlarına dair örnekler verilmiştir:

## Uygulama Durumu
Genellikle, çaba tahminleri aşırı iyimserdir ve bu tahminlerin doğruluğuna karşı güçlü bir güven vardır. Ortalama çaba aşımı yaklaşık %30 gibi görünmekte olup, bu oran zamanla azalmamaktadır. Çaba tahmini hatalarını inceleyen anketlerle ilgili bir inceleme için bkz. adresine bakabilirsiniz. Ancak, tahmin hatalarının ölçülmesi sorunlu bir süreçtir, bu konuda daha fazla bilgi için "Tahminlerin Doğruluğunu Değerlendirmek" başlığına bakabilirsiniz. Çaba tahminlerinin doğruluğuna duyulan aşırı güven, şu bulguyla ortaya konulmaktadır: Bir yazılım uzmanı, tahmin edilen minimum-maksimum aralığa gerçek çabanın dahil olacağına %90 emin ya da "neredeyse kesin" olduğunda, gerçekte bu aralığa girme oranı yalnızca %60-70'tir.

Günümüzde "çaba tahmini" terimi, genellikle farklı kavramları ifade etmek için kullanılmaktadır; en olası çaba (mod değer), aşılma olasılığı %50 olan çaba (medyan), planlanan çaba, bütçelenen çaba veya müşteriye teklif sunmak ya da fiyat belirlemek için kullanılan çaba. Bu durumun talihsiz olduğu düşünülmektedir, çünkü bu farklı kavramlar arasında iletişim sorunlarına yol açabilir ve her biri farklı amaçlara hizmet eder.

## Uygun Tahmin Yöntemi Seçimi
Çaba tahmini sadece bir tahminden daha fazlasıdır; yazılım projelerinin  başarısını önemli ölçüde etkileyebilecek stratejik bir süreçtir. Doğru çaba tahmini, projelerin belirlenen zaman çizelgeleri içinde tamamlanmasını, kaynakların verimli bir şekilde kullanılmasını ve genel proje yönetim sürecinin kolaylaştırılmasını sağlar.

Ancak, çaba tahmini süreci karmaşık olabilir ve çeşitli yöntem ve teknikleri içerebilir. Uygun yöntemi belirleyebilmek için;

* Proje kapsamı
* Kaynaklar
* Potansiyel zorluklar
* Ekip becerisi gibi konularda önceden bilgi sahibi olmak gerekir.

## Tahmin Süreci Adımları

Yukarıda bahsedildiği üzere tahmin etme işlemi belli başlı bir süreçtir. Bu süreç belirli adımlardan oluşur.

**1.Kapsam Belirleme**: Proje kapsamı, proje hedefleri, teslimatların, görevlerin, maliyetin ve son tarihlerin bir listesini belirlemeyi ve belgelemeyi içeren proje planlamasının bir parçasıdır. Bu adımda en kritik nokta ise paydaşların aynı fikirde olmasıdır.

**2.Parçalara Ayırma:** Bu aşamada ise projenin yazılımı küçük parçalara ayrılmalı ve sistematik olarak mantığa sahip olmalıdır. Zaman ve iş maliyetini sistematik olarak parçalamak işi kolaylaştıracaktır.

**3.Boyutlandırma:** Her bir  parça için gerçek değere en uygun maliyetlendirme yapılan aşamadır.

**4.Uzman Değerlendirmesi:** İlk tahmin sonrası gözden kaçırılan şeylerin tekrar değerlendirilmesi için uzaman görüşüne ihtiyaç duyulur. Bu adımda ise uzamandan genel bir değerlendirme istenilir.

**5.Tahminin Sonlandırılması:** Tüm adımların son aşamasıdır. Ancak en doğru tahmini elde etmek amacı ile bu adımdan sonra tekrar başa dönülebilir.

Yandaki şemada bu işlem adımları net olarak gözükmektedir.

## Gelişim Tahmin Yazılımlarının Karşılaştırılması

## Mizahi Bakış Açısı ile Yazılım Çaba Tahmini
Geliştirme çabasının kronik olarak küçümsenmesi, bir görevden ironik bir şekilde " küçük bir programlama meselesi " olarak bahsetmek (çok fazla çaba gerektirse bile) ve küçümsemeyle ilgili yasalara atıfta bulunmak gibi çok sayıda esprili atasözünün ortaya çıkmasına ve popülerleşmesine yol açmıştır:

* Doksan-doksan kuralı:

Kodun ilk %90'ı geliştirme süresinin ilk %90'ını oluşturur. Kodun kalan %10'u geliştirme süresinin diğer %90'ını oluşturur.

—&hairsp; Tom Cargill, Bell Laboratuvarları

* Hofstadter yasası:

Hofstadter Yasası: Hofstadter Yasası'nı hesaba kattığınızda bile, her zaman beklediğinizden daha uzun sürer



* Fred Brooks yasası:

Bir programcının bir ayda yaptığını iki programcı iki ayda yapabiliyor.

—Fred&hairsp; Brooks

## Kaynakça