You are on page 1of 11

T.

C
ATATÜRK ÜNİVERSİTESİ

YAZILIM GELİŞTİRME PROJELERİNDE BÜYÜKLÜK/EFOR


KESTİRİM YÖNTEMLERİ

HAZIRLAYAN:
Özmen AKBULUT

ERZURUM
İçindekiler
ÖZET ........................................................................................................................................................ 2
GİRİŞ ........................................................................................................................................................ 3
YAZILIM GELİŞTİRME PROJELERİNDE BÜYÜKLÜK/EFOR KESTİRİM YÖNTEMLERİ.................................... 5
1- Algoritmik Modeller.................................................................................................................... 5
1.1 İşlev Puan Analizi (Function Point Analysis) ..................................................................... 5
1.2 Kaynak Kod Satırı (SLOC-Source Line of Codes) ............................................................. 5
1.3 SEER-SEM (Software Evaluation and Estimation of Resources-Software Estimation
Model) 5
1.4 Putnam Modeli .................................................................................................................... 6
1.5 COCOMO Model (Constructive Costing Model) ............................................................... 6
2- Algoritmik Olmayan Modeller (Non-Algorithmic Model) ......................................................... 6
2.1 Anolji (Analogy) ......................................................................................................................... 7
2.2 Uzman Görüşü / Değerlendirmesi (Expert Judgement) ............................................................ 7
3- Makine Öğrenmesi Metotları (Machine Learning Methods)....................................................... 7
4- Kestirim Yöntemlerinin Karşılaştırılması ................................................................................... 7

1
YAZILIM GELİŞTİRME PROJELERİNDE BÜYÜKLÜK/EFOR KESTİRİM
YÖNTEMLERİ

Özmen AKBULUT

ÖZET

Bir yazılım geliştirme projesinin temel hedefi, kullanıcısının/müşterisinin ihtiyaçlarını


tam olarak ve planlanan bir performans ile karşılayabilen, hatasız bir yazılımın üretilmesidir.
Bu hedef Chatzoglou tarafından tüm proje yöneticilerinin amacı, bir projeyi zamanında,
bütçelenen maliyetler dahilinde bitirmek ve projeye atanan tüm kaynakları etkin ve verimli bir
şekilde düzenleyerek planlanan performansı veya son ürün hedeflerini karşılamak şeklinde
tanımlanmıştır (Chatzoglou & Macaulay, 1996:2). Yazılım mühendisliğinin yazılım projesi
açısından hedefi ise maliyet, süre, personel ve ürün kalitesi açısından olabilecek en iyi düzeyde
projeyi tamamlamaktır (Keskinkılıç, M, Kahveci, F. 2019).

Her ne kadar temel hedef yazılımın üretilmesi olsa da, yazılım projesinin öngörülebilir bir bütçe
ve kabul edilebilir bir süre içerisinde gerçekleşmesi gerekmektedir. Bu açıdan bakıldığı zaman
bir yazılım geliştirme projesi için bütçe ve süre kavramları en önemli iki kısıt ya da ulaşılması
gereken hedefler olarak ele alınabilir. Atanabilecek bütçe sınırlarını aşan ya da kabul edilebilir
bir süre içerisinde bitirilemeyen projeler, yazılım mühendisliği açısından gerçek başarıyı elde
etmiş sayılmamaktadır. Standish Grubunun 2014 yılında yayınladığı “Chaos Report” raporuna
göre Amerika’da yapılan yazılım geliştirme projelerinden sadece %16 ‘sı gerçekten başarılı
olmuştur. Yine aynı raporda yazılım projelerinin başarısında düzgün bir planlamanın önemli
olduğu vurgulanmıştır (Standish Report, 2014:4,8). Bu nedenle bir yazılım projesinde proje
planlama en önemli faaliyetlerden biridir. Zayıf planlama genellikle proje hatalarına ve proje
ekibi için dramatik sonuçlara yol açar. Yazılım projelerinde büyüklük, efor, süre ve dolayısıyla
maliyet tahminleri yazılım geliştirme projelerinin başarısı açısından önem arz etmektedir.

