Size and Cost Estimation

DR. BHARATI WUKKADADA

 Software Project Planning & Estimation
Software project planning encompasses five major activities-
• Estimation
• Scheduling
• Risk Analysis
• Quality Management Planning
• Change management planning
Consider only estimation
• Money
• Effort
• Resources
• Time
 Software Project Planning & Estimation

• Estimation of resources, cost and schedule for a software engineering

effort requires experience, access to good historical information
(metrics), and the courage to commit to quantitative predictions when
qualitative information is all that exists.

• Estimation carries inherent risk, and this risk leads to uncertainty.

 Project Estimation

• Project scope must be understood

• Elaboration (decomposition) is necessary
• Historical metrics are very helpful
• At least two different techniques should be used
• Uncertainty is inherent in the process
 Estimation Techniques

• Past (similar) project experience

• Conventional estimation techniques
• task breakdown and effort estimates
• size (e.g., FP) estimates
• Empirical models
• Automated tools
 Estimation Accuracy
• Predicated on …
• the degree to which the planner has properly estimated the size of the product
to be built.
• the ability to translate the size estimate into human effort, calendar time, and
dollars (a function of the availability of reliable software metrics from past
projects).
• the degree to which the project plan reflects the abilities of the software team.
• the stability of product requirements and the environment that supports the
software engineering effort.
 Size Estimation Conventional Methods:
LOC/FP Approach
• Text-based measures
• Function points measures
• Compute LOC/FP using estimates of information domain values
• Use historical data to build estimates for the project
 Typical Size-Oriented Metrics
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per LOC
• Pages of documentation per KLOC
• Errors per person-month
• Errors per review hour
• LOC per person-month
• $ per page of documentation
Typical Function-Oriented Metrics
• Errors per FP (thousand lines of code)
• Defects per FP
• $ per FP
• Pages of documentation per FP
• FP per person-month
 Why Opt for FP?

• Programming language independent

• Used readily countable characteristics that are determined
early in the software process
• Does not “penalize” inventive (short) implementations
that use fewer LOC that other more clumsy versions
• Makes it easier to measure the impact of reusable
components
 Decomposition Techniques
Main Issue : Software sizing
• LOC based Estimation
• Function Point Based Estimation
• Problem-Based Estimation
• Process-Based Estimation
 Function Point Estimation

• Alan Albrecht while working for IBM, recognized the problem in size
measurement in the 1970s.
• Developed a technique (which he called Function Point Analysis),
which appeared to be a solution to the size measurement problem.
 Function Point Estimation
• The principle of Albrecht’s function point analysis (FPA) is that a
system is decomposed into functional units.
• Inputs : information entering the system
• Outputs : information leaving the system
• Inquiries : requests for instant access to information
• Internal logical files : information held within the system
• External interface files : information held by other system that is used by the
system being analysed.
 Function Point Estimation
• The five functional units are divided in two categories:
(i) Data function types
• Internal Logical Files (ILF): A user identifiable group of logical
related data or control information maintained within the system.
• External Interface Files (EIF): A user identifiable group of logically
related data or control information referenced by the system, but
maintained within another system. This means that EIF counted for
one system, may be an ILF in another system.
 Function Point Estimation
(ii) Transactional function types
• External Input (EI): An EI processes data or control information that
comes from outside the system. The EI is an elementary process,
which is the smallest unit of activity that is meaningful to the end user
in the business.
• External Output (EO): An EO is an elementary process that generate
data or control information to be sent outside the system.
• External Inquiry (EQ): An EQ is an elementary process that is made
up to an input-output combination that results in data retrieval.
 Function Point Estimation
• Function point approach is independent of the language, tools, or
methodologies used for implementation; i.e. they do not take into
consideration programming languages, data base management systems,
processing hardware or any other data base technology.
• Function points can be estimated from requirement specification or design
specification, thus making it possible to estimate development efforts in
early phases of development.
• Function points are directly linked to the statement of requirements; any
change of requirements can easily be followed by a re-estimate.
• Function points are based on the system user’s external view of the system,
non-technical users of the software system have a better understanding of
what function points are measuring.
 Function Point Estimation
