Cost/effort estimation sırasında kullanılacak veriler daha önce kullanılan ve ortaya atılan
modellerdeki verilere benzer olacak. Biz projede bugüne kadar geçerliliği en yüksek iki
modele, Cocomo veya Cocomo II, göre bir veri toplamayı şimdilik planlıyoruz. Fakat her
proje için toplanan veya hali hazırda bulunan ve bu formatta olmayan veriler de işimize
yarayacaktır.
Toplanacak veriler proje bazında, release bazında, her projedeki farklı component’lar bazında
olabilir. Bizim projemizdeki modelde verilerin çokluğu önemli olduğundan, çok veri
toplamaya elverişli olan bir baz seçmek tabii ki daha yararlı olacaktır.
Cocomo_quest.pdf dosyasında Cocomo II modeline göre verilerin nasıl toplanacağı detaylı
bir şekilde anlatılmaktadır. Fakat bazı veri tiplerinde detaydan kaçınılmıştır. Bu dökumanda
ilgili verilerle ilgili pdf dökumanına referans verilerek açıklama yapılacaktır. Verileri
toplamak zor değildir, fakat yapılan araştırmalara göre project manager veya grup manager
supervision’ında toplanması daha yararlı sonuçlar verir.
Bu dosyada 20-24 ve 6-7 sayfalarındaki veriler bizi ilgilendirmektedir. Bu veriler component,
release veya proje bazında toplanabilir. 6-7’ deki veriler 5 adet scale factor‘ u içermektedir.
Diğer sayfalarda ise 17 adet asıl cost factor’leri bulunmakatadır. Bunlardan ayrı olarak seçilen
baza göre person-month biriminde o proje, component veya release için bir effort verisi de
tutulmalıdır. Bu değer yaklaşık olarak belirtilebilir.
6-7’deki verilerden precentedness (PREC) ve development flexibility (FLEX) aşağıdaki tablo
kullanılarak çıkarılabilir. Eğer hali hazırda bu değer yoksa, precentedness yerine tablodaki 4
değeri çıkarmanız yararlı olabilir. Yine developmant flexibility de de tablodaki 3 değer
çıkarılabilir.
Tablo1 – PREC ve FLEX verileri
1
Sayfa 6’ daki Architecture / Risk Resolution (RESL) aşağıdaki tablodaki veriler çıkarılarak
hesaplanır. Tablodaki verileri çıkarmak yeterlidir.
Tablo 2 – RESL verileri
Sayfa 6’ da yer alan team cohesion (TEAM) Tablo 3 deki veriler çıkarılarak hesaplanır.
Tablodaki tüm veriler çıkarılmalıdır.
Tablo 3 – TEAM verileri
2
Sayfa 7’de Process Maturity (PMAT) factor’u ya CMM level’ine ya da KPA değerine göre
belirlenir. Eğer CMM level’i biliniyorsa o verilmeli bilinmiyorsa sayfa 7’de verilen
değerlendirme yapısı kullanılarak sayfa 8-9’ daki tablo doldurulmalı ve verilmelidir. PMAT
değeri bu veriler kulanılarak hesaplanacaktır.
Sayfa 20-24’ teki veriler effort için topalnılan verilerdir. 4 farklı kategoride sunulmuştur :
product, platform, personnel, ve project.
Sayfa 20’de product cost drivers vardır. RELY açıklaması dökumanda verlmiştir. DATA
verisinin toplanması için bazı değerlerin hesaplanması gerekmektedir. D/P hesaplanarak
bulunur. Bu değere tablodaki aralıklara bakılarak bir değer atanır. D/P şöyle hesaplanır.
Burada byte değeri test esnasındaki değer olarak alınır. SLOC ise source lines of code’dur. Bu
değer code satır saymı yapılarak veya unadjusted function point (UAF) sayısı kullanılarak
bulunabilir. Eğer SLOC bilinmiyorsa Tablo 4 kullanılarak SLOC çıkarılabilir.
Tablo 4 – UAF-SLOC dönüştürme verileri
3
Sayfa 20’de Develop for Reuse (RUSE) ‘u hesaplamak için ASLOC (adapted source lines of
code), yani reuse edilen kod büyüklüğü, DM (percent design modified), CM (percent code
modified) ve IM (Percent of Integration Required for Modified Software) değerleri
verilmelidir. Bunların açıklaması aşağıdadır.
DM: Percent Design Modified. The percentage of the adapted software’s design which
is modified in order to adapt it to the new objectives and environment. (This is
necessarily a subjective quantity.)
CM: Percent Code Modified. The percentage of the adapted software’s code which is
modified in order to adapt it to the new objectives and environment.
IM: Percent of Integration Required for Modified Software. The percentage of effort
required to integrate the adapted software into an overall product and to test the
resulting product as compared to the normal amount of integration and test effort for
software of comparable size.
If there is no DM or CM (the component is being used unmodified) leave it as 0.
Ayrıca aşağıdaki tabloya göre bir değer belilenmelidir.
Tablo 6 – RUSE değerlendirme
Sayfa 20’de yer alan Documentation match to life-cycle needs (DOCU) Tablo 7’ye göre
hesaplanır.
Sayfa 21’de Product Complexity (CPLX)’ in nasıl toplanması gerektiği açıklanmıştır.
Sayfa 22’de platform cost drivers adı altında üç tane driver sunulmuştur. Nasıl
belirlenecekleri aynı sayfadaki tabloda sunulmuştur. Açıklamaları aşağıdadır.
TIME (Execution Time Constraint) : The rating is expressed in terms of the percentage
of available execution time expected to be used by the system or subsystem consuming
the execution time resource. The rating ranges from nominal, less than 50% of the
execution time resource used, to extra high, 95% of the execution time resource is
consumed.
Main Storage Constraint (STOR) : This rating represents the degree of main storage
constraint imposed on a software system or subsystem. The rating ranges from nominal,
less that 50%, to extra high, 95%.
Platform Volatility (PVOL) : “Platform” is used here to mean the complex of hardware
and software (OS, DBMS, etc.) the software product calls on to perform its tasks. If the
4
software to be developed is an operating system then the platform is the computer
hardware. If a database management system is to be developed then the platform is the
hardware and the operating system. If a network text browser is to be developed then
the platform is the network, computer hardware, the operating system, and the
distributed information repositories. The platform includes any compilers or assemblers
supporting the development of the software system. This rating ranges from low, where
there is a major change every 12 months, to very high, where there is a major change
every two weeks.
Sayfa 23’ te personnel cost drivers altında 6 tane driver vardır. Nasıl değerlendirilecekleri
aynı sayfada yer alan tabloda verilmiştir. Açıklamaları aşağıdadır.
Analyst Capability (ACAP) : The major attributes that should be considered in this
rating are Analysis and Design ability, efficiency and thoroughness, and the ability to
communicate and cooperate. The rating should not consider the level of experience of
the analyst; that is rated with AEXP. Analysts that fall in the 15th percentile are rated
very low and those that fall in the 95th percentile are rated as very high.
Programmer Capability (PCAP) : Evaluation should be based on the capability of the
programmers as a team rather than as individuals. Major factors which should be
considered in the rating are ability, efficiency and thoroughness, and the ability to
communicate and cooperate. The experience of the programmer should not be
considered here; it is rated with AEXP. A very low rated programmer team is in the
15th percentile and a very high rated programmer team is in the 95th percentile.
Applications Experience (AEXP): This rating is dependent on the level of applications
experience of the project team developing the software system or subsystem. The ratings
are defined in terms of the project team’s equivalent level of experience with this type of
application. A very low rating is for application experience of less than 2 months. A very
high rating is for experience of 6 years or more.
Platform Experience (PEXP) : The Post-Architecture model broadens the productivity
influence of PEXP, recognizing the importance of understanding the use of more
powerful platforms, including more graphic user interface, database, networking, and
distributed middleware capabilities.
Language and Tool Experience (LTEX): This is a measure of the level of programming
language and software tool experience of the project team developing the software
system or subsystem. Software development includes the use of tools that perform
requirements and design representation and analysis, configuration management,
document extraction, library management, program style and formatting, consistency
checking, etc. In addition to experience in programming with a specific language the
supporting tool set also effects development time. A low rating given for experience of
less than 2 months. A very high rating is given for experience of 6 or more years.
Personnel Continuity (PCON): The rating scale for PCON is in terms of the project’s
annual personnel turnover: from 3%, very high, to 48%, very low.
Bu değerler için tablodan yararlanılması gerekli ve yeterlidir.
Sayfa 24’te proje ile ilgili factor’ler vardır. Yine aynı sayfada verilen tabloya göre değerler
belirlenmelidir. Bu factor’lerin detaylı tanımları aşağıdadır.
5
Use of Software Tools (TOOL) : Software tools have improved significantly since the
1970’s projects used to calibrate COCOMO. The tool rating ranges from simple edit and
code, very low, to integrated lifecycle management tools, very high.
Multisite Development (SITE) : Given the increasing frequency of multisite
developments, and indications that multisite development effects are significant, the
SITE cost driver has been added in COCOMO II. Determining its cost driver rating
involves the assessment and averaging of two factors: site collocation (from fully
collocated to international distribution) and communication support (from surface mail
and some phone access to full interactive multimedia).
Required Development Schedule (SCED) : This rating measures the schedule
constraint imposed on the project team developing the software. The ratings are defined
in terms of the percentage of schedule stretch-out or acceleration with respect to a
nominal schedule for a project requiring a given amount of effort. Accelerated schedules
tend to produce more effort in the later phases of development because more issues are
left to be determined due to lack of time to resolve them earlier. A schedule compress of
74% is rated very low. A stretch-out of a schedule produces more effort in the earlier
phases of development where there is more time for thorough planning, specification
and validation. A stretch-out of 160% is rated very high.
6