Software Project Estimation
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques
• Experience (historical data)
• The Decomposition Techniques
• The Empirical Estimation Model
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
1. Experience (historical data) based Project Estimation
• A model is based on experience (historical data) and takes the form
• where d is one of a number of estimated values (e.g., effort, cost, project duration)
and vi are selected independent parameters (e.g., estimated LOC or FP).
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach
• The Project Estimation Approach that is widely used
is Decomposition Technique.
• Decomposition techniques take a divide-and-conquer
approach. Size, Effort and Cost estimation are
performed in a stepwise manner by breaking down a
Project into major Functions or related Software
Engineering Activities.
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.1 Software Sizing
• A project estimate is only as good as the estimate of the size of the work
to be accomplished.
• In project planning, size refers to a quantifiable outcome of the software
project.
• Direct approach - lines of code (LOC)
• An indirect approach - Function points (FP)
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.1 Software Sizing (cont’d)
• Four different approaches to the sizing problem proposed by Putnam and Myers (1992)
▪ Fuzzy logic sizing - the approximate reasoning techniques that are the cornerstone of
fuzzy logic.
▪ Function point sizing - The planner develops estimates of the information domain
characteristics.
▪ Standard component sizing - the standard components for an information system are
subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC,
and object-level instructions.
▪ Change sizing - the use of existing software that must be modified in some way as part of a
project. Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.2 Problem-Based Estimation
LOC and FP data are used in two ways during software project estimation:
(1) As estimation variables to “size” each element of the software and
(2) As baseline metrics collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.
• LOC and FP estimation are distinct estimation techniques. Yet both have a number of
characteristics in common.
• Other components for sizing, such as classes or objects, changes, or business
processes affected
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.2 Problem-Based Estimation Cont’d
• A three-point or expected value can then be computed.
• The expected value for the estimation variable (size) S can be computed as a weighted average of
the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates.
• gives the heaviest credence to the
“most likely” estimate and follows a
beta probability distribution.
• Once the expected value for the estimation variable has been determined, historical LOC or FP
productivity data are applied.
• Productivity = KLOC / Person-month
• Quality = Defects / KLOC
• Cost = $ / LOC
• DocumentationDr.=Selva
pages of documentation / KLOC
Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
Lines of Code (LOC)
• It is one of the earliest and simpler metrics for calculating the size of the computer program.
• It is generally used in calculating and comparing the productivity of programmers.
• These metrics are derived by normalizing the quality and productivity measures by considering the
size of the product as a metric.
• As Lines of Code (LOC) only counts the volume of code, you can only use it to compare or estimate
projects that use the same language and are coded using the same coding standards
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
An example of LOC based Estimation
• Take the Library management system case. Software developed for the library will accept data
from the operator for issuing and returning books. Issuing and returning will require some validity
checks. For issue, it is required to check if the member has already issued the maximum number of
books allowed. In case of a return, if the member is returning the book after the due date then a
fine has to be calculated. All the interactions will be through the user interface. Other operations
include maintaining the database and generating reports at regular intervals.
Major software functions identified.
• User interface
• Database management
• Report generation
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
For user interface(Assumptions of LOC). Expected Value(EV) for user interface
• Sopt : 1800 EV = (1800 + 4*2000 + 4000) / 6
• Sm : 2000 EV = 2300
• Spess : 4000
Expected Value(EV) for database management
EV = (4600 + 4*6900 + 8600) / 6
For database management
• Sopt: 4600 EV = 6800
• Sm: 6900
Expected Value(EV) for user interface
• Spess : 8600
EV = (1200 + 4*1600 + 3200) / 6
For report generation EV = 1800
• Sopt: 1200
• Sm: 1600
Estimated lines of code
• Spess : 3200 =2300+6800+1800
=10900
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
• For example, A review of historical data indicates that the organizational average productivity for
systems of this type is 500 LOC/pm. Based on a burdened labor rate of $6000 per month.
• The cost per line of code is approximate.
• Cost/LOC=(6000/500)=$12
• Based on the LOC estimate and the historical productivity data and By Considering the total
estimated LOC as 10900,
The total Estimated project cost =(10900*12)=$130800.
10900
• The estimated effort is
The total estimated project effort = (10900/500) =21.8 Persons- Months
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
The problems of lines of code (LOC)
• Different languages lead to different lengths of code
• It is not clear how to count lines of code
• A report, screen, or GUI generator can generate thousands of lines of code
in minutes
• Depending on the application, the complexity of the code is different.
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
FP-Based Estimation
• Decomposition for FP-based estimation focuses on information domain values rather than software
functions.
FP=320*1.17=375
• The organizational average productivity for systems of this
type is 6.5 FP/pm.
• Based on a burdened labour rate of $8000 per month, the
cost per FP is approximately $1230.
• Based on the FP estimate and the historical productivity
Value adjustment factor 1.17
data, the total estimated project cost is $461,000 and the
estimated effort is 58 person-months.
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2.3 Process-Based Estimation
• The most common technique for estimating a project is to base the estimate on the process that
will be used.
• The process is decomposed into a relatively small set of tasks and the effort required to accomplish
each task is estimated.
• Like problem-based techniques, process-based estimation begins with a delineation of software
functions obtained from the project scope.
• A series of framework activities must be performed for each function.
• Once problem functions and process activities are melded, you estimate the effort (e.g., person-
months) that will be required to accomplish each software process activity for each software function.
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
2.3 Process-Based Estimation Cont’d
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
[Link] With Use Case Points
• A Use-Case is a series of related interactions between a user and a system that enables the user to
achieve a goal.
• Use-Case Points (UCP) is a software estimation technique used to measure the software size with use
cases. The concept of UCP is similar to FPs.
• The Use-Case Point estimation method was introduced by Gustav Karner in 1993. The work was later
licensed by Rational Software which merged into IBM.
The number of UCPs in a project is based on the following
• The number and complexity of the use cases in the system.
• The number and complexity of the actor in the system.
• Various non-functional requirements such as portability, performance, and maintainability that are
not written as use cases.
• The environment in which the project will be developed such as the language, the team’s
Dr. Selva Kumar S (Scope- VITAP University)
motivation, etc.
Software Project Estimation Techniques Cont’d
[Link] With Use Case Points cont’d
The Use-Case Points counting process has the following steps −
• Unadjusted Use Case Weight (UUCW)
Use Case Points (UCP)
• Unadjusted Actor Weight (UAW)
• Technical Complexity Factor (TCF) UCP = (UUCW + UAW) x TCF x ECF
• Environmental Complexity Factor (ECF)
Unadjusted Use Case Weight (UUCW)
UUCW = (Total No. of Simple Use Cases x 5) +Dr.(Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)
Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Unadjusted Actor Weight (UAW)
UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No. Complex actors x 3)
Technical Complexity Factor (TCF)
• The TCF is one of the factors applied to the estimated size of the software in order to account for
technical considerations of the system
TCF = 0.6 + (TF/100)
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Environmental Complexity Factor (ECF)
• The ECF is another factor applied to the estimated size of the software in order to account for the
environmental considerations of the system.
ECF = 1.4 + (-0.03 x EF)
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Example Unadjusted Use Case Weight (UUCW)
UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No.
Complex Use Cases x 15).
UUCW = (1x 5) + (1 x 10) + (3 x 15) = 60
Unadjusted Actor Weight (UAW)
UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2)
+ (Total No. Complex Actors x 3)
UAW = (1 x 1) + (0 x 2) + (2 x 3) = 7
Technical Complexity Factor (TCF) Environmental Complexity Factor (ECF)
TCF = 0.6 + (TF/100) • ECF = 1.4 + (-0.03 x EF)
TCF = 0.6 + (49/100) = 1.09 • ECF = 1.4 + (-0.03 * 10.0) = 1.1
Use Case Points (UCP)
• UCP = (UUCW + UAW) x TCF x ECF = (60+7)*1.09*1.1= 80.33
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Use cases are problematic for the following reasons
• Use cases are described using many different formats and styles—there is no standard form.
• Use cases represent an external view (the user’s view) of the software and can therefore be
written at many different levels of abstraction.
• Use cases do not address the complexity of the functions and features that are described.
• Use cases can describe complex behavior (e.g., interactions) that involve many functions and
features.
Dr. Selva Kumar S (Scope- VITAP University)
Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Use-Case–Based LOC Calculation
• N – the actual number of use cases
• LOCavg -historical average LOC per use case for this type of subsystem
• LOCadjust - represents an adjustment based on n percent of LOCavg where n is defined locally and
represents the difference between this project and “average” projects.
• Sa - actual scenarios per use case
• Sh - average scenarios per use case for this type of subsystem
• Pa - actual pages per use case
• Ph - average pages per use case for this type of subsystem
Dr. Selva Kumar S (Scope- VITAP University)