Yazılım Gelitirme Projelerinde Maliyet Tahminleme Çalımasında Kullanılabilinecek Bir Ölçev Kümesi Ve Bir Yapay Sinir Aı Topolojisi Önerisi

Transkript

1 Yazılım Gelitirme Projelerinde Maliyet Tahminleme Çalımasında Kullanılabilinecek Bir Ölçev Kümesi Ve Bir Yapay Sinir Aı Topolojisi Önerisi Oya KALIPSIZ 1, Murat AYYILDIZ 1 1 Yıldız Teknik Üniversitesi, Bilgisayar Mühendislii Bölümü, Barbaros Bulvarı Yıldız, stanbul 1 e-posta : {kalipsiz, f }@yildiz.edu.tr Özet Yazılım projeleri çaba maliyeti genellikle karmaık ve pahallı olarak görünmektedir. Yazılım üretimi bir kriz içindedir.aırı maliyetlerden müstariptir. Yazılım üretimi çou kez kontrol dıındadır çünkü ölçmüyoruz. Eer ölçemezsen kontrol edemezsin. Bu makale yazılım gelitirme maliyet kestirim çalımaları için bir ölçev kümesi önermektedir. Bu ölçev kümesi yazılım gelitirme projelerinden, çalımalardan ve tecrübelerden türetilmitir. Ölçev kümesi seçiminin aslında yazılım maliyet kestirim çalımalarında hayati bir rolü vardır. Birçok model COCOMO ölçev kümesi tabanlıdır.maalesef ölçev kümesinin önemi bir çok çalımada göz ardı edilmitir. Ölçev kümesi üzerine çok az çalıma vardır. Aynı zamanda, bu makale önerilen ölçev kümesini girdi parametresi olarak alan çok katmanlı perceptron a topolojisi önermektedir. Abstract Software project effort estimation is frequently seen as complex and expensive for individual software engineers. Software production is in a crisis. It suffers from excessive costs. Software production is often out of control. It has been suggested that software production is out control because we do not measure. You cannot control what you cannot measure. This paper suggests a metric-set for software development cost estimation studies. This metric-set has been derived from software development projects, studies and experience The metric-set selection is actually have a vital role in software cost estimation studies. Most of the model based on cocomo metric-set. Unfortunately importance of the metric set has been ignored in most of the studies. There is few studies on metric set. Also, this paper suggests a multi-layer perceptron network topology which takes the sugested metric-set as input parameter. 1. Giri Mühendisliin temel yapı talarından biri ölçmedir. Yazılım mühendisliinin bir disiplinden çok bir ideoloji gibi kalmasının temel nedeni yazılım mühendisliine yön veren kiilerce ölçümün neredeyse tamamen göz ardı edilmesidir. Yazılım mühendisliini gerçek bir mühendislie çevirme anahtarı ölçmedir. Ölçme gerçek dünyadaki varlıkların özelliklerine onları tanımlayabilmek için açıkça tanımlanmı kurallara göre sayı veya sembol atanması iidir. Bir varlıı ölçmek diye bir süreçten bahsedemeyiz. Bir varlıın bir özelliini tanımlanmı bir kurala göre ölçme iinden bahsedebiliriz.

