CMU UC Professional Master of Software Engineering

Transcription

1 Outline The Software Estimation problem CMU UC Professional Master of Software Engineering Estimation Techniques in Software Projects Process oriented estimation techniques The WAG Wild Altogether Guess Estimation by analogy Experts judgment Wideband Delphi Parametric or algorithmic estimation methods CMU/UC MSE What is estimation? Why estimate? When estimate? Function Points Marco Vieira Departamento de Eng. Informática Universidade de Coimbra 2 Bad estimation J What is Software Estimation? The American Heritage Dic., 2nd College Edition, 1985: 1. A tentative evaluation or rough calculation 2. A preliminary calculation of the cost of a project 3. A judgment based upon one s impressions; opinion When someone asks for an estimate he is often asking for a commitment or for a plan to meet a target This is wrong!!! An estimate is a prediction of how long a project will take or how much it will cost 3 Why do we need to estimate? Standish Report Systems complexity i.e., on time, on budget, meeting user expectations i.e., either had costs or schedule overruns or did not fully meet user needs Infrequency Underestimation bias Complexity vs size 19% of project never complete ( 46% of the projects are considered challenged Why are we so bad at estimating? Only 35% of the projects can be considered successful 4 i.e., canceled or finished but not used We need to improve this scenario! Very fast changes over time Unrealistic goals 5 ~ SLOC in a pace maker ~ SLOC in OpenOffice.org ~ SLOC in Windows XP Requirements, market, people, etc Must be done by June! 6 1

2 What do we need to estimate? Estimation uncertainty n Size n Effort n Cost 7 8 When should we estimate? n During the bid n Short duration n As fast as possible n Reduced knowledge about the problem n At project Start n Create a project plan n Allocate resources n Detailed estimation n During the project n Handle change Estimate in the bid n No real money evolved n But it costs money!!! n The cost of losing the bid n The cost of performing the estimation n Key issue: n Compare with available history on other projects n Must be performed as quickly and cheaply as possible n Market do not wait for you n You are investing in something you are not sure to win n How important is it? n Critical!!! n Decisive to win the bid n It defines the money you will have to run the project 9 10 Decisive during bid n Identify critical requirements n The ones that really determine the development effort n Pareto rule (80-20)? n Create a rough estimate n But precise enough!!! n Apply history to improve estimates n Apply reuse to improve estimates n Understand the effort needed to bid on a project n To determining the development effort: n First look for similarities n then look for differences n and create a conceptual design! Conceptual design n The goal is to better understand the problem n Key requirements n Draft architecture n Experiments! n Estimate the parts n Easier than estimate the full piece at once n Never confuse conceptual with actual design n Conceptual design is meant for estimating n It will be redo if you win the bid

3 Estimate before you begin the work n More information than during the bid n Team n Technology n Processes n Requirements n n The goal is to create a detailed estimate n The estimation result may be different from the one got in the bid n Understand why n Needed to create a project plan Estimate as you go n Have customers ever changed requirements? n All the time! n Some reasons to revise: n Correct errors n Reflect changes in assumptions n Reflect changes in project scope n Reflect changes in the project calendar n Reflect changes in the team n Respond to changes in the approach taken to complete an activity n n The goal: understand where you are! Estimation approaches n Process oriented techniques n Based on a well defined process n Parametric or algorithmic methods n Based on historical data Some process oriented size estimation techniques n The WAG Wild Altogether Guess n Estimation by analogy n Experts judgment n Wideband Delphi WAG - Wild Altogether Guess n Extremely useful when dealing with a totally new area n No historical data is available n No expertise in this new area n No experts to contact n Research turns up no information n The only solution is n Guessing! n But make sure you record everything Estimation by analogy n Identify the similarity dimensions n Based on the software specification n Include application type, size of application, language used, etc. n Compare with other similar projects n Small grain estimation n Do it by considering small pieces of the project n Large grain estimation n Do it by considering large pieces of the project

4 Experts judgment n Involves consulting with human experts to use their experience and understanding of a project n Pay attention to the differences between past projects and the proposed project n Pay attention impacts caused by new technologies, applications, and languages n Nice complement to other estimation methodologies n The estimates are as good as the expertise and judgment of the expert n Hard to define and document Wideband Delphi n Six step process 1. Planning n Define the scope of the problem n Break large problems into smaller 2. The Kick-off n Handle the problem to the estimation team 3. Individual preparation n Individual estimates on problem parts n All assumptions are written down 4. Estimation Meeting n Team gets together 5. Assembling Tasks n Put together the estimates on the several parts 6. Review Results n Team reviews the final results Wideband Delphi estimation meeting Rounds in Wideband Delphi n Moderator collects the estimates for the part being estimated n Estimates are anonymous n Data is presented as a average or a line with all estimates n The estimate is discussed and assumptions are presented n Moderator ask for a new estimate n Values are again presented to the team and discussed n The process end when: n Four rounds are completed n The estimates converged n The meeting time is complete n All participants are unwilling to change their estimates n minutes per item discussed Round #4 Round #3 Round #2 Round #1 X X X X X Some rules n Use an heterogeneous team n Different points-of-view are important n Write down and discuss assumptions n Critical! n Make anonymous estimates n Avoids the follow the boss approach n Never estimate too large tasks n Be sure the team is comfortable with the granularity of the task being estimated Parametric or Algorithmic Methods n Uses equations to create software estimates n Pros: n Able to generate repeatable results n Easy to modify input data n Easy to refine and customize formulas n Disadvantages: n Questionable results when estimating future projects with new technologies n Equations are unable to deal with exceptional conditions such as exceptional teamwork

5 Function points n Based on the program characteristics n External inputs n External outputs n User interactions n External interfaces n Files used n A weight is associated to each of these characteristics n FP count is modified by the complexity of the project n Can be used to estimate LOC based on a language factor n LOC = AVC * number of function points n AVC is a well-defined language-dependent factor n FPs can be very subjective n Depend on the estimator Estimate the system size System Elements and their Complexity Description Low Medium High Total Inputs x 3 x 4 x 6 Outputs x 4 x 5 x 7 Queries x 3 x 4 x 6 Files x 7 x 10 x 15 Program x 5 x 7 x 10 Interfaces TOTAL UNADJUSTED FUNCTION POINTS Compute the technical complexity factor (TCF) n Assign a value from 0 to 5 to each of 14 factors n 0 Not present n 5 Strong influence n Add 14 numbers n Total degree of influence (DI) n TCF = x DI n Technical complexity factor (TCF) lies between 0.65 and 1.35 n The number of function points (FP) is given by n FP = UFP x TCF Convert FP to SLOC Language Access C C ++ COBOL Excel HTML JAVA Javascript Oracle Perl Powerbuilder SQL VBScript Visual Basic Web Scripts LOC/Function Code Point Source: Quality Software Management ( Calculate FP Information Domain Value Count Weigthting Factor Simple Average Complex External Inputs (EI) 3 x = 9 External Outputs (EO) 2 x = 8 External Inquiries (EI) 2 x = 6 Internal Logical Files (ILF) 1 x = 7 External Interface Files (EIF) 4 x = 20 UFP 50 n FP = UFP x [ x DI] n Total degree of influence? n FP? n Assume a moderately complex product n DI = 42 n 54 n How may lines of Java Code? n 3348 SLOC 29 CMU/UC MSE Questions/Comments? Marco Vieira Departamento de Eng. Informática Universidade de Coimbra mvieira@dei.uc.pt 5