The document discusses various techniques for estimating software project size, effort, cost and duration. It describes lines of code and function points as common metrics for estimating project size. Function points measure the number of inputs, outputs, inquiries and files to estimate size early in development. The document also explains the COCOMO model for estimating effort, productivity, duration and staffing needs based on project size, complexity and other cost drivers. Intermediate COCOMO incorporates 15 cost drivers while basic COCOMO uses only size. References are provided for further reading.

1. SE-381
Software Engineering
BEIT - V
Lecture # 25
(Program Size and Cost Estimation
Models)

2. Metrics - Program Size Estimation
– Program size is a measure of the effort and time
required to develop the product
– Two prevalent metrics in use are
• Lines of Code
• Function Points
– Lines of Code (LOC)
• Historically oldest, evolved and its use propagated by the
availability of historical data with the orgs
• Simplest and so, popular
• Source lines of code counted and comments and headers left
out

3. Lines of Code
• Cons
– LOC available when product is ready, and
difficult to estimate before the start of SD
– Favors the (novice) programmers for their
poor programming skills as compared to
the experienced who write smartly
– Biased towards the programming language
used
– Reflective of only coding phase, which is a
fraction of SD process
– Complexity not addressed
– Penalizes re-usability

4. Function Point
– Function Point metric is in use since mid 70‟s and published by
Albrecht 1983, and cures the shortcomings of LOC
– FP metric can estimate program size directly from SRS
– FP is based on the concept that size of software is directly
dependent on the number of different functions and features it
supports
– Each feature when invoked reads input data and transforms it
to output data, Albrecht proposed to include the no of files and
no of interfaces as well
– FP is computed in two steps, in first step UFP - Unadjusted
Function Points are computed then these are corrected
UFP = (no of inputs)*w1 + (no of outputs)*w2 + (no of
inquiries)*w3 + (no of files)*w4 + (no of interfaces)*w5
Where wi depends on the complexity level of program,
according to Rajib Mall (2005), these weights are 4, 5, 4, 10
and 10 respectively. In general these are given in the table
below

5. Computation of Function Points
Description
Level of Information Processing Function
Total
Simple Average Complex
External Input
___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ _____________
External Output
___ x 4 = ___ ___ x 5 = ___ ___ x 7 = ___ _____________
Logical Internal File
___ x 7 = ___ ___ x 10 =___ ___ x 15 = ___ _____________
Ext. Interface File
___ x 5 = ___ ___ x 7 = ___ ___ x 10 = ___ _____________
External Inquiry
___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ _____________
Total Unadjusted Fictions Points (UFP)
_____________

6. Computation of FP
– In the second step, first Degree of Influence - DI, is
computed considering fourteen possible factors, each
having influence value varying from 0 - no influence to
5 - maximum influence, so DI can vary from 0 - 70
– The parameters considered for DI computation are
shown in the table (on next slide)
– Technical Complexity Factor - TCF is computed using
TCF = 0.65 + 0.01 * DI
– TCF varies from 0.65 to 1.35, and in second step FP
is computed by
FP = UFP * TCF

7. ID Characteristic DI ID Characteristic DI
C1 Data Communications --- C8 On-Line Update ---
C2 Distributed Functions --- C9 Complex Processing ---
C3 Performance --- C10 Re-Usability ---
C4 Heavily Used
Configuration
--- C11 Installation Ease ---
C5 Transaction Rate --- C12 Operational Ease ---
C6 On-Line Data Entry --- C13 Multiple Sites ---
C7 End User Efficiency --- C14 Facilitate Change ---
Total Degree of Influence
TCF = 0.65 + 0.01 x (Total ‘Degree of Influence’)
FP = UFP * TCF
DI Values
Not Present, or not Influence = 0
Insignificant Influence = 1
Moderate Influence = 2
Average Influence = 3
Significant Influence = 4
Strong Influence, throughout = 5

8. FP Cons and Improvements
• Shortcomings
– Allocation of parameters is subjective
– Symons 1988 pointed out that the proposed FP
analysis is based on two „intrinsic‟ factors but did not
include the Environmental factors like Project
Management Risks, People Skills, Methods and
tools used for development etc
• His proposed method includes the influence of
Environmental factors
– Algorithmic complexity not taken into account
• Inclusion of Feature Point metric is proposed to cater this
shortcomings

