5.3 Quality

Methods for benefit analysis are techniques to identify, measure, and quantify the benefits of software process improvement (SPI). Methods for benefit analysis are the cornerstone of SPI, SPI methods, and the return on investment (ROI) of SPI. Methods for benefit analysis are perhaps the most elusive , evasive, and least understood area in software engineering. Few know how to measure the benefits of software project management, software quality, and SPI. All other issues aside, methods for benefit analysis are the key enablers to understanding SPI and performing ROI of SPI. Methods for benefit analysis include measurement of productivity, defect density, quality, and defect removal efficiency. Measurements using the defect removal, software effort, and total life cycle cost models are also key methods for benefit analysis. This is by no means an exhaustive list of methods for benefit analysis. However, it is a virtual treasure trove of methods for benefit analysis that can fuel your SPI and ROI of SPI activities for years .

Productivity is a measure of how much and how fast software is produced. Defect density is a measure of the number of software defects. Quality is a measure of conformance to customer requirements. Defect removal efficiency is a measure of how effective your processes are at achieving software quality. The defect removal model is an estimate of how many defects escape your software process. It is also used to measure the effectiveness of your software processes. Software effort is a measure of how many hours it will take you to analyze, design, develop, and test your software. Total life cycle cost is an important method for estimating both software development and maintenance costs. The methods for benefit analysis build on one another and support the business case for SPI and ROI of SPI.

5.1 Productivity

Productivity is generally the amount of work that is performed. It is also the number of products and services created. Productivity is the rate, speed, or capacity of a software process. In this case, productivity is a measure of how fast and how many software products and services are rendered over a given period of time. The time period can be an hour, day, month, year, project length, or average for a software-producing enterprise. For example, a productivity of 25 lines of code per hour means that for every hour that is spent, 25 lines of code are produced.

Let's examine what a productivity of 25 lines of code per hour means. Does it mean that my programmers are pretty darn good? Does it mean that my programmers worked triple overtime for a few days, banging out code all night? Does it mean that productivity is a useless measure that tells me nothing about my process, operation, or firm? Does it mean that we should all begin looking for a few good super-programmers and fire anyone who can't keep up with them? The answer to these questions is a resounding "no." A productivity of 25 lines of code per hour is a simple ratio of total lines of code produced to the total number of project hours used. Figure 13 illustrates the formula for productivity.

Figure 13: Formula for Productivity

In other words, the software analysts may have spent 100 hours developing requirements, the architects may have spent 100 hours on design, the programmers may have spent 100 hours on coding, and the testers may have spent 100 hours on integration, for a total of 400 hours. However, the programmers produced 10,000 lines of code. The lines of code were eventually divided by the 400 hours spent by the analysts, architects, programmers, and testers: 10,000 lines of code divided by 400 software project hours is 25 lines of code per hour. In fact, the programmers could not have produced their code without the requirements, design, and evaluation by the analysts, architects , and testers. Therefore, 25 lines of code per hour is the productivity of everyone, not just the computer programmers. This is a common point of confusion within software engineering.

Productivity is just one of a few key measures which characterize the fields of software engineering, SPI, and ROI of SPI. Productivity cannot and should not be used in a vacuum , as a single-point, all-telling software measure. However, it should not be ignored. Productivity is a key measure for evaluating the benefits of SPI methods and thus the ROI of SPI. Productivity is a highly controversial measure for several reasons. First, many feel threatened by it, because they don't want to be hired , fired , or evaluated based on their individual productivity. It just sounds so cold and heartless to many people. Second, some people feel that there are better approaches to measuring software size , functionality, and complexity.

The bottom line on productivity is that it is a useful measure, it should be used responsibly, and it has many technical merits. However, you are free to choose your own measure of productivity other than the one presented here. Other highly relevant things to count include the number of software projects, number of releases, and number of documents. The number of requirements, number of design elements, and number of test cases may also be counted. The choices are limitless. Productivity is related to cost and cycle time. Increase productivity, and you reduce costs and cycle times. Reduce costs and cycle times, and you also reduce total life cycle costs. Productivity is more than just a measure of output. It is also related to cost efficiency, speed and cycle time, and total cost of ownership. Productivity is the source of vast benefits.