Use Case Points Method
The Use Case Points Method (UCPM) is an effort estimation algorithm proposed by Gustav Karner and reported in [1] that employs Use Cases as a representation of system complexity based on system functionality. The steps in the application of the UCPM are explained below. This is the method as originally reported. Readers should be aware that some problems with the original method have been reported, but for completeness it is fully described. For the purposes of estimation in procurement this method has been simplified.
Learn a lot more about simplifications to this method by downloading the appropriate resource from the literature survey.
Method summary
• Identify, classify and weight actors
• Identify, classify and weight use cases
• Identify and Weight Technical Factors
• Identify and Weight Environmental Factors
• Converting Points into Time
• Calculate Adjusted Use Case Points
Identify, classify and weight actors
The basic method can be summarised as first requiring the identification of actors who will interface with the system. Actors are classified as either people or other systems. Each identified actor is given a weighting from 1-3 that corresponds to simple, average, and complex. Human actors are always classified as complex and receive a weighting of 3. Systems to which the new system will interface (legacy systems) are either simple or average depending on the mechanism by which they are addressed.
| Actor type | Definition | Factor |
| Simple | Program interface | 1 |
| Average | Interactive, or protocol-driven interface | 2 |
| Complex | Graphical interface (Human) | 3 |
The specifier of the system sums the actors in each category and multiplies them by the appropriate factor. The results are then summed together.
E.g.:
2 simple * 1 = 2
2 average * 2 = 4
3 complex * 3 = 9
Total actor weight = 2 + 4 + 9 = 15
Identify, classify and weight use cases
After calculating the Total actor weight, it is necessary to create a use case model and to then classify each use case as being either simple, average or complex. The method specifies ignoring use cases that are associated through the extend or include stereotypes. There are two suggestions as to how this classification can be done. Either on the basis of the number of transactions in a use case, or on the basis of the number of analysis classes into which the use case will resolve. A transaction is defined according to the standard definition of a set of atomic activities either entirely performed or abandoned.
| Use case type | Definition | Factor |
| Simple | 3 or fewer transactions or < 5 analysis classes |
5 |
| Average | 4 to 7 transactions or 5 – 10 analysis classes |
10 |
| Complex | More than 7 transactions or > 10 analysis classes |
15 |
E.g.:
5 simple * 5 = 25
4 average * 10 = 40
0 complex * 3 = 0
Total use case weight = 25 + 40 + 0 = 65
The Total actor weight and the Total use case weight are then summed to produce the Unadjusted Use Case Points (UUCP) score.
15 + 65 = 85
UUCP = 85
Identify and Weight Technical Factors
This calculation makes provision for the overall complexity of the project and, to some extent, the experience level of the staff. To do this it is necessary to go through the list of possible technical factors and give each one a rating on the scale of [0 – 5]. A ‘0’ rating means the factor is irrelevant to the project, a ‘5’ rating means it is essential. Then for each factor it is necessary to multiply its score by its weight and sum the results. The final result is then substituted into a Technical Complexity Factor calculation.
| Technical Factor Number |
Technical Factor Description |
Weight | Value | Weight * Value |
| T1 | System will be distributed (released) |
2 | 0 | 0 |
| T2 | Performance objectives |
1 | 3 | 3 |
| T3 | End-user efficiency |
1 | 5 | 5 |
| T4 | Complex internal processing |
1 | 1 | 1 |
| T5 | Code must by reused |
1 | 0 | 0 |
| T6 | Easy to install |
.5 | 5 | 2.5 |
| T7 | Easy to use |
.5 | 5 | 2.5 |
| T8 | Portable |
2 | 0 | 0 |
| T9 | Easy to change |
1 | 3 | 3 |
| T10 | Concurrent |
1 | 5 | 5 |
| T11 | Includes special security features |
1 | 3 | 3 |
| T12 | Provides direct access for third parties |
1 | 5 | 5 |
| T13 | Special user training facilities are required | 1 | 0 | 0 |
E.g.:
TFactor = Sum of Weight * Value column
TFactor = 30
Technical Complexity Factor (TCF) = 0.6 + (0.01 * TFactor)
TCF = 0.9
Identify and Weight Environmental Factors
This calculation makes explicit provision for the experience of the people on the project. As described in the section on Technical Complexity Factors. Each factor is rated on a scale from [0-5]. Again, ‘0’ means the factor is irrelevant to the project, ‘5’ means it is essential. Each factor is calculated by multiplying its score by its weight and producing a sum of the results. The final result becomes the Environmental Complexity Factor calculation.
| Environmental Factor Number |
Environmental Factor Description |
Weight | Value | Weight * Value |
| EF1 | Familiar with RUP | 1.5 | 1 | 1.5 |
| EF2 | Application experience | 0.5 | 1 | 0.5 |
| EF3 | Object-oriented experience | 1 | 1 | 1 |
| EF4 | Lead analyst capability | 0.5 | 5 | 2.5 |
| EF5 | Motivation | 1 | 5 | 5 |
| EF6 | Stable requirements | 2 | 5 | 10 |
| EF7 | Part-time workers | -1 | 0 | 0 |
| EF8 | Difficult programming language | -2 | 2 | -4 |
E.g.:
EF-Factor = Sum of (Weight * Value) column
EF-Factor = 16.5
Environmental Complexity Factor (ECF) = 1.4 + (-0.03 * EF-Factor)
ECF = 0.905
Calculate Adjusted Use Case Points
Finally Use Case Points are calculated using this formula:
UCP = UUCP * TCF * ECF
E.g.:
UCP = UUCP * TCF * ECF
UCP = 80 * 0.9 * 0.905
UCP = 65.16 (65)
Converting Points into Time
Schneider and Winter [1] report Karner’s recommendation that each UCP should be converted into 20 hours of work. They further report a suggested improvement to the method that ranges the amount of time to be allocated per use case to between 20 and 28 hours.
Using the figure of 20 hours/UCP, a project of 61 UCPs would take 1220 hours. Given a 35 hour working week, this project would be estimated to take 35 weeks if one person were working on it. Schneider and Winter recommend following Brooks [2] by adding a contingency to account for the complexity of working in teams that they estimate to be 25%. They caution that their results are based on a small amount of research, without making that research explicit, and solicit other researcher’s results in their book.
[1.] Schneider, G. and J. Winters, Applying Use Cases - A Practical Guide. 1998: Addison Wesley Longman, Inc.
[2.] Brooks, F.P., No Silver Bullet. Information Processing, Elsevier Science Publishing, 1986