A Winsor Brown and Ye Yang

1

577a 2007 Tutorial Software Cost Estimation
Tools COCOMO II and COCOTS

• A Winsor Brown and Ye Yang
• Center for Systems and Software Engineering
• University of Southern California
• AWBrown, YangY_at_sunset.usc.edu

2
Prepare Your Machine

• Copy COCOMO II folder to the DesktopMy Computer
  / LabApps / Programs / COCOMO_IIThe same
  contents as the CD from the book.
• Download COCOMO_II_2000.3 from Class
  WebsiteCSSE.USC.edu gtgt Courses gtgt Current gtgt
  CSCI 577orhttp//greenbay.usc.edu/csci577/fall20
  07/site/tools

3
CS577abc Course/Project Characteristics

• Learn by Doing
• Real Projects for Real Clients
• Teaches Software Engineering of Large systems
  using small e-services/tools projects
• 577A most projects through preliminary LCA
• 577B ½ as many projectsConstruction,
  Transition
• 577C in some of yours USC lifetimes
  Maintenance and (Agile?) Enhancement
• Teaches Software Engineering of Large systems
  using small e-services/tools projects

4
Part I COCOMO II Model and Demo
Download COCOMO II.2000.3 from the class Tools
Website Quietly, in parallel with next few
slides,Copy folder COCOMO II to the desktop
Start the Help Click on Help.htmlStart COCOMO
II.2000.3 Estimate a project with 2,000 lines of
code
5
Software Cost Estimation Methods

• Cost estimation prediction of both the
  person-effort and elapsed time of a project
• Methods
• Algorithmic
• Expert judgement
• Estimation by analogy
• Parkinsonian
• Best approach is a combination of (at least two)
  methods
• compare and iterate estimates, reconcile
  differences
• COCOMO is the most widely used, thoroughly
  documented and calibrated cost model

• Price-to-win
• Top-down
• Bottom-up
• Parametric

6
COCOMO Background

• COCOMO - the COnstructive COst MOdel
• COCOMO II is the update to COCOMO 1981
• Results from ongoing research with new data
  collection model calibration(SFs more data
  points new ratings values Bayesian calibration)
• Originally developed by Dr. Barry Boehm and
  published in 1981 book Software Engineering
  Economics
• COCOMO II described in new book Software Cost
  Estimation with COCOMO II
• COCOMO II can be used as a framework for cost
  estimation and related activities

7
RUP/ICM Anchor Points Enable Concurrent
Engineering
8
COCOMO Black Box Model
product size estimate
development, maintenance cost and schedule
estimates
product, process, platform, and personnel
attributes
COCOMO II
reuse, maintenance, and increment parameters
cost, schedule distribution by phase and
activity(for Elaboration and Construction!)
organizational project data
local recalibration to organizational data
9
COCOMO Sub-models

• Applications Composition involves rapid
  development or prototyping efforts to resolve
  potential high-risk issues such as user
  interfaces, software/system interaction,
  performance, or technology maturity. Its sized
  with application points (weighted screen
  elements, reports and 3GL modules).
• The Early Design model involves exploration of
  alternative software/system architectures and
  concepts of operation using function points and a
  course-grained set of 7 cost drivers.
• The Post-Architecture model involves the actual
  development and maintenance of a software product
  using source instructions and / or function
  points for sizing, with modifiers for reuse and
  software breakage a set of 17 multiplicative
  cost drivers and a set of 5 factors determining
  the project's scaling exponent.

10
COCOMO Effort Formulation
Quietly Estimate a project with 2,000 lines of
codeusing COCOMOII_2000.3
11
1st Run of COCOMO II

• Edit / Add Module Or Click on
• Set Size Click on
• Select SLOC Method
• Enter SLOC

12
1st Run of COCOMO II (cont.)
13
Coverage of Different Processes

• COCOMO II provides a framework for tailoring the
  model to any desired process
• Original COCOMO was predicated on the waterfall
  process
• single-pass, sequential progression of
  requirements, design, code, test
• Modern processes are concurrent, iterative,
  incremental, and cyclic
• e.g. Rational Unified Process (RUP), the USC
  Model-Based Architecting and Software Engineering
  (MBASE) process
• Effort and schedule are distributed among
  different phases and activities per work
  breakdown structure of chosen process

