CHAPTER 4 – SOFTWARE PROJECT ESTIMATION (16 MARKS )

Software Project Planning: The objective of software planning is to provide a framework that
enables the manager to make reasonable estimates of resources, cost and schedule. These
estimates are made within a limited time frame at the beginning of a software project and should
be updated regularly as the project progresses.
➢ The first activity in software project planning is the determination of the scope.
Function and performance should be assessed to establish a project scope that is
unambiguous and understandable at management and technical levels. A statement of
software scope must be bounded. That is, quantitative data (e.g. number of simultaneous
users, size of mailing list, maximum allowable response time, etc) are stated explicitly,
constraints and limitations (e.g. product cost that restricts memory size) are noted and
helpful factors (e.g. algorithms that are well understood and available) are described.
Since both cost and schedule estimates are functionally oriented, some degree of
decomposition is often useful.
➢ Once scope is established, it is necessary to determine if the cost is feasible or not. The
feasibility of the project must be determined keeping in mind four major aspects:
1) Technology
2) Finance
3) Time
4) Resources (other than financial)
➢ The next task is the estimation of resources required to accomplish the software
development effort. At the beginning, software and hardware tools must exist to support
the development effort. At a higher level, the primary resource i.e. manpower, must
exist. Each resource is specified with four characteristics:
1) Description of the resource.
2) Statement of availability
3) Time at which the resource will be required
4) Duration of time the resource will be applied
4.1 Management Spectrum of 4 P’s
In software engineering, the management spectrum describes the management of a software
project. The management of a software project starts from requirement analysis and finishes
based on the nature of the product, it may or may not end because almost all software
products faces changes and requires support. It is about turning the project from plan to
reality.
The management spectrum focuses on the four P‘s; people, product, process and project.
1. 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.
• It is so important to have highly skilled and motivated developers that the
Software Engineering Institute has developed a People Management Capability

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 1

 Maturity Model (PM-CMM),
Organizations that achieve high levels of maturity in the people management area
have a higher likelihood of implementing effective software engineering practices.
2. The Product:
• The product is the ultimate goal of the project.
• This is any types of software product that has to be developed.
• To develop a software product successfully, all the product objectives and scopes
should be established, alternative solutions should be considered, and technical
and management constraints should be identified beforehand.
• Lack of these information, it is impossible to define reasonable and accurate
estimation of the cost, an effective assessment of risks, a realistic breakdown of
project tasks or a manageable project schedule that provides a meaningful
indication of progress.
3. The Process:
• A software process provides the framework from which a comprehensive plan for
software development can be established.
• A number of different tasks sets— tasks, milestones, work products, and quality
assurance points—enable the framework activities to be adapted to the characteristics
of the software project and the requirements of the project team.
• Finally, umbrella activities overlay the software process model.
• Umbrella activities are independent of any one framework activity and occur
throughout the process.
4. The Project:
• The project is the complete software project that includes requirement analysis,
development, delivery, maintenance and updates.
• The project manager of a project or sub-project is responsible for managing the
people, product and process.
• The responsibilities or activities of software project manager would be a long list but
that has to be followed to avoid project failure.
A software project could be extremely complex and as per the industry data the
failure rate is high.
• Its merely due to the development but mostly due to the steps before development and
sometimes due to the lack of maintenance.
4.2 Metrics for Size Estimation
4.2.1 Lines of Code (LOC)
Lines of Code (LOC) method measures software and the process by which it is being
developed.
Before an estimate for software is made, it is important and necessary to understand software
scope and estimate its size.
• Lines of Code (LOC) is a direct approach method and requires a higher level of
detail by means of decomposition and partitioning.
• In contrast, Function Points (FP) is indirect an approach method where instead of
focusing on the function it focuses on the domain characteristics.
From statement of software scope software is decomposed into problem functions that can
each be estimated individually.
• LOC or FP (estimate variables) is then calculated for each function.
• An expected value is then computed using the following formula.
EV= (Sopt + 4 *Sm + Spess)/6
where,
• EV stands for the estimation variable.
• Sopt stand for the optimistic(POSITIVE) estimate.

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 2

 • Sm stands for the most likely estimate.
• Spess stand for the pessimistic(NEGATIVE) estimate.