Literatür çalışmalarında genellikle yazılım geliştirme projelerinin büyüklük ve efor tahminleri


hakkında araştırmalar yapıldığı ve halen bu alanda araştırmaların yürütüldüğü görülmüştür. Biz
bu çalışmada yazılım projelerinde büyüklük/efor kestirim yöntemlerini ele alacağız.

2
GİRİŞ

Günümüzde, yazılım sistemleri, hayatımızın her aşamasında yer almaktadır.


Bankacılıktan otomotiv sanayisine, sağlık bilgi sistemlerinden şirket yönetimine,
telekomünikasyon sistemlerinden taşımacılığa kadar çok geniş alanlarda kullanılan bilgisayar
sistemlerinin çok önemli ve kritik bir parçasını oluşturmaktadır. Bu nedenle dünya her yıl
milyarlarca dolar kaynak aktarılarak yazılım geliştirme projeleri yapılmaktadır. Bununla
birlikte yakın zamanda Standish Grubunun yaptığı araştırmadan görüyoruz ki, genel olarak bu
projelerden %31’i iptal edilmekte, % 52 ‘si ise zaman ve bütçeyi aşarak tamamlanmaktadır.
Durumun anlaşılması ve konunun altının çizilmesi açısından Standish Grubu Chaos raporunda
verilen büyük, orta ve küçük ölçekli firmaların projelerdeki başarı durumunu gösterir tablo
aşağıda verilmiştir (Standish Report, 2014:4,8).

ÖLÇEK BAŞARILI SORUNLU BAŞARISIZ

BÜYÜK %9 % 61.5 % 29.5

ORTA % 16.2 % 46.7 % 37.1

KÜÇÜK % 28 % 50.4 % 21.6

Tablo 1: Firma ölçeklerine göre proje başarı yüzdeleri - Standish Report, 2014

Tabloda kullanılan sütun başlıkları ve tanımları aşağıdaki gibidir;

BAŞARILI (Successful): Proje, başlangıçta belirtilen tüm özellik ve işlevlerle


zamanında ve bütçe dahilinde tamamlanmıştır.

SORUNLU (Challenged): Proje tamamlanmış ve operasyoneldir, ancak tahmini süre


boyunca bütçeyi aşmıştır ve başlangıçta belirtilenden daha az özellik ve işlev sunar.

BAŞARISIZ (Impaired): Proje, geliştirme sırasında bir noktada iptal edilmiştir.

Son yıllarda yazılım geliştirme projelerinin başarısızlığının nedenini bulmak için birçok
çalışma yapılmıştır. Galorath ve Evans ‘ın yaptığı bir araştırmada 2100 internet sitesi
incelenmiş ve yazılım projesi başarısızlıklarıyla ilgili 5500 neden bulmuştur. Bulunan nedenler
arasında, yetersiz ihtiyaç analizi ve mühendisliği, projelerin kötü planlanması, projenin erken
aşamalarında aniden karar verilmesi ve yanlış tahminler en önemli nedenler arasında yer
almaktadır (Galorath and Evans: 2006).

Yazılım projelerindeki başarısızlığı inceleyen Devrim Rehber bu nedenleri sırasıyla, Teknik


Nedenler, Yönetimsel Nedenler, Sosyal Nedenler ve Diğer nedenler olarak dört kategori altında
incelemiştir. Yönetimsel Nedenler başlığı altında toplamda 5 adet planlama ve kestirime ilişkin
neden ortaya koymuştur. (Rehber, D. 2003);

Konuya tam ters açıdan bakacak olursak, Standish Grup raporunda yazılım projelerinde
yaşanan başarısızlıkların nedenini araştırılırken, yapılan önemli analizlerden birisi de bir

3
projeyi başarıya ulaştıran etkenlerin incelenmesi olmuştur. Bu etkenler ve başarıya etki oranları
aşağıda tablo halinde verilmiştir (Standish Report, 2014);

Proje Başarı Faktörleri % Oran


