ISO/IEC/IEEE 12207:2017

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2017-11
Systems and software engineering —
Software life cycle processes
Ingénierie des systèmes et du logiciel — Processus du cycle de vie du
logiciel
Reference number
©
ISO/IEC 2017
©
IEEE 2017
© ISO/IEC 2017, Published in Switzerland
© IEEE 2017
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO or IEEE at the address below or ISO’s member body in the
country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
Ch. de Blandonnet 8 • CP 401 3 Park Avenue, New York
CH-1214 Vernier, Geneva, Switzerland NY 10016-5997, USA
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org stds.ipr@ieee.org
www.iso.org www.ieee.org
© ISO/IEC 2017 – All rights reserved
ii © IEEE 2017 – All rights reserved

Contents Page
Foreword . vi
Introduction . vii
1 Scope . 1
1.1 Overview . 1
1.2 Purpose . 1
1.3 Field of application . 1
1.4 Limitations . 2
2 Normative references . 2
3 Terms, definitions, and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 11
4 Conformance . 11
4.1 Intended usage . 11
4.2 Full conformance . 12
4.2.1 Full conformance to outcomes . 12
4.2.2 Full conformance to tasks . 12
4.3 Tailored conformance . 12
5 Key concepts and application . 13
5.1 Introduction . 13
5.2 Software system concepts . 13
5.2.1 Software systems . 13
5.2.2 Software system structure . 13
5.2.3 Enabling systems . 15
5.2.4 Life cycle processes for the software system . 16
5.3 Organization and project concepts . 16
5.3.1 Organizations . 16
5.3.2 Organization and project-level adoption . 17
5.4 Life cycle concepts . 17
5.4.1 Software life cycle stages . 17
5.4.2 Life cycle model for the software system . 17
5.5 Process concepts . 19
5.5.1 Criteria for processes . 19
5.5.2 Description of processes . 19
5.5.3 General characteristics of processes . 19
5.5.4 Tailoring . 19
5.6 Process groups . 19
5.6.1 Introduction . 19
5.6.2 Agreement processes . 21
5.6.3 Organizational project-enabling processes . 22
5.6.4 Technical Management processes . 22
5.6.5 Technical processes . 22
5.7 Process application . 22
5.8 Process reference model . 23
6 Software life cycle processes . 24
6.1 Agreement processes . 24
6.1.1 Acquisition process . 24
6.1.2 Supply process . 27
6.2 Organizational Project-Enabling processes . 28
6.2.1 Life cycle model management process . 29
6.2.2 Infrastructure Management process . 30
6.2.3 Portfolio Management process . 31
6.2.4 Human Resource Management process . 33
iii
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

6.2.5 Quality Management process . 34
6.2.6 Knowledge Management process . 36
6.3 Technical Management processes . 37
6.3.1 Project Planning process . 38
6.3.2 Project assessment and control process . 40
6.3.3 Decision Management process . 43
6.3.4 Risk Management process . 44
6.3.5 Configuration Management process . 46
6.3.6 Information Management process . 50
6.3.7 Measurement process . 52
6.3.8 Quality Assurance process . 53
6.4 Technical processes . 55
6.4.1 Business or Mission Analysis process . 56
6.4.2 Stakeholder Needs and Requirements Definition process . 59
6.4.3 System/Software requirements definition process . 63
6.4.4 Architecture Definition process . 66
6.4.5 Design Definition process . 71
6.4.6 System Analysis process . 74
6.4.7 Implementation process . 75
6.4.8 Integration process . 79
6.4.9 Verification process . 82
6.4.10 Transition process. 85
6.4.11 Validation process . 89
6.4.12 Operation process . 92
6.4.13 Maintenance process . 95
6.4.14 Disposal process . 99
Annex A (normative) Tailoring process . 102
A.1 Introduction . 102
A.2 Tailoring process . 102
A.2.1 Purpose . 102
A.2.2 Outcomes . 102
A.2.3 Activities and tasks . 102
Annex B (informative) Examples of process information items . 104
Annex C (informative) Process Reference Model for assessment purposes . 107
C.1 Introduction . 107
C.2 Conformance with ISO/IEC 33004 . 107
C.2.1 General . 107
C.2.2 Requirements for process reference models . 107
C.2.3 Process descriptions . 108
C.3 The process reference model . 108
Annex D (informative) Process integration and process constructs . 109
D.1 Introduction . 109
D.2 Process constructs and their usage . 109
Annex E (informative) Process views . 111
E.1 Introduction . 111
E.2 The process view concept . 111
E.3 Process viewpoint . 111
E.4 Process view for specialty engineering . 112
E.5 Process view for interface management . 114
E.6 Process view for software assurance (Information security) . 116
Annex F (informative) Software system architecture modelling . 120
F.1 Introduction . 120
F.2 Views, models and model kinds used in software system architecture . 120
F.2.1 Functional model . 120
F.2.2 Static model . 121
F.2.3 Data model . 121
F.2.4 Behavioral model . 121
F.2.5 Temporal model . 121
F.2.6 Structural model . 121
iv
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

