COCOMO 2.0 Cost Estimation Questionnaire - CSSEcsse.usc.edu/csse/event/1996/ARR/8 COCOMO...

COCOMO 2.0 Cost Estimation Questionnaire

1. Introduction

The Center for Software Engineering at the University of Southern California is conducting research to update the software development cost estimation model called COCOMO'. The project name is COCOMO 2.0 and is led by Dr. Barry W. Boehm.

A fundamental requirement for such research is real-world software development project data. This data will be used to test hypotheses and verify the model's postulations. In return the model will be open and made available to the public. The contribution of your data will ensure the final model is useful.

The data that is contributed is important to us. We will safeguard your contribution so as not to compromise company proprietary infomation. The next section discusses the data management aspects of the project. T h e f ~ l l o ~ i g ~ s e c t i o n is the data co~leaion form. The last section i s an explanation of expected values inthe data collection form.

Some Affiliates have an active collection program and the data from past projects is available for the COCOMO 2.0 data collection effort. This questionnaire can be used to extract relevant COCOMO 2.0 data.

This questio~aire attempts to address two different levels of data granularity: project level and component level. The project level of granularity is data that is applicable for the whole project. Thls includes things llke application type and development activity being reported. Component level data are things like size. cost, and component cost dnvers. If the data being submitted is on a project that has multiple components then fill out the project data once, and the component data for each of the identdable component. If the data being submitted for the whole project fill out the form once.

COCOMO 2.0 Points of Contact

For questions on USC COCOMO soha re , the COCOMO 2.0 Model. data definitions, or project data collect~on and management, contact:

. . . . . . . . . . . . Chris Abts or Brad Clark or Sunita Devnani (21 3) 740-6470 Karen Prouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (2 13) 740-5703

- - . . . . , . . Dr,Barry Boehrn. . -. . -. . , . . , . .-. . ,. . ,. . :. . . ., ., (2 13) 740-8 163 - - - - - - - - - -

. . . . . . . . . . . . . . . . . . . . . Center for Software Engineering FAX (213) 740-4927

Internet Electronic-Mail . . . . . . . . . . . . . . . . . . . . [email protected]

COCOMO 20 Data Submission Address: COCOMO 2.0 Data Submission Center for Sofnvare Engineering Department of Computer Science Salvatori 330 University of Southern California 941 W. 37th Place Los Angeles, CA. 90089-078 1

Copyright University of Southern California - Version 1.4

n i s page Iej intentionally biank.


Pmjecf Level Infotmatjon

2. Project Level Information

General Information . . Affiliate. Each separate software project contributing data will have a separate file

identlfication number of the form XXX. XXX will be one of a m d o m set of three-digit organization identification numbers, provided by USC Center for Software Engineering to the Affiliate.

Proiect Maldimm Numbs . . . The project identrfication is a three digit number assigned by the organization. Only the Aaliate knows the co~respondence between YYY and the actual project. The same project identlfication must be used with each data submission.

Date. Th~s is the date the data elements were collected for submission. - - - - -

- - - - - - - - - - - - - - - - - - -

~ o n TVDC. Tlus field captures a broad description of the type of activity this software application is attempting to perform.

Command and Control, MIS, Simulation, Communication, Operating Systems, Sofrware Dev. Tools, Diagnostics, Process Control, Testing, Engineering and Science, Signal processing, Utilities.

Other:

Activity. This field captures the phase of develc~pment that the project is in. For one-time reponing the activity is 'completed'. It is assumed that data for completed projects includes data from s o h a r e requirements through integration 1 test. Please report the correct phasing if t h~s is not the case.

Circle One; Requirements, Design, Code, Unit Test, InteptionTest, Maintenance, Completed

- - - - - - - - - - -

Other:

Qeve10~)ent TmeA Is the development a new software product or an upgrade of an existing product?

2.7 D e v e m Procey. This is a description of the software process used to control the software development.

- - - -- -- -

2.8 Deve-t Process Iteratiu. If the process is iterative, e.g. spiral, which iteration is h s ?

Pruject Level Infomation

2.9 COCOMO Model. This specifies whch COCOMO 2.0 model is being used in this data submission. If this is a "historical" data submission, select the Post-Architecture model or the Applications Composition model.

Application Composition: This model involves prototyping efforts to resolve potential high risk issues such as user interfaces, software/system interaction, performance, or technology maturity.

Early Design: Tbis model involves exploration of alternative software/system architectures and concepts of operations. At this stage of development, not enough is known to support he-grain cost estimation.

