As I told you lately there are several ways to estimate the effort for software projects. Most important for all of them is that they don't just create their values through some kind of voodoo magic. They have to use a comprehensible and parameterizable way for their calculation. First this is needed to get a better base for argumentations with you project stakeholders. Second you'll have to review your calculation during the development and when it is finished to adjust those parameters for future calculations.
Instead of thinking about an own, totally new way of estimation it often is much better to use the experiences of others and fall back to well proven methods. It's not only that you can learn from them. But you have also by far less problem when arguing your numbers. I've really often undergone and observed how high values for the first effort estimation based on the developers experience frightened the project management or the customer. As a result the developers are forced to recalculate (!) until the values are low enough. *sigh* What a bad, bad way, almost allways leading into a project failing or at least a strong delay. Estimations based on more academic methods are accepted much more instead.
My favorite methods are the function point analysis (FPA) together with COCOMO II. The first one is a method that examines the software project from five angles. Those are external inputs, external outputs, external inquieries, internal logical files, and external interface files. Based on parameters their complexity is rated as low, medium, or high. At the end they are counted for each type and complexity multiplied with a defined value. Adding all together results into the unadjusted function points, an abstract unit for the size of a software. Too fast? Don't panic, I'll document this here in a later entry and you'll see how simple it is. But the FPA isn't finished here. Non-functional requirements also have influence on the effort. So there are 14 general system characteristics, each one with six descriptions and assigned values from 0 to 5. 0 means that there is no influence, 5 shows a high impact of the characteristic for the project. All together lead to a value adjustment factor between 0.65 and 1.35. Multiplied with the unadjasted function point you now get the total adjusted function points. I'll also cover this in detail later.
And now? How does it help me to know that my project has a size of 2731 total adjusted function points? The next step is to determine the total program size for the used language. There are different tables available, like http://www.qsm.com/FPGearing.html. The values here help you to get a feeling for the size of your application in source lines of code (SLOC). So for our TAF value above we would get 166,591 SLOC in JEE, 161,129 in C#, and 95,585 in Smalltalk. For some this may be astonishing, but not for Smalltalkers with Java and .NET experience. *smile* The table of languages on the page above also shows Notes or SQL. That doesn't mean that all those languages fit for the same problems. Also some of the newer languages like Ruby or Python are missing.
Even if we're now a step further we still don't know the effort. This will be calculated with the help of COCOMO II. This method provides formulars which take the software size as estimated above as an input parameter. Another one is the size of reused code. There are several more input parameters, but the most important are the scaling factors, the product factors, the platform factors, the personnel factors, and the project factors. Alltogether 22 factors have to be rated between very low and extra high by given questions and answers. Playing around with the result values shows how much influence the answers have. As a result you get the total effort and the duration. COCOMO II is more complex than the FPA, but it is also not so difficult to handle. I'll write about it later, too.
Right here the estimation isn't finished. But you allready have got the most important values: How much will it cost (in personnel) and how long will it last. Doing this more often, in different project and with reviews of project in progress or finished projects you'll get more training in estimate the size right and to rate the general system characteristics and the factors better. COCOMO II additionally allows you to adjust the parameters to your company and environment. So you'll get even better estimations.
Instead of thinking about an own, totally new way of estimation it often is much better to use the experiences of others and fall back to well proven methods. It's not only that you can learn from them. But you have also by far less problem when arguing your numbers. I've really often undergone and observed how high values for the first effort estimation based on the developers experience frightened the project management or the customer. As a result the developers are forced to recalculate (!) until the values are low enough. *sigh* What a bad, bad way, almost allways leading into a project failing or at least a strong delay. Estimations based on more academic methods are accepted much more instead.
My favorite methods are the function point analysis (FPA) together with COCOMO II. The first one is a method that examines the software project from five angles. Those are external inputs, external outputs, external inquieries, internal logical files, and external interface files. Based on parameters their complexity is rated as low, medium, or high. At the end they are counted for each type and complexity multiplied with a defined value. Adding all together results into the unadjusted function points, an abstract unit for the size of a software. Too fast? Don't panic, I'll document this here in a later entry and you'll see how simple it is. But the FPA isn't finished here. Non-functional requirements also have influence on the effort. So there are 14 general system characteristics, each one with six descriptions and assigned values from 0 to 5. 0 means that there is no influence, 5 shows a high impact of the characteristic for the project. All together lead to a value adjustment factor between 0.65 and 1.35. Multiplied with the unadjasted function point you now get the total adjusted function points. I'll also cover this in detail later.
And now? How does it help me to know that my project has a size of 2731 total adjusted function points? The next step is to determine the total program size for the used language. There are different tables available, like http://www.qsm.com/FPGearing.html. The values here help you to get a feeling for the size of your application in source lines of code (SLOC). So for our TAF value above we would get 166,591 SLOC in JEE, 161,129 in C#, and 95,585 in Smalltalk. For some this may be astonishing, but not for Smalltalkers with Java and .NET experience. *smile* The table of languages on the page above also shows Notes or SQL. That doesn't mean that all those languages fit for the same problems. Also some of the newer languages like Ruby or Python are missing.
Even if we're now a step further we still don't know the effort. This will be calculated with the help of COCOMO II. This method provides formulars which take the software size as estimated above as an input parameter. Another one is the size of reused code. There are several more input parameters, but the most important are the scaling factors, the product factors, the platform factors, the personnel factors, and the project factors. Alltogether 22 factors have to be rated between very low and extra high by given questions and answers. Playing around with the result values shows how much influence the answers have. As a result you get the total effort and the duration. COCOMO II is more complex than the FPA, but it is also not so difficult to handle. I'll write about it later, too.
Right here the estimation isn't finished. But you allready have got the most important values: How much will it cost (in personnel) and how long will it last. Doing this more often, in different project and with reviews of project in progress or finished projects you'll get more training in estimate the size right and to rate the general system characteristics and the factors better. COCOMO II additionally allows you to adjust the parameters to your company and environment. So you'll get even better estimations.
0 Comments:
Post a Comment