Skip to main content
main-content

Über dieses Buch

Purpose The purpose of this book is to provide the reader with an understanding of the ISO 9000-3 guideline and how it applies to the specification, development, test, and maintenance of software. We will show that the basic practices and procedures that define software engineering and the ISO guideline are, for all intents and purposes, one and the same. We hope that the readers of this book will use the information found within not only to pass the certification audit but as a tool to be used to create the well-managed engineering environment needed to create reliable, well­ engineered products in a consistent manner. Audience This book is intended for senior software engineers, software managers, and non­ software managers within software organizations whose aim is to create an engi­ neering environment within their company or organization. In addition, individ­ uals outside the software organization who have responsibility for the specification of the software product and preparing their organization to take ownership of the developed product will find this book of great interest. Finally, those who must choose software companies to do business with or audit software companies to determine their ability to engineer and maintain a software product will find this book helpful. 2 Introduction Overview This book is made up of twenty-four chapters that can be grouped into four sections. Chapter 1 through Chapter 4 set the basis for the following chapters that deal directly with the guideline.

Inhaltsverzeichnis

Frontmatter

Introduction

Abstract
The purpose of this book is to provide the reader with an understanding of the ISO 9000-3 guideline and how it applies to the specification, development, test, and maintenance of software. We will show that the basic practices and procedures that define software engineering and the ISO guideline are, for all intents and purposes, one and the same. We hope that the readers of this book will use the information found within not only to pass the certification audit but as a tool to be used to create the well-managed engineering environment needed to create reliable, well-engineered products in a consistent manner.
Raymond Kehoe, Alka Jarvis

1. Introduction to ISO 9000

Abstract
The ISO standards were developed with the intent of creating a set of common standards for quality management and quality assurance. The standards can be applied to the manufacturing and service industries regardless of a company’s size or the complexity of the product or service. The standards were developed by the International Organization for Standardization in Geneva, Switzerland. This organization was established in 1946 and has chapters in Germany (DIN), the United States (ANSI), France (AFNOR), and the United Kingdom (BSI).
Raymond Kehoe, Alka Jarvis

2. Overview of Software Engineering

Abstract
This chapter is a high-level overview of software engineering and is meant to serve as an introduction for those who may not be familiar with, or only have a partial understanding of, software engineering. In addition, this overview can be useful to organizations that are trying to establish a common, organization-wide understanding of software engineering. Without such an understanding, many organizations will struggle to implement the engineering activities identified in the ISO 9000-3 guideline that, when all things are considered, are meant to aid in the development of reliable products in an expeditious manner.
Raymond Kehoe, Alka Jarvis

3. ISO 9000-3: Theory, Concept, Themes, Interpretation, and Critique

Abstract
To provide a deeper understanding of the guideline, we discuss the theories, concepts, and themes that form the guideline’s philosophical basis. We also present several criticisms of an otherwise excellent document, especially focusing on the sometimes inexact and widespread use of the term “quality.” Also, for the reader to have a better understanding of our interpretation of the guideline, we briefly discuss the manner in which we deal with the documentation required for the Quality Policy, Quality Manual, and Quality Plan that make up so much of the ISO 9000 literature.
Raymond Kehoe, Alka Jarvis

4. ISO 9000-3: Scope and Overview

Abstract
Many readers and users of the guideline will skip over this chapter or give it only superficial attention. This would be a mistake. This chapter discusses the guideline’s scope and provides an overview of the guideline. We strongly recommend that the reader go through this chapter several times in order to gain a high-level understanding of the guideline. Without this level of understanding the reader may become lost in the details of following chapters or confused by the repetitiveness sometimes exhibited by the guideline. Failure to “see the forest for the trees” will affect the reader’s understanding of how the management and engineering processes described in each section are meant to support the development and maintenance of a quality product.
Raymond Kehoe, Alka Jarvis

5. Supplier Management Responsibility

Abstract
Supplier management, at the organization level, has two basic responsibilities: (1) to ensure that the engineering environment is based on a defined engineering process, with engineers trained to work within that environment; (2) to ensure that the engineering process is being used and is effective in producing products that meet or exceed the product’s requirements (i.e., functionality, reliability, maintainability, testability, usability, and supportability).
Raymond Kehoe, Alka Jarvis

6. Purchaser Management Responsibility

