Unit - IV

Software Project Cost Estimation

➢ The management spectrum 4 P’s

Q] Explain 4 p’s in Management Spectrum?

The management spectrum describes the management of a software project or how to make a project
successful.
It focuses on the four P’s; people, product, process and project.

The four P’s of management spectrum has been described briefly in below.
The People:
People of a project includes from manager to developer, from customer to end user.
But mainly people of a project highlight the developers.
The “people factor” is so important that the Software Engineering Institute has developed a People
Capability Maturity Model (People CMM) to continually improve its ability to attract, develop,
motivate, organize, and retain the workforce needed to achieve its business objectives.
Organizations that effectively manage their people and achieve high levels of maturity in people
management have a greater chance of implementing successful software engineering practices.

The Product:
Product is any software that has to be developed. To
develop successfully,
• product objectives and scope should be established,
• alternative solutions should be considered, and
• technical and management constraints should be identified.
Without this information, it is impossible to define
• accurate estimates of the cost,
• an effective assessment of risk,
• a realistic breakdown of project tasks, or a manageable project schedule
The Process:
A software process provides the framework from which a comprehensive plan for software
development can be established.
The Process has several steps involved like, documentation phase, implementation phase,
deployment phase, and interaction phase.

The Project:
Planning and controlling a software project is done for one primary reason…it is the only known way
to manage complexity.
The success rate for present-day software projects may have improved but our project failure rate
remains much higher than it should be.
To avoid project failure, a software project manager and the software engineers who build the product
must avoid a set of common warning signs, and develop a common-sense approach for planning,
monitoring, and controlling the project.
 ➢ Metrics for Software Project Size Estimation
The project size is a measure of the problem complexity in terms of the effort and time required
to develop the product.
Currently two metrics are popularly being used widely to estimate size:
• Lines of Code (LOC)
• Function Point (FP)
1. Lines of Code (LOC)
Q] Explain LOC. [4M]

LOC is the simplest among all metrics available to estimate project size.
This metric is very popular because it is the simplest to use.
Using this metric, the project size is estimated by counting the number of source instructions in the
developed program.
Obviously, while counting the number of source instructions, lines used for commenting the code and
the header lines should be ignored.
Determining the LOC count at the end of a project is a very simple job.
However, accurate estimation of the LOC count at the beginning of a project is very difficult.
In order to estimate the LOC count at the beginning of a project, project managers usually divide
the problem into modules, and each module into submodules and so on, until the sizes of the
different leaflevel modules can be approximately predicted.
To be able to do this, past experience in developing similar products is helpful.
By using the estimation of the lowest level modules, project managers arrive at the total size
estimation.

Consider example of mechanical CAD software.

The mechanical CAD software will accept two dimensional and three-dimensional data.
User will interact with system through user interface and peripheral devices like mouse, plotter,
laser printer.
All geometric data and supporting information are stored in database.
Design analysis modules will be developed to produce the required output, which will be displayed
on variety of graphic devices.
For size estimation CAD software is divided into major functions and size estimation of each function
is done.
Function Estimated
LOC
User interface 2,300
Two-dimension geometric analysis 5,300
Three-dimension geometric 6,800
analysis
Database management 3,500
Computer Graphics display facilities 4,950
Peripheral Control Function 2,100
Design analysis module 8,400
 Estimated line of code 33,350
For our purposes, we assume that the following major software
functions are identified:
• User interface and control facilities (UICF)
• Two-dimensional geometric analysis (2DGA)
• Three-dimensional geometric analysis (3DGA)
• Database management (DBM)
• Computer graphics display facilities (CGDF)
• Peripheral control function (PCF)
• Design analysis modules (DAM)

Following the decomposition technique for LOC, an estimation

table is developed.
A range of LOC estimates is developed for each function.
For example, the range of LOC estimates for the 3D geometric
analysis function is:

• Optimistic—4600 LOC.
• Most likely—6900 LOC.
• Pessimistic—8600 LOC.

The expected value for the estimation variable (size), S, can be

computed as a weighted average of the optimistic (sopt), most
likely (sm), and pessimistic (spess) estimates.
For example,
S = (Sopt + 4Sm + Spess)/6
Applying Equation, the expected value for the 3D geometric
analysis function is 6800 LOC.
Other estimates are derived in a similar fashion.

2. Function point (FP)

Q] Write note on FP. [4M]

The conceptual idea behind the function point metric is that the size of a software product is directly
dependent on the number of different functions or features it supports.
A software product supporting many features would certainly be of larger size than a product with less
number of features.
Each function when invoked reads some input data and transforms it to the corresponding output data.
For example, the issue book feature of a Library Automation Software takes the name of the book as
input and displays its location and the number of copies available.
Besides using the number of input and output data values, function point metric computes the size of
a software product using three other characteristics of the product such as Number of inquiries,
Number of files and Number of interfaces
The steps in function point analysis are:
• Count the number of functions of each proposed type
• Compute the unadjusted function point (UFP)
• Find total degree of influence (TDI)
• Compute value adjustment factor (VAF)
• Find the function point count (FPC)

1. Count the number of functions of each proposed type:

Functions belong to the following types:

• External Input: Functions related to data entering the system.

• External Outputs: Functions related to data exiting from the system.
• External Enquires: They lead to data retrieval from the system.
• Internal Files: Logical files maintained within the system.
• External interface files: These are logical files of other application used by our application.

2. Compute the unadjusted function point (UFP)

Categories each of the function types like simple, average or complex based on their complexity.
Multiply the count of each function type with its weighing factor and find the weighted sum.

Eg:-

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of files)*10

+ (Number of interfaces)*7

3. Find total degree of influence (TDI)

