Software Cost Estimation With Use Case Points – Actor Analysis

Software project cost estimation using use case points takes the approach of estimating the amount of effort based upon what the software is being asked to do – not an analysis of how someone chooses to do it. We’ve looked at technical and environmental factors that influence our estimate. And we’ve done a use case analysis to quantify how much work the software is being asked to do. The last area of analysis focuses on the users of the software.

Background

This is the fifth article in a series on applying use case points to create reliable software cost estimates. What makes use case points different is that they allow the project cost estimation to happen much earlier in the process. This cost estimation technique was developed by Gustav Karner for Rational Software Corporation in the mid 1990’s.

The introduction to software cost estimation is the right place to start if you came to this article first. In the previous article we discussed how to analyze the complexity of use cases.

Actor Analysis

When most people say “user” they think about people. Other systems are also users. Software often talks to other software, especially as we transition to more and more service oriented architectures as solutions. Actor analysis accounts for the different types of users that are expected to interact with the system.

You will identify all of the people and systems that interact with the software being estimated. Then you will classify those actors as being simple, average, or complex.

Simple Actors

Simple actors are other systems that communicate with your software via a pre-defined API. An API could be exposed through a dll, or as a REST, SOAP, or any web-service API or remote procedure call (RPC). The key element is that you are exposing interaction with your software through a specific, well-defined mechanism.

Average Actors

Average actors can either be human beings interacting in a well defined protocol, or they could be systems that interact through a more complex or flexible API.

When human users are constrained to a protocol, there is very little difference between their interactions and the interactions of systems via a defined API. This protocol may be a command-line interface, using ftp to push and pull files, or using html (with forms) for input and output. The key element to note is a well defined semantic for behavior. This differs from system to system interaction because human actions are harder to anticipate than those of other software systems.
If other systems are allowed to interact directly with the data stores of your software (e.g. direct reading and modification of the database), then they are considered to be average actors as well. It is more work to assure quality when allowing unfettered access to data stores than it would be to constrain that access to predictable behaviors.

Complex Actors

The original definition of complex actors specifies that users who interact with the software through a graphical user interface are complex actors. While that is true, the same classifcation should apply to users who interact with the system in unpredictable ways. An AJAX interface that exposes more of the underlying application (and data stores) than would be available through a rigid protocol might introduce similar complexity.

If users are interacting through a “rich html” interface, they may be better classified as complex actors. If anyone has any experience with this, I would love to hear their feedback. It seems to me that a well-reasoned AJAX implementation would leverage an API such that the actors would be classified as average actors. But I don’t have enough experience to base that decision on data – just on intuition.

Calculate The Totals

Add the following number of points for each actor in each classification:

• Simple Actor – 1 point.
• Average Actor – 2 points.
• Complex Actor – 3 points.

This represents the actor complexity factor. It will be combined with the other data previously identified (technical and environmental factors, as well as an unadjusted use case points total).

Next Step

The next step is to combine the four values you’ve identified and determine the estimated amount of effort.