1 Kullanıcı Katılımı User Involvement 15.9%
2 Üst Yönetim Desteği Executive Management Support 13.9%
3 Net Gereksinim Beyanı Clear Statement of Requirements 13.0%
4 Doğru planlama Proper Planning 9.6%
5 Gerçekçi Beklentiler Realistic Expectations 8.2%
6 Daha küçük Proje Aşamaları Smaller Project Milestones 7.7%
7 Yetkili Kadro Competent Staff 7.2%
8 Sahiplik Ownership 5.3%
9 Net Vizyon ve Hedefler Clear Vision & Objectives 2.9%
10 Çalışkan,Odaklanmış Personel Hard-Working, Focused Staff 2.4%
11 Diğer Other 13.9%
Tablo 2: Proje başarı faktörleri - Standish Report, 2014

Yukarıda verilen tabloya göre doğru planlama yazılım geliştirme projelerinde 4.sırada etki
düzeyine sahip bir süreçtir. Bu sürecin sağlıklı ve doğru bir şekilde yapılabilmesi aynı zamanda
büyüklük kestiriminde sağlanan başarıya da bağlıdır.

Yazılım büyüklük ve efor tahmini, yazılım geliştirme süreçlerinde kritik ve karmaşık


faaliyetlerden biridir. Genellikle yazılım projelerinde efor ve maliyet tahmini zordur. Bunun
nedeni, yazılım projelerinin genellikle benzersiz olması ve buna bağlı olarak onlar hakkında
edinilmiş herhangi bir deneyimin bulunmayışıdır. Ayrıca yazılım geliştirme süreci dinamik ve
yinelenen bir süreç olduğu için gereksinimler değişebilmektedir, bu değişkenlik ise yapılan
tahminin güncellenmesini gerektirmektedir. Bu sebeplerden dolayı proje yöneticileri de maliyet
ve iş gücü tahminlerini sınırlı bir kapsamda yapmaya çalışır ve proje planlarını bu tahminler
çerçevesinde oluştururlar.

Bazı proje yöneticileri ise; a) ortaya çıkan ürün ve kalitesinin önemli olan tek şey olduğu, b)
var olan proje planlama modellerinin çoğunlukla proje başında net olmayan bilgilere dayalı ve
net sonuç vermediğini, c) planlamaya harcanan zamanın boşa harcandığını düşünerek proje
planlama adımlarını atlamaktadırlar (Chatzoglou & Macaulay, 1996:4).

Araştırmaların sunduğu bazı verilerinde gösterdiği üzere yazılım üretimi konusunda kestirim
ve tahmin yöntemlerinin önemi büyüktür. Yazılım geliştirme sürecinin başında, büyüklük,
emek, süre ve maliyet kestirimleri geliştiricilerin ve yöneticilerin daha başarılı sonuçlar elde
etmesine katkı sağlayacaktır. Yazılım proje yönetiminde çok önemli olan kestirim yöntemleri
aracılığı ile zaman ve işgücü gibi planlamaların daha iyi yapılabilmesi sağlanır.

4
YAZILIM GELİŞTİRME PROJELERİNDE BÜYÜKLÜK/EFOR KESTİRİM
YÖNTEMLERİ

Yazılım projeleri genellikle belirlenen zaman ve bütçe planlarına uymamaktadır. Bunun


sebebi ise harcanan efor tahminin proje başlangıcında yanlış hesaplanmasıdır. Gereksinim
analizleri ve diğer tüm planlar da belirlenen bu hesaplara göre düzenlediğinden proje yanlışlar
zinciri ile devam etmektedir. Bu yüzden proje belirlenen maliyetten çok daha yüksek
maliyetlere çıkmaktadır. Bu problemleri en düşük seviyeye indirmek için ise projede gerekli
olan iş gücü ve maliyeti tahmin etmek yönünde daha fazla çalışmalar yapılmalıdır.

Yazılım projeleri genel olarak geliştirme sürecinde değişkenlik gösteren bir yapıdadır, bu
yüzden farklı yazılım projelerinde farklı yöntemler kullanımı söz konusu olmuştur. Daha iyi bir
proje planlaması yapabilmek, kestirim hatalarını en aza indirmek ve başarılı sonuçlar elde
edebilmek birçok kestirim yöntemi geliştirilmiştir. Bu yöntemler genel dört ana kategori altında
incelenmiştir (Tailor, O., Saini, J., & Rijwani, M. P. 2014).

