1. Use-Case Points for Estimating Software Size
EECS/IT811: IT Project Management
Sairath Bhattacharjya
March 21, 2019

2. Organization Introduction What is use case? Use case 2.0
Basic principle of application of use case
Software effort estimation
Use case points calculation
Usage of UCP
The agile way
Conclusions
Question & Answer

3. Resources Used
All resources shared by Professor Saiedian (on class website)
Book chapters
White papers
Articles
Wikipedia

4. Why I chose the use-case point topic?
Use case is a very popular method for requirement gathering
Ties the triple constrains (scope, time and cost) really well
Considers non-functional and environmental factors for software development
A more scientific method for estimation
Leads towards agile development

5. What is a use case? [1 of 4]
A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.
Source:
In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known as an actor) and a system to achieve a goal
Source:

6. What is a use case? [2 of 4]
A popular approach of collecting the requirements
A user-centric approach: a specific situation in which a product or service could potentially be used by a user
Can be developed to tell a story of how the system will be used from the perspective of each actor
Getting started with use case modelling by Oracle is a good example to understand how to write use cases

7. What is a use case? [3 of 4]
•actors - something with a behavior or role, e.g., a person, another system, organization.
•scenario - a specific sequence of actions and interactions between actors and the system, a.k.a. a use case instance
•use case - a collection of related success and failure scenarios, describing actors using the system to support a goal.

8. What is a use case? [4 of 4] •Association relationships
•Generalization relationships
One element (child) "is based on" another element (parent)
•Include relationships
One use case (base) includes the functionality of another (inclusion case)
Supports re-use of functionality
•Extend relationships
One use case (extension) extends the behavior of another (base)

9. Use case 2.0 [1 of 2]
A scalable, agile practice that uses use cases to capture a set of requirements
Drive the incremental development of a system
Features of use case 2.0:
Lightweight
Scalable
Versatile
Easy to use
Use-Case 2.0 drives the development of a system by first helping you understand how the system will be used and then helping you evolve an appropriate system to support the users.

10. Use case 2.0 [2 of 2]
The subject of Use-Case 2.0 is the requirements, the system to be developed to meet the requirements, and the tests used to demonstrate that the system meets the requirements. At the heart of Use-Case 2.0 are the use case, the story and the use-case slice. These capture the requirements and drive the development of the system.
The stakeholders are the people, groups, or organizations who affect or are affected by a software system. The requirements are what the system must do to satisfy the stakeholders. It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development of the new system. In Use-Case 2.0 the requirements are captured as a set of use cases, which are scope managed and addressed as a set of use case slices. Any changes requested by the stakeholders result in additions or changes to the set of use cases and use-case slices.
The system is the system to be built. It is typically a software system although Use-Case 2.0 can also be used in the development of new businesses (where you treat the business itself as a system), and combined hardware and software systems (embedded systems). It is the system that implements the requirements and is the subject of the use-case model. The quality and completeness of the system is verified by a set of tests. The tests also verify whether or not the implementation of the use-case slices has been a success. If defects are found during the testing then their presence will prevent the completion of the use-case slice until they have been fixed and the system improved.

11. Basic principle of application of use case
Keep it simple by telling stories
Understand the big picture
Focus on value
Build the system in slices
Deliver the system in increments
Adapt to meet the team’s needs

12. Software effort estimation
Objective: estimate the most realistic amount of efforts to complete a project
There are many methods
Expert judgment
Analogy-based estimation
Size-based models
Function points
Feature points
Use case points
Story points …

13. Use case points [1 of 2]
Use Case Points (UCP) is a software estimation technique used to forecast the software size for software development projects
Helps in determining the overall completion date of a project
Helps in release planning

14. Use case points [2 of 2]
The number of use case points in a project is a function of the following:
The number and complexity of the use cases in the system (UUCW)
The number and complexity of the actors on the system (UAW)
various non-functional requirements (TCF)
the environment in which the project will be developed (EF)
The basic formula for converting all of this into a single measure, use case points, is that we will “weigh” the complexity of the use cases and actors and then adjust their combined weight to reflect the influence of the non-functional and environmental factors.

15. Unadjusted Use Case Weight (UUCW) [1 of 3]
Shows the main scenario and extensions
2a, 2b, 2c and 3a are outcomes and not considered a transaction
Total transactions: 10

16. Unadjusted Use Case Weight (UUCW) [1 of 3]
Based on the number of transactions the complexity is defined as follows:

17. Unadjusted Use Case Weight (UUCW) [3 of 3]
Each use case is categorized based on transactions
Each complexity is assigned a weight
The summation of product of weight and number of use case gives the UUCW
In our example UUCW = 260

18. Unadjusted Actor Weight (UAW) [1 of 2]
An actor can be a person, system or program
Complexity is defined based on the type of actor

19. Unadjusted Actor Weight (UAW) [2 of 2]
Each use case is assigned a weight based on the complexity of the actors interacting with the system
The summation of product of weight and number of use case gives the UAW
In our example UAW = 140

