Software Engineering(22413)

Unit-IV
Software Project Estimation
S.A.Sarwade
Lecturer in Information Technology
Government Polytechnic, Jalgaon
Learning Objectives
By watching this presentation students will be able to

• Estimate the size of the software product using the given method.

• Estimate the cost of the software product using the given empirical
method.

• Evaluate the size of the given software using COCOMO Model.

• Apply the RMMM strategy in identified risks for the given software
development problem.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 2

Project Management Concepts

The 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. Here, the manager of the project
has to control all these P’s to have a smooth flow in the project
progress and to reach the goal.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 3

Project Management Spectrum

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 4

 The People
• It deals with the cultivation of motivated, highly skilled people. It Consists of the
stakeholders, the team leaders, and the software team .
• Software Engineering Institute has developed a People Capability Maturity Model
(People-CMM), in recognition of the fact that “every organization needs to
continually improve its ability to attract, develop, motivate, organize, and retain
the workforce needed to accomplish its strategic business objectives”.
• The people capability maturity model defines the following key practice areas for
software people: staffing, communication and coordination, work environment,
performance management, training, compensation, competency analysis and
development, career development, workgroup development, and team/ culture
development, and others. Organizations that achieve high levels of People-CMM
maturity have a higher likelihood of implementing effective software project
management practices.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 5

The People: The Stakeholders
Five categories of stakeholders
• Senior managers – define business issues that often have significant influence
on the project.
• Project (technical) managers – plan, motivate, organize, and control the
practitioners who do the work.
• Practitioners – deliver the technical skills that are necessary to engineer a
product or application.
• Customers – specify the requirements for the software to be engineered and
other stakeholders who have a peripheral interest in the outcome.
• End users – interact with the software once it is released for production use.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 6

The Product
Product is any software that has to be developed. To develop successfully,
Product objectives and scope should be established before a project can be
planned.
• Objectives identify the overall goals for the product (from the stakeholders’
points of view) without considering how these goals will be achieved.
• Scope identifies the primary data, functions, and behaviors that characterize the
product, and more important, attempts to bound these characteristics in a
quantitative manner.
• Once the product objectives and scope are understood, alternative solutions are
considered.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 7

The Process
• A software process provides the framework from which a comprehensive plan for
software development can be established.
• A small number of framework activities are applicable to all software projects,
regardless of their size or complexity.
• 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.
• Finally, umbrella activities —such as software quality assurance, software
configuration management, and measurement—overlay the process model.
• Umbrella activities are independent of any one framework activity and occur
throughout the process.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 8
Project
• The project includes all and everything of the total development
process and to avoid project failure.

• 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 commonsense approach
for planning, monitoring, and controlling the project.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 9
Size estimation metrics in Software Engineering
• Accurate estimation of the problem size is fundamental to satisfactory
estimation of effort, time duration and cost of a software project.
• The size of a problem is obviously not the number of bytes that the
source code occupies. It is neither the byte size of the executable
code.
• 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). The usage of each of
these metrics in project size estimation has its own advantages and
disadvantages.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 10
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Lines of Code (LOC)
• LOC is the simplest among all metrics available to estimate project
size.
• Using this metric, the project size is estimated by counting the
number of source instructions in the developed program.
• While counting the number of source instructions, lines used for
commenting the code and the blank lines should be ignored.
The units of LOC are-
• KLOC- Thousand lines of code
• NLOC- Non comment lines of code
• KDSI- Thousands of delivered source instruction

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 11

Example

for(i=0;i<50;i++) printf (“LOC”);//Number of LOC

From the above example we have

• 1 physical lines of code.
• 2 logical line of code (printf statement and for statement)
• 1 comment line

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 12

The same code can be written in a different style

for(i=0;i<50;i++)
{
printf (“LOC”);
}
//Number of LOC
There are
• 5 physical line of code.
• 2 logical line of code
• 1 comment line.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 13

Advantages of LOC
• Universally accepted and is used in many models like COCOMO.
• Estimation is closer to developer’s perspective.
• Simple to use.

Disadvantages of LOC
• There is no definite clear picture of how to count number of lines because the
length and complexity of the code is different in different languages.
• It only depends on the length but not on complexity and functionality.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 14

