CSSE 372 Software Project

Management:
Software Estimation
With COCOMO-II
Shawn Bohner
Office: Moench Room F212
Phone: (812) 877-8685
Email: [email protected]
Estimation
Experience
and Beware of
the Sales
Guy…

Yikes!
Cost Estimation
n  Project scope must be explicitly defined
n  Task, functional, or component
decomposition is necessary
n  Historical measures
(metrics) are very helpful
n  To assure fit, use two or
more estimation techniques
n  Uncertainty is inherent in most estimation
endeavors – plan on it!
 Learning Outcomes: Estimation

Estimate software project

effort, cost, and schedule
for an intermediate size
project.
n  Outline the COCOMO-II
parametric model as an
example
n  Examine the key factors
and adjustments
n  Walk through getting
started…
Constructive Cost Model (COCOMO)
n  Empirical model based on project experience

n  Well-documented, independent model,

Independent of a specific software vendor

n  Long history – initially published in 1981

(COCOMO-81) and last in 1999 (COCOMO-II)

n  COCOMO-II takes into account different

approaches to software development, reuse,
etc.
Accommodating Progression
Three-level model that allows increasingly
detailed estimates to be prepared as
development progresses
n  Early prototyping level
¨  Based on “object points”
¨  Simple formula

n  Early design level

¨  Basedon “function points” that are then
translated to lines of source code (LOC)
n  Post-architecture level
¨  Estimates based on LOC
Q1
Early Prototyping Level

n  Supports prototyping projects and

projects where there is extensive reuse

n  Estimates effort in object points/staff month

n  PM = ( NOP × (1 - %reuse/100 ) ) / PROD,

where:
¨  PMis the effort in person-months
¨  NOP is the number of object points
¨  PROD is the productivity

Q2
Early Design Level
n  Estimates made after requirements confirmed

!PM = A × SizeB × M + π
n
! I=1
EMi
where:
n  A = 2.5 in initial calibration
n  Size in KLOC
n  B varies from 1.1 to 1.24 depending on novelty of
project, development flexibility, risk management
approaches, and process maturity
n  EM = (ASLOC × (AT / 100) ) / ATPROD
n  M = PERS × RCPX × RUSE × PDIF × PREX × FCIL ×
SCED
Q3
Multipliers
Multipliers reflect capability of developers, non-
functional requirements, familiarity with
development platform, etc.

RCPX - product reliability and complexity

RUSE - the reuse required
PDIF - platform difficulty
PREX - personnel experience
PERS - personnel capability
SCED - required schedule
FCIL - the team support facilities
Post-Architecture Level

n  Uses same formula

as early design estimates

n  Estimate of size adjusted to account for:

¨  Requirements volatility
¨  Rework required to support change
¨  Extent of possible reuse

Q4
Post-Architecture Level (continued)

ESLOC = ASLOC x (AA + SU +0.4DM + 0.3CM + 0.3IM) / 100

n  ESLOC is equivalent number of lines of new code
n  ASLOC is the adjusted number of lines of reusable
code which must be modified
n  DM is the % of design modified
n  CM is the % of the code that is modified
n  IM is the % of the original integration effort required for
integrating the reused software
n  SU is a factor based on the cost of software
understanding
n  AA is a factor which reflects the initial assessment
costs of deciding if software may be reused
 Exponent Scale Factors

Scale factor Explanation

Precedentedness Reflects the previous experience of the organization with this type
of project. Very low means no previous experience, Extra high
means that the organization is completely familiar with this
application domain.
Development flexibility Reflects the degree of flexibility in the development process. Very
low means a prescribed process is used; Extra high means that the
client only sets general goals.
Architecture/risk Reflects the extent of risk analysis carried out. Very low means
resolution little analysis, Extra high means a complete a thorough risk
analysis.
Team cohesion Reflects how well the development team know each other and work
together. Very low means very difficult interactions, Extra high
means an integrated and effective team with no communication
problems.
Process maturity Reflects the process maturity of the organization. The computation
of this value depends on the CMM Maturity Questionnaire but an
estimate can be achieved by subtracting the CMM process maturity
level from 5.

Q5
Project Product attributes
RELY Required system DATA Size of database used
Cost CPLX
reliability
Complexity of system RUSE Required percentage of
Drivers DOCU
modules
Extent of documentation
reusable components

