Lines of Code Versus Functon Points Versus Use Cases For Sizing
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.
Click here for a blog on software sizing as part of the estimation process
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Dealing With Generated Lines of Code We have gotten several questions recently on how to estimate using lines of code when the lines are generated, that...
- Counting (Or Estimating) Lines of Code Counting or estimating lines of code is a viable sizing method so long as consistant counting rules are used and...
- Original Function Point Paper Here is (one of) the original papers on Function Points, circa 1983. I love the simple definition of function points...
- Counting XML Source Lines of Code A customer recently asked how to count XML for their software sizing activity. Turned out the question was more detailed...
- New Code Counter Update Available from USC The University of Southern California has been developing and updating line of code counters for a number of years. Such...
Comments
3 Responses to “Lines of Code Versus Functon Points Versus Use Cases For Sizing”
Leave a Reply
Project Prediction Infographic
It may be helpful to think about this in terms of the ‘grammar’ of the metric and whether it matches the language of what you are developing. Lines of code and function points of may come into play at the same time, but are each better matched to certain types of systems.
can you please suggest were can we get the PF(Productivity Factor) in UCP(Use case point) estimation. Is there any body which sells actual project data of UCP estimation.
Shall be waiting for your response.
[...] From Dan… Functional sizing methods such as Function Points, SEER Function Based Sizing, Use Case Points, COSMIC Function Points, etc. [...]