Abstract
The guideline addresses one of the key problem areas of software development, that is, that purchaser management also has responsibilities in the development of a software product. Basically it should ensure that the requirements for the product are explicitly, accurately, and completely stated; communication with the supplier concerning questions and proposals are addressed by the right people and in a timely manner; and the purchaser organization fulfills its contractual agreements and is prepared to take ownership of the product through the acceptance tests of the product.
Raymond Kehoe, Alka Jarvis

7. The Supplier’s Quality System

Abstract
Supplier management must first identify the organization’s goals when developing a product and then ensure the existence of an engineering environment where these goals can be reached in the most efficient manner possible. This chapter identifies supplier management’s responsibility to ensure the existence of an engineering environment that has defined engineering processes and procedures; development and maintenance plans based on the defined process and procedures; reviews, audits, and tests to determine the quality of the product(s) being developed and effectiveness of the process used to develop those products; and corrective actions based on the information gained form reviews, audits, and tests.
Raymond Kehoe, Alka Jarvis

8. The Purchaser and Supplier Contract

Abstract
This is a very important stage. In the rush to get “on contract” and develop a sense of trust and good fellowship between the two organizations, many difficult issues are glossed over and procedures needed to deal with the problems that are sure to arise during the development effort are not defined. Basically, the lack of an engineering approach in dealing with business relationships at the very beginning of a project increases the likelihood of product budget, schedule, and quality issues. For the short-term feeling of “teamwork” and the warm feeling the effort is under way, both the purchaser and supplier have put the future at risk.
Raymond Kehoe, Alka Jarvis

9. Identify the Purchaser’s Requirements

Abstract
This chapter discusses the need to identify in detail the product’s functional, interface, and technical (e.g., performance, safety, reliability, testability, usability, etc.), requirements. Both the purchaser and supplier have a responsibility to ensure these requirements are complete and quantifiable before product development begins. The key to this effort is that the purchaser must take an active role in the identification of the requirements. Another key point is that both organizations must ensure that all requirements are reviewed and jointly agreed to and that approval authority of requirements and proposals is strictly limited to select individuals within both organizations.
Raymond Kehoe, Alka Jarvis

10. Development Planning

Abstract
Once a purchaser’s requirements have been identified there needs to be a development plan to deliver a product that meets those requirements. The development plan identifies the resources and schedule required to develop a product. The resources and schedule are based on a combination of the purchaser’s requirements, engineering practices and procedures used by the supplier to meet those requirements, historical data from previous projects, and the date the purchaser requires the product.
Raymond Kehoe, Alka Jarvis

11. Design and Implementation

Abstract
Design is the technical kernel of a software product and to a great degree dictates the quality of the product. The quality of a product’s design impacts the usability, testability, and the costs of maintaining and enhancing the product throughout its lifetime. The guideline suggests the design effort and the product itself would benefit from careful consideration of design methodologies, design rules and guidelines, internal design (not seen by the user), and a comparison of the product to designs used for previous products. Design and code reviews are an important part of the software engineering process. They should be planned and executed with the outcome of the reviews becoming part of the project documentation.
Raymond Kehoe, Alka Jarvis

12. Testing and Validation

Abstract
Testing is a complex engineering effort and must be well planned in order to be executed properly. In order to test a product the supplier must be able to identify the various levels of testing to be performed and the requirements for those levels of testing. This chapter focuses mainly on the supplier’s responsibilities for testing the product from the unit tests through system-level testing and on into field tests. Generally speaking, for each level of testing the supplier must identify the requirements being tested, test methods to be used, software and hardware resources required to execute the tests, and schedule and budget required to develop the test cases, identify the expected results, and actually run the tests.
Raymond Kehoe, Alka Jarvis

13. Purchaser Acceptance

Abstract
Acceptance testing is performed by the purchaser. The guideline points out the need for this to be a formal process planned well in advance of the actual testing. Both the supplier and the purchaser must agree on the validity of the acceptance test cases and the accuracy of the results of those test cases being executed.
Raymond Kehoe, Alka Jarvis

14. Software Maintenance

Abstract
The guideline points out that the product maintenance, or enhancement, has all the same aspects as product development. Analysis, design, implementation, and testing of changes to the product must all be planned, scheduled, and performed. An especially important issue that the guideline identifies is that the purchaser and the supplier must agree to the timing and content of product releases.
Raymond Kehoe, Alka Jarvis

