ISO/IEC 12207:1995

INTERNATIONAL ISO/IEC
STANDARD
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)
ISO/IEC 12207 : 1995 (E)
Contents
. . .
III
Foreword
iv
Introduction
Scope
2 Normative references
3 Definitions
4 Application of this International Standard
5 Primary life cycle processes
IO
5.1 Acquisition process
5.2 Supply process
5.3 Development process
5.4 Operation process
5.5 Maintenance process
6 Supporting life cycle processes
6.1 Documentation process
6.2 Configuration management process
6.3 Quality assurance process
6.4 Verification process
6.5 Validation process
6.6 Joint review process
6.7 Audit process
6.8 Problem resolution process
7 Organizational life cycle processes
7.1 Management process
7.2 Infrastructure process
7.3 Improvement process
7.4 Training process
Annexes
A - Tailoring process
B - Guidance on tailoring
C - Guidance on processes and organizations
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
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.

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
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.

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.
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.

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.

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.
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.

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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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

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.
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.

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 acquire,
5.1.1.1 The acquirer begins the acquisition process by describing
develop, or enhance a system, software product or software service.
The system requirements should
5.1.1.2 The acquirer will define and analyze the system requirements.
include business, organizational and user as well as safety, security, and other criticality requirements
along with related design, testing, and compliance standards and procedures.
5.1.1.3 If the acquirer retains a supplier to perform system requirements analysis, the acquirer will
approve the analyzed requirements.
5.1.1.4 The acquirer may perform the definition and analysis of software requirements by itself or may
retain a supplier to perform this task.
5.1.1.5 The Development Process (5.3) should be used to perform the tasks in 5.1.1.2 and 5.1.1.4.
5.1.1.6 The acquirer will consider options for acquisition against analysis of appropriate criteria to
include risk, cost and benefits for each option. Options include:
a) Purchase an off-the-shelf software product that satisfies the requirements.
b) Develop the software product or obtain the software service internally.
c) Develop the software product or obtain the software service through contract.
d) A combination of a, b, and c above.
e) Enhance an existing software product or service.
5.1.1.7 When an off-the-shelf software product is to be acquired, the acquirer will ensure the following
conditions are satisfied:
a) The requirements for the software product are satisfied.
b) The documentation is available.
c) Proprietary, usage, ownership, warranty and licensing rights are satisfied.
d) Future support for the software product is planned.