F.2.7 Network model . 121
F.3 Other model considerations . 121
Annex G (informative) Application of software life cycle processes to a system of systems . 123
G.1 Introduction . 123
G.2 SoS characteristics and types . 123
G.3 SE processes applied to systems of systems . 124
G.3.1 General . 124
G.3.2 Agreement processes . 124
G.3.3 Organizational project enabling processes . 124
G.3.4 Technical management processes . 125
G.3.5 Technical processes . 125
Annex H (informative)  Application of Agile . 127
Annex I (informative)  Process Mapping from ISO/IEC/IEEE 12207:2008 . 129
Bibliography . 143

List of Illustrations
Figure 1 —Software system and software system element relationship . 14
Figure 2 —Example of software system-of-interest structure . 14
Figure 3 —Software system-of-interest, its operational environment and enabling systems . 15
Figure 4 —Software life cycle processes . 21
Table B.1 — Sample information items by process . 104
Figure D.1 — ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process constructs . 110
Table G.1 — System of Systems types . 123
Table I.1 — Comparison of processes in ISO/IEC/IEEE 12207:2017 and the previous edition . 129
Table I.2 — Comparison of process outcomes in ISO/IEC/IEEE 12207:2017 and software-related
outcomes in the previous edition . 131

v
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO 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. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non‐governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees
of the IEEE Standards Association (IEEE‐SA) Standards Board. The IEEE develops its standards through a
consensus development process, approved by the American National Standards Institute, which brings together
volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not
necessarily members of the Institute and serve without compensation. While the IEEE administers the process
and establishes rules to promote fairness in the consensus development process, the IEEE does not independently
evaluate, test, or verify the accuracy of any of the information contained in its standards.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO, IEC, and IEEE shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well
as information about ISO’s adherence to the World Trade Organization (WTO) principles in the Technical Barriers
to Trade (TBT) see the following URL www.iso.org/iso/foreword.html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 7, Systems and software engineering, in cooperation with the IEEE Computer Society Systems and Software
Engineering Standards Committee, under the Partner Standards Development Organization cooperation
agreement between ISO and IEEE.
This first edition of ISO/IEC/IEEE 12207 cancels and replaces ISO/IEC 12207:2008 (second edition), which has
been technically revised.
Changes in this revision of ISO/IEC/IEEE 12207 were developed in conjunction with a corresponding revision of
ISO/IEC/IEEE 15288:2015, Systems and software engineering – System life cycle processes. The purpose of these
revisions is to accomplish the harmonization of the structures and contents of the two documents, while
supporting the requirements of the engineering and assessment communities.
This document was developed with the following goals:
— provide a common terminology between the revision of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207;
— where applicable, provide common process names and process structure between the revision of
ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207; and
— enable the user community to evolve towards fully harmonized standards, while allowing backward
compatibility.
This revision is intended to achieve a fully harmonized view of the system and software life cycle processes.
vi
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

Introduction
The complexity of software systems has increased to an unprecedented level. This has led to new opportunities,
but also to increased challenges for the organizations that create and utilize systems. These challenges exist
throughout the life cycle of a system and at all levels of architectural detail. This document provides a common
process framework for describing the life cycle of systems created by humans, adopting a Software Engineering
approach. Software Engineering is an interdisciplinary approach and means to enable the realization of successful
software systems. It focuses on defining stakeholder needs and required functionality early in the development
cycle, documenting requirements, and performing design synthesis and system validation while considering the
complete problem. It integrates all the disciplines and specialty groups into a team effort forming a structured
development process that proceeds from concept to production to operation and maintenance. It considers both
the business and the technical needs of all stakeholders with the goal of providing a quality product that meets the
needs of users and other applicable stakeholders. This life cycle spans the conception of ideas through to the
retirement of a system. It provides the processes for acquiring and supplying systems. It helps to improve
communication and cooperation among the parties that create, utilize and manage modern software systems in
order that they can work in an integrated, coherent fashion. In addition, this framework provides for the
assessment and improvement of the life cycle processes.
The processes in this document form a comprehensive set from which an organization can construct software life
cycle models appropriate to its products and services. An organization, depending on its purpose, can select and
apply an appropriate subset to fulfill that purpose.
This document can be used in one or more of the following modes:
a) By an organization — to help establish an environment of desired processes. These processes can be
supported by an infrastructure of methods, procedures, techniques, tools and trained personnel. The
organization may then employ this environment to perform and manage its projects and progress
software systems through their life cycle stages. In this mode, this document is used to assess
conformance of a declared, established environment to its provisions.
b) By a project — to help select, structure and employ the elements of an established environment to
provide products and services. In this mode, this document is used in the assessment of conformance of
the project to the declared and established environment.
c) By an acquirer and a supplier — to help develop an agreement concerning processes and activities. Via
the agreement, the processes and activities in this document are selected, negotiated, agreed to and
performed. In this mode, this document is used for guidance in developing the agreement.
d) By process assessors — to serve as a process reference model for use in the performance of process
assessments that may be used to support organizational process improvement.