Function Point (FP)
• Function point metric was proposed by Albrecht [1983]. This metric
overcomes many of the shortcomings of the LOC metric.

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

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 15

The steps in function point analysis

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

2. Compute the Unadjusted Function Points(UFP).

3. Find Total Degree of Influence(TDI).

4. Compute Value Adjustment Factor(VAF).

5. Find the Function Point Count(FPC).

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 16

Count the number of functions of each proposed type.

• Function points are derived from countable (direct) measures of software’s

information domain and qualitative assessments of software complexity.

• Information domain values (or the number of functions)are defined in the

following manner:

• External Inputs(EI): Functions related to data entering the system.

• Ex. In library database system, enter an existing student’s library card number.

• External outputs(EO) : Functions related to data exiting the system.

• Ex. In library database system, display a list of books checked out to a student.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 17

 Count the number of functions of each proposed type.

• External Inquiries(EQ): They leads to data retrieval from system but don’t change the system.

• Ex. In library database system, determine what books are currently checked out to a
student.

• Internal Logical Files(ILF): Logical files maintained within the system. Log files are not included here.

•Ex. library database system, the file of books in the library.

• External interface Files(EIF): These are logical files from other applications which are used by
our system.

• Ex.In Library database system, the file that contains transactions in the library's billing
system.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 18

Count the number of functions of each proposed type

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 Logical files (ILF) Databases and directories

Shared databases and
5. Number of external interfaces (EIF)
shared routines.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 19

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:

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 20

 Compute the Unadjusted Function Points(UFP)

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 21

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 22
Find Total Degree of Influence(TDI)

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

• Each characteristics is evaluated on a scale of 0-5.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 23

The 14 general characteristics are

1. Data Communication 9.Complex Processing

2. Distributed Data Processing 10. Reusability
3. Performance 11. Installation Ease
4. Heavily Used Configuration 12. Operational Ease
5. Transaction Role 13. Multiple Sites
6. Online Data Entry 14. Facilitate Change
7. End-User Efficiency
8. Online Update

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 24

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 25
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

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 26

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 27
CONVERTING FP TO LOC
• FP is multiplied by productivity factor of programming language.

LOC= FP X Productivity factor

• Productivity factor – No. of logical code statement per function point.

It varies among programming language.

• For ex. For java it is 53

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 28

Example
Compute the function point for the following data (consider average
weighting factor)
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
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2,
4, 5.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 29

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)]
= 412 * [0.65 + 0.01 * 43]
= 412 * [0.65 + 0.43]
= 412 * 1.08
= 444.96 = 445
So FP= 445

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 30

COCOMO MODEL
Constructive Cost Model
• COCOMO (Constructive Cost Model) is developed by Barry Bohm .
• It is a procedural cost estimate model for software projects based on LOC, i.e
number of Lines of Code.
• Estimate the total effort in terms of “person-month”.
• Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.
• E.g. effort= 100PM means 1 person 100 months or 100 person in 1 month or 50
person in 2 months.
• 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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 32

Boehm’s definition of Three types of systems
Organic –
• Team size required is adequately small.
• Problem is well understood and has been solved in the past.
• Team members have a nominal experience regarding the problem.
Examples - simple business systems, simple inventory management systems, and data processing
systems.

Semi-detached –
• Team size required is medium.
• The projects comparatively less familiar and difficult to develop compared to the organic ones.
• require more experience and better guidance and creativity.
Example- developing a new operating system (OS), a Database Management System (DBMS), and
complex inventory management system.

Embedded –
•requires a larger team size than the other two models.
•the highest level of complexity, creativity, and experience requirement.
•the developers need to be sufficiently experienced and creative to develop such complex models.
Example - ATM, Air Traffic control.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 33

 Types of systems
Development Project Characteristics
Mode
Size Innovation Deadline/Constraints Development
Environment
Organic Small Little Not Tight Stable

Semidetached Medium Medium Medium Medium

Embedded Large Greater Tight Complex

Hardware

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 34

Types of COCOMO Models

These are types of COCOMO model:

• Basic COCOMO Model

• Intermediate COCOMO Model

• Detailed COCOMO Model

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 35