14
MBASE Phase Distributions

• see COCOMO II book for complete phase/activity
  distributions

Schedule
Effort
Phase
12.5
6
Inception
37.5
24
Elaboration
62.5
76
Construction
12.5
12
Transition
100
100
COCOMO Total
125
118
Project Total
15
RUP/ICM Anchor Points Enable Concurrent
Engineering
16
COPSEMO Distributes Effort Schedule
17
Part I COCOMO II Model and Demo

• Quietly, in parallel with next few slides,copy
  folder with Software Estimation to the
  desktop Download COCOMO II.2000.3 from the
  class Tools Website Start the HelpStart COCOMO
  II.2000.3 A realistic estimate of a project
  with 2,000 lines of code Add REVL!

18
2nd Run COCOMO II

• Set REVL to 15 (a good first guess)

19
Cost Factors

• Significant factors of development cost
• scale drivers are sources of exponential effort
  variation
• cost drivers are sources of linear effort
  variation
• product, platform, personnel and project
  attributes
• effort multipliers associated with cost driver
  ratings
• Defined to be as objective as possible
• Each factor is rated between very low and very
  high per rating guidelines
• relevant effort multipliers adjust the cost up or
  down

20
Scale Drivers

• Precedentedness (PREC)
• Degree to which system is new and past experience
  applies
• Development Flexibility (FLEX)
• Need to conform with specified requirements
• Architecture/Risk Resolution (RESL)
• Degree of design thoroughness and risk
  elimination
• Team Cohesion (TEAM)
• Need to synchronize stakeholders and minimize
  conflict
• Process Maturity (PMAT)
• SEI CMM process maturity rating

21
Scale Factors

• Sum scale factors SFi across all of the factors
  to determine a scale exponent, B, using B .91
  .01 S SFi

22
Cost Drivers

• Product Factors
• Reliability (RELY)
• Data (DATA)
• Complexity (CPLX)
• Reusability (RUSE)
• Documentation (DOCU)
• Platform Factors
• Time constraint (TIME)
• Storage constraint (STOR)
• Platform volatility (PVOL)

• Personnel factors
• Analyst capability (ACAP)
• Program capability (PCAP)
• Applications experience (APEX)
• Platform experience (PLEX)
• Language and tool experience (LTEX)
• Personnel continuity (PCON)
• Project Factors
• Software tools (TOOL)
• Multisite development (SITE)
• Required schedule (SCED)

23
Example Cost Driver - Required Software
Reliability (RELY)

• Measures the extent to which the software must
  perform its intended function over a period of
  time.
• Ask what is the effect of a software failure?

24
Significant CSCI577A Scale Factors

• PREC
• RESL

25
Significant CSCI577A Effort Multipliers
26
Significant CSCI577A Effort Multipliers
27
3rd Run COCOMO II

• Set PREC to Low
• Set RESL to High

28
3rd Run COCOMO II (cont.)

• Set RELY to 50 of Low to Nominal
• Set DATA to Low
• Set DOCU to High
• Set PCON to Very Low

29
3rd Run COCOMO II (cont.)
30
Reused and Modified Software

• Effort for adapted software (reused or modified)
  is not the same as for new software.
• Approach convert adapted software into
  equivalent size of new software.

31
Nonlinear Reuse Effects

• The reuse cost function does not go through the
  origin due to a cost of about 5 for assessing,
  selecting, and assimilating the reusable
  component.
• Small modifications generate disproportionately
  large costs primarily due the cost of
  understanding the software to be modified, and
  the relative cost of interface checking.

32
COCOMO Reuse Model

• A nonlinear estimation model to convert adapted
  (reused or modified) software into equivalent
  size of new software

33
COCOMO Reuse Model (contd)

• ASLOC - Adapted Source Lines of Code
• ESLOC - Equivalent Source Lines of Code
• AAF - Adaptation Adjustment Factor
• 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.
• 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.
• AA - Assessment and Assimilation effort needed to
  determine whether a fully-reused software module
  is appropriate to the application, and to
  integrate its description into the overall
  product description. See table.
• SU - Software Understanding. Effort increment as
  a percentage. Only used when code is modified
  (zero when DM0 and CM0). See table.
