Unit-4

Software Project Estimation

 The Management Spectrum

 Metrics for size estimation –LOC(Line of Code), FP(Function Points)

 Project Cost estimation approach

 COCOMO(Constructive Cost Model),COCOMO II

 Risk Management- Identification ,Risk Assement , Risk

Containment ,RMMM Strategy

4.1The Management Spectrum

Effective software project management focuses on the four P’s: people, product, process, and
project.

The People:

1. 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 accomplish its strategic business
objectives.

2. The people capability maturity model defines the following key practice areas for software
people:

a. Staffing
b. communication and coordination

c. work environment

d. performance management

e. Training, compensation, competency analysis and development, career development,

workgroup development, team/culture development and others.

3. Organizations that achieve high levels of People-CMM maturity have higher likelihood of
implementing effective software project management practices.

The Product:

1. Before a project can be planned, product objectives and scope should be established,
alternative solutions should be considered and technical and management constraints should be
identified.

2. Without this information, it is impossible to define reasonable (and accurate) estimates of the
cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable
project schedule that provides a meaningful indication of progress.

3. Objectives identify the overall goals for the product (from the stakeholders’ points of view)
without considering how these goals will be achieved.

4. Scope identifies the primary data, functions, and behaviors that characterize the product

5. The alternatives enable managers and practitioners to select a “best” approach, given the
constraints imposed by delivery deadlines, budgetary restrictions, personnel availability,
technical interfaces, and other factors.

The Process:

1. A software process provides the framework from which a comprehensive plan for software
development can be established.

2. A small number of framework activities are applicable to all software projects, regardless of
their size or complexity.

3. A number of different task 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.

4. Finally, umbrella activities—such as software quality assurance, software configuration

management, and measurement occur throughout the process.
The Project:

1. To manage complexity, we conduct planned and controlled software projects.

2. The success rate for present-day software projects may have improved but our project failure
rate remains much higher than it should be.

3. To avoid project failure, a software project manager and the software engineers who build the
product must avoid a set of common warning signs, understand the critical success factors that
lead to good project management, and develop a common-sense approach for planning,
monitoring, and controlling the project.

4.2 Metrics for size estimation

 A Metric defines in quantitative terms the degree to which a system, system
component, or process possesses a given attribute.

 Accurate estimation of the problem size is fundamental to satisfactory estimation of

effort, time duration and cost of a software project.

 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) and Function Point (FP).

4.2.1 LOC (Line of Code)

Q1. With an example, explain Line of Code (LOC) based estimation.(4 marks)

Q2. State importance of “Function point “and “lines of code” in concerned with project
estimation

 LOC is the simplest among all metrics available to estimate project size.

 This metric is very popular because it is the simplest to use.

 LOC measure the size of a project by counting the number of source instructions in the
development program ignoring the commenting code and header lines.

 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 leaf-level modules can be approximately predicted.
 Example - let us consider a software package to be developed for a computer-aided
design application for mechanical components. A review of the System Specification
indicates that the software is to execute on an engineering workstation and must interface
with various computer graphics peripherals including a mouse, digitizer, high resolution
color display and laser printer.

Using the System Specification as a guide, a preliminary statement of software scope can
be developed. Further divide the project into modules, estimates the lines of code for each
module and ultimately combine all modules LOC to get final LOC count as given below.

Sr.No Project Module LOC

.
01 User interface and control facilities (UICF) 2,300 2300
02 Two-dimensional geometric analysis (2DGA) 5300
03 Three-dimensional geometric analysis (3DGA) 6800
04 Database management (DBM) 3350
05 Computer graphics display facilities (CGDF) 4950
06 Peripheral control function (PCF) 2100
07 Design analysis modules (DAM) 8400
Total 33200
33.2KLOC

4.2.2 Function Point (FP)

 Function Point Analysis was initially developed by Allan J. Albercht in 1979 at IBM

 It has been further modified by the International Function Point Users Group (IFPUG).

 It can be used to easily estimate the size of a software product directly from the problem
specification.

 It assesses the functionality delivered to its users, based on the user’s external view of the
functional requirements.

 It measures the logical view of an application not the physically implemented view or
the internal technical view

 FP characterizes the complexity of the software system and hence can be used to depict
the project time and the manpower requirement.

 The effort required to develop the project depends on what the software does.

 FP is programming language independent.

  FP method is used for data processing systems, business systems like information
systems.

In this method, the number and type of functions supported by the software are utilized to find
FPC (function point count). The steps in function point analysis are:

 Count the number of functions of each proposed type.

 Compute the Unadjusted Function Points (UFP).
 Find Total Degree of Influence (TDI).
 Compute Value Adjustment Factor (VAF).
 Find the Function Point Count (FPC).