Basic COCOMO
• This model can be used for quick and slightly rough calculations of Software Costs. Its
accuracy is somewhat restricted due to the absence of sufficient factor considerations.

Intermediate Model
• The basic COCOMO model assumes that the effort is only a function of the number of
lines of code and some constants evaluated according to the different software system.
• However, in reality, no system’s effort and schedule can be solely calculated on the basis
of Lines of Code. For that, various other factors such as reliability, experience,
Capability are also important.
• These factors are known as Cost Drivers and the Intermediate Model utilizes 15 such
drivers for cost estimation.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 36
Detailed Model
Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact on
each step of the software engineering process.
• The detailed model uses different effort multipliers for each cost driver
attribute.

• In detailed COCOMO, the whole software is divided into different modules

and then we apply COCOMO in different modules to estimate effort and then
sum the effort.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 37

 Basic COCOMO
• The first level, Basic COCOMO can be used for quick and slightly rough
calculations of Software Costs.
• Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations.
• Estimation of Effort and Development Time :
E = a (KLOC)b
Tdev = 2.5 (E)d
a,b,and d are constants.
E - The effort is measured in Person-Months.
KLOC - Kilo lines of code.
Tdev - time required for development in months.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 38

 Basic COCOMO

Software
Projects a b d
Organic 2.4 1.05 0.38
Semi
Detached 3.0 1.12 0.35

Embedded 3.6 1.20 0.32

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 39

 Basic COCOMO
Person Estimation OR Staff Size

N = E/Tdev
N - Number of persons required
Productivity = KLOC/E
Productivity is measured as KLOC/month

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 40

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

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 41

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

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 42

 Example

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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 43

 Solution
