Use case based estimation
How long will your software development project take? How long is a piece of string? If you are in software development, you are always faced with the problem of estimation. It is difficult to predict accurately how long software development will take because of the underlying complexities in requirements that are not always well understood. Many techniques exist, some very complex, others requiring PhD's in Computer science, Mathematics and Quantum Physics. Even something like function point counting, which seems to be straightforward (you appoint highly paid consultants) seems difficult and may have huge variations, depending on who did the count.
For the average develop manager who often do not have the time and resources to do a proper function point count or other estimation we offer a basic estimation method using a use case based approach. This idiot's guide to the idiot's guide of estimation is a quick approach to getting an 80% correct estimation for a software development project. The downside of this approach is that you will have to have some idea of how long it takes to deliver work across a systems development life cycle.
Step 1. Develop use cases to the correct level of granularity.
If use cases are to be used as a basis for estimation, it is important to properly develop them to the correct granularity level. Xpdian has formulated a definition of an elementary use case which has proven successful for good estimation. The definition is as follows:
An elementary use case is a self contained interaction that is executed by one primary actor, in one place, with no intervening time delays.
This definition implies a systems use case that will be started by a user, executed and completed without time delays. With other words, it is an atomic transaction that is started and finished. To demonstrate the principle we will use the following example:
Figure 1. Estimation example
Step 2. Allocate points
In this example we have four granular transactions represented by use cases. Several estimation methods advocate that, depending on complexity, scores of between 5 and 15 points be allocated to each use case. We are going to standardize that number on 10 points per use case.
This implies => 4 use cases x 10 points = 40 points
Step 3. Estimate effort
Estimating the effort now is dependent on the time it will take to deliver a point. Industry resources suggest that a total of 20 man hours per point across the whole systems development lifecycle can be used as a starting point. The SDLC will then include the following phases:
Total time required = 40 points x 20 man hours
= 800 man hours
Assuming six hour days (effective effort) are worked => 800/6
= 133 days to deliver the entire SDLC
Taking into account the average effort involved in the SDLC phases, we can now calculate the following:
Conclusion
The above mentioned timeframe may change significantly depending on the ability of your organization to deliver points per time period. You may want to use the method initially to detect the ability of the organization to deliver and then refine it over time. The success of the method is greatly dependent on the correct definition of the use cases at the right level of granularity and getting the scope of the project right.
This simplified method is derived from a more complex and scientific method which we will discuss in an upcoming article.
Making life easy!
How long will your software development project take? How long is a piece of string? If you are in software development, you are always faced with the problem of estimation. It is difficult to predict accurately how long software development will take because of the underlying complexities in requirements that are not always well understood. Many techniques exist, some very complex, others requiring PhD's in Computer science, Mathematics and Quantum Physics. Even something like function point counting, which seems to be straightforward (you appoint highly paid consultants) seems difficult and may have huge variations, depending on who did the count.
For the average develop manager who often do not have the time and resources to do a proper function point count or other estimation we offer a basic estimation method using a use case based approach. This idiot's guide to the idiot's guide of estimation is a quick approach to getting an 80% correct estimation for a software development project. The downside of this approach is that you will have to have some idea of how long it takes to deliver work across a systems development life cycle.
Step 1. Develop use cases to the correct level of granularity.
If use cases are to be used as a basis for estimation, it is important to properly develop them to the correct granularity level. Xpdian has formulated a definition of an elementary use case which has proven successful for good estimation. The definition is as follows:
An elementary use case is a self contained interaction that is executed by one primary actor, in one place, with no intervening time delays.
This definition implies a systems use case that will be started by a user, executed and completed without time delays. With other words, it is an atomic transaction that is started and finished. To demonstrate the principle we will use the following example:
Figure 1. Estimation example
Step 2. Allocate points
In this example we have four granular transactions represented by use cases. Several estimation methods advocate that, depending on complexity, scores of between 5 and 15 points be allocated to each use case. We are going to standardize that number on 10 points per use case.
This implies => 4 use cases x 10 points = 40 points
Step 3. Estimate effort
Estimating the effort now is dependent on the time it will take to deliver a point. Industry resources suggest that a total of 20 man hours per point across the whole systems development lifecycle can be used as a starting point. The SDLC will then include the following phases:
- Business analysis
- Systems analysis
- Design
- Construction
- Testing
- Rollout
Total time required = 40 points x 20 man hours
= 800 man hours
Assuming six hour days (effective effort) are worked => 800/6
= 133 days to deliver the entire SDLC
Taking into account the average effort involved in the SDLC phases, we can now calculate the following:
Conclusion
The above mentioned timeframe may change significantly depending on the ability of your organization to deliver points per time period. You may want to use the method initially to detect the ability of the organization to deliver and then refine it over time. The success of the method is greatly dependent on the correct definition of the use cases at the right level of granularity and getting the scope of the project right.
This simplified method is derived from a more complex and scientific method which we will discuss in an upcoming article.
Making life easy!