Post-Architecture: This model involves the actual development and maintenance of a software product. This stage of development proceeds most cost-effectively if a software lifecycle architecture has been developed; validated with respect to the system's mission, concept of operation, and risk; and established as the framework for the product.

Qrcle Qne; Application Composition, Early Design, Post- Architecture

Schedule

2.10 of deve-. For reporring of historical data, please provide the year in which the software development was completed. For periodic reporting put the year of this submission or leave blank.

2.11 ScheduleMonths. For reporting of historical data, provide the number of calendar months from the time the development began through the time it completed (from the beginning of Software Preliminary Design through the end of System Test and Integration). For periodic reporting, provide the number of months in this development activity.

Circle the life-cycle phases that the schedule covers:

System Prellmlnary Code and Requirements Design Unit Test Maintenance

I%ttwpre I Detail& I I Integration

Requirements Design and Test

Software Requirements. This phase defines the complete, validated specification of the required functions, interfaces, and performances for the software product.

Preliminary Design. This phase defines the complete, verified specification of the overall hardwarel software architecture, control smcture, and data structure for the producc along with such necessary components as draft user's manuals and test plans.

Detailed Design. This phase defines a complete, verified specification of the control structure, data structure, interface relations, sizing, key algorithms, and assumptions of each program component.

Code & Unit Test. This phase produces a complete and verified set of program components.

SIW System Integration & Test. This phase produces a properly functioning software product composed of the software components.

Maintenance. This phase produces a fully functioning update of the hardwarelsoftware system.


Project Exponential Cost Drivers

Development Flexi- bility

Architecture 1 risk resolution'

Team cohesion

Very Low

thoroughly unprecedented

rigorous

very difficult interactions interactions

largely unprcce- dented

occasional relax- ation

largely farml~ar throughly farnlhar - Very High

some (40%) oftm (60%) generally (75%)

somewhat unprecedented

some relaxatioln

some I general goals conformity I

Extra High

generally familiar

general conformity

highly I seamless wperative interactions I

- - - - -

% sigmficant module interfaces specified,% significant risks eliminated.

Enter the rating level for the first four cost drivers by circling one of the tick marks.

2.12 P r e c e m TPRFC]. 1f.the product is similar to several that have been developed before then the precedentedness is hgh.

2.13 Pevelo~ment Flexibiliw ffLEX). This cost driver captures the amount of constraints the product has to meet. The more flexible the requirements, schedules, interfaces, etc., the hgher the rating. See the User's Manual for more details.

2.14 Archlt ecture 1 Risk Resolution IRESL). a s cost driver captures the thoroughness of definition and freedom from risk of the software archtecture .used for the product. See the User's Manual for more details.

VL L N H VH XH

2.15 '&am Cohesipn (TFAM). The Team Cohesion cost driver accounts for the sources of project turbulence and extra effon due to difficulties in synchronizing the project's stakeholders: users, customers, developers, maintainers, interfacers, others. See the User's Manual for more details.


Project Level lnfonnation -- - - - -

2.16 Process -. The procedure for determining PMAT is organued around the S o h a r e Engineering Institute's Capability Manuity Model (CMM). The tune period for reponing process maturity is at the time the project was underway. We are interested in the capabilities practiced at the project level more than the overall organization's capabdities.

There are three ways of responding to this question: EhpPse only a. "Key Process Area Evaluation*' requires a response for each Key Process Area W A ) . We have provided enough information for you to self- evaluate the project's enactment of a KPA (we hope will you will take the time to complete this section). "Overall Maturity Level" is a response that captures the result of an organized evaluation based on the Ch4M. "No Response" means you do not know or will not reporr the process maturity either at the Capability Maturity Model or Key Process Area level.

0 NoResponse

Overall Maturity Level

0 CMM Level 1 (lower half)

0 CIKM Level 1 (upper half) 0 CIKM Level 2

0 CIKM Level 3

0 CMM Level 4

0 CMM Level 5

Basis of estimate:

0 Software Process Assessment (SPA)

0 Software Capability Evaluation (SCE) 0 Interim Process Assessment ( P A )

0 Other:

Key Process Area Evaluation

Enough information is provided in the following table so that you can assess the degee to whlch a KPA was exercised on the project. Each KPA is briefly described and its goals are given. The response catagories are explained below:

