Estimation techniques

Estimation techniques

 Organizations need to make software effort and cost estimates.

 There are two types of technique that can be used to do this:
1. Experience-based techniques
• The estimate of future effort requirements is based on the manager’s
experience of past projects and the application domain.
• Essentially, the manager makes a judgment of what the effort
requirements are likely to be.
2. Algorithmic cost modeling
• In this approach, a formulaic approach is used to compute the project
effort based on estimates of product attributes, such as size, and
process characteristics, such as experience of staff involved.
Estimate uncertainty
 Problem with experience-based approaches

 The difficulty with experience-based techniques is that a new software project

may not have much in common/similar with previous projects.
 Software development changes very quickly and a project will often use
unfamiliar techniques such as web services, application system configuration
or HTML5.
 If you have not worked/experienced on these techniques, your previous
experiences may not help you to estimate the effort required, making it more
difficult to produce accurate costs and schedule estimations.
Algorithmic cost modelling

 Cost is estimated as a mathematical function of (1) product, (2) project and

(3) process attributes whose values are estimated by project managers:
 Effort = A x KLOCB x EAF (formulas are given in next slides!)
 For example, most commonly used product attribute for cost
estimation is code size.
 Most models are similar but they use different coefficient values.
Estimation accuracy

 The size of a software system can only be known accurately when it is

finished.
 Several factors affect the final size:
 Use of reused systems and components;
 Programming language;
 Distribution of system.
 As the development stage progresses then the size estimate becomes more
accurate/clear.
 Effectiveness of algorithmic models

 Algorithmic cost models are systematic ways to estimate the effort required
to develop a system.
 However, these models are complex and difficult to use.
 There are many attributes and considerable scope for uncertainty in
estimating their values.
An algorithmic model is:

• B.W. Boehm introduced COCOMO model in his book “Software Engineering

Economics in 1981”
• COCOMO is an approach applied for cost estimation of software projects
• COCOMO has three sub models: basic , intermediate and detailed
• COCOMO 2 considers different approaches to software development,
reuse, etc.
• COCOMO is an empirical/experimental model based on project experience.
• Well-documented, ‘independent’ model which is not tied to a specific
software vendor.
COCOMO estimation models
Comparison
of three
COCOMO
modes
Basic Model
• The basic model aims at estimating most of the small to medium sized software
projects, in a quick and rough fashion.
• Three modes are considered in this model:
• Organic: A small team + experienced developers develops software in a very
familiar environment.
• Semidetached: It is an intermediate mode between the organic model and
embedded mode.
• Embedded: The project has hard constraints + large team.
• Depending on the problem, the team may include a mixture of experienced and less
experienced people.
 Basic
COCOMO
Equations
Example
• Suppose that a SW project was estimated to be 400 KLOC. Calculate the
effort and development time for each of the three modes i.e. organic,
semidetached and embedded.
Intermediate Model
• In this model, Boehm introduced an additional set of 15 predictors
called cost drivers.
• The model considers the software development environment.
• Cost drivers are used to adjust the estimated cost of a project
according to the actual project environment which increase the
accuracy of the estimate.
The cost drivers are grouped into 4 categories:
1. Product attributes
a. Required software reliability (RELY)
b. Database size (DATA)
c. Product complexity (CPLX)

2. Computer attributes
a. Execution time constraint (TIME)
b. Main store constraint (STOR)
c. Virtual machine volatility (VIRT)
d. Computer turnaround time (TURN)
The cost drivers are grouped into 4 categories:
3. Personnel attributes
a. System Analyst capability (ACAP)
b. Application experience (AEXP)
c. Programmer capability (PCAP)
d. Virtual machine experience (VEXP)
e. Programming Language experience (LEXP)

4. Project attributes
a. Morden programming practices (MODP)
b. Use of software tool (TOOL)
c. Required development schedule (SCED)
Ratings of the cost drivers
• Each cost driver is rated for a given project environment.
• The rating uses a scale; very low, low, nominal, high, very high, extra
high
which describes to what extent the cost driver applies to the project
being estimated.
Intermediate
Model
Equations
 Example