2 Yazılım mühendislii bir yazılım ürünü inaa etmek için kullanılan teknikler topluluunu tanımlamak için kullanılan bir terimdir. Burada mühendislik yaklaımıyla yönetim, bütçeleme, planlama, modelleme, tasarlama, uygulama, test etme ve bakım konularını içine almaktadır. Günümüzde yazılım projeleri gelitirirken ölçülebilir hedefler koymakta baarılı olunamamaktadır. Örnein bir yazılıma balarken onun güvenilir, bakım yapılabilir, kullanıcı dostu gibi olacaı söylenmekte, net tanımlar verilmemektedir. Ölçme iinin açık ve net hedefleri olmalıdır. Yazılım mühendisliinde ölçevlerin kullanımı teorik ve pratik çalımalar arasındaki aralıı küçültecek bir anahtardır. Ölçme ve deerlendirme yapabilmek için sistematik ölçüm yapmak gerekmektedir. Bir i için gereken çabayı batan bilmek çok önemlidir. Bunu bilmeden ileri yönetmek mümkün deildir. Yönetmek için bu tahminleri kullanıp projeleri batan kabul etme veya reddetmek çok daha faydalıdır. Çok uzun sürebilecek ve çok kaynak gerektirebilecek bir yazılım gelitirme iine girmemek veya girilme kararı verilse bile batan gerekli i gücünü organize etmek verimi her aamada artıracaktır. Bügünün dünyasında yazılım maliyet kestiriminin önemi sürekli artmakta ve yayılmaktadır. Bu konuda yapılmı çalımalar olmasına ramen hala bu konu tam olarak aydınlatılabilinmi deildir ve üzerinde bir çok çalıma yapılması gerekmektedir. Bu konu u an ihtiyaç duyulandan çok daha yava olarak ilerlemektedir. Ölçüm yapabilmeyi baarabildikten sonra aslında temel problem ölçülmesi gerekenleri ortaya çıkarmaktır. Yazılım projeleri zaman planına ve bütçe planına uymama yönünde kötü ün salmı projelerdir. Bunun temel nedeni gereken i gücünü batan yanlı tahmin etmektir. Bütün planları bu yanlı tahminler üzerine kurmakla devam eden bu yanlılık zinciri yüksek maliyetlere neden olmaktadır. Yazılım mühendisliinde yazılım projelerinin gereken i gücünü, zamanı ve bütçeyi tahmin etme yönünde yapılacak çalımalar bu problemleri azaltacaktır. Yazılım maliyet tahminlemesi bir yazılım sisteminin inaası için gereken çaba miktarının tahminleme sürecidir. Yazılım mühendislii henüz olgunlamamı bir disiplindir. Dier disiplinler gibi ispatı henüz mümkün olmayan tahminleme, plan ve kontrolleri içerir larda Standish Group 8000 yazılım projesini incelemitir. Bu projeler hem kamu hemde özel projelerden olumakta idi. Bu projelerin %90 ının bütçe ve zaman aımı nedeniyle baarısız oldukları görülmütür. Bunların %33 ü daha tamamlanmadan iptal edilmitir. Yaklaık üçte biri ilk tahmin edilen ve bütçelenen maliyeti %150 ile %200 arasında ve ortalama olarak %189 atıı görülmütür. Yaklaık üçte biri ise %200 ile %300 arasında ve ortalamada %222 atıı görülmütür. [1] Bu makalede amaç yazılım gelitirme maliyet tahminleme çalımalarında kullanılabilinecek bir ölçev seti ve bir yapar sinir aı topolojisi önermektir. Bu ölçev seti gerçek proje çalımalarından, proje yöneticileri ile görümelerden ve tecrübelerinden alınan veriler üzerinde çalıma yapılarak çıkarılmıtır. 2. Ölçev Kümesi Önerisi Ölçev (Metric) bir sistemin veya bir parçanın verilen bir özelliinin nicel ölçüm derecesidir. Ölçev hesaplanabilir veya birleik bir gösterge olabilir. Bir yazılım ihtiyacının büyüklüünün ölçülebilecei fikrini ilk ortaya çıkaran ve bir sistem kuran Allan Albrecht tir da IBM de çalıan Albrecht ilev puan analizi (Function Point Analysis) adıyla bir method ortaya koymutur. California da bir danımanlık firması olan TRW de bulunan bir çok proje üzerinde çalıarak, Boehm COCOMO yu ortaya koymutur. COCOMO göreceli olarak dosdoru bir modeldir. Orjinal COCOMO modeli 1981 de yayınlanmıtır.[1] Daha sonra bu gelitirilmi ve COCOMO II adını almıtır. Bu makale yazılım maliyet tahminlemesinde kullanılabilinecek bir ölçev kümesi önermektedir. Bu konuda yapılmı olan birçok çalımada COCOMI 81 ölçev kümesini kullanmıtır. Dolayısıyla

