ISO/IEC 12207:1995
(Main)Information technology — Software life cycle processes
Information technology — Software life cycle processes
Establishes a system for software life cycle processes with well-defined terminology. Contains processes, activities and tasks that are to be applied during the acquisition of a system that contains software, a stand-alone software product and software services.
Technologies de l'information — Processus du cycle de vie du logiciel
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD
12207
First edition
1995-08-01
Information technology - Software life
cycle processes
Technologies de /‘information - Processus du cycle de vie des logiciels
Reference number
ISO/l EC 12207: 1995(E)
---------------------- Page: 1 ----------------------
ISO/IEC 12207 : 1995 (E)
Contents
. . .
III
Foreword
iv
Introduction
1
1
Scope
2
2 Normative references
3
3 Definitions
6
4 Application of this International Standard
9
5 Primary life cycle processes
IO
5.1 Acquisition process
13
5.2 Supply process
16
5.3 Development process
23
5.4 Operation process
24
5.5 Maintenance process
27
6 Supporting life cycle processes
28
6.1 Documentation process
29
6.2 Configuration management process
31
6.3 Quality assurance process
33
6.4 Verification process
36
6.5 Validation process
38
6.6 Joint review process
40
6.7 Audit process
41
6.8 Problem resolution process
42
7 Organizational life cycle processes
43
7.1 Management process
45
7.2 Infrastructure process
46
7.3 Improvement process
47
7.4 Training process
Annexes
48
A - Tailoring process
49
B - Guidance on tailoring
53
C - Guidance on processes and organizations
57
D - Bibliography
0 ISO/IEC 1995
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
l Case Postale 56 l CH-1211 Geneve 20 l Switzerland
I SO/I EC Copyright Off ice
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
0 lSO/lEC ISO/IEC 12207 : 1995 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for
worldwide standardization. National bodies that are members of IS0 or
IEC participate in the development of International Standards through
technical committees established by the respective organization to deal
with particular fields of technical activity. IS0 and IEC technical com-
mittees collaborate in fields of mutual interest. Other international organ-
izations, governmental and non-governmental, in liaison with IS0 and IEC,
also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, lSO/IEC JTC 1. Draft International Standards adopted
by the joint technical committee are circulated to national bodies for vot-
ing. Publication as an International Standard requires approval by at least
75 % of the national bodies casting a vote.
International Standard lSO/IEC 12207 was prepared by Joint Technical
Committee lSO/IEC JTC 1, Information technology, Subcommittee SC 7,
Software engineering.
Annex A forms an integral part of this International Standard. Annexes B
and C are for information only.
---------------------- Page: 3 ----------------------
ISO/IEC 12207 : 1995 (E) 0 ISO/lEC
Software is an integral part of information technology and conventional systems, such as
transportation, military, medical care, and finance. There is a proliferation of standards, procedures,
methods, tools, and environments for developing and managing software. This proliferation has
created difficulties in software management and engineering, especially in integrating products and
services. The software discipline needs to migrate from this proliferation to a common framework that
can be used by software practitioners to “speak the same language’” to create and manage software.
This International Standard provides such a common framework.
The framework covers the life cycle of software from conceptualization of ideas through retirement and
consists of processes for acquiring and supplying software products and services. In addition, the
framework provides for controlling and improving these processes.
The processes in this International Standard form a comprehensive set. An organization, depending on
its purpose, can select an appropriate subset to fulfill that purpose. This International Standard is,
therefore, designed to be tailored for an individual organization, project, or application. It is also
designed to be used when software is a stand-alone entity, or an embedded or integral part of the total
system.
iv
---------------------- Page: 4 ----------------------
ISO/IEC 12207:1995(E)
INTERNATIONAL STANDARD 0 lSO/IEC
Information technology - Software life cycle processes
1 Scope
1.1 Purpose
This International Standard establishes a common framework for software life cycle processes, with
well-defined terminology, that can be referenced by the software industry. It contains processes,
activities, and tasks that are to be applied during the acquisition of a system that contains software, a
stand-alone software product, and software service and during the supply, development, operation,
and maintenance of software products. Software includes the software portion of firmware.
This International Standard also provides a process that can be employed for defining, controlling, and
improving software life cycle processes.
1.2 Field of application
This International Standard applies to the acquisition of systems and software products and services, to
and maintenance of software products, and to the software
the supply, development, operation,
portion of firmware, whether performed internally or externally to an organization. Those aspects of
system definition needed to provide the context for software products and services are included.
NOTE - The processes used during the software life cycle need to be compatible with the processes used during
the system life cycle.
This International Standard is intended for use in a two-party situation and may be equally applied
where the two parties are from the same organization. The situation may range from an informal
agreement up to a legally binding contract. This International Standard may be used by a single party
as self-imposed tasks.
This International Standard is not intended for off-the-shelf software products unless incorporated into
a deliverable product.
This International Standard is written for acquirers of systems and software products and services and
for suppliers, developers, operators, maintainers, managers, quality assurance managers, and users of
software products.
1.3 Tailoring of this International Standard
This International Standard contains a set of processes, activities, and tasks designed to be tailored in
respect of software projects. The tailoring process is deletion of non-applicable processes, activities,
and tasks.
NOTE -Addition of unique or special processes, activities, and tasks may be provided in the contract.
---------------------- Page: 5 ----------------------
0 lSO/lEC
ISO/lEC 12207 : 1995 (E)
1.4 Compliance
Compliance with this International Standard is defined as the performance of all the processes,
activities, and tasks selected from this International Standard in the Tailoring Process (annex A) for the
software project. The performance of a process or an activity is complete when all its required tasks
are performed in accordance with the pre-established criteria and the requirements specified in the
contract as applicable.
Any organization (for example, national, industrial association, company) imposing this International
Standard, as a condition of trade, is responsible for specifying and making public the minimum set of
required processes, activities, and tasks, which constitute suppliers’ compliance with this International
Standard.
1.5 Limitations
This International Standard describes the architecture of the software life cycle processes but does not
specify the details of how to implement or perform the activities and tasks included in the processes.
This International Standard is not intended to prescribe the name, format, or explicit content of the
documentation to be produced. This International Standard may require development of documents
of similar class or type; various plans are an example. This International Standard, however, does not
imply that such documents be developed or packaged separately or combined in some fashion. These
decisions are left to the user of this International Standard.
This International Standard does not prescribe a specific life cycle model or software development
method. The parties of this International Standard are responsible for selecting a life cycle model for
the software project and mapping the processes, activities, and tasks in this International Standard onto
that model. The parties are also responsible for selecting and applying the software development
methods and for performing the activities and tasks suitable for the software project.
This International Standard is not intended to be in conflict with any organization’s policies, standards
or procedures that are already in place. However, any conflict needs to be resolved and any overriding
conditions and situations need to be cited in writing as exceptions to the application of this
International Standard.
Throughout this International Standard, “shall” is used to express a provision that is binding between
two or more parties, “will” to express a declaration of purpose or intent by one party, “should” to
express a recommendation among other possibilities, and “may” to indicate a course of action
permissible within the limits of this International Standard.
In this International Standard, there are a number of lists for tasks; none of these is presumed to be
-- they are intended as examples.
exhaustive
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions
of this International Standard. At the time of publication, the editions indicated were valid. All
standards are subject to revision, and parties to agreements based on this International Standard are
encouraged to investigate the possibility of applying the most recent editions of the standards
indicated below. Members of IEC and IS0 maintain registers of currently valid International Standards.
ISO/AFNOR: 1989, Dictionary of computer science.
lSO/lEC 2382-l : 1993, Information technology - Vocabulary - Part I: Fundamental terms.
lSO/lEC 2382-20: 1990, Information technology - Vocabulary - Part 20: System development
IS0 8402: 1994, Quality management and quality assurance - Vocabulary.
2
---------------------- Page: 6 ----------------------
ISO/IEC 12207 : 1995 (E)
0 lSO/lEC
Model for quality assurance in design, development, production,
IS0 9001: 1994, Quality systems -
installation and servicing.
- Quality characteristics and
lSO/lEC 9126: 1991, Information technology - Software product evaluation
guidelines for their use.
3 Definitions
For the purposes of this International Standard, the definitions given in IS0 8402, lSO/IEC 2382-l and
lSO/lEC 2382-20 apply, together with the following definitions.
NOTE -A product may be interpreted as a part of a system as applicable.
3.1 Acquirer: An organization that acquires or procures a system, software product or software service
from a supplier.
NOTE -The acquirer could be one of the following: buyer, customer, owner, user, purchaser.
3.2 Acquisition: The process of obtaining a system, software product or software service.
The definition of terms and conditions under which a working relationship will be
3.3 Agreement:
conducted.
3.4 Audit: Conducted by an authorized person for the purpose of providing an independent
assessment of software products and processes in order to assess compliance with requirements.
3.5 Baseline: A formally approved version of a configuration item, regardless of media, formally
designated and fixed at a specific time during the configuration item’s life cycle.
3.6 Configuration item: An entity within a configuration that satisfies an end use function and that can
be uniquely identified at a given reference point.
3.7 Contract: A binding agreement between two parties, especially enforceable by law, or a similar
internal agreement wholly within an organization, for the supply of software service or for the supply,
development, production, operation, or maintenance of a software product.
3.8 Developer: An organization that performs development activities (including requirements analysis,
design, testing through acceptance) during the software life cycle process.
3.9 Evaluation: A systematic determination of the extent to which an entity meets its specified criteria.
3.10 Firmware: The combination of a hardware device and computer instructions or computer data
that reside as read-only software on the hardware device. The software cannot be readily modified
under program control.
3.11 Life cycle model: A framework containing the processes, activities, and tasks involved in the
development, operation, and maintenance of a software product, spanning the life of the system from
the definition of its requirements to the termination of its use.
3.12 Maintainer: An organization that performs maintenance activities,
3.13 Monitoring: An examination of the status of the activities of a supplier and of their results by the
acquirer or a third party.
3.14 Non-deliverable item: Hardware or software product that is not required to be delivered under the
contract but may be employed in the development of a software product.
---------------------- Page: 7 ----------------------
ISO/lEC 12207 : 1995 (E) 0 lSO/lEC
3.15 Off-the-shelf product: Product that is already developed and available, usable either “as is” or
with modification.
3.16 Operator: An organization that operates the system.
3.17 Process: A set of interrelated activities, which transform inputs into outputs.
NOTE -The term “activities” covers use of resources. [See IS0 8402: 1994, ‘I .2.]
3.18 Qualification: The process of demonstrating whether an entity is capable of fulfilling specified
requirements. [See IS0 8402: 1994, 2.13.1
3.19 Qualification requirement: A set of criteria or conditions that have to be met in order to qualify a
software product as complying with its specifications and being ready for use in its target environment.
Testing, conducted by the developer and witnessed by the acquirer (as
3.20 Qualification testing:
appropriate), to demonstrate that a software product meets its specifications and is ready for use in its
target environment.
3.21 Quality assurance: All the planned and systematic activities implemented within the quality
system, and demonstrated as needed, to provide adequate confidence that an entity will fulfil
requirements for quality.
NOTES
I purposes for quality assurance:
1 There are both internal and externa
organization, quality assurance provides confidence to
a) Internal quality assurance within an
management;
b) External quality assurance: in contractual situations, quality assurance provides confidence to the
customer or others.
2 Some quality control and quality assurance actions are interrelated.
3 Unless requirements for quality fully reflect the needs of the user, quality assurance may not provide adequate
confidence.
[ IS0 8402: 1994,3.5]
3.22 Release: A particular version of a configuration item that is made available for a specific purpose
(for example, test release).
means to announce its
3.23 Request for proposal [tender]: A document used by the acquirer as the
intention to potential bidders to acquire a specified system, software product or software service.
3.24 Retirement: Withdrawal of active support by the operation and maintenance organization, partial
or total replacement by a new system, or installation of an upgraded system.
3.25 Security: The protection of information and data so that unauthorized persons or systems cannot
read or modify them and authorized persons or systems are not denied access to them.
3.26 Software product: The set of computer programs, procedures, and possibly associated
documentation and data.
with
3.27 Software service: Performance of activities, work, or duties connected a software product,
such as its development, maintenance, and operation.
3.28 Software unit: A separately compilable piece of code.
---------------------- Page: 8 ----------------------
ISO/IEC 12207 : 1995 (E)
0 lSO/lEC
3.29 Statement of work: A document used by the acquirer as the means to describe and specify the
tasks to be performed under the contract.
3.30 Supplier: An organization that enters into a contract with the acquirer for the supply of a system,
software product or software service under the terms of the contract.
NOTES
1 The term “supplier” is synonymous with contractor, producer, seller, or vendor.
2 The acquirer may designate a part of its organization as supplier.
An integrated composite that consists of one or more of the processes, hardware,
3.31 System:
software, facilities and people, that provides a capability to satisfy a stated need or objective.
3.32 Test coverage: The extent to which the test cases test the requirements for the system or software
product.
3.33 Testability: The extent to which an objective and feasible test can be designed to determine
whether a requirement is met.
3.34 User: An individual or organization that uses the operational system to perform a specific
function.
NOTE -The user may perform other roles, such as acquirer, developer, or maintainer.
3.35 Validation: Confirmation by examination and provision of objective evidence that the particular
requirements for a specific intended use are fulfilled.
NOTES
process of
1 In design and development, validation concerns the examining a product to determine conformity
with user ne eds.
2 Validation is normally performed on the final product under defined operating conditions. It may be necessary
in earlier stages.
3 “Validated” is used to designate the corresponding status.
4 Multiple validations may be carried out if there are different intended uses.
[ IS0 8402: 1994, 2.181
by examination and provision of objective evidence
3.36 Verification: Confirmation that specified
requirements have been fulfilled.
NOTES
1 In d esign and development, ver ,ification concern ,s the process of examining the result of a given activity to
deter *m ine confor ,mity with the state d requirement fo r that activity.
2 “Verified” is used to designate the corresponding status.
[ISO 8402: 1994, 2.171
3.37 Version: An identified instance of an item.
NOTE - Modification to a version of a software product, resulting in a new version, requires configuration
management action.
---------------------- Page: 9 ----------------------
0 lSO/lEC
ISO/IEC 12207 : 1995 (E)
4 Application of this International Standard
This clause presents the software life cycle processes that can be employed to acquire, supply, develop,
operate, and maintain software products. The objective is to provide a road map for the users of this
International Standard so that they can orient themselves in it and apply it judiciously.
4.1 Organization of this International Standard
4.1.1 Life cycle processes
This International Standard groups the activities that may be performed during the life cycle of
software into five primary processes, eight supporting processes, and four organizational processes.
Each life cycle process is divided into a set of activities; each activity is further divided into a set of
tasks. Subclause numbering a.b denotes a process, a.b.c an activity, and a.b.c.d a task. These life cycle
processes are introduced below and depicted in figure 1.
4.1.1.1 Primary life cycle processes
The primary life cycle processes (clause 5) consist of five processes that serve primary parties during
the life cycle of software. A primary party is one that initiates or performs the development, operation,
or maintenance of software products. These primary parties are the acquirer, the supplier, the
developer, the operator, and the maintainer of software products. The primary processes are:
1) Acquisition process (subclause 5.1). Defines the activities of the acquirer, the organization that
acquires a system, software product or software service.
Defines the activities of the supplier, the organization that
2) Supply process (subclause 5.2).
provides the system, software product or software service to the acquirer.
Development process (subclause 5.3). Defines the activities of the developer, the organization
that defines and develops the software product.
Operafion process (subclause 5.4). Defines the activities of the operator, the organization that
provides the service of operating a computer system in its live environment for its users.
Minfenance process (subclause 5.5). Defines the activities of the maintainer, the organization
that provides the service of maintaining the software product; that is, managing modifications
to the software product to keep it current and in operational fitness. This process includes the
migration and retirement of the software product.
4.1.1.2 Supporting life cycle processes
The supporting life cycle processes (clause 6) consist of eight processes. A supporting process
supports another process as an integral part with a distinct purpose and contributes to the success and
quality of the software project. A supporting process is employed and executed, as needed, by another
process. The supporting processes are:
Defines the activities for recording the information
I) Documentation process (subclause 6.1).
produced by a life cycle process.
2) Configuration management process (subclause 6.2). Defines the configuration management
activities.
3) Quality assurance process (subclause 6.3). Defines the activities for objectively assuring that
the software products and processes are in conformance with their specified requirements and
adhere to their established plans. Joint Reviews, Audits, Verification, and Validation may be
used as techniques of Quality Assurance.
---------------------- Page: 10 ----------------------
ISO/IEC 12207 : 1995 (El
0 lSO/IEC
5, PRIMARY 6. SUPPORTING
LIFE CYCLE PROCESSES LIFE CYCLE PROCESSES
6.1 Documentation
5.1 Acquisition
6.2 Configuration
Management
5.2 Supply
-
.......................................... . . .
.......................................... . . .
.......................................... . . .
. . .
. . . . .
. . .
. .
. . . . .
. . . . .
11 6.3 Quality
. . . . .
. . . . .
. . .
. .
. . .
Assurance
. . .
. . . . .
1 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
Operation
6.4 Verification
I
c
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L 1
. . .
. . .
. . .
53 a I! I( 6.5 Validation
. . . . . .
. . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Development
. . .
. . .
. . .
. . .
6.6 Joint Review ii:
. . . . . .
L I
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
55 m
6.7 Audit
..........................................
..........................................
Maintenance
..........................................
..........................................
..........................................
6.8 Problem Resolution
7. OR.GANlZATlONAL LIFE CYCLE PROCESSES
c
7.2 Infrastructure
7.1 Management
7.4 Training
7.3 Improvement
Figure 1. Structure of the International Standard
---------------------- Page: 11 ----------------------
ISO/lEC 12207 : 1995 (E) 0 lSO/lEC
Verification process (subclause 6.4). Defines the activities (for the acquirer, the supplier, or an
4)
independent party) for verifying the software products in varying depth depending on the
software project.
Validation process (subclause 6.5). Defines the activities (for the acquirer, the supplier, or an
5)
independent party) for validating the software products of the software project.
Joint review process (subclause 6.6). Defines the activities for evaluating the status and
products of an activity. This process may be employed by any two parties, where one party
(reviewing party) reviews another party (reviewed party) in a joint forum.
Audit process (subclause 6.7). Defines the activities for determining compliance with the
requirements, plans and contract. This process may be employed by any two parties, where
one party (auditing party) audits the software products or activities of another party (audited
pa fty).
8) Problem resolution process (subclause 6.8). Defines a process for analyzing and removing the
problems (including non-conformances), whatever their nature or source, that are discovered
during the execution of development, operation, maintenance, or other processes.
4.1.1.3 Organizational life cycle processes
The organizational life cycle processes (clause 7) consist of four processes. They are employed by an
organization to establish and implement an underlying structure made up of associated life cycle
processes and personnel and continuously improve the structure and processes. They are typically
employed outside the realm of specific projects and contracts; however, lessons from such projects and
The organizational processes are:
contracts contribute to the improvement of the organization.
I) Management process (subclause 7.1). Defines the basic activities of the management,
including project management, during a life cycle process.
2) Infrastructure process (subclause 7.2). Defines the basic activities for establishing the
underlying structure of a life cycle process.
3) improvement process (subclause 7.3). Defines the basic activities that an organization (that is,
supplier, developer, operator, maintainer, or the manager of another process)
acquirer,
performs for establishing, measuring, controlling, and improving its life cycle process.
4) Training process (subclause 7.4). Defines the activities for providing adequately trained
personnel.
4.1.2 Tailoring process. Annex A, which is normative, defines the basic activities needed to perform
Annex B contains a brief guidance on tailoring the
tailoring of this International Standard.
requirements of this International Standard; it lists the key factors upon which tailoring decisions may
be made.
4.1.3 Relationship between the processes and organizations
This International Standard contains various processes that are applied throughout the life cycle of
software by various organizations depending on their needs and goals. For understandability, annex C
presents the relationships between the life cycle processes and related parties.
8
---------------------- Page: 12 ----------------------
ISO/IEC 12207 : 1995 (EI
0 lSO/lEC
5 Primary life cycle processes
This clause defines the following primary life cycle processes:
1) Acquisition process;
2) Supply process;
3) Development process;
4) Operation process;
5) Maintenance process.
The activities and tasks in a primary process are the responsibility of the organization initiating and
performing that process. This organization ensures that the process is in existence and functional.
---------------------- Page: 13 ----------------------
0 lSO/lEC
ISO/IEC 12207 : 1995 (E)
5.1 Acquisition process
The Acquisition Process contains the activities and tasks of the acquirer. The process begins with the
definition of the need to acquire a system, software product or software service. The process continues
with the preparation and issue of a request for proposal, selection of a supplier, and management of
the acquisition process through to the acceptance of the system, software product or software service.
The owner may contract any or
The individual organization having the need may be called the owner.
all of the acquisition activities to an agent who will in turn conduct these activities according to the
Acquisition Process. The acquirer in this subclause may be the owner or the agent.
The acquirer manages the Acquisition Process at the project level following the Management Process
(7.1), which is instantiated in this process; establishes an infrastructure under the process following the
Infrastructure Process (7.2); tailors the process for the project following the Tailoring Process (annex A);
and manages the process at the organizational level following the Improvement Process (7.3) and the
Training Process (7.4).
. . . .
1st of actrvrtres: This process consists of the following activities:
1) Initiation;
2) Request-for-Proposal [-tender] preparation;
3)
Contract preparation and update;
4) Supplier monitoring;
5) Acceptance and completion.
5.1.1 Initiation. This activity consists of the following tasks:
a concept or a need to
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.