• Counting function points

Table 1
Function Point Estimation
 Function Point Estimation
• The weighting factors are identified for all functional units and
multiplied with the functional units accordingly.

• The procedure for the calculation of Unadjusted Function Point (UFP)

is given in table shown above.
 Function Point Estimation
• The procedure for the calculation of UFP in mathematical form is
given below:

• Where i indicate the row and j indicates the column of Table 1

• Wij : It is the entry of the ith row and jth column of the table 1
• Zij : It is the count of the number of functional units of Type i that have been
classified as having the complexity corresponding to column j.
 Function Point Estimation
• Organizations that use function point methods develop a criterion for
determining whether a particular entry is Low, Average or High.
• Nonetheless, the determination of complexity is somewhat subjective.
• FP = UFP * CAF

• Where CAF is complexity adjustment factor and is equal to

[0.65 +0.01 * Fi]
• The Fi (i=1 to 14) are the degree of influence and are based on
responses to questions noted as below.
 Function Point Estimation
• Number of factors considered ( Fi )
1. Does the system require reliable backup and recovery ?
2. Is data communication required ?
3. Are there distributed processing functions ?
4. Is performance critical ?
5. Will the system run in an existing heavily utilized operational environment ?
6. Does the system require on line data entry ?
7. Does the on line data entry require the input transaction to be built over
multiple screens or operations ?
 Function Point Estimation
8. Are the master files updated on line ?
9. Is the inputs, outputs, files, or inquiries complex ?
10. Is the internal processing complex ?
11. Is the code designed to be reusable ?
12. Are conversion and installation included in the design ?
13. Is the system designed for multiple installations in different
organizations ?
14. Is the application designed to facilitate change and ease of use by the
user ?
Function Point Estimation
 Function Point Estimation
• Consider a project with the following functional units:
• Number of user inputs = 50
• Number of user outputs = 40
• Number of user enquiries = 35
• Number of user files = 06
• Number of external interfaces = 04
• Assume all complexity adjustment factors and weighting factors are
average. Compute the function points for the project.
 Function Point Estimation
• We know

• UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
= 200 + 200 + 140 + 60 + 28 = 628
• CAF = (0.65 + 0.01 Fi)
= (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
• FP = UFP x CAF
= 628 x 1.07 = 672
 Function Point Estimation
• An application has the following:
10 low external inputs, 12 high external outputs, 20 low internal
logical files, 15 high external interface files, 12 average external
inquiries, and a value of complexity adjustment factor of 1.10.
What are the unadjusted and adjusted function point counts ?
 Function Point Estimation
• Consider a project with the following parameters.
(i) External Inputs:
(a) 10 with low complexity
(b)15 with average complexity
(c)17 with high complexity
(ii) External Outputs:
(a) 6 with low complexity
(b)13 with high complexity
(iii) External Inquiries:
(a) 3 with low complexity
(b) 4 with average complexity
(c) 2 high complexity
 Function Point Estimation
(iv) Internal logical files:
(a) 2 with average complexity
(b)1 with high complexity
(v) External Interface files:
(a) 9 with low complexity
• In addition to above, system requires
i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately reusable
iv. System is not designed for multiple installation in different organizations.
• Other complexity adjustment factors are treated as average. Compute the function points
for the project.
Empirical Estimation Models
 Cost Estimation

• Approximate judgement of the costs for a project. It should be done

throughout the entire life cycle.
• Why we need?
 To determine how much effort and time a software project requires.
 Important for making good management decisions.
 It facilitates competitive contract bids.
 It affect the planning and budgeting of a project.
 The Constructive Cost Model (COCOMO)
• Model proposed by B. W. Boehm’s
Constructive Cost
Model (COCOMO)

Basic

Intermediate Detailed
 COCOMO

COCOMO
Applied to

Organic Semidetached Embedded

Mode Mode Mode
 Development Mode of Software Projects

Mode Project Nature of Project Innovation Deadline

Size

Organic Typically Small size project, Experienced developers. Little Not

2-50 KLOC Examples: Simple Business Systems, Simple Tight
Inventory Management Systems, Data
Processing Systems etc.
Semi Detached Typically Medium size project and team. Medium Medium
50-300KLOC Examples: New Operating System, DBMS,
Complex Inventory Management Systems etc.

Embedded Typically over Large project, Real-time systems Significant Tight

300KLOC Examples: Real Time Command Systems,
Embedded Avionics Systems etc.
 COCOMO

 The COCOMO model is a single variable software cost estimation model

developed by Barry Boehm in 1981.
 The model uses a basic regression formula, with parameters that are derived from
historical project data and current project characteristics.
Hierarchy of Cocomo Model
1. Basic COCOMO model
2. Intermediate COCOMO model
3. Detailed COCOMO model
 COCOMO
• Basic COCOMO model takes the form

E = ab * (KLOC) bb (in Person-months)

D = cb * (E) db (in month)
• where E is effort applied in Person-Months, and D is the development
time in months. The coefficients ab , bb, cb and db are given in table
COCOMO
 COCOMO
• When effort and development time are known, the average staff size to
complete the project may be calculated as:

Average staff size(SS) = E/D (in Person)

Productivity(P) = KLOC / E (in KLOC/Person-month)
 COCOMO Example

Suppose that a 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.
 COCOMO 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.
 COCOMO Solution

Ans: 200 KLOC implies semi-detached mode.

Hence, E= 3.0 * (200)1.12 = 1133.12 PM
D=2.5 * (1133.12)0.35 = 29.3 M
Avg. staff size(SS) = E/D
= 1133.12/29.3=38.67 Persons.
Productivity (P) = KLOC/E
= 200/1133.12=0.1765 KLOC/PM.
 Intermediate COCOMO
• Extension of Basic COCOMO
• Why Use ?
Basic model lacks accuracy
• Computes software development effort as a function of program
size and set of 15 Cost Drivers
• Cost Driver: A multiplicative factor that determines the effort
required to complete the software project.
• Why Cost Drivers?
Adjust the nominal cost of a project to the actual project
Environment.
• For each Characteristics, Estimator decides the scale factor
 Intermediate COCOMO
• Cost Drivers
• Software Project Planning
(i) Product Attributes
• Required s/w reliability (RELY)
• Size of application database (DATA)
• Product Complexity (CPLX)

(ii) Hardware Attributes

• Run time performance constraints (TIME)
• Main Storage constraint (STOR)
• Virtual Machine volatility (VIRT)
• Computer turnaround time (TURN)
 Intermediate COCOMO
(iii) Personal Attributes
• Analyst capability (ACAP)
• Application Experience (AEXP)
• Programmer Capability (PCAP)
• Virtual Machine Experience (VEXP)
• Programming language Experience (LEXP)
(iv) Project Attributes
• Modern programming practices (MODP)
• Use of software tools (TOOL)
• Required development Schedule (SCED)
Intermediate COCOMO
Intermediate COCOMO
 Intermediate COCOMO Equations
• Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF)
• E (Effort) = ab(KLOC)bb * EAF(in Person-Month)
• D (Development Time) = cb(E)db (in month)
• SS (Avg Staff Size) = E/D (in persons)
• P (Productivity) = KLOC/E (in KLOC/Person-month)
Project ab bb cb db
Organic 3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
 Intermediate COCOMO : Example

A new project with estimated 400 KLOC embedded system has to be