3 önereceimiz ölçev kümesinde COCOMO 81 i içermek bize çalıma sonuçlarını bir nebze karılatırabilme ansı tanıyacaktır. Bu önerilen ölçev kümesi temel olarak COCOMO 81, COCOMO II, 21 adet gerçek yazılım projesini, toplam 90 yıllık yazılım gelitirme tecrübesi olan 28 yazılım gelitirme proje yöneticisi öneri ve fikirleri üzerinde çalıılarak hazırlanmıtır. Ölçev belirleme çalımamızda dikkat ettiimiz temel noktalar unlardır: a. Bir yazılım mühendislii ölçevi ayrık, yalıtılmı olması avantajlıdır. b. Süreç, kii, ürün bazında mümkün olduunca çok ölçev bulup daha sonra yapılacak bir analiz ile en yararlıların bulunmasının salanması faydalıdır. c. Ölçevlerin birbirleriyle ilikili olmamaması gerekmektedir. Birbirleri üzerinde etkisi olmamalıdır veya çok az olmalıdır. Bu sürekli izlenmelidir. d. Ölçev bulma, çıkarma süreci sistematik ve düzenli olmalıdır. Sürekli iyiletirme yapmak gerekir. e. Ölçevlerin doruluu gerçek hayat ile kontrol edilebilmelidir. f. statistiksel ve baka yöntemlele ölçevlerin hata analizleri yapılmalıdır. Böylece gereksiz hatta zararlı ölçevler temizlenmelidir. g. Ölçev bazında mantıklı ve doru karılatırmalar yapabilmek için kii, süreç ve ürün benzerlikleri ve farklılıkları karılatırmaları iyi bilinmelidir. h. Ölçevleri toplarken ölçevlere bulaanların farkında olmalıdırlar. Burada çok ünlü iki "H" vardır (Heisenberg etkisi ve Hawthorne etkisi.) i. Ölçevler zararlı olabilir. Daha dorusu ölçevler yanlı kullanılıyor olabilirler. Buna sürekli dikkat edilmelidir. Yazılım maliyet tahminleme çalımalarında çounlukla COCOMO 81 ölçev seti kullanılmıtır. Bu yüzden önerilen ölçev seti aslında COCOMO bazlı bir ölçev kümesidir. Ölçev belirleme çalıması yaparken 21 adet gerçek proje, COCOMO 81, yapılmı çalımalar ve 28 tane 3 yıldan fazla proje yönetim tecrübesi olmu proje yöneticisiyle birebir görüüldü. Proje yöneticisinin önerileri bu balangıç matrise eklenmitir. Elde edilen verilen üzerinde dönüüm matrisi oluturuldu. Korelasyonlar belirlenip elenmitir. Matematiksel, istatistiksel ve gözlemsel bir optimizasyon çalımasından sonra 6 temel grupta toplanmıtır. Bunlar iin büyüklüü (ürün), kaynak, risk, teknoloji, ortam ile planlar ve tahminler gruplarıdır. COCOMO da belirtilen tüm ölçevler bu önerilen ölçev setinde kullanılmıtır. Bununla beraber bir hiyerarik yapı getirilmitir. Bu makalenin temel amacı yazılım gelitirme projelerinin maliyet tahminlemesi çalımalarında kullanılabilinecek ve daha iyi sonuç alınmasını salayacak ölçev seti önermektir. Bu makale aynı zamanda daha iyi sonuç alabilmek için bir melez model önermektedir. Birçok ölçevin yanı sıra ilev puanı kullanımı ve batan yapılan tahminlerinde girdi olarak kullanımı melez bir durum yaratmaktadır ve baarı ihtimalini artırmaktadır. COCOMO da kullanılmayan bazı ölçevlerde eklenmitir. Elde ettiimiz ölçev kümesi Tablo 1 de gösterilmitir. 6 Ana ölçev grubu ve bunlara balı 24 ölçevi bu tablodan görebilirsiniz. Bu 24 tane ölçevin bazılarınında alt ölçevleri vardır. Bunlarla beraber aslında toplam 56 tane girdi ölçevi vardır. Bu alt ölçevleri bu tabloda gösterip tabloyu karmaık hale getirmemek için tablodan sonra açıklamaya çalıtık. Bu ölçevler ve alt ölçevler için çou kez direk bir sayı elde etmek mümkün olmayabilir. Bu durumda bulanık mantık kümeleri kullanmak mümkün olabilir.

