Webinar Alert - CRED Model: Your Guide to Reliable Cost Risk Management

Galorath
Book a Consultation search close
Book a Consultation

Lines of Code Versus Function Points Versus Use Cases For Sizing

  • Software
  • April 30, 2021
  • Updated on: March 21, 2023
half-open laptop on a desk

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)

table with a column of software types

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.

Navigating Estimation Bias Across Software Development

In today’s software development landscape of ever-changing requirements and uncertainties, it can be difficult to manage projects, ensure each initiative is rooted in data-driven insights, and stay on track for success. However, it doesn’t have to be a time-consuming and demanding process….

img
Avatar for Galorath
Galorath From software to hardware, IT to space, Galorath's cost estimating software helps the most complex projects on the planet stay on budget and on schedule.

Every project is a journey, and with Galorath by your side, it’s a journey towards assured success. Our expertise becomes your asset, our insights your guiding light. Let’s collaborate to turn your project visions into remarkable realities.

BOOK A CONSULTATION