developed. Project manager hires developers of low quality but a lot of
experience in programming language. Calculate the Effort, Development
time, Staff size & Productivity.
 Intermediate COCOMO : Example

EAF = 1.29 * 0.95 = 1.22

400 LOC implies Embedded System
Effort = 2.8*(400)1.20 * 1.225 = 3712 * 1.22 = 4528 person-months
Development Time = 2.5 * (4528)0.32 = 2.5 * 14.78 = 36.9 months
Avg. Staff Size = E/D = 4528/36.9 = 122 persons
Productivity = KLOC/Effort = 400/4528 = 0.0884 KLOC/person-month
 Intermediate COCOMO : Example
• Consider a project of MCA admission process is to be develop.
Modules to be developed with sizes M1=10, M2=5, M3=14, M4=8
and M5=12 respectively.
Cost drivers are high analyzed capability 0.86, low language
experience 1.14, low model programming language practice 1.10.
Calculate efforts development time, average staff size, team
productivity using intermediate COCOMO model.
 Detailed COCOMO
• Detailed COCOMO = Intermediate COCOMO + assessment of
Cost Drivers impact on each phase.
• Phases
1) Plans and requirements
2) System Design
3) Detailed Design
4) Module code and test
5) Integrate and test
• Cost of each subsystem is estimated separately.
• This reduces the margin of error.
 The Calculation

• Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF)

• E(Effort) = ab(KLOC)bb * EAF (in Person-Month)

• D(Development Time) = cb(E)db (in month)
• Ep (Total Effort) = µp * E (in Person-Month)
• Dp (Total Development Time) = τp * D (in month)
Lifecycle Phase Values of µp
Lifecycle Phase Values of τp
 Detailed COCOMO : Example

Consider a project to develop a full screen editor. The major components

identified and their sizes are
(i) Screen Edit – 4K
(ii) Command Lang Interpreter – 2K
(iii) File Input and Output – 1K
(iv) Cursor movement – 2K
(v) Screen Movement – 3K.
Assume the Required software reliability is high, product complexity is
high, analyst capability is high & programming language experience is
low. Use COCOMO model to estimate cost and time for different phases.
 Detailed COCOMO : Example
Size of modules : 4 + 2 + 1 + 2 + 3 = 12 KLOC [Organic]

EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169

 Detailed COCOMO : Example (Contd.)
Initial Effort (E) = ab(KLOC)bb * EAF = 3.2*(12)1.05 * 1.2169
= 52.9 person-months
Initial Development Time = cb(E)db =2.5*(52.9)0.38 = 11.29 months
Phase value of µp and τp

Plan & System Detail Module code & Integration &

Reqr Design Design test Test
Organic Small µp 0.06 0.16 0.26 0.42 0.16
Organic
Phase wise Small
effortτ& 0.10 time distribution
p development 0.19 0.24 0.39 0.18

E D Ep (in person-months) Dp (in months)

Plan & Requirement 52.9 11.29 0.06*52.9 = 3.17 0.10*11.29=1.12
System Design 52.9 11.29 0.16*52.9=8.46 0.19*11.29=2.14
Detail Design 52.9 11.29 0.26*52.9=13.74 0.24*11.29=2.70
Module code & test 52.9 11.29 0.42*52.9=22.21 0.39*11.29=4.40
Integration & test 52.9 11.29 0.16*52.9=8.46 0.18*11.29=2.03
 WHY COCOMO-II ?
• The changes in software development techniques included a move
away from mainframe overnight batch processing to desktop-based
real-time turnaround.
• These changes and others began to make applying the original
COCOMO model problematic.
• The model is tuned to the life cycle practices of the 21st century.
 COCOMO-II

• The following categories of applications / projects are identified by

COCOMO-II and are shown as
 Stages of COCOMO II Model

• Application composition model

• Used during the early stages of software engineering, when prototyping of user
interfaces, consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.
• Early design stage model
• Used once requirements have been stabilized and basis software architecture has
been established.
• Post-architecture stage model
• Used during the construction of the software.
 COCOMO-II