(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

TDEV = 2.5 * (1295.31)0.38 = 38.07 M

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM

TDEV = 2.5 * (2462.79)0.35=38.45 M

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

TDEV = 2.5 * (4772.8)0.32 = 38 M
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 44
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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 45

 Solution
The semidetached mode is the most appropriate mode, keeping in view the size,
schedule and experience of development time.

Effort E = 3.0(200)1.12=1133.12PM
Development time Tdev = 2.5(1133.12)0.35=29.3 M
Staff Size = E/ Tdev
= 1133.12/29.3= 38.67 persons
Productivity = KLOC/E
= 200/1133.12
= 0.1765 KLOC/MONTH
= 176 LOC/MONTH

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 46

 Intermediate COCOMO
Classification of Cost Drivers and their attributes
(i) Product attributes –
•Required software reliability extent
•Size of the application database
•The complexity of the product
(ii) Hardware attributes –
•Run-time performance constraints
•Memory constraints
•The volatility of the virtual machine environment
•Required turnabout time

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 47

Classification of Cost Drivers and their attributes
(iii) Personnel attributes –
•Analyst capability
•Software engineering capability
•Applications experience
•Virtual machine experience
•Programming language experience
(iv) Project attributes –
•Use of software tools
•Application of software engineering methods
•Required development schedule

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 48

 Cost Drivers Very Low Low Nominal High Very High
Product Attributes
Required Software
Reliability 0.75 0.88 1.00 1.15 1.40
Size of Application
Database 0.94 1.00 1.08 1.16
Complexity of The Product 0.70 0.85 1.00 1.15 1.30
Hardware Attributes
Runtime Performance
Constraints 1.00 1.11 1.30
Memory Constraints 1.00 1.06 1.21
Volatility of the virtual
machine environment 0.87 1.00 1.15 1.30
Required turnabout time 0.94 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer
capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language
experience 1.14 1.07 1.00 0.95
Project Attributes
Application of software
engineering methods 1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development
schedule 1.23 1.08 1.00 1.04 1.10
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 49
Intermediate COCOMO

• The project manager is to rate these 15 different parameters for a

particular project on a scale of one to three. Then, depending on
these ratings, appropriate cost driver values are taken from the above
table. These 15 values are then multiplied to calculate the EAF (Effort
Adjustment Factor). The Intermediate COCOMO formula now takes
the form:
E= (a (KLOC) b )*EAF

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 50

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

• It is the model that allows one to estimate the cost, effort and
schedule when planning a new software development activity.
It consists of four stages:

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 52

• Application Composition Model - This model is used for the prototyping stage
of application generator and system integration.
• Early Design Stage Model - This model is used when requirements have been
stabilized and the basic architecture has been established.
• Post Architecture Stage Model - This model is used after the completion of
the detailed architecture of application generator, infrastructure, system
integration.
• Reuse Model – This model is used to compute the effort required to integrate
reusable components.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 53

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 54
Application Composition Estimation Model
• Allows to estimate the cost, effort at the stage 1 of the COCOMO II
Model.

Following steps are taken to estimate effort to develop a project

• Step-1: Access Object counts

Estimate the number of screens, reports and 3GL components that
will comprise this application.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 55

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 56
• Step-2: Classify complexity levels of each object
We have to classify each object instance into simple, medium and difficult
complexity level depending on values of its characteristics.
Complexity levels are assigned according to the given table

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 57

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 58
• Step-3: Assign complexity weights to each object
The weights are used for three object types i.e, screens, reports and
3GL components. Complexity weight are assigned according to
object’s complexity level using following table.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 59

 • Step-4: Determine Object Points
Add all the weighted object instances to get one number and this is known
.
as object point count
Object Point = ∑ (number of object instances) * (Complexity weight of each
object instance)
• Step-5: Compute New Object Points (NOP)
We have to estimate the %reuse to be achieved in a project.
Depending on %reuse

NOP = [(object points) * (100 - %reuse)]/100

• NOP are the object point that will need to be developed and differ from the
object point count because there may be reuse of some object instance in
project.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 60
• Step-6: Calculate Productivity rate (PROD)
Productivity rate is calculated on the basis of information given about
developer’s experience and capability.
For calculating it, we use following table

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 61

• Step-7: Compute the estimated Effort
Effort to develop a project can be calculated as

Effort = NOP/PROD

Effort is measured in person-month.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 62

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 63
Example:
Consider a database application project with
• The application has four screens with four views each and seven data tables for
three servers and four clients.
• Application may generate two reports of six section each from seven data tables for
two servers and three clients.
• 10% reuse of object points.
Developer’s experience and capability in similar environment is low.
Calculate the object point count, New object point and effort to develop such project.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 64

• Step-1:
Number of screens = 4
Number of reports = 2
• Step-2:
For screens,
Number of views = 4
Number of data tables = 7
Number of servers = 3
Number of clients = 4
by using above given information and table (For Screens),
Complexity level for each screen = medium
• For reports,
Number of sections = 6
Number of data tables = 7
Number of servers = 2
Number of clients = 3
by using above given information and table (For Reports),
Complexity level for each report = difficult

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 65

• Step-3:
By using complexity weight table we can assign complexity weight to each
object instance depending upon their complexity level.
Complexity weight for each screen = 2
Complexity weight for each report = 8
• Step-4:
Object point count = ∑[(Number of object instances) * (its Complexity weight) ]
= (4 * 2) + (2 * 8)
= 24
• Step-5:
%reuse of object points = 10% (given)
NOP = [object points * (100 - %reuse)]/100
= [24 * (100 -10)]/100 = 21.6

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 66

• Step-6:
Developer’s experience and capability is low (given)
Using information given about developer and productivity rate table
Productivity rate (PROD) of given project = 7
• Step-7:
Effort = NOP/PROD
= 21.6/7
= 3.086 person-month
Therefore, effort to develop the given project = 3.086 person-month.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 67

Cost Estimation Models in Software Engineering
• Cost estimation simply means a technique that is used to find out the cost
estimates. The cost estimate is the financial spend that is done on the
efforts to develop and test software in Software Engineering.

• Cost estimation models are some mathematical algorithms or parametric

equations that are used to estimate the cost of a product or a project.

• Various techniques or models are available for cost estimation, also known
as Cost Estimation Models as shown below :

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 68

 Expert
Delphi
Judgement

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 69

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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 70

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.

• However, this technique is subject to human errors and individual bias.

• 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.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 71
Expert Judgment Technique
• 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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 72

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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 73

Delphi Cost 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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 74

Delphi Cost Estimation Process

Estimator 1 ESTIMATE

ESTIMATE
Estimator 2
Iterated
Coordinator

ESTIMATE
Estimator n

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 75

Heuristic Estimation Technique
• As techniques basically uses the concept of learning from the
previous project and estimate the cost.
• Although intuitively very similar to expertise based techniques,
heuristic estimation technique take a different angle.
• 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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 76

Heuristic Estimation Technique
Two classes of different heuristic Estimation Techniques:
- single variable model
- multi variable model
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.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 77

Heuristic Estimation Technique
Multivariable Cost Estimation Model:
It has the following form
Estimated Resources = c1*e1d1 + c2*e1d1 + ----
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.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 78
Analytical estimation technique
• 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 is especially useful for estimating software

maintenance efforts.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 79

Halstead's Software Metrics
• Halstead’s software science is an analytical technique to measure size,
development effort, and development cost of software products.
• 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.“
• By counting the tokens and determining which are operators and which are
operands, the following base measures can be collected :

n1 = Number of distinct operators.

n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 80
Halstead metrics
• Halstead Program Length – The total number of operator occurrences and
the total number of operand occurrences.
N = N1 + N2

And estimated program length is,

N^ = n1 log2n1 + n2 log2n2

• Halstead Vocabulary – The total number of unique operator and unique

operand occurrences.
n = n1 + n2

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 81

Halstead metrics
• Program Volume(V) – Proportional to program size, represents the size,
in bits, of space necessary for storing the program. This parameter is
dependent on specific algorithm implementation. The properties V, N, and
the number of lines in the code are shown to be linearly connected and
equally valid for measuring relative program size.
V = Size * (log2 vocabulary)
= N * log2(n)
The unit of measurement of volume is the common unit for size “bits”. It is
the actual size of a program if a uniform binary encoding for the vocabulary
is used. And error = Volume / 3000

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 82

Halstead metrics
• Program Difficulty(D) – This parameter shows how difficult to handle
the program is.
D = (n1 / 2) * (N2 / n2)
D=1/L
As the volume of the implementation of a program increases, the
program level decreases and the difficulty increases.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 83

Halstead metrics
• Programming Effort (E) – Measures the amount of mental activity needed to translate
the existing algorithm into implementation in the specified program language.
E=V/L
=D*V
= Difficulty * Volume

• Language Level (L) – 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

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 84

Halstead metrics
• Intelligence Content (I) – Determines the amount of intelligence
presented (stated) in the program.This parameter provides a measurement
of program complexity, independently of the program language in which it
was implemented.
I=V/D
• Programming Time (T) – Shows time (in minutes) needed to translate
the existing algorithm into implementation in the specified program
language.
T = E / (f * S) i.e. T=E/18
• No of Delivered bugs = (E 2/3)/3000

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 85

Analytical estimation technique
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, avg, 3, “%d %d %d”, “avg = %d”

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 86

 Example Distinct
Operator
Total No
.of
Distinct
Operands
Total No
.of
(n1) Operators (n1) Operands
main 1 a 3
main( ) () 4 b 3
{ {} 1 c 3
int 1 avg 3
int a, b, c, avg;
scanf 1 “%d %d %d” 1
scanf(“%d %d %d”, &a, &b, &c); & 3 3 1
avg = (a+b+c)/3; = 1 “avg = %d” 1
printf(“avg = %d”, avg); + 2
/ 1
}
printf 1
, 7
; 4
n1=12 N1=27 n2=7 N2=15

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 87

Analytical estimation technique
n1 = 12, n2 =7,
n = n1 + n2 = 12 + 7 = 19
N1= 27,N2=15
N = N1 + N2 = 27 + 15 = 42
Estimated Length = n1log2n1 + n2log2n2
=(12*log212 + 7*log27)
= (12*3.584+ 7*2.807) = (43.008+19.649) =62.657
Volume V = N*log2(n) = 42*log2(19) = 42*4.25 =178.5
Difficulty D = (n1/2)*(N2/n2) = (12/2)*(15/7) = 12.85
Effort E = D*V = 12.85*178.5 = 2293.72
Time Required T = E/18 = 2293.72/18 = 127.42
No.of Delivered Bugs = (E 2/3)/3000 = 2293.722/3 /3000 = 0.057

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 88

Risk Management
 Risk Management
- Introduction
- Characteristics of risk
- Types of Risks
- Risk identification
- Assessing Project Risk
- Risk projection (estimation)
- Risk mitigation, monitoring, and
management
- Risk containment

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 90

 Risk
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 91

 What Is Software Risk?
• Risk is an expectation of loss, a potential problem that may or may
not occur in the future.

• It is generally caused due to lack of information, control or time.

• A possibility of suffering from loss in software development process

is called a software risk.

• Loss can be anything, increase in production cost, development of

poor quality software, not being able to complete the project on
time.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 92

Characteristics of risk

• Two characteristics of risk

• Uncertainty – the risk may or may not happen, that is, there are no 100%
risks (those, instead, are called constraints).

• Loss – the risk becomes a reality and unwanted consequences or losses occur.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 93

Risk Categorization – Approach #1
• Project risks
• They threaten the project plan.
• If they become real, it is likely that the project schedule will slip and that costs
will increase.

• Technical risks
• They threaten the quality and timeliness of the software to be produced.
• If they become real, implementation may become difficult or impossible.

• Business risks
• They threaten the viability of the software to be built.
• If they become real, they jeopardize the project or the product.
28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 94
Risk Categorization – Approach #1 (continued)
• Sub-categories of Business risks

• Market risk – building an excellent product or system that no one really wants.

• Strategic risk – building a product that no longer fits into the overall business
strategy for the company.

• Sales risk – building a product that the sales force doesn't understand how to sell.

• Management risk – losing the support of senior management due to a change in

focus or a change in people.

• Budget risk – losing budgetary or personnel commitment.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 95

Risk Categorization – Approach #2
• Known risks
• Those risks that can be uncovered after careful evaluation of the project plan, the business
and technical environment in which the project is being developed, and other reliable
information sources (e.g., unrealistic delivery date)

• Predictable risks
• Those risks that are extrapolated from past project experience (e.g., past turnover)

• Unpredictable risks
• Those risks that can and do occur, but are extremely difficult to identify in advance

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 96

Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
• "Don't worry, I'll think of something"
• The majority of software teams and managers rely on this approach
• Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem rapidly (fire
fighting)

• Proactive risk strategies

• Steps for risk management are followed
• Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 97

Steps for Risk Management

Identify possible risks; recognize what can go wrong

Analyze each risk to estimate the probability that it

will occur and the impact (i.e., damage) that it will
do if it does occur

Rank the risks by probability and impact

- Impact may be negligible, marginal, critical, and
catastrophic

Develop a contingency plan to manage those risks

having high probability and high impact

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 98

Risk Identification
Risk Identification
• Risk identification is a systematic attempt to specify threats to the project plan

• By identifying known and predictable risks, the project manager takes a first step toward avoiding
them when possible and controlling them when necessary

• Generic risks

• Risks that are a potential threat to every software project

• Product-specific risks
• Risks that can be identified only by those a with a clear understanding of the technology, the
people, and the environment that is specific to the software that is to be built
• This requires examination of the project plan and the statement of scope.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 100

 Known and Predictable Risk Categories
1-Product size risks associated with overall size of the software to be built

2-Business impact risks associated with constraints imposed by management or the

marketplace
3-Customer risks associated with sophistication of the customer and the developer's ability to
characteristics communicate with the customer in a timely manner
4-Process risks associated with the degree to which the software process has been
definition defined and is followed
5-Development risks associated with availability and quality of the tools to be used to build
environment the project
6-Technology to be risks associated with complexity of the system to be built and the
built "newness" of the technology in the system
7-Staff size and risks associated with overall technical and project experience of the
experience software engineers who will do the work

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 101

Assessing Overall Project Risk
1) Have top software and customer managers formally committed to
support the project?
2) Are end-users enthusiastically committed to the project and the
system/product to be built?
3) Are requirements fully understood by the software engineering
team and its customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 102