vii
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

INTERNATIONAL STANDARD     ISO/IEC/IEEE 12207:2017(E)
Systems and software engineering — Software life cycle processes
1 Scope
1.1 Overview
This document 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 applicable
during the acquisition, supply, development, operation, maintenance or disposal of software systems, products,
and services. These life cycle processes are accomplished through the involvement of stakeholders, with the
ultimate goal of achieving customer satisfaction.
This document applies to the acquisition, supply, development, operation, maintenance, and disposal (whether
performed internally or externally to an organization) of software systems, products and services, and the
software portion of any system, Software includes the software portion of firmware. Those aspects of system
definition needed to provide the context for software products and services are included.
This document also provides processes that can be employed for defining, controlling, and improving software life
cycle processes within an organization or a project.
The processes, activities, and tasks of this document can also be applied during the acquisition of a system that
contains software, either alone or in conjunction with ISO/IEC/IEEE 15288:2015, Systems and software
engineering—System life cycle processes.
In the context of this document and ISO/IEC/IEEE 15288, there is a continuum of human‐made systems from
those that use little or no software to those in which software is the primary interest. It is rare to encounter a
complex system without software, and all software systems require physical system components (hardware) to
operate, either as part of the software system‐of‐interest or as an enabling system or infrastructure. Thus, the
choice of whether to apply this document for the software life cycle processes, or ISO/IEC/IEEE 15288:2015,
Systems and software engineering—System life cycle processes, depends on the system‐of‐interest. Processes in
both documents have the same process purpose and process outcomes, but differ in activities and tasks to
perform software engineering or systems engineering, respectively.
1.2 Purpose
The purpose of this document is to provide a defined set of processes to facilitate communication among acquirers,
suppliers and other stakeholders in the life cycle of a software system.
This document is written for acquirers, suppliers, developers, integrators, operators, maintainers, managers,
quality assurance managers, and users of software systems, products, and services. It can be used by a single
organization in a self‐imposed mode or in a multi‐party situation. Parties can be from the same organization or
from different organizations and the situation can range from an informal agreement to a formal contract.
The processes in this document can be used as a basis for establishing business environments, e.g., methods,
procedures, techniques, tools and trained personnel. Annex A provides normative direction regarding the tailoring
of these software life cycle processes.
1.3 Field of application
This document applies to the full life cycle of software systems, products, and services, including conception,
development, production, utilization, support and retirement, and to their acquisition and supply, whether
performed internally or externally to an organization. The life cycle processes of this document can be applied
concurrently, iteratively and recursively to a software system and incrementally to its elements.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

