Re: Use Case Point Estimation
- From: AndyW <foo_@xxxxxxxxxxxxxxxx>
- Date: Wed, 21 Sep 2005 00:06:18 +1200
On 20 Sep 2005 01:27:58 -0700, "Tomasz" <tomasz@xxxxxxxxxxxxx> wrote:
>I'm new to both Use Cases and Use Case Point Estimation.
>I've ben reading some articles about it and found the following
>(recommended as a reference on this site as well):
>http://www.geocities.com/shiv_koirala/fp/usecasepoints.html
>
>As a person that learns best on practical examples I liked the approach
>taken in this article.
>
>However:
>1. The final estimate seems to me a bit excessive for such a simple
>application.
>2. As I understand from other articles this estimate includes:
>Analysis, Design, Implementation and Unit Testing, it does not include
>Testing effort which would add another 90 hours of effort.
>3. The use case presented there seems a little to detailed (I mean it
>goes down to almost pseudo code) and the resulting estimate is very
>large.
>
>Can anyone give me their practical comments on this example?
>I mean is this use case correct? If not how would a correct use case
>look like?
>Is the estimate correct? If not which parts should be modified?
>
>Regards,
>
>Tomasz
I get the feeling that work is not the authors own stuff. I've seen
quite a lot of that in other books.
There are 7 requirements. Of these, 3 are just validations, 1 is the
actual functional requirement (what needs to be developed), 1 is a non
functional requirement, 1 is a business requirement (which when
examined hides another functional requirement) and the last is some
esoteric environmental constraint.
Of the two functional requirements you have the operator to perform
CRUD activites (this may be an already existing feature) and the other
is to make one or more API calls (both need requirements analyssis
performed to confirm this).
So you are looking at at least 2 man days work minimum, considering
its unlikely a foreign API actually works as intended - especially one
from ericsson [grin]. Try thinking in the ballpark of a minimum of
about 5 man days.
I dont know a programmer who works 25 days (effectively a month) for
only $840. Thats about $28 per hour. I assume US currency - thats a
bit low, I would expect perhaps $70/hr would be a more reasonalble
rate.
[Note: I dont know the actually going rates in the US, but thats close
to a rate I used in the last US company I worked for].
So i'd be looking at about $2800 for 5 days work. And that would
assume no setup costs/time.
Sods law dictates that someone is going to have to manipulate some
code in the customers system and thats going to generate some effort
involved in learning how to do that and creating a duplicate
development environment.
Once you start adding in all these environmental factors, testing and
all that, you get somewhere between 15 and 20 man days effort at
whatever cost that works out to - more than $840 anyhow.
As you can see I've already given a variation between 5 days and $2500
and 20 days at $10k. The reason for the difference is that the lower
end would be a likely scenario of it was in-house development or you
already had a development relationship with the customer. The higher
end would be more likely if the customer walked in off the street.
(not that the use case in the example also had a stated variation of
+/- 40%).
Creating the Use case is a good idea, but I tend (for personal
reasons) to use function point analysis using hystorical metrics for
job costings - its way more accurate.
A common industry mistake for such a trivial piece of work (and one
often made by programmers) is to say they could do it in a day. There
is a lot of environmental uncertainty in that job, hence I've given a
range estimate that includes risk rather than a more acurate single
figure value - you'd do a normal job costing with. The author hasnt
taken risk into account. Instead, under environmental factors, its
been deemed a simple project which is a classic example of the mistake
in action. No-oe would make that classification without performing
some form of business environment and/or risk analysis first - that
information isnt on that website. Without first quantifying the risk,
your on a hiding to nothing should something unexpected happen.
Just my thoughts.
.
- Follow-Ups:
- Re: Use Case Point Estimation
- From: tomasz
- Re: Use Case Point Estimation
- Prev by Date: Re: Comparing design by contract with defensive development
- Next by Date: Re: Comparing design by contract with defensive development
- Previous by thread: ANN (Presentation)::: The Art of Agility and the Agile Unified Process (AUP)
- Next by thread: Re: Use Case Point Estimation
- Index(es):
Relevant Pages
|
|