It is assumed that there is a very small probability that the actual size results will fall outside
the optimistic or pessimistic value.
Once the expected value for estimation variable has been determined, historical LOC or FP
data are applied and person months, costs etc are calculated using the following formula.
Productivity = KLOC / Person-month
Quality = Defects / KLOC
Cost = $ / LOC
Documentation = pages of documentation / KLOC
Where,
KLOC stand for no. of lines of code (in thousands).
Person-month stand for is the time(in months) taken by developers to finish the product.
Defects stand for Total Number of errors discovered

Example:
Problem Statement: Take the Library management system case. Software developed for library
will accept data from operator for issuing and returning books. Issuing and returning will
require some validity checks. For issue it is required to check if the member has already issued
the maximum books allowed. In case for return, if the member is returning the book after the
due date then fine has to be calculated. All the interactions will be through user interface. Other
operations include maintaining database and generating reports at regular intervals.
Major software functions identified.
1. User interface
2. Database management
3. Report generation
For user interface
Sopt : 1800
Sm : 2000
Spess : 4000
EV for user interface
EV = (1800 + 4*2000 + 4000) / 6
EV = 2300

For database management

Sopt : 4600
Sm : 6900
Spess : 8600
EV for database management
EV = (4600 + 4*6900 + 8600) / 6
EV = 6800

For report generation

Sopt : 1200
Sm : 1600
Spess : 3200
EV for report generation
EV = (1200 + 4*1600 + 3200) / 6
EV = 1800

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 3

5.2.2 Function Points (FP):
These metrics use a measure of functionality delivered by the application as a
normalization value.
Functionality must be derived indirectly using other direct measures.
A suggested measure called function points uses an empirical relationship based on direct
measures and assessment of the software complexity.
Function points are computed by completing the table as shown in figure 2.2.

Information domain characteristics are determined and counts are provided in the appropriate
table location. Information domain values are defined in the following manner:
i) Number of user inputs
Each user input that provides distinct application-oriented data to the software is counted.
Inputs should be distinguished from enquiries, which are counted separately.
ii) Number of user outputs
Each user output that provides application-oriented data to the user is counted. In this context
output refers to reports, screens, error messages, etc. Individual data items within a report are
not counted separately.
iii) Number of user enquiries
An enquiry is defined as an on-line input that results in the generation of some immediate
software response in the form of an on-line output. Each distinct enquiry is counted.
iv) Number of files
Each logical master file is counted.
v) Number of external interfaces
All machine-readable interfaces (e.g. data files on storage media) that are used to transmit
information to another system are counted.
Once this data is collected, a complexity value is associated with each count. Criteria are
developed to determine whether a particular entry is simple, average or complex.
To compute function points (FP) the following relationship is used:
FP = count total * [0.65 + 0.01 * Σ(Fi)]
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following
questions:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or
operations?
8. Are the master files updated on-line?

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 4

9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential).

Once function points have been calculated, productivity, quality, cost and
documentation can be evaluated.
Productivity = FP / person-month
Quality = defects / FP
Cost = $ / FP
Documentation = pages of documentation / FP

Example: Same as LOC problem

Information Domain est
Opt likely Pess wt FP Account
Values Account
Number of Inputs 4 10 16 10 4 40
Number of Outputs 4 7 16 8 5 40
Number of Inquiries 5 12 19 12 4 48
Number of Files 3 6 9 6 10 60
Number of external
2 2 3 2 7 14
interfaces
Count Total 202

Complexity weighing factors are determined and the following results are obtained.
Factor Value
Backup Recovery 4
Data Communication 1
Distributed processing 0
Perfomance Critical 3
Existing Operating Environment 2
On-line data entry 5
Input transaction over multiple screens 5
Master file updated online 3
Information domain values complex 3
Internal processing complex 2
Code design for reuse 0
Conversion/Installation in design 1
Multiple installations 3
Application designed for change 5
Sum ( Fi ) 37

Estimated number of FP: = 202/55.5 = 3.64 person-month

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 5

Total Cost = Development cost * person-month
= 8000 * 3.64 FPestimated = count-total * [0.65 + 0.01 * ∑(Fi) ]
FPestimated = 206
From historical data, productivity is 55.5 FP/person-month and development cost is $8000
per month.
Productivity = FP/ person-month
person-month = FP/Productivity =$29100
Cost per FP = Cost/FP = 29100/202 = $144.2per FP

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 6