1. Algoritmik modeller (Algorithmic),


2. Algoritmik olmayan (Non-Algorithmic),
3. Parametrik (Parametric),
4. Makine Öğrenmesine Dayalı Modelleri (Machine Learning Models).

1- Algoritmik Modeller
Algoritmik yöntemlerde, geçmiş veriler ve deneyimlerle oluşturulan matematik denklemleri
kullanılır. Yani algoritmik yöntemler için bir kestirim fonksiyonu oluşturulur ve bu fonksiyon
ile kullanılan modele göre değişen zorluk/maliyet faktörleri kullanılarak yazılım projesi
büyüklüğü toplam efor değeri üzerinden bulunmaya çalışılır (Tailor, O., Saini, J., & Rijwani,
M. P. 2014). Aşağıda günümüzde genel olarak kullanılan algoritmik modellerin kısaca
tanımları yapılmıştır.

1.1 İşlev Puan Analizi (Function Point Analysis)


İşlev Puan Analizi (İPA) A.J. Albrecht tarafından, kod satır sayısı (Lines of Code-LOC)
yaklaşımına alternatif olarak önerilen, akademik yazında üzerinde çok çalışılan bir maliyet
yaklaşımıdır. İşlev Puan Analizi, yazılımdaki fonksiyonları karmaşıklıkları ve yaptıkları
işlere göre sınıflandırıp saymaktadır (Keskin, M., & Alptekin, G. I. 2016).

1.2 Kaynak Kod Satırı (SLOC-Source Line of Codes)


Büyüklük ve efor kestirim yöntemlerinden en çok bilinen yöntemlerden birisi Kaynak Kod
Satır Sayısı (Source Lines of Code - SLOC) yöntemidir. Minimum düzeyde programlama
bilgisi ile yazılım büyüklüğü tahmini için modellenmiştir. Kabaca bu yöntemde
uygulamanın büyüklüğünü anlamak için bilgisayar programlarındaki kodların satırları
sayılır ve sayı üzerinden bir büyüklük hesaplaması yapılır.

1.3 SEER-SEM (Software Evaluation and Estimation of Resources-Software Estimation Model)


SEER (SEER-SEM) , yazılım geliştirme projeleri, yazılım bakım projeleri için gereken
çaba ve kaynakları tahmin etmek, planlamak ve izlemek için özel olarak tasarlanmış

