Slide 1

Jerrid Gimenez Feb. 7, 2013

Slide 2

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

Slide 30

COCOMO Coefficients abcd Organic2.41.052.50.38 Semi-detached3.01.122.50.35 Embedded3.61.202.50.32

Slide 31

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