Use Case Point Estimation
in [OOP]
|
From: Tomasz on 20 Sep 2005 04:27 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
From: tomasz on 20 Sep 2005 06:15 A couple of other interesting issues: 1. If you assume his use case is not correct and the transactions you should count are: Add, Update, Delete, Call API - which will change your use case from complex to simple the result you will get will be 87 hours (development) not 200 - quite a big difference. 2. The same guy has an article about Function Point estimation. In this article he estimates almost exactly the same program. However this time his estimate (for development only I presume) is only 56 hours (7 days*8 hours). Overall none of this seems to make sense unless I'm missing something. Regards, Tomasz > 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
From: AndyW on 20 Sep 2005 08:06 On 20 Sep 2005 01:27:58 -0700, "Tomasz" <tomasz(a)01systems.com> 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.
From: Phlip on 20 Sep 2005 09:06 tomasz wrote: > 1. If you assume his use case is not correct and the transactions you > should count are: Add, Update, Delete, Call API - which will change > your use case from complex to simple the result you will get will be 87 > hours (development) not 200 - quite a big difference. > 2. The same guy has an article about Function Point estimation. In this > article he estimates almost exactly the same program. However this time > his estimate (for development only I presume) is only 56 hours (7 > days*8 hours). Right. These are both examples of the following techniques leading to longer estimates and longer actuals: - specify many features before implementing them - manually test after implementation - make each use case big, so it is complete Your back-of-the-envelop math has perfectly revealed how those techniques are very sensitive to early mistakes. These tend to conflate and intertwingle easily. (Apologies I recently saw those two words online somewhere.) A small variation in estimating, multiplied over many line items of many use cases, will cause a huge change in the total estimate. That is why teams tend to use these practices these days: - only specify high-value features and immediately implement them - estimate the features in hours or half-days, and re-estimate for each new story. Don't estimate in huge batches - draw a "burn down chart" of the feature counts implemented - specify tiny-bite sized features with only a very few fields of each of those "use case" templates filled out - write automated tests before writing the tested code Using those techniques, the person empowered to specify stories can control the system by learning how to reduce each feature to an estimatable size. This provides great stability for a team, and allows the empowered person to review the live program as it grows, and _censor_ features and line items that should not affect the schedule. Then, the slope of the burn-down chart becomes the schedule estimate. _Not_ the total of all the estimates of a huge batch of fat user stories. Teams should never think only complete and detailed user stories will lead to fully useful programs. -- Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
From: tomasz on 20 Sep 2005 09:37
Thanks for the reply. So far I've been using functional decomposition and estimation on a fine grained level based on previous experience. I've combined it with an estimation for a minimum and maximum effort to get an idea of possible risk. We usually do the estimates in a group and then discuss the differences to find the holes in our assumptions as well. However finally on a low level it is based on judgement and experience and does not seem to be accurate as much as we would like. Based on this approach I've been thinking that expected effort would be around 1 week with maximum of 2 weeks (with fully perfect documentation, etc.) and possibly 2-3 days if we were under real pressure. Thus I was really surprised when I've seen the 200-300 hours estimate. I would like to ask you a couple of questions: 1. It seems to me that use case estimation is based on processing (transactions) and ignores complexity of data. I mean let's assume you have the same use case, same transactions, but instead of capturing 4-5 fields you need to capture 100 (no special processing just simple validation). How will this affect use case estimate? 2. Can you recommend a good book or even better good online training (best with assessment or exam) for Function Points or Use Case Points estimation? 3. How do you estimate effort for the RFP responses - when you do not have enough details to perform Use Case or Function Points analysis? Regards, Tomasz |