ost Alwavs (over 90% ofthe time) when the goals are consistently achieved and are well established in standard operating procedures. Freau- (about 60 to 90% of the time) when the goals are achieved relatively often, but sometimes are omined under difficult circumstances. About (about 40 to 60% of the time) when the goals are achieved about half of the time.

. cc- (about 10 to 40% of the time) when the goals arc sometimes achieved, but less often.

. If F v a (less than 10% of the time) when the goals are rarely if ever achieved.

Does N o t when you have the required knowledge about your project or organization and the KPA, but you feel the KPA does not apply to your circumstances (e.g. Subcontract Management). Don't Know when you are uncertain about how to respond for the KPA.


Key Process Area I Goals of each KPA

~Rcauirewnts Manaccmnt mvolvcs ~ah l i sh ing and mamhining an j Sydcm rcquircmcn~ allocated to d l w a r c arc controlled to cdahlish a 1 agreement with the customer on the requirements for the kdlwarc 1 hascline for sonware cnginccring and management use.

I Loiect. I 1 Sonware plans, products, and activitics are kept consistent with the sys- . - I

I I tcm rcquircmcnts allncatcd to software.

SpDware PI&[ Planninn;establishes reasonable plans f ~ r performing I Sonwarc cstimatcs arc documental for u a in planning and tracking the (the sonware engineering activities and for managing the pnwarc I sonware projcct .

Sonware project activities and commitments are planned and dwu- project.

I

mcntcd. Affected goups and individuals agrce to their commitmnts rdlated to the

I sonware proicct. I I

provides adcqpte visibility into actual progrcss so that managcmnt can lake comcctivc actions I Actual results and pcrformanccs are tracked against thc sonware plans.

Corrcctivc actions are takcn and managed to closurc when actual rcsults

I . -

when the sonware project's perf&mcc dcvia~cs signifilcantly from and performance deviate significantly from the sonware plans the sonware plans.

I I Changes to sonware commitments are agreed to by the af ictcd groups I I I ( and individuals.

tracking and reviewing the subcontractor's performanwand rcsults.

I 1

mitments to each (her. I

The prime contractor and the sonware suhcontractor maintaiv ongoing communicatims. The prime contractor tracks the soflware suhcontraclnr's actual rcsults

l and perrormancc against its cnmmitmenls. I

Sonware Oualitv Assurance: provides management with appropriate I Sonware quality assurance acliviticsire planned. I

visibility into the process heing used by h e sonware prdject and orthe products being huilt . I

Adherence o f sonware products and activities to the applicahlc standards. procedures, and rcquircments is vcri ficd objectively. AlTectcd p u p s and individuals arc informed o f sonware quilily assurance activitics and results. Noncompliance issues that cannot he resolved within the snflware project

integrity o f the products o f the sonware project througHout the projcct's sonware life cycle.

arc a d d r c s . hy senior management. I

Sonware configuration management activities are planned. 1

Selected sonwarc work products arc identified. contrnllcd, a(rd availahlc. Changes to identified sonware work products arc ccintroll~d.~ Af5ccted groups and individuals arc informed of thc status and content of

I . .

estahlishcs the organ&ational rcspnnsihil- Software prcxcss dcvchrpnrnt and improvcmcnt activitics arc ccnrdi- ily for sonwarc process activities that improve the organi7ation1s over- I natcd across the organization. I

I all sonware process capability. I ( The strengths and wcaknesscs o f thc sonware prnccsws used are idcnti- ficd relative to a prnccsc standard. I

Organization-lcvcl process dcvclnpment and improvcmcnt dctivitics are planned. I

Key Process Area Goals of each KPA

. . )rean~;rat~on Procns Ikfinition: develops and mainlains a usahlc set ,f sonware process assets that improve process performance acrms the ~ojects and provides a basis lor cumulative, long- term bcnclits to thc vnani7alion. w-

b in inn P roa rm develops he skills and knowledge 01 ind~viduals so -- - -

hey can perform their roles effectively and efficiently.

- - S a

P C - 1 I

- I I

I

I - I

I

I - 1 I

I

I

! I

I

. I

lcmslicnlly identilying, cvalualing. and implemenling improvcmcnls to the organizalinn's standard sonware process and thc projects' dcfincd sonware pwesscs on a conlinunus basis.

ware M- integrales Ihe sonwarc cnginccring and management aclivitics inlo a cohercn~, dclincd sonware process ha1 is tailorcd from the organiiration's standard sollwarc proccss and .elated process assets.

. . . integrates all the sonware enginccrlng

activi~ics to producc and support comcl, consis~enl snnwarc products . .

e f i t i ve ly and cfficicntly

k r ~ r o u o Coordinatio~ eslablishes r mcans lor the sonwarc engineering group lo parlicipale aclively wilh the other engineering groups so the project is better ahle lo satisfy ~ h c customer's needs cffcctivcly and ck icn l ly .

peer Review; removes defects from the sonware work products carly a n d elTiciently.

. . m ~ l o t l v c P r w wntrols lhc process performance of the sonware project quantilatively.

involvcs &fining quality goals lor Ihe sonware products, cslahlishing plans to achieve ~hesc goals. and mnni- toring and adjusting Ihc sonware plans. sonwarc work producls, acllv- itics, and quality goals lo satisfy the weds and desires ollhc cuslnmer and end u w r

k k c l Prevcn~iox analyzcs defects that wcrc cncoun~crcd in h c pas1 snd lakcs spccific actions to prevent the occurrence of t h m lypes 01 defocts in the future.

involves idcntifymg, selcc~lng. and - ~ - . .

evaluating new ~echnologics. and incorpra~ing ef ic l ive tcchnologics into Ihe organizelion.

boccss C h w Manaecrnenc involves defining process improvcmcnt &MIS and, with senior management sponsorship. proactivcly and sys-

r\ standard sonware proccss for the organ17ation IS dcvclopcd and main- aincd. Information rclatcd to the use of the organi7stion's standard sonware pro. :es. hv ~ h c sonware ~roiccts is cnllec~cd. rcvicwed. and made available.

Training activitics arc planncd. rraining lor developing the skills and knowledgc needed lo perform sonwarc managerncnl and technical roles is providcd. Individuals in the sonware engineering group and sonware-relatcd groups rcccivc ~ h c trainina necessary lo wrlorm lhcir roles.

The project's defined software proccs. is a tailored version o f lhc organi- lation's standard sonware prwcss. The projccl is planncd and managed according to the projcct's defined snnwarc process.

Thc sonware engineering tasks arc dcfined, integrated, and consislcntly prformed lo produce thc sonware. Sonware work nrnducls arc kcnl consistent wilh each other - - .

Thc cuslomcr's rcqulrcmnts arc agreed to hy all affeclcd groups The comrnitrncn~s hctwecn the enginccrlng groups are agrccd lo hy the srfcctcd groups. The cnnlncerlnn arouns idenlifv. track. and resolve inlernrnuv hues

Pccr review activitics arc planned. Dcfcc~s in the sonware work products are identified and remvcd.

Ihc quanlitalivc process monagclncnt aclivilics arc planned. The proccss performance ofthc project's defined sonwarc process is controlled quantilalivcly. The process capahilily olthe organization's s~andard sonware proccss is known in quanlitalivc terms.

Thc projccl's sonwarc qualily management aclivilics arc planncd. Mcasurahlc goals lor sonware prnducl quality and their prioritics are dcfincd. Actual progress loward achieving the quality goals lor the sonware products is quantilicd and managcd.

I)clcct prcvcnlion acl~v~lics arc planncd. Common causes ofdclccts arc sought o u ~ and idcntilicd. C o r n m causes of dclccts arc prioritized and systematically eliminated.

Incorpnralion o f Icchnology changes arc planncd. New lcchnologics arc cvalualcd lo delerminc their cffcc~ on qualily and prnduct~vily. Apprnprialc new Icchnolopics arc transferred into normal procticc across the organi7alion.

('ontinuo~~s process imprnvemenl is planncd. Particip~ion in thc organilalion's sonware proccs irnprovcmcnl activi- lics is organizallon wdc. Thc organi7alion's s~andard .wnwarc proccss and the prnjccls' defincd snnwarc prnccsscs arc impmvcd c~~nlinuously.

0

I Prviect Level Infomation I

2.17 Defect Prevention and Detection Methods I

I What methods are used to prevent and detect defects? The infoxmation in the following table is Project Level information.

I Total: Rigorous use, 100% of the time

I General: Ample use, 80% of the time. I Moderate: Basic use,60% of the time. I

' Some: Panial use, 40% of the time. I

Linle or None: Sketchy use, less than 20% of the time. I

- - - - - - - - - - - - - - -

Software Architecture

Detailed Design

Software Requirements

DctailcdDaign- - - - - - - - - -

Code

Rotoryping

Automared design aids

Code static analyzer

Unit testing

:overage testing

Inteption testing

Copyright University of Southern California - Version 1.4 I

Project Level Information

Method

Smss tening

Synem testing

Acceptance testing

Regression tcning

Alpha - teaing

Beta - testing

Cleanroom

lndcpendent Verification & Validation

Other (specify):

Copyright Universrty of Sou?hern California - Version 1.4

Component Level Information

3. Component Level Information

If the whole project is being reported as a single component then skip to the next section.

If the data being submitted is for multiple componentr; that comprise a single project then it is necessary to idenufy each component with its project Please fill our this section for each component and attach all of the component sections to the project sections describing the overall project data.

. . 3.1 Affiliate Iden- Each separate software project conmbuting data will have a separate file

identification number of the form MCX. XXX will be one of a random set of three-digit organization identfication numbers, provided by USC Center for Software Enpeering to the Affiliate.

3.2 Proiect Id- . . . The project identfication is a three digit number assigned by the

- organization. OnlytheAfKliatehows &e correspondence betyeen WY - and - the actual project. The same - - - - - - -

project identification must be used with each data submission.

. . . 3.3 -at~on (Jf. This is a unique sequential letter that identifies a s o h a r e

module that is part of a project.

Cost

3.4 w o n (Person M a . For one-time reporting, provide the effon in Person Months associated with development and test of the software component described, including its share of such common activities as system design and integration. For periodic reponing, provide the effort in Person Months since the project began.

- - - - - - - - - - - - - -

Circle the life-cycle phases that the effon estimate covers:

System Prellminary Code and Requirements Design Unit Test Maintenance

I I I ~ f t w a r e I I -tall& I I I

integration Requirements Desl~gn and Test

3.5 fI9m I P e u . Indicate the average number of hours per person month experienced by your organization.

Copyright Universityof Southern-California --Version - - - 1.4 Page 1 1 - -


3.6 Labor. Indicate the percentage of labor for different categories,e.g. Managers, S N Requirement Analysts, Designers, CMIQA Personnel, Programmers, Testers, and Interfacers for each phase of software development:

Requirements(Rqts). This phase defines the complete, validated specification of the required functions, interfaces, and performances for the software product.

Preliminary Design (PD). This phase defines the complete, verified specification of the overall hardwarel software architecture, control structure, and data structure for the product, along with such necessary components as draft user's manuals and test plans.

Detailed Design (DD). This phase defines a complete, verified specification of the control saucnue, data structure, interface relations, sizing, key algorithms, and assumptions of each program component.

Code & Unit Test (CUT). This phase produces a complete and verified set of program components.

S N System Integration & Test (IT). This phase produces a properly functioning software product composed of the software components.

Maintenance (M). This phase produces a hllly functioning update of the hardwarelsoftware system.

Copyright University of Southern California - Version 1.4 Pag s 12


Size 7 l e project would like to collect size in object points, logical lines of code, and unadjusted function points. Please submit all size measures that are available, e.g. if you have a component in lines of code and unadjusted function points then submit both numbers.

3.7 Percentaee of Code Wre-. This is an estimate of how much the requirements have changed over the lifetime of the project. It is the percentage of code thrown away due to requirements volatility. For example, a project whch delivers 100,000 instructions but discards the equivalent of an additional 20,000 instnctions would have a breakage of value of 20. See the User's Manual for more detail.

3.8 m. If the COCOMO 2.0 Applications Programming model was used then enter the object point count.

3.9 Yew Uniaue SLOC. This is the number of new source lines of code (SLOC) generated.

3.10 S $ . When reporting size in source lines of code, please indicate if the count was for logical SLOC orphysical SLOC. If both are available, please submit both types of counts. If neither type of count applies to the way the code was counted, please describe the method. An extensive deh t ion for logical source lines of code is given in an Appendix in the Model User's Manual.

circle One; Logical SLOC Physical SLOC (carriage returns) Physical SLOC (semicolons) Non-CommentedlNon-Blank SLOC

3.1 1 Unadiusted Function Points. If you are using the Early Design or Post-Architecture model, provide the total Unadjusted Function Points for each type. An Unadjusted Function Point is the product of the function point count and the weight for that type of point. Function Points are discussed in the User's Manual.


Component LeveE Information

Sofiware -ce P m . For software maintenance, use items 4.8 - 4.12 to describe the size of the base sofiware product, and use the same units to describe the following parameters:

v. If you are using the Early Design or Post-kchitecture model, enter the language name that was used in this component, e.g. Ada, C, C++, COBOL, FORTR4.N and the amount of usage if more than one language was used.

a. Amount of software added:

Lrnguage Used

b. Amount of software modified:

Percentage Used

c. Amount of software deleted:

Obiect PQ~U Reused. If you are using the Ap:plication Composition model, enter the number of oblect reused. Do not fill in the fields on DM, CM, I'M, SU, or AA.

3.15 &OC Adapted. If you are using the Early Dlesign or Post-Architecture model enter the amounts for the SLOC adapted.

3.16 ASbOC Count T m . When reporting size in source lines of code, please indicate if the count was for logical ASLOC or physical ASLOC. If both are available, please submit both types of counts. If neither type of count applies to the way the code was counted, please describe the method. An extensive d e h t i o n for logical source lines of code is given in an Appendix in the Model User's Manual.

Sircle One; Logical ASLOC Physical ASLOC (camage returns) Physical ASLOC (semicolons:~ Non-Commentemon-Blank ASLOC

Other:

3.17 Modified - DM. The percentage of design modified.

3.18 Code W e d - CM. The percentage of code modified.


I Component Level Information I I I

I I 3.19 Test - N. The percentage of the (adapted software's original integration and test effon 1 I expended. 1 I I

I 3.20 Software U-.

Clarity

Self-Descriptiveness

SU Increment to ESLOC I--

I 1

Very low cohesion. I Moderately low ( Rcvonably well-

I I

No match between p m 1 Some comlation I Moderate concla-

high coupling, spa- ghmi &.

gram and application between program tion between pro- iandapplica~ion. world views. - grama and

application.

Obscure code; docu- Some code corn- Moderate level of mentation missing. rncnwy and head- code commentary, obscure or obsolete en; some useful headers, documenta-

docummtation. tions.

cohesion, high cow piing.

mucrured; some wwk areas.

coupling. information hiding in &ta 1 control

world-views.

- -

High HI@ cohes~on. low

Good code com- I Selfdescriptive

tion upto-date,

Very High Srrong rnodulanty.

I Table 1: Rating Scale for Sofovare Understanding Increment SU I I The So@aw Understanding increment (SU) is obtained from Table 1. SU is expressed quantitatively as a

I percentage. If the software is rated very high on structure, applications clarity, and self-descriptiveness, the

I software understanding and interface checking penalty is 10%. If the software is rated very low on these 1 factors, the penalty is 50%. SU is determined by t i h g the subjective average of the three categories. Enter 1

I the percentage. I I I

1 1

I I 3.21 Assessment and m t l o n - AA. . . .

I

AA Increment Level of AA Effort

Basic module search and doc~lmentatlon

Some module Ten and Evaluation (TLE), documentation

The other nonlinear reuse increment deals with the degree of Assessment and Assimilation (AA) needed to determine whether a fully-reused software module is appropriate to the application, and to integrate its description into the overall product description. Table 2 provides the rating scale and values for the assessment and assimilation increment. Enter the percentage of AA:

I

6

8

The amount of effon required to modify existing software is a h c t i o n not only of the amount of modlficarion (AAF) and understandability of the existing software (SU), but also of the programmer's relative unfamiliarity with the software (UNFM). The UNFM parameter is applied multiplicatively to the

I 1 Copyright University of Southern California - Version1 1.4 1

I Table 2: Rating Scale for Assessment and Assimilation Increment (AA) I

Considerable module TBE, docurnentarion

Extensive module T&E, documentation I

Component Level Infomafion

I

1 0.0 I Comdetelv familiar 1

I 1 .O I Com~letely unfamiliar I

0.2 0.4 0.6 0.8

Table 3: Rating Scale for Progrimmer Unfamiliarity (UNFM)

Mostly familiar Somewhat familiar Considerably familiar Mostly unfamiliar

software understanding effort increment. If the programmer works with the software every day, the 0.0 multiplier for UNFM will add no software understanding increment. If the progmmmer has never seen the software before, the 1.0 multiplier will add the full software understanding effort increment. The rating of UNFM is in Table 3. Enter the Level of Unfamiliarity.

-- -



Post-Architecture Cost Drivers.

Use this section for completed projects. These arc the 17 effon multipliers used in COCOMO 2.0 Post- Architecture model to adjust the nominal effort, Person Months, to reflect the software product under development. They are grouped into four categories: product, platform, personnel, and project. When an evaluation is in-between two rating levels always round to Nominal.

Product Cost Drivers

For maintenance projects, identify any differences between the base code and modified code Product Cost Drivers (e.g. complexity).

Very Low I Low I Nominal I High slight inconve- 1 low. easily recov- I moderate, eastly 1 high financial loss nimce 1 erable losses 1 recoverable l o ~ x s I

I , I I Many hfe-cycle 1 Some I~fe-qcle I kght-sued to I~fe- I Excesstve for hfe-

DBbylesPgm SLOC < 10

none

needs unco&d needs unco&d. cycle needs I I I cycle needs

I

across product line I across multiple

IOsD/P<100

across project product lines

for life-cycle needs

1006D/P~1OOO

across pro-

Software -LY) . . . . This is the measure of the extent to which the software must perform its intended fimction over a pmod of time.

Base S i 7 ~ ( D m . This measure attempts to capture the affect large data requirements have on product development. The rating is determined by calculating DR.

VL L N H VH XH I I I I I I I I I I I I I I I I I I I

I

Emuired R e W ( R U S F 1 . . . This cost driver accounts for the additional effon needed to construct

components intended for reuse on the current or future projects.

to life-cv- IDOCQ. This capnues the suitability of the project's documentation to its life-cycle needs. See the User's Manual.


Component Level lnfonation

Very Low I Smght-line code with a few non-nmed structured prognun- ming operators: Ws. CASES. IFTHENELSEs. Simple module composition via procedure calls or simole scrims.

I

Low I Smightforward nesting of SUUcturCd programming O F -

tors. Mostly simple predicates

I

Uominal Mostly simple nesting. Some intennodule control. Decision ubles. Simple callbacks or message passing, including middleware-supported dimib- uted processing

4igh Highly nested mucrured programming operaton with many compound predicates. Queue and stack control. Homoge- neous. distributed processing. Single processor sofi real-time control.

Jery High Reentrant and recursive coding. Fixed-priority interrupt handling. Task synchronization, complex callbacks, heteroge- neous distributed processing.

Sxoa High

Single-processor hard real- tune control.

Multiple resource scheduling with dynarmcally changing pri- orities. Microcode-level con- uol. Dismbuted hard real-time control.

Evaluation of simple I Simple read. write state- expressions: e.g.. mrs wirh simple for- A = B + C g 0 mats.

I

Evaluation of modeme- I No cognizance needed - level expressions: e.g.. of particular processor D=SQR T(P.2- or WO device character- 4. *A *C) istics. 110 done at GEf/

PUT level.

operations. cessing.

I

Basic numerical analy- I Operations at physical 11 sis: multinriate inter- 6level @hyskai stor- polation, ordinary age addms mnslatlons; differential equations. seeks. reads, etc.). Opti- Basic nuncation, round- mized 110 overlap. off concerns.

I Difficult but mcrured I Routlnes for inremot numerical analysis: near-singular manix equations, partial differ- cntial equations. Sim- ple parallelization.

Difficult and unmuc- wed numerical analysis: highly accurate analysis of noisy, sto- chastic data. Complex ~araklization.

diaposis, servicing, masking. Communica- tion line handling. Per- formance-intensive embedded systems.

dent coding, micro-pro- grammed operations. Perfomrance-critical embedded systems.

Data Managelmot Opcrrtlons

Simple arrays in main memory. Simple COTS- DB queries. updates.

Single file subwing with no data structure changes, no edits, no intermediate files. Mod- erately complex COTS- DB queries. updates.

Multi-file input and single file ourput. Simple mucrural changes, simple edits. Complex COTS-DB qumes. updates.

Simple niggen aai- vatcd by data stream contents. Complex data remucturing.

Disuibuted database coordination. Complex mggers. Search optimi- zation.

Highly coupled, dynamic relational and object srmcrures. Natu- ral language data management.

User Interface Mnnrgement Operations

Simple input forms, repon gen- mtors.

Use of simple graphic wr interface (GUI) build- ers.

Simple w of widget set.

Widget set development and exten- sion. Simple voice 1/0, multimedia.

Moderately complex 2D13D. dynamic graphics. multunedia.

Complex multimedia, vlnual reality.

Complexity is divided into five ateas: control operations. computational operations, device-dependent operations, data management operations, and user interface management operations. Select the area or combination of areas that characterize the product or a subsystem of the product. The complexity rating is the subjective weighted average of these areas. The Post-Arch model only used one value for all 5 areas but for data collection purposes we are collecting the rating of each of the areas.



Platform Cost Drivers.

The platform refers to the target-machine complex of hardware and infrastrucnw software.

3.28 p. This is a measure of the execution time constraint imposed upon a sofrware system.

TIME

SfOR

PVOL

3.29 Storage Cons- (STOR). Thls rating represents the degree of main storage constraint imposed on a sofnvare system or subsystem. See the User's Manual.

3.30 Platforzn Volatllitv (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.

Very Low


Low

major change every 12 rno.; minor change every 1 mo.

Nomlaal 5 500h use of avaiUde exccu- tion time

s 500h use of available storage

major: 6 mo.; minor 2 wk.

High

70%

700/0

major: 2 mo.; minor: 1 wk.

Very High

85%

85%

major: 2 wk.; minor: 2 days

Extra Eiigh

95%

95%


Personnel Cost Driven.

I I Very Low 1 Low I Nominal I u g h ( Very Hlgh 1 Extra HIgh I I t ACAP I 15th ~ercentile I 35th percentile I 55th percentile I 75th percentile I 901h percentile 1 1

PC AP

PCON

3.31 U v s t C ~ N (m . . . Analysts are personnel that work on requirements, high level design and detailed design. See the User's Manual.

AEXP

PEXP LTEX

3.32 Prommmer Cab . .

abil~tv (PCAP). Evaluation should be based on the capability of the programmers as a team rather than as individuls. Major factors which should be considered in the rating are ability, efficiency and thoroughness, and the ability to communicate and cooperate. See the User's Manual.

VL L N H VH XH

15th percentile

48% / ycar

3.33 -om E v m (AFXP) . . . Thls raring is dependent on the level of applications experience of the

project team developing the sofrware system or subsystem:The ratings are defined in terms of the project team's equivalent level of experience with h s type of application. See the User's Manual.

S 2 months

S 2 months

S 2 months

3.34 Platform. The Post-Architecture model broadens the productivity ~nfluence of PEXP. recognizing the importance of understanding the use of more powerful platforms, including more graphc user interface, database, networlung. and distributed middleware capabilities. See the User's Manual.

35th percentile

24% /year

3.35 sand This is a measure of the level of pr0gmnm.q language and software tool experieuce of the project team developing the software system or subsystem. See the User's Manual.

6 months

6 months

6 months

3.36 P e r s o n n e l f P C O N . . . The rating scale for PCON is in t e r n of the project's annual personnel

m o v e r .

55th percentile

12% /year


1 ytu

1 year

i year

75th percentile

6% / year

90th percentile

3% / year

3 years

3 years

3 years

6 Y- 6 year

6 year

Component Level Infomation

Project Cost Drivers.

T ~ I S table gives a summary of the criteria used to s8elect a rating level for project cost dnvers.

I grated

TOOL

Very Law Low Nominal High edit, code, debug simple, frontend, basic lifecycle strong, marure

hckmd CASE. tools. miodmely lifecycle tools, link inupt ion mteptcd moderately inte-

t I I , . , . SITE. 1 Some phone, mail I Indiv~dual phone. I Narrowband email I W~dcband elcc-

SITE: Collocation

International

- - - - - - - - - - - - - - - - -

3.37 b e of Sofnuare Tools (TOOL). See the User's :Manual.

Commun icat ions

SCED

proactive lifecy- clc tools, well intepted with processes, meth-

comlex

FAX R O ~ ~ C comrnuni-

75% of normnal 859'0

1

Wideband elect. I lnteractlvc rnul-

3.38 w l t e De - . .

velonmwt (SITE). Given the increasing frequency of multisite developments. and indications that multisite development effects are signficant, the SITE cost driver has been added in COCOMO 2.0. Determining its cost dnver rating involves the assessment and averaging of two factors: site collocation (from fully collocated to international distribution) and communication suppon (from surface mail and some phone access to full interactive multimedia). See the User's Manual.

3.39 w e d Development Schedule (SCED). This rating measures the schedule constraint imposed on the project team developing the sofware. The ratings are defined in terns of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for a project requiring a given amount of effon. See the User's Manual.

University of Southern -- ----

California ---

Version - - -

- - -


fiis page lefi intentionally blank.


COCOMO 2.0 Cost Estimation Questionnaire - CSSEcsse.usc.edu/csse/event/1996/ARR/8 COCOMO...

Documents

Transcript of COCOMO 2.0 Cost Estimation Questionnaire - CSSEcsse.usc.edu/csse/event/1996/ARR/8 COCOMO...