1.1 Cost, Schedule, and Quality

Though the need for high quality distinguishes industrial strength software from others, cost and schedule are other major driving forces for such software. In the industrial-strength software domain, there are three basic forces at play—cost, schedule, and quality. The software should be produced at reasonable cost, in a reasonable time, and should be of good quality. These three parameters often drive and define a software project.

Industrial-strength software is very expensive primarily due to the fact that software development is extremely labor-intensive. To get an idea of the costs involved, let us consider the current state of practice in the industry. Lines of code (LOC) or thousands of lines of code (KLOC) delivered is by far the most commonly used measure of software size in the industry. As the main cost of producing software is the manpower employed, the cost of developing software is generally measured in terms of person-months of effort spent in development. And productivity is frequently measured in the industry in terms of LOC (or KLOC) per person-month.

The productivity in the software industry for writing fresh code generally ranges from few hundred to about 1000+ LOC per person-month. This productivity is over the entire development cycle, not just the coding task. Software companies often charge the client for whom they are developing the software between $3000 - $15,000 per person-month. With a productivity of 1000 LOC per person-month, it means that each line of delivered code costs between $3 and $15! And even small projects can easily end up with software of 50,000 LOC. With this productivity, such a software project will cost between $150,000 and $750,000!

Schedule is another important factor in many projects. Business trends are dictating that the time to market of a product should be reduced; that is, the cycle time from concept to delivery should be small. For software this means that it needs to be developed faster, and within the specified time. Unfortunately, the history of software is full of cases where projects have been substantially late.

Clearly, therefore, reducing the cost and the cycle time for software development are central goals of software engineering. Productivity in terms of output (KLOC) per person-month can adequately capture both cost and schedule concerns. If productivity is higher, it should be clear that the cost in terms of person-months will be lower (the same work can now be done with fewer person-months). Similarly, if productivity is higher, the potential of developing the software in less time improves—a team of higher productivity will finish a job in less time than a same-size team with lower productivity. (The actual time the project will take, of course, depends also on the number of people allocated to the project.) Hence, pursuit of higher productivity is a basic driving force behind software engineering and a major reason for using the different tools and techniques.

Besides cost and schedule, the other major factor driving software engineering is quality. Today, quality is one of the main mantras, and business strategies are designed around it. Unfortunately, a large number of instances have occurred regarding the unreliability of software—the software often does not do what it is supposed to do or does something it is not supposed to do. Clearly, developing high-quality software is another fundamental goal of software engineering. However, while cost is generally well understood, the concept of quality in the context of software needs further elaboration. The international standard on software product quality [55] suggests that software quality comprises six main attributes, as shown in Figure 1.1.

 Figure 1.1: Software quality attributes.

These attributes can be defined as follows:

• Functionality. The capability to provide functions which meet stated and implied needs when the software is used.
• Reliability. The capability to provide failure-free service.
• Usability. The capability to be understood, learned, and used.
• Efficiency. The capability to provide appropriate performance relative to the amount of resources used.
• Maintainability. The capability to be modified for purposes of making corrections, improvements, or adaptation.
• Portability. The capability to be adapted for different specified environments without applying actions or means other than those provided for this purpose in the product.

With multiple dimensions to quality, different projects may emphasize different attributes, and a global single number for quality is not possible. However, despite the fact that there are many quality attributes, reliability is generally accepted to be the main quality criterion. As unreliability of software is due to the presence of defects in the software, one measure of quality is the number of defects in the delivered software per unit size (generally taken to be thousands of lines of code, or KLOC). With this as the major quality criterion, the quality objective is to reduce the number of defects per KLOC as much as possible. Current best practices in software engineering have been able to reduce the defect density to less than 1 defect per KLOC.

To determine the quality of a software product, we need to determine the number of defects in the software that was delivered. This number is clearly not known at delivery time and may never be known. One approach to measure quality is to log the defects found in 6 months (or 1 year) after delivery and define quality with respect to these defects. This means that quality of delivered software can only be determined 6 months after its delivery. The defect density can, however, also be estimated from past data of similar projects—if similar approaches are being used, then it is expected that the current project will have similar defect density as the past projects. It should be pointed out that to use this definition of quality, what a defect is must be clearly defined. A defect could be some problem in the software that causes the software to crash or a problem that causes an output to be not properly aligned or one that misspells some word, etc. The exact definition of what is considered a defect will clearly depend on the project or the standards the organization developing the project uses (typically it is the latter).

Besides reliability, another quality attribute of great interest is maintainability. Once the software is delivered and deployed, it enters the maintenance phase. Why is maintenance needed for software, when software has no physical components that can degrade with age? Software needs to be maintained because of the residual defects remaining in the system. It is commonly believed that the state of the art today is limited and developing software with zero defect density is not possible. These defects, once discovered, need to be removed, leading to what is called corrective maintenance. Maintenance is also needed to change the delivered software to satisfy the enhanced needs of the users and the environment, leading to adaptive maintenance. Over the life of a software system, maintenance cost can far exceed the cost of original development. The maintenance-to-development-cost ratio has been variously suggested as 80:20, 70:30, or 60:40. Due to this high cost, maintainability attribute of delivered software is of high interest—it is clearly desirable to have software systems that are easier to maintain.