• Requires sizing information.
• Sizing options
• Object Points
• Function Points
• Lines of Source Code
• Application composition model uses object points
• Object point is an indirect measure that is computed using counts of
the number of
• Screens (at the user interface)
• Reports
• Components likely to be required to build the application
 COCOMO-II
1. Assess object counts:
• Estimate the number of screens, reports and 3 GL components that will
comprise this application.
2. Classification of complexity levels:
• We have to classify each object instance into simple, medium and difficult
complexity levels depending on values of its characteristics.
COCOMO-II

For Screens
COCOMO-II

For Reports
 COCOMO-II
3. Assign complexity weight to each object :
• The weights are used for three object types i.e., screen, report and 3GL
components using the Table
 COCOMO-II
4. Determine object points:
Add all the weighted object instances to get one number and this known as
object-point count.
5. Compute new object points:
We have to estimate the percentage of reuse to be achieved in a project. Depending on
the percentage reuse, the new object points (NOP) are computed.

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

• NOP are the object points that will need to be developed and differ from the
object point count because there may be reuse.
 COCOMO-II
6. Calculation of productivity rate: The productivity rate can be
calculated as:
Productivity rate (PROD) = NOP/Person month
 COCOMO-II
• Compute the effort in Persons-Months: When PROD is known, we
may estimate effort in Person-Months as:

Effort in PM = NOP /PROD

 COCOMO-II Example
• Consider a database application project with the following characteristics:
I. The application has 4 screens with 4 views each and 7 data tables
for 3 servers and 4 clients.
II. The application may generate two report of 6 sections each
from 07 data tables for two server and 3 clients. There is 10% reuse of
object points.
• The developer’s experience and capability in the similar environment is low.
The maturity of organization in terms of capability is also low.
• Calculate the object point count, New object points and effort to develop
such a project.
 COCOMO-II Example
• Number of screens = 4 with 4 views each
• Number of reports = 2 with 6 sections each
• From Screens and Reports Table we know that each screen will be of
medium complexity and each report will be difficult complexity.
• Using Table 10 of complexity weights, we may calculate object point
count.
Object Points= 4 x 2 + 2 x 8 = 24
NOP= 24*[(100-10)/100] =21.6
 COCOMO-II Example
Productivity rate (PROD) = NOP/Person month

PROD = 7

Effort in PM = NOP /PROD

E= 21.6/ 7 = 3.085
 Cost-benefit Analysis
– Purpose - answer questions such as:
• Is the project justified (i.e. will benefits outweigh costs)?
• What is the minimal cost to attain a certain system?
• How soon will the benefits accrue?
• Which alternative offers the best return on investment?
– Examples of things to consider:
• Hardware/software selection
• Selection among alternative financing arrangements (rent/lease/purchase)
– Difficulties
• Benefits and costs can both be intangible, hidden and/or hard to estimate
• Ranking multi-criteria alternatives
 Cost-benefit Analysis
• Need to consider several cost elements
– Hardware Cost
– Personnel Cost
– Facility Cost
– Operating Cost
– Supply Cost
Procedure for Cost-benefit Analysis
• Expenditure
– We spend to get what we need
• Investment
– We invest to realize a return on theinvestment
• Costs are incurred throughout its life cycle.
• Benefits are realized in the form of reduced operating
costs, improved corporate image, staff efficiency or
revenues.
• To what extent benefits outweigh costs is the function
of cost/benefit analysis.
 Procedure for Cost-benefit Analysis

• Steps:
– Identify the costs and benefits pertaining to a given project.
– Categorize the various costs and benefits for analysis.
– Select method for evaluation.
– Interpret the results of the analysis.
– Take action.
Classification of Cost and Benefits
• Cost and benefits can be classified as:
– Tangible and Intangible
– Direct or Indirect
– Fixed or Variable
 Evaluation Method