The explanation of above points given below:

 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:
o External Inputs: Functions related to data entering the system.
o External outputs: Functions related to data exiting the system.
o External Inquiries: They leads to data retrieval from system but don’t change the
system.
o Internal Files: Logical files maintained within the system. Log files are not
included here.
o External interface Files: These are logical files for other applications which are
used by our system.
 Compute the Unadjusted Function Points (UFP): Categories each of the five function
types as simple, average or complex based on their complexity. Multiply count of each
function type with its weighting factor and find the weighted sum. The weighting factors
for each type based on their complexity are as follows:

Function type Simple Average Complex

External Inputs 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10

Find Total Degree of Influence:

  Use the ’14 general characteristics’ of a system to find the degree of influence of each of
them. The sum of all 14 degrees of influences will give the TDI. The range of TDI is 0 to
70.
 The 14 general characteristics are: Data Communications, Distributed Data Processing,
Performance, Heavily Used Configuration, Transaction Rate, On-Line Data Entry, End-
user Efficiency, Online Update, Complex Processing Reusability, Installation Ease,
Operational Ease, Multiple Sites and Facilitate Change. Each of above characteristics is
evaluated on a scale of 0-5.
 Compute Value Adjustment Factor(VAF): Use the following formula to calculate
VAF
VAF = (TDI * 0.01) + 0.65
 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF

Advantages:

 It can be easily used in the early stages of project planning.

 It is independent on the programming language.
 It can be used to compare different projects even if they use different technologies
(database, language etc).

4.2Project Cost Estimation Approach

Q1. Explain any one project cost estimation approach (4 marks)
Q2. Name two cost estimation approaches. (2 marks)
Q3. Describe the Analytical method of project cost estimation with example.(4 marks)

 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:

1. Empirical estimation techniques

2. Heuristic estimation techniques

3. Analytical estimation techniques

4.3.1 Empirical Estimation Techniques

 It is 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.

 Example of Empirical estimation - Expert judgment technique and Delphi cost

estimation.

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.
 For example, he may be familiar 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.

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.3.2 Heuristic estimation techniques

 Heuristic techniques assume that the relationships among the different project parameters
can be modeled using suitable mathematical expressions.
 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 the 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 = c 1 * e d 1

In the above expression, e is the characteristic of the software which has already been
estimated (independent variable).
The values of the constants c 1 and d 1 are usually determined using data collected from
past projects (historical data).
 The basic COCOMO model is an example of single variable cost estimation model.
 A multivariable cost estimation model -takes the following form:

Estimated Resource = c 1 *e 1 d 1 + c 2 *e 2 d 2 +...

Where e 1 , e 2 , … are the basic (independent) characteristics of the software already

estimated, and c 1 , c 2 , d 1 , d 2 , … are constants. Multivariable estimation models are
expected to give more accurate estimates compared to the single variable models, since a
project parameter is typically influenced by several independent parameters.
c 1 , c 2 , d 1 , d 2 , … . These are constants usually determined from historical data.
 The intermediate COCOMO model can be considered to be an example of a
multivariable estimation model.

4.3.3 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 overall
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 and Vocabulary

 Halstead’s definition of the length of the program as the total number of operators and
operands roughly agrees with the intuitive notation of the program length as the total
number of tokens used in the program.
 The program vocabulary is the number of unique operators and operands used in the
program. Thus, program vocabulary η = η 1 + η 2.

So estimated program length can be calculated by following formula

Estimated Length = η 1 log 2 η 1 + η 2 log 2 η 2

Program Volume

So program volume can be be calculated as follows

V = L log 2 η
Here the program volume V is the minimum number of bits needed to encode the
program.

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

Estimated Length (L) = η 1 log 2 η 1 + η 2 log 2 η 2

Estimated Length (L) = (12*log12 + 11*log11)

= (12*3.58 + 11*3.45) = (43+38) = 81

Volume (V) = L log 2 η

Volume (V) = Length*log (23) = 81*4.52 = 366
  COCOMO(Constructive Cost Model),COCOMO II

Q1. Describe COCOMO II model for evaluating size of software project with any
three parameters in detail.

Q2. Calculate using COCOMO model

i) Effort ii) Project duration iii) Average staff size if estimated size of project is
200 KLOC using organic mode

COCOMO (Constructive Cost Model)

 COCOMO (Constructive Cost Model) is a regression model based on LOC,

i.e number of Lines of Code.

 It can be used to predict the various parameters associated a project such as

size, effort, cost, time and quality.

 It was proposed by Barry Boehm in 1970 and is based on the study of 63

