Yazılım Projelerinde, Geliştirme Teknolojilerinin İşgücüne Etkisi: Bir
Transkript
Yazılım Projelerinde, Geliştirme Teknolojilerinin İşgücüne Etkisi: Bir
Yaz m Projelerinde, Geli tirme Teknolojilerinin Bir Durum Çal mas gücüne Etkisi: The Effect of Implementation Technology on Software Development Effort: An Industrial Case lkay, Ünal Savunma Teknolojileri Mühendislik ve Ticaret A. . Bilkent, Ankara Erdir, Ungan Enformatik Enstitüsü Bili im Sistemleri ODTÜ, Ankara Onur, Demirörs Enformatik Enstitüsü Bili im Sistemleri ODTÜ, Ankara iunal@stm.com.tr erdir@ii.metu.edu.tr demirors@metu.edu.tr Özet Bu makalede, yaz m projelerinde kullan lan geli tirme teknolojilerinin i gücünü ne ekilde etkiledi ini gözlemek amac yla gerçekle tirdi imiz bir endüstriyel durum çal mas n sonuçlar sunulmaktad r. Bunun yan ra, k yaslama çal malar nda kullan lan ve referans veri kümeleri taraf ndan tan mlanm büyüklük d proje özniteliklerinin i gücü kestirimlerinde kullan da tart lm r. Abstract In this paper, we present the results of an industrial case in which we demonstrate the effect of implementation technology on project effort. We also discuss the project attributes defined by benchmarking data sets and the involvement of non-functional project characteristics in effort estimation methods. 1. Giri Do ru i gücü kestirimi, yaz m projelerinin ba ar bir ekilde yönetilebilmesi için, çok önemlidir. Bu alanda yap lm birçok çal ma [25],[22], ba ar zl kla sonuçlanan yaz m projelerinin ço unun yanl kestirimler nedeniyle ba ar z oldu unu göstermektedir. Geçti imiz otuz y l içerisinde yaz m projelerinde kullan lmak üzere birçok kestirim yöntemi geli tirilmi ve kullan ma sunulmu tur. Genelgeçer bu modellerin yan s ra, kurumlar kendilerine özgü kestirim yöntemleri ve modelleri geli tirmi lerdir. Bütün bu yöntemler üç ana grupta de erlendirilebilir [16]. Uzman Görü ü: Bu yöntemler belli bir uygulama alan nda yaz m geli tirme konusunda deneyim sahibi uzmanlar n, geçmi deneyimlerine dayanarak kestirim yapmalar na dayanan yöntemlerdir. Kurall Kestirim Yöntemleri: Bu yöntemler, nicel verilere ve bu verileri kullanan matematiksel modellere ve formüllere dayanan yöntemlerdir. Bile ik Kestirim Yöntemleri: Bu yöntemler, yukar da bahsedilen iki türün yakla mlar birle tiren yöntemlerdir. Öznel de erlendirmeler ve matematiksel modellerin beraber kullan içerir. Kurall kestirim yöntemleri, büyük oranda geçmi verilere dayal k yas çal malar temel al r. K yaslama çal malar nda kullan lan bu veriler, bir kurumun kendi proje veritaban ndan gelebilece i gibi, genel kullan ma aç k referans veri kümeleri de bu amaç için kullan labilir. Kurum içi verilerin kullan ld k yas çal malar ç K yaslama, referans veri kümelerinin kullan ld çal malar ise D K yaslama olarak adland r. Var olan i gücü kestirim yöntemlerinin ana girdisini yaz m büyüklük verileri olu turmaktad r [6]. Ancak, bu alanda yap lan birçok çal mada, proje özelliklerinin de gücü üzerinde belirgin bir etkisi oldu u kan tlanm r [10][3][2]. Bu nedenle, ISBSG (International Software Benchmarking Standards Group), CSBSG (Chinese Software Benchmarking Standards Group) [7], IPA/SEC [12], PROMISE (Predictor Models in Software Engineering) [21] ve Experience Pro [8] gibi yayg n olarak kullan lan birçok referans veri kümesi, yaz m projelerinin büyüklülerinin yan s ra, i levsel olmayan proje özniteliklerine dair çe itli veriler de sa lamaktad r [13]. Benzer ekilde, birçok iç ve d k yaslama yöntemi de i gücü kestirimleri için bu tip proje özniteliklerinin kullan içermektedir [14][24]. En yayg n olarak kabul gören referans veri kümesi olan ISBSG [13] taraf ndan kullan lan proje öznitelikleri u ekilde gruplanmaktad r [6]: Proje Ortam : Ülke, kurum tipi, i alan ve uygulama geli tirme tipi. Ürün Özellikleri: Uygulama türü, mimari, kullan tipi. Geli tirme Ortam Özellikleri: Geli tirme tak n özellikleri, geli tirme teknolojileri (programlama dili, platformu, kullan lan yaz m mühendisli i araçlar ) ve geli tirme teknikleri. Projenin Yürütülmesinde Etkili Nitelikler: Geli tiricilerin deneyim seviyeleri, gereksinimlerin de kenli i. Bu çal mam zda, yaz m geli tiren bir kurum bünyesinde bir kar la rmal vaka analizi gerçekle tirdik. Bu analizde, yukar da bahsedilen proje özniteliklerinden tek bir tanesini di er etmenlerden ayr rma ve proje i gücü üzerindeki tekil etkisini gözlemleme olana bulduk. Bu makalede aktard z çal ma, bahsedilen kurumun i gücü kestirim yöntemlerinin ba ar de erlendirmek üzere gerçekle tirdi imiz daha geni kapsaml bir çal man n bir ad olu turmaktad r. Kurumda, uzman görü üne ve i levsel yaz m büyüklü üne dayal kestirim yöntemleri içeren oturmu bir kestirim süreci bulunmaktad r. Bu sürecin verimlili ini de erlendirmek amac yla yap lan çal man n bir parças olarak, kestirimlerde proje özelliklerinin ne derecede de erlendirildi i ve hangi özniteliklerin kullan ld incelenmi tir. Kurum bünyesinde yürütülen projelerin biri, tek bir gereksinim kümesinin iki ayr platform için geli tirilmesini içermektedir. Bu iki geli tirme etkinli i iki farkl proje olarak ele al nm r. Çal ma sonunda, bu iki projenin kar la lmas ile programlama dili ve platformu gibi geli tirme teknolojisini tan mlayan proje özniteliklerinin gerekli i gücü üzerinde belirgin etkileri oldu u kan tlanm r. Bu makalede, bu kar la rmal analizin sonuçlar sunulmu tur. Çal mada inceledi imiz durum, i gücü kestirimleri ve k yas çal malar alan nda yürütülen ara rmalar için de yararl bir veri olu turmaktad r. Yukar da bahsedildi i gibi, i levsel olmayan proje özelliklerinin proje i gücünü etkiledi i ve bu nedenle k yaslama tabanl çal malarda de erlendirilmeye al nmas gerekti i kan tlanm r [10][3][2]. Ancak, bu proje özelliklerinin i gücü üzerindeki tekil etkilerini incelemek her zaman mümkün olamamaktad r. Bunun nedeni, her bir yaz m projesinin benzersiz olmas ve projeden projeye birçok proje özelli inin birden de mesidir. Bu durum proje özelliklerini ayr ayr incelemeyi olanaks z k lmaktad r. Bu çal mada sundu umuz durumda ise proje özelliklerinden biri olan geli tirme teknolojisi, di er özelliklerden ayr labilmi ve i gücü üzerindeki yal n etkisi incelebilmi tir. 2. Çal ma Ana çal mada, kurumun i gücü kestirim süreci incelenmi , kurum bünyesinde yak n zamanda tamamlanm veya halen devam etmekte olan projeler, özniteliklerine, büyüklüklerine ve i gücü verileri temel al narak de erlendirilmi tir. Devam etmekte olan projeler aras ndan, yukar da bahsedildi i gibi, tek bir gereksinim kümesi için iki ayr platformda yaz m geli tirilmesini içeren bir proje seçilmi tir. Bu iki geli tirme yaz m geli tirme faaliyeti iki alt proje olarak ele al nm r. Bu iki alt proje, ayn proje yönetimi etkinlikleri ile yönetilmi ve çok benzer ekiplerce geli tirilmi tir. Bu iki proje öncelikle proje özellikleri temel al narak kar la lm r. Bu kar la rmada ISBSG taraf ndan tan mlanan proje öznitelikleri kullan lm r. Kar la rma sonucunda geli tirme teknolojileri ndaki özniteliklerin çok benzer ç kmas öngörülmü tür. Daha sonra, projelerin gereksinimleri kar la lm ve ortak gereksinimlerin d nda, platforma özgü gereksinimlerin varl ara lm r. Projelerin i levsel büyüklükleri COSMIC levsel Büyüklük Yöntemi ile ölçülmü tür. Birçok gereksinimleri ortak oldu undan projelerin i levsel büyüklüklerinin de çok yak n ç kmas öngörülmü tür. Daha sonra, projelerin her bir ya am döngüsü amas için i gücü verileri toplanm r. Son olarak, toplanan i gücü verileri kar la larak, geli tirme teknolojisindeki farkl n i gücünde nas l bir de ikli e neden oldu u ara lm r. 2.1. Kurum Çal ma, CMMI (Capability Maturity Model Integration) seviye 3 olgunlu unda bir yaz m irketinde gerçekle tirilmi tir. irket, 1991 y ndan beri, sistem mühendisli i, proje yönetimi, teknoloji transferi ve lojistik destek alanlar nda hizmet vermekte ve savunma sistemleri için yaz m geli tirmektedir. irket bünyesinde toplamda 300, yaz m geli tirme projelerinde ise 50 ki i çal maktad r. irket, SEI CMMI Seviye 3 belgelendirmesi d nda, u belgelere sahiptir: TSE-EN-ISO 9001:2000: Consultancy, Design, Development, Installation and Maintenance of Software Based Systems NATO AQAP 160: Software Based System Design, Development, Integration and Maintenance TS ISO/IEC 27001 Information Management System Certificate. Security Kurum, i gücü kestirimleri ve proje ilerleyi ini denetlemek amac yla levsel yaz m büyüklü ü kullanmaktad r. Kullan lan i gücü kestiririm süreci birkaç ad mdan olu maktad r. Uzman görü ü ve kurall kestirim yöntemlerini içermektedir. Proje ba lang nda, gereksinimler netle medi inden yaz m büyüklü ü ve i gücü uzmanlarca kestirilir. Daha sonra analiz a amas n sonunda gereksinimler olu turulur ve bu gereksinimler üzerinde COSMIC V2.2 ölçümü gerçekle tirilir. Kurumda iki tip proje için COSMIC ölçümü gerçekle tirilir. Yönetim bilgi sistemleri gibi veri yo un yaz mlar. Komuta ve kontrol yaz mlar gibi kontrol yo un yaz mlar. COSMIC ölçüm yöntemi uyguland nda yaz n levsel büyüklü ünün say sal bir de eri elde edilir. Kurum, kendi geçmi proje verilerini kullanan, büyüklük tabanl bir i gücü kestirim yöntemi geli tirmi tir. Ölçülen COSMIC i levsel büyüklük, proje özelliklerini yans tan baz çarpanlarla düzeltilir. Toplam büyüklük proje ekibinin özelliklerine ba bir çarpanla düzeltilirken, yeniden kullan m ve karma kl k özelliklerini yans tan çarpanlar COSMIC ölçümündeki her bir i levsel süreç için belirlenir. Düzeltilmi COSMIC büyüklük a daki formülle hesaplan r. 2.2. Projeler Çal mada kar la lan projeler, daha büyük bir projenin alt parçalar r. Ana proje burada incelenen projelere benzer 4 parçadan olu maktad r ve tamamlanmas 40 ay sürmü tür. Ana projenin ç kt , bir komuta kontrol bilgi sistemi olup, araç içi ve araçlar aras veri haberle mesi için kullan lmaktad r. Bu çal ma kapsam nda incelenen iki alt yaz m parças birbirleri ile ayn i levselli e sahip olup, bu levselli i farkl araçlar ve farkl platformlarda gerçekle tireceklerinden iki ayr proje olarak ele al nm lard r. Her iki projede kullan lan gerçekle tirme teknolojileri ve araçlar Tablo 1’de özetlenmi tir. Tablo 1: Projelerde Kullan lan Araç ve Teknolojiler Proje #1 Nesne VxWorks 6.3 (Real Time OS) Microsoft Windows XP Programlama Dili C++ C# Tasar m Arac Telelogic Rhapsody 7.2 Sparx Enterprise Architect 7.1 Geli tirme Ortam WindRiver Workbench 2.5 Visual Studio .NET 2005 Framework letim Sistemi Düzeltilmi COSMIC Büyüklük = ( ( ( Her Bir levsel Süreçteki Veri Hareketi Say ) x Yaz m Kal m Çarpan x Ürün Karma kl k Çarpan ) ) x Personel Özellikleri Çarpan (1) Formülde, Yaz m Kal m Çarpan , Yeniden kullan ma ba gücü Düzeltme Çarpan na [17], Tablo 2: Projelerin Çal an Bilgileri Proje Ürün Karma kl k Çarpan , COCOMO yönteminde tan mlanan karma kl k faktörüne [11], Personel Özellikleri Çarpan , geli tirici ekibin genel deneyim ve yeterlik seviyesine kar k gelmektedir. Çarpan tan mlar ve katsay lar COCOMO yönteminde verilen tan m ve de erler temel al narak belirlenmi tir. Ayr ca, kurumun kestirim süreci kapsam nda, yaz m büyüklü ü proje sonunda bir kez daha ölçülür. Bu ölçümler, kurumda yaz m büyüklü ünün proje boyunca gösterdi i de imlerle ilgili veri birikmesini sa lamaktad r. Elde edilen bu veriler, gelecekteki projelerin kestirimlerinde ve proje sonunda elde edilecek yaz m büyüklüklerinin tahmin edilmesinde kullan lmaktad r. Proje #2 Nesne Metodoloji Her iki proje Proje #1 Proje #2 Görev Say Tam/Yar Zamanl Ort. Deneyim (Y l) Proje Yöneticisi 1 Tam Zamanl 15 Yaz m Kalite Mühendisi 1 Yar Zamanl 20 Konfigürasyon Yöneticisi 1 Yar Zamanl 10 Sistem Mühendisi 3 Tam Zamanl 10 Yaz m Mühendisi 7 Tam Zamanl 7 Test Mühendisi 1 Yar Zamanl 8 Yaz m Mühendisi 6 Tam Zamanl 6 Test Mühendisi 1 Yar Zamanl 8 Projeler bir ana projenin alt projeleri oldu undan, iki projenin proje yöneticisi Yaz m Kalite Mühendisi, Konfigürasyon yöneticisi ve sistem mühendisleri ortakt r. Di er çal anlar n, Yaz m mühendisleri ve test mühendislerinin projelere göre da Tablo 2’de verilmi tir. 2.3. Veriler Projelerin gereksinimlerinde tan mlanan i levselliklerin büyük bir k sm ortakt r. Ba ka bir deyi le, belirli bir küme gereksinim projelerin toplam gereksinimlerinin ço unlu unu olu turmaktad r. Ancak her iki projede de projeye özgü baz gereksinimler bulundu u, Proje 1’in, Proje 2’den daha fazla gereksinim içerdi i tespit edilmi tir. Bu durum, gerçek zamanl i letim sistemlerinde gerek duyulan s rlama ve yap land rma lemlerine ba gereksinimlerden kaynaklanmaktad r. Ekranlar n kullan ve ekranlar aras geçi ler ile ilgili gereksinimlerin de her iki i letim sistemi için farkl yaz lmas gerekmi tir. Bu iki unsur, iki projenin gereksinim say lar nda az da olsa bir farkl a yol açm r. Projelerin gereksinim say lar , i levsel kullan gereksinim say lar ( KG) ve ortak gereksinimlerin say Tablo 3‘de verilmi tir. Tablo 3: Projelerin Gereksinim Say lar Gereksinimler Proje #2 932 853 765 886 KG’ler 781 754 Ortak KG’ler Ortak Gereksinimlerin Oran %82.08 %89.69 Ortak Oran %85.10 %96.54 KG’lerin bak aç na göre yaz m kullan ya sa layaca levsel Kullan Gereksinimlerinden, her bir uygulamayla ilgili Tetikleyici Olaylar ile uygulamaya ait levsel Süreçler ve Veri Gruplar olu turulur. Her bir (Giri , ç levsel Süreç içindeki Veri Hareketleri , okuma, yazma) belirlenir ve ölçülür. Tüm i levsel süreçler için yap lan ölçümler toplan r ve yaz m büyüklü ü elde edilir. Projelerin COSMIC büyüklükleri ve elde edilen i gücü verileri Tablo 4‘de verilmi tir. Tablo 4 : Projelerin COSMIC Büyüklükleri ve gücü Verileri COSMIC (Cfsu (COSMIC- v2.2)) Harcanan gücü (Adam-Saat) Proje #1 1918 17183 Proje #2 1965 14177 3. Bulgular Proje #1 Ortak Gereksinimler uygulan r. Son kullan bile eninin son fonksiyonellik ölçülür. Proje verisi çe itli araçlar kullan larak düzenli ve otomatik olarak toplanm r. Harcanan i gücü için Primavera Timesheet arac kullan lm r. Proje çal anlar günlük olarak saat baz nda harcad klar gücünü araca girmi ve bu de erler proje yöneticisi taraf ndan onaylanm r. Bildiride yeralan i gücü de erleri, gizlilik ve kurum mahremiyeti nedeniyle belli bir de erle orant kurularak de tirilmi de erlerdir. Yukar da bahsedili i gibi, yaz mlar n büyüklü ü COSMIC BÖ ( levsel Büyüklük Ölçümü) yöntemi kullan larak elde edilmi tir. Kurumda COSMIC BÖ yönteminde süreçlere uygun olarak a daki ad mlar izlenmektedir: Kurumda, COSMIC’de önerilen geli tirici ve son kullan bak aç lar ndan, son kullan bak aç Bu bölümde önceki bölümde incelenen iki proje, önceki bölümde sunulan veriler üzerinden kar la lm r. Bu kar la rmada, ISBSG taraf ndan kullan lan proje öznitelikleri temel al nm r [13]. Her bir öznitelik için kar la rma sonuçlar bu makale kapsam nda sunmak olanaks z oldu undan, 1. k mda bahsedilen gruplama öznitelik gruplamas esas al nm r [6]. 3.1. COSMIC Büyüklü ü Proje #1’in büyüklü ü 1918 CFP (Cosmic Functional Points), Proje #2’nin büyüklü ü 1965 CFP olarak ölçülmü tür. ki proje aras ndaki i levsel büyüklük farkl %3’ten azd r. Projelerin büyüklükleri aras ndaki fark ihmal edilebilecek kadar küçük oldu undan, büyüklük farkl gücü farkl etkileyecek bir etmen olarak de erlendirilmemi tir. 3.2. Proje Ortam Ülke, kurum tipi, i alan ve uygulama geli tirme tipi gibi özniteliklerdir. ncelenen projeler ayn kurumda gerçekle tirildi inden bu özellikler her iki proje için ayn r. Bu nedenle bu gruptaki özellikler de i gücü farkl etkileyen bir etmen de ildir. 3.3. Ürün Özellikleri Uygulama türü, mimari, kullan tipi gibi özelliklerdir. Her iki projede üretilen yaz m da “Elektronik veri arayüzü” türündedir ve mimarileri ayn r. Her iki yaz m ürünü de ayn kullan lar taraf ndan ayn amaçlarla kullan laca ndan, projelerin “kullan tipi” özelli i ayn r. Ürün özellikleri grubundaki öznitelikler de i gücü farkl etkileyen etmenler olarak de erlendirilmemi tir. 3.4. Geli tirme Ortam Özellikleri Geli tirme tak n özellikleri, geli tirme teknolojileri (programlama dili, platformu, kullan lan yaz m mühendisli i araçlar ) ve geli tirme teknikleri gibi özniteliklerdir. Her iki projenin proje yöneticisi, yaz m kalite mühendisi, konfigürasyon yöneticisi ve sistem mühendisleri ortakt r. Proje #1’de 7 yaz m mühendisi (geli tirici), proje #2’de 6 yaz m mühendisi (geli tirici) görev alm r. Her iki projede de bir adet test mühendisi görev alm r. Önceki bölümde sunuldu u üzere, yaz m mühendisleri ve test mühendislerinin deneyimleri ve say projeler aras nda çok az bir farkl k göstermektedir. Çal an say lar aras ndaki fark ISBSG taraf ndan kullan lan tan m ve veriler göz önüne al nd nda, ihmal edilebilir düzeydedir. Bu nedenle, iki projenin geli tirme tak mlar n özellikleri, i gücü farkl etkileyen bir etmen olarak de erlendirilmemi tir. Proje #1 C++, Proje #2 ise C# programlama dilleri kullan larak geli tirilmi tir. Proje #1’de geli tirme ortam olarak WindRiver Workbench 2.5, Proje #2’de ise Visual Studio .NET 2005 kullan lm r. Programlama dili ve geli tirme platformu iki projenin belirgin ekilde farkl la özellikler olmu lard r. 3.5. Projenin Yürütülmesinde Etkili Nitelikler Geli tiricilerin deneyim seviyeleri, gereksinimlerin de kenli i, kullan lan araçlar n projeye uygunlu u gibi özelliklerdir. Proje #1’de görev alan yaz m mühendislerinin ortalama deneyim seviyeleri 7 y l, Proje #2’de yer alan yaz m mühendislerinin ortalama deneyim seviyeleri 6 ld r. Yine ISBGS’nin “çal an deneyimi” özniteli i için kulland tan m göz önüne al nd nda, bu fark n ihmal edilebilir bir fark oldu u görülür. Zira ISBSG veri kümesinde, çal an deneyim seviyeleri “0-3 y l”, “3-9 l” ve “9 y ldan fazla” eklinde tan mlanm r. Bu nedenle “çal an deneyimi” projeler aras ndaki gücü farkl etkileyen bir etmen olarak de erlendirilmemi tir. Projelerin gereksinimlerinin büyük ço unlu u ortakt r. Ortak olmayan gereksinimler büyük oranda letim sistemi ve ekran gereksinimlerinden türemi oldu undan kullan gereksinimlerine oranla çok daha az de ikli e u ram lard r. Bu nedenle “Gereksinimlerin De kenli i” her iki proje için ayn kabul edilmi tir. Özet olarak, proje özelliklerine dayal olarak gerçekle tirilen bu kar la rmalarda, geli tirme teknolojileri ile ilgili proje özellikleri d ndaki proje özelliklerinin iki proje aras nda kayda de er bir de iklik göstermedi i belirlenmi tir. Bununla beraber, projeler için harcanan i gücü miktarlar kar la ld nda; proje #1 için, proje #2’den %21 daha fazla i gücü harcand görülmektedir. Bu iki ana bulgu nda, projelerin i gücü miktarlar aras ndaki fark n esas olarak geli tirme teknolojilerindeki farkl ktan kaynakland söylenebilir. Kullan lan programlama dilleri, geli tirme platformlar ve hedef i letim sistemleri aras ndaki farkl n i gücünde %21 seviyesine bir farkl a neden oldu u gözlemlenmektedir. Bu durumdan öyle bir yan ç kar ma daha varmak mümkündür: Programlama dili, tasar m arac , geli tirme platformu ve benzeri teknoloji seçimlerinin temelde, hedef i letim sistemi seçimine ba birer mühendislik karar r. Di er bir deyi le, hedef i letim sistemi seçimi geli tirme teknolojileri ile ilgili proje özelliklerini direk olarak etkilemektedir. Bu durumda, gerçek zamanl letim sistemleri için yaz m geli tirmenin, di er geleneksel i letim sistemlerine oranla çok daha fazla gücü gerektirdi i sonucuna var labilir. 4. Sonuç Bu çal mada, geli tirme teknolojilerinin i gücünü etkileyen ana etmenlerden biri oldu u kan tlanm r. Bu nedenle, kurumlarda i gücü kestirimlerinin ba ar artt rmak için kurumlarda; Yaz m projelerinde kullan lan teknolojileri tan mlayacak proje öznitelikleri tan mlanmal r. Geçmi projeler için de bu öznitelikleri belirlenmeli ve k yas çal malar nda kullan lmal r. Kurumun i gücü kestirim süreci geli tirme teknolojilerinin etkisini de dikkate alacak ekilde güncellenmeli, bu süreçte geçmi projelere ait ilgili verilerin kullan lmas sa lanmal r. 5. Çal man n K tlar Çal mada incelenen kurumun, sahip oldu u belgeler ve kar lad standartlar göz önüne al nd nda, benzeri kurumlar için temsil gücü yüksek bir örnek oldu u söylenebilir. Buna ra men, çal ma tek bir kurumda gerçekle tirilmi oldu undan, sonuçlar n farkl büyüklükte ve yetkinlik seviyelerindeki kurumlara uygulanabilirli i ileriki çal malarda ara lacakt r. 6. Referanslar [1] A.J. Albrecht, Measuring Application Development Productivity. Proceedings of IBM Applications Development Symposium, Monterey, California, October 14-17 1979. [2] Boehm, B.W., Horowitz, E., Madachy, R., Reifer, D., Bradford K.C., Steece, B., Brown, A.W., Chulani, S., Abts, C.: Software Cost Estimation with COCOMO II, Prentice Hall, New Jersey, (2000). [3] Boehm, B.W.: Software Engineering Economics, PrenticeHall, (1981). [4] C. Gencel, and O. Demirors, “Functional Size Measurement Revisited”, scheduled for publication in ACM Transactions on Software Engineering and Methodology, July 2008. [5] C. Symons. Come Back Function Point Analysis (Modernized) – All is Forgiven!). Proc. of the 4th European Conference on Software Measurement and ICT Control, FESMA-DASMA 2001, Germany, 2001, pp. 413426. [6] Lokan C., Wright T, Hill P.R., Stringer M. Organizational Benchmarking Using the ISBSG Data Repository. IEEE Software September/October 2001 [7] CSBSG Data Repository, http://www.csbsg.org [8] Czarnacka-Chrobot, B. 2009. The Role of Benchmarking Data in the Software Development and Enhancement Projects Effort Planning. In Proceeding of the 2009 Conference on New Trends in Software Methodologies, Tools and Techniques: Proceedings of the Eighth Somet_09 H. Fujita and V. Ma írk, Eds. Frontiers in Artificial Intelligence and Applications, vol. 199. IOS Press, Amsterdam, The Netherlands, 106-127 [9] Experience Pro, http://www.sttf.fi [10] Gencel, C., Buglione, L.: Do Different Functionality Types Affect the Relationship between Software Functional Size and Effort? In: Proceedings of the Intern. Conf. on Software Process and Product Measurement (IWSMMENSURA 2007), Palma de Mallorca, Spain, November 5-8, 2007, pp. 235–246 (2007) [11] http://csse.usc.edu/csse/research/COCOMOII/cocomo_mai n.html [12] IPA/SEC Data Repository, http://www.ipa.go.jp/indexe.html [13] ISBSG Data Collection Questionnaire, http://www.isbsg.org/isbsgnew.nsf/webpages/-GBLData%20Collection%20Questionaires?opendocument [14] ISBSG: SC 7 Proposed New Work Item on Software and systems engineering – IT Performance Benchmarking Framework (2008), http://www.isbsg.org/ISBSGnew.nsf/WebPages/c7b3fcc5c e6308f7ca2574580013f206 [15] ISO/IEC 14143-1:1998 Information Technology - Software Measurement - Functional Size Measurement - Part 1: Definition of Concepts, 1998. [16] K. Kavoussanakis, Terry Sloan,UKHEC Report on Software Estimation,The University of Edinburgh December 2001 [17] K.Lum, Handbook for Software Cost Estimation, Jet Propulsion Laboratory, May 30, 2003 [18] Lokan, C. and Mendes, E. 2006. Cross-company and single-company effort models using the ISBSG database: a further replicated study. In Proceedings of the 2006 ACM/IEEE international Symposium on Empirical Software Engineering (Rio de Janeiro, Brazil, September 21 - 22, 2006). ISESE '06. ACM, New York, NY, 75-84. [19] M. Jorgensen, M. Shepperd. A Systematic Review of Software Development Cost Estimation Studies IEEE Transactions on Software Engineering 33(1):33-53 [20] Molkken, K. and Jrgensen, M. 2003. A Review of Surveys on Software Effort Estimation. In Proceedings of the 2003 international Symposium on Empirical Software Engineering (September 30 - October 01, 2003). International Symposium on Empirical Software Engineering. IEEE Computer Society, Washington, DC, 223. [21] PROMISE Data Repositories, http://promisedata.org, [22] Steve McConnell. Rapid development: taming wild software schedules. Microsoft Press, 1996. [23] The Common Software Measurement International Consortium (COSMIC). COSMIC-FFP v.2.2, Measurement Manual (January 2003) [24] Wang, H & Wang, H. & Zhang, H. (2008). Software Productivity Analysis with CSBSG Data Set, International Conference on Computer Science and Software Engineering, pp 587-593. [25] B W Boehm, C Abts, A W Brown, S Chulani, B K Clark, E Horowitz, R Madachy, D Reifer, and B Steece. Software Cost Estimation with COCOMO II. Prentice Hall PTR, 2000.