Estimating With Use Case Points - Part 2

Mike Cohn, Mountain Goat Software, https://www.mountaingoatsoftware.com/

Unadjusted Actor Weight

The transactions (or steps) of a use case are one aspect of the complexity of a use case, the actors involved in a use case are another. An actor in a use case might be a person, another program, a piece of hardware, and so on. Some actors, such as a user working with a straightforward command-line interface, have very simple needs and increase the complexity of a use case only slightly. Other actors, such as a user working with a highly interactive graphical user interface, have a much more significant impact on the effort to develop a use case. To capture these differences, each actor in the system is classified as simple, average, or complex, and is assigned a weight in the same way the use cases were weighted.

In Karner's use case point system, a simple actor is another system that is interacted with through an API (Application Programming Interface). An average actor may be either a person interacting through a text-based user interface or another system interacting through a protocol such as TCP/IP, HTTP, or SOAP. A complex actor is a human interacting with the system though a graphical user interface. This is summarized, and the weight of each actor type is given, in Table 3.

Actor Type	Example	Weight
Simple	Another system through an API	1
Average	Another system through a protocol A person through a text-based user interface	2
Complex	A person through a graphical user interface	3

Table 3. Actor complexity

Each actor in the proposed system is assessed as either simple, average, or complex and is weighted accordingly. The sum of all actor weights in known as Unadjusted Actor Weight (UAW). This is shown for a sample project in Table 4.

Actor Type	Weight	Number of Actors	Product
Simple	1	8	8
Average	2	7	14
Complex	3	6	18
Total			40

Table 4. Calculating Unadjusted Actor Weight (UAW) for a sample project

Unadjusted Use Case Points

At this point we have the two values that represent the size of the system to be built. Combining the Unadjusted Use Case Weight (UUCW) and the Unadjusted Actor Weight (UAW) gives the unadjusted size of the overall system. This is referred to as Unadjusted Use Case Points (UUCP) and is determined by this equation: UCP=UUCW+UAW. 

Using our example, UUCP is calculated as: UUCP=560+40=600

To this estimate of the size of the application, Karner's use case points approach next applies a pair of adjustments to reflect the technical and environmental complexity associated with the system being developed.

Adjusting For Technical Complexity

The total effort to develop a system is influenced by factors beyond the collection of use cases that describe the functionality of the intended system. A distributed system will take more effort to develop than a nondistributed system. Similarly, a system with difficult to meet performance objectives will take more effort than one with easily met performance objectives. The impact on use case points of the technical complexity of a project is captured by assessing the project on each of thirteen factors, as shown in Table 5. Many of these factors represent the impact of a project's nonfunctional requirements on the effort to complete the project. The project is assessed and rated from 0 (irrelevant) to 5 (very important) for each of these factors.

Factor	Description	Weight
T1	Distributed system	2
T2	Performance objectives	2
T3	End-user efficiency	1
T4	Complex processing	1
T5	Reusable code	1
T6	Easy to install	0.5
T7	Easy to use	0.5
T8	Portable	2
T9	Easy to change	1
T10	Concurrent use	1
T11	Security	1
T12	Access for third parties	1
T13	Training needs	1

Table 5. The weight of each factor impacting technical complexity

An example assessment of a project's technical factors is shown in Table 6. This project is a web-based system for making investment decisions and trading mutual funds. It is somewhat distributed and is given a three for that factor. Users expect good performance but nothing above or beyond a normal web application so it is given a three for performance objectives. End users will expect to be efficient but there are no exceptional demands in this area. Processing is relatively straightforward but some areas deal with money and we'll need to be more carefully developing, leading to a two for complex processing. There is no need to pursue reusable code and the system will not be installed outside the developing company's walls so these areas are given zeroes. It is extremely important that the system be easy to use, so it is given a four in that area. There are no portability concerns beyond a mild desire to keep database vendor options open. The system is expected to grow and change dramatically if the company succeeds and so a five is given for the system being easy to change. The system needs to support concurrent use by tens of thousands of users and is given a five in that area as well. Because the system is handling money and mutual funds, security is a significant concern and is given a five. Some slightly restricted access will be given to third-party partners and that area is given a three. Finally, there are no unique training needs so that is assessed as a zero.

Factor	Weight	Assessment	Impact
Distributed system	2	3	6
Performance objectives	2	3	6
End-user efficiency	1	3	3
Complex processing	1	2	2
Reusable code	1	0	0
Easy to install	0.5	0	0
Easy to use	0.5	4	2
Portable	2	2	4
Easy to change	1	5	5
Concurrent use	1	5	5
Security	1	5	5
Access for third parties	1	3	3
Training needs	1	0	1
Total (TFactor)			42

Table 6. Example assessment of a project's technical factors

In Karner's formula, the weighted assessments for these twelve individual factors are next summed into what is called the TFactor. The TFactor is then used to calculate the Technical Complexity Factor, TCF, as follows: TCF = 0.6 + (0.01 x TFactor)

In our example, TCF = 0.6 + (0.01 x 42) = 1.02

Adjusting For Environmental Complexity

Environmental factors also affect the size of a project. The motivation level of the team, their experience with the application, and other factors affect the calculation of use case points. Table 7 shows the eight environmental factors Karner's formulas consider for each project.

Factor	Description	Weight
E1	Familiar with the development process	1.5
E2	Application experience	0.5
E3	Object-oriented experience	1
E4	Lead analyst capability	0.5
E5	Motivation	1
E6	Stable requirements	2
E7	Part-time staff	-1
E8	Difficult programming language	-1

Table 7. Environmental factors and their weights

An example assessment of a project's environmental factors is shown in Table 8. The weighted assessments for these eight individual factors are summed into what is called the EFactor. The EFactor is then used to calculate the Environment Factor, EF, as follows: EF = 1.4 + (-0.03 x EFactor)

In our example, this leads to: EF = 1.4 + (-0.03 x 17.5) = 1.4 + (-0.51) = 0.89

Factor	Weight	Assessment	Impact
Familiar with the development process	1.5	3	4.5
Application experience	0.5	4	2
Object-oriented experience	1	4	4
Lead analyst capability	0.5	4	2
Motivation	1	5	5
Stable requirements	2	1	2
Part-time staff	-1	0	0
Difficult programming language	-1	2	-2
Total (EFactor)			17.5

Table 8. Example calculation of EFactor

Page 1

Page 3

Back to the archive list