There is a wide variety of software systems in terms of their purpose, domain of application, complexity, size,
novelty, adaptability, quantities, locations, life spans and evolution. This document describes the processes that
comprise the life cycle of man‐made software systems. It therefore applies to one‐of‐a‐kind software systems,
software systems for wide commercial or public distribution, and customized, adaptable software systems. It also
applies to a complete stand‐alone software system and to software systems that are embedded and integrated
into larger, more complex and complete systems.
This document provides a process reference model characterized in terms of the process purpose and the process
outcomes that result from the successful execution of the activity tasks. Annex B lists examples of artifacts and
information items that may be associated with various processes. This document can therefore be used as a
reference model to support process assessment as specified in ISO/IEC 33002:2015. Annex C provides
information regarding the use of the software life cycle processes as a process reference model. Annex D describes
the process constructs for use in the process reference model. Annex I provides the correspondence between this
document and ISO/IEC/IEEE 12207:2008 at the level of process name and process outcome.
1.4 Limitations
This document does not prescribe a specific software life cycle model, development methodology, method,
modelling approach, or technique. The users of this document are responsible for selecting a life cycle model for
the project and mapping the processes, activities, and tasks in this document into that model. The parties are also
responsible for selecting and applying appropriate methodologies, methods, models and techniques suitable for
the project.
This document does not establish a management system or require the use of any management system standard.
However, it is intended to be compatible with the quality management system specified by ISO 9001, the service
management system specified by ISO/IEC 20000‐1 (IEEE Std 20000‐1), and the information security management
system specified by ISO/IEC 27000.
This document does not detail information items in terms of name, format, explicit content and recording media.
ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation).
2 Normative references
There are no normative references in this document.
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEEE Standards Dictionary Online: available at http://ieeexplore.ieee.org/xpls/dictionary.jsp
Definitions for other terms typically can be found in ISO/IEC/IEEE 24765, System and software engineering —
Vocabulary, available at .
3.1.1
acquirer
stakeholder that acquires or procures a product or service from a supplier
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or
internal/organizational sponsor.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.1.2
acquisition
process of obtaining a system, product or service
3.1.3
activity
set of cohesive tasks of a process
3.1.4
agile development
software development approach based on iterative development, frequent inspection and adaptation, and
incremental deliveries, in which requirements and solutions evolve through collaboration in cross‐functional
teams and through continual stakeholder feedback
[SOURCE: ISO/IEC/IEEE 26515: 2011]
3.1.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
3.1.6
architecture
fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution
[SOURCE: ISO/IEC/IEEE 42010:2011]
3.1.7
architecture framework
conventions, principles and practices for the description of architectures established within a specific domain of
application and/or community of stakeholders
EXAMPLE 1 Generalised Enterprise Reference Architecture and Methodologies (GERAM) [ISO 15704] is an architecture
framework.
EXAMPLE 2 Reference Model of Open Distributed Processing (RM‐ODP) [ISO/IEC 10746] is an architecture framework.
[SOURCE: ISO/IEC/IEEE 42010:2011]
3.1.8
architecture view
work product expressing the architecture of a system from the perspective of specific system concerns
[SOURCE: ISO/IEC/IEEE 42010:2011]
3.1.9
architecture viewpoint
work product establishing the conventions for the construction, interpretation and use of architecture views to
frame specific system concerns
[SOURCE: ISO/IEC/IEEE 42010:2011]
3.1.10
audit
independent examination of a work product or set of work products to assess compliance with specifications,
standards, contractual agreements, or other criteria
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.1.11
baseline
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
[SOURCE: IEEE Std 828‐2012]
3.1.12
business process
partially ordered set of enterprise activities that can be executed to achieve some desired end‐result in pursuit of
a given objective of an organization
3.1.13
concept of operations
verbal and/or graphic statement, in broad outline, of an organization’s assumptions or intent in regard to an
operation or series of operations
Note 1 to entry: The concept of operations frequently is embodied in long‐range strategic plans and annual operational
plans. In the latter case, the concept of operations in the plan covers a series of connected operations to be carried out
simultaneously or in succession. The concept is designed to give an overall picture of the organization operations. See also
operational concept (3.1.28).
Note 2 to entry: It provides the basis for bounding the operating space, system capabilities, interfaces and operating
environment.
[SOURCE: ANSI/AIAA G‐043A‐2012e]
3.1.14
concern
interest in a system relevant to one or more of its stakeholders
Note 1 to entry: A concern pertains to any influence on a system in its environment, including developmental,
technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
[SOURCE: ISO/IEC/IEEE 42010:2011]
3.1.15
configuration item
item or aggregation of hardware, software, or both, that is designated for configuration management and treated
as a single entity in the configuration management process
EXAMPLE Software, firmware, data, hardware, humans, processes (e.g., processes for providing service to users),
procedures (e.g., operator instructions and user manuals), facilities, services, materials, and naturally occurring entities
3.1.16
customer
organization or person that receives a product or service
EXAMPLE Consumer, client, user, acquirer, buyer, or purchaser.
Note 1 to entry: A customer can be internal or external to the organization.
3.1.17
design, verb
to define the architecture, system elements, interfaces, and other characteristics of a system or system
element
[SOURCE: ISO/IEC/IEEE 24765:2010, modified, changed ‘components’ to ‘system element’]
3.1.18
design, noun
result of the process in 3.1.17
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

Note 1 to entry: Information, including specification of system elements and their relationships, that is sufficiently
complete to support a compliant implementation of the architecture
Note 2 to entry: Design provides the detailed implementation‐level physical structure, behavior, temporal relationships,
and other attributes of system elements.
3.1.19
design characteristic
design attributes or distinguishing features that pertain to a measurable description of a product or service
3.1.20
enabling system
system that supports a system‐of‐interest during its life cycle stages but does not necessarily contribute directly to
its function during operation
EXAMPLE A configuration manage
...