1. Estimating with Use Cases Extracts from the Lamri Use Case Survival Guide™ Mark Aked Managing Consultant For more information visit www.lamri.com or email marketing@lamri.com Copyright 2003

2. Agenda Why Estimates are not Accurate What Use Cases bring to Estimating What a Difference a Phase makes! Estimating Methods Use Case Points – a worked example How Use Cases can be mapped to function points Summary Questions

3. Copyright 2003 The Typical Estimating Process Architecture Schedule Needs Budget

4. Copyright 2003 Why Estimates are not Accurate

5. Copyright 2003 Why Estimates are not Accurate

6. Copyright 2003 Why Estimates are not Accurate

7. Copyright 2003 Why Estimates are not Accurate

8. Copyright 2003 Why Estimates are not Accurate Technical and Process Issues are uncovered and the uncertainty increases The uncertainty blip

9. Copyright 2003 Agenda Why Estimates are not Accurate What Use Cases bring to Estimating What a Difference a Phase makes! Estimating Methods Use Case Points – a worked example How Use Cases can be mapped to function points Summary Questions

10. Copyright 2003 Do Use Cases Improve Estimates? Use Cases provide a mechanism for articulating the product scope from the user’s point of view Size and Complexity can be attributed to each Use Case, but are really based upon the artefacts derived from Use Cases

11. Copyright 2003 Product Complexity and Size Product complexity is driven by architecture Architecture is represented in many models! Product Size is measured through artefacts derived from a Use Case

12. Copyright 2003 Architecture Exposes Complexity

13. Copyright 2003 Do Use Cases Improve Estimates? An approximate answer to the right question is worth a good deal more than the exact answer to an approximate problem. John Tukey “ ” Use Cases help us ensure the right question is being answered and provide the basis for the approximate answer.

14. Copyright 2003 The Waterfall Process Prevents Accurate Estimates The waterfall process leaves technical risks unexposed for too long Technical risks may be considered but are not actively mitigated by proving (i.e. actually building and integrating software)

15. Copyright 2003 The Waterfall Process Prevents Accurate Estimates When technical risks become issues the cost and schedule have to be extended invalidating the budget forecast Adding Use Cases to a waterfall process improves the articulation and management of scope but the estimate will still hit the ‘uncertainty blip’ too late

16. Copyright 2003 Agenda Why Estimates are not Accurate What Use Cases bring to Estimating What a Difference a Phase makes! Estimating Methods Use Case Points – a worked example How Use Cases can be mapped to function points Summary Questions

17. Copyright 2003 Remember this?

18. Copyright 2003 What a Difference A Phase Makes!

19. Copyright 2003 What a Difference A Phase Makes!

20. Copyright 2003 What a Difference A Phase Makes!

21. Copyright 2003 What a Difference A Phase Makes!

22. Copyright 2003 What a Difference A Phase Makes!

23. Copyright 2003 What a Difference A Phase Makes!

24. Copyright 2003 What a Difference A Phase Makes!

25. Copyright 2003 Your SDLC Constrains Your Ability to Estimate Inserting a technical risk phase into your software development lifecycle (SDLC) will have a significant contribution to your estimating accuracy Pulls the uncertainty blip forward Encourages you to do the hard stuff first Enables you to assess whether you can actually deliver Provides real metrics to improve the estimate Enables you to carry out an Engineering Forecast

26. Copyright 2003 Agenda Why Estimates are not Accurate What Use Cases bring to Estimating What a Difference a Phase makes! Estimating Methods Use Case Points – a worked example How Use Cases can be mapped to function points Summary Questions

27. Copyright 2003 Estimating Methods We Can Use Analogy - Compare the proposed project to previously completed similar projects where project development information is known. Bottom-up - Identify and estimating each individual component separately, then combining the results to produce an estimate of the entire project. Top-down - Project is partitioned into lower-level components and life cycle phases beginning at the highest level. Expert Judgement - Human ‘experts’ consulted to provide an estimate based upon their experience and understanding of a proposed project. Algorithmic - Use of equations from research and historical data to perform software estimates.

28. Copyright 2003 Which Methods Do We Apply? We tend to use Expert Judgement We should use a blend of methods at the appropriate time The method that is least used or avoided (but craved for) is the algorithmic method

29. Copyright 2003 The Recommended Approach E = Expertise

30. Copyright 2003 The Recommended Approach E = Expertise A = Algorithm

31. Copyright 2003 The Recommended Approach E = Expertise A = Algorithm

32. Copyright 2003 The Recommended Approach Algorithms provide the repeatable basis that supplement the Risk Focused approach E = Expertise A = Algorithm

33. Copyright 2003 Using Algorithms with Use Cases A worked example of Use Case Points How use cases can be mapped to function points A few points about algorithms All based upon knowledge of the scope Require a feedback mechanism for tuning Differentiator is the currency they use for scope / risks

34. Copyright 2003 Use Case Points Developed by Gustav Karner of Objectory in 1993 Derived from Function Points Uses weighting on Actors and Use Cases to assess scope Uses Environmental and Technology factors to assess Risk Applicable to small team, < 5 month development Quick and dirty but can be accurate

35. Copyright 2003 Use Case Points Process

36. Copyright 2003 Weight Actors (AW)