of
Intermediate
Model
COCOMO
Detailed COCOMO Model
• A large amount of research is done by Boehm to define all significant aspects
of a software development.
• This model is a tool for processing all the project characteristics to perform a
software estimation.
Phase-Sensitive Effort Multipliers
• Some phases (design, programming, integration/test) are more affected
than other stages by factors defined in the cost drivers.
• This model helps in determining the man power allocation (MM) of each
phase for the project.

Three-Level Product Hierarchy

• Three product levels are defined.
• These levels are modules, subsystems and system levels.
• The rating of the cost drivers are done at appropriate level; namely, the level at
which it is most sensitive to variation.
 Development Phase
A software development is performed in four successive phases:

1. Planning/requirements:
• This is the first phase of the development cycle.
• The requirement is analyzed, the product plan is set up and a full
product specification is generated.
• This phase consumes from 6% to 8% of the effort and can take 10% to
40% of the total time required.

2. Product Design:
• The second phase of the COCOMO development cycle is concerned with
the determination of the architecture and the specification of the
subsystems.
• This phase requires from 16% to 18% of the effort and can take the 19%
to 38% of total time required.
Development Phase
3. Programming/Module Code-Test:
• The third phase of the COCOMO development cycle is divided into two
sub phases: detailed design and module code/unit test.
• This phase requires from 48% to 68% of the effort and can take 24%
to 64% of total time required.

4. Integration/test :
• This phase of the COCOMO development cycle occurs before delivery.
• This mainly consist of putting the tested parts together and then
testing the final product.
• This phase requires from 16% to 34% of the effort and can take from
18% to 34% of total time required.
 Detailed COCOMO

Effort and
Schedule
ratings for
each phase of
SDLC
Advanced
COCOMO
Equations
SOLUTION
CONTINUE
If you don’t know KLOC?
COCOMO estimation models
 Cost Estimation Process based on
Functional Point

Effort
Size Table
Development Time
Lines of Code
Estimation Process
Number of Use Case Number of Personnel

Function Point Errors

FUNCTION POINTS (FP) Estimation

• If you can estimate some features about your

project at the beginning such as input / output,
then you can define a function points (FP) number
for the system to be developed.
• After that you can convert it to KLOC.
• After defining KLOC Effort, Duration, Person
 Function Points
• STEP 1: measure size in terms of the amount of functionality in a system.
• FPs are computed by first calculating an Unadjusted Function Point (UFP).
 Unadjusted Function Point (UFP)
• Counts are made for the following categories:
1-External inputs – those items provided by the user that describe distinct application-
oriented data (such as file names and menu selections, any function requiring input
from user)
2-External outputs – those items provided to the user that generate distinct
application-oriented data (such as any produced reports and messages to users, any
screen outputs to users)
3- External inquiries – interactive inputs requiring a response (SELECT* queries, just
reading data from DB, data change like insert, delete, update.)
4- External files – machine-readable interfaces to other systems. It refers to sharing
with another application system.
5- Internal files – logical master files in the system (user data, stored data, tables..)
 Unadjusted Function Point (UFP)
• STEP 2: Multiply each number by a weight factor, according to complexity (simple,
average or complex) of the parameter, associated with that number. The value is given
by a table:

This table will give you a total Unadjusted Function Points (UFP) value
Unadjusted Function Point (UFP)
• STEP 3: Calculate the total UFP (Unadjusted Function Points)
• STEP 4: Calculate the total TCF (Technical Complexity Factor)

TCF=0.65+0.01*DI
• To calculate TCF, you have to calculate DI first from the
following points given.
•
Summarizes the complexity characteristics of the software system – assign grades (0 to 5) to
the 14 subjects that significantly affect the effort:

Technical Complexity Factors:

• 1. Data Communication