projects, which make it one of the best-documented models.

 Using this model one can calculate Effort(E) & schedule (project duration)

 Effort: Amount of labor that will be required to complete a task. It is

measured in person-months units.

 Schedule: Simply means the amount of time required for the completion of
the job, which is, of course, proportional to the effort put. It is measured in
the units of time such as weeks, months.

 Barry Boehm proposed three types of COCOMO Model

 Basic COCOMO Model-it is the first level model. Basic

COCOMO can be used for quick and slightly rough calculations of
Software Costs.

 Intermediate COCOMO Model-

Intermediate COCOMO takes these Cost Drivers into account

3. Detailed COCOMO Model-

 Detailed COCOMO additionally accounts for the influence of individual
project phases.

Following formula used to calculate project estimation of various parameter

such as effort, project duration, average staff size ,productivity and cost of
project.

In above formula value of a,b,c,d are constant and consider by type of

project mode.

Following three types of project mode defined by Barry Boehm

 Organic – A software project is said to be an organic type if the team size

required is adequately small, the problem is well understood and has been
solved in the past and also the team members have a nominal experience
regarding the problem.

 Semi-detached –
 A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various
programming environment lie in between that of organic and Embedded.

 Embedded – A software project with requiring the highest level of

complexity, creativity, and experience requirement fall under this category.

Example: 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.

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
COCOMO-II

 The COCOMO-II is the revised version of the original COCOMO (Constructive Cost
Model) and is developed at the University of Southern California.

 This model calculates the development time and effort taken as the total of the estimates
of all the individual subsystems.

 It is to develop Support capabilities for Continuous model improvement & provide a

quantitative analytics framework.

There are four models defined in COCOMO-II

 Application Composition Model

 Early Design Stage Model

 Past-Architecture Model

 Reuse Model
Risk Management

 Risk management is the process of identifying, addressing, and resolving

problems before they harm the project.

 The risks can be broadly categorized into three categories, as illustrated

below:

i. Project risks are those that have an impact on the project's schedule or
resources.
ii. Product risks affect the quality or performance of the product being
developed.
iii. Business risks are risks to the corporation developing or licensing the
software.

Risk Management Process

Risk Identification

 Several types of risks can impact a software product; a few of them are
defined below:

 Technology Risks: Risks arising from the software or hardware technologies

utilised to construct the system.

 People Risks: Risks associated with an individual of the development team.

 Organizational Risks: Risks arise due to the organization in which the

software is being produced.

 Tools Risks: Risks arising from the software tools and other support
software used to build the system.

 Requirement Risks: Risks associated with changes in client requirements

and the process of managing those changes.

 Estimation Risks: Risks arising from management estimates of the resources

necessary to create the system.

Risk Analysis

 During the risk analysis process, you must analyze each identified risk and
form opinions about its likelihood and severity.

 The risk could be classified as extremely low (0-10%), low (10-25%),

moderate (25-50%), high (50-75%), or very high (+75%) in probability.

The risk's impact might be classified as catastrophic (threatening the plan's

survival), severe (causing vital delays), bearable (delays are within allowable
contingencies), or trivial

Risk Planning

 The risk planning technique considers all of the significant risks that have
been identified and develop strategies to mitigate them.
Risk Monitoring

 Risk monitoring ensures that your assumptions about the product, process,
and business risks remain unchanged.

Risk Mitigation, Monitoring and Management(RMMM) Plan

 In most cases, a risk management approach can be found in the software

project plan.

 This can be broken down into three sections: risk mitigation, monitoring,
and management (RMMM).

 All work is done as part of the risk analysis in this strategy.

 The project manager typically uses this RMMM plan as part of the overall
project plan.

Risk Mitigation

 Risk Mitigation is a technique for avoiding risks (Risk Avoidance).

 The following are steps to take to reduce the risks:

 Finding out the risk.

 Removing causes that are the reason for risk creation.

 Controlling the corresponding documents from time to time.

 Conducting timely reviews to speed up the work.

Risk Monitoring

 Risk monitoring is an activity used to track a project's progress.

The following are the critical goals of the task.

 To check if predicted risks occur or not.

 To ensure proper application of risk aversion steps defined for risk.

 To collect data for future risk analysis.

  To allocate what problems are caused by which risks throughout the project.

Risk Management and planning

 It assumes that the mitigation activity failed and the risk is a reality.

 This task is done by Project manager when risk becomes reality and causes
severe problems.

 If the project manager effectively uses project mitigation to remove risks

successfully then it is easier to manage the risks.

 This shows that the response that will be taken for each risk by a manager.

 The main objective of the risk management plan is the risk register.

 This risk register describes and focuses on the predicted threats to a software
project.

Following table shows RMMM plan