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.
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.
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).
Table 2.1 Categories of Software Quality Costs
|Prevention cost||Quality basis definition||Effort to define quality, and to set quality goals, standards, and thresholds. Quality trade-off analysis||Definition of release criteria for acceptance testing and related quality standards|
|Project and process-oriented interventions||Effort to prevent poor product quality or improve process quality||Process improvement, updating of procedures and work instructions; metric collection and analysis; internal and external quality audits; training and certification of employees|
|Appraisal or evaluation cost||Discovery of the condition of the product||Discovery of the level of non-conformance||Test, walk-through, inspection, desk-check, quality assurance|
|Ensuring the achievement of quality||Quality control gating||Contract/proposal review, product quality audits, “go” or “no go” decisions to release or proceed, quality assurance of subcontractor|
|Cost of anomalies or non-conformance||Internal anomalies or non-conformance||Problem detected before delivery to the customer||Rework (e.g., recode, retest, re-review, re-document, etc.)|
|External anomalies or non-conformance||Problem detected after delivery to the customer||Warranty support, resolution of complaints, reimbursement damage paid to customer, domino effect (e.g., other projects are delayed), reduction of sales, damage to reputation of enterprise, increased marketing|
Source: Adapted from Krasner 1998 [KRA 98].
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). The1 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).
Table 2.2 Relationship Between the Process Maturity Characteristic and Rework [KRA 98]
|Process maturity||Rework (percent of total development effort)|
|Project controlled||25% – 50%|
|Defined organizational process||15% – 25%|
|Management by fact||5% – 15%|
|Continuous learning and improvement||≤5%|
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.
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).
Table 2.3 Cultural Principles in Software Engineering [WIE 96, p. 17]
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.
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.
Table 2.4 Summary Table of Dimensions Negotiated for an In-House Project [WIE 96, p. 32]
|Dimension||Driver||Constraint||Degree of freedom|
|Cost||20% overrun acceptable|
|Features||60–90% of priority 1 features must be in release 1.0|
|Quality||Release 1.0 can contain up to five known major defects|
|Schedule||Release 1.0 must be delivered within 4 months|
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.
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).
Table 2.5 The Eight Principles of the IEEE's Software Engineering Code of Ethics [IEE 99]
|1. The public||Software engineers shall act consistently with the public interest.|
|2. Client and Employer||Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.|
|3. Product||Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.|
|4. Judgment||Software engineers shall maintain integrity and independence in their professional judgment.|
|5. Management||Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.|
|6. Profession||Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.|
|7. Colleagues||Software engineers shall be fair to and supportive of their colleagues.|
|8. Self||Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.|
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.
The abridged version of the code states the main aspirations, whereas the articles in the complete version of the code provide examples and more information as to the manner in which these aspirations must be reflected in the behavior of the software engineer. Together, the abridged and complete versions of the code form a consistent whole. Indeed, without the statement of aspirations, the code risks seeming boring and full of legalese, and without any detailed development included, aspirations could seem abstract and devoid of meaning.
Software engineers who are professionally involved in carrying out analysis, specifications, design, development, tests, and maintenance must respect the principles outlined in the code of ethics.
In accordance with their commitment to the health, safety, and the public good, software engineers must adhere to eight principles presented in Table 2.5.
To use the code professionally, a simple usage procedure is proposed. It is important to understand that the practices are presented in a specific order: from most important to least important. Therefore, you must examine any conflict and go through the code one article at a time to see which article relates to the situation.
As soon as you identify an article in the code of ethics that represents the situation described, you should note that the article has been infringed. Then you should briefly explain why this situation violates the code. Continue in this way, going through all the articles one by one, since the situation may violate more than one article in the code.
Since the code of ethics of the Ordre des ingénieurs du Québec, an association of professional engineers, is quite similar to the code of ethics of the software engineer presented in this chapter, we will illustrate only one of the consequences that an engineer who does not respect this code of ethics may be subject to.
The following text box contains an example of a sanction incurred by an engineer.
Another possible consequence is the limitation of the right to practice for a given period, the obligation to undergo training, fines, and the obligation to redo the professional engineering certification.
The following form can be used for the software staff in an organization to demonstrate their commitment to the code of ethics.
Sometimes, in an organization, a person must make certain situations public. The whistle blower seriously thinks that the interest of the client or public is at stake, and denounces the situation either internally or externally. Internally, he may communicate with the ombudsman or security group, which represents upper management, whereas externally he can contact his professional order or a journalist. When the whistle blower denounces a situation internally, he may be subject to pressure or attacks from his superiors and colleagues. He might also be fired. This fear of reprisals is quite real. However, the engineer is protected; otherwise the practice of whistle blowing would not be encouraged. The professional tribunal ensures that the identity of the whistle blower is protected by law, if he so wishes. As well, there is an article in the code that stipulates the engineer being accused does not have to communicate with the complainant should he be told his name.
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.
- GOTTERBARN D. How the new software engineering code of ethics affects you, IEEE Software, vol. 16, issue 6, November/December 1999, pp. 58–64.
- LEVERSON N. G. and TURNER C. S. An investigation of the Therac-25 accidents, IEEE Computer, vol. 26, issue 7, July 1993, pp. 18–41.
- WIEGERS K. E. Standing on principles, The Journal of the Quality Assurance Institute, vol. 11, issue 3, July 1997, pp. 1–8.
Give arguments to convince management that it is necessary and profitable to invest in SQA.
In the most commonly used model today, the costs of quality consider five perspectives. Describe the quality cost formula and give some examples to illustrate each perspective.
What is the relationship between software quality and the total cost of detection and prevention according to observations made by researchers?
What are the benefits to identifying and eliminating defects early on in the software life cycle?
How can we use the results of the Raytheon study to convince management of the benefits of setting up SQA?
According to Weigers, what elements make up a healthy quality culture in an organization?
Name 5 of the 10 cultural principles of software engineering.
What are the five dimensions of a software project according to Wiegers?
Draw up the summary table of dimensions negotiated for the project described in Figure 2.10.
Apply the code of ethics and indicate the two main clauses that have been infringed in the following situations:
- Peter, a software engineer, developed software for his company. His company develops and sells inventory software. After months of work, he finds he is stuck regarding several parts of the software. His manager, not understanding the complexity of the problem, wants the work finished this week. Peter remembers that a colleague, Francine, had showed him modules from a commercial software package that she developed at another company. After studying this package, Peter directly incorporates some of these modules into his software. However, he did not tell Francine or his boss, and did not mention this in the software documentation. What clauses in the code did Peter violate?
- A company developed software to manage a nuclear power plant. The software was designed to manage the plant's reactor. While inspecting the code, Marie found major errors in the software. Frank, Marie's boss, said that the software must be delivered to the client this week. Marie knows that the errors will not be corrected in time. What clauses in the code require Marie to take action?
- In a company with approximately 10 people, you were named by the president to apply the code of ethics. You are head of the development and maintenance team. Describe the steps in your action plan to apply the code of ethics.
Name factors within an organization that make it easier to apply the code of ethics.
What clauses in the code of ethics require a software engineer to denounce a potentially dangerous situation?
What clause in the code of ethics clearly states that a software engineer must not have pirated software in his possession?
Read the CONFIRM case [OZ 94], which describes the development of a reservation system that became a money pit, and:
- Identify the clauses in the code that were infringed.
- What should the AMRIS directors have done differently?
- What could the AMRIS developers have done differently?
- How can a consumer know whether software will cause him irreparable damage before it is actually installed on his workstation?
- If the software causes major errors a few months after being installed, how could the consumer have protected himself?
Read the case of Therac-25 [LEV 93], a medical device that has caused the death of several patients, and:
- Identify the clauses in the code that were infringed.
- What could you have said to a representative of AECL who has made the usual excuses in the software industry in order to avoid responsibility (complexity, testability, and development process)? To back up your answer, explain in concrete terms what the company could have done to reduce the risks inherent in these three characteristics of the software product?
- You were recently named director of SQA for the new Therac-30 project. This project will reuse Therac-25 technology to produce a more efficient version. What SQA precautions should be taken?
- You talked with the Software Quality Director for the Therac-25. He shared the lessons learned from the incidents caused by Therac-25. List four of these lessons.
You have just purchased a new computer. The technician tells you that he installed demo software on your computer. When you start up your computer, you notice that commercial software was installed. What should you do?