Yazılım Projelerinde, Geliştirme Teknolojilerinin İşgücüne Etkisi: Bir

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
[email protected]
[email protected]
[email protected]
Ö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.