5
algoritmik bir proje yönetimi yazılımı uygulamasıdır. İsimden gelen SEER, geleceği
öngörebilme yeteneğine sahip olana atıfta bulunarak, proje yöneticilerinin, mühendislerin
ve maliyet analistlerinin bir proje için gerekli efor, maliyet takvimi ve risk faktörlerini
doğru tahmin etmesini sağlamak için parametrik algoritmalara, bilgi bankalarına,
simülasyon tabanlı olasılığa ve daha önce yapılan emsal projelere dayanır (Pauline, M.,
Aruna, D. P., & Shadaksharappa, D. B. (2013).

1.4 Putnam Modeli


Putnam tahmin yöntemi, Kantitatif Yazılım Yönetiminden Larry Putnam tarafından
1970'lerin sonunda geliştirilmiştir. Bu model deneysel bir yazılım çaba tahmin modelidir
ve aynı zamanda ilk algoritmik maliyet modellerinden biridir. Yazılım projesini belirli bir
boyutta bitirmek için gereken zamanı ve çabayı açıklar. Norden / Rayleigh işlevine dayalı
olarak, genellikle makro tahmin modeli olarak bilinir (Tripathi, R., & Rai, D. P. (2016).

1.5 COCOMO Model (Constructive Costing Model)


COCOMO modeli değişkenler arası ilişkiyi inceleyen yani regresyon tabanlı bir yazılım
maliyet tahmin yöntemidir. Bary Boehm tarafından 1981 yılında geliştirilmiş ve dünyada
şu an en çok kullanılan ve en çok atıf yapılan yöntemlerden birisidir. Tek değişkenli ve
büyük ölçekli projeler için lineer olmayan bir yöntemdir. COCOMO modelinde proje
büyüklüğü belirlendikten sonra proje boyutuna göre belirli parametreler kullanılarak
hesaplamalar yapılır. Model proje boyutlarına göre belirli tiplere ayrılır. Ayrıca modelin
doğru sonuç vermesi de garanti edilemez. Projeniz için yapacağınız hesabın doğruya yakın
sonuç vermesi Boehm’in yaptığı çalışmalara ne kadar yakın olduğu ile alakalıdır (Tripathi,
R., & Rai, D. P. (2016).

Toplamda üç tip COCOMO modeli vardır;

COCOMO (Basic): COCOMO, proje için harcanan eforu ve geliştirme için gerekli olan
süreyi proje büyüklüğünün bir fonksiyonu olarak kod satır sayısı cinsinden hesaplar.

COCOMO II (Intermediate): COCOMO II’de aynı denklem kullanılır ancak bu tipte


kullanılan hesaplamalarda proje karakteristiklerini belirleyen ve 20’ye kadar çıkabilen yeni
çarpanlar eklenir. Daha detaylı ve güvenilir bir hesaplama yapılır. COCOMO Intermediate
olarak da bilinir (Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby,
R. 1995).

Detaylı COCOMO (Detailed): COCOMO II’nin üzerine projenin test, geliştirme ve tasarım
gibi fazlarının ve ürünün sistem, alt-sistem ve modül gibi farklı seviyelerine göre maliyet
hesaplamalarının yapıldığı COCOMO modelidir.

2- Algoritmik Olmayan Modeller (Non-Algorithmic Model)


Algoritmik olmayan kestirim yöntemleri istatistiki bilgilere, analitik karşılaştırmalara ve
çıkarımlara dayanmaktadır. Algoritmik Olmayan yöntemleri kullanmak için, tahmin edilmeye
çalışılan projeye benzer önceki projeler hakkında bilgiler gereklidir ve genellikle bu
yöntemlerde tahmin işlemi önceki veri setlerinin analizine göre yapılır. Son yıllarda en çok

6
kullanılan ve üzerine araştırmalar yapılan Algoritmik Olmayan Modeller, Analoji, Uzman
Görüşü/Değerlendirmesi ve Makine Öğrenmesi Modelleridir.

2.1 Analoji (Analogy)


Analojiye dayalı tahmin, yazılım çabası veya maliyet tahmini alanlarında değerlendirilen
ve onaylanan, yaygın olarak benimsenen bir problem çözme yöntemidir. Analoji temelli
tahmin, son zamanlarda bazı çalışmalarda algoritmik yöntemlerle karşılaştırılabilir
doğrulukta umut verici bir yaklaşım ve aynı zamanda anlaşılması ve uygulanması
potansiyel olarak daha kolay olan bir modeldir. Analoji temelli kestirim modelinde işlem
adımlarını kısaca belirtecek olursak; Öncelikle Analoji seçimi yapılır, sonra seçilen
analojide benzerlikler ve farklılıklar araştırılır, sonraki adımda elde edilen bilgilere dayalı
olarak analoji başarısı/kalitesi incelenir son adımda ise oluşturulan bu modele göre bir
kestirim yapılır( Chiu, Nan-Hsing, and Sun-Jen Huang.2007).

2.2 Uzman Görüşü / Değerlendirmesi (Expert Judgement)


Uzman Değerlendirmesi, maliyet ve süre tahminlerinin oluşturulmasında yaygın olarak
kullanılan metotlardan birisidir. Algoritmik yada bilgisayarlar üzerinden yapılan maliyet
modelleri, birçok yönden Uzman Görüşü modeli ihtiyacını azaltsa da zaman içerisinde
onun yerini tam olarak alamamışlardır (Rush, C., & Roy, R. 2001). Uzman Görüşüne dayalı
tahmin, benzer projelerde geniş deneyime sahip uzmanlardan tavsiyeler alınarak yapılır.
Bu yöntem genellikle veri bulma ve toplama gereksinimlerinde sınırlama olduğunda
kullanılır.

3- Makine Öğrenmesi Metotları (Machine Learning Methods)


Günümüzün popüler çalışma alanlarından biriside Veri Madenciliği alanıdır. Veri
madenciliği eldeki verilerden üstü kapalı, çok net olmayan, önceden bilinmeyen ancak
potansiyel olarak kullanışlı bilginin çeşitli içinde makine öğrenmesinin de bulunduğu
algoritmalar ve bilgisayar kullanılarak çıkarılmasıdır. Günümüzde çok yüksek bütçelerde
çok büyük yazılım projeleri yapılmaktadır. Bu nedenle yazılım geliştirme sürecinde efor
ve süre tahmini açısından daha kesin/ daha yaklaşık tahminlerin yapılmasına duyulan
ihtiyaç artmıştır (BaniMustafa, A. 2018).

Geleneksel ve parametrik tahmin tekniklerinin eksikliklerini gidermeyi, proje başarı


oranlarını artırmayı amaçlayan makine öğrenimi algoritmalarını kullanarak yazılım
tahmini alanında önemli araştırmalar yapılmıştır. Bu alanda yapılan çalışmalar genel olarak
Yapay Sinir Ağları (Artificial Neural Networks) ve Bulanık Metot (Fuzzy Method) olmak
üzere iki kategori altında toplanmıştır.

4- Kestirim Yöntemlerinin Karşılaştırılması


Yazılım projelerinde proje başarısızlık nedenleri popüler araştırma konusu olmaya devam
etmektedir. Yapılan literatür tarama çalışmalarında, yazılım projelerinin başarısında en önemli
etkenlerden birisinin doğru tahmine/kestirime dayalı doğru bir planlama yapmak olduğu ortaya
konulmuştur. Tailor ve Saini yaptıkları bir çalışmada yazılım büyüklük ve maliyet tahmin
yöntemlerini incelemiş ve elde ettikleri sonuçlara göre karşılaştırma yapmışlardır. Bu çalışmada
elde edilen sonuçlara dayalı özet karşılaştırma tablosu Tablo-3 de verilmiştir.

7
Metod Kategori Avantajları Dezavantajları

Kaynak Kod Algoritmik Uygulaması çok kolay Proje erken safhalarında satır
Sayısı (LOC-SLOC) sayısı tahmini zor, çok büyük
projelerde iyi değil, dile
bağımlı
İşlev Puan Analizi Algoritmik LOC-SLOC dan daha iyi, dil’e Çok fazla yargı var, tasarım
(Functional bağımlı değil, grafik arayüz şartnamesinden sonra başlar,
point) tabanlı işlevde araştırma verisi az

SEER-SEM Algoritmik Çok büyük projelerde kullanılır Karmaşıklığı ve belirsizliği


artıran 50 girdi/giriş
parametresi gereklidir

COCOMO Algoritmik Temel COCOMO, yazılım Büyüklüğün 10000'den büyük


maliyetlerinin hızlı, erken ve olduğu büyük projelerde
kaba büyüklük tahminleri için kullanılmaz. Doğruluk sınırlıdır,
iyidir, genelde küçük tahmin oldukça zayıf
projelerde kullanılır, makine
dili programlamaları için
uygundur
COCOMO II Algoritmik Modern yazılım geliştirme SDLC'nin tüm farklı
süreçleri ve güncellenmiş bir aşamalarında gerekli eforu
proje veritabanı için daha fazla tahmin edemez. Tahmin
destek sağlar. başarısı oldukça iyi.
Mainframe’i, kodun yeniden
kullanılabilirliğini ve betik
işlemeyi destekler.
Detaylı COCOMO Algoritmik Faza duyarlı çaba çarpanlarının Tahmin süresi karmaşıklığıile
her biri, her fazı tamamlamak ilgili birçok parametre
için gereken çaba miktarını yüksektir. Tahmin başarısı iyi
belirlemek için kullanılır seviyede.

PUTNAM Algoritmik Olasılıksal model, çok büyük Sadece çok büyük projeler için
projelerde kullanılır

Uzman Algoritmik Hızlı tahmin, özel projelere Başarısı uzmana bağlıdır,


Değerlendirmesi Olmayan uyum sağlama genellikle eksik yapılır
(Expert
judgement)

Analogy Algoritmik Gerçek deneyime dayalı olarak Geçmiş projeler hakkında çok
Olmayan çalışır, özel uzmana sahip fazla bilgi gereklidir, bazı
olmak önemli değildir durumlarda benzer bir proje
yoktur

8
Sinir Ağları Makine Veritabanlarından farklı olarak Tasarım için bir kılavuz yoktur,
(Neural Öğrenmesi tutarlı olması, muhakeme gücü performans büyük eğitim
networks) verilerine bağlıdır

Bulanık Mantık Makine Eğitim gerektirmez, esneklik Kullanımı zor, anlamlılık


(Fuzzy ) Öğrenmesi sağlar derecesini korumak zordur

Tablo-3: Yazılım geliştirmede Büyüklük/Efor kestirim yöntemlerinin


karşılaştırması (Tailor, O., Saini, J., & Rijwani, M. P. 2014)

9
Kaynakça;

1- Chatzoglou, P. D., & Macaulay, L. A. (1996). A review of existing models for project
planning and estimation and the need for a new approach. International Journal of
Project Management, 14(3), 173-183.
2- The Standish Group Report- CHAOS, 2014
3- Galorath, D. D., & Evans, M. W. (2006). Software sizing, estimation, and risk
management: when performance is measured performance improves. CRC Press.
4- Tailor, O., Saini, J., & Rijwani, M. P. (2014). Comparative analysis of software cost
and effort estimation methods: a review. Interfaces, 5(7), 10.
5- Keskinkılıç, M, Kahveci, F. (2019). Yazılım Mühendisliğinde Çevik Yöntemler
Üzerine Kavramsal Bir İnceleme ve Sınıflandırma. Atatürk Üniversitesi Sosyal
Bilimler Enstitüsü Dergisi, 23 (3) , 1067-1091.
6- Rehber, D. (2003). Yazılım Projelerinde Başarısızlık.
7- Keskin, M., & Alptekin, G. I. (2016).Yazılım Maliyet Tahmininde İşlev Puanı Analizi
ve Yapay Sinir Ağları Kullanımı.
8- Borandağ, E., Yücalar, F., & Şahinaslan, Ö. (2013) Yazılım Projelerinde Büyüklük
Tahmini.
9- Eveleens, J. L., & Verhoef, C. (2010). The rise and fall of the chaos report figures.
IEEE software, 27(1), 30.
10- Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995).
Cost models for future software life cycle processes: COCOMO 2.0. Annals of
software engineering, 1(1), 57-94.
11- Pauline, M., Aruna, D. P., & Shadaksharappa, D. B. (2013). Comparison of available
Methods to Estimate Effort, Performance and Cost with the Proposed Method‖.
International Journal of Engineering Inventions, 2(9), 55-68.
12- Sharma, T. N., Bhardwaj, A., & Sharma, A. (2011). A Comparative study of
COCOMO II and Putnam models of Software Cost Estimation. vol, 2, 1-3.
13- Tripathi, R., & Rai, D. P. (2016). Comparative Study of Software Cost Estimation
Technique. International Journal of Advanced Research in Computer Science and
Software Engineering, 6(1).
14- Chiu, Nan-Hsing, and Sun-Jen Huang. "The adjusted analogy-based software effort
estimation based on similarity distances." Journal of Systems and Software 80, no. 4
(2007): 628-640.
15- Chemuturi, M. (2011). Analogy based software estimation. Chemuturi Consultants.
16- Rush, C., & Roy, R. (2001). Expert judgement in cost estimating: Modelling the
reasoning process. Concurrent Engineering, 9(4), 271-284.
17- Pospieszny, P., Czarnacka-Chrobot, B., & Kobylinski, A. (2018). An effective
approach for software project effort and duration estimation with machine learning
algorithms. Journal of Systems and Software, 137, 184-196.
18- BaniMustafa, A. (2018, July). Predicting software effort estimation using machine
learning techniques. In 2018 8th International Conference on Computer Science and
Information Technology (CSIT) (pp. 249-256). IEEE.
19- Ian Sommerwille “Software Engineering Tenth Edition”

10

You might also like