Assessing Overall Project Risk
7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be
implemented?
10) Is the number of people on the project team adequate to do the
job?
11) Do all customer/user constituencies agree on the importance of
the project and on the requirements for the system/product to be
built?

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 103

Risk Components and Drivers
• The project manager identifies the risk drivers that affect the following risk
components
• Performance risk - the degree of uncertainty that the product will meet its requirements and
be fit for its intended use.
• Cost risk - the degree of uncertainty that the project budget will be maintained.
• Support risk - the degree of uncertainty that the resultant software will be easy to Correct,
adapt, and enhance.
• Schedule risk - the degree of uncertainty that the project schedule will be maintained and
that the product will be delivered on time.
• The impact of each risk driver on the risk component is divided into one of four
impact levels
• Negligible, marginal, critical, and catastrophic

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 104

Risk Projection (Estimation)
Risk Projection
• Risk projection (or estimation) attempts to rate each risk in two
ways
• The probability that the risk is real.
• The consequence of the problems associated with the risk, should
it occur.
• The project planner, managers, and technical staff perform four risk
projection steps.
• The intent of these steps is to consider risks in a manner that leads to
prioritization.
• By prioritizing risks, the software team can allocate limited resources
where they will have the most impact.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 106

Risk Projection/Estimation Steps
1) Establish a scale that reflects the perceived likelihood of a risk (e.g.,
1-low, 10-high)

