Lab 2

COCOMO Software Cost Estimating Model

CPCS-353 Software Engineering Practices Lab 2

Statement Purpose

This lab provides students with the knowledge and skills to use COCOMO II tool. This lab takes students step-
by-step through the features of tool and implements the concepts of COCOMO model.

Activity Outcomes

In this lab, students will learn about Microsoft Project:

— COCOMO Model
— Using COCOMO II tool
— SLOC
— Function Points
— Adaptation and Reuse

Instructor Note

Read the exercises below and submit your answer in the answer sheet available in the end in individual format.
English will be the official language in throughout the discussion.

All assignments are to be your own work unless directed otherwise by the instructor.

2
CPCS-353 Software Engineering Practices Lab 2

Lab 2 – COCOMO Software Cost Estimating Model

2.1. Overview of COCOMO

COCOMO (Constructive Cost Model) is a model that allows software project managers to estimate project
cost and duration. It was developed initially (COCOMO 81) by Barry Boehm in the early eighties2). The
COCOMO II1) model is a COCOMO 81 update to address software development practices in the 1990's and
2000's. The most fundamental calculation in the COCOMO model is the use of the Effort Equation to
estimate the number of Person-Months required for developing a project. Most of the other COCOMO
results, including the estimates for Requirements and Maintenance, are derived from this quantity.

2.2. Source Lines of Code

The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC).
SLOC is defined such that:

 Only Source lines that are DELIVERED as part of the product are included -- test drivers and other
support software is excluded

 SOURCE lines are created by the project staff -- code created by applications generators is
excluded

 One SLOC is one logical line of code

 Declarations are counted as SLOC

 Comments are not counted as SLOC

The original COCOMO 81 model was defined in terms of Delivered Source Instructions, which are very
similar to SLOC. 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, but might
be counted as several DSI.

2.3. The Scale Drivers

In the COCOMO II model, some of the most important factors contributing to a project's duration and cost
are the Scale Drivers. You set each Scale Driver to describe your project; these Scale Drivers determine the
exponent used in the Effort Equation.

The 5 Scale Drivers are:

1. Precedentedness

3
CPCS-353 Software Engineering Practices Lab 2

2. Development Flexibility

3. Architecture / Risk Resolution

4. Team Cohesion

5. Process Maturity

Note that the Scale Drivers have replaced the Development Mode of COCOMO 81. The first two Scale
Drivers, Precedentedness and Development Flexibility actually describe much the same influences that the
original Development Mode did.

2.4. Cost Drivers

COCOMO II has 17 cost drivers ï‫ ½؟‬you assess your project, development environment, and team to set
each cost driver. The cost drivers are multiplicative factors that determine the effort required to complete
your software project. For example, if your project will develop software that controls an airplane's flight,
you would set the Required Software Reliability (RELY) cost driver to Very High. That rating corresponds to
an effort multiplier of 1.26, meaning that your project will require 26% more effort than a typical software
project.
Table 1 - Cost Driver codes

Code Cost Driver

Personnel Factors
ACAP Analyst Capability
APEX Applications Experience
AEXP
PCAP Programmer Capability
LEXP Programming Language Experience
VEXP Virtual Machine Experience
PERS Personnel Capability
PREX Personnel Experience
PCON Personnel Continuity
PLEX Platform Experience
PEXP
LTEX Language and Tool Experience
Product Factors
RELY Required Software Reliability
DATA Database Size
CPLX Software Product Complexity
RUSE Required Reusability
DOCU Documentation Match to Life-Cycle Needs
RCPX Product Reliability and Complexity
Platform Factors
TIME Execution Time Constraint

4
CPCS-353 Software Engineering Practices Lab 2

STOR Main Storage Constraint

TURN Computer Turnaround Time
VIRT Virtual Machine Volatility
VMVH Virtual Machine Volatility: Host
VMVT Virtual Machine Volatility: Target
PVOL Platform Volatility
PDIF Platform Difficulty
PLAT Platform
Project Factors
TOOL Use of Software Tools
MODP Modern Programming Practices
SCED Required Development Schedule
SECU Classified Security Application
SITE Multisite Development
FCIL Facilities
RVOL Requirements Volatility

COCOMO II defines each of the cost drivers, and the Effort Multiplier associated with each rating. Check the
Costar help for details about the definitions and how to set the cost drivers.

2.5. Using COCOMO II tool

Download and install COCOMO II from
http://csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/CII2000.exe

COCOMO II screen looks like upon starting a new Project. Note you start out in the Post Architecture model.

5
CPCS-353 Software Engineering Practices Lab 2

To add a Module, choose Edit  Add Module, a new line shows up in the screen with a default module name
<sample>. Change the module name to whatever you want.

6
CPCS-353 Software Engineering Practices Lab 2

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.

Set values for your program language, for example

 JAVA (this is really important to know for Function Points)

 there is an estimated 20,000 lines of code
 30% of the code will be discarded due to requirements evolution and volatility (REVL)

Click OK

7
CPCS-353 Software Engineering Practices Lab 2

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 26,000 (30% added for REVL).

8
CPCS-353 Software Engineering Practices Lab 2

Now add another module (Module2) and choose Function Points from dialog box, it will change as shown
below:

9
CPCS-353 Software Engineering Practices Lab 2

This is the default screen for Function Points. Let’s look deeper at the Function type description in below table.

Function type Description

External Input (Inputs) Count each unique user data or user control input type that (i) enters the
external boundary of the software system being measured and (ii) adds or
changes data in a logical internal file.
External Output (Outputs) Count each unique user data or control output type that leaves the external
boundary of the software system being measured.
Internal Logical File (Files) Count each major logical group of user data or control 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 Files passed or shared between software systems should be counted as
(Interfaces) external interface file types within each system.
External Inquiry (Queries) Count each unique input-output combination, where an input causes and
generates an immediate output, as an external inquiry type.

Now enter number of function points in the grid as shown below:

10
CPCS-353 Software Engineering Practices Lab 2

Now change Language to “JAVA” and observe the changes.

11
CPCS-353 Software Engineering Practices Lab 2

You can check the effect on Multiplier by selecting different languages.

Change REVL to 30% and click OK.

12
CPCS-353 Software Engineering Practices Lab 2

So how did the 17,156 (or even the 13,197) get calc’d?

Click on Parameters  Function Points, you will see the following screen:

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 Multiplier.

13
CPCS-353 Software Engineering Practices Lab 2

So now let’s add a new module (Module3) and use Adaptation and Reuse from dialog box, it will shown below:

14
CPCS-353 Software Engineering Practices Lab 2

15
CPCS-353 Software Engineering Practices Lab 2

16
CPCS-353 Software Engineering Practices Lab 2

17
CPCS-353 Software Engineering Practices Lab 2

18