After completing this chapter, you will be able to:

• – understand the cost of quality;
• – recognize the signs of a quality culture;
• – identify the compromises of the five dimensions of a software project;
• – know and follow the software engineer's code of ethics.

2.1 Introduction

In this chapter, we consider the concepts of the cost of quality, quality culture, and the code of ethics for software engineers. The issues related to quality will be applied to the context of software development. The principles set out in this book apply to those who develop, maintain, and work on information technology infrastructure, be it computer technicians, management computer specialists, or software and IT engineers. Typically, software engineers graduate from a school of engineering and are members of a professional order. We know that the term “software engineer” is currently used freely in both universities and the business world. Very few software engineers have obtained certified university degrees. For the engineer who is a member of a professional association, quality is part of the civil liabilities for the profession and must be managed prudently.

Non-quality in software has led to several catastrophes. In this chapter, we present examples where poor quality culture and the lack of a code of ethics have led to disastrous situations involving poor quality software and irreversible damage to people and the environment.

The following description is of the case of a Canadian medical device for treating cancer (Therac-25), which caused the death of several patients from massive irradiation. Similar incidents have occurred with devices developed by other companies throughout the world. We describe the Therac-25 case because it has been extensively studied and documented.

We believe that setting up a quality culture and software quality assurance (SQA) principles, as stipulated in the standards, could help solve these problems.

It is clear that quality, which is influenced by your organization's senior management and the organization's culture, has a cost, has a positive effect on profits, and must be governed by a code of ethics.

In the software industry, there are still too many quality problems that are becoming increasingly severe and with more consequences (consult the Incidents and Horror Stories Involving Software in the appendix at the end of this book). In the following text box, we describe the case of a defective medical device, the Therac-25, which injured and killed patients. Its software had many defects.

Readers are invited to read the 24-page article, available on the internet, written by Leveson and Turner (1993) [LEV 93], describing the six accidents involving massive overdoses to patients in more detail as well as a description of the investigations conducted to discover the multiple causes of the Therac-25 accidents.

2.2 Cost of Quality

One of the major factors that explains the resistance to implementing quality assurance is the perception of its high cost. In organizations that develop software, it is rare to find data on the cost of non-quality.

In this part of the book, we define the components of the cost of quality. Next, we discuss the cost of quality used in a major American company working in the military industry, and the data collected by Professor Claude Y. Laporte while working with different organizations. Lastly, we present a case study using data collected from a major transportation equipment manufacturer in Canada, Bombardier Transport.

Thinking in terms of costs helps attract the attention of administrators. This approach means better positioning of the software quality file and confronting the sometimes negative perceptions of company administrators, project managers, and often engineers from other disciplines (e.g., mechanical engineer). This approach is preferred to a technological discussion since the terminology of costs is common to almost all administrators, and a constant concern for management. Thus, SQA must strive to present the software quality improvement file in a way that is homogenous and consistent with the company's other investments, that is, as a business case for the organization. It is also a professional way to present an investment file.

As software engineers, you are responsible for informing administrators of the risks that a company takes when not fully committed to the quality of its software. A practical manner of beginning the exercise is to identify the costs of non-quality. It is easier to identify potential savings by studying the problems caused by software.

The costs of a project can be grouped into four categories: (1) implementation costs, (2) prevention costs, (3) appraisal costs, and (4) the costs associated with failures or anomalies.

If we are certain that all development activities are error free, then 100% of costs could be implementation costs. Given that we make mistakes, we need to be able to identify them. The costs of detecting errors are appraisal costs (e.g., testing).

Costs due to errors are anomaly costs. When we want to reduce the cost of anomalies, we invest in training, tools, and methodology. These are prevention costs.

The “cost of quality” is not calculated in the same way in all organizations. There is a certain amount of ambiguity between the notion of the cost of quality, the cost of non-quality, and the cost of obtaining quality. In fact, this is a non-issue, regardless of what it is called, it is important to clearly identify the different costs taken into account in our calculations. To do so, we can see how other companies have dealt with this.