15. Configuration Management

Abstract
Section 6 of the guideline is entitled: “Quality System—Supporting Activities (Not Phase Dependent).” The previous sections of the guideline have discussed the engineering activities required to develop and test a product. Section 6 discusses the engineering activities that support the development of the product. The following chapters address these activities starting with configuration management.
Raymond Kehoe, Alka Jarvis

16. Document Control

Abstract
Engineering is a specification-driven process. There are a number of different engineering documents used in the development and maintenance of a software product. The guideline identifies the need for an engineering organization to identify and control the use of those documents. Control is especially important for the initial approval and dissemination of such documents and the authorization and reissue of updated versions.
Raymond Kehoe, Alka Jarvis

17. Quality Records

Abstract
Engineering organizations should maintain records that document the quality of their processes and products. Records of changes to baselines, reviews, audits, and test results should be maintained. The guideline suggests that procedures and processes should be identified and implemented to control the accumulation, storage, and retrieval of such documents.
Raymond Kehoe, Alka Jarvis

18. Measurement, Rules, and Tools

Abstract
Engineering management should be a closed-loop process where measurements are taken to determine the quality of the products and processes used to create or manage those products. The guideline states that product measurement is based upon purchaser/customer feedback and a need to capture and use those measurements for product improvement. The guideline suggests that process measurement is used to determine whether schedule milestones are being met and whether the by-products of the process are meeting their quality goals. The guideline points out that for measurements to be useful, an organization needs to identify the current level of performance, improvement goals, measurement data to be collected, and actions to be taken based on measuring data against goals.
Raymond Kehoe, Alka Jarvis

19. Purchasing and Including Third-Party Products

Abstract
This chapter addresses the issues concerning the purchase and inclusion of thirdparty products into the supplier’s product. In this and the following section the guideline points out that, concerning subcontractors used by the supplier, the supplier should apply many of the same management and engineering techniques as the purchaser uses in relation to the supplier. For example, the supplier should ensure the subcontractor’s ability to perform the contracted work and validate the subcontractor’s products. Basically, concerning third-party products, the supplier has now become a purchaser in the sense that the supplier must now perform analysis of vendor engineering capabilities, validation of third-party products, and configuration control of included products.
Raymond Kehoe, Alka Jarvis

20. Training

Abstract
Engineers need to be trained in order to meet their responsibilities. An engineering organization must identify the techniques, tools, procedures, and methodologies that are used in the development and maintenance of a product. Once these have been identified, then a program can be instituted to ensure that engineers are proficient in their use.
Raymond Kehoe, Alka Jarvis

21. The Audit Process

Abstract
When a company makes the decision to apply for an ISO 9000 registration, it selects a certification body. The selection decision is based on the availability of the auditors, the location of the auditor company, the reputation of the auditors, and the total cost involved in an audit. The amount of time required for an audit will vary depending on the size of the company and the scope of the audit.
Raymond Kehoe, Alka Jarvis

22. Specifying the Purchaser Requirements

Abstract
There is a general recognition that regardless of the development model used, the software life cycle consists of specification, requirements definition, implementation, testing, and maintenance. Each of these phases is meant to address certain questions whose answers will provide the information needed for the next phase to begin. These questions are fairly simple to answer. The key is to make sure that the right questions are asked, of the right people, at the right time, and that the answers are reviewed by the right people.
Raymond Kehoe, Alka Jarvis

23. Configuration Management Process

Abstract
Software development is by its very nature a research and development effort. Consequently the products and by-products of this effort, especially the requirements, are subject to change. In addition software products are made up of a large number of interdependent components. Changes to these products, by-products, and components are, in many cases, made without updates to the project budget and schedule. This failure to update budgets and schedules is the single greatest cause for late, over-budget, unreliable, or incomplete products.
Raymond Kehoe, Alka Jarvis

24. The Software Process Handbook as the Quality Manual

Abstract
This chapter presents a generic software process handbook. We hope that such a document can form the basis for organizations to create their own handbook. We recommend that the handbook be short enough to be read in about an hour. We also recommend that roughly half of the handbook be given over to engineering specification document templates. A handbook that is too long and detailed may go unread, and one lacking templates will be difficult to implement.
Raymond Kehoe, Alka Jarvis

Backmatter

Weitere Informationen