Upload
mrinal-ghosh
View
221
Download
0
Embed Size (px)
Citation preview
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 1/30
Software Estimation
Tutorial
Presented by Dongwon Kang
ⓒ KAIST SE LAB 2008
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 2/30
Contents
Introduction
Overview of the estimation process
Sizing methods
Source lines of code
Function point
Use case point
Effort estimation methods
Algorithmic models
Expert judgment
Analogy
Best practices for estimation
2 / 29ⓒ KAIST SE LAB 2008
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 3/30
Introduction (1/3)
What is software estimation?
Predicting the resources required for a software developmentprocess
• Effort / cost / schedule
Why do we estimate?
No estimate, no plan and control Crucial to go/no-go decisions on a software project
Essential to establish a budget for a software project
…
ⓒ KAIST SE LAB 2008 3 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 4/30
Introduction (2/3)
Difficulties in software estimation
Average project exceeded 90% of budget and 120% of schedule
• Standish Group of 8,380 projects (1994)
55% of projects exceeded budget
• 24 companies that developed large distributed systems (1994)
ⓒ KAIST SE LAB 2008 4 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 5/30
Introduction (3/3)
Why is the estimation so inaccurate?
Uncertainty is unavoidable when predicting the future
• Requirements – often unstable and vague
• Design – preferences of architecture and design may vary
• Implementation – language and development environment
• Testing – degree of extensiveness• Deployment - user acceptance
• Personnel - experience & expertise
• Technology - Multi-platform or not
Finding all the factors affecting a project is almost impossible
Most factors are hard to quantify
We need systematic approaches to help to reduce theinaccuracy of estimates!
ⓒ KAIST SE LAB 2008 5 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 6/30
Overview of the estimation process (1/2)
6 / 29
Requirements
Environmental andbusiness factors
Staff Skill andAvailability
Define Project(Products, Process)
Identify andEvaluate Risks
Estimate Cost and
Schedule
Work Breakdown Structure
Project Estimate Project PlanBudget andSchedule
Perform PlannedActivities
Project Actuals
Status and Estimateto Complete
Compare Plannedand Actual Values
Organization’s
Historical DataCalibrate
DocumentedEstimation Models
Improve ProcessUpdateProcedures andChecklists
Close out report
Re-estimate Costand Schedule
Changes inRequirements,Design andEnvironment
Revised Inputs
Enhancements
BEFORE
DURING
AFTER
Total Estimation cycle
Source : R. Stutzke, “Estimating Software-intensive Systems”
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 7/30
Overview of the estimation process (2/2)
Bottom-upestimation
history data
Experts
Estimating project size
Algorithmic Models
Expert judgment
Analogy
Algorithmic Models
Expert judgment
Analogy
Top-down
estimation
…
SLOC
Function Point
Use Case Point
…
Projectcharacteristics
Estimating effort
Estimated effort
Apply productivity
ⓒ KAIST SE LAB 2008 7 / 29
Technical view using various techniques
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 8/30
Software Sizing Methods
Estimating Source Lines of Code
Function Point
Use case Point
ⓒ KAIST SE LAB 2008 8 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 9/30
Estimating Source Lines of Code
Characteristics
Traditional method to measure software size
Developers view of the software
How to estimate?
Experience
Previous / existing system size
Breaking system into pieces (bottom up)
Problems with SLOC estimation
Hard to reflect the complexity
Hard to consider environmental considerations (language, etc.)
“Measuring programming progress by
lines of code is like measuring aircraft
building progress by weight”
Bill Gatesⓒ KAIST SE LAB 2008 9 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 10/30
Function Point (1/4)
Characteristics
User (functional) view of software
• Calculated from system requirements
• Counts attributes of the planned system
– Inputs, outputs, inquiries, internal logical files, external interface files
Standard is maintained by IFPUG
In Korea, FP is used as a pricing standard of software development
Internal Files
External Inputs
External
Outputs
System Boundary
External Interface File
ⓒ KAIST SE LAB 2008 10 / 29
ExternalInquiries
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 11/30
Function Point (2/4)
Attributes
External Inputs (EI)
• Control or business information coming from out of system boundary
– Ex) user input / sensor data
External Outputs (EO)
• Derived data from calculation or applying algorithms, sent to outside – Ex) graphics, reports
External Inquiry (EQ)
• A process that retrieves data from ILF or EIF, including no calculation
Internal Logical Files (ILF)
• Data that reside within application boundary – Ex) database, masterfile
External Interface Files (EIF)
• Data that reside outside the application and is maintained by anotherapplications, used for reference purposes only
– Ex) help message, reference dataⓒ KAIST SE LAB 2008 11 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 12/30
Calculating unadjusted function point (UFP)
Calculating adjusted function point (AFP)( )
(VAF considers characteristics of the environment and complexity of product)
Low Avg. High
External Input __ x 3 __ x 4 __ x 6
External Output __ x 4 __ x 5 __ x 7
Internal Logical File __ x 7 __ x 10 __ x 15
External Interface File __ x 5 __ x 7 __ x 10External Inquiry __ x 3 __ x 4 __ x 6
3
1
5
1i j
ijij xwUFP
VAF UFP AFP
14
1
01.065.0
i
ir VAF
Function Point (3/4)
ⓒ KAIST SE LAB 2008 12 / 29
(Weight is given by the number of data types, number of fields, etc.)
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 13/30
1. Data communications2. Distributed functions3. Performance4. Heavily used configuration5. Transaction rate
6. Online data entry7. End user efficiency8. Online update9. Complex processing10. Reusability11. Installation ease
12. Operational ease13. Multiple sites14. Facilitates change
5 – Very Influential
0 – No Influence
Function Point (4/4)
Value adjustment factor (VAF)
ⓒ KAIST SE LAB 2008 13 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 14/30
Use Case Point (1/2)
Characteristics
Sizing based on use-cases
• Intuitive to stakeholders and project team
• Traceable for controlling projects
Derived from function points
Consider actors, use-cases, technical factors and environmentalfactors
ⓒ KAIST SE LAB 2008 14 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 15/30
Use Case Point (2/2)
Calculating Unadjusted Use Case Point (UUCP)
UUCP = UAW + UUCW
• Unadjusted Actor Weights (UAW) = ∑(# Actors* weight factor)
– Weight is decided by complexity of communication with actors
• Unadjusted Use Case Weights (UUCW) = ∑(# Use Cases* weight
factor)
– Weight is decided by # of transactions
Calculating adjusted Use Case Point (UCP)
UCP = UUCP * TCF * EF
• Technical Complexity Factor (TCF) = 0.6+0.01*Tfactor
– Derived from Function Points• Environmental Factor (EF) = 1.4 + (-0.03*EFactor)
– Based on the interview from Objectory
ⓒ KAIST SE LAB 2008 15 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 16/30
Comparison of sizing methods
SLOC Function Point Use Case Point
Viewpoints Developer User (functionality) User (functionality)
Collecting phase Early After basic requirementanalysis
After identifying usecases
Understandability ofconcepts
Easy Not intuitive and difficultto communicate
Relatively easy
Ease of collecting data
from previous projects
Easy to automate Difficult to automate Requires use-case
document
Subjectivity ofestimation
High Relatively objective, butstill easy to get biasedaccording to estimators
Subjective creation ofuse cases
Expertise needed forestimation
Experience needed Specialized trainingneeded
None
Limitations Unable to reflectcomplexity
/ Dependent onlanguages
/ not suitable for web orIDE
Hard to reflect internalcomplexity
/ Time consuming / Hard to apply to acorrective maintenanceproject
Granularity of use casesmay vary according toanalysts
ⓒ KAIST SE LAB 2008 16 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 17/30
Estimation Method
Techniques for estimation
Algorithmic models
Expert judgment
Analogy
Top-down and bottom-up estimation
ⓒ KAIST SE LAB 2008 17 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 18/30
Algorithmic models (1/3)
Characteristics
Use a mathematical formulae for estimation
• Yielded from analysis of historical data
• Regression is widely used for algorithmic models
Calibration using local history data is strongly required
• Project environments vary according to the characteristics of eachorganization
• Information of a new project environment need to be updated to themodel
ⓒ KAIST SE LAB 2008 18 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 19/30
Algorithmic models (2/3)
Example - COCOMO II
Application composition model
• Used when software is prototyped or composed from existing parts
• Utilizing Object Point, similar to Function Point, and productivityinformation
– Counting the number of screens, reports and 3GL modules
Early design model
• Used when requirements are available but design has not yet started
Post-architecture model
• Used once the system architecture has been designed and moreinformation about the system is available
Reuse model
• Used to compute the effort of integrating reusable components
ⓒ KAIST SE LAB 2008 19 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 20/30
Algorithmic models (3/3)
Example - COCOMO II (Cont’d)
Early design model and post-architecture model utilize the form offormula “Effort = A x SizeB x M”
• For sizing, SLOC or FP is used
• A: organization-dependent constant
• B: scale factors
– Factors affecting the effort in an exponential manner
• M: effort Multipliers
– Supports four categories - product factors, platform factors,personnel factors, project factors
– Early design model supports 7 factors, while post-architecture model
supports 17 factors, according to the available amount of information
ⓒ KAIST SE LAB 2008 20 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 21/30
Expert judgment
Characteristics
Utilize personal expertise and experience in estimation
One of the most commonly used method for estimation
• Not requires preparation such as data and models
Example - Wideband Delphi
1. Coordinator explains the project 2. Coordinator calls a group meeting to discuss estimation issues
3. Experts fill out estimation forms anonymously
4. Coordinator distributes a summery of the estimates
5. Coordinator calls a group meeting to discuss points where theirestimates varied widely
6. Experts fill out forms again anonymously and Step 4 to 6 areiterated for as many rounds as appropriate
ⓒ KAIST SE LAB 2008 21 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 22/30
Characteristics
Effort is estimated by comparing the project to a similar project inthe same application domain
Estimation can be done either at the total project level or at asubsystem level
Process 1. Selection of analogous projects
2. Assessing similarities and differences
3. Adjust the estimate using the difference
4. Consideration of any special cases
5. Creating the estimate
Analogy
(http://www.ecfc.u-net.com)
ⓒ KAIST SE LAB 2008 22 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 23/30
Comparison of estimation techniques
Algorithmic models Expert judgment Analogy
Approach Building statistical model Depending on experts’opinion
Measuring similarity andadjustment
Need for data Yes (for calibration) No Yes
Need for expert Low High Low
Strong point Objective, repeatable,analyzable formula
/ Suitable for sensitivityanalysis
Relatively cheapestimation
/ Accurate if expertshave direct experienceof similar systems
Based on actualexperience on a project
Week point Weak against exceptionalcircumstances
/ calibrated to past, notfuture
/ No better thanparticipants
/ The result may bebiased
Requires accuratedetails on many pastprojects/ Doesn’t work if similar
project doesn’t exist / Hard to define thesimilarity betweenprojects
ⓒ KAIST SE LAB 2008 23 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 24/30
Top-down and bottom-up estimation (1/4)
Any of above approaches may be used top-down or
bottom-up
Top-down
Starts at the system level and assess the overall systemfunctionality and how this is delivered through sub-systems
Does not consider details at first• Usable without knowledge of the architecture and the components
• Can underestimate the cost of solving difficult low-level technicalproblems
ⓒ KAIST SE LAB 2008 24 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 25/30
Bottom-up Start at the component level and estimate the effort required for
each component
Usable when the architecture of the system is known andcomponents identified
Accurate if the system has been designed in detail
May underestimate the costs of system level activities such asintegration and documentation
Top-down and bottom-up estimation (2/4)
ⓒ KAIST SE LAB 2008 25 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 26/30
Process-based estimation
Most commonly-used technique for project estimation
Project is broken down into a relatively small set of tasks and theeffort required to accomplish each task is estimated
• Bottom up estimation
Process
• Begins with outlining software functions obtained from the projectscope
• Once functions and activities are identified, the planner estimates theeffort (person-months) required to accomplish each activity perfunction
• Average labor rates are then applied to the estimated efforts(i.e. cost per unit effort - may vary per task)
• Cost and effort for each function and activity (row and column totals)are computed as the last step
Top-down and bottom-up estimation (3/4)
ⓒ KAIST SE LAB 2008 26 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 27/30
Activity CC PlanningRisk
analysisEngineering Release CE Totals
Task → Anal. Design Code Test
Function ↓
UICF 0.75 2.50 0.40 5.00 n/a 8.653DGA 0.50 4.00 0.60 2.00 n/a 7.10
CGDF 0.50 4.00 1.00 3.00 n/a 8.50
DBM 0.50 3.00 1.00 1.50 n/a 6.00
PCF 0.25 2.00 0.75 1.50 n/a 4.50
DAM 0.50 2.00 0.50 2.00 n/a 5.00
Totals .25 .25 .25 3.00 17.50 4.25 15.00 34.80
% effort 1% 1% 1% 7% 45% 12% 40%
Process-based estimation (Cont’d)
Example – CAD software
CC: Customer communicationCE: Customer evaluation
UICF: User interface and control facilities3DGA: Three-dimensional geometric analysisCGDF: Computer graphics display facilitiesDBM: Database managementPCF: Peripheral control functionDAM: Design analysis modules
Top-down and bottom-up estimation (4/4)
ⓒ KAIST SE LAB 2008 27 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 28/30
Best practices for estimation (1/2)
Estimate early and often!
Cost estimation should be done throughout the software life cycle
• Allow refinement according to changes
Select experts with similar experience on the project
Ask justification
Can help to reduce mistakes in consideration of estimation
Gather and analyze historical data
Must perform calibration when using algorithmic models
Do a final assessment of cost estimation at the end of the
project Identify problems in estimation
ⓒ KAIST SE LAB 2008 28 / 29
8/8/2019 4.Software Estimation
http://slidepdf.com/reader/full/4software-estimation 29/30
Best practices for estimation (2/2)
Avoid informal estimates due to the pressure from
management Allow time for estimation and plan for it
Use developer-based estimates
Manager based estimates are easy to be biased to the positive side
and not to reflect the realistic development environment
Estimate at a low level of detail, if possible
Can be more accurate with considering details
ⓒ KAIST SE LAB 2008 29 / 29