37. Copyright 2003 Weight Actors (AW) Each Actor (interface) is weighted based on Actor Type Actor Weighting (AW) = ∑Actor Weights

38. Copyright 2003 Weight Use Cases (UCW)

39. Copyright 2003 Weight Use Cases (UCW) Use Case Weighting Factor is based on the Number of Use Case Flows Use Case Weighting (UCW) = ∑Use Case Weights

40. Copyright 2003 Apply Technical Factors (TCF) The Technical Complexity Factor (TCF) is derived by assigning a value to each technical factor on a scale of 0 to 5. 0 = Factor is irrelevant for this project 5 = Factor is essential. Total Weighted Factor = ∑(Extended Value) Extended Value = Assigned Value x Weight TCF = 0.6+(0.01*Total Weighted Value)

41. Copyright 2003 Apply Environmental Factors (ECF) The Environmental Factors (EF) considers the experience level of the people on the project derived from rating each factor from 0 to 5. 0 = factor is irrelevant for this project 5 = factor is essential for this project Total Weighted Factor = ∑(Extended Value) Extended Value = Assigned Value x Weight EF = 1.4+(-0.03 x Total Weighted Value)

42. Copyright 2003 Apply Environmental Factors (ECF) How many > 3? How many < 3? Person Hours Factor (PHF) If total <= 2, PHF = 20 If total = 3 or 4, PHF = 28 hours. Above this…big risk!!!

43. Copyright 2003 Apply Environmental Factors (ECF) PHF = 4, so 28 Person Hours How many > 3? How many < 3? Person Hours Factor (PHF) If total <= 2, PHF = 20 If total = 3 or 4, PHF = 28 hours. Above this…big risk!!!

44. Copyright 2003 Calculate Effort and Schedule Use Case Points = (AW + UCW) x TCF x EF Use Case Points = (8 + 35) x 0.93 x 0.905 = 36.19

45. Copyright 2003 Analysis of Use Case Points Take Use Cases as the natural currency Provides an effort estimate Additional work required on the resource and SDLC process profile Assume all team have same competence

46. Copyright 2003 Analysis of Use Case Points Don’t really get ‘inside’ the Use Case to incorporate other scope elements Little scope for tuning the results of what we know more Not a widely used metric for size

47. Copyright 2003 Function Points Provides a unit of software size calculated from functional requirements. Are independent of technology or method. Developed for business systems, not scientific or real-time based systems 2 flavours Function Points – US developed MK II Function Points – UK developed

48. Copyright 2003 Function Point Analysis

49. Copyright 2003 Function Point Analysis

50. Copyright 2003 Function Point Analysis Number of Input Attributes Number of Entities Referenced Number of Output Attributes

51. Copyright 2003 Function Point Analysis UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced) + (0.26*Number of Output Attributes) Number of Input Attributes Number of Entities Referenced Number of Output Attributes

52. Copyright 2003 Function Point Analysis UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced) + (0.26*Number of Output Attributes) Number of Input Attributes Number of Entities Referenced Number of Output Attributes

53. Copyright 2003 Use Cases and Function Points

54. Copyright 2003 Use Cases and Function Points A Use Case flow contains one or more Functional Transactions

55. Copyright 2003 Use Cases and Function Points Logical Transactions found by studying the Use Case Flow A Use Case flow contains one or more Logical Transactions

56. Copyright 2003 Use Case and Function Point Process

57. Copyright 2003 Use Case and Function Point Process

58. Copyright 2003 Use Case and Function Point Process

59. Copyright 2003 Use Case and Function Point Process

60. Copyright 2003 Use Case and Function Point Process

61. Copyright 2003 Function Point Guidelines CCTA Guidelines for Function Point Estimation

62. Copyright 2003 Use Case and Function Point Process UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced) + (0.26*Number of Output Attributes) UFPSystem = ∑(UFP 1 + UFP 2 + … + UFP n )

63. Copyright 2003 Use Case and Function Point Process System Characteristics Data Communications Distributed Data Processing Performance Heavily Use Configuration Transaction Rate On-line Data Entry End-User Efficiency On-line Update Complex Processing Re-useability Ease of Installation Ease of Operation Multiple Sites Facilitate Change

64. Copyright 2003 Analysis of Function Points Take Logical Transactions the natural currency Mapping can be made to Use Cases Can be used as the input into various algortihmic methods (e.g. COCOMOII) Widely used

65. Copyright 2003 Analysis of Function Points Only applicable to business systems Require good understanding of counting rules and so trained counters

66. Copyright 2003 Summary Use Cases provide a close approximation of project scope that provides an estimate that is extremely useful for high-level project planning. We need a process that respects technical and project risk (capability) so that it naturally becomes part of the planning and estimation process.

67. Copyright 2003 Summary Remember the Cone of Uncertainty Adding a phase that addresses technical risk will have a significant impact upon the confidence of your estimate Use a blend of estimating methods but include an algorithmic approach

68. Copyright 2003 Summary All algorithmic approaches are all based upon knowledge of the scope Garbage IN Garbage OUT Require a feedback mechanism for tuning Need to be applied at the organisation level in order to gain comparison and past project data Differentiator is The currency they use for scope / risks