4 Tablo 1. Önerilen Ölçev Seti Ana Ölçev A. in Büyüklüü (Ürün) B. Kaynak C. Risk D. Teknoloji F.Ortam F.Planlar ve Tahminler Ölçev (Metric) 1. Karmaıklık 2.lev Puan (Function Point) 3.Önem 4. Ayrılan Bütçe 5. Ürünün beklenen özellikleri 6. Çalıanın yeterlilikleri 7 Çalıanların Projeye katılım oranları 8. Çalıan Kii Sayıları 9. Donanım Durumu 10.Bütçe Deime Riski 11. Çalıan Riski 12.Donanım Riski 13.Ürünün tanımının ve kapsamının deime riski 14.Yazılım Gelitirme araçlarının kullanım kolaylıı 15.Yazılım Gelitirme araçlarının kullanım tecrübesi 16. Yazılım Gelitirme Araçlarının Kullanımı 17. Modern Programlama Teknikleri 18.Ortamın genel özellikleri 19.Sahiplenilme (Her bir payda türünün projeyi sahiplenmesi) 20.Baskı 21.Zaman kullanım durumu 22.Verimlilik durumu 23. Tahmin 24. Planlar A. in Büyüklüü 6 temel gruptan biri olan iin büyüklüünü bulabilmek için ilev puanı kullanmanın yanısıra ürünün karmaıklıı, önemi, beklenen özellikleri almak büyüklük temel ölçevini daha doru olmasını salayacaktır. Karmaıklıın 3 alt ölçevi olarak Veritabanı büyüklüü, Ürün karmaıklıı ve yeniden kullanılabilinirlik olarak belirledik. Bunların üçüde COCOMO da DATA, CPLX ve RUSE olarak geçmektedir. lev puanı bir yazılım uygulamasının büyüklüünün ölçevidir. Bu büyüklük ilevsellik ölçümüdür. Yazılım dilinden, methodolojiden, proje takımının yeterliliinden baımsızdır. lev puanın nerede zorlandıını bilmek önemlidir. lev puan bir uygulama için gereken çabayı ölçmek için mükemmel deildir. Ancak iin büyüklüünü belirleme anlamında önemlidir. Çounlukla gerçek hayatta iin büyüklüünü anlamak için benzetim kullanılır. Örnein 1000 m 2 bir ev yapmak genellikle 2000 m 2 bir ev yapmaktan daha ucuza mal olmaktadır. Ancak mermer banyo, karo fayans gibi birçok parametrenin aslında durumu tamamen deimesi mümkündür. Dolayısıyla 1000 m 2 bir evin yapımının 2000 m 2 bir ev yapmaktan daha ucuza mal olabilir veya daha pahallıya mal olabilir. Dolayısıyla sadece evin büyük olması bize çaba ile ilgili bir fikir verse bile bunun üzerine maliyeti

