Transcript COCOMO II

COCOMO II
資管研一 張永昌
Agenda







Overall Model Definition
COCOMO II Models for the Software Marketplace Sectors
COCOMO II Model Rationale and Elaboration
Development Effort Estimates
Software Economies and Diseconomies of Scale
Previous Approaches
Scaling Drivers







Adjusting Nominal Effort
Development Schedule Estimation
Using COCOMO II




Precedentedness (PREC) and Development Flexibility (FLEX)
Architecture / Risk Resolution (RESL)
Team Cohesion (TEAM)
Process Maturity (PMAT)
Lines of Code
Function Points
Converting Function Points to Lines of Code
Breakage
Overall Model Definition

COCOMO II strategy:




Preserve the openness of the original COCOMO;
Key the structure of COCOMO II to the future
software marketplace sectors described earlier;
Key the inputs and outputs of the COCOMO II
submodels to the level of information available;
Enable the COCOMO II submodels to be
tailored to a project's particular process
strategy.
COCOMO II Models for the
Software Marketplace Sectors

COCOMO II capability for estimation：
Application Generator
 System Integration
 Infrastructure


Two life cycle：
Early Design
 Post-Architecture

COCOMO II Model
Rationale and Elaboration

Three-stage



The earliest phases or spiral cycles will
generally involve prototyping, using the
Application Composition model capabilities.
The next phases or spiral cycles will generally
involve exploration of architectural alternatives
or incremental development strategies.
Once the project is ready to develop and
sustain a fielded system, it should have a lifecycle architecture, which provides more
accurate information on cost driver inputs, and
enables more accurate cost estimates.
Development Effort
Estimates
PMnominal  A  (Size)
B
PM：Person Months（人月）
A：constant
Size：Size of software development
units＝KSLOC（units of thousands of source lines of
code）
B：scale factor
Software Economies and
Diseconomies of Scale
B＜1.0：the project exhibits
economies of scale.
 B＝1.0：the economies and
diseconomies of scale are in balance.
 B＞1.0：the project exhibits
diseconomies of scale.

Previous Approaches

Original COCOMO：




Ada COCOMO：


Embedded（COCOMO） B：1.04~1.24
COCOMO II：





Organic B=1.05
Semidetached B=1.12
Embedded B=1.20
combin：COCOMO and Ada COCOMO
Arcgitecture、Risk（ Ada COCOMO ）
=>RESL
add： Precedentedness (PREC) 、Development
Flexibility (FLEX) 、 Team Cohesion (TEAM)
Scaling Drivers
B  0.91 0.01  wi
Precedentedness (PREC) and
Development Flexibility (FLEX)
Feature
Very Low Nominal
/ High
Extra
High
Precedentedness
Organizational understanding of product
objectives
General
Considerable
Thorough
Experience in working with related
software Systems
Moderate
Considerable
Extensive
Concurrent development of associated
new hardware and operational
procedures
Extensive
Moderate
Some
Need for innovative data processing
architectures, algorithms
Considerable
Some
Minimal
Development Flexibility
Need for software conformance with
preestablished requirements
Full
Considerable
Basic
Need for software conformance with
external interface specifications
Full
Considerable
Basic
Premium on early completion
High
Medium
Low
Architecture / Risk
Resolution (RESL)
Team Cohesion (TEAM)
Process Maturity (PMAT)


organized around：Software Engineering
Institute’s Capability Maturity Model (CMM)
two ways of rating Process Maturity：

CMM Maturity level

Overall Maturity Level







p
p
p
p
p
p
CMM
CMM
CMM
CMM
CMM
CMM
Level
Level
Level
Level
Level
Level
1 (lower half)
1 (upper half)
2
3
4
5
Key Process Areas（KPAs）
KPAs:
  KPA%i 5 
5   
 
18 
 i 1  100
18
Adjusting Nominal Effort

Early Design Model

 7

PMadjusted  PMnominal   EMi 
 i 1

Post-Architecture Model
 17

PMadjusted  PMnominal   EMi 
 i 1

Development Schedule
Estimation

TDEV  3.67  ( PM )
( 0.28  0.2 B 1.01)

SCED %

100
Using COCOMO II
Determining Size
 Lines of Code

Function Points

Counting Procedure for
Unadjusted Function Points
1.Determine function counts by type.
2. Determine complexity-level
function counts.

Apply complexity weights.

Compute Unadjusted Function Points.

Converting Function Points to
Lines of Code
Breakage
額外
BRAK百分比 
原本
20000
ex :
 20%
100000