1
Chapter 23Chapter 23Estimation for Software Estimation for Software
ProjectsProjects
2
Software Project Software Project PlanningPlanning
The overall goal of project planning is to The overall goal of project planning is to establish a pragmatic strategy for establish a pragmatic strategy for controlling, tracking, and monitoring a controlling, tracking, and monitoring a complex technical project.complex technical project.
Why?Why?
So the end result gets done on time, with So the end result gets done on time, with quality!quality!
3
Project Planning Task Set-IProject Planning Task Set-I
Establish project scopeEstablish project scope Determine feasibilityDetermine feasibility Analyze risksAnalyze risks
Risk analysis is considered in detail in Chapter 25.Risk analysis is considered in detail in Chapter 25. Define required resourcesDefine required resources
Determine require human resourcesDetermine require human resources Define reusable software resourcesDefine reusable software resources Identify environmental resourcesIdentify environmental resources
4
Project Planning Task Set-IIProject Planning Task Set-II
Estimate cost and effortEstimate cost and effort Decompose the problemDecompose the problem Develop two or more estimates using size, function Develop two or more estimates using size, function
points, process tasks or use-casespoints, process tasks or use-cases Reconcile the estimatesReconcile the estimates
Develop a project scheduleDevelop a project schedule Scheduling is considered in detail in Chapter 24.Scheduling is considered in detail in Chapter 24.
Establish a meaningful task setEstablish a meaningful task set Define a task networkDefine a task network Use scheduling tools to develop a timeline chartUse scheduling tools to develop a timeline chart Define schedule tracking mechanismsDefine schedule tracking mechanisms
5
EstimationEstimation
Estimation of resources, cost, and schedule for a Estimation of resources, cost, and schedule for a software engineering effort requires software engineering effort requires experienceexperience access to good historical information (metricsaccess to good historical information (metrics the courage to commit to quantitative predictions when the courage to commit to quantitative predictions when
qualitative information is all that existsqualitative information is all that exists Estimation carries inherent risk and this risk Estimation carries inherent risk and this risk
leads to uncertaintyleads to uncertainty
6
Write it Down!Write it Down!
SoftwareSoftwareProjectProject
PlanPlan
Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl strategy
7
To Understand Scope ...To Understand Scope ...
Understand the customers needsUnderstand the customers needs understand the business contextunderstand the business context understand the project boundariesunderstand the project boundaries understand the customer’s understand the customer’s
motivationmotivation understand the likely paths for understand the likely paths for
changechange understand that ...understand that ...Even when you understand,Even when you understand,
nothing is guaranteed!nothing is guaranteed!
8
What is Scope?What is Scope?
Software scopeSoftware scope describes describes the functions and features that are to be delivered to the functions and features that are to be delivered to
end-usersend-users the data that are input and outputthe data that are input and output the “content” that is presented to users as a the “content” that is presented to users as a
consequence of using the softwareconsequence of using the software the performance, constraints, interfaces, and reliability the performance, constraints, interfaces, and reliability
that that boundbound the system. the system. Scope is defined using one of two techniques:Scope is defined using one of two techniques:
A narrative description of software scope is developed A narrative description of software scope is developed after communication with all stakeholders.after communication with all stakeholders.
A set of use-cases is developed by end-users.A set of use-cases is developed by end-users.
9
ResourcesResources
project
people
skills
number
location
reusable software
OTS components
full-experience components
new components
part.-experience components
environment
hardware
software tools
network resources
10
Project EstimationProject Estimation
Project scope must be understoodProject scope must be understood Elaboration (decomposition) is Elaboration (decomposition) is
necessarynecessary Historical metrics are very helpfulHistorical metrics are very helpful At least two different techniques At least two different techniques
should be usedshould be used Uncertainty is inherent in the processUncertainty is inherent in the process
11
Estimation TechniquesEstimation Techniques Past (similar) project experiencePast (similar) project experience Conventional estimation techniquesConventional estimation techniques
task breakdown and effort estimatestask breakdown and effort estimates size (e.g., FP) estimatessize (e.g., FP) estimates
Empirical modelsEmpirical models Automated toolsAutomated tools
12
Estimation AccuracyEstimation Accuracy
Predicated on …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.
13
Functional DecompositionFunctional Decomposition
functional functional decompositiondecomposition
StatementStatementofof
ScopeScope Perform a Perform a Grammatical “parse”Grammatical “parse”
14
Conventional Methods:Conventional Methods:LOC/FP ApproachLOC/FP Approach
compute LOC/FP using estimates of compute LOC/FP using estimates of information domain valuesinformation domain values
use historical data to build estimates for use historical data to build estimates for the projectthe project
15
Example: LOC Example: LOC ApproachApproach
Average productivity for systems of this type = 620 Average productivity for systems of this type = 620 LOC/pm. LOC/pm.
Burdened labor rate =$8000 per month, the cost per Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. line of code is approximately $13.
Based on the LOC estimate and the historical Based on the LOC estimate and the historical productivity data, the total estimated project cost is productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-$431,000 and the estimated effort is 54 person-months.months.
16
Example: FP ApproachExample: FP Approach
The estimated number of FP is derived:The estimated number of FP is derived:FPFPestimatedestimated = count-total = count-total 33 [0.65 + 0.01 [0.65 + 0.01 33 SS (F (Fii)])]
FPFPestimatedestimated = 375 = 375
organizational average productivity = 6.5 FP/pm. organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is burdened labor rate = $8000 per month, the cost per FP is approximately $1230. approximately $1230. Based on the FP estimate and the historical productivity data, Based on the FP estimate and the historical productivity data, the total the total estimated project cost is $461,000 and the estimated effort is 58 person-estimated project cost is $461,000 and the estimated effort is 58 person-monthsmonths..
17
Process-Based EstimationProcess-Based EstimationObtained from “process framework”Obtained from “process framework”
applicationapplicationfunctionsfunctions
framework activitiesframework activities
Effort required to Effort required to accomplishaccomplisheach framework each framework activity for each activity for each application functionapplication function
18
Estimation with Use-CasesEstimation with Use-Cases
use cases scenarios pages Ź scenarios pages LOC LOC estimatee subsystem 6 10 6 Ź 12 5 560 3,366subsystem group 10 20 8 Ź 16 8 3100 31,233e subsystem group 5 6 5 Ź 10 6 1650 7,970
Ź Ź Ź Źstimate Ź Ź Ź Ź 42,568
User interface subsystem Engineering subsystem group Infrastructure subsystem group
Total LOC estimate
Using 620 LOC/pm as the average productivity for systems Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated total estimated project cost is $552,000 and the estimated effort is 68 person-months.effort is 68 person-months.
19
Empirical Estimation Empirical Estimation ModelsModels
General form:General form:
effort = tuning coefficient * sizeeffort = tuning coefficient * sizeexponentexponent
usually derivedusually derivedas person-monthsas person-monthsof effort requiredof effort required
either a constant oreither a constant ora number derived based a number derived based on complexity of projecton complexity of project
usually LOC butusually LOC butmay also bemay also befunction pointfunction point
empiricallyempiricallyderivedderived
20
COCOMO-IICOCOMO-II
COCOMO II is actually a hierarchy of estimation COCOMO II is actually a hierarchy of estimation models that address the following areas:models that address the following areas:
Application composition model.Application composition model. Used during the early Used during the early stages of software engineering, when prototyping of user stages of software engineering, when prototyping of user interfaces, consideration of software and system interfaces, consideration of software and system interaction, assessment of performance, and evaluation of interaction, assessment of performance, and evaluation of technology maturity are paramount.technology maturity are paramount.
Early design stage model.Early design stage model. Used once requirements have Used once requirements have been stabilized and basic software architecture has been been stabilized and basic software architecture has been established.established.
Post-architecture-stage model.Post-architecture-stage model. Used during the Used during the construction of the software.construction of the software.
21
Estimation for OO Projects-IEstimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and Develop estimates using effort decomposition, FP analysis, and
any other method that is applicable for conventional applications.any other method that is applicable for conventional applications. Using object-oriented analysis modeling (Chapter 8), develop use-Using object-oriented analysis modeling (Chapter 8), develop use-
cases and determine a count. cases and determine a count. From the analysis model, determine the number of key classes From the analysis model, determine the number of key classes
(called analysis classes in Chapter 8).(called analysis classes in Chapter 8). Categorize the type of interface for the application and develop a Categorize the type of interface for the application and develop a
multiplier for support classes:multiplier for support classes: Interface typeInterface type MultiplierMultiplier No GUINo GUI 2.0 2.0 Text-based user interfaceText-based user interface 2.25 2.25 GUIGUI 2.5 2.5 Complex GUIComplex GUI 3.0 3.0
22
Estimation for OO Projects-IIEstimation for OO Projects-II
Multiply the number of key classes (step 3) by the Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support multiplier to obtain an estimate for the number of support classes.classes.
Multiply the total number of classes (key + support) by the Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.suggest 15 to 20 person-days per class.
Cross check the class-based estimate by multiplying the Cross check the class-based estimate by multiplying the average number of work-units per use-caseaverage number of work-units per use-case
23
Estimation for Agile ProjectsEstimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for Each user scenario (a mini-use-case) is considered separately for
estimation purposes.estimation purposes. The scenario is decomposed into the set of software engineering The scenario is decomposed into the set of software engineering
tasks that will be required to develop it.tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based Each task is estimated separately. Note: estimation can be based
on historical data, an empirical model, or “experience.”on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP
or some other volume-oriented measure (e.g., use-case count).or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the Estimates for each task are summed to create an estimate for the
scenario.scenario. Alternatively, the volume estimate for the scenario is translated into Alternatively, the volume estimate for the scenario is translated into
effort using historical data.effort using historical data. The effort estimates for all scenarios that are to be implemented The effort estimates for all scenarios that are to be implemented
for a given software increment are summed to develop the effort for a given software increment are summed to develop the effort estimate for the increment.estimate for the increment.
24
The Make-Buy DecisionThe Make-Buy Decision
system Xsystem Xreusereuse
simple (0.30)simple (0.30)
difficult (0.70)difficult (0.70)
minorminor changeschanges
(0.40)(0.40)
majormajorchangeschanges
(0.60)(0.60)
simple (0.20)simple (0.20)
complex (0.80)complex (0.80)
majormajor changeschanges (0.30)(0.30)
minorminor changeschanges
(0.70)(0.70)
$380,000$380,000
$450,000$450,000
$275,000$275,000
$310,000$310,000
$490,000$490,000
$210,000$210,000
$400,000$400,000
buybuy
contractcontract
without changes (0.60)without changes (0.60)
with changes (0.40)with changes (0.40)
$350,000$350,000
$500,000$500,000
buildbuild
25
Computing Expected CostComputing Expected Cost
(path probability) x (estimated path cost) (path probability) x (estimated path cost) ii ii
For example, the expected cost to build is:For example, the expected cost to build is:
expected cost = 0.30 ($380K) + 0.70 ($450K) expected cost = 0.30 ($380K) + 0.70 ($450K)
similarly,similarly,
expected cost = expected cost = $382K$382Kexpected cost = expected cost = $267K$267Kexpected cost = expected cost = $410K$410K
buildbuild
reureusesebubuyyconcontrtr
expected cost =expected cost =
= $429 K= $429 K