2) Delineate the consequences of the risk.

3) Estimate the impact of the risk on the project and product.

4) Note the overall accuracy of the risk projection so that there will be
no misunderstandings.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 107

Developing a Risk Table
• List all risks in the first column (by way of the help of the risk item checklists).

• Mark the category of each risk.

• Estimate the probability of each risk occurring.

• Assess the impact of each risk based on an averaging of the four risk components
to determine an overall impact value.

• Sort the rows by probability and impact in descending order.

• Draw a horizontal cutoff line in the table that indicates the risks that will be given
further attention.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 108

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 109
Risk Mitigation, Monitoring,
and Management
(RMMM)
RMMM
• An effective strategy for dealing with risk must consider three issues.

Risk mitigation (i.e., avoidance)

Risk monitoring
Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is achieved through
a plan

• Example: Risk of high staff turnover

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 111
Risk mitigation (avoidance)
To mitigate the risk, project management must develop a strategy for Reducing Staff Turnover
• Meet with current staff to determine causes for turnover (e.g., poor working conditions, low
pay, competitive job market)
• Mitigate those causes that are under our control before the project starts.
• Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave.
• Organize project teams so that information about each development activity is widely
dispersed.
• Define documentation standards and establish mechanisms to ensure that documents are
developed in a timely manner.
• Conduct peer reviews of all work (so that more than one person is "up to speed").
• Assign a backup staff member for every critical technologist.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 112

