Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: mchiuminatto on October 22, 2004, 11:54:40 am
-
Hi everybody.
Does anybody have information regarding how was defined the mathematical model behind this technique? I know the math model, in fact, soon I will release a web application in my site that does the calculations, but I would like to know, in depth, the reasoning behind the scene.
I will appreciate books, white papers, sites, etc.
-
Do you mean the time estimation for realizing use cases? This is pure heuristic and strongly depends on the person designing the model. The numbers from Sparx can be used as a starting point but you need to refine them in practical use.
-
Hi Thomas.
The links bellow, explains the technique.
www.cognizant.com/cogcommunity/ presentations/Test_Effort_Estimation.pdf
www.globaltester.com/sp7/usecasepoint.html
As you will see both are coincident in the formulas and the weights assignes to the factors.
My question is, how they have calculated those weights?.
What if the calculated effort differs from reality (and I bet will happen), how can I get the model closer to the reality?.
In the bottom line I want to know how can I fine-tune the technique, so, I think (some times I can do that), it would be useful to know how they have formulated the math model.
If you have any experience, I would appreciate a lot your comments.
-
Marcello,
can I quickly redirect you to this thread: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=general;action=display;num=1075285964
I'll have a closer look at your links on monday. Have a nice weekend.
-
Hi Marcello,
now I found some time to look at the links you stated. I have to repeat myself in saying that these numbers are purely heuristic. That means you have to have a lot of use cases to implement in order to get satisfactory results. There are quite many factors which actually influence the denoted weights. Simply speaking: start with as many finished projects as possible, evaluate the total time, set it in relation to the number of use cases. Draw project against total time divided by number of use cases. The result should be an almost horizontal line. Now you have the basic points (days per use case). Second step woul be to find an estimate for simple, medium and complex use cases (you could simply take the factors 5, 10 and 20) by going into detailed analysis of each use case. Whenever you come that far you might start to discuss finding more settings 8)
-
Thanks Thomas, I will take your advice; I will try a little with numbres and history.
But this technique smell a lot to function points, so I will look for something there too.
-
Have fun ;) You indeed can make this a science by itself...
-
this technique smell a lot to function points
Indeed it does. Karner, who did the original work on this as a thesis, attempted to move the function point style of estimation backwards in the design lifecycle to get an early estimate of size given just the use case and actor model.
IOW function points are excellent estimators given that the entire process is followed - this means you essentiallty cant do it until you have a conceptual system design.
Since estimates are usually needed way back at the initial scoping exercises, the point where use case approaches exhibit their greatest power, he analysed a small set of projects and proposed the UCP method.
Similar to FPC, its basis is to get some metric on overall size and convert that to an effort estimate given technical approach and environmental risk modifiers - TCF and ECF.
My basic problem with the UCP method (as opposed to FP counting) is that Karner's original constants are still used without question. Given the small sample set he based it on, I would have thought that the IT and academic communities would, by now, have reviewed and revised those constants. I have seen some evidence of the TC constant being quoted as .65 rather than .6 as Sparx has implemented but I have no reference to back that up.
(one thing about the EA UCP model that irks me is that you cannot persist your own values for TWF,TC,EWF and EC as I find that, for example, a TC and EC of .65 gives me a better IMO estimate for test effort - but thats another matter)
Karners original work does not appear to be published on the net, but "Estimating Object-Oriented Software Projects with Use Cases" by Kirsten Ribu (MSc Thesis 2001 University of Oslo, Department of Informatics) is obtainable and gives some excellent insights. I'm sorry, I dont have the link for it, though...
hth
Bruce
p.s. Ribu quotes Schneider and Winters. Applying use Cases. Addison-Wesley, 1998. as a basis reference for Karners work - but I haven't seen this work.
-
It seems this site have some interesting material regarding UCP:
http://www.bfpug.com.br/artigos.htm
Is in portuguese, but the articles are published in englisgh.
-
Hi Bruce,
the constants are not actually supposed to be constants - there is a mathematical model behind it that ensures that if you evaluate each of the factors as "no impact" or "average" (numberical value 3) then the total estimate is not impacted at all.
Exactly as you say, the method is usually used blindly, as are the proposed sets of Technical Complexity Factors and Environment Complexity Factors - yet those are the crucial part of the estimation technique. One should customize the set of the factors for his/her own need, however doing that necessarily requires recalculating the constants.
Bruno
Indeed it does. Karner, who did the original work on this as a thesis, attempted to move the function point style of estimation backwards in the design lifecycle to get an early estimate of size given just the use case and actor model.
IOW function points are excellent estimators given that the entire process is followed - this means you essentiallty cant do it until you have a conceptual system design.
Since estimates are usually needed way back at the initial scoping exercises, the point where use case approaches exhibit their greatest power, he analysed a small set of projects and proposed the UCP method.
Similar to FPC, its basis is to get some metric on overall size and convert that to an effort estimate given technical approach and environmental risk modifiers - TCF and ECF.
My basic problem with the UCP method (as opposed to FP counting) is that Karner's original constants are still used without question. Given the small sample set he based it on, I would have thought that the IT and academic communities would, by now, have reviewed and revised those constants. I have seen some evidence of the TC constant being quoted as .65 rather than .6 as Sparx has implemented but I have no reference to back that up.
(one thing about the EA UCP model that irks me is that you cannot persist your own values for TWF,TC,EWF and EC as I find that, for example, a TC and EC of .65 gives me a better IMO estimate for test effort - but thats another matter)
Karners original work does not appear to be published on the net, but "Estimating Object-Oriented Software Projects with Use Cases" by Kirsten Ribu (MSc Thesis 2001 University of Oslo, Department of Informatics) is obtainable and gives some excellent insights. I'm sorry, I dont have the link for it, though...
hth
Bruce
p.s. Ribu quotes Schneider and Winters. Applying use Cases. Addison-Wesley, 1998. as a basis reference for Karners work - but I haven't seen this work.
-
Karners original work does not appear to be published on the net, but "Estimating Object-Oriented Software Projects with Use Cases" by Kirsten Ribu (MSc Thesis 2001 University of Oslo, Department of Informatics) is obtainable and gives some excellent insights. I'm sorry, I dont have the link for it, though...
Here is a link:
Estimating Object-Oriented Software Projects with Use Cases (http://heim.ifi.uio.no/~kribu/oppgave.pdf)