In the most commonly used model at this time, costs of quality take into account the following five perspectives: (1) prevention costs, (2) appraisal costs, (3–4) failure costs (internal during development, external on the client's premises), and (5) costs associated with warranty claims and loss of reputation caused by non-quality.

The only difficulty with this model is clearly identifying the activities associated with each perspective and then tracking the actual costs for the company. We must not underestimate the complexity of this second step! The calculation of the cost of quality in this model is as follows:

• – Prevention costs: This is defined as the cost incurred by an organization to prevent the occurrence of errors in the various steps of the development or maintenance process. For example, the cost of training employees, the cost of maintenance to ensure a stable manufacturing process, and the cost of making improvements.
• – Appraisal costs: The cost of verifying or evaluating a product or service during the different steps in the development process. Monitoring system costs (their maintenance and management costs).
• – Internal failure costs: The cost resulting from anomalies before the product or service has been delivered to the client. Loss of earnings due to non-compliance (cost of making changes, waste, additional human activities, and the use of extra products).
• – External failure costs: The cost incurred by the company when the client discovers defects. Cost of late deliveries, cost of managing disputes with the client, logistical costs for storing the replacement product or for delivery of the product to the client.
• – Warranty claims and loss of reputation costs: Cost of warranty execution and damage caused to a corporate image as well as the cost of losing clients.

In addition to the costs listed above, an organization may suffer other repercussions following the development of a defective software such as lawsuits, penalties imposed by the court, a deterioration of the market value of their shares, the withdrawal of financial partners, and the departure of key employees.

Krasner [KRA 98] published a table to better understand the activities and costs for three quality perspectives (see Table 2.1).

Cost of quality models started appearing in the 1950s based on the work of Feigenbaum and colleagues. They proposed a method for classifying the costs associated with the quality assurance carried out on a product. They proposed an economic point of view and empirically studied the relationship of each perspective on total cost.

As illustrated in Figure 2.1, increased detection and prevention costs lead to reduced costs related to failures (internal or external) and vice versa: a drop in the costs of detection and prevention leads to an increase in the costs related to failures. As well, there is a relationship between the level of software quality and the total cost of detection and prevention. The discussion in the previous section on the different business fields enables us to see that software with high criticality will need a higher quality level than software with lower criticality, which will mean increased detection and prevention costs.

The first objective of the SQA is to convince management that there are proven benefits to SQA activities. To do this, he must be convinced of this himself. We all have been taught the following: “identifying an error early in the process can save a lot of time, money and effort.”

After years spent studying and measuring software practices, Capers Jones [JON 00] estimated the average costs of fixing defects in the software industry (see Figure 2.2). The¹ simulations show that it is profitable to identify and fix a defect as soon as possible. A defect that arises during the assembly phase will cost three times more to fix than one that is corrected during the previous phase (during which we should had been able to find it). It will cost seven times more to fix the defect in the next phase (test and integration), 50 times more in the trial phase, 130 times more in the integration phase, and 100 times more when it is a failure for the client, and has to be repaired during the operational phase of the product.

In fact, Boehm [BOE 01] also published that it would only cost $25, in 2001, to correct a problem identified in a requirements and specifications document. This cost increases to $139 if the problem is discovered during programming. The origin of software defects ended up being the subject of many studies. For example, Figure 2.3 presents the origin of the defects throughout the development life cycle of software in a case study published by Selby and Selby (2007) [SEL 07].

In this case study, we see that approximately 50% of defects occurred during the requirements phase. If these defects are not corrected early on, they will be very expensive to fix during the test and operational phases. As well, it is quite possible that correcting these defects will involve extending the delivery schedule, since all too often the effort involved in correcting the defects was not factored into the initial plan. If, however, the software must be delivered by a set date, it is quite possible that a large number of defects will not be corrected in order to meet the delivery date. Therefore, the client will have to use software containing a large number of defects while awaiting a new version.

In the defense industry, the American company Raytheon carried out a study on the cost of quality [DIO 92, HAL 96]. This study measured the cost of quality over a 9-year period. Figure 2.4 shows that, at the beginning of the study, the rework cost for this company was evaluated at approximately 41% of the total cost of the projects, at 18% when process maturity had been improved and 11% when the process maturity was at level 3, and then 6% when it was at level 4 maturity. The figure also describes that with prevention costs of less than 10% of the total cost of the projects, the rework costs were reduced from 45% to less than 10% of the total cost of the projects.

The study by Dion concluded that the cost of quality seems to be correlated with the implementation of increasingly mature processes. Another study on quality costs published by Krasner proposes that the rework costs vary between 15% and 25% of the development costs for a level 3 maturity organization (see Table 2.2).

We hope that this section, which discussed the concepts of the cost of quality, has convinced you of the importance of implementing improvements in software processes and quality assurance so as to better understand the cost categories to include in your estimates. It is indeed possible to produce quality software while minimizing rework costs (since rework costs are, if the organization has made the right choices, either losses or profits). The use of the cost of quality concept could affect the level of a company's competitiveness. We have shown that a company that invests in defect prevention can offer a product at a lower cost, with less risk of failures and can gradually make strides ahead of their competitors.

Defect prevention is an activity that has not always been popular with software developers. This activity is wrongly perceived as a waste of time and energy. The following section presents a model that evaluates the efficacy of the defect elimination activity and its associated costs. The objective is to convince you that adding a quality activity is worthwhile, and once you are convinced, you will then be able to convince your bosses.

2.3 Quality Culture

Tylor [TYL 10] defined human culture as “that complex whole which includes knowledge, belief, art, morals, law, custom, and any other capabilities and habits acquired by man as a member of society.” It is culture that guides the behaviors, activities, priorities, and decisions of an individual as well as of an organization.

Wiegers (1996) [WIE 96], in his book “Creating a Software Engineering Culture,” illustrates the interaction between the software engineering culture of an organization, its software engineers, and its projects (see Figure 2.5).

According to Wiegers, a healthy culture is made up of the following elements:

• – The personal commitment of each developer to create quality products by systematically applying effective software engineering practices.
• – The commitment to the organization by managers at all levels to provide an environment in which software quality is a fundamental factor of success and allows each developer to carry out this goal.
• – The commitment of all team members to constantly improve the processes they use and to always work on improving the products they create.

As software engineers, why should we be concerned with this aspect? First of all, quality culture cannot be bought. The organization's founders must develop it from the creation of the company. Then, when employees are selected and hired, the founders’ corporate culture will slowly begin to change, as illustrated in Figure 2.5. Quality culture cannot be an afterthought; it must be firmly integrated from the outset, and constantly consolidated. The objective of management is to instill a culture that will promote the development of high quality software products and offer them at competitive prices in order to produce income and dividends within an organization where employees are engaged and happy.

The second reason why a software engineer should be interested in the cultural aspects of quality is that effecting change within an organization does not boil down to placing an order with employees. The organization must work to change its culture with the help of change agents. We now know that one of the main stumbling blocks to change within an organization is the organization's culture.

Employees must feel involved and be able to see the benefits of any change. For example, if the change provides no benefit to a worker and has only been made to satisfy a manager's whim, the worker will not be interested in this change. The actions of the employee in our example will not foster the reinforcement of corporate culture and its degree of maturity will not be affected. It is imperative that cultural change is managed in order to obtain the desired results [LAP 98].

You may be asked to “cut corners” regarding the quality of your work or the way in which things are done (comic strip in Figure 2.6). Managers and clients may increase pressure and ask you to skip steps. In the most desperate situations, you may be asked to start programming even before having identified the needs. This old way of thinking about IT still prevails in some companies.

It is not always easy to resist pressure from people who are paying the bills or your salary. In certain cases, you will feel that you have no choice: do what you are being asked to do or leave (see the comic strips in Figures 2.7 and 2.8).

It may be difficult to imagine spending your career in this type of environment. When a quality culture is well established, employees will get involved even in times of crisis. It is for this reason that software developers and managers must adopt principles that motivate them to stick to their processes even during these difficult periods. Of course, we are always more flexible during a crisis, but not to the point of dropping all quality assurance activities and our good judgment.

In difficult situations, you must never let your boss, a colleague, or your client convince you do to bad work; proceed with integrity and intelligence with your boss and clients.

The client is not always right. Yes, you heard right! However, he probably has a valid point of view and you have a duty to listen to the client's concerns. Having said that, you are the person solely responsible for interpreting his needs and converting them into specifications and reasonable estimates of effort and duration. The highest added value of a business analyst in a project is to mitigate expectations and find a solution that will meet requirements and is realistic, feasible, and practical. Be aware of overly aggressive salespersons. One of my friends used to say “Nothing is impossible for those who do not have to do it.”

Be honest with your clients and make sure that you clearly communicate the limitations and scope of the work that will be done. Wiegers lists fourteen principles to follow to develop a culture that fosters quality (see Table 2.3).

The culture of an organization is a defining factor of successful efforts to improve processes. “Culture” includes a set of shared values and principles that guide behaviors, activities, priorities, and decisions of a group of people working in the same field. When colleagues share beliefs, it is easier to bring about changes to increase group efficiency as well as the chances of survival.

Quality involves an important social aspect in which the level of involvement and collaboration of each member in the company becomes essential. It is imperative to promote, and continuously support, beliefs and practices in terms of quality in order to preserve and enrich this critical aspect of corporate culture.

It is important to understand the context in which the organization is developing software in order to be able to understand why it is using a specific practice and not another [IBE 03]. Indeed, a company that develops and distributes software in a highly regulated sector is quite different from a company that develops its own applications for in-house operations. Moreover, other factors within these organizations may also be influencing practices, such as risk and project scope, mastering business rules, and laws for the sector. By analyzing the situation, the software engineer can better evaluate the changes that should be made to promote the development of a quality culture.

Quality culture must, above all, be expressed by the willingness to cultivate it emanating from the company's upper management and not only from the engineering team who, in a way, plays the role of quality police. In the most extreme cases where accidents occurred, corporate management very often seemed involved in choosing non-quality in order to maximize shareholder profits without having a long-term vision. The next section will provide tools for managing these situations.

2.4 The Five Dimensions of a Software Project

Wiegers developed an approach at Eastman Kodak in New York, in order to better frame project start-up discussions. He believed there are five dimensions that must be managed as part of a software project (see Figure 2.10). These dimensions are not independent. For example, if you add staff members to the project team, this may (but not always) shorten the deadline; however, this will increase costs. A common compromise is to shorten the deadlines by reducing features or reducing quality. Compromises that need to be made among these five dimensions are not easily made, but can be illustrated so as to have more realistic discussions and better document these decisions. For each project, you must have an idea of which dimensions have more constraints, and which are able to offset these constraints.

Three roles can be associated with each dimension: (1) a driver, (2) a constraint, and (3) a degree of freedom.

A driver is the specific and major reason for which the project must be carried out. For a product that has competition in the market and must offer new features that are expected by clients, the deadline is the main driver. For a project to update software, the driver could be a specific feature. Defining the project driver and associating it with one of the five dimensions allows us to focus on the status of each dimension.

A constraint is an external factor that is not under the control of the project manager. If you have a set number of resources, the “staff” dimension will be a constraint. Often cost will be a constraint for a project under contract. Quality is also a software constraint for medical devices or helicopters, for example.

Certain dimensions, such as features, may have roles as both drivers and constraints when a feature is non-negotiable. Any dimension that is not a driver or a constraint provides a certain degree of freedom. These dimensions can be adjusted to contribute to achieving an objective under a given constraint. The five dimensions cannot simultaneously be either all drivers or all constraints. Therefore, the priority of each dimension must be negotiated with the client right from the start of the project.

Here are two examples of how to use this negotiation model proposed by Wiegers. A Kiviat diagram with five dimensions allows us to illustrate the model using a graduated 10-point scale where 0 means total constraint and 10 means total freedom.

Figure 2.9 describes a project developed in-house with a set team size and a schedule with little leeway. The team is free to determine which features to implement and the quality level for the first version. Since the cost is linked for the most part to staff expenses, it will differ depending on the amount of resources used. Given the schedule allows for some leeway, deadlines may vary slightly.

Figure 2.10 describes the flexibility diagram for a critical software project in which quality is a constraint and the schedule has a high degree of freedom. The patterns shown in these diagrams provide an idea of the type of project you are dealing with. A project cannot focus all its dimensions at 0. There must be some latitude with certain levels to ensure some project success.

All too often in short discussions we tend to speak only of budget and schedules. It is this attitude that generally leads to overruns and chronic dissatisfaction in our industry. We therefore have to get our administrators and clients accustomed to the reality of not always having the features requested, without defects, delivered quickly by a small team at a low cost.

Table 2.4 can be drawn up to summarize the results of negotiation at the start of a project. For each dimension, the table describes the driver, the constraints, and the degree of freedom. The software engineer will attempt to describe the values given to each dimension. The example in Table 2.4 is related to the case in Figure 2.9.

A major characteristic of a quality culture and software engineering principles is that expectations and promises are established professionally and in a negotiated manner. Of course, this type of step may at first meet with resistance, but this approach will help you to avoid accepting projects that are not realistic or impossible to carry out in the conditions laid down. Therefore, you should get into the habit of taking a pass on these unrealistic projects and not committing to unavoidable disaster! You can also use other tools that are available to you to help make the right decisions. The next section presents the code of ethics that can be used to convince your clients and superiors of the importance of having a quality culture. Referring to a code of ethics can help the engineer better understand and communicate a quality culture.

2.5 The Software Engineering Code of Ethics

The first draft of the software engineering code of ethics was developed in cooperation with the Institute of Electrical and Electronics Engineers (IEEE) Computer Society and the Association for Computing Machinery (ACM) in 1996. Following this, the draft was widely circulated to elicit comments and suggestions for improvement. The IEEE and the ACM approved the current version in 1998 [GOT 99a; GOT 99b; IEE 99]).

