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
To deliver the above example will then take:
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:
|
Phases
|
% effort
|
Estimated duration (man
days)
|
|
Business analysis
|
30
|
40
|
|
Systems analysis
|
20
|
27
|
|
Design
|
10
|
13
|
|
Construction
|
25
|
33
|
|
Testing
|
10
|
13
|
|
Rollout
|
5
|
7
|
|
Total
|
|
133
|
Figure 2. Estimation per SDLC phase
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!