Risk Monitoring
• During risk monitoring, the project manager monitors factors that may provide an
indication of whether a risk is becoming more or less likely.

• In case of high staff turnover, following factors can be monitored.

• General attitude of team members based on project pressure.
• The degree to which team is ready to jelled(to cooperate).
• Interpersonal relationship among team members.
• Potential problems with compensation and benefits.
• The availability of jobs within the company and outside it.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 113

Risk Management
• Risk management and contingency planning assume that mitigation efforts have
failed and that the risk has become a reality.

• Those individuals who are leaving are asked to stop all work and spend their
last weeks in knowledge transfer mode.

• This might include video based knowledge capture, the development of

complementary documents, or meeting with other team members who will
remain on the project.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 114

The RMMM Plan
• RMMM plan documents all work performed as part of risk analysis
and is used by project manager as part of the overall project plan.

• Once RMMM has been documented and the project has begun, the
risk mitigation, and monitoring steps begin
• Risk mitigation is a problem avoidance activity.

• Risk monitoring is a project tracking activity.

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 115

Risk Containment
• Risk containment means risk reduction.
• The project manager and the team identifies strategies to minimize
or eliminate the risk factors.
Strategies to plan for risk containment
• Avoid the risk (change the requirement to reduce scope of the work,
giving incentives to engineers to avoid risk of manpower turnover)
• Transfer the risk (getting the risky components developed by third
party)
• Risk reduction (planning way to manage the damage due to risk. In
case of staff turnover, new recruitment may be planned)

28/05/2021 S.A.Sarwade, Lecturer in IT, G.P.Jalgaon 116

Thank You!