Use the 14 general factots of system to find the degree of influence of each of them.
Factors include high transaction rates, throughput, response time etc
The sum of all 14 degree of influence will give TDI. The range of TDI is 0 to 70.

4. Compute value adjustment factor (VAF)

VAF=(TDI*0.01)+0.65

5. Find the function point count (FPC)

FPC=UFP*VAF
➢ Project Cost Estimation Approaches

Software cost estimation is the process of predicting the effort required to develop a software system.
Project cost estimating is the process of predicting the total cost of the tasks, time, and resources
required to deliver a project's scope of work.
These estimates not only help in quoting the project cost to the customer, but are also useful in resource
planning and scheduling.

There are three broad categories of estimation techniques:

i) Heuristic ii) Analytical iii) Empirical

1. Heuristic cost estimation approach

Heuristic techniques assume that the relationships among the different project parameters can be
modeled using suitable mathematical expressions.

y = f(x)

y = x3
dependant = independent (x = 3)

Once the basic (independent) parameters are known, the other (dependent) parameters can be easily
determined by substituting the value of the basic parameters in the mathematical expression.
Different heuristic estimation models can be divided into the following two classes:
• single variable model and
• multi variable model.
Single variable estimation models provide a means to estimate the desired characteristics of a problem,
using some previously estimated basic (independent) characteristic of the software product such as its
size.

A single variable estimation model takes the following form:

Estimated Parameter = c1 * e1 d1

e1 = characteristic which already have been calculated.

Estimated parameter is the dependent parameter to be estimated. The dependent parameters to be
estimated could be effort, duration, staff size etc.
c1 and d1 are constants whose value is usualy determined using data collected from past projects
(historical data).
COCOMO is one of this type of models example.

A multivariable cost estimation model takes the following form:

Estimated Resource = c1*e1 d 1 + c2*e2 d 2 + ...

e1, e2, … are the basic (independent) characteristics of the software already estimated,
c1, c2, d1, d2, … are constants.
Multivariable estimation models are expected to give more accurate estimates compared to the single
variable models.
The intermediate COCOMO model can be considered to be an example of a multivariable estimation
model.

2. Analytical Estimation Techniques

Analytical estimation techniques derive the required results starting with basic assumptions regarding
the project.
Thus, unlike empirical and heuristic techniques, analytical techniques do have scientific basis.
Halstead’s software science is an example of an analytical technique.
Halstead’s software science can be used to derive some interesting results starting with a few simple
assumptions.
Halstead’s software science is especially useful for estimating software maintenance efforts. In fact, it
outperforms both empirical and heuristic techniques when used for predicting software maintenance
efforts.

Halstead’s Software Science – an analytical technique

Halstead’s software science is an analytical technique to measure size, development effort, and
development cost of software products.

Halstead used a few primitive program parameters to develop the expressions for over all program
length, potential minimum value, actual volume, effort, and development time.

For a given program, let:

η1 be the number of unique operators used in the program,

η2 be the number of unique operands used in the program,
N1 be the total number of operators used in the program, N2
be the total number of operands used in the program.

Length Estimation
N = η1log2η1 + η2log2η2
Program Volume
V = Nlog2η ……… whre η = η1+ η2

Example:

Let us consider the following C program: main(

{
int a, b, c, avg;

scanf(“%d %d %d”, &a, &b, &c);

avg = (a+b+c)/3; printf(“avg =

%d”, avg);

The unique operators are:

main,(),{},int,scanf,&,“,”,“;”,=,+,/, printf

The unique operands are:

a, b, c, &a, &b, &c, a+b+c, avg, 3, “%d %d %d”, “avg = %d”

Therefore, η1 = 12, η2 = 11 η = η1+ η2 = 23
Estimated Length (N) = η1log2η1 + η2log2η2
= (12*log12 + 11*log11)
= (12*3.58 + 11*3.45)
= (43+38)
= 81

Volume (V) = Nlog2η ……… whre η = η1+ η2

= 81*4.52
= 366

3. Empirical Estimation Techniques

Empirical estimation techniques are based on making an educated guess of the project parameters.
While using this technique, prior experience with development of similar products is helpful. Although
empirical estimation techniques are based on common sense, different activities involved in estimation
have been formalized over the years.
Two popular empirical estimation techniques are: Expert judgment technique and Delphi cost
estimation.

A] Expert Judgment Technique

Expert judgment is one of the most widely used estimation techniques. In this approach, an expert
makes an educated guess of the problem size after analyzing the problem thoroughly.
Usually, the expert estimates the cost of the different components (i.e. modules or subsystems) of the
system and then combines them to arrive at the overall estimate.
However, this technique is subject to human errors and individual bias.
Also, it is possible that the expert may overlook some factors inadvertently.
Further, an expert making an estimate may not have experience and knowledge of all aspects of a
project.
B] Delphi cost estimation
Delphi cost estimation approach tries to overcome some of the shortcomings of the expert judgment
approach.
Delphi estimation is carried out by a team comprising of a group of experts and a coordinator. In this
approach, the coordinator provides each estimator with a copy of the software requirements
specification (SRS) document and a form for recording his cost estimate.
Estimators complete their individual estimates anonymously and submit to the coordinator. In their
estimates, the estimators mention any unusual characteristic of the product which has influenced his
estimation.
The coordinator prepares and distributes the summary of the responses of all the estimators, and
includes any unusual rationale noted by any of the estimators.
Based on this summary, the estimators re-estimate.
This process is iterated for several rounds. However, no discussion among the estimators is allowed
during the entire estimation process. The idea behind this is that if any discussion is allowed among
the estimators, then many estimators may easily get influenced by the rationale of an estimator who
may be more experienced or senior. After the completion of several iterations of estimations, the
coordinator takes the responsibility of compiling the results and preparing the final estimate.