Upcoming SlideShare
×

# 3 Estimation

4,857 views

Published on

• Full Name
Comment goes here.

Are you sure you want to Yes No

Are you sure you want to  Yes  No

### 3 Estimation

1. 1. SoberIT Software Business and Engineering Institute Previous lecture: Processes… HELSINKI UNIVERSITY OF TECHNOLOGY
2. 2. SoberIT Software Business and Engineering Institute Process Choice   There are several factors Risks ~ that affect which type of -  novelty of process you should use: methods, tools,   Product type application   Business type Iterative, prototyping domain   Project size - fuzziness of requirements   Project initial Incremental uncertainty   Environmental uncertainty   Organizational culture Plan-driven   … Product size/complexity HELSINKI UNIVERSITY OF TECHNOLOGY
3. 3. Dimensions Affecting Process Model SoberIT Selection and Engineering Institute Software Business Personnel (Boehm & Turner 2003) (Percent level 1B) (Percent level 2 and 3) 40 15 30 20 20 25 Criticality Dynamism (Loss due to impact (Percent requirements on defects) Single 10 30 change/month) life Discretionary Many 1 funds 0 35 5 lives 10 Essential funds 30 Comfort 50 3 90 Ag 10 ile 70 Pla 30 n-d r ive 50 n 100 Size 30 300 Culture (# of HELSINKI UNIVERSITY OF TECHNOLOGY (% of thriving on chaos vs. order) personnel) 10 Size Culture (Number of personnel) (Percent thriving on chaos versus order)
4. 4. SoberIT Software Business and Engineering Institute T-76.5612 Software Project Management Spring 2010 3: Software estimation Tuomas Niinimäki Department of Computer Science and Engineering Helsinki University of Technology HELSINKI UNIVERSITY OF TECHNOLOGY
5. 5. SoberIT Software Business and Engineering Institute What is estimation? HELSINKI UNIVERSITY OF TECHNOLOGY
6. 6. SoberIT Software Business and Engineering Institute What is estimation? In mathematics, use of a function or formula to derive a solution or make a prediction. Unlike approximation, it has precise connotations. In statistics, for example, it connotes the careful selection and testing of a function called an estimator. In calculus, it usually refers to an initial guess for a solution to an equation, which is gradually refined by a process that generates closer estimates. The difference between the estimate and the exact value is the error. (Encyclopedia Britannica Concise) HELSINKI UNIVERSITY OF TECHNOLOGY
7. 7. SoberIT Software Business and Engineering Institute Why would we want to estimate software? HELSINKI UNIVERSITY OF TECHNOLOGY
8. 8. SoberIT Software Business and Engineering Institute The use of estimates (1/3) Phase / Activity Why The question answered Strategic Planning Finding out potential Could we do this more efficiently than application domains the others? Prioritizing projects Should we emphasize this project over the others? Feasibility study Cost-benefit analysis, Is the project worth doing? making a bid (Adapted from Boehm, 2000, Hughes & Cotterell, 2002) HELSINKI UNIVERSITY OF TECHNOLOGY
9. 9. SoberIT Software Business and Engineering Institute The use of estimates (2/3) Phase / Activity Why The question answered Evaluation of Evaluating project cost How much should we pay for this suppliers’ project? proposals Evaluating supplier’s Is this bidding realistic? proposals Has the supplier understood the requirements? Project Planning Budgeting How much is the project going to cost? Resourcing and How long is the project going to take? Scheduling How does the resourcing decisions affect it? (Adapted from Boehm, 2000, Hughes & Cotterell, 2002) HELSINKI UNIVERSITY OF TECHNOLOGY
10. 10. SoberIT Software Business and Engineering Institute The use of estimates (3/3) Phase / Activity Why The question answered System Requirements analysis How long does it take to implement a specification feature/requirement? Which features will take the most effort? Project execution Iteration-level plans How much effort do the different tasks take? Making trade-offs Should I leave this feature out to match the schedule wishes? (Adapted from Boehm, 2000, Hughes & Cotterell, 2002) HELSINKI UNIVERSITY OF TECHNOLOGY
11. 11. SoberIT Software Business and Engineering Institute What to estimate in software project? HELSINKI UNIVERSITY OF TECHNOLOGY
12. 12. SoberIT Software Business and Engineering Institute What to estimate in software project? Effort Schedule Size HELSINKI UNIVERSITY OF TECHNOLOGY
13. 13. SoberIT Software Business and Engineering Institute What to estimate in software project? Resources Effort Schedule Size Time Scope HELSINKI UNIVERSITY OF TECHNOLOGY
14. 14. SoberIT Software Business and Engineering Institute What can be estimated in software?   Software size   Lines of code?   Number of classes / methods?   Amount of database tables / queries / user views?   Functionality?   Effort   Person-hours   Schedule   Calendar-days or months HELSINKI UNIVERSITY OF TECHNOLOGY
15. 15. SoberIT Software Business and Engineering Institute Derived estimates (examples)   Software size   Potential / probable number of defects   Probable number of change requests   …   Effort   Project cost   Team size   Schedule   Suitable number of iterations / milestones HELSINKI UNIVERSITY OF TECHNOLOGY
16. 16. SoberIT Software Business and Engineering Institute Project cost drivers (from COCOMO81) … or even better, Use the relevant cost drivers for your project /organization HELSINKI UNIVERSITY OF TECHNOLOGY
17. 17. SoberIT Software Business and Engineering Institute How to estimate software?   Estimation process in a nutshell: 1 2 3 Estimate the size of the product Estimate the effort Estimate the schedule   Provide the estimates in ranges   Periodically refine the ranges to provide increasing precision as the project progresses (McConnell, Rapid Development, 1996) HELSINKI UNIVERSITY OF TECHNOLOGY
18. 18. SoberIT Software Business and Engineering Institute Problems in software estimation (1/6)   Basic problem: Predicting the future by looking into the past HELSINKI UNIVERSITY OF TECHNOLOGY http://www.flickr.com/photos/wabbit42/3691518084/ CC BY-NC-SA 2.0
19. 19. SoberIT Software Business and Engineering Institute Problems in software estimation (2/6)   A lack of good historical information   Does the historical information have such metrics that distinguish the previous projects from each others?   Does the historical data contain enough cases to make a reliable estimation?   Can these metrics describe the project you are estimating?   Do we have the right metrics to measure the project environment? HELSINKI UNIVERSITY OF TECHNOLOGY
20. 20. SoberIT Software Business and Engineering Institute Problems in software estimation (3/6)   A lack of information on the project to be estimated   Most influential decisions are made in the early phases of project, based on inadequate information   Important information is not available   ... or there simply is not enough time to collect it HELSINKI UNIVERSITY OF TECHNOLOGY
21. 21. SoberIT Software Business and Engineering Institute Problems in software estimation (4/6)   Estimates are done sloppily   ”If they cannot be done perfectly, why pay attention to them?”   There can be a order-of-magnitude difference between a careful and a sloppy estimate   There are no “final estimates” - they can (and should!) be updated whenever new information becomes available HELSINKI UNIVERSITY OF TECHNOLOGY
22. 22. SoberIT Software Business and Engineering Institute Project Cost Project (effort and size) schedule 4× 1.6× 2× 1.25× 1.5× 1.15× 1.25× 1.1× 1.0× 1.0× 0.8× 0.9× 0.67× 0.85× 0.5× 0.8× 0.25× 0.6× Initial Approved Requirements Product Detailed Product product product specification design design complete HELSINKI UNIVERSITYdefinition definition OF TECHNOLOGY specification specification
23. 23. SoberIT Software Business and Engineering Institute Problems in software estimation (5/6)   Estimates are not updated   Estimating is done only in the beginning of the project, based on incomplete information   New estimates are not done, but the old estimates are still followed   As new information becomes available, estimates should be updated   Estimates can be used in various stages of software project   e.g. size estimation for estimating the number of bugs HELSINKI UNIVERSITY OF TECHNOLOGY
24. 24. SoberIT Software Business and Engineering Institute Problems in software estimation (6/6)   Estimates are not followed, respected or trusted   An estimate should not be an opinion   An opinion can be overruled by your superior   An estimate is not automatically a commitment   ... but may be considered as such   Justify and criticize the estimates   Accept uncertainties   Visualize probabilities HELSINKI UNIVERSITY OF TECHNOLOGY
25. 25. SoberIT Software Business and Engineering Institute Estimation in practice HELSINKI UNIVERSITY OF TECHNOLOGY
26. 26. SoberIT Software Business and Engineering Institute Tools for estimation   Work breakdown structure   Product breakdown structure   Top-down estimation   Bottom-up estimation HELSINKI UNIVERSITY OF TECHNOLOGY
27. 27. SoberIT Software Business and Engineering Institute Work breakdown structure   Work Breakdown Structure (WBS) is a graph (a tree) of activities done during the project   Each activity is broken down into tasks, until desired level of detail is reached   A task must contain work related only to their parent activity   The top-level activity (= project) must contain 100% of work in the project   For each node, the sum of work shares in its sub-activities must be 100%   A desired level of detail for tasks is usually the size of task that can be allocated to a single person   Maximum size is usually 10-20 hours HELSINKI UNIVERSITY OF TECHNOLOGY
28. 28. SoberIT Software Business and Engineering Institute Example: Work breakdown structure Project Specification Implementation Testing Delivery Eliciting Implementing Testing Installing requirements module A module A software Analyzing Implementing Testing Training requirements module B module B Writing req. Implementing Testing specification doc. module C module C Creating Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
29. 29. SoberIT Software Business and Engineering Institute Product breakdown structure   Product Breakdown Structure (PBS) is a similar construct as WBS, but is based on the structure of product rather than the type of activities   Lower levels in PBS describe the structure of item on level above   The top level of PBS is the product   Second level may consist of the major components of the product   Lowest level should contain items that are “comprehensible” HELSINKI UNIVERSITY OF TECHNOLOGY
30. 30. SoberIT Software Business and Engineering Institute Example: Product breakdown structure Product Documentation Software Project plan Module A Requirements Class A_x Module B specification Class A_y Architecture Class A_z Module C specification User manual Main module HELSINKI UNIVERSITY OF TECHNOLOGY
31. 31. SoberIT Software Business and Engineering Institute Top-down estimation   Idea: Allocate proportions of an effort estimate to different activities of the project   Inputs: Main project activities (high level design) and earlier project data on efforts spent for activities   Outputs: Rough work breakdown with corresponding effort estimates   Advantages   Takes into account integration, configuration management and documentation costs (e.g. algorithmic models seldom take)   Disadvantages   Underestimating the difficult low-level technical problems HELSINKI UNIVERSITY OF TECHNOLOGY
32. 32. SoberIT Software Business and Engineering Institute Example: Top-down estimation 100 % 800 h Project Specification Implementation Testing Delivery Eliciting Implementing Testing Installing requirements module A module A software Analyzing Implementing Testing Training requirements module B module B Writing req. Implementing Testing specification doc. module C module C Creating Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
33. 33. SoberIT Software Business and Engineering Institute Example: Top-down estimation 100 % 800 h Project 20 % 40 % 30 % 10 % Specification h 160 Implementation h 320 Testing 240 h Delivery 80 h Eliciting Implementing Testing Installing requirements module A module A software Analyzing Implementing Testing Training requirements module B module B Writing req. Implementing Testing specification doc. module C module C Creating Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
34. 34. SoberIT Software Business and Engineering Institute Example: Top-down estimation 100 % 800 h Project 20 % 40 % 30 % 10 % Specification h 160 Implementation h 320 Testing 240 h Delivery 80 h 50 % Eliciting Implementing Testing Installing 80 h requirements module A module A software 30 % Analyzing Implementing Testing 48 h requirements Training module B module B 10 % Writing req. Implementing Testing 16 hspecification doc. module C module C 20 % Creating Integrating Integration 16 h architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
35. 35. SoberIT Software Business and Engineering Institute Bottom-up estimation   Idea: Calculate the total effort from the sum of effort estimations of single tasks (by analogy estimation or expert judgement)   Inputs: Detailed work breakdown (tasks 1-2 weeks for 1 person), descriptions of factors affecting production   Outputs: Effort estimates on individual tasks, total effort   Advantages   If the task division is accurate, the model may provide the most accurate estimates   Disadvantages   Underestimates costs of system level (e.g. integration and documentation)   Needs detailed breakdown of project tasks HELSINKI UNIVERSITY OF TECHNOLOGY
36. 36. SoberIT Software Business and Engineering Institute Example: Bottom-up estimation Project Specification Implementation Testing Delivery Eliciting 60 Implementing h Testing Installing requirements module A module A software Analyzing Implementing Testing Training requirements module B module B Writing req. Implementing Testing specification doc. module C module C Creating Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
37. 37. SoberIT Software Business and Engineering Institute Example: Bottom-up estimation Project Specification Implementation Testing Delivery Eliciting 60 Implementing h Testing Installing requirements module A module A software Analyzing 80 Implementing h Testing Training requirements module B module B Writing req. 45 Implementing h Testing specification doc. module C module C Creating 68 h Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
38. 38. SoberIT Software Business and Engineering Institute Example: Bottom-up estimation Project 252 h Specification Implementation Testing Delivery Eliciting 60 Implementing h Testing Installing requirements module A module A software Analyzing 80 Implementing h Testing Training requirements module B module B Writing req. 45 Implementing h Testing specification doc. module C module C Creating 68 h Integrating Integration architecture plan modules testing Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
39. 39. SoberIT Software Business and Engineering Institute Example: Bottom-up estimation 695 h Project 272 h 252 h 100 h 70 h Specification Implementation Testing Delivery 68 h Eliciting 60 Implementing h 20 h Testing Installing 10 h requirements module A module A software 68 h Analyzing 80 Implementing h 20 h Testing 60 h Training requirements module B module B 68 h Writing req. 45 Implementing h 20 h Testing specification doc. module C module C 68 h Creating 68 h Integrating 20 h Integration architecture plan modules testing 20 h Acceptance testing HELSINKI UNIVERSITY OF TECHNOLOGY
40. 40. SoberIT Software Business and Engineering Institute Estimation techniques HELSINKI UNIVERSITY OF TECHNOLOGY
41. 41. SoberIT Software Business and Engineering Institute Estimation techniques   Estimation by analogy   Expert judgment   Agile estimation   Algorithmic models   Albrecht & MarkII function points   COCOMO 81 and COCOMO II HELSINKI UNIVERSITY OF TECHNOLOGY
42. 42. SoberIT Software Business and Engineering Institute Estimation by analogy (1/2)   Idea: Finding similar cases to the target project   Inputs: Earlier projects, each described with p features   Outputs: Project size, effort estimate, schedule estimate, (estimation error) HELSINKI UNIVERSITY OF TECHNOLOGY
43. 43. SoberIT Software Business and Engineering Institute Example: Estimation by analogy ce ce n n o n s e ti n th e ri ts p o ri e ts n ri ti in e e p o sc ta n d p o x m y e co x p e n e it ze m e d e r rm n x a f m e si in le g io ct o n d ir in le o a p g ct n m je s u l tf m ta m si le st e p q n a ro la n Im o e e o a o Fu e e Li D D R P P C C T T T Project time tracking software 41 246 246 287 820 6.3 1 140 8300 Very low Nominal Very high Customizable user register module 25 50 138 37 250 3.2 1 40 2300 Low High High Mobile calendar and email application 525 1575 700 700 3500 12 3 310 22000 Nominal Very low Nominal Intranet product 237 316 553 474 1580 11 1 260 18200 Low High Nominal Web survey tool 105 126 84 105 420 2 2 92 5200 Nominal High Low   For new project:   Lines of code?   Complexity? Finding similar Deriving estimate (inter/extrapolation)   Platform experience? earlier projects from actual outcomes   Domain experience? HELSINKI UNIVERSITY OF TECHNOLOGY
44. 44. SoberIT Software Business and Engineering Institute Estimation by analogy (2/2)   Advantages   If done systematically, the estimate can be justified to project stakeholders   If a good analogy is found, the estimation can be fairly accurate   Tool support (e.g. ANGEL, http://dec.bournemouth.ac.uk/ESERG/ANGEL/)   Disadvantages   The feature data on earlier projects is limited   There may not be an analogous project in the project data set   Choosing the right features for finding analogous project   The significance of many features only becomes visible afterwards  It might not be documented systematically even in earlier projects   By definition, no project is exactly equivalent HELSINKI UNIVERSITY OF TECHNOLOGY
45. 45. SoberIT Software Business and Engineering Institute Estimation techniques   Estimation by analogy   Expert judgment   Agile estimation   Algorithmic models   Albrecht & MarkII function points   COCOMO 81 and COCOMO II HELSINKI UNIVERSITY OF TECHNOLOGY
46. 46. SoberIT Software Business and Engineering Institute Expert judgment (1/4)   Idea: Ask the required estimate from persons that have previous experience on some parts of the problem   Inputs: Descriptions of problem domain, technology or other affecting factors   Outputs: Project size, effort estimate, schedule estimate (in all varying metrics)   Dominant technique for effort estimation (Jorgensen, 2004) HELSINKI UNIVERSITY OF TECHNOLOGY
47. 47. SoberIT Software Business and Engineering Institute Expert judgment (2/4)   Who are the experts?   Your own developers   Domain experts   Technology experts   Other project managers   Non-technical people may be better at estimating than technical people   Skilled technical personnel tend to be overoptimistic   Varying background (employment, education, domain experience) of estimators can improve the estimates   Different backgrounds yield different estimation strategies HELSINKI UNIVERSITY OF TECHNOLOGY
48. 48. SoberIT Software Business and Engineering Institute Expert judgment (3/4)   In practice expert judgment estimates are derived from analogies to earlier projects   Experience on similar projects is crucial   Require justification for estimates, so that they can be reviewed HELSINKI UNIVERSITY OF TECHNOLOGY
49. 49. SoberIT Software Business and Engineering Institute Expert judgment (4/4)   Advantages   Cheap and fast   Easy to adapt to changing situations (a judgement can be made based on whatever information is available)   If developers are making the estimates, they are more committed to them   More accurate than algorithmic methods, if the experts have good domain knowledge and the project is of low uncertainty   Disadvantages   The analogies or evaluation criteria cannot be easily made visible  How to distinguish good estimates from bad ones?   Underestimation of large tasks and overestimating small   Can be strongly biased by information that is irrelevant for the estimates (e.g. schedule constraints) HELSINKI UNIVERSITY OF TECHNOLOGY
50. 50. SoberIT Software Business and Engineering Institute Estimation techniques   Estimation by analogy   Expert judgment   Agile estimation   Algorithmic models   Albrecht & MarkII function points   COCOMO 81 and COCOMO II HELSINKI UNIVERSITY OF TECHNOLOGY
51. 51. SoberIT Software Business and Engineering Institute Agile estimation (Scrum) (1/5) Strategic Release Management Release Project Cycle 3 months Sprint 1 month   Time-paced (heartbeat - sprint - release project - strategic)   Time is fixed, scope can change   User requirements come as “user stories”   “Things to do” (tasks) are stored in product & sprint backlog HELSINKI UNIVERSITY OF TECHNOLOGY
52. 52. SoberIT Software Business and Engineering Institute Agile estimation (Scrum) (2/5)   Each feature (a “user story”) is assigned a number of points   This number represents how hard / time consuming it is to complete this feature Story A Story B Story C Story D 3 pt 5 pt 4 pt 7 pt   What do these numbers mean?   Where do these numbers come from? HELSINKI UNIVERSITY OF TECHNOLOGY
53. 53. SoberIT Software Business and Engineering Institute Agile estimation (Scrum) (3/5)   They do not mean much individually (they are relative)   They come out from team “consensus”   Delphi method, planning poker Story A Story B Story C Story D 3 pt 5 pt 4 pt 7 pt I think B is much more work than A (B = ~2 x A) I guess A would be quite I agree, but I think D simple to do (A = 3) is the hardest one (D ~ A + B) HELSINKI UNIVERSITY OF TECHNOLOGY
54. 54. SoberIT Software Business and Engineering Institute Planning poker 1.  At the start of planning poker, each estimator is given a deck of cards.   Each card has written on it one of the valid estimates (e.g. 1,2,3,5,8,13,…) 2.  For each user story or theme to be estimated, a moderator reads the description.   The product owner answers any questions that the estimators have. 3.  After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection   If estimates differ, the high and low estimators explain their estimates. 4.  After the discussion, each estimator re-estimates by selecting a card. 5.  Continue the process as long as estimates are moving closer together http://www.flickr.com/photos/tomnatt/ CC BY-NC 2.0 HELSINKI UNIVERSITY OF TECHNOLOGY
55. 55. SoberIT Software Business and Engineering Institute Agile estimation (Scrum) (4/5)   After a few sprints   The story points assigned to the user stories start to stabilize   You may start counting the story points implemented per sprint   This measure is called velocity   Velocity tells how many story points can be completed on average during a sprint   However, velocity is not a team performance metric Sprint 1: planned scope = 8 pt Story A Story B Story C Story D 3 pt 5 pt 4 pt 7 pt HELSINKI UNIVERSITY OF TECHNOLOGY
56. 56. SoberIT Software Business and Engineering Institute Agile estimation (Scrum) (5/5)   Velocity tells how many story points can be completed on average during a sprint   Velocity can be used to estimate the amount of work for a new sprint Backlog: sum of points = 11 pt > 8 pt Story C Story D 4 pt 7 pt Sprint 1: implemented => velocity = 8 pt Sprint 2: “maximum” story points = 8 pt Story A Story B 3 pt 5 pt HELSINKI UNIVERSITY OF TECHNOLOGY
57. 57. SoberIT Software Business and Engineering Institute Agile estimation: Summary   Advantages   Simple and comprehensible process   Easy to set up and maintain   Empowers developers (helps in team&project commitment)   Self-calibrating   Disadvantages   Needs active participation, self-organization, motivation   It can be difficult to give reasoning to the story points   It usually takes a number of iterations to stabilize   Long-term estimation is difficult   Stories are created   and story points assigned “just-in-time” HELSINKI UNIVERSITY OF TECHNOLOGY
58. 58. SoberIT Software Business and Engineering Institute Estimation techniques   Estimation by analogy   Expert judgment   Agile estimation   Algorithmic models   Albrecht & MarkII function points   COCOMO 81 and COCOMO II HELSINKI UNIVERSITY OF TECHNOLOGY
59. 59. SoberIT Software Business and Engineering Institute Algorithmic models   Based on an algorithm (procedure of calculation)   Model based on (non-)linear regression   Research on software engineering   Weights and factors derived from past project metrics   Function point methods are used to estimate software size   Constructive cost model (COCOMO) is used to estimate effort based on estimated software size   See course material (Estimation of Software) for more details and examples HELSINKI UNIVERSITY OF TECHNOLOGY
60. 60. SoberIT Software Business and Engineering Institute Function point methods (1/2)   Idea: Quantify the size of programs independently of programming languages   Function point methods are based on historical data   Mathematical model is similar as in (algorithmic) estimation by analogy, but the granularity is finer   Function point methods should be calibrated to each organization   Even though they give one number, they are not necessarily more (or less) accurate than other estimation techniques   Inputs: ”External user types” (Albrecht) or ”transactions” (MarkII)   Outputs: Project size (in function points) HELSINKI UNIVERSITY OF TECHNOLOGY
61. 61. SoberIT Software Business and Engineering Institute Function point methods (2/2)   Advantages   Can be made in early stages of project (e.g. based on requirements or a detailed problem description)   Independent of implementation details or the person estimating   Tool support   Disadvantages   Difficult to apply for application domains which are hard to describe with external user types or transactions   Do not take development process, organization or technology into account (Apply corrective multipliers for deriving person-hours from function points, e.g. COCOMO or data on earlier projects)   Need to be calibrated for each organization   May give false sense of accurate estimates HELSINKI UNIVERSITY OF TECHNOLOGY
62. 62. SoberIT Software Business and Engineering Institute Albrecht function points (1/3)   Based on five major components - the external user types   External input type: input transactions from user that update internal files   External output type: transactions that output data to user   Logical internal file type: data storage used by the system   External interface file type: input/output between different computer systems   External inquiry type: transactions initiated by users that do not update the internal files HELSINKI UNIVERSITY OF TECHNOLOGY
63. 63. SoberIT Software Business and Engineering Institute Albrecht function points (2/3)   Function points are calculated for each activity in the software, including   functionality   reports   data storage   The total function points for a system is the sum of function points for all activities HELSINKI UNIVERSITY OF TECHNOLOGY
64. 64. SoberIT Software Business and Engineering Institute Albrecht function points (3/3)   Steps to calculate function points for an activity: 1. Identify the external user type for the activity 2. Identify the record types used in the activity   Record types could be modeled as classes in OOP   Note that you might need to take a look at other activities to fully determine the record types used in this activity 3. Identify the data types   Data types could be modeled as attributes in OOP 4. Determine component complexity multiplier based on external user type and the amount of record and data types involved   Identifying record and data types requires training to do properly, and can be subjective in some cases HELSINKI UNIVERSITY OF TECHNOLOGY
65. 65. SoberIT Software Business and Engineering Institute MarkII function points   MarkII function points are calculated for activities modeled as transactions:   Input data is data provided by the user   The system then processes the input data, and (possibly) manipulates some internal data (= entity types)   The system outputs data to user   Calculating the total function points for the system is done by calculating the sum of function points of the transactions in the system HELSINKI UNIVERSITY OF TECHNOLOGY
66. 66. SoberIT Software Business and Engineering Institute Constructive cost model (COCOMO)   Idea: Quantify the effort required based on a size estimate   Inputs: ”Lines of code” (COCOMO 81 & II) or ”function points” (COCOMO II), ”cost multipliers”, ”scale factors”   Outputs: Effort estimate (in person-months = 152 person-hours)   COCOMO II dataset is updated continuously, software support is available   Possibly the biggest and most descriptive dataset on software projects HELSINKI UNIVERSITY OF TECHNOLOGY
67. 67. SoberIT Software Business and Engineering Institute Constructive cost model (COCOMO)   The basic model of COCOMO 81 is based on the equation effort = c x sizek   effort = person-months   size = thousands of delivered source code instructions   c,k = constants (depend on the system type)   System types are classified as follows:   Organic mode: relatively small team, highly familiar environment, flexible interface requirements   Embedded mode: very tight constaints on the system   Semi-detached mode: characteristics between organic and embedded mode HELSINKI UNIVERSITY OF TECHNOLOGY
68. 68. SoberIT Software Business and Engineering Institute Constructive cost model (COCOMO)   The intermediate model of COCOMO 81 takes development environment into account via 15 cost drivers, resulting in equation effort’ = effort x dem = c x sizek x dem   effort’ = effort estimate adjusted by cost drivers   effort = original effort estimate from the basic model   dem = development effort multiplier   The 15 cost driver coefficients are multiplied to get the development effort multiplier   Each cost driver is evaluated on scale (very low, low, nominal, high, very high, extra high)   Values for each cost driver are determined from past projects HELSINKI UNIVERSITY OF TECHNOLOGY
69. 69. SoberIT Software Business and Engineering Institute Constructive cost model (COCOMO)   Advantages   Independent of the estimator (provided that the scale factors can be determined objectively)   An effort estimate can be derived quickly if the needed information is available   Disadvantages   Underlying assumption that lines of code or function points are easier to calculate than the effort needed   A company needs a huge dataset of its own projects to calibrate all the scale factors   Risk: you get ”an exact number” HELSINKI UNIVERSITY OF TECHNOLOGY
70. 70. SoberIT Software Business and Engineering Institute What techniques are actually used? Technique McAulay Heemstra Wydenbach 1987 1989 1995 Expert Expert Judgement 26% 86% based Intuition and experience 85% 62% Estimation by Analogy 61% 65% Model Algorithmic Models 13% 14% 26% based Other Price-to-win 8% 16% Capacity related 21% 11% Top-down 13% Bottom-up 51% Other 12% 9% 0% (Moløkken et al.: A Survey on Software Estimation in the Norwegian Industry, 2004) HELSINKI UNIVERSITY OF TECHNOLOGY
71. 71. SoberIT Software Business and Engineering Institute Effort estimation best practices (1/3)   Allow time for making the estimate, and plan it   Use documented data from previous projects   Use developer-based estimates   Estimate by walk-through   Estimate at a low level of detail   Don’t omit common tasks   Use software estimation tools   Use several different estimation techniques, and compare the results   Monitor and adapt estimation practices as the project progresses (McConnell, 1996) HELSINKI UNIVERSITY OF TECHNOLOGY
72. 72. SoberIT Software Business and Engineering Institute Effort estimation best practices (2/3)   Reduce situational and human bias   Find estimation experts with highly relevant domain background and good estimation records   Ask the evaluators to justify and criticize their estimations   Assess the uncertainty of the estimate   Use plus/minus qualifiers or value ranges to indicate the direction of uncertainty or estimation range   Quantify risks – explicate the reasons of uncertainty   Provide estimation feedback and training opportunities   Provide feedback on estimation accuracy and development task relations   Provide estimation training opportunities (Jørgensen, 2004) HELSINKI UNIVERSITY OF TECHNOLOGY
73. 73. SoberIT Software Business and Engineering Institute Effort estimation best practices (3/3)   Use several estimation techniques and compare them   If they converge, you are probably on the right track   Find out why the estimates are different   Delphi method - Combine several expert opinions   Ask each expert to make an estimate independently   Then let each of them present their estimate and reasoning   Based on this discussion, let them adjust their estimation   Iterate until the estimates converge   Ask several different estimates – optimistic, probable and pessimistic – and compare them HELSINKI UNIVERSITY OF TECHNOLOGY
74. 74. SoberIT Software Business and Engineering Institute Exercise 1 best practices   Start early!   Read the exercise carefully!   Read the additional material (especially Estimation of Software)   Estimation is sometimes subjective   Don’t get frustrated!   Sometimes you just have to assume   Remember to give reasoning and make your process visible   Each question is graded separately   Don’t give up!   Keep track of the time you are spending and give feedback! HELSINKI UNIVERSITY OF TECHNOLOGY
75. 75. SoberIT Software Business and Engineering Institute Thank you. Questions? Tuomas Niinimäki tuomas.niinimaki@soberit.hut.fi HELSINKI UNIVERSITY OF TECHNOLOGY
76. 76. SoberIT Software Business and Engineering Institute Examples HELSINKI UNIVERSITY OF TECHNOLOGY
77. 77. SoberIT Software Business and Engineering Institute Example: Albrecht function points   Actual requirement from exercise 1: List category products: This screen lists the product, its name, price, short description, thumbnail image,variations (size, colors and materials) and their stock availability. When clicking a product name or image, a detailed product data screen is activated (see FR3). The user is also able to make an order through this screen (see FR4).   Step 1: Identify the external user type   User type is external inquiry, as no data structures are updated.   Step 2: Identify record types   Category, Product, Customer, Discount   Note that you may have to look into other requirements to identify all records that are present - in this case, the Discount type is stated in a different requirement (not shown here).   Step 3: Identify data types   categoryName, productName, price, shortDescription, smallImage, size, color, material, availability HELSINKI UNIVERSITY OF TECHNOLOGY
78. 78. SoberIT Software Business and Engineering Institute Example: Albrecht function points   Step 4: Determine component complexity multiplier based on external user type and the amount of record and data types involved   External inquiry with 4 record types, 9 data types   External inquiries use whichever complexity is higher, external input or external output complexity   In this case, both give a high complexity   For our requirement, the multiplier for high external inquiry complexity is 6; therefore, we get 6 adjusted function points for this requirement! HELSINKI UNIVERSITY OF TECHNOLOGY
79. 79. SoberIT Software Business and Engineering Institute Example: MarkII function points   Actual requirement from exercise 1: List category products: This screen lists the product, its name, price, short description, thumbnail image,variations (size, colors and materials) and their stock availability. When clicking a product name or image, a detailed product data screen is activated (see FR3). The user is also able to make an order through this screen (see FR4).   Step 1: Identify input types, entity types and output types   Input types: categoryName   Entity types: Category, Product, Customer, Discount   Output types: productName, price, shortDescription, smallImage, size, color, material, availability   Step 2: Calculate function point amount using weights   0.58*1 + 1.66*4 + 0.26*8 = 9.30 function points. HELSINKI UNIVERSITY OF TECHNOLOGY
80. 80. SoberIT Software Business and Engineering Institute Example: Constructive cost model   Using COCOMO 81 to estimate effort: 1. Calculate function points for the system   Example: FP = 19 2. Calculate source lines of code for the system based on the function points   Example: Development in Java, thus SLOC = 60 x 19 = 1140 3. Apply the basic model for nominal effort estimate   Example: Organic model (c=2.4,k=1.05) => effort = c x sizek = 2.4 x (1.140)1.05 = 2.75 person-months 4. Apply the development effort multiplier   Example: Other cost drivers at nominal level, but programmer capability (PCAP) and operating system experience (VEXP) is high: dem = 0.80 x 0.90 = 0.72 => effort’ = 0.72 x effort = 1.98 person-months HELSINKI UNIVERSITY OF TECHNOLOGY