Jerrid Gimenez Feb. 7, 2013. Software Estimation – “estimation of the software size, development effort, software development cost, and software development
Software Estimation estimation of the software size,
development effort, software development cost, and software
development schedule for a specified project in a specified
environment, using defined methods, tools, and techniques -Murali
Chemuturi Author: Software Estimation Best Practices, Tools &
Techniques
Slide 3
What do we get out of the estimate? Components Size Effort
needed Cost Time Risk Data for future improvements
Slide 4
Recommended: Project Lead Person responsible for completion of
estimated task Often: You!
Slide 5
Estimation gives the Customer: Budget Quote to compare with
Estimation gives the Supplier: Budget chance to evaluate the
risks/rewards of a project way to keep track of progress Why is
this Important to You? It will be a part of our job as Software
Engineers!
Slide 6
Before Development When project is acquired from customer
Following project Approval for internal projects. During
Development Decreases Uncertainty(See Uncertainty Later) Estimating
After Development? Not as common - but very beneficial Compare
actual cost size time to estimated values Improves knowledge for
future estimations
Slide 7
Many variables Sizing Development Environment Support
Environment Staff (how much/how talented)
Slide 8
Not done as often as Estimating Effort. Why do we do it? Drives
Scheduling and Cost Estimations Size -> Effort -> Cost How do
we size Software?
Slide 9
Experiment: How many lines of code(LOC)? //Function
Population(string town) returns count of //people in personList who
live in the input town Public int Population(string town) { int
count = 0; for(int i = 0; i < personList.length(); i++)
if(personList[i].Town == town) count++; return count; }
Slide 10
Orginal method of estimating size Program Size = LOC needed for
functionality How many LOC from the experiment? The world may never
know
Slide 11
Module 1 Estimated LOC FunctionalityMin LOC Max. LOCLikely
LOCEstimated LOC F1100150125140 F295120105 TOTAL245
Slide 12
Pros Beneficial for Real Time/Embedded Applications Can be used
to create Historical data for future estimates Easy to count Cons
No defined Line Doesnt promote code optimizations
Slide 13
What are they? Points used to quantify functionality given to
the user Most popular size measure Developed late 1970s Allan J.
Albrecht of IBM International Function Point Users Group Maintains
FP standards Certifications Training
Slide 14
Function Point Analysis Counts: External Inputs External
Outputs External Inquiry Internal Logical File External Interface
File Each has 3 complexity possibilities to come up with FP
count
Slide 15
Pros: Very well defined Benchmarking Used to show Productivity
Cons: Not Intuitive Must train / find well trained counters Need
user perspective
Slide 16
Person Hours/Months/[Unit of time] Derives Schedule, Cost
Slide 17
How its done: Use knowledge of previous projects to come up
with estimates What is needed for success: Company must keep
records Similar Projects must have been made
Slide 18
Parameters for Analyzing Project Type Full life cycle
Implementation Conversion Port Migration Client Information
Application Domain Size of clients organization Number of client
locations Development Platform
Slide 19
Strengths: Reliable Inuitive Estimation Data can be purchased
Weaknesses Poor Record Keeping = bad estimates Not the best for new
organizations Time consuming
Slide 20
How its done: Work with Subject Matter Experts (SMEs) to
formulate estimates If a small team of SMEs is used, a common
estimate is derived. Works well because: No historical data needed
If proper SME is chosen - Extremely accurate Quick Inaccurate
because: SME can be biased / inconsistent / overconfident
Slide 21
Expert Estimates must be Converged Simple average Swap
extremes
Slide 22
Slide 23
How its done: Outline the needed tasks involved for the project
Should be done by person who ensures the tasks are accomplished.
Use knowledge of needed work and skill set of the implementers to
derive time estimates. Pros: Estimator is knowledgeable of the work
at hand No explicit sizing such as Lines of Code count is needed
Limitations: Subjective accuracy is up to the estimators opinion No
sizing
Slide 24
How its done: Decomposition of system into smaller components
Works well because: Estimates are linked to requirements Inaccurate
when: Good requirements arent available Bias may lead to
underestimation
Slide 25
How its done: Individuals evaluate each component of the entire
system. Sum to formulate project estimate Works well because: Can
be very accurate detailed Builds responsibility Issues: Time
consuming process Details may not be available Bias can lead to
underestimation Can miss integration costs
Slide 26
How its done: Work with SMEs to find out how much we can give
the customer for given budget Works well because: The price is
right! Issues: Need knowledge of functionality cost
Slide 27
How its done: Estimate by use of design parameters and
mathematic formulas Works well because: Fast Ease of use Can be
re-useable Issues: Models need to fit the bill Can end up being
very inaccurate through poor choice of parameters
Slide 28
Developed by: Dr. Barry Boehm Studied historical data 63
projects: 2,000 100,000 LOC Large following 3 Types: Basic
Intermediate Product Attributes Hardware Attributes Personnel
Attributes Project Attributes Advanced Intermediate + Phase
approach
Slide 29
3 Classes of Projects Used for Formula Organic Small team More
experienced Less rigid requirements / constraints Semi-detached
Mixed teams / experiences Mixed rigidity of requirements /
constraints Embedded Tight constraints
Organic Mode - We have estimated: 15 KLOC minumum 17.5 KLOC
likely 22 KLOC maximum
Slide 32
Slide 33
400% to 25% !? Current studies show closer to +100% / -50% at
feasibility stage Strong tendency to underestimate
Slide 34
Alternatives to giving a single number Between X and Y person
months X% chance it will be under Y person months Use the pX
approach X = X% chance of NOT exceeding the estimate Example Youre
on a project and your estimate is 8 person months. Youve researched
that 10% of similar projects have been under budget. p10 estimate =
7 staff months 10% chance of being under, 90% being over
Slide 35
Communicate in a way that makes them known, such as the pX
method. Methodology > Gut Feelings Work pressure drives over
confidence Re-Estimate Feasibility Stage - Ball Park Requirements
Stage More Detailed Design Stage - Refined Agile Environments:
Expect higher uncertainty
Slide 36
Little / Misused historical data Record estimates + actual data
Make sure data fits the bill Over-Optimistic / Hopeful management
Avoid gut feelings use the methods Avoid over-confidence Not using
the estimate! Dont Confuse targets with estimates Not updating the
estimate Acknowledge uncertainty in estimation Estimate often it
will become more accurate
Slide 37
Slide 38
Chemuturi, M. (2009). Software estimation best practices, tools
& techniques. Fort Lauderdale, FL: J. Ross Publishing, Inc..
FAQs. (n.d.). International function point users group. Retrieved
February 4, 2013, from http://www.ifpug.org/?page_id=12 Galorath,
D. D., & Evans, M. W. (2006). Software sizing, estimation, and
risk management when performance is measured performance improves.
Boca Raton, FL: Auerbach Publications. Laird, L., & Brennan, M.
(2006). Software measurement and estimation: a practical approach.
Hoboken, NJ: John Wiley & Sons, Inc.. Pressman, R. (n.d.). A
brief summary of the original cocomo model. McGraw hill higher
education. Retrieved February 4, 2013,from
www.mhhe.com/engcs/compsci/pressman/information/olc/
www.mhhe.com/engcs/compsci/pressman/information/olc/
COCOMO.html