• UNFM - Unfamiliarity. The programmer's relative
  unfamiliarity with the software which is applied
  multiplicatively to the software understanding
  effort increment (0-1).

34
Sizing - Lines of Code

• Source Lines of Code (SLOCs) logical source
  statements
• Logical source statements data declarations
  executable statements
• Executable statements cause runtime actions
• Declaration statements are non-executable
  statements that affect an assembler's or
  compiler's interpretation of other program
  elements
• CodeCount tool available on CSSE website

35
USC COCOMO II Exercise

• Re-do COCOMO II Estimation
• Size 3300 Total SLOC in two modules
• Re-Use 1,500 SLOC from Open Source Library
• DM, CM 0 IM 50
• Unfm.80
• 1,800 new SLOC
• SFs as appropriate based on earlier
  discussionPREC to LowRESL to High
• EAFs as appropriate based on earlier
  discussionRELY to 50 Low to NomDATA to
  LowDOCU to HighPCON to Very Low

36
4th Run COCOMO II
37
4th Run COCOMO II (cont.)
38
Size Estimation

• By analogy with Wide-Band Delphi before LCO
• Ask each team member what they think the size
  might be
• Apply personal experience,
• Look at completed projects,
• Guess (WAG),
• SWAG based on modules known to date
• Collect and share in a meeting discuss why/how
  different people made their estimate
• Repeat
• When stable, Size (H 4 X Ave. L)/6

39
Size Estimation

• By analogy with Wide-Band Delphi after LCO
• Measure Size of Prototype Code (CodeCount, or
  other tools)
• Measure Size of Reused Code (CodeCount, or other
  tools)
• Ask each team member what they think the final
  size might be
• Extrapolate from prototype (apply personal
  experience)
• Guess (WAG),
• SWAG based on modules known to date
• Collect and share in a meeting discuss why/how
  different people made their estimate
• Repeat
• When stable, Size (H 4 X Ave. L)/6

40
Size Estimation

• By analogy with Wide-Band Delphi before LCA Draft
• Measure Size of final Prototype Code provide
  along with original prototype code measure
• Measure Size of Reused Code (CodeCount, or other
  tools)
• Ask each team member what they think the final
  size might be
• Extrapolate from prototypes (apply personal
  experience?)
• Guess (WAG),
• SWAG based on modules known to date
• Collect and share in a meeting discuss why/how
  different people made their estimate
• Repeat
• When stable, Size (H 4 X Ave. L)/6

41
COCOMO II Estimates in 577A

• Before LCO (for ARB)
• After LCO ARB (for grading)
• Before LCA (for ARB)
• After LCA ARB (for grading and plan for 577B)

42
Part II COCOTS Model and Demo
43
Relationship between CII and COCOTS
44
COCOTS

• COCOTS is the acronym for the Constructive COTS
  integration cost estimation model
• A member of the USC COCOMO II family of cost
  estimation models
• For estimating the expected initial cost of
  integrating COTS software into a new software
  system development
• Three sub-models
• COTS Assessment
• COTS Tailoring
• COTS Glue code development

45
COTS Assessment Sub-model

• COTS Assessment the activity of determining the
  appropriateness or feasibility of using specific
  COTS products to fulfill required system
  functions.

46
COTS Tailoring Sub-model

• COTS Tailoring the activity associated with
  setting or defining shell parameters or
  configuration options available for a COTS
  product, but which do not require modification of
  COTS source code, including defining I/O report
  formats, screens, etc.

47
COTS Glue Code Sub-model

• COTS glue code/integration refers to software
  developed in-house and composed of
• 1) code needed to facilitate data or information
  exchange between the COTS and the system or other
  COTS
• 2) code needed to connect the COTS into the
  system or other COTS but does not necessarily
  enable data exchange
• 3) code needed to provide required functionality
  missing in the COTS AND which depends upon or
  must interact with the COTS.

48
COTS Glue Code Sub-model Formula
49
Total COCOTS Estimation

• Sum of three sub-models estimates
• EffortCOT EffortA EffortT EffortGC
• Grand total effort for developing a COTS-Based
  System (CBS)
• EffortCBS EffortCOC EffortCOT

50
Questions and Answers

• Questions from you?
• Question from HHGG the great question of Life,
  The Universe and Everything.
• Answer 42! (1010102)