required
Computer attributes
TIME Execution time STOR Memory constraints
constraints
PVOL Volatility of
development platform
Personnel attributes
ACAP Capability of project PCAP Programmer capability
analysts
PCON Personnel continuity AEXP Analyst experience in project
domain
PEXP Programmer experience LTEX Language and tool experience
in project domain
Project attributes
TOOL Use of software tools SITE Extent of multi-site working
and quality of site
communications
SCED Development schedule
compression
Q6
What the Cocomo II screen looks like upon starting a new
Project.
Note you start out in the Post Architecture model, and there
is no Application Composition model available.
Enter a Project Name
Can’t really do much unless we add a Module,
so choose Edit à Add Module. A new line shows
up in the screen with a default module name.
1. Change the 2. Now double click on
module name the yellow rectangle
to whatever under Module Size…
you want.
This screen will pop up allowing us to choose
between Source Lines Of Code (SLOC),
Function Points, or Adaptation and Re-Use.
Let’s stick with SLOC for this module.
The program language is C++ (this is really
important to know for Function Points), there is
an estimated 10,000 lines of code, and 20% of
the code will be discarded due to requirements
evolution and volatility.
Hit OK…
The main screen is updated with the SLOC and
programming language as well as some calculated values
we will decipher later. Note that the SLOC is 12,000. Why? J
{Pertinent portion of calculation on next slide in red boxes}
Now add another module and choose Function Points.
COCOMO-II Calculations: Effort
Equation for Post Architecture Model
This is the
default screen
for Function
Points.

Let’s look
deeper at the
Function Type
descriptions…
External Input Count each unique user data or user control input type that (i)
(Inputs)
enters the external boundary of the software system being
measured and (ii) adds or changes data in a logical internal file.

External Output Count each unique user data or control output type that leaves
(Outputs)
the external boundary of the software system being measured.

Internal Logical File Count each major logical group of user data or control
(Files)
information in the software system as a logical internal file
type. Include each logical file (e.g., each logical group of data)
that is generated, used, or maintained by the software system.

External Interface Files passed or shared between software systems should be

Files (Interfaces)
counted as external interface file types within each system.

External Inquiry Count each unique input-output combination, where an input

(Queries)
causes and generates an immediate output, as an external
inquiry type.

From Cocomo II User Manual via software

So let’s go back
into this screen
and add some
entries in the grid.

Notice, there are

some kind of
subtotals per line,
but the Equivalent
SLOC = 0.

Let’s change the

Language and
see what
happens.
By changing the
language to C++,
we now have an
Equivalent Total in
SLOC.

Also, we can see a

value next to the
Change Multiplier
button.

Let’s change the

language to
Machine Code! J
Quite a
difference
jumping from
10,653 SLOC to
128,640 SLOC.

Note the
multiplier
changed from 53
to 640.

Change the
language once
more to 5th
Generation.
So using a 5th
generation level
language would cut
our code base by a
factor of 285 times
according to
COCOMO II’s default
estimation (not
calibrated for your
environment, not
taking into account
other factors).

Change the language

to C++ and change
REVL to 20%…
So now Module2 has F:12783 or, in other words, it’s
based on Function points (the F:) and it has an
equivalent 12,783 lines of code (10,653 + 20% for
volatility).
So how did the 12,783 (or even the 10,653) get calc’d?
Part 1 of the answer is to click on Parameters à
Function Points. You will see the following screen… Q7
These are the default values used as weighting factors
against the entries you put in. So if you entered 2,3,4
when enter in Function Point information for the first
row, the end result would be 2*7 + 3*10 + 4*15. This is
then multiplied by The Change Multiplier…
Triangulation on Size

Estimation Method
Estimate

Results Choose
Estimation
Methods

Each Estimation Method has

strengths and weaknesses Define
Environmental
need to offset. Parameters

Estimation Estimation
Method 1 (M1) Method 2 (M2)

Note: Estimates within

20% are acceptable in
the early phases of a
project
< +
- 20% +
M1 - M2 > - 20%

Continue Investigate discrepancies

Estimation between the 2 estimates.
Process
Homework and Reading Reminders
n  Read Paper for Thursday’s Case Study

n  Complete Homework 3 – Software Estimate

Using COCOMO-II or Costar
¨  Due by 5pm, Tuesday, September 25th, 2012