Cocomo II EEE493 2001 References:HvV 7'3'6

1
Cocomo II EEE493 2001ReferencesHvV 7.3.6
Royal Military College of Canada Electrical and
Computer Engineering
Major Ron Smith smith-r_at_rmc.ca 1-613-541-6000
ext. 6030

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Teaching Points

• Why use a software cost and schedule model
• Recall algorithmic models
• COnstructive COst MOdel
• COCOMO II assumptions
• Three increasingly detailed COCOMO II models
• Application Composition
• Early Design
• Post-Architecture

3
Cost and Schedule Models - Why?

• set project budgets and schedules
• basis of planning
• make investment / financial decisions
• tradeoff studies involving
• cost, schedule, function, performance and quality
• support risk management
• deciding which parts of a system to
• develop, reuse, lease or purchase (OTS or
  develop)
• make legacy software system decisions

4
Recall Algorithmic Models

• algorithmic models provide one or more
  mathematical algorithms which produce an estimate
  a a function of a number of variables considered
  to be major cost drivers. ?(x1, x2,... xn)
• Cost Drivers
• lines of source code
• programmer capability
• schedule constraints
• execution time constraints
• etc.

5
The COnstructive COst MOdel

• created by Barry Boehm
• provides cost and schedule estimates for software
  projects
• COCOMO (now COCOMO 81) began circa 1976
• COCOMO II - (also known as COCMO II.2000)
• there was no firm basis for explaining to a
  manager, customer, etc. that a proposal is
  unrealistic
• it was hard to make S/W - H/W trade-offs
• it was difficult to tell if development was
  proceeding I.A.W. plan

6
COCOMO II - Assumptions (1)

• Primary cost driver is DSI - delivered source
  instructions (in KSLOC)
• Cost estimates cover only a defined set of
  activities (e.g. user training is not covered)
• Estimates cover all direct-charged labour (e.g.
  analysts, project-managers, program librarians,
  designers, programmers) but excludes indirect
  labour (e.g. secretaries, janitors,
  higher-management, etc.)
• A COCOMO person-month
• 152 hours
• 19 person-days

7
COCOMO II - Assumptions (2)

• assumes customer and developer enjoy good
  management
• the granularity of the cost estimation model
  needs to be commensurate with the information
  available at the time of estimating, thus ...
• there are three separate models used to cover the
  period from beginning of the requirements
  analysis phase to the end of the integration and
  test phase
• Application Composition
• Early Design
• Post-Architecture

8
Application Composition Model

• intended mainly for prototyping activities
• uses Object Point (OP) counts (not FPs)
• a count of the number and complexity of large
  granularity entities such as screens, reports and
  components
• and factors in code reuse and productivity
• new object points, NOP OP x (100 - reuse) /
  100
• productivity, PROD NOP / person-months
• effort, PM NOP / PROD

9
Early Design Model

• intended mainly for architectural design
  activities
• uses Unadjusted Function Point (UFP) counts
• straight UFPs are converted to DSI
• application adjustment factors are not applied
  until after conversion to SLOC
• effort, PMNS a x Size b x ? EMi (i 1
  to 6)
• where a 2.94 (calibrated from 161 projects)
• b 1.01 0.01 x S SFj (j 1 to 5)
• and EMi - effort multipliers for 6 different
  cost drivers
• SFi - exponential scale factors for 5 cost
  drivers
• NS - implies nominal schedule

10
Post-Architecture Model

• intended for actual development activities
• essentially a modern update to COCOMO 81
• considers a wide range of cost drivers
• new cost drivers include reusability,
  documentation needs, personnel continuity and
  multi-site teams
• effort, PMNS a x Size b x ? EMi (i 1 to
  16)
• where a 2.94 (calibrated from 161 projects)
• b 1.01 0.01 x S SFj (j 1 to 5)
• and EMi - effort multipliers for 16 different
  cost drivers
• SFi - exponential scale factors for 5 cost
  drivers
• NS - implies nominal schedule

11
Development Time

• to determine actual calendar development time
  requires a translation from person-months to
  development time
• a factor for non-nominal schedule is introduced
• schedules can be compressed and stretched (within
  limits of 75 to 160)
• time, TDEV c x (PMNS)d x SCED/100
• where c 3.67
• d 0.28 0.2 x b - 1.01
• and SCED - percentage of required schedule
  compression

12
Scaling Factors

• cause an exponential cost increase

13
Scaling Factors
14
Effort Multipliers (Post-Architecture)

• Product factors

15
Effort Multipliers (Post-Architecture)

• Platform factors

16
Effort Multipliers (Post-Architecture)

• Personnel factors

17
Effort Multipliers (Post-Architecture)

• Project factors

18
Effort Multipliers (Post-Architecture)
every 1 mo.
19
Effort Multipliers (Post-Architecture)
20
Supplemental References

• Boehm, Barry, et al., Software Cost Estimation
  with COCOMO II , Prentice-Hall, 2000. ISBN
  0-13-026692-2.

21
Next ClassCocomo II - Maintenance Reuse