Software Cost Estimation With Use Case Points – Introduction

[Update: Welcome carnival readers, thanks for the visit, we hope you like this and the other articles here and stick around to share with the community! Scott]

Estimating the amount of work required to deliver software is hard. Estimating the amount of work in the very early stages of a project is even harder. A method was developed to estimate the amount of work required by analyzing what the system will allow its users to do. That method is called Estimating With Use Case Points. This article is an introduction to the concept.

Why Is Estimation Hard?

Predicting the amount of work required to complete a job requires an understanding of the job. At the beginning of a software project, people don’t have a detailed understanding of what the job actually entails. Imagine that your job is to create a website that allows people to create, manage and share their family trees (details of their ancestry). With that little amount of information, you can’t reliably predict how much work is involved. You need to know a lot more.

How Do I Start The Estimation Process?

One way you can approach the work is to start by defining all the things the software will do. You can list out the functionality, and then estimate the amount of effort required to create that functionality. With experienced team members you can get good estimates of how much effort is required to create the functionality. The problem is that you don’t know what the functionality needs to be – at least not at the beginning of a project.

The functionality you need derives directly from what the software needs to do. What the software needs to do is meet the goals of the users. OK, so the first step is to define the relevant goals of the users. Wait – the first step is to define who the primary users are.

1. Define the primary users of the software.

Back to our example genealogy example. The primary users you are targeting are 30-50 year olds who have aging parents and who realize that they are about to lose a lot of knowledge about their ancestry. The secondary users are other family members and other software applications (you want to expose an API that helps integrate this site with other social networking sites). Now you can identify their goals.

2. Define the goals of the users.

OK, now you have users and goals. But goals can’t be estimated either. How much effort does it take to help someone bring their extended family close together? How much money must be spent to help someone get a sense of identity?

Addressing the personal goals of users is critical to creating great software. The next step is to identify the things that your users will do in order to achieve their goals. In a structured requirements world, use cases support goals. This is why you write use cases.

When your approach is user-centric (like this one), you can incorporate some of the ideas from the interaction design camp.

In this case, you use a person’s practical goals to identify the use cases that support the goals of your primary users and secondary users. You can narrow down that list of use cases to only include those that involve your software.

3. Define the use cases.

You can use any of a number of formats for documenting the use cases.

• You can document usage scenarios.
• You can document formal use cases.
• You can document informal use cases (free informal use case template for MS Word).
• You can create UML 2.0 use case diagrams.

For the purpose of software cost estimation, informal use cases are the fastest to define. Formal use cases provide a way to capture additional detail that will help to validate the complexity of the use cases. The additional detail available in the formal use case document is not, however, needed to create a project cost estimate using use case points.
4. Calculate the effort to implement the use cases.

You can use the use case points methodology to determine the relative size of the project, and then convert that to predicted man-hours.

Use Case Points

Use case points is a measurement of how much effort is required to write software – based on how much work the software is intended to do. The use case point method was created by Gustav Karner of Rational Software Corporation in the mid 1990’s. This method was based on a study of about 200 projects with an average size of 5 man-years of effort. The use case point method of estimation was found to be within 10% of the actual results for over 95% of the projects. This method has since been incorporated into the RUP methodology.

The cost estimation technique of use case points evaluates the following factors to determine an estimate of cost:

1. Technical Factors of the Implementation. Primarily non-functional requirements of the system.
2. Environmental Factors. Mostly characterizing the implementation team, but touching on process as well.
3. Use Case Quantity and Complexity. The number of use cases and the number of steps within the use cases.
4. Actor Quantity and Complexity. The number and type of actors and interface.
5. Effort Estimation. The previously collected data is converted into man-hours.
6. Free Excel Spreadsheet for Calculating UCP. Download it today. Its free.

In this series of articles we will discuss what is involved in each step.

Summary

The earlier in the cycle you can develop reliable cost estimates for software, the greater the chance that you will achieve software product success.