Use Case Points

Introduction

Use Case Points (UCP) is a software size and effort estimation method introduced by Gustav Karner in 1993 [1]. The method itself is based on the Function Points Method MKII [2], but uses use-case model as an input (as well as some additional information regarding environment and technical issues).

Since the introduction of UCP many papers have been published about the method, some of them presenting proposals for modifications [3, 4, 5, 6], some reporting case studies with use of the method [1, 3, 7, 8, 9]. Here, I would like to focus on the original version of the method, however I will try to write something about the alternatives somewhere in the future.

Construction of the method

The model of UCP includes two main inputs: actors and use cases. When you assess complexity of both of them, you will obtain Unadjusted UCP (UUCP), which you can further adjust with environmental factors (EF) and technical complexity factors (TCF). That's how you obtain UCP. To estimate effort you will have to multiply UCP by so-called Productivity Factor (PF), which should be derived based on historical data to obtained higher accuracy of the effort estimation.

Actors Complexity

First, you have to assess the complexity of each actor, which is done based on the type of interface it uses to communicate with the system under development, and then assign the actor to one of three complexity classes:

• simple: a system actor which communicates using API;
• average: a system actor which communicates through a protocol (e.g. HTTP, FTP), or person who interacts with a system through a terminal console;
• complex: a person who uses graphical user interface (GUI) in order to communicate with the system.

Then you have to count the number of actors assigned to each class, which is required to calculate Unadjusted Actors Weights (UAW):

Where

• Actors_i is the number of actors assigned to the complexity class i.

Typical problems regarding calculation of UAW relate to generalization of actors [7] (you have to decide which actors should be included), and with introduction of additional actors, which is sometimes done to make model easier to understand [4].

Complexity of Use Cases

Similar to actors, each use case is also assigned to one of three complexity classes, but this time it is done based on the number of so-called use-case transactions:

• simple: from 1 to 3 transactions;
• average: from 4 to 7 transactions;
• complex: more than 7 transactions;

Again, you have to count the number of use cases assigned to each class to calculate the Unadjusted Use Case Weights (UUCW):

Where

• UC_i is the number of use cases assigned to the complexity class i.

Transactions in Use Cases

Identification of transactions is probably the most difficult part of UCP, because the definition, which states that transaction is a set of activities in use-case-scenarios (that is meaningful to the actor), which is either performed entirely, or not at all, and leaves the business of application in consistent state, is vague.

I could write a separate blog entry only on transaction identification (which I hope I will in the future), so for now I would recommend you reading the IBM white paper [13]. I think it is the most comprehensive, freely available source of knowledge about transactions in use cases.

