Handbook

INTERNATIONAL STANDARD ISO/IEC 12207 SOFTWARE LIFE CYCLE PROCESSES
Raghu Singh Federal Aviation Administration Washington, DC, USA BACKGROUND In 1987 the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) established a Joint Technical Committee (JTC1) on Information Technology. The scope of the JTC1 is "Standardization in the field ofinformation technology systems (including microprocessor systems) and equipments." In June 1989, the JTC1 initiated the development of an International Standard, ISO/IEC 12207 [1], on software life cycle processes to fill a critical need. Since the "cottage" industry era of the late 1970's, software has been establishing itself as an integral part of many scientific and business disciplines. However,environments for developing and managing software have been proliferating for lack of a uniform framework for managing and engineering software. The International Standard fills that critical need by establishing a common framework that can be used by software practitioners to manage and engineer software. Besides, such a uniform framework would promote international trade in software productsand services. The International Standard was published August 1, 1995. The following countries participated in the development of the standard: Australia, Brazil, Canada, Czech Republic, Denmark, Finland, France, Germany, Ireland, Italy, Japan, Korea, The Netherlands, Spain, Sweden, the United Kingdom, and the United States of America. The standard is voluntary; that is, it does not in itself imposeany obligation upon anyone to follow it. Yet, it may be imposed by an organization through internal policy directive or by individual parties through contractual agreements. The standard is designed for use by one or more parties as the basis of an agreement or in a self-imposed way. BASIC CONCEPTS Software life cycle architecture. The standard establishes a top-level architecture of the lifecycle of software. The life cycle begins with an idea or a need that can be satisfied wholly or partly by software and ends with the retirement of the software. The architecture is built with a set of processes and interrelationships among these processes. The derivation of the processes is based upon two basic principles: modularity and responsibility. Modularity. The processes are modular; that is,they are maximally cohesive and minimally coupled to the practical extent feasible. An individual process is dedicated to a unique function. Responsibility. A process is considered to be the responsibility of a party in the software life cycle. In other words, each party has certain responsibilities. Responsibility is one of the key principles of total quality management, as discussed later.)This is in contrast to a "text book approach," where the life

1

cycle functions could be studied as topics or subjects, such as management, design, measurement, quality control, etc. The life cycle processes. The processes are grouped into three broad classes: primary; supporting; and organizational. See Figure 1 [2]. Primary processes are the prime movers in the life cycle; they areacquisition, supply, development, operation, and maintenance. Supporting processes are documentation, configuration management, quality assurance, joint review, audit, verification, validation, and problem resolution. A supporting process supports another process in performing a specialized function. Organizational processes are management, infrastructure, improvement, and training. An organization mayemploy an organizational process to establish, control, and improve a life cycle process.

MAINTENANCE OPERATION DEVELOPMENT SUPPLY ACQUISITION PRIMARY LIFE CYCLE SUPPORTING

DOCUMENTATION CONFIGURATION MANAGEMENT QUALITY ASSURANCE VERIFICATION VALIDATION JOINT REVIEW AUDIT PROBLEM RESOLUTION ORGANIZATIONAL MANAGEMENT INFRASTRUCTURE IMPROVEMENT TRAINING

Figure 1. The Life Cycle Processes...