5 hesaplamamız pek mümkün gözükmemektedir. lev puan da bunun gibi bize ürünün büyüklüünü vermesine karın tek baına maliyeti bulmamız mümkün deildir. lev puanı kullanmanın iki avantajı vardır. Bize ürünün büyüklüünü ve ürünün görünen büyüklüünü verir. Bunu girdi olarak kulanmak faydalı olacaktır. Dolayısıyla önereceimiz ölçev setine ilev puanıda bir ölçev olarak ekledik. Bir projeye ayrılan bütçe o projenin temel parçalarından biridir. Dolayısıyla projenin büyüklüü ve önemi ile iligli genel bir fakir verir. Bu açıdan ayrılan bütçe büyüklüünü bir ölçev olarak kullanmak faydalı olacaktır. Bununda beraber nihai ürünün önemide direk gereken çabayı etkileyecektir. Bu bize toplam baskıyı vermenin yanısıra o proje atanacak çalıanların yetkinlikleri ile ilgili bir bilgi vermi olacaktır. Hatta yönetimsel destek ile ilgili önemli bir parametre olması dolaysıyla projenin planlanan zamanda bitmesini etkileyecektir. Ürünün beklenen özellikleri ölçevinin alt ölçevlerini belirledik. Bunlar esneklik, güvenilirlik, kullanım kolaylıı, bakım yapılabilirlik, güvenlik ve dökümantasyon dur. B. Kaynak Kaynaın büyüklüü ve nitelii direk olarak sonucu etkilemektedir. Basit olarak bir iin maliyetini bulmak istersek ürünün büyüklüünü ve dolayısıyla gereken kaynaın büyüklüünün ne olduunu bilmeye ihtiyacımız vardır. Çalıan yetkinliklerini ise gruplara göre alt ölçevlerini oluturduk. Bunlar proje yöneticisin yetkinlii, yazılım gelitiricilerin yetkinlii, system analistlerin yetkinlii ve test edenlerin yetkinlikleridir. Çalıan kii sayılarını gruplara göre alt ölçevlerde kapsamak faydalı olacaktır. Yazılım gelitirici sayısı, analist sayısı, test yapanların sayısı ve genelde bir olmasına ramen olası durumlar için proje yöneticisi sayısı alt ölçevlerdir. Donanım durumu ölçevinin de alt ölçevleri vardır. Bunlar zaman kısıtı, depolama kısıtı, platform deikenliidir. Bunların üçüde COCOMO da mevcuttur ve adları TIME, STOR ve PVOL dur. C. Risk Risk etkisi riskin oluma olasılıı ve bunun maliyetinin çarpımı olarak tanımlanabilir. Dolayısıyla ürün ve kaynak risklerini ve etkilerine ihtiyacımız vardır. Dolayısıyla her birinin alt ölçevlerini belirledik. Her birinin iki alt ölçevi vardır. Bunlar olma olasılıı ve olunca yaratacaı etkidir. D. Teknoloji Yazılım gelitirme araçları ve tecrübe oldukça önemlidir ve sonucu oldukça önemli bir biçimde etkiler. Yazılım gelitirme araçlarının kullanım kolaylıı yanında yer alan yazılım gelitirme araçlarındaki tecrübeninde alt ölçevini belirledik. Bunlar platform tecrübesi, uygulama tecrübesi, yazılım dili ve çoklu ortam gelitirme durumu tecrübesidir. Bunlar COCOMO da PEXP, AEXP ve LTEX,SITE olarak geçmektedir. E. Ortam Yazılım gelitirilen kurumun yapısı maliyetleri direk etkilemektedir. Bu kurumdaki ortalama gecikme, ortalama sapma, baskı, sahiplenme ve sorumluluk gibi durumlar sonucu direk