4.3 Project Cost Estimation Approaches
Software cost estimation is a continuing activity, which starts at the proposal stage and
continues through the lifetime of the project. Estimation of various project parameters is a
basic project planning activity. The important project parameters that are estimated include:
project size, effort required to develop the software, project duration, and cost. 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:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
4.3.1 Heuristic Estimation Technique
Experience based
As techniques basically use the concept of learning from the previous project and
estimate the cost.
The objective is to find a similar system produced earlier and through knowing how the
properties of the new system vary from the existing one.

Two classes of different heuristic Estimation Techniques:

- Single variable model
- Multi variable model
1. Single Variable Estimation Models:
It provides 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 estimator model takes the following form:
Estimated Parameter = c1 * ed1
e= 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- calculated from past projects.
COCOMO is one of this type of models example.
2. Multivariable Cost Estimation Model:
It has the following form
Estimated Resources = c1 * e1d1 + c2 * e2d2 + - - - -
e1 and 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 estimate compared to
the Single Variable Models, since a project parameters is typically influenced by several
independent parameters.
The independent parameters influence the dependent parameter to different extents.
This is modeled by the constants
c1,c2,d1,d2.....
These constants are determined from historical data. Intermediate Model of COCOMO is an
example of this.

4.3.2 Analytical Estimation

Assumptions based
• Analytical estimation techniques derive the required results starting with basic
assumptions regarding the project.

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 7

• 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.
• The length of a program as defined by Halstead, quantifies total usage of all
operators and operands in the program.
• The program vocabulary is the number of unique operators and operands
used in the program.
• The length of a program (i.e. the total number of operators and operands used
in the code) depends on the choice of the operators and operands used.
• The program volume V is the minimum number of bits needed to encode the
program.
• The potential minimum volume V* is defined as the volume of most succinct
program in which a problem can be coded.
• The effort required to develop a program can be obtained by dividing the
program volume with the level of the programming language used to develop
the code.
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‖
4.3.3 Empirical Estimation Techniques
Guess based
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:
1. Expert judgment technique and
2. Delphi cost estimation.
4.3.3.1 Expert Judgment Technique
Expert judgment is one of the most widely used estimation techniques.

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 8

 • 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.
For example, he may be conversant with the database and user interface parts but may not
be very knowledgeable about the computer communication part. A more refined form of
expert judgment is the estimation made by group of experts. Estimation by a group of experts
minimizes factors such as individual oversight, lack of familiarity with a particular aspect of
a project, personal bias, and the desire to win contract through overly optimistic estimates.
However, the estimate made by a group of experts may still exhibit bias on issues where the
entire group of experts may be biased due to reasons such as political considerations. Also,
the decision made by the group may be dominated by overly assertive members.
4.3.3.1 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.

4.4 COCOMO (Constructive Cost Model)

B.W. Boehm Introduced COCOMO model in his book Software Engineering Economics in
1981 COCOMO is a hierarchy of cost estimation models it includes basic , intermediate and
detailed sub model.

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 9

1. Basic Model
The basic model aims at estimating, in a quick and rough fashion, most of the small to
medium sized software projects.
Three modes of software development are considered in this model:
Organic: A small team of experienced developers develops software in a very familiar
environment.
Embedded: The project has tight constraints, which might be related to the target processor.
Semidetached: It is an intermediate mode between the organic mode and embedded mode.

Depending on the problem at hand, the team might include a mixture of experienced and less
experienced people with only a recent history of working together.
The Basic COCOMO equations take the form:
E = ab (KLOC)bb
D = cb (E)db
SS = E/D persons
P = KLOC/E
Where E = effort
D = Deployment time
SS = staff size
P = productivity
ab ,bb ,cb ,db = Coefficients

Example
Use COCOMO model for organic, semi-detached, embedded mode to calculate effort
and development time for size of project 600 KLOC.

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 10

Solution:
The basic COCOMO equations take the form:
E = a *(KLOC)b
D = c* (E)d
Estimated size of the project = 600 KLOC
1. Organic Mode
E = 2.4 *(600)1.05 = 1982.76 PM
D = 2.5 *(1982.76)0.38 = 44.76 M
2. Semidetached Mode
E = 3.0* (600)1.12 = 3878.38 PM
D = 2.5* (3878.38)0.35 = 45.08 M
3. Embedded Mode
E = 3.6 *(600)1.20 = 7763.97 PM
D = 2.5 *(7763.97)0.32 = 43.93 M

CHAPTER 4 SEN FOR CO BY VAISHALI RANE Page 11