Kullanıcı:AkcabaIlknur/deneme tahtası
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 . Proje planlamasında en önemli adımdır. Doğru tahmin, proje başarısızlığına yol açabilecek zamanlama ve bütçe sorunlarını önlemeye yardımcı olur.[1] 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.[2][3] 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.[4]
Yazılım Çaba Tahmini Önemi
[değiştir | kaynağı değiştir]Ç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.[5]
- 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
[değiştir | kaynağı değiştir]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:[1]
- 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
[değiştir | kaynağı değiştir]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 [6]. 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
[değiştir | kaynağı değiştir]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.[7] Tahminler yapılırken bazı teknikler kullanılır. Tahmin yaklaşımlarını kategorize etmenin birçok yolu vardır, örneklendirmeler için bkz.[8] Bu teknikleri aşağıdaki gibi sıralanabilir:[9]
- 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ı hikayelerine veya özelliklere göreceli büyüklükler atamak için kart oyunu oynadığı bir süreçtir.
- Çevik Hikaye Puanları(Agile Story Points): Bu teknikte, kullanıcı hikayelerine 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[10].
Uygun Tahmin Yöntemi Seçimi
[değiştir | kaynağı değiştir]Ç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.[11]
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ı
[değiştir | kaynağı değiştir]
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[12]. 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.
Tarihsel Gelişimi
[değiştir | kaynağı değiştir]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[13][14] 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.[15]
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[16]
Son yıllarda, yapay zeka ve 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.[17]
Tahmin İçin Kullanılan En Yaygın Modeller
[değiştir | kaynağı değiştir]Yazılım geliştirme çabasını ve maliyetlerini tahmin etmek için birçok model bulunmaktadır. COCOMO (Yapıcı Maliyet Modeli) [18] en yaygın kullanılan modeldir.
Yapıcı Maliyet Modeli ( COCOMO )
[değiştir | kaynağı değiştir]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[19].
- 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)[20].
Tahmin yaklaşımlarını kategorize etmenin birçok yolu vardır. En üst düzey kategoriler ve her kategorideki tahmin yaklaşımlarına dair örnekler verilmiştir:[19]
| Tahmin yaklaşımı | Kategori | Tahmin yaklaşımının uygulanmasına yönelik destek örnekleri |
|---|---|---|
| Analojiye dayalı tahmin | Resmi tahmin modeli | ANGEL, Ağırlıklı Mikro Fonksiyon Noktaları |
| WBS tabanlı (aşağıdan yukarıya) tahmin | Uzman tahmini | Proje yönetim yazılımı , şirkete özel aktivite şablonları |
| Parametrik modeller | Resmi tahmin modeli | COCOMO , SLIM , SEER-SEM , Yazılım için TruePlanning |
| Boyuta dayalı tahmin modelleri | Resmi tahmin modeli | İşlev Noktası Analizi, Kullanım Durumu Analizi, Kullanım Durumu Puanları, Yazılım Büyüklüğü Birimi (SSU), Çevik yazılım geliştirmede Hikaye Puanlarına dayalı tahmin, Nesne Puanları |
| Grup tahmini | Uzman tahmini | Planlama pokeri , Wideband delphi |
| Mekanik kombinasyon | Kombinasyona dayalı tahmin | Analojiye dayalı ve İş dökümü yapısına dayalı çaba tahmininin ortalaması |
| Yargısal kombinasyon | Kombinasyona dayalı tahmin | Parametreli model ve grup tahmininden elde edilen tahminlere dayalı uzman değerlendirmesi |
Uygulama Durumu
[değiştir | kaynağı değiştir]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.[21] 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.[22]
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.[23][24]
Gelişim Tahmin Yazılımlarının Karşılaştırılması
[değiştir | kaynağı değiştir]| Yazılım | Program tahmini | Maliyet tahmini | Maliyet Modelleri | Giriş | Rapor Çıktı Biçimi | Desteklenen Programlama Dilleri | Platformlar | Maliyet | Lisans |
|---|---|---|---|---|---|---|---|---|---|
| AFCAA REVIC | Evet | Evet | REVIC | KLOC , Ölçek Faktörleri, Maliyet Sürücüleri | Tescilli, Metin | Herhangi | DOS | Ücretsiz | Özel
/ Genel dağıtım için ücretsiz |
| Yazılım için Seer | Evet | Evet | SEER-SEM | SLOC , Fonksiyon noktaları , kullanım durumları, aşağıdan yukarıya, nesne, özellikler | Tescilli, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball | Herhangi | Windows, Web tabanlı | Reklam | Tescilli |
| SLIM[25] | Evet | Evet | SLIM | Boyut ( SLOC , Fonksiyon noktaları , Kullanım Örnekleri, vb.), kısıtlamalar (boyut, süre, çaba, personel), ölçek faktörleri, geçmiş projeler, geçmiş eğilimler | tescilli, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, metin, HTML | Herhangi | Windows, Web tabanlı | Reklam | Tescilli |
| TruePlanning | Evet | Evet | PRICE | Bileşenler, Yapılar, Aktiviteler, Maliyet Sürücüleri, İşlemler, Fonksiyonel Yazılım Boyutu (Kaynak Kod Satırları (SLOC), Fonksiyon Noktaları, Kullanım Durumu Dönüşüm Noktaları (UCCP), Tahmini Nesne Noktaları (POP'lar) vb.) | Excel, CAD | Herhangi | Windows | Reklam | Tescilli |
Mizahi Bakış Açısı ile Yazılım Çaba Tahmini
[değiştir | kaynağı değiştir]Geliştirme çabasının kronik olarak küçümsenmesi, bir görevden ironik bir şekilde " küçük bir programlama meselesi [26]" 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[27] :
- 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.[28] — Tom Cargill, Bell Laboratuvarları
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 Brooks
Kaynakça
[değiştir | kaynağı değiştir]- ^ a b "Software Effort Estimation: How to Get It Right the First Time". softwaredominos.com. Erişim tarihi: 26 Ekim 2024.
- ^ "What We Do and Don't Know about Software Development Effort Estimation". InfoQ (İngilizce). Erişim tarihi: 26 Ekim 2024.
- ^ [chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.gao.gov/assets/gao-09-3sp.pdf GAO COst EstimAtinG And AssEssmEnt GuidE]
|url=değerini kontrol edin (yardım) (PDF) (İngilizce). Erişim tarihi: 26 Ekim 2024. - ^ Jang, Kyoung-ae; Kim, Woo-Je (1 Ağustos 2021). "A method of activity-based software maintenance cost estimation for package software". The Journal of Supercomputing (İngilizce). 77 (8): 8151-8171. doi:10.1007/s11227-020-03610-6. ISSN 1573-0484.
- ^ Sami, Mohamed (15 Ocak 2018). "5 Steps to Software Development Effort Estimation". Mohamed Sami (İngilizce). Erişim tarihi: 26 Ekim 2024.
- ^ "Avoiding Irrelevant and Misleading Information When Estimating Development Effort". www.simula.no. Erişim tarihi: 27 Ekim 2024.
- ^ Jørgensen, M. (1 Şubat 2004). "A review of studies on expert estimation of software development effort". Journal of Systems and Software. 70 (1): 37-60. doi:10.1016/S0164-1212(02)00156-5. ISSN 0164-1212.
- ^ Grimstad, Stein; Jørgensen, Magne (21 Eylül 2006). "A framework for the analysis of software cost estimation accuracy". Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering. ISESE '06. New York, NY, USA: Association for Computing Machinery: 58-65. doi:10.1145/1159733.1159745. ISBN 978-1-59593-218-1.
- ^ "Software Effort Estimation: How to Get It Right the First Time". softwaredominos.com. Erişim tarihi: 26 Ekim 2024.
- ^ "Software Cost Estimation: A Comparative Analysis".
- ^ "What Is Effort Estimation in Project Management? | Wrike". www.wrike.com (İngilizce). Erişim tarihi: 26 Ekim 2024.
- ^ Sami, Mohamed (14 Mayıs 2017). "Software Scope vs. Requirement specifications". Mohamed Sami (İngilizce). Erişim tarihi: 27 Ekim 2024.
- ^ "Farr, L. Nanus, B. "Factors that affect the cost of computer programming, volume I" (PDF).
- ^ "Factors that affect the cost of computer programming, volume II" (PDF). 28 Temmuz 2018.
- ^ Anda, Bente; Angelvik, Endre; Ribu, Kirsten (2002). Oivo, Markku; Komi-Sirviö, Seija (Ed.). "Improving Estimation Practices by Applying Use Case Models". Product Focused Software Process Improvement (İngilizce). Berlin, Heidelberg: Springer: 383-397. doi:10.1007/3-540-36209-6_32. ISBN 978-3-540-36209-8.
- ^ Software development effort estimation (İngilizce), 31 Temmuz 2024, erişim tarihi: 26 Ekim 2024
- ^ "An Ensemble Model for Software Development Cost Estimation".
- ^ "Google Scholar". scholar.google.com. Erişim tarihi: 27 Ekim 2024.
- ^ a b "Software Cost Estimation: A Comparative Analysis".
- ^ Sami, Mohamed (15 Ocak 2018). "5 Steps to Software Development Effort Estimation". Mohamed Sami (İngilizce). Erişim tarihi: 26 Ekim 2024.
- ^ Molokken, K.; Jorgensen, M. (2003). "A review of software surveys on software effort estimation". 2003 International Symposium on Empirical Software Engineering, 2003. ISESE 2003. Proceedings.: 223-230. doi:10.1109/ISESE.2003.1237981.
- ^ Jørgensen, Magne; Teigen, Karl Halvor; Moløkken, Kjetil (1 Şubat 2004). "Better sure than safe? Over-confidence in judgement based software development effort prediction intervals". Journal of Systems and Software. 70 (1): 79-93. doi:10.1016/S0164-1212(02)00160-7. ISSN 0164-1212.
- ^ Software development effort estimation (İngilizce), 31 Temmuz 2024, erişim tarihi: 26 Ekim 2024
- ^ Edwards, J. S.; Moores, T. T. (Ocak 1994). "A conflict between the use of estimating and planning tools in the management of information systems". European Journal of Information Systems (İngilizce). 3 (2): 139-147. doi:10.1057/ejis.1994.14. ISSN 0960-085X.
- ^ "SLIM Suite - Estimate, Track & Benchmark Software Projects | QSM". www.qsm.com. Erişim tarihi: 27 Ekim 2024.
- ^ Small matter of programming (İngilizce), 12 Şubat 2023, erişim tarihi: 27 Ekim 2024
- ^ "Software Cost Estimation: A Comparative Analysis".
- ^ Bentley, Jon (Eylül 1985). "Programmimg pearls". Communications of the ACM (İngilizce). 28 (9): 896-901. doi:10.1145/4284.315122. ISSN 0001-0782.