6 etkilemektedir. Ortamın genel özellikleri ölçevinin alt ölçevlerini geciken proje oranı, kurumdaki ortalam gecikme oranı, ortalama gecikme miktarı, gecikmenin standart sapma miktarıdır. Sahiplenme çok önemli bir ölçevdir. Bunun alt ölçevleri proje yöneticisinin, yönetimin, müterinin, proje çalıanlarının sahiplenme durumları alt ölçevlerdir. Baskı miktarı projenin gecikip gecikmeyeceine ve maliyete etkileyen önemli bir ölçevdir. Bunun 3 alt ölçevi vardır. Bunlar pazar baskısı, müteri baskısı, yönetim baskısıdır. Zaman yönetimin alt ölçevleri bir çalıanın ortalama gün içinde kesilme (interrupt) sayısı, bir kesilmenin ortalama süresi, kesilme sonrası önceki duruma geçme ortalama süresi, bu kurumda ortalama yapılan fazla mesai süresidir. F. Planlar ve Tahminler Uzman görüü çou yerde en çok kullanılan yazılım maliyeti tahmin etme yöntemidir. Bu yöntem maalesef mevcut yöntemler arasında hala en baarılı olandır. Bu görüüde bir ölçev olarak almak faydalı olacaktır. Bu uzmanların tahmin sapma oranlarınıda bir ölçev olarak aldıımız takdirde daha doru sonuçlar alabileceiz. Tahmin ölçevinin alt ölçevleri tahmini zaman planı, Tahmini yapankii veya kiilerin otalama sapma oranıdır. Plan ölçevinin alt ölçevi planlanan zaman, yanılma oranı ve hedeflenen zamanda bitmemesi durumunda katlanılabilinirlik eklindedir. 3. Yapay Sinir Aı Önerisi Temelde iki tür maliyet tahmin yöntemi vardır : algoritmik ve algoritmik olmayan. Algoritmik modellerin bazıları istatistii kullanarak basit aritmetik formüller kullanmaktadır. Algoritmik model bir takım deikenleri kullanan bir fonksiyon (1) olarak düünebiliriz. Maliyet = f(x1, x2,, xn) (1) Burada x1,x2,..xn, maliyet faktorleri olarak düünebiliriz. Bir çok maliyet çalımasında kullanılan COCOMO II modelinin 4 temel maliyet faktörü vardır : ürün faktörleri, bilgisayar faktörleri, personel faktörleri ve proje faktörleri. kinci kısımda önerdiimiz ölçev kümesi COCOMO nun tüm ölçevlerini kapsamaktadır. Ancak bu 4 temel faktör yerine 6 temel faktör getirmitir. Maliyet tahminleme aslında oldukça karmaık bir problemdir ancak bugune kadar gereken ilgiyi görmemitir. Aratırmacılar deiik yaklaımlar getirmeye çalımılardır. Son zamanlarda yeni yeni yapay zeka yaklaımları düünülmeye balanmıtır.temel ve basit gösterimle durum ekil 1 de gösterilmitir. Yapay sinir aları kullanılarak yapılan bazı çalımalar vardır. Bu konu henüz yeni gelien bir konudur. Bu konuda yapılmı çalımaları tablo 2 de görebilirsiniz.

7 ekil 1. Yapay Sinir aı (YSA) Topolojisi Tablo 2. Yapay sinir Aı kullanarak Yazılım Maliyet Tahminlemesi yapma konusunda yapılmı çalımalar Çalıma Kullanılan Algoritma Ölçev Kümesi Proje Sayısı Sonuç (MMRE) Wittig & Finnie [6] Back-Propagation ASMA ve 136 ve 81 17% Desharnais Venkatachalm [7] Back-Propagation COCOMO 63 Jorgenson [8] Back-Propagation Jorgensen % Serluca [9] Back-Propagation Mermaid % Karunanithi et al [10] Cascade- Correlation Samson et al [11] Back-Propagation COCOMO % Srinivasan & Fisher [12] Back-Propagation Kemerer ve 78 70% COCOMO Hughes [13] Back-Propagation Hughes 33 55% Yapay sinir aı kullanarak maliyet tahminlemede iyi bir tahminleme oranı yakalayacaımızı düünüyoruz. Yapılan çalımalarda baarıyı artırmak için tahminleme çalıılmı ve girdiler çok önemsenmemitir. Burada bir farklılık yaratarak önemli bir sonuç farkı olabileceini düünmekteyiz. Ölçev kümesinin yazılım maliyet tahmininde çok önemli bir rolü vardır. Bir çok model ölçev kümesi üzerinde çok çalıma yapmadan COCOMO yu kullanmayı tercih edip çounlukla tahminleme yöntemi üzerinde çalımayı tercih etmilerdir. Ancak ölçev kümesi sonucu direk etkilemektedir. Dolayısıyla iyi bir tahminleme çalıması yapmadan önce iyi bir ölçev kümesi ile ie balamak önemlidir. Bu konuda yapılan en ünlü çalıma Wittig ve Finnie nin yaptıı çalımadır. [10] Avusturya Yazılım Metric Birliinin (ASMA) verilerini kullanmılardır.[6] Göreceli hatanın miktarının ortalaması (MMRE) göz önüne alınarak en baarılı olanın Wittig & Finnie çalımasıdır. Bu çalımada COCOMO ölçev kümesini direk girdi olarak kullanmıtır. (ekil 1) Bu çalımayı baz alarak bizim önerdiimiz ölçev setini bu yapı üzerine oturtabiliriz. Bu durumu ekil 2 de görebilirsiniz. Bu çok katmanlı perceptron a topolojisi bizim önerimizdir.