9. 3 Components of System Size

10. Project Estimation Techniques
– After determining the Project Size; effort to
develop the sw, project duration and cost are
to be estimated
– These parameters help in winning the
contract, as well as in resource planning,
scheduling, monitoring and controlling the
project
– Estimation Techniques can be categorised as:
• Empirical Estimation Techniques
• Heuristic Techniques
• Analytical Estimation Techniques

11. Empirical Estimation Techniques
– Based on educated guess of the project
parameters
– Prior experience of similar products helpful
– Although based on common sense, different
activities involved in estimation have been
formalised over the years,
– First the estimates are guessed and later, on
completion of project these are calibrated i.e.
estimates are corrected to reflect the desired
– Two such formalisations are
• Expert Judgement and
• Delphi Technique

12. Delphi Technique
• Non-Consultative, group consensus technique
• Needs access to several experts
• Experts may be at one or more locations
• Operates under the control of a coordinator
• Steps in a typical Delphi process
– Coordinator explains the task to experts
– Specifications are supplied to each expert
– Each expert makes estimates anonymously
– Coordinator consolidates responses and circulates the
summary
– Each expert reacts to disagreements giving reason
– This process iterates till agreement is reached
• Wideband Delphi Approach requires minimal
interaction between experts to speed up
consensus process

13. Heuristic Techniques
– Assumes that relationships among the
different project parameters can be modelled
using suitable mathematical expressions
– Once basic (independent) parameters are
known,the other (dependent) parameters can
be determined using basic parameters in
mathematical expressions
– Heuristic Models can be divided into two
classes:
• Single variable estimation models
• Multivariable estimation models

14. Single Variable Estimation Models

15. Multivariable estimation models

16. Analytical Estimation
Techniques

17. Software Cost Estimation
• COCOMO
COnstructive COst-estimation MOdel
– A software cost and schedule estimating
method that was developed by Barry W
Boehm and documented in Software
Engineering Economics [Boehm 1981].
– The model is an empirically derived,
nonproprietary, cost-estimation model,
based on a study by Boehm of 63 sw
development projects.

18. COCOMO
Accommodates three categories of software:
Organic
• Application programs – small well understood, smaller
development teams needed and team members are
experienced in developing similar programs
Semidetached
• Compilers, linkers etc the utility programs; development teams
are mix of experienced and novices, team members may have
limited experience on related systems but may be unfamiliar
with some aspects of the system to be developed.
Embedded
• System programs, that interact directly with the hardware and
typically involve meeting of timing constraints and concurrent
processing, include Operating Systems The developed sw is
strongly coupled to complex hw, or stringent regulations on the
operational procedures exist.

19. Effort and Development Time
• Effort is measured in PM – Person Months
– PM is the effort one can put in one month, taking into
account the productivity loss due to holidays, weekly
offs, coffee and prayer breaks etc.
– One PM is 19 calendar days or 152 working hours
– Conforms to the engineers assignments and
deadlines of calendar months
• Development time is measured in months, i.e.
Calendar months

20. Three Levels of Cost Estimation
• According to Boehm the cost estimation
should be done through three stages:
– Basic COCOMO
– Intermediate COCOMO
– Complete COCOMO
• Basic COCOMO (Single variable model)
Effort = a1 * (KLOC)**a2 PM
Tdev = b1 * (Effort)**b2 months

21. Basic COCOMO (cont.)
– PM is the area under the person-month plot, the
100 PM is NOT the effort put in by 100 people in
one month or effort put in by one person for 100
months – the commonly followed myth
– According to Boehm every LOC should be
calculated as one LOC, irrespective of actual no
of instructions on that line, some authors refer it
as DSI delivered Source Instructions
a1 a2 b1 b2
Organic 2.4 1.05 2.5 0.38
S-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

22. Correlations between variables
• Effort vs. Product Size
– For different program sizes if the Effort is
plotted for all the three categories against
program size, Effort has super-linear
behavior and higher effort for complexity is
reflected. That is Embedded Sw needs
higher effort than Organic sw for same
product size
• Development Time vs. Size
– Development Time is sub-linear to Size,
Because of parallel activities in Sw
development process

23. Effort vs. Product Size

24. Development Time vs. Size

