This document discusses various techniques for estimating effort for software projects. It describes common challenges with software estimation like subjective nature and changing requirements. It then explains different estimation techniques like algorithmic models, expert judgment, analogy, top-down and bottom-up approaches. Specifically, it outlines the function point analysis technique and COCOMO model for estimating effort based on source lines of code and complexity factors. Finally, it lists some typical rules of thumb for software estimation from Capers Jones.
5. Where are estimates done?
Estimates are carried out at various stages of
software project.
Strategic Planning
Decide priority to each project.
Feasibility Study
Benefits of potential system
System Specification
Detailed requirement analysis at design stage.
Evaluation of Suppliers Proposals
Tender Management
Project Planning
Detailed estimates of smaller work components during
implementation.
6. Software Effort Estimation
Techniques
Algorithmic Models
Expert Judgment
Analogy – Similar Completed Project
Parkinson – Staff Effort available to do project
Price to Win – Sufficiently low to win a contract.
Top-down – Overall estimate is formulated
Bottom-up – Individual components are
aggregated
7. Bottom-up Estimating
Work Breakdown Structure
Assumptions about characteristics of final
system
Number and Size of software modules.
Appropriate at detailed stages of project
planning.
When a project is completely novel or no
historical data available.
8. Top-down Approach and
Parametric Models
Effort = (system size ) * (productivity rate)
System size in the form of KLOC
Productivity rate 40 days per KLOC
Software module to be constructed is 2 KLOC
Effort = 2 * 80 = 160 days
Note:
KLOC- Thousands of Lines of Code
9. Expert Judgment
Asking for estimate of task effort from
someone who is knowledgeable about either
application or development environment.
Experts use the combination of informal
analogy approach where similar projects
from past are identified and bottom up
estimating.
10. Estimating by Analogy
Called “Case Based Analogy”
Estimator identifies completed projects
source cases with similar characteristics to
new project (target case)
Effort of the source case used as base
estimate for target.
TOOL – ANGEL software tool
Measuring Euclidean Distance between the
cases
12. Problems with Over and Under
Estimates
Parkinson’s Law
“Given an easy target staff will work less hard”
Brook’s Law
Effort required to implement a project will go up
disproportionately with the number of staff assigned
to the project
“ Putting more people on a late job makes it later”
13. Measure of Work
Measure such as
SLOC ( Source Lines of Code)
KLOC ( Thousand Lines of Code)
14. Albrecht Function Point Analysis
Top - down method devised by Allan
Albrecht(IBM)
Developed the idea of Function Points(FPs)
Basis of function point analysis has five
components:
External Input Types
External Output Types
External Inquiry Types – US spelling inquiry
Logical Internal File Types – Data store
External Interface File Types – To & Fro (BACS)
BACS-Bank Automation Clearing System
17. Example:
A logical Internal File contain:
Purchase order organized into two separate record
types:
Main purchase order details
Purchase order number, supplier reference,
purchase order date
Purchase order item details
product code, unit price and number ordered.
No. of record types = 2
No. of data types = 6
File type would be rated as low
FP Count=7
18. Function Points Mark II
Sponsored by CCTA(Central Computer and
Telecommunications Agency)
Mark II – Improvement and replacement in
Albrecht method
In Albrecht method
Information Processing Size is measured in
UFPs(Unadjusted Functional Points)
Then TCA(Technical Complexity Adjustment) is
applied
20. For each transaction UFPs are
calculated
UFPs = Wi * (number of input data element types)+ We
* (number of entity types referenced)+ Wo * (number of
output data element types)
Wi We Wo are weightings derived by asking
the developers the proportions of effort
spent.
FP counters use industry averages which are:
Wi = 0.58
We = 1.66
Wo = 0.26
21. COSMIC Full Function Points
Cosmic deals with decomposing the system
architecture into hierarchy of software layers.
Inputs and outputs are aggregated into data
groups
Each data group brings together data items that
relate to the same object of interest.
Data Groups can be moved in 4 ways:
Entries(E)
Exits(X)
Reads ( R)
Writes(W)
22. COCOMO II
COCOMO (Constructive Cost Model)-Boehm
Formula :
(effort)=c(size)k
Effort measured in pm(number of person-month)
Size in kdsi (Thousands of delivered source code instructions)
C,K constants
C and K are from
System Type C K
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20
23. Organic Mode:
Small teams develop software in a highly
familiar environment (Small & Flexible)
Embedded Mode:
Operate within very tight constraints and
changes to the system very costly
Semi-Detached Mode:
Combined elements of both
24. COCOMO II - Models
It has three stages
Application Composition
Early Design
Post Architecture
25. Estimate of person-months
pm=A(size)(sf)*(em1) *(em2) *(em3)*.. *(emn)
Pm Effort in person-months
A Constant (In 2000 - 2.94)
Size kdsi
sf Exponent Scale Factor
Exponent Scale Factor is derived as
Sf= B+0.01*∑(Exponent driver ratings)
B Constant (0.91)
26. Exponent Driver Ratings
Precedentedness(PREC)
Development Flexibility(FLEX)
Risk Resolution(RESL)
Team Cohesion(TEAM)
Process Maturity(PMAT)
Driver Very low Low Nominal High Very
High
Extra
High
PREC 6.20 4.96 3.72 2.48 1.24 0.00
FLEX 5.07 4.05 3.04 2.03 1.01 0.00
RESL 7.07 5.65 4.24 2.83 1.41 0.00
TEAM 5.48 4.38 3.29 2.19 1.10 0.00
PMAT 7.80 6.24 4.68 3.12 1.56 0.00
27. Capers Jones Estimating Rules of
Thumb
Rule1: SLOC Function Point Equivalence
One Function Point = 125 SLOC For C Programs
Rule2: Project duration estimation
Function points raised to the power 0.4 predicts the
approximate development time in calendar months.
Rule3: Rate of requirements creep
User requirements creep in at average rate of 2%
per month from the design through coding phases.
Rule4: Defect Removal Efficiency
Each software review, inspection, or test step will
find and remove 30% of the bugs that are present
28. ……
Rule5: Project ManPower Estimation
The size of the software divided by 150 predicts the
approximate number of the personnel required for
developing the application.
Rule6: Software development effort estimation
The approximate number of staff months of effort
required to develop a software is given by software
development time multiplied with the number of
personnel required.
Rule7: Function points divided by 500 predicts
the approximate number of personnel required
for regular maintenance activity.