Importance of Factors
• 2. Distributed Data Processing
• 3. Performance Criteria
Each is a value
• 4. Heavily Utilized Hardware between 0 and 5
• 5. High Transaction Rates 0: No influence
• 6. Online Data Entry 1: Incidental
• 7. Online Updating 2: Moderate
• 8. End-user Efficiency 3: Average
• 9. Complex Computations 4: Significant
• 10. Reusability 5. Essential
• 11. Ease of Installation
• 12. Ease of Operation
• 13. Portability
• 14. Maintainability
Function Points(.....)
• STEP 5: Sum the resulting numbers to obtain DI (degree of influence)
• STEP 6: TCF (Technical Complexity Factor) by given by the formula
TCF=0.65+0.01*DI
• STEP 7: Function Points can be calculated by the formula
FP=UFP*TCF
or,
FP=UFP*[0.65+0.01*DI]
TCF
COCOMO EXAMPLE
EXAMPLE: Compute the FP for a SW project with the following information domain characteristics?
 Number of user inputs: 30 (Simple)
 Number of user outputs: 60 (Avg) ∑(Fi)Assume that all
 Number of user inquiries: 24 (Complex) complexity adjustment values
 Number of files: 8 (Avg) are “AVERAGE”.
 Number of external interfaces: 2 (Avg) FP=UFP*[0.65+0.01*DI]

UFP
 Complexity Factors ∑(Fi)Assume that all
complexity
• Technical Complexity Factors: adjustment values are
• 1. Data Communication “AVERAGE”.
• 2. Distributed Data Processing
• 3. Performance Criteria
• 4. Heavily Utilized Hardware
• 5. High Transaction Rates
• 6. Online Data Entry Each is a value between 0 and 5
• 7. Online Updating
•
•
8.
9.
End-user Efficiency
Complex Computations
0: No influence
• 10. Reusability 1: Incidental
•
•
11.
12.
Ease of Installation
Ease of Operation 2: Moderate
•
•
13.
14.
Portability
Maintainability
3: Average
DI=3x14=42 4: Significant
5. Essential
FP=UFP*[0.65+0.01*DI]
 AFTER FINDING FP
YOU NEED TO CONVERT IT TO KLOC
 Conversion FP <-> KLOC

KLOC=FP x Language Ratio

Calculate the KLOC according to the computed FP function point for the project
Assume that Java is the programming language for the project.

Conversion FP <-> KLOC

ANSWER:

KLOC = 671x53
= 35563 LOC
= 35.5 KLOC
Assume that Intermediate COCOMO
Model is used…
Calculate Unadjusted Effort values EO, ES, and EE, according to INTERMEDIATE MODEL?

KLOC=35.5
Organic mode (EO = 3.2 * 35.51.05)= 136 PM
Semi-detached mode (ES = 3.0 * 35.51.12)= 163 PM
Embedded mode (EE = 2.8 * 35.51.20)= 202 PM

EAF=?
Calculate the EAF value according to the following cost-drivers:
ATTRIBUTE RATING

Realiability V high
Complexity V high
Memory Constarints V high
Tool Use Low
Schedule V Low
Cost Driver Very Low Nominal High Very Extra
Low High High
Required Reliability .75 .88 1.00 1.15 1.40 1.40

Database Size .94 .94 1.00 1.08 1.16 1.16

Product Complexity .70 .85 1.00 1.15 1.30 1.65

EAF
Execution Time Constraint 1.00 1.00 1.00 1.11 1.30 1.66

Main Storage Constraint 1.00 1.00 1.00 1.06 1.21 1.56

Virtual Machine Volatility .87 .87 1.00 1.15 1.30 1.30

Comp Turn Around Time .87 .87 1.00 1.07 1.15 1.15

Analyst Capability 1.46 1.19 1.00 .86 .71 .71

Application Experience 1.29 1.13 1.00 .91 .82 .82

Programmers Capability 1.42 1.17 1.00 .86 .70 .70

Virtual machine Experience 1.21 1.10 1.00 .90 .90 .90

Language Experience 1.14 1.07 1.00 .95 .95 .95

Modern Prog Practices 1.24 1.10 1.00 .91 .82 .82

SW Tools 1.24 1.10 1.00 .91 .83 .83

Required Dev Schedule 1.23 1.08 1.00 1.04 1.10 1,10

Calculate the development time D for each EO, ES, and EE.
Calculate SS and Productivity of team?

SSo=401/24=16.7 Man
SSs=480/21.7= 22.1 Man
SSE=596/19.3=30.8 Man

Po= 35.5 KLOC/401 PM= 0.08

Ps= 35.5 KLOC /480 PM= 0.073
PE= 35.5 KLOC /596 PM=0.059