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!
