cocomo ii

22
COCOMO II

Upload: yogesh-deshmukh

Post on 27-Nov-2014

117 views

Category:

Documents


0 download

TRANSCRIPT

COCOMO II

REENGINEERING COCOMO I NEEDS

--New software processes--New phenomena: size, reuse --Need for decision making based on

incomplete information

FOCUSED ISSUES

• 1. non-sequential and rapid-development process models• 2. reuse-driven approaches involving commercial-off-the-

shelf (COTS) packages• 3. reengineering [reused, translated code integration]• 4. applications composition• 5. application generation capabilities• 6. object oriented approaches supported by distributed

middleware• 7. software process maturity effects• 8. process-driven quality estimation

DIFFERENCES BETWEEN COCOMO I AND COCOMO II

• COCOMO'81 requires software size in KDSI as an input, but COCOMO II is based on KSLOC (logical code). The major difference between DSI and SLOC is that a single Source Line of Code may be several physical lines. For example, an "if-then-else" statement would be counted as one SLOC, butmight be counted as several DSI.

• COCOMO II addresses the following three phases of the spiral life cycle: Applications development, early design and post architecture.

• COCOMO'81 provides point estimates of effort and schedule, but COCOMO II provides likely ranges of estimates that represent one standard deviation around the most likely estimate.

• COCOMO II adjusts for software reuse and reengineering where automated tools are used for translation of existing software, but COCOMO'81 made little accommodation for these factors

COCOMO II provides three stage series of models for estimation of

software projects• APPLICATION COMPOSITION MODEL• EARLY DESIGN MODEL- Involves exploration of

architectural alternatives or incremental development strategies.

• POST-ARCHITECTURE MODEL: once the project is ready to develop and sustain a fielded system it should have a life-cycle architecture which provides more accurate information on cost driver inputs, and enables more accurate cost estimates.

Changes in cost drivers are:

• Added cost drivers (7): DOCU, RUSE, PVOL, PLEX, LTEX, PCON, SITE

• Deleted cost drivers (5): VIRT, TURN, VEXP, LEXP, MODP

Added cost drivers

Required Reuse (RUSE):• This cost driver accounts for the additional

effort needed to construct components intended for reuse on the current or future projects. This effort is consumed with creating more generic design of software, more elaborate documentation, and more extensive testing to ensure components are ready for use in other applications.

Documentation match to life-cycle needs (DOCU)

• Several software cost models have a cost driver for the level of required documentation. In COCOMO II, the rating scale for the DOCU cost driver is evaluated in terms of the suitability of the project’s documentation to its life-cycle needs. The rating scale goes from Very Low to Very High.

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 software to be developed is an operating system then the platform is the computer hardware.

Personnel Experience (PREX)

• This Early Design cost driver combines the three Post-Architecture cost drivers application experience (AEXP), platform experience (PEXP), and language and tool experience (LTEX).

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.

Personnel Continuity (PCON)

• The rating scale for PCON is in terms of the project’s annual personnel turnover

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.

NOMINAL SCHEDULE ESTIMATION EQUATIONS (NS)

The Early Design and Post-Architecture model use the same approach for product sizing (including reuse) and for scale factors as well as for estimating the amount of effort (PMNS) and calendar time it will take to develop (TDEVNS) a software project.

where A = 2.94 (for COCOMO II.2000)

where B = 0.91 (for COCOMO II.2000)

and C = 3.67 and D = 0.28

Inputs: A = Effort coefficient, E = scale factors (5) which account for relative economies or diseconomies of scale encountered for software projects of different sizes, EM = effort multipliers (n=7 for the Early Designmodel, n=17 for the Post-Architecture model).

THE SCALE FACTORS

• The exponent E in Equation 11 is an aggregation of five scale factors (SF) that account for the relative economies or diseconomies of scale encountered for software projects of different sizes

• If E < 1.0, the project exhibits economies of scale• If E = 1.0, the economies and diseconomies of

scale are in balance. This linear model is often used for cost estimation of small projects.

W(i) Very Low

Low Nominal High Very High

Extra High

Precedentedness 4.05 3.24 2.43 1.62 0.81 0.00

Development Flexibility

6.07 4.86 3.64 2.43 1.21 0.00

Architecture / RiskResolution

4.22 3.38 2.53 1.69 0.84 0.00

Team Cohesion 4.94 3.95 2.97 1.98 0.99 0.00

Process Maturity 4.54 3.64 2.73 1.82 0.91 0.00