20. Technical Complexity (TCF) [1 of 3]
Thirteen standard technical factors exist to estimate the impact on productivity that various technical issues have on a project. Each factor is weighted according to its relative impact. For each project, the technical factors are evaluated by the development team and assigned a perceived complexity value between zero and five. The perceived complexity factor is subjectively determined by the development team’s perception of the project’s complexity

21. Technical Complexity (TCF) [2 of 3]

22. Technical Complexity (TCF) [3 of 3]
There are 13 standard technical factors to estimate the impact on productivity
Weight is the relative impact
Assessment is the perceived complexity of each factor
The summation of the product of weight and assessment gives the Tfactor
TFC is calculated as TCF = (0.01 * TFactor)
In our example TCF = (0.01 * 42) = 1.02

23. Environmental Complexity (EF) [1 of 3]
More experienced teams will have a greater impact on the UCP computation than less experienced teams. The development team determines each factor’s perceived impact based on its perception the factor has on the project’s

24. Environmental Complexity (EF) [1 of 3]

25. Environmental Complexity (EF) [1 of 3]
More experienced teams will have a greater impact on the UCP
Development team assigns perceived complexity for each factor between 1 and 5
The EFactor is calculated as a sum of the product of weight and assessment.
The EF is calculated as EF = (–0.03 • EFactor)
In our case EF = (–0.03 • 17.5) = (–0.51) = 0.89

26. Calculating the UCP Use Case Point (UCP) is calculate as
UCP = (UUCW + UAW) • TCF • EF
In our example,
UCP = ( ) • 1.02 • 0.89 = 363

27. Effort estimation Use Case Points (UCP) = 363
Considering 20 hours per UCP
Total hours for project: 363 * 20 = 7,260 hours
Considering
iterations are of 2 weeks
5 people are working in the project (40 hours/week)
Total iterations: 7260 / (5 * 40 * 2) = ~ 19
Total time for completion: 38 weeks
Karner (1993) originally proposed a ratio of 20 hours per use case point. This means
that our example of 363 use case points translates into 7,260 hours of development
work. Building on Karner’s work, Kirsten Ribu (2001) reports that this effort can
range from 15 to 30 hours per use case point. In much the same way an XP team will
often need to take a wild guess at its initial velocity, a team working with use cases
may need to take a similar guess at first.
A different approach is proposed by Schneider and Winters (1998). They suggest
counting the number of environmental factors in E1 through E6 that are above 3 and
those in E7 and E8 that are below three. If the total is two or less, assume 20 hours
per use case point. If the total is 3 or 4, assume 28 hours per use case. Any total larger
than 4 indicates that there are two many environmental factors stacked against the
project. The project should be put on hold until some environmental factors can be
improved.

28. Cost estimation Total hours for project: 7,260 hours
Rate per person: $45/hour
Total cost of the project
= 45 * 7260
= $326,700
Considering additional costs and buffers the project should cost around $350,000

29. Release planning
Weight of use case per iteration: Unadjusted Use Case Weight (UUCW) by the number of iterations gives the
Weight per iteration = UUCW / iterations
In our case: 260 / 19 = 13.7 (~14)
Defines the expected velocity of the team
Actual velocity is compared against this to determine if the project is in schedule

30. The agile way Use case can be considered as a Epic
Scenarios in a use case can be considered as a user story
Completion of all the scenarios results in completion of the use case
Ties back to use case 2.0 objectives

31. Conclusions UCP helps in resource planning
Helps in providing a early estimate of the effort required
UCP method is versatile and extensible to a variety of development and testing projects.

32. Question and Answers

33. Resources used [1 of 6]
All resources shared by Professor Saiedian (on class website)
Book: Use case points – Chapter 6
Wikipedia – Use case
Wikipedia - Software development effort estimation 33

34. Resources used [2 of 6]
Title: Use Case 2.0, the guide to succeeding with use case Author: Dr. Ivar Jacobson, Ian Spence, Kurt Bittner Edition: December 2011 Type: EBook Link:

35. Resources used [3 of 6]
Title: Introduction to use case Author: Ian Gibson, Matthew Hause (Artisan Software) Type: Presentation Link:

36. Resources used [4 of 6]
Title: Getting Started With Use Case Modeling Author: Jan Kettenis, Oracle Corporation Edition: May 2007 Type: White paper Link:

37. Resources used [5 of 6]
Title: Project Estimation With Use Case Points Author: Roy K. Clemmons Edition: February 2006 Type: Article Journal: CROSSTALK The Journal of Defense Software Engineering Link:

38. Resources used [6 of 6]
Title: Estimating Effort by Use Case Points: Method, Tool and Case Study Author: S. Kusumoto, F. Matukawa, K. Inoue, S. Hanabusa, Y. Maegawa Edition: September 2004 Type: Article Journal: 10th International Symposium on Software Metrics, Proceedings. Link: