Software Cost Estimation With Use Case Points - Final Calculations

The final step in project cost estimation with use case points is to do the math. First you identify the technical and environmental factors that influence your environment and describe your team. Then you analyze the use cases and actors that describe the expectations of the software and who has them. Finally, you bring it all together to do the math.

Background

This is the sixth 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:

1. Technical Factors of the Implementation. Characterizing (non-functional) requirements of the software.
2. Environmental Factors. Describing the team and the process.
3. Use Case Quantity and Complexity. Representing what the software is asked to accomplish.
4. Actor Quantity and Complexity. Enumerating the users of the software.

Collecting The Use Case Point Data

Use the links above the abacus to review any of the calculations that you performed in the previous articles.

In the first step you determined a numerical representation of the technical factors for your software. This is the technical complexity factor, TCF.

In the second step you created a number representing the environmental factors that influence your team’s ability to get the job done. This is the environmental factor, EF.

In the third step you measured the use cases, creating a representation of the quantity and complexity of the use cases that the software must enable. This is the unadjusted use case points, UUCP.

In the fourth step you reviewed the users of the software - both people and other systems. This is the actor weighting, AW. [Note: Some articles refer to this as the unadjusted actor weight, or UAW].

Calculating The Use Case Points

The formula to calculate use case points is described below in terms of the variables from above: TCF, EF, UUCP, and AW.

Use Case Points = (UUCP + AW) * TCF * EF.

The total use case points equals the sum of unadjusted use case points plus the actor weight, multiplied by both the technical complexity factor and the environmental factor.

The next step is to convert this normalized representation of “how big the job is” into an estimate of effort.

Determining Effort From Use Case Points

This is the part where your math becomes an estimate of effort.

Unfortunately, this is where opinions can sneak in when you’re first using use case points. Different experts identify different values to use.

• Karner, the originator of the approach, suggests using 20 hours of effort per use case point.
• A case-study team, cited by Ed Carroll, found empirical data to support using 28 hours per use case point.
• Other estimates range from 15 to 30 hours per use case point, cited by Roy Clem.

Another approach proposed that “complex projects” have a higher conversion factor (28 to 1) than “simpler projects” (20 to 1). The following calculation determines if a project is complex:

For each of the following environmental factors that has a value below 3, add a point.

• 1. Familiarity with the project.
• 2. Application experience.
• 3. Object oriented programming experience.
• 4. Lead analyst capability.
• 5. Motivation.
• 6. Stable requirements.

For each of the remaining environmental factors that has a value above 3, add a point.

• 7. Part time staff.
• 8. Difficult programming language.

Add up the points. If you have fewer than 3 points, use 20 hrs per UCP. If you have 3 or 4 points, use 28 hrs per UCP. If you have 5 or more points, restructure the project.

This makes a lot of sense - it essentially says that inexperienced teams will take 40% longer to complete the project. And when there is a significant disconnect (between capability and expectation), the project should be reset - to lower expectations or increase capabilities or both.

Revise and Refine

The key thing to note is that these “generic” effort-to-UCP conversions are a starting point. You have to adjust them over time to improve the accuracy of your estimates. Maybe you will need to rethink what it means to be “experienced,” or just how difficult “difficult” is.

Use Case Points Can’t Be Proven To Work

This actually identifies a weakness in the approach - you can never prove that it works (or doesn’t). Essentially, you have one equation with two unknowns. If an estimate is proven wrong at the end of the project, it could be because the calculation-math is flawed, or it could be because the estimates along the way are flawed. If your estimates prove to be right, it could be because both are wrong, and the errors happen to cancel each other out.

Use Case Points Are Still Valid

Nonetheless, use case point-based software cost estimates are still reasonable. Producing an estimate with use case points will result in a greater likelihood of project success than any other estimate (that I know of) that can be performed at the same stage in the project, with the same amount of data. And the introspective act of calculating UCP at the beginning of a project will help find and avoid costly mistakes later in the project.

Save Time And Effort

[Update: Download our free excel spreadsheet for calculating use case points.]

This article was published on Monday, February 19th, 2007 at 9:00 pm and is filed under Business Analysis, Product Management, Project Management, Requirements, Requirements Models, Use Cases.
You can leave a comment on this post.
Trackback URL