For those who don't have so much time to read external sources I will try to describe transactions in a nutshell. Transactions in use cases have two most important parts, which are actor's requrest (a stimulus to the system), and system response. For instance, our automatic appraoch for transaction identification [11], was based on finding these kind of patterns (request -> response.) However, the biggest challange is to decide whether a meaningful goal is obtained in such interaction, and the business of application is left in consistent state. Although in most cases (it actually depends on author's writing style), identification of round trips between actor and system is sufficent to identify transactions, sometimes few requests->responses are required to obtain a single meaningful goal and to leave the business of application in a consistent state.

For example, imagine you are supposed to add an object - article to the system. The simple use-case transaction can look like that (1) System asks for the content of the article; (2) Author provides the content; (3) System stores the article and presents it to the Author. And what if we introduce two additional steps between steps (2) and (3): System asks Author to confirm adding the article; Authors confirms. The whole 5-step scenario is still a single transaction!

We have defined eleven semantic types of transactions [12] (probably there are even more of them, but so far we were not able to find more of them), which can help you to find (and understand) the goals of transactions. We are also working on improving our tool for the automatic transaction identification, by introducing additional information about the types to the algorithm it uses.

Some authors suggested also that counting transactions is equivalent to counting steps [8, 15, 16], however from my experience, it is not the same as counting transactions (in most of the cases).

Unadjusted Use Case Points

When you have calculated UAW and UUCW, you are ready to calculate Unadjusted Use Case Points (UUCP):

Adjustment Factors

There are two types of adjustment factors in UCP, technical complexity factors (TCF) and environmental factors (EF). The first one relates to the some of the non-functional requirements, and the second one describes environment.  As estimator, you have to predict the influence of each of the factor presented in Table 1, on your system. This influence is expressed by assigning a value between 0 to 5 (0 - no impact, 5 - maximum impact, 3 - default if you are not sure).

Table 1 Technical Complexity Factors (TCF) and Environmental Factors (EF)

Once you predict the influence, you will have to multiply the assigned value by the weight for each factor and calculate TCF and EF:

Where

• value_i is predicted degree of influence of the i-th factor on the project (value between 0 and 5);
• XF_weight_i (where X is T for technical complexity factors and E for environmental factors) is the weight of the i-th adjustment factor (see Table 1).

The biggest problem in assessment of these factors is lack of standardization, which leads to subjectivity in their assessment (you can use the proposal for standardization of factors presented in [8]).

Use Case Points

Finally, you have to multiply UUCP by both adjustment factors to obtain Use Case Points (UCP):

Productivity Factor

OK, but still UCP is actualy not what we were lookin for...  We would like to estimate effort. In order to do so, you have to multiply the value of UCP by so-called Productivity Factor (which, in fact, should be rather called Project Delivery Rate - PDR), which states how many man-hours is required to deliver 1 UCP. So the equation for obtaining the Effort would be:

The question is what the value of PF you should use for your project? The default value proposed by Karner was 20 hours / UCP. Schneider and Winters [13] proposed to count number of environmental factors F1-F6 which influence is predicted to be less then 3, and factors F7-F8 which influence is predicted to be greater than 3, and based on that number:

• 0-2, PF = 20 h/UCP;
• 3-4, PF = 28 h/UCP;
• >4, PF = 36 h/UCP;

From my experience, for  simple projects (without  heavy documentation, with rather stable requirements), you should choose PF equal 15 h/UCP. The PF equal to 20 h/UCP is a good choice for a typical small-middle size industrial project (not very complex systems). If the project is complex and requires heavy and highly-documented process consider using 36 h/UCP.

However, the best choice is to collect your own data and create the historical database of projects developed in your organization, because multi-organizational data is less accurate than the company-specific [14] (of course if the projects are similar).

The simplest approach to calibrate PF is that after you finish the project you can calculate a post Productivity Factor, and store it in your database:

Calculating, and storing, postPF is the easiest way. If you collect data from many projects you can also try to re-calibrate weights of TCF and EF (or even introduce new factors).

References

1. G. Karner. Resource Estimation for Objectory Projects. Objective Systems SF AB (copyright owned by Rational Software), 1993.
2. C. Symons. Software sizing and estimating: Mk II FPA (Function Point Analysis). Wiley Series In Software Engineering Practice, page 200, 1991.
3. M. Braz, S. Vergilio, Software Effort Estimation Based on Use Cases, Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC’06)- Volume 01 (2006) 221–228.
4. S. Diev, Use cases modeling and software estimation: applying use case points, ACM SIGSOFT Software Engineering Notes 31 (6) (2006) 1–4.
5. P. Mohagheghi, B. Anda, R. Conradi, Effort estimation of use cases for incremental large-scale software development, Proceedings of the 27th international conference on Software engineering (2005) 303–311.
6. S. Nageswaran, Test effort estimation using use case points, 14 th International Internet & Software Quality Week 2001.
7. B.Anda,H.Dreiem,D.Sjøberg,M.Jørgensen,Estimating Software Development Effort Based on Use Cases-Experiences from Industry, Fourth International Conference on the UML (2001) 487–504.
8. K. Ribu, Estimating object-oriented software projects with use cases, Master’s thesis, University of Oslo, Department of Informatics (2001).
9. C. Gencel, L. Buglione, O. Demirors, P. Efe, A case study on the evaluation of cosmic-ffp and use case points, in: Proceedings of SMEF 2006, 2006.
10. R. Collaris, Dekker, Software cost estimation using use case points: Getting use case transactions straight, IBM White paper, 2009.
11. M. Ochodek, J. Nawrocki: Automatic Transactions Identification in Use Cases In: Balancing Agility and Formalism in Software Engineering: 2nd IFIP Central and East European Conference on Software Engineering Techniques CEE-SET 2007, vol. 5082, pp. 55-68, Springer Verlag. LNCS. 2008.

12. M. Ochodek, J. Nawrocki: Enhancing Use-Case-Based Effort Estimation with Transaction Types. Foundations of Computing and Decision Sciences, 35(2):91-106. 2010.

13. G.Schneider, J.Winters, Applying use cases:a practical guide, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 1998.
14. R. Jeffery, M. Ruhe, I. Wieczorek, A comparative study of two software development cost modeling techniques using multi-organizational and company-specific data, Information and Software Technology 42 (14) (2000) 1009–1016.
15. G.Banerjee, Use case estimation framework, 2004.
16. CrossTalk–The Journal of Defense Software Engineering 19 (2) (2006) 18–22.