8 ekil 2. Wittig & Finnie çalımasında kullanılan yapay sinir aı topolojisi ekil 3. Önerdiimiz yapay sinir aı topolojisi

9 4. Sonuç Yazılım projeleri maliyet tahmini yapmadan önce ölçev kümesi oluturmak durumundayız. Ölçev kümesi çalımasını gerektii kadar önemsemeden yazılım projeleri maliyeti tahminleme yöntemleri üzerinde yapılan çalımalar yeteri kadar baarılı olamamaktadırlar. Belirlediimiz ölçevleri düzgün kullanılabilinirsek bize salayacaı yararlar : 1. Nicel olarak baarıyı ve baarısızlıı tanımlayabileceiz. Bir ürünün, bir sürecin veya bir kiinin baarı veya baarısızlıın derecesini nicel olarak tanımlayabileceiz. 2. Ürünlerimizde, süreçlerimizde ve kiilerdeki geliimi, geliim eksikliini, bozulmayı ve gerilemeyi tanımlayabilir ve ölçebiliriz. 3. Teknik ve yönetimsel kararlar vermemizde yarar salar. 4. Trend'leri tanımlamamızı salar. 5. Mantıklı tahminler yapmakta kullanılabilinir. Bu makalenin iki temel amacı vardır. Biri bir ölçev seti önermek dieri bunu kullanarak bir yapay sinir aı topolojisi önermektir. Kaynakça 1 The Standish Group, CHAOS Chronicles, Standish Group Int. Report, Stephen H.Kan: Metrics and Models in Software Quality Engineering, Ad.-Wesley, Gray, A.R. and S.G. MacDonell, A Comparison of Alternatives to Regression Analysis as Model Building Techniques to Develop Predictive Equations for SW Metrics. No., University of Otago, E.Fenton : Software Metrics,Chapman&Hall 5 Bayesian Analysis of Software Cost and Qualıty models,sunita devnani-chulani,university of Southern California, Doctor of philosophy Thesis, Wittig, G. and G. Finnie, Estimating Software Development Effort with Connectionist Models. Information and Software Technology, vol 39pp , Venkatachalam, A.R. Software Cost Estimation Using Artificial Neural Networks. in International Joint Conference on Neural Networks. Nagoya: IEEE, Jorgensen, M., Experience with the Accuracy of Software Main. Task Effort Prediction Models. IEEE Transactions on Software Engineering, vol 21(8), pp , Serluca, C., An Investigation Into Software Effort Estimation using a Back-Propogation Neural Network. 1995, M.Sc. Thesis, Bournemouth University: 10 Karunanithi, N., D. Whitley, and Y.K. Malaiya, Using Neural Networks in Reliability Prediction. IEEE Software, vol 9(4), pp53-59, Samson, B., D. Ellison, and P. Dugard. Software Cost Estimation using an Albus Perceptron(CMAC). in Proc. Eight International COCOMO Est. Meeting. Pittsburgh: Srinivasan, K. and D. Fisher, Machine Learning Approaches to Estimating Software Dev. Effort. IEEE Transactions on Software Engineering, vol 21(2), pp , Hughes, R.T., An Evaluation of Machine Learning Techniques for Software Effort Estimation. University of Brighton, 1996.