UseCase-based effort estimation of software projects TDT 4290 Customer-driven project IDI, NTNU, 14. Sept. 2005

1. UseCase-based effort estimation of software projects TDT 4290 Customer-driven project IDI, NTNU, 14. Sept. 2005 • Bente Anda, Simula Research Lab., Oslo, bentea@simula.no • Reidar Conradi, NTNU (minor additions), conradi@idi.ntnu.no

2. Trustworthy estimation crucial to all (software) projects, especially of volume/effort – but also schedule, and quality properties like reliability, performance, … An effort estimate: • Is different from tactical/political project bids! • May be done at several stages: initially, after requirements analysis (here), after design, … • Should reflect original rqmts, in increments? • May be adjusted with slack (+-30%?) • Several possibilities: • Informal expert estimates/guesses (by experience) • Break down top-down, estimate bottum-up • Formal methods (FP, UCP) – see later, cf. COCOMO Delphi triangulation (combine many estimates)

3. ”The project triangle”- three competing variables or dimensions effort time (fixed for you)

4. Approach to improved effort estimation • Best practices for effort estimation: • Combine estimates from different experts and estimation strategies. • Estimate top-down and bottom-up independently. • Justify and criticize estimates.  Use method-based estimates to improve expert estimates.

5. Function-Point (FP) estimation method, by Albrecht at IBM in 1979 • Idea: Operationalize functional requirements into UnadjustedFPs, then multiply by various technical/environment factors to get AdjustedFPs. Then apply expansion factors (Ci) to get source lines (SLOC i.e. volume), then effort and time. • Example: • UFP: … • AFP: <tech./env. factors> * UCP • SLOC: C1 * AFP**(1.07) -- diseconomy of scale • Effort: C2 * SLOC • Time: C3 * Effort**(0.38)

6. FP based on computing 15 numbers, from a rqmt spec: Computing Unadjusted FPs, then multiplied by misc. factors

7. The UseCase Points (UCP) Estimation Method • The UseCase Points Estimation Method was introduced by Gustav Karner from Linkøping University. • The method is inspired by the Function Point (FP) method. • The method is implemented using a spreadsheet.

8. The Estimation Method in Detail • The actors in the UseCase model are categorized as simple, average or complex. A simple actor is typically either another system with a defined API or an internal actor; an average actor is another system interacting through a protocol such as TCP/IP; and a complex actor may be a person interacting through a graphical user interface or a web-page. A weighting factor is assigned to each actor category. • Simple/Average/Complex: Weighting factor 1/2/3 • The UseCases are also categorized as simple, average or complex, depending on the number of transactions, including the transactions in alternative flows. A simple UseCase has 3 or fewer transactions; an average 4 to 7 transactions; and a complex more than 7 transactions. A weighting factor is assigned to each UseCase category: • Simple/Average/Complex: Weighting factor 5/10/15 • The unadjusted UseCase points are calculated by adding the weighted actors and UseCases. • The unadjusted UseCase points are adjusted based on the values of 13 technical factors and 8 environmental factors.

9. Adjust Based on Technical Factors • Each factor is assigned a value from 0 to 5 based on importance and how it is supported by the technology used.

10. Adjust Based on Environmental Factors • Each factor is assigned a value from 0 to 5

11. Assigning values to the Environmental Factors F1 Familiar with Development Method: Score 0 if none of the team members are familiar with the development method to 5 if all the team has experience from using the method on several projects. F2 Application experience: Score 0 if none of team members has experience with similar application domains to 5 if all the team has more than 5 years experience. F3 Object-Oriented experience: Score 0 if the team is totally unfamiliar with OOAD to 5 if all the developers been trained in OOAD and have more than 5 years experience with it. F4 Lead analyst capability: Score 0 if the lead analyst is a novice to 5 if he/she has more than 5 years experience from similar projects F5 Motivation: Score 0 if the project members lack motivation to 5 if the team is very motivated. F6 Stable requirements: Score 0 if the requirements are likely to undergo constant changes to 5 if no changes in the requirements are expected. F7 Part-time workers: Score 0 if there are no part-time workers to 5 if all are part-time workers. F8 Experience with the tools: Score 0 if all the team members have been trained and have experience with the tools to 5 if they are all novices.

12. Productivity Factor • The adjusted UseCase points are multiplied with a productivity factor (hours per UseCase point). • This factor is typically set to 20 – 36, depending on the values of the environmental factors, the level of detail of the UseCases, and the development process. • For small projects that are not required to deliver high quality solutions, 10 -15 hours per UseCase point may be sufficient.

13. Producing an Estimate • The unadjusted actor weight, UAW, is calculated adding the weights for each actor. • The unadjusted UseCase weights, UUCW, is calculated correspondingly. • The unadjusted UseCase points, UUCP = UAW + UUCW. • The technical factor, TCF = .6 + .01*1..13Tn*Weightn). • The environmental factor, EF = 1.4 + (-.03* 1..8Fn*Weightn). • UCP = UUCP*TCF*EF • Estimate = UCP * Productivity factor

14. Prerequisites for Applying the UseCase Points Method • Correctness of the UseCase model: The UseCase model should include the functional requirements of all the user groups. The main challenge is sufficient access to skilled and motivated domain experts. 2. Level of detail: The UseCase model should be described at an appropriate level of detail. The main challenges are to obtain balanced UseCases and avoid ”infinite” expansion. Possible solutions are guidelines and good examples of UseCase models.

15. Adapting the Method • Assessing the size of a UseCase: • In the inception phase the UseCases are usually not described with sufficient detail to apply the UseCase points method directly. • The UseCases are often described at an unbalanced level of detail. • The UseCase descriptions hide complexities. • The impact of each UseCase on the different parts of the architecture should be considered together with possibilities for reuse. • Adjustment factors: • Omit technical factors when the method is applied to detailed UseCases. • Functionality vs. architecture: • Estimate architecture separately when there is much uncertainty • Otherwise, use one environmental factor to assess stability of architecture instead of stability of requirements.