ISO/IEC 12207 : 1995 (E)
0 lSO/IEC
5.1.1.8 The acquirer should prepare, document and execute an acquisition plan. The plan should
contain the following:
a) Requirements for the system;
b) Planned employment of the system;
c) Type of contract to be employed;
d) Responsibilities of the organizations involved;
e) Support concept to be used;
f) Risks considered as well as methods to manage the risks.
5.1.1.9 The acquirer should define and document the acceptance strategy and conditions (criteria).
5.1.2 Request-for-proposal [-tender] preparation. This activity consists of the following tasks:
5.1.2.1 The acquirer should document the acquisition requirements (e.g., request for proposal), the
The acquisition
content of which depends upon the acquisition option selected in 5.1.1.6.
documentation should include, as appropriate:
a) System requirements;
b) Scope statement;
c) Instructions for bidders;
d) List of software products;
e) Terms and conditions;
f) Control of subcontracts;
g) Technical constraints (e.g., target environment).
5.1.2.2 The acquirer should determine which processes, activities, and tasks of this International
Standard are appropriate for the project and should tailor them accordingly. Especially, the acquirer
should specify the applicable supporting processes (clause 6) and their performing organizations,
including responsibilities (if other than supplier), so that the suppliers may, in their proposals, define
the approach to each of the specified supporting processes. The acquirer will define the scope of those
tasks that reference the contract.
5.1.2.3 The acquisition documentation will also define the contract milestones at which the supplier’s
progress will be reviewed and audited as part of monitoring the acquisition (see 6.6 and 6.7).
5.1.2.4 The acquisition requirements should be given to the organization selected for performing the
acquisition activities.
5.1.3 Contract preparation and update. This activity consists of the following tasks:
5.1.3. 1 The acquirer should establish a procedu re for supplier selection including proposal evaluation
trite r ‘ia and requirements co mpliance weighting.
5.1.3.2 The acquirer should select a supplier based upon the evaluation of the suppliers’ proposals,
and other factors that need to be considered.
capabilities,
5.1.3.3 The acquirer may involve other parties, including potential suppliers, before contract award, in
tailoring this International Standard for the project. However, the acquirer will make the final decision
on the tailoring. The acquirer will include or reference the tailored International Standard in the
contract.
5.1.3.4 The acquirer will then prepare and negotiate a contract with the supplier, that addresses the
acquisition requirements, including the cost and schedule, of the software product or service to be
delivered. The contract will address proprietary, usage, ownership, warranty and licensing rights
associated with the reusable off-the-shelf software products.
ISO/IEC 12207 : 1995 (E) 8 lSO/IEC
5.1.3.5 Once the contract is underway, the acquirer will control changes to the contract through
negotiation with the supplier as part of a change control mechanism. Changes to the contract shall be
investigated for impact on project plans, costs, benefits, quality, and schedule.
NOTE - The acquirer determines whether the term “contract” or “agreement ” is to be used in the application of this
International Standard.
5.1.4 Supplier monitoring. This activity consists of the following tasks:
5.1.4.1 The acquirer will monitor the supplier’s activities in accordance with the Joint Review Process
(6.6) and the Audit Process (6.7). The acquirer should supplement the monitoring with the Verification
Process (6.4) and the Validation Process (6.5) as needed.
5.1.4.2 The acquirer will cooperate with the supplier to provide all necessary information in a timely
manner and resolve all pending items.
5.1.5 Acceptance and completion. This activity consists of the following tasks:
5.1.5.1 The acquirer should prepare for acceptance based on the defined acceptance strategy and
criteria. The preparation of test cases, test data, test procedures, and test environment should be
included. The extent of supplier involvement should be defined.
5.1.5.2 The acquirer will conduct acceptance review and acceptance testing of the deliverable software
product or service and will accept it from the supplier when all acceptance conditions are satisfied. The
acceptance procedure should comply with the provisions of 5.1.1.9.
5.1.5.3 After acceptance, the acquirer should take the responsibility for the configuration management
of the delivered software product (see 6.2).
may install or perform the software service in accordance with
NOTE - The acquirer the software product
instructions defined by the supplier
ISO/IEC 12207 : 1995 (E)
0 lSO/lEC
5.2 Supply process
The Supply Process contains the activities and tasks of the supplier. The process may be initiated
either by a decision to prepare a proposal to answer an acquirer’s request for proposal or by signing
and entering into a contract with the acquirer to provide the system, software product or software
service. The process continues with the determination of procedures and resources needed to manage
and assure the project, including development of project plans and execution of the plans through
delivery of the system, software product or software service to the acquirer.
The supplier manages the Supply 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).
. . .
st of actrvrtres: This process consists of the following activities:
1) Initiation;
2) Preparation of response;
3) Contract;
4) Planning;
5) Execution and control;
6) Review and evaluation;
7) Delivery and completion.
5.2.1 Initiation. This activity consists of the following tasks:
5.2.1.1 The supplier conducts a review of requirements in the request for proposal taking into account
organizational policies and other regulations.
5.2.1.2 The supplier should make a decision to bid or accept the contract.
5.2.2 Preparation of response. This activity consists of the following task:
5.2.2.1 The supplier should define and prepare a proposal in response to the request for proposal,
including its recommended tailoring of this International Standard.
5.2.3 Contract. This activity consists of the following tasks:
5.2.3.1 The supplier shall negotiate and enter into a contract with the acquirer organization to provide
the software product or service.
5.2.3.2 The supplier may request modification to the contract as part of the change control mechanism.
5.2.4 Planning. This activity consists of the following tasks:
5.2.4.1 The supplier shall conduct a review of the acquisition requirements to define the framework for
managing and assuring the project and for assuring the quality of the deliverable software product or
service.
5.2.4.2 If not stipulated in the contract, the supplier shall define or select a software life cycle model
appropriate to the scope, magnitude, and complexity of the project. The processes, activities, and tasks
of this International Standard shall be selected and mapped onto the life cycle model.
5.2.4.3 The supplier shall establish requirements for the plans for managing and assuring the project
and for assuring the quality of the deliverable software product or service. Requirements for the plans
should include resource needs and acquirer involvement.
ISO/IEC 12207 : 1995 (E)
0 ISO/lEC
5.2.4.4 Once the planning requirements are established, the supplier shall consider the options for
developing the software product or providing the software service, against an analysis of risks
associated with each option. Options include:
a) Develop the software product or provide the software service using internal resources.
b) Develop the software product or provide the software service by subcontracting.
c) Obtain off-the-shelf software products from internal or external sources.
d) A combination of a, b, and c above.
5.2.4.5 The supplier shall develop and document project management plan(s) based upon the planning
requirements and options selected in 5.2.4.4. Items to be considered in the plan include but are not
limited to the following:
Project organizational structure and authority and responsibility of each organizational unit,
a)
including external organizations;
Engineering environment (for development, operation, or maintenance, as applicable),
b)
including test environment, library, equipment, facilities, standards, procedures, and tools;
Work breakdown structure of the life cycle processes and activities, including the software
d
products, software services and non-deliverable items, to be performed together with budgets,
staffing, physical resources, software size, and schedules associated with the tasks;
Management of the quality characteristics of the software products or services. Separate plans
d)
for quality may be developed.
Manageme.nt of the safety, security, and other critical requirements of the software products or
e)
services. Separate plans for safety and security may be developed.
Subcontractor management, including subcontractor selection and involvement between the
f 1
subcontractor and the acquirer, if any;
Quality assurance (see 6.3);
9)
Verification (see 6.4) and validation (see 6.5); including tt le approach for interfacing with the
h)
verification and validation agent, if specified;
Acquirer involvement; that is, by such means as joint reviews (see 6.61, audits (see 6.71,
i)
lplementation, approval, acceptance,
informal meetings, reporting, modification and change; ir
and access to facilities;
User involvement; by such means as requirements setting exercises, prototype demonstrations
and evaluations;
Risk management; that is management of the areas of the project that involve potential
technical, cost, and schedule risks;
Security policy; that is, the rules for need-to-know and access-to-information at each project
I)
organization level;
Approval required by such means as regulations, required certifications, proprietary, usage,
m)
ownership, warranty and licensing rights;
n) Means for scheduling, tracking, and reporting;
Training of personnel (see 7.4).
0)
ISO/IEC 12207 : 1995 (El
0 lSO/lEC
5.2.5 Execution and control. This activity consists of the following tasks:
5.2.5.1 The supplier shall implement and execute the project management plan(s) developed in 5.2.4.
5.2.5.2 The supplier shall:
a) Develop the software product in accordance with Development Process (5.3).
b) Operate the software product in accordance with Operation Process (5.4).
c) Maintain the software product in accordance with Maintenance Process (5.5).
5.2.5.3 The supplier shall monitor and control the progress and the quality of the software products or
services of the project throughout the contracted life cycle. This shall be an ongoing, iterative task,
which shall provide for:
Monitoring progress of technical performance, costs, and schedules and reporting of project
a)
status;
b) Problem identification, recording, analysis, and resolution.
5.2.5.4 The supplier shall manage and control the subcontractors in accordance with the Acquisition
Process (5.1). The supplier shall pass down all contractual requirements necessary to ensure that the
software product or service delivered to the acquirer is developed or performed in accordance with the
prime-contract requirements.
5.2.5.5 The supplier shall interface with the independent verification, validation, or test agent as
specified in the contract and project plans.
5.2.5.6 The supplier shall interface with other parties as specified in the contract and project plans.
5.2.6 Review and evaluation. This activity consists of the following tasks:
5.2.6.1 The supplier should coordinate contract review activities, interfaces, and communication with
the acquirer’s organization.
5.2.6.2 The supplier shall conduct or support the informal meetings, acceptance review, acceptance
testing, joint reviews, and audits with the acquirer as specified in the contract and project plans. The
joint reviews shall be conducted in accordance with 6.6, audits in accordance with 6.7.
5.2.6.3 The supplier shall perform verification and validation in accordance with 6.4 and 6.5
respectively to demonstrate that the software products or services and processes fully satisfy their
respective requirements.
5.2.6.4 The supplier shall make available to the acq
...