25. Example – Basic COCOMO
Calculations
Find Effort, Productivity (LOC per Person-
Month), Development Time (in months)
and Average Staffing (full-time staff
personnel per month) for a project , which
is of Organic type and estimated size of
128,000 Lines of Code.

26. • Effort = 2.4 * (KLOC)**1.05
= 392 PM (person-months)
• Productivity = Size / Effort
= 128,000 LOC/392 PM
= 327 LOC/PM
• Dev Time = 2.5 * (Effort)**0.38
= 2.5 * (392)**0.38
= 24 months
• Av. Staffing = Effort / Tdev
= 392 PM / 24 months
= 16 FSP
• FSP = Full-time-equivalent Staff Personnel

27. Intermediate COCOMO
– Intermediate COCOMO is an extension to
Basic COCOMO and provides greater
accuracy and level of detail which makes it
more suitable for cost estimation in more
detailed stages of software product
definition.
– For all three categories it uses the same
exponents but the coefficients for Effort
computation are 3.2, 3.0 and 2.8
respectively for Organic, Semi-detached
and embedded.
– Schedule for Intermediate is determined by
the same equations as that for Basic model

28. Cost Drivers
– It incorporates 15 predictor variables,
called Cost Drivers, to account for software
project cost variations, that are not directly
correlated to project size.
– These Cost Drivers are grouped into four
categories
• Software Product Attributes
• Computer Attributes
• Personnel Attributes and
• Project Attributes

29. • Each of these attributes have different
ratings and some numerical values are
assigned to each, Eg RELY - Required
Sw Reliability has ratings as: Very Low,
Low, Nominal, High and Very High.
• Software Attributes:
– RELY – Required Software Reliability
– DATA – Database size
– CPLX – Software Complexity
• Computer Attributes:
– TIME – Execution Time Constraint
– STOR – Main Storage Constraint

30. – VIRT – Virtual Memory Volatility
– TURN – Computer Turnaround Time
• Personnel Attributes
– ACAP – Analyst Capability
– AEXP – Applications Experience (Team)
– PCAP – Programmer Capability
– VEXP – Virtual Machine Experience
– LEXP – Programming Language Experience
• Project Attributes
– MODP – Use of Modern Programming
Practices
– TOOL – Use of Software Tools
– SCED – Schedule Constraint

31. Reuse – Adaptation Adjustment
– The previously developed software, code, which
is now reused, or being adapted for reuse in the
new project. Its effect could be incorporated as
EDSI – Equivalent number of Delivered Software
Instructions. Calculated as:
AAF = Adaptation Adjustment Factor
AAF = 0.40(DM) + 0.30(CDM) +0.30 (IM)
Where DM = % Design Modified, CDM = % Code
Modified and IM = % of Integration required for
modified Sw
So
EDSI = (Adapted DSI) * (AAF / 100)

32. References
1. Deanna B Legg, Synopsis of COCOMO from Richard H Thayer (Ed) Software
Engineering Project Management, 2nd Ed, IEEE Society of Computer Sciences
(2000)
2. Barry Boehm et al, Cost Models for future Software Life Cycle Processes:
COCOMO 2.0 from Richard H Thayer (Ed) Software Engineering Project
Management, 2nd Ed, IEEE Society of Computer Sciences (2000)
3. Rajib Mall (2005); Fundamentals of Software Engineerign, 2nd Ed, Prentice-Hall of
India, New Delhi, Ch – 3 Software Project Management, pp:38-84
4. Capers Jones (2007); Estimating software Costs: Bringing Realism to Estimating;
2nd Ed, Tata McGraw-Hill Publishing Company, New Delhi
5. Jalote Pankaj (2005), An Integrated Approach to Software Engineering, Ch - 5
6. A J Albrecht and J E Gaffney; “Software Functions, Source Lines of Code and
Development Effort Prediction: A software Science Validation” in IEEE
Transactions on Software Engineering, Vol SE-9, no 6, pp 639-47, Nov 1983
7. Charles R Symons, “Function Point Analysis: Difficulties and Improvements” in
IEEE Transactions on Software Engineering, Vol 14, no 1, pp:2-11, Jan 1988
8. S A Kelkar (2007); Software Engineering – A Concise Study; Printice Hall of India,
New Delhi, Appendix A – Estimation Techniques pp: 641 – 682