Why estimations? Chair of Softw are Engineering Software - PDF document

Why estimations? Chair of Softw are Engineering Software Engineering Project Change Price selection (bids) requests Prof. Dr. Bertrand Meyer March 2007 – June 2007 Costs Lecturer: Hermann Lehner (http://sct.inf.ethz.ch/h) Based on estimations Slides: Based on KSE06 – With kind permission of Peter Müller Duration Schedule Resources Hiring Lecture 6: Estimation Techniques Milestones Resource allocation Estimations in software projects Overview � Mostly personnel cost Estimation Techniques Costs (effort) Empirical Estimations � Travel, training Algorithmical Estimations � Hardware, Estimation Process software Duration is Effort essentially effort / resources Schedule Resources Estimation Exercise Overview � How many passenger planes does Lufthansa have? Estimation Techniques � Not counting regional subsidiaries Empirical Estimations Algorithmical Estimations Estimation Process � How can we approach this problem systematically?

Empirical estimation: Expert judgment Top-down estimation � Estimation by analogy � Estimate is based on experience and historical data � Comparison with similar projects � Analysis of differences � Typical example: SAP introduction � Involve experts in � Development techniques Pros Cons � Application domain � Quicker and less � Underestimation of expensive than other difficult technical methods problems likely � Most common technique in practice � Can be done early in the � No detailed justification project of estimate � Be aware of scalability problems! Top-down estimation: Delphi method Top-down estimation: Typical figures Step 1: Each expert submits � Typical figures for software development � Estimate � Justification � Analysis 20% Analysis � Design 40% Test Step 3: Each expert � Implementation 15% submits � New estimate � Test 25% Design � Justification of Implementation deviation from average of previous estimates � Very helpful to validate estimations � More accurate than ordinary expert judgment � Eliminates outliers � More expensive to produce Bottom-up estimation Program evaluation and review technique � Estimation by decomposition � Goal: Manage probabilities with simple statistics � Estimating the effort for individual work packages � Approach: Ask several experts for three estimates � Cost and accuracy depend on size of the work � Optimistic, Likely (mode), and Pessimistic packages � Important formulas Pros Cons � Mean M = ( O + 4 × L + P ) / 6 � See “cons” of top-down � Underestimation because � Deviation V = ( P – O ) / 6 estimation effort does not grow � Assumptions linearly (due to � Project effort is normally distributed complexity, etc.) (more than 20 work packages) � Underestimation of integration effort � Work package efforts are statistically independent (ignores single underlying cause of delay) � Requires initial system design

Overview Algorithmic estimation of software � Basic cost model Estimation Techniques Effort = A × Size B × m(X) Empirical Estimations Algorithmical Estimations Size: Some measurement of the software size Estimation Process A: Constant factor that depends on Organizational practices Type of software B: Usually lies between 1 and 1.5 X: Vector of cost factors m: Adjustment multiplier Cost models Measuring size: Lines of code � Software size can be measured in lines of source code Effort = A × Size B × m(X) � Most commonly used metric � Cost models � Define a way to determine the size � Difficult in early phases of the project (before design is known) � Define cost factors X � Reuse, make-or-buy decisions � Provide defaults for parameters A, B, m (based on hundreds of projects) � Influenced heavily by choice of programming language � Important examples � Should only be used indirectly � Function point analysis � Constructive cost model (COCOMO) Function point analysis Functions � Inputs � Size is estimated based on requirements � Forms, dialogs, messages, XML documents � Outputs � Web pages, reports, graphs, messages, XML Inputs documents Internal files � Inquiries (input/output combinations) Inquiries Function � Simple web inputs, generally producing a single output � Logical internal files (controlled by the program) External files � Tables, views or files in database Outputs � External files (controlled by other programs) � Tables or files used from other systems or databases

Complexity of functions Cost factors Rate each element from 0 – 5 Factor Simple Average Complex Data communications Distributed processing � 0: no influence Inputs 3 4 6 Performance � 1: insignificant influence Outputs 4 5 7 Heavy use � 2: moderate influence Inquiries 3 4 6 Transaction rate Online data entry Ext. files 7 10 15 � 3: average influence Complex interface Int. files 5 7 10 � 4: significant influence Online data update � Determine � 5: strong influence Complex processing complexity of Reusability Technical complexity factor Input Simple Average Complex each function Installation ease � TCF = 0.65 + 0.01 × sum Data 1-5 6-10 >10 Operational ease � Weight each elements � Varies between 0.65 and 1.35 Multiple sites function Checking Formal Formal, Formal, logical, Facilitate change according to logical requires DB access complexity Function point computation Determining effort and size � Empirical value for effort Effort = FP 1.4 / 150 � Or use a table � Empirical value for size � Huge differences in productivity � Factor 10-20 between individual programmers � Factor 4 between companies Adjusted function points : FP = UFP × TCF Observation about software size Function point analysis: Discussion � Consider a project that requires 10 Web pages, Pros Cons 15 reports, and 20 database tables � Based on requirements � Estimation of overall � 315 function points, if each item is medium complexity (instead of code size) effort (not per phase) � How many lines of C code would it have? � Can be applied in early � Tailored towards project phases functional decomposition � About 32,000 lines (rather than OO) � Can be calibrated (for � What if you used Excel? company, project type) � Tailored towards � About 2,000 lines information systems � Counting standards by “International Function � Needs calibration to � Why do you think there are so many spreadsheets out Points User Group” produce reliable results there? � Technology-independent

Estimation techniques: Discussion Other estimation strategies Empirical Estimation Algorithmic Estimation Parkinson’s Law Pricing to win Empirical studies � Accurate if experts are � Very accurate if model is � Work expands to fill the � Cost is estimated to � Do not show that uncalibrated algorithmic estimation experienced calibrated time available whatever the customer is is, in general, more accurate willing to spend � Experts can be strongly � Calibration is very - Gold plating � Show that algorithmic estimation is more accurate biased (over-optimism) difficult and expensive � Effort is determined by � Common strategy to win than experts who do not have important domain available resources projects � Estimation is expensive knowledge � Important for team � Features are negotiated management later, constrained by agreed costs � Costs are fixed, not requirements Overview Estimate types Rough order of Budgetary Definitive magnitude Estimation Techniques Empirical Estimations -25 / +75% -10 / +25% -5 / +10% Algorithmical Estimations Estimation Process Initial estimates Decision making, Project plan, response to proposals proposals � Refine your estimates at each project stage � Requirements document, system design, detailed design, working code Estimating process Estimation tips Determine Select Estimators, • Avoid off-the-cuff • Estimate at a low level Establish project strategy and type of validation, objectives estimates of detail details plan historic data • Allow time for the • Don’t omit common tasks estimate, and plan it Why? Accuracy? (management; use Generate Audience? • Use historic data checklists ) effort estimate • Use developer-based • Use different estimates Duration = √ Effort techniques and compare Duration = 3.0 × Effort 1/3 • Estimate by walkthrough Determine the results Document (Effort in person months, team size and • Estimate by categories assumptions • Change estimation Duration in months) duration � e.g. easy, medium, hard practices as the project Effort = Duration × Team Size progresses Validate and Document finalize Different method, review