6 Best Software Productivity Measurements You Need to Implement (and 3 Worst You Need to Avoid) in 2019


Software productivity measurement has eluded the software design and engineering industry, which happens to be the fastest growing industry in the world according to Investopedia.  However, the software industry also carries the notoriety of having the worst metrics of all.  In a recent article, Capers Jones, VP and CTO of Namcook Analytics, discussed the best and worst software metrics used in the industry

Software Product Measurement Foundation: Function Points

Function points were invented by IBM and placed in the public domain in the late 1970s.  Function points measure economic value of software by quantifying the business value of software.  Many new software productivity measurements have been introduced since, such as story points and use case points, but none of them truly capture software size, are technology agnostic, and can be standardized internationally.  

There are two main international standards for functions points:

Modern Software Productivity Measurement: The Pragmatic Guide
  1. International Function Points User Group (IFPUG)

  2. Object Management Group (OMG) - Automated Function Points

Because of these well established standards, function point-based benchmarks are abundant, allowing organizations to set targets internally and compare with the whole industry.

Top 6 Software Productivity Measurements

To deploy a successful software metrics program in your enterprise, you need to include the following metrics.

  1. Work Hours per Function Point
    Measures the amount of time needed to maintain or develop a new function point.  This productivity metric allows organizations to track the efficiency of their software productivity over time.  Benchmarks from organizations like Namcook Analytics and Gartner are also available.

  2. Defect Potentials Using Function Points
    The sum of defects likely to be found in requirements, architecture, design, source code, and documents.  Invented by IBM, defect potentials is a prediction of defects in the SDLC. This number should be adjusted based on actuals, but serves as a strong indication of development productivity.  

  3. Defect Removal Efficiency (DRE)
    The original IBM version of DRE measured internal defects found by developers and compared them to external defects found by clients in the first 90 days following release.  If developers found 90 bugs and clients reported 10 bugs, DRE is 90% (The Economics of Software Quality).  

  4. Delivered Defects per Function Point
    Delivered Defects per function point measures how many defects are in delivered software while standardizing over function points.  This is an important overarching software quality defect.  

  5. How Automated Function Point Counting Made Portfolio Sizing & Assessment Possible at Broadridge
  6. High-Severity Defects per Function Point
    Not all defects are created equal!  High-Severity defects are typically those that cause (or can cause) production incidents.  By measuring high-severity defects, organizations can track and predict work needed based on the type of release.

  7. Security Flaws per Function Point
    Security flaws are those that expose your software to potential exploitations, data breaches, and, worse, a PR disaster.  Tracking the level of security vulnerabilities over time and ensure that it reduces is an important activity in software quality assurance.

The 3 Worse Software Productivity Measurements

Don’t fall into the same trap as many organizations have.  Avoid relying heavily on the following metrics in your software metrics program.

  1. Cost per Defect
    There are several issues with the cost per defect metric.  First, cost per defects tends to always be the cheapest where more defects are found.  This phenomenon is because as software becomes bigger, variable costs tends to be shifted to the fixed cost bucket which reduces the cost of a single defect over time.  Further, because more bugs are found at the beginning of the SDLC than at the end, the increase in cost per defect at the end of the SDLC is artificial. Lastly, this metric ignores the savings of shorter development schedules and overall boost in productivity due to better quality.  Therefore, cost per defect understates the true value of quality.

  2. Any Metrics based on Lines of Code (LOC)
    Metrics based on LOC penalize high-level languages and give low-level languages an advantage.  LOC metrics ignore software complexity which are derived from architecture and design. Further, there are no standards for counting LOC metrics.  About half of all publications that use LOC metrics use physical LOC, and half use logical LOC. There can be up to 500% difference between counts of physical and logical LOC on the same piece of software.  

  3. Use Case Points
    Used by projects with designs based on “use cases” which often utilize IBM’s Rational Unified Process (RUP).  There are no standards for use cases. Use cases are ambiguous and vary by over 200% from company to company and project to project.  

What software productivity measurements are you using today? Talk to a software metrics expert at CAST to find out better ways to measure software with CAST Application Intelligence Platform (AIP), the only solution that offers OMG Standard Automated Function Points measurement.

  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
John Chang
John Chang
John Chang has helped Fortune 2000 companies leverage CAST’s solutions to reduce system-level defects and improve application development outcome success.
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item