Estimating
what effort is needed to develop an IT solution is not an easy act. The
pitfalls are multiple and chances are that you end up guessing.
In this
post I will outline how to estimate projects based on the use cases. In
addition I will show you how you can use Use Case estimation to negotiate with
suppliers.
Estimation
can be hard. Luckily a number of techniques exist that can give you a qualified
(gu)estimate.
Among
others, the following popular estimation techniques for estimation IT
development exist:
- Expert Judgment
- Lines of
Code (LOC)
- Function
Point Estimate
- Use Case
Point Estimate
Expert Judgment is when you rely on an estimate based on talking
to experts. Especially valid when talking to experts experienced in the domain
and with experience from developing similar solutions. Investigations shows
that expert judgments can be fairly valid and almost as valid as more proven
methodologies. Challenges are for example how to find the right experts and to
evaluate their expert level. Furthermore, it can be hard to convince others
(for example your supplier) that your estimate is valid, because it is a subjective
evaluation.
Lines of Code (LOC) are a technique that is fairly reliable in the
hands of an experienced team. The technique says, as a rule of thumb, that it
takes X number of hours to develop Y lines of code. For example 100 hours per
1000 lines of code. An disadvantage of this technique is that you need to know
how many lines of code you are going to produce – this can be estimated for
example for a 1:1 conversion of an existing system, but can be hard to
determine in other situations. Another disadvantage is that you need an
experienced team to do the estimation, and you need to compare with similar
systems – the amount of lines of code in a from-scratch-developed-system might
differ from a similar system developed using a industry-standard-solution or
framework.
Function
Point Estimate,
is an estimation technique developed by IBM. It counts the elements of the
functional requirements and based on that calculates an estimate. The technique is very usable and accurate. The
advantage of this technique is that it is fact based and can be used by teams
not experienced in the domain of the solution. Another advantage is that the
cost of the project can be based on previous/other projects, and that other
estimates using Function Point Estimation within your organization can be used
as baselines. A description on how to use Function Point Estimation can be
found here: http://en.wikipedia.org/wiki/Function_point
Use Case
Point Estimation is a technique developed by the Swede Gustav Karner in 1993.
The Use Case Point estimation technique is based on the same principles of
Function Point estimation and has the same advantages. It has turned out that
Use Case Point (UCP) estimation is as reliable as Function Point
estimation.
An explanation of the content of Use Case Point
Estimation can be found here: http://en.wikipedia.org/wiki/Use_Case_Points
“What makes this technique
particular interesting is that by using UCP estimation you are able to produce
a reliable estimate very early in the development cycle.”
“Actually even after sketching the use case
model you are able to produce an estimate, apply it to the business case and
consider stopping the project at this early stage, if the business case is not
positive. That is a strong asset”
The figure
below outlines where in the development cycle the various estimation techniques
apply.
Lets have a look on a practical
example on how to use the UCP estimation technique:
Lets say
you’ve created the following simple use case model:
In this use
case model there are seven use cases and two actors. The UCP technique involves
ten calculation steps. Once learned they are easy to follow and your UCP
estimate can be calculated within minutes.
The very
first step is to calculate the Unadjusted Use Case Weight (UUCW). For calculating
the UUCW you look at the number of use cases in your use case model, categorise
them and calculate a UUCW score. The UUCW score will be used in other
calculations as we move forward. So, we already know we have seven use cases.
Those seven use cases needs to be categorised into Simple Use Cases, Average
Use Cases, and Complex Use Cases.
In the
table below you can see how each Use Case Category is described. Simple Use
Cases are those having 1-3 transactions, and so on.
You just
need to determine for each use case how many transactions they have in order to
categorise them. To do so, you could have a look at the activity diagram and
count the number of times the flow control switches from actor side to system
side and vice versa.
For example
in use case #1 the activity diagram could look like the one shown below
(Notice: The activity diagram could as well be represented by a table showing
the steps):
When
looking at the activity diagram you can see that the control flow starts in the
User side where the user is on a screen typing in some details. At some point
in time the User chooses to save the input and clicks “Save”. By doing that,
the control flow switches to the System side where the system validates the
input.
When
counting the transactions you should count the number of times the control flow
switches lane (crosses the lane line) – except for error handling – those
should not be counted.
So, in the activity
diagram above I count three lane crossing – when I subtract the one involved in
error handling, I calculate a total of two transactions for that use case.
Imagine
doing this for all seven use cases in the use case model, we might end up with
following categorising and a total UUCW score of 45:
“As you might have noticed
you are now taken advantage of having documented your use cases properly by
using activity diagrams with clear division of actor lanes!”
So far, so
good.
The next
step is to calculate the unadjusted Actor Weight (UAW) score. The UAW score
tells something about the complexity of the solution. The Actor categories
shown in the figure below doesn’t need much explanation.
When
looking at the use case model shown in top (above) of this post, let’s assume
that the two actors are human beings. The UAW score is then ‘6’ as stated in
the figure above.
The next
step in calculating the UCP score is to calculate the Technical Complexity
Factor (TCF). The Technical Complexity Factor is often the most confusing part.
In short, the TCF score adds an overhead of complexity to your score – the more
complex the technical part of your solution is the higher score. Lets have a
look at the TCF below:
By filling
in the 13 factors above you’ll reach a score of 0,8 (TCF). Notice that the Complexity
Factor (not to be confused with TCF) is 0.6. The formula to get to the TCF is
just to multiply the Complexity Factor by 0.01 – don’t ask! it just happens to
be the formula.
The final
calculation to do is calculating the Environmental Complexity Factor. This
factor is even more confusing than the TCF score. As you can see from the
figure below the impact of various factors are rated. This gives you a sum (ETF)
that goes into the ECF formula:
So far the following calculations has been performed:
Unadjusted Use Case Weight : UUCW
Unadjusted Actor Weight: UAC
Complexity Factor: CF
Technical Complexity Factor: TCF
Environmental Technical Factor: ETF
Environmental Complexity Factor: ECF
By having those six formula results you are now able to calculate the
Use Case Point result. The Use Case Point for your solution is based on the
following formula:
UCP = (UUCW + UAW) x TCF x ECF
Here is what the calculation from the example in this post looks like:
UUCW = 45
UAW = 6
TCF = 0,8
ECF = 1,085
UCP = (45 x 6) x 0,8 x 1,085
UCP
= 44,268
Now, what use do you get from that?
Knowing that this project or this solution equals 44,268 worth of Use
Case Points tells you a lot about the size of your project/solution. For
example if you previously developed a solution worth 88 Use Case Point you now
know that (with all other things being equal) this project is about half as
big. This is valuable information in estimating the effort.
If you know that the previous solution you developed (the one worth 88
UCP) demanded you 1000 hours of development,
then it is likely that this new solution will take you about 500 hours to
develop. That is, what the final calculation is all about: The Productivity
Factor (PF).
The Productivity Factor (PF) is the hours of development per use Case
Point. If the PF equals 10 then; (from the example above) the project estimate
is (10 x 44,268) 442,68 hours.
Using the UCP method for creating estimates and discussing those
estimates with suppliers can involve a lot of arguing about what the right PF
factor should be. The supplier of course, will argue that the PF factor should
be fairly high – e.g. 20 or 25. You, on the other hand, might argue that the
productivity factor should be way lower – e.g. 9 or 8. So, what is right then?
Reading materials explaining UCP estimation often suggests that a productivity factor
of 20 is correct. The thing is though, that it depends.
Building
your own baseline of PF Factor documentation
What you should do is to start collecting knowledge about your projects
and the realised PF calculated. Let’s say you have completed a project and that
the UCP point calculated for that project was 120. Now, if you spend 1800 hours
developing the solution then your realised PF is: 1800/120 = 15
Imagine doing this for all your projects the result could look like illustrated
below.
Now, by tracking your realised PF you can calculate a baseline by
calculating an average PF of 12,6.
What the average PF of 12,6 tells you is that in average, when
developing solutions in your organisation, using your IT environment, dealing
with your business complexity, you spend in average 12,6 hours per use case
point.
You could take the UCP baseline calculation a step further. For example
if Project1 and Project2 are infrastructure projects and Project4 and Project7
are ERP projects you can create various Realised PF baselines depending on the
project type ….. or depending on the suppliers, or in-house / external
development, or, or….. The possibilities go on. It only requires a solid base
of project tracking.
Using
this information to control your suppliers
By having an average PF calculation you are able to create a documented
fact based estimate. With a fact based estimate you have a better position when
negotiating with suppliers.
-
Why
can’t you deliver on a PF of 12,6, when all our other current suppliers in
average delivers on 12,6 PF?
-
If
your offer is based on a PF of 30 we believe you are charging too much based on
the performance of our other suppliers/projects
-
If
your offer is based on a PF of 4 we fear that you have not understood the
complexity of our project, or that you under-charge just to get your foot in.
-
All
right, we’ll accept your offer based on a PF of 20 once again, but you must
document a strategy on how to optimise your performance to match our other
suppliers.
Warning
Remember that UCP estimation and PF calculation are not absolute truths.
What you get is an estimate based on facts and an estimate that gives you a
feeling of what end the “real” estimate should be in.
