10 Step Estimation Process Sample Checklist
View our 10 Step Estimating Process Checklist. This checklist should be tuned to the individual company’s needs and suggestions.
I, along with many others, have written about the virtues of one size metric versus another. Some attempt to make their measure look better by bashing the others (a curious approach used by too many, in my opinion)
Lines of Code: Can Work I hear some people say “Lines of code don’t work because people don’t know how to count them.” I certainly agree that if the definition of a line is not consistent sizing will suffer. But some of these same people say “function points do work because they are not language specific and they are better defined that is sometimes true.
So many issues with Lines of code counting.. My personal favorite definition of lines of code involves using logical lines meaning that the number of physical lines it takes to write a statement is irrelevant. That it is the logical statement that is important. Even there some people call my definition of logical lines physical lines. Go figure. Of course SEER for Software will work with any definition, as well as the many function point definitions.
Function Points Can Work: There is some sound logic to the argument that function points work because they have a common definition. Only problem is…
So many organizations make up their own definition… I recall reviewing a project estimate on a major program. One of my standard questions “what is a function point” got an odd stare. They said they would have to get back to me on that. When they finally did I found that they had their own, company specific definition, nearly 10 times bigger than traditional. Now that is not all bad.. if a consistent definition is used it is likely OK for estimating. Only problem is they didn’t normally advertise that their definition was different. So, when showing productivity they were much more productive. But models showed over estimation (in SEER for Software they could have defined their new function point method and resolved this but they didn’t… they just put their not a function point count in as normal function points. This is not a one time occurrence. I have seen this on numerous occasions.
Oh.. and go tell senior management a system is 4000 function points. More likely than not you will receive a blank stare. A function point is a pretty esoteric concept to the uninitiated.
SEER-FBS in the table refers to SEER’s function based sizing. Function based sizing can be used to approximate function points from simple characteristics with end user oriented language. And it shows independent functionality. For example, what is the effort to add 1 report. Function based sizing was developed during a multi year study of how to make function point analysis quicker and consumable by laymen.
Use Cases Can Work:Then there are those who want to use use cases as their size measure. I like use cases and we have written papers on this topic and even have an automated use case extraction adapter to SEER-SEM. Unfortunately, however, use cases cannot, by their very nature, provide as much fidelity in the estimate as more granular measures. So… use cases are great for early estimates or high level portfolio planning. But if a project manager wants a detailed estimate and plan, use cases provide too much variance in the estimate. This is due to their nature. They are wonderful since they are natural artifacts of the development process. But they are much higher level abstractions of the problem. My recommendation, use use cases early, then a more detailed size measure when producing a detailed project plan. Use case points, derived from use cases can help a bit if you are willing to refine the use case point estimates. But now you may sink back into the function point issues.
Bottom line: all three measures, lines, function points and use cases can be used for estimation. Definition is important. And the closer to the natural artifacts of development the approach is the more likely it is to be used. But just using use cases will have more variance.
Estimating Total Cost of Ownership (TCO)
Find out how you can use Total Cost of Ownership (TCO) model to create an estimate which includes all the costs generated over the useful life of a given application.
Should Cost Analysis
Learn how Should-Cost Analysis can identify savings opportunities and drive cost efficiency in procurement and manufacturing processes.
ROM Estimate: The First Step Towards a Detailed Project Plan
Find out what ROM (rough order of magnitude) estimate is and why is it a crucial element of every project planning cycle.
Software Maintenance Cost
Find out why accurate estimation of software maintenance costs is critical to proper project management, and how it can make up to roughly 75% of the TCO.