Different perspectives clashed as the code of ethics was being developed. One such confrontation took place in regards to how to approach ethics. The first approach was based on the inherent virtuous nature of humans. This implies that we simply have to indicate the proper direction and people will follow it. Proponents of this approach wanted a code that inspires good behavior with few details. The other approach, based on rights and obligations, requires an outline of all rights and all obligations. The supporters of the latter approach wanted a very detailed code.

Another source of tension stemmed from conflicts in terms of what priority to give to the code's principles. For example, should we favor the employer or the public? This was resolved by indicating that the public good comes before loyalty to the employer or to the profession.

Some people would have preferred to list the standards to be used. It was decided not to list any and instead specify within the code that the currently accepted standards should be used.

On the other hand, everyone agreed that software engineers must be proactive when they become aware of potential problems within the system. Therefore, clauses were added to require engineers to communicate potentially dangerous situations, and to allow software engineers to denounce these types of situations.

To satisfy those who wanted a high-level code and those who wanted a more detailed code, two versions of the code were developed: an abridged version and a complete version.

The code has already been adopted by many organizations. For example, the code is a document that is part of an employee contract. The employee must sign it upon hiring. Over the years, the code became a de facto standard. In some cases, companies may decide not to do business with a company that does not adhere to this code.

The code describes eight commitments with which peers, the public, and legal organizations can measure the moral behavior of a software engineer (see Table 2.5).

Each commitment, called a principle here, is described in one sentence and supported by a certain number of clauses that include examples and details that help in its interpretation. Software engineers and software developers who adopt the code agree to respect the eight principles of quality and morality.

Following are some examples of the code of ethics: Principle 3 (product) declares that software engineers will ensure that their products and any related changes meet the highest possible professional standards. This principle is supported by 15 clauses. Clause 3.10 states that software engineers will carry out the tests, debugging and reviews of software and the related documents on which they are working.

The code has been translated into nine languages: German, Chinese, Croatian, English, French, Hebrew, Italian, Japanese, and Spanish. Many organizations have publically adopted the code of ethics and a few universities have included it as part of their software engineering study program. The complete version is found in Appendix 1.

2.6 Success Factors

In the following text box, several factors in relation to the culture of an organization which are likely to foster the development of quality software are listed.

In the following text box, some factors related to organizational culture which could adversely affect the development of quality software are listed.