Software Estimation. Tutorial. Presented by Dongwon Kang

Transcription

1 Software Estimation Tutorial Presented by Dongwon Kang c KAIST SE LAB 2008

2 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 c KAIST SE LAB / 29

3 Introduction (1/3) What is software estimation? Predicting the resources required for a software development process 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 c KAIST SE LAB / 29

4 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) c KAIST SE LAB / 29

5 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 the inaccuracy of estimates! c KAIST SE LAB / 29

6 Overview of the estimation process (1/2) Total Estimation cycle BEFORE Requirements Environmental and business factors Staff Skill and Availability Define Project (Products, Process) Work Breakdown Structure Identify and Evaluate Risks Estimate Cost and Schedule Re-estimate Cost and Schedule Project Estimate Budget and Schedule Project Plan DURING Changes in Requirements, Design and Environment Perform Planned Activities Project Actuals AFTER Documented Estimation Models Enhancements Calibrate Revised Inputs Compare Planned and Actual Values Close out report Organization s Historical Data Status and Estimate to Complete Update Procedures and Checklists Improve Process Source : R. Stutzke, Estimating Software-intensive Systems 6 / 29

7 Overview of the estimation process (2/2) Technical view using various techniques history data Project characteristics Estimating project size SLOC Function Point Estimating effort Top-down estimation Apply productivity Use Case Point Algorithmic Algorithmic Models Models Analogy Analogy Estimated effort Experts Expert Expert judgment judgment Bottom-up estimation c KAIST SE LAB / 29

8 Software Sizing Methods Estimating Source Lines of Code Function Point Use case Point c KAIST SE LAB / 29

9 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 c KAIST SE LAB / 29

10 Characteristics Function Point (1/4) User (functional) view of software Calculated from system requirements Counts attributes of the planned system Inputs, outputs, inquiries, internal logical files, external interface files External Inquiries System Boundary Internal Files External Outputs External Interface File External Inputs Standard is maintained by IFPUG In Korea, FP is used as a pricing standard of software development c KAIST SE LAB / 29

11 Attributes External Inputs (EI) Function Point (2/4) 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 another applications, used for reference purposes only Ex) help message, reference data c KAIST SE LAB / 29

12 Calculating unadjusted function point (UFP) 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 10 External Inquiry x 3 x 4 x 6 UFP 3 i 1 Function Point (3/4) 5 j 1 w ij x ij (Weight is given by the number of data types, number of fields, etc.) Calculating adjusted function point (AFP) AFP UFP VAF VAF ( ) (VAF considers characteristics of the environment and complexity of product) 14 i 1 r i c KAIST SE LAB / 29

13 Function Point (4/4) Value adjustment factor (VAF) 1. Data communications 2. Distributed functions 3. Performance 4. Heavily used configuration 5. Transaction rate 6. Online data entry 7. End user efficiency 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitates change 0 No Influence 5 Very Influential c KAIST SE LAB / 29

14 Characteristics Use Case Point (1/2) 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 environmental factors c KAIST SE LAB / 29

15 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) = *Tfactor Derived from Function Points Environmental Factor (EF) = (-0.03*EFactor) Based on the interview from Objectory c KAIST SE LAB / 29

16 Comparison of sizing methods SLOC Function Point Use Case Point Viewpoints Developer User (functionality) User (functionality) Collecting phase Early After basic requirement analysis Understandability of concepts Ease of collecting data from previous projects Subjectivity of estimation Expertise needed for estimation Limitations Easy Not intuitive and difficult to communicate After identifying use cases Relatively easy Easy to automate Difficult to automate Requires use-case document High Experience needed Unable to reflect complexity / Dependent on languages / not suitable for web or IDE Relatively objective, but still easy to get biased according to estimators Specialized training needed Hard to reflect internal complexity / Time consuming / Hard to apply to a corrective maintenance project Subjective creation of use cases None Granularity of use cases may vary according to analysts c KAIST SE LAB / 29

17 Techniques for estimation Algorithmic models Expert judgment Analogy Estimation Method Top-down and bottom-up estimation c KAIST SE LAB / 29

18 Characteristics Algorithmic models (1/3) 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 each organization Information of a new project environment need to be updated to the model c KAIST SE LAB / 29

19 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 productivity information 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 more information about the system is available Reuse model Used to compute the effort of integrating reusable components c KAIST SE LAB / 29

20 Algorithmic models (3/3) Example - COCOMO II (Cont d) Early design model and post-architecture model utilize the form of formula Effort = A x Size B 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 c KAIST SE LAB / 29

21 Characteristics Expert judgment 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 their estimates varied widely 6. Experts fill out forms again anonymously and Step 4 to 6 are iterated for as many rounds as appropriate c KAIST SE LAB / 29

22 Characteristics Effort is estimated by comparing the project to a similar project in the same application domain Estimation can be done either at the total project level or at a subsystem 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 ( c KAIST SE LAB / 29

23 Comparison of estimation techniques Algorithmic models Expert judgment Analogy Approach Building statistical model Depending on experts opinion Need for data Yes (for calibration) No Yes Need for expert Low High Low Measuring similarity and adjustment Strong point Objective, repeatable, analyzable formula / Suitable for sensitivity analysis Relatively cheap estimation / Accurate if experts have direct experience of similar systems Based on actual experience on a project Week point Weak against exceptional circumstances / calibrated to past, not future / No better than participants / The result may be biased Requires accurate details on many past projects / Doesn t work if similar project doesn t exist / Hard to define the similarity between projects c KAIST SE LAB / 29

24 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 system functionality 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 technical problems c KAIST SE LAB / 29

25 Top-down and bottom-up estimation (2/4) Bottom-up Start at the component level and estimate the effort required for each component Usable when the architecture of the system is known and components identified Accurate if the system has been designed in detail May underestimate the costs of system level activities such as integration and documentation c KAIST SE LAB / 29

26 Top-down and bottom-up estimation (3/4) Process-based estimation Most commonly-used technique for project estimation Project is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimated Bottom up estimation Process Begins with outlining software functions obtained from the project scope Once functions and activities are identified, the planner estimates the effort (person-months) required to accomplish each activity per function 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 c KAIST SE LAB / 29

27 Top-down and bottom-up estimation (4/4) Process-based estimation (Cont d) Example CAD software Activity CC Planning Risk analysis Engineering Release CE Totals Task Anal. Design Code Test Function UICF n/a DGA n/a 7.10 CGDF n/a 8.50 DBM n/a 6.00 PCF n/a 4.50 DAM n/a 5.00 Totals % effort 1% 1% 1% 7% 45% 12% 40% CC: Customer communication CE: Customer evaluation UICF: User interface and control facilities 3DGA: Three-dimensional geometric analysis CGDF: Computer graphics display facilities DBM: Database management PCF: Peripheral control function DAM: Design analysis modules c KAIST SE LAB / 29

28 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 c KAIST SE LAB / 29

29 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 c KAIST SE LAB / 29

30 Q & A?