• Payback analysis
• Return on Investment
• Cash-flow analysis
 Payback Analysis
• Is a common measure of the relative time value of a
project.
• Determines the time it takes for the accumulated
benefits to equal the initial investment. The shorter
the payback period, the sooner a profit is realized and
more attractive is the investment.
• It is easy to calculate and allows two or more
activities to be ranked.
• It does not allow for the time value of money
 Payback Analysis
Overall cost outlay = (A* B) + (C*D)= Years + Installation time (G)
Annual cash flow 5+2 Years to recover
• Elements offormula
– A: Capital investment (include escalation costs)
– B: Investment credit (1.00-0.08=0.92; must use current rate)
– C: Cost investment
– D: Company’s federal income taxbracket
– E: State and local taxes
– F: Life of capital (expected)
– G: Time to install system
– H: Benefits and savings
 Payback Analysis
– 1: Project benefits
– 2:Depreciation (Capital Investment-Salvage/ Expected life)
– 3: State and local taxes (percentage)
– 4: Benefits before FTT (federal income tax: 1-2-3=4)
– 5 Benefits after FTT (4*D)
 Payback Analysis
• Elements Rs. 200,000
– A: Capital investment 92%
– B: Investment credit difference Rs. 25,000
– C: Cost investment 54%
– D: Company’s federal income taxbracket(100%-46%) 2%
– E: State and local taxes 5 years
– F: Life of capital (expected) 1 year
– G: Time to install system Rs. 250,000
– H: Benefits and savings
 Payback Analysis
• Calculations Rs. 250,000
– 1: Project benefits Rs. 40,000
– 2: Depreciation (200,000/5) Rs. 4000
– 3: State and local taxes (200,000*0.02) Rs. 206,000
– 4: Benefits before FTT Rs. 94,760
Less tax difference (206,000*0.46) Rs. 111,240
– 5 Benefits after FTT (4*D)
 Payback Analysis
• Formula Calculation (200,000*.92)+ (25,000*.54)
(111,240+40,000)

= 197,500/ 151,240
= 1.3 years + installation time (G)
= 2.3 years to recover investment
2 years and 3 months is the payback period
 Cash Flow Analysis

• Keeps track of accumulated costs and revenues on a regular basis.

• Spread sheet format also provides break-even and payback

information.
 Cash Flow Analysis
Jan Feb March Apr May
Revenues from Comp. Services 22,000 22,000 26,000 27,100 41,000
Operating Expenses:
Facility Preparation 24,000 9,000 1,400
Hardware Lease 7,400 7,400 7,400 7,400 7,400
Insurance 195 195 195 195 195
Salaries 11,100 11,100 11,100 10,600 10,600
Supplies 3,640 2,700 2,740 3,950 4,600
Tele. Communication 1,300 1,300 1,300 1,300 1,900
Travel/ Entertainment 2,000 1,600 900 800 900
User Training 1,500 1,500 2,760 2,810 2,850
Total Expenses 51,135 34,795 27,795 27,055 28,445
Cash Flow (revenue- expenses) -29,135 -12,795 -1,795 45 12,555
Accumulated cash flow -29,135 -41,930 -43,725 -43,680 -31,125
 Return On Investment
• Return on investment (ROI) is the result of subtracting the project costs from the benefits and then dividing
by the costs.
• For example, if you invest $100 today and next year it is worth $110, your ROI is ($110- 100)/100 or 0.10 (10
percent).
• Note that the ROI is always a percentage.
• It can be positive or negative.
• It is best to consider discounted costs and benefits for multi-year projects when calculating ROI.
• Can be calculate as follows:
• ROI= (total discounted benefits- total discounted costs)/ discounted costs
• ROI= ( 516 000- 243 200)/ 243 200 =112%
• The higher the ROI, the better.
• Many organizations use ROI in the project selection process.