Discussions

News: Software metrics: Lines of Code vs Function Points

  1. An article on GotDotNet discusses two common metrics for measuring the complexity of an application: measuring the number of lines of code in the system, and a technique some developers may not have heard before, called "Function Point Analysis", where the goal is measure the complexity--not the code lines--of the system.

    From the paper, the following brief introduction to FPA appears:
    Function Point Analysis is an objective and structured technique to measure software size by quantifying its functionality provided to the user, based on the requirements and logical design. This technique breaks the system into smaller components so they can be better understood and analyzed. Function Point count can be applied to Development projects, Enhancement projects, and existing applications as well. There are 5 major components of Function Point Analysis which capture the functionality of the application. These are: External Inputs (EIs), External Outputs (EOs), External Inquiries (EQs), Internal Logical Files (ILFs) and External Interface Files (EIFs). First three are treated as Transactional Function Types and last two are called Data Function Types. Function Point Analysis consists of performing the following steps:
    • Determine the type of Function Point count
    • Determine the application boundary
    • Identify and rate transactional function types to calculate their contribution to the Unadjusted Function Point count (UFP)
    • Identify and rate the data function types to calculate their contribution to the UFP
    • Determine the Value Adjustment Factor (VAF) by using General System Characteristics (GSCs)
    • Finally, calculate the adjusted Function Point count
    Each of the components of Function Point Analysis is explained in brief [later in the paper].
    For those who've never heard of FPA before, it's a good lightweight introduction to the topic.

    Download the paper from Function Points or Lines of Code? – An Insight.

    Threaded Messages (19)

  2. We were using FPA back in '96. Didn't have much exposure to it before I left the company. It seemed to work Ok for COBOL programs. But so did our previous software metrics technique. And it was pretty easily understandable. I wonder if anyone has used it with OOD. It has been a while since I've even thought about it but at first glance, it is geared towards the older technology.
  3. some of the concepts of FPA are good[ Go to top ]

    As a previous poster mentioned, FPA is all about (client server) information systems.

    FPA breaks down on complex multi-tier systems because it doesn't take into account all of the quality attribute goals of a system:
    -performance
    -maintainability
    -robustness, etc

    In FPA, the first step is to count the compexity of the system via the requirements (UFP). You then multiply by a really simplistic system attribute number (VAF) to get your function point count.

    From memory the VAF adjustment is never large (from .9 to 1.1 or so) which means the quality attribute goals don't have a significant impact on the function point count - which is a real problem; according to FPA, a code heavy set of JSP pages doing sql directly to the database has almost the same count as a multi-tier implementation using struts, hibernate, session facades etc.

    One of the ideas is that over time you build up a productivity delivery rate (function points delivered per day) which can then be taken to market against other development companies. The Victorian goverment in Australia looked at selecting it's vendors via a competitive cost per function point bidding process. (Not sure how this went).

    My experience with FPA is that the "formal" FPA doesn't map well to J2EE development in its complex multi-tier state.

    _However_ some of the core concepts from FPA are extremely useful for evolving your own estimation method.

    Use cases if defined at the correct granularity are very similiar to FPA's atomic business units of functionality.

    Come up with a method of counting the complexity of a use case
    (data entities, screens or external interfaces, alternative flows)

    Use the use case complexity count to build up a functional complexity count for your requirements.

    Count up your projects/ timesheets (new/ existing) to get a delivery rate (per named developer if possible) for _very_ similiar projects (i.e. same layering/ tiering/ significant frameworks).

    Use this rate to estimate future projects.

    However, here is a few gotchas:
    -first and foremost, very detailed timesheeting is more important then anything else - GIGO. Timesheeting should be extremely detailed, showing _actual_ hours worked, use case worked on, and activity type (requirements/ test script writing/ detailed design/UCR/ development/ bug fix/ code review).

    -be very careful if applying blanket (role based) delivery rates; I always see cases where different developers have vastly different productiveness or i.e. ratios of 1:5 or even greater; having a good team is so important!

    -rapid delivery doesn't necessarily give total cost, often the surge ahead developers have a higher cost of rework after the code review/ testing cycles etc, which may be worn by another developer altogether if bug fixing is shared

    -It is very hard to spend too much time on preparing an estimate. Key concepts to successful estimation:
       +build a very detailed project history as you need some existing figures to work with
       +have the estimate done independantly by multiple estimators, and then reconcile the gap
       +not only use different people, use different methods (one person does a top down requirement count / complexity approach i.e. an FPA derivative, and the other person does a bottom up - details the tasks and components and estimate for each)

    Estimation is an extremely tricky area - it has smatterings of art as well as science because so many of the inputs and outputs are hard to measure.

    good luck :)
  4. some of the concepts of FPA are good[ Go to top ]

    totally agree. FPA is good especially for client systems with user interfaces. One of the ways to do the counting is by looking at the GUI screens and count the number of dropdown menu, input boxes, etc and apply points to them.

    If a backend system which does not interace with the user much and has very high complexity, then FPA does not reveal the complexity.

    cheers
    romen
  5. FPA debunked[ Go to top ]

    http://www.hacknot.info/hacknot/action/showEntry?eid=59
  6. Used my boss's own version of function points in my last two projects and found it to be a very effective way to estimate man-hours. A few of points I learned during the experience:

    - Must be combined with iterative development. Function points and therefore estimates became more precise with each iteration. We made sure the clients understood that our initial estimates were only initial estimates.

    - Composition of the team was considered (skill-level, morale, etc), not just complexity of the code.

    - Experience and insight of the estimator/s very important. The combined experiences and perspectives of my boss and myself allowed us to assign the right functional points and weights.
  7. Iterative Development[ Go to top ]

    Must be combined with iterative development. Function points and therefore estimates became more precise with each iteration. We made sure the clients understood that our initial estimates were only initial estimates.
    Now that is some statement. What it actually means is "Software metrics does not work". Now really. If I just put my finger in the air, my estimates will get better with any iteration, if I break down my project into any number of tasks, whatever the metric, my estimates get better with every iteration.

    Unfortunately, the estimates for producing piece of software are much more dependent on quality of requirements, feature creep, client communication, quality of development staff, availability of infrastructure, quality of products and product support than on function points. The latter may account for the largest chunk of development time but the former stuff will be the main constraint on _completion time_. And only completion time is relevant for the customer.
  8. Function points are certainly more effective than lines of code, especially with regards to the brevity of more dynamic languages.

    But the problem is that thay're not a general measure of code complexity. They work only for information systems, with a focus on inputs & outputs and files. It also is somewhat rough to translate its 1980's terminology of "files" into modern concepts of "classes" and "relations", though the international FP user's group has made attempts at standardizing these translations.

    I've used FP in combination with estimation models such as COCOMO II and come out wiht some reasonable "first guess" schedule estimates.

    Stu
  9. I've used (a non formal version) of FPA on most of the projects I have been involved with since 1992. It does work really well, as Calen said, with iterative development. It can even be used at a very early stage, as you are gathering high level requirements and estimating total project duration and cost.

    I used to determine all FPs then rate them on complexity on a scale of 1-4. Each complexity level was given a base development time between 1/2 and 4 days. The total development time is the sum of all FPs. Total project duration is this x3 (for design and test) or x4 (if detailed requirements are also required). Requirements, design, development and testing are done in parallel in an iRad form.

    The longest I ever overran a 6 month project was 2 weeks.

    Nice to see such an old technique make a reappearance.
  10. These normalilzing factors have been understood for years in the academic communitiy to be better than nothing, but ultimately not that great and far too simplistic to be useful. They are just too highly dependant on other factors which aren't taken into account and there's too many other metrics that measure complexity much more accurately.

    For instance, a one-line PERL program can be much harder to understand (and therefore more complex) than a 10 line one that does the same thing.

    OR, a program with a 4000 line function can be much more complex than an equivalent program that solves it in 300 lines using code re-use/structure programming.

    A better metric of complexity is McCabe's cyclomatic complexitiy metric.

    Even better metrics are those related to data flow. When and where data (i.e. variables) changes in a program is very clearly related to how easy it is to understand and how complicated it is. The more variables in scope at any given time, the more difficult it is to understand what's going on. And if the line you are looking at is 500 lines away from the last use of a given variable on that line, it is much harder to figure out what's going on then if that variable is declared on the previous line.
  11. These normalilzing factors have been understood for years in the academic communitiy to be better than nothing, but ultimately not that great and far too simplistic to be useful. They are just too highly dependant on other factors which aren't taken into account and there's too many other metrics that measure complexity much more accurately.For instance, a one-line PERL program can be much harder to understand (and therefore more complex) than a 10 line one that does the same thing.OR, a program with a 4000 line function can be much more complex than an equivalent program that solves it in 300 lines using code re-use/structure programming.A better metric of complexity is McCabe's cyclomatic complexitiy metric.Even better metrics are those related to data flow. When and where data (i.e. variables) changes in a program is very clearly related to how easy it is to understand and how complicated it is. The more variables in scope at any given time, the more difficult it is to understand what's going on. And if the line you are looking at is 500 lines away from the last use of a given variable on that line, it is much harder to figure out what's going on then if that variable is declared on the previous line.
    McCabe and other methods are useful to measure the complexity of existing software or at least existing designs. FPA can be used to ESTIMATE the complexity (and therefore cost to design, produce and/or maintain) a system prior to having a complete understanding of how it will be implemented.

    Of course, it is ONLY an ESTIMATE and all estimates are inaccurate to some degree. It beats just pull numbers out of your hat as it provides a methodical approach to considering the work in front of you. But in the end, there are enough variables to play with that your experience in the domain and with the technology to be used are critical to providing a close enough estimate.

    All tools can be misused and FPA lends itself to plenty of that. If you want to hit a certain date or cost figure, poor analysts or misguided managers can twist the numbers to produce any answer they want. But they'll do that anyway.
  12. A better way to estimate is to keep and use historical data. Without that, you can probably fare better by breaking your problem down into chunks that can be more reasonably estimated (which is, in a sense, what FPA does, though it tries to be generic about it).

    AS mentioned in the Hacknot article, FPA is fairly antiquated in some of the ways in which it quantifies things, plus it results in nebulous values that aren't really comparable to other values or representative of any real-world measurable thing (i.e. you cannot definitively measure the ACTUAL function points after you've implemented).

    If you follow the easy to use Painless Software Schedules method of project tracking (even for your own personal chunk of the work), you will begin to see which tasks you overestimated, and which under, and after a while, you can improve your estimates.

    As for estimated based on Lines of Code; that is a complete joke (though it is more quantifiable than function points!)
  13. As for estimated based on Lines of Code; that is a complete joke (though it is more quantifiable than function points!)
    How so?
  14. I think he's referring to the fact that you can count the # of lines of code after the project is done (or how many lines of code have been completed so far). This is very quantitative as opposed to FPA where you can't say exactly the number of FPs or how many have been done.
  15. I think he's referring to the fact that you can count the # of lines of code after the project is done (or how many lines of code have been completed so far). This is very quantitative as opposed to FPA where you can't say exactly the number of FPs or how many have been done.
    Ah yes. After the fact it is obviously more quantifiable. But beforehand, it is useless (IMHO).
  16. If you follow the easy to use Painless Software Schedules method of project tracking
    Here's a quote from that article that I absolutely love:
    If we hadn't done this, Excel 5 would have taken twice as long and included 50% useless crap features.
    I wish they'd shown this article to the guys who wrote the latest generation of Office. Maybe not so much Excel, but Word is without a doubt the world-champion "useless crap features" application.
  17. In Tom DeMarco's book "Why Does Software Cost So Much" there is a very good article called "Mad About Metrics", which explains some interesting real-life issues that arise with software metrics.
  18. Use case points[ Go to top ]

    Geri Schneider describes a similar technique based on use case points in Applying Use Cases: A Practical Guide, ISBN 0201309815.
  19. Use case points[ Go to top ]

    Geri Schneider describes a similar technique based on use case points in Applying Use Cases: A Practical Guide, ISBN 0201309815.
  20. Hi all the same things came to my mind i was reading comparison between use case points and function points from a free ebook located at http://www.geocities.com/shiv_koirala/fp/usecasepoints.html

    The same things are discussed in this book