Program : B.

Tech
Subject Name: Software Engineering
Subject Code: IT-604
Semester: 6th
Downloaded from www.rgpvnotes.in

Software Metrics
A software metric is a measure of software characteristics which are measurable or countable. Software
metrics are valuable for many reasons, including measuring software performance, planning work items,
measuring productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software metrics are
similar to the four functions of management: Planning, Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of the software product. The two
important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the software development process.
For example, the efficiency of fault detection. They are used to measure the characteristics of methods,
techniques, and tools that are used for developing software.

Types of Metrics
Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC) measure.
External metrics: External metrics are the metrics used for measuring properties that are viewed to be of
greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For
example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to check the project's progress.
Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as

Page no: 1 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

a base of new software. Note that as the project proceeds, the project manager will check its progress from
time-to-time and will compare the effort, cost, and time with the original effort, cost and time. Also understand
that these metrics are used to decrease the development costs, time efforts and risks. The project quality can
also be improved. As quality improves, the number of errors and time, as well as cost required, is also reduced.
Advantage of Software Metrics
Comparative study of various design methodology of software systems.
For analysis, comparison, and critical study of different programming language concerning their
characteristics.
In comparing and evaluating the capabilities and productivity of people involved in software development.
In the preparation of software quality specifications.
In the verification of compliance of software systems requirements and specifications.
In making inference about the effort to be put in the design and development of the software systems.
In getting an idea about the complexity of the code.
In taking decisions regarding further division of a complex module is to be done or not.
In guiding resource manager for their proper utilization.
In comparison and making design tradeoffs between software development and maintenance cost.
In providing feedback to software managers about the progress and quality during various phases of the
software development life cycle.
In the allocation of testing resources for testing the code.
Disadvantage of Software Metrics
The application of software metrics is not always easy, and in some cases, it is difficult and costly.
The verification and justification of software metrics are based on historical/empirical data whose validity is
difficult to verify.
These are useful for managing software products but not for evaluating the performance of the technical staff.
The definition and derivation of Software metrics are usually based on assuming which are not standardized
and may depend upon tools available and working environment.
Most of the predictive models rely on estimates of certain variables which are often not known precisely.

Size Oriented Metrics

LOC Metrics
It is one of the earliest and simpler metrics for calculating the size of the computer program. It is generally
used in calculating and comparing the productivity of programmers. These metrics are derived by normalizing
the quality and productivity measures by considering the size of the product as a metric.
Following are the points regarding LOC measures:
1. In size-oriented metrics, LOC is considered to be the normalization value.
2. It is an older method that was developed when FORTRAN and COBOL programming were very
popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-based)
programming. As already explained, Graphical User Interfaces (GUIs) use forms basically. LOC
metric is not applicable here.
9. It requires that all organizations must use the same method for counting LOC. This is so because some
organizations use only executable statements, some useful comments, and some do not. Thus, the
standard needs to be established.
10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:
1. Errors/KLOC.
2. $/ KLOC.

Page no: 2 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

3. Defects/KLOC.
4. Pages of documentation/KLOC.
5. Errors/PM.
6. Productivity = KLOC/PM (effort is measured in person-months).
7. $/ Page of documentation.

Advantages of LOC
1. Simple to measure

Disadvantage of LOC
1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of functionality or
complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further modified
by the International Function Point Users Group (IFPUG). FPA is used to make estimate of the software
project, including its testing in terms of functionality or function size of the software product. However,
functional point analysis may be used for the test estimation of the product. The functional size of the product
is measured in terms of the function point, which is a standard of measurement to measure the software
application.

Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the software
application functional size to the client, customer, and the stakeholder on their request. Further, it is used to
measure the software project development along with its maintenance, consistently throughout the project
irrespective of the tools and the technologies.
Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions used in the applications.
Various functions used in an application can be put under five types, as shown in Table:

Types of FP Attributes
Measurements Parameters Examples
1.Number of External Inputs (EI) Input screen and tables
2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.
All these parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

Page no: 3 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

1. FP characterizes the complexity of the software system and hence can be used to depict the project time
and the manpower requirement.
2. The effort required to develop the project depends on what the software does.
3. FP is programming language independent.
4. FP method is used for data processing systems, business systems like information systems.
5. The five parameters mentioned above are also known as information domain characteristics.
6. All the parameters mentioned above are assigned some weights that have been experimentally determined
and are shown in Table
Weights of 5-FP Attributes
Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each function, and the
values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.

Page no: 4 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Here that weighing factor will be simple, average, or complex for a measurement parameter type.
The Function Point (FP) is thus calculated with the following formula.

FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF

where Count-total is obtained from the above Table.

CAF = [0.65 + 0.01 *∑(fi)]

and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i
ranges from 1 to 14). Usually, a student is provided with the value of ∑(fi)
Also note that ∑(fi) ranges from 0 to 70, i.e.,
0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
1. When ∑(fi) = 0 then CAF = 0.65
2. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:

1. Errors/FP
2. $/FP.
3. Defects/FP
4. Pages of documentation/FP
5. Errors/PM.
6. Productivity = FP/PM (effort is measured in person-months).
7. $/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This process is
known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System (MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a
subsystem are further adjusted by considering some more General System Characteristics (GSCs). It is a set
of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:

1. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a particular
GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5.

Page no: 5 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

2. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
3. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula:
VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because
1. When TDI = 0, VAF = 0.65
2. When TDI = 70, VAF = 1.35
3. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution:
Measurement Parameter Count Weighing factor

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 184

3. Number of external inquiries (EQ) 8 * 6 = 48

4. Number of internal files (ILF) 4 * 10 = 40

5. Number of external interfaces (EIF) Count-total → 2 * 5 = 10

378

So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94

Differentiate between FP and LOC

Page no: 6 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

Extended Function Point (EFP) Metrics

FP metric has been further extended to compute:
1. Feature points.
2. 3D function points.
Feature Points
1. Feature point is the superset of function point measure that can be applied to systems and engineering
software applications.
2. The feature points are used in those applications in which the algorithmic complexity is high like real-
time systems where time constraints are there, embedded systems, etc.
3. Feature points are computed by counting the information domain values and are weighed by only
single weight.
4. Feature point includes another measurement parameter-ALGORITHM.
5. The table for the computation of feature point is as follows:
Feature Point Calculations
Measurement Parameter Count Weighing factor
1. Number of external inputs (EI) - *4 -
2. Number of external outputs (EO) - *5 -
3. Number of external inquiries (EQ) - *4 -
4. Number of internal files (ILF) - *7 -
5. Number of external interfaces (EIF) - *7 -
6.Algorithms used Count total → - *3 -
The feature point is thus calculated with the following formula:
FP = Count-total * [0.65 + 0.01 *∑(fi)]
= Count-total * CAF
where count-total is obtained from the above table.
CAF = [0.65 + 0.01 * ∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/factor-CAF (where i
ranges from 1 to 14). Usually, a student is provided with the value of ∑(fi) .
6. Function point and feature point both represent systems functionality only.
7. For real-time applications that are very complex, the feature point is between 20 and 35% higher than the
count determined using function point above.
3D function points
Three dimensions may be used to represent 3D function points?data dimension, functional dimension, and
control dimension.
2. The data dimension is evaluated as FPs are calculated. Herein, counts are made for inputs, outputs,
inquiries, external interfaces, and files.
3. The functional dimension adds another feature-Transformation, that is, the sequence of steps which
transforms input to output.
4. The control dimension that adds another feature-Transition that is defined as the total number of
transitions between states. A state represents some externally observable mode

Page no: 7 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Now fi for average case = 3. So sum of all fi (i ←1 to 14) = 14 * 3 = 42

FP = Count-total * [0.65 + 0.01 *∑(fi ) ]
= 618 * [0.65 + 0.01 * 42]
= 618 * [0.65 + 0.42]
= 618 * 1.07 = 661.26
and feature point = (32 *4 + 60 * 5 + 24 * 4 + 80 +14) * 1.07 + {12 * 15 *1.07}
= 853.86
Example: Compute the 3D-function point value for an embedded system with the following characteristics:
1. Internal data structures = 6
2. External data structures = 3
3. No. of user inputs = 12
4. No. of user outputs = 60
5. No. of user inquiries = 9
6. No. of external interfaces = 3
7. Transformations = 36
8. Transitions = 24
Assume complexity of the above counts is high.
Solution: We draw the Table first. For embedded systems, the weighting factor is complex and complexity is
high. So,

Page no: 8 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Halstead's Software Metrics

According to Halstead's "A computer program is an implementation of an algorithm considered to be a
collection of tokens which can be classified as either operators or operand."

Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be classified as
either operators or operands. All software science metrics can be defined in terms of these basic symbols.
These symbols are called as a token.

The basic measures are

n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.

Halstead metrics are:

Program Volume (V)
The unit of measurement of volume is the standard unit for size "bits." It is the actual size of a program if a
uniform binary encoding for the vocabulary is used.
V=N*log2n

Program Level (L)

The value of L ranges between zero and one, with L=1 representing a program written at the highest possible
level (i.e., with minimum size).
L=V*/V

Program Difficulty
The difficulty level or error-proneness (D) of the program is proportional to the number of the unique operator
in the program.
D= (n1/2) * (N2/n2)

Page no: 9 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Programming Effort (E)

The unit of measurement of E is elementary mental discriminations.
E=V/L=D*V

Estimated Program Length

According to Halstead, The first Hypothesis of software science is that the length of a well-structured program
is a function only of the number of unique operators and operands.
N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to estimate program length:
 NJ = log2 (n1!) + log2 (n2!)
 NB = n1 * log2n2 + n2 * log2n1
 NC = n1 * sqrt(n1) + n2 * sqrt(n2)
 NS = (n * log2n) / 2

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most short program in which a problem
can be coded.
V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters

Size of Vocabulary (n)

The size of the vocabulary of a program, which consists of the number of unique tokens used to build a
program, is defined as:
n=n1+n2
where
n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands

Language Level - Shows the algorithm implementation program language level. The same algorithm
demands additional effort if it is written in a low-level program language. For example, it is easier to program
in Pascal than in Assembler.
L' = V / D / D
2
lambda = L * V* = L * V

Language levels
Language Language level λ Variance σ
PL/1 1.53 0.92
ALGOL 1.21 0.74
FORTRAN 1.14 0.81
CDC Assembly 0.88 0.42
PASCAL 2.54 -
APL 2.42 -
C 0.857 0.445

Page no: 10 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Counting rules for C language

1. Comments are not considered.
2. The identifier and function declarations are not considered
3. All the variables and constants are considered operands.
4. Global variables used in different modules of the same program are counted as multiple occurrences
of the same variable.
5. Local variables with the same name in different functions are counted as unique operands.
6. Functions calls are considered as operators.
7. All looping statements e.g., do {...} while ( ), while ( ) {...}, for ( ) {...}, all control statements e.g., if
( ) {...}, if ( ) {...} else {...}, etc. are considered as operators.
8. In control construct switch ( ) {case:...}, switch as well as all the case statements are considered as
operators.
9. The reserve words like return, default, continue, break, sizeof, etc., are considered as operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator, and the label is counted as an operand.
12. The unary and binary occurrence of "+" and "-" are dealt with separately. Similarly "*" (multiplication
operator) are dealt separately.
13. In the array variables such as "array-name [index]" "array-name" and "index" are considered as
operands and [ ] is considered an operator.
14. In the structure variables such as "struct-name, member-name" or "struct-name -> member-name,"
struct-name, member-name are considered as operands and '.', '->' are taken as operators. Some names
of member elements in different structure variables are counted as unique operands.
15. All the hash directive is ignored.

Example: Consider the sorting program as shown in fig: List out the operators and operands and also calculate
the value of software science measure like n, N, V, E, λ ,etc.

Solution: The list of operators and operands is given in the table

Operators Occurrences Operands Occurrences

int 4 SORT 1
() 5 x 7
, 4 n 3
[] 7 i 8
if 2 j 7
< 2 save 3
; 11 im1 3
for 2 2 2
= 6 1 3
- 1 0 1
<= 2 - -
++ 2 - -
return 2 - -
{} 3 - -
n1=14 N1=53 n2=10 N2=38

Here N1=53 and N2=38.

The program length N=N1+N2=53+38=91

Vocabulary of the program n=n1+n2=14+10=24

Volume V= N * log2N=91 x log2 24=417 bits.

The estimate program length N of the program

Page no: 11 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

= 14 log214+10 log2)10
= 14 * 3.81+10 * 3.32
= 53.34+33.2=86.45

Conceptually unique input and output parameters are represented by n2*.

n2*=3 {x: array holding the integer to be sorted. This is used as both input and output}
{N: the size of the array to be sorted}

The Potential Volume V*=5log25=11.6

Since L=V*/V

We may use another formula

V^=V x L^= 417 x 0.038=15.67
E^=V/L^=D^ x V

Therefore, 10974 elementary mental discrimination is required to construct the program.

This is probably a reasonable time to produce the program, which is very simple.

Cyclomatic Complexity
Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J. McCabe
developed this metric in 1976.McCabe interprets a computer program as a set of a strongly connected directed
graph. Nodes represent parts of the source code having no branches and arcs represent possible control flow
transfers during program execution. The notion of program graph has been used for this measure, and it is
used to measure and control the number of paths through a program. The complexity of a computer program
can be correlated with the topological complexity of a graph.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity. The
cyclomatic number is equal to the number of linearly independent paths through a program in its graphs
representation. For a program control graph G, cyclomatic number, V (G), is given as:
V (G) = E - N + 2 * P
E = The number of edges in graphs G
N = The number of nodes in graphs G

Page no: 12 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

P = The number of connected components in graph G.

Example:

Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:
1. V (G) is the maximum number of independent paths in the graph
2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10

Case Tools For Software Metrics

Many CASE tools (Computer Aided Software Engineering tools) exist for measuring software. They are either
open source or are paid tools. Some of them are listed below:
1. Analyst4j tool is based on the Eclipse platform and available as a stand-alone Rich Client Application
or as an Eclipse IDE plug-in. It features search, metrics, analyzing quality, and report generation for
Java programs.
2. CCCC is an open source command-line tool. It analyzes C++ and Java lines and generates reports
on various metrics, including Lines of Code and metrics proposed by Chidamber & Kemerer and Henry
& Kafura.
3. Chidamber & Kemerer Java Metrics is an open source command-line tool. It calculates the C&K
object-oriented metrics by processing the byte-code of compiled Java.
4. Dependency Finder is an open source. It is a suite of tools for analyzing compiled Java code. Its core
is a dependency analysis application that extracts dependency graphs and mines them for useful
information. This application comes as a command-line tool, a Swing-based application, and a web
application.
5. Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open source metrics calculation and dependency
analyzer plugin for the Eclipse IDE. It measures various metrics and detects cycles in package and
type dependencies.
6. Eclipse Metrics Plug-in 3.4 by Lance Walton is open source. It calculates various metrics during build
cycles and warns, via the problems view, of metrics 'range violations'.
7. OOMeter is an experimental software metrics tool developed by Alghamdi. It accepts Java/C# source
code and UML models in XMI and calculates various metrics.
8. Semmle is an Eclipse plug-in. It provides an SQL like querying language for object-oriented code,
which allows searching for bugs, measure code metrics, etc.

Page no: 13 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Software Cost Estimation

For any new software project, it is necessary to know how much it will cost to develop and how much
development time will it take. These estimates are needed before development is initiated, but how is this
done? Several estimation procedures have been developed and are having the following attributes in
common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule estimates.
6. Acquire one or more automated estimation tools.

Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers are required for the project and
to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is progressing according
to the procedure and takes corrective action, if necessary.

Cost Estimation Models

A model may be static or dynamic. In a static model, a single variable is taken as a key element for
calculating cost and time. In a dynamic model, all variable are interdependent, and there is no basic variable.

Static, Single Variable Models: When a model makes use of single variables to calculate desired values
such as cost, time, efforts, etc. is said to be a single variable model. The most common equation is:
C=aLb
Where C = Costs
L= size
a and b are constants

The Software Engineering Laboratory established a model called SEL model, for estimating its software
production. This model is an example of the static, single variable model.
E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26

Where E= Efforts (Person Per Month)

DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code

Page no: 14 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Static, Multivariable Models: These models are based on method (1), they depend on several variables
describing various aspects of the software development environment. In some model, several variables are
needed to describe the software development process, and selected equation combined these variables to
give the estimate of time & cost. These models are called multivariable models.
WALSTON and FELIX develop the models at IBM provide the following equation gives a relationship
between lines of source code and effort:
E=5.2L0.91

In the same manner duration of development is given by

D=4.1L0.36

The productivity index uses 29 variables which are found to be highly correlated productivity as follows:

Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the estimator gives Xione of the values -1,
0 or +1 depending on the variable decreases, has no effect or increases the productivity.

Example: Compare the Walston-Felix Model with the SEL model on a software development expected to
involve 8 person-years of effort.
1. Calculate the number of lines of source code that can be produced.
2. Calculate the duration of the development.
3. Calculate the productivity in LOC/PY
4. Calculate the average manning

Solution:
The amount of manpower involved = 8PY=96persons-months
(a)Number of lines of source code can be obtained by reversing equation to give:

Then
L (SEL) = (96/1.4)1⁄0.93=94264 LOC
L (SEL) = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
D (SEL) = 4.6 (L) 0.26
= 4.6 (94.264)0.26 = 15 months
D (W-F) = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months
(c) Productivity is the lines of code produced per persons/month (year)

(d)Average manning is the average number of persons required per month in the project

COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the most
generally used software estimation models in the world. COCOMO predicts the efforts and schedule of a
software product based on the size of the software.

Page no: 15 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of
source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e.,
multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static
single variable models, using KDLOC as the measure of the size. To determine the initial effort E i in person-
months the equation used is of the type is shown below
Ei=a*(KDLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1.Organic: A development project can be treated of the organic type, if the project deals with developing a
well-understood application program, the size of the development team is reasonably small, and the team
members are experienced in developing similar methods of projects. Examples of this type of projects are
simple business systems, simple inventory management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the development consists
of a mixture of experienced and inexperienced staff. Team members may have finite experience in related
systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached
system includes developing a new operating system (OS), a Database Management System (DBMS), and
complex inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being developed
is strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For
Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person
month) and development time from the size of estimation in KLOC (Kilo Line of code) efforts estimation
takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc.
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters.
The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the code size are
shown below:

Page no: 16 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time based on the
effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for
different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe
that the effort is somewhat superliner in the size of the software product. Thus, the effort required to develop
a product increases very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the
development time is a sub linear function of the size of the product, i.e. when the size of the product increases
by two times, the time to develop the product does not double but rises moderately. This can be explained by
the fact that for larger products, a larger number of activities which can be carried out concurrently can be
identified. The parallel activities can be

carried out simultaneously by the engineers. This reduces the time to complete the project. Further, from fig,
it can be observed that the development time is roughly the same for all three categories of products. For
example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it is of
organic, semidetached, or embedded type.

Page no: 17 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower
cost per month. But, implicit in this project cost computation is the assumption that the entire project cost is
incurred on account of the manpower cost alone. In addition to manpower cost, a project would incur costs
due to hardware and software required for the project and the company overheads for administration, office
space, etc.

It is important to note that the effort and the duration estimations obtained using the COCOMO model are
called a nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries
to complete the project in a time shorter than the estimated duration, then the cost will increase drastically.
But, if anyone completes the project over a longer period of time than the estimated, then there is almost no
decrease in the estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for
each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has average
experience on similar type of projects. The project schedule is not very tight. Calculate the Effort, development
time, average staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and
experience of development time.
Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

Page no: 18 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

P = 176 LOC/PM

2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number
of lines of code and some constants calculated according to the various software systems. The intermediate
COCOMO model recognizes these facts and refines the initial estimates obtained through the basic COCOMO
model by using a set of 15 cost drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes -
 Required software reliability extent
 Size of the application database
 The complexity of the product
Hardware attributes -
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Personnel attributes -
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
Project attributes -
 Use of software tools
 Application of software engineering methods
 Required development schedule
The cost drivers are divided into four categories:

Page no: 19 Get real-time updates from RGPV

Downloaded from www.rgpvnotes.in

Intermediate COCOMO equation:

E=ai (KLOC) bi*EAF
D=ci (E)di
Coefficients for intermediate COCOMO
Project ai bi ci di
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost driver?s effect on each method of the software engineering process. The detailed model
uses various effort multipliers for each cost driver property. In detailed cocomo, the whole software is
differentiated into multiple modules, and then we apply COCOMO in various modules to estimate effort and
then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given according to
every phase of the software lifecycle.

Page no: 20 Get real-time updates from RGPV

 We hope you find these notes useful.
You can get previous year question papers at
https://qp.rgpvnotes.in .

If you have any queries or you want to submit your

study notes please write us at
[email protected]