ISO/IEC/IEEE 24748-5:2017

INTERNATIONAL ISO/IEC/
STANDARD IEEE
24748-5
First edition
2017-06
Systems and software engineering —
Life cycle management —
Part 5:
Software development planning
Ingénierie des systèmes et du logiciel — Gestion du cycle de vie —
Partie 5: Planification de développement de 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
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
4 Abbreviations . 5
5 Conformance . 5
5.1 General . 5
5.2 Intended usage . 6
5.3 Conformance to processes . 6
5.4 Conformance to information item content . 6
5.5 Full conformance . 6
5.6 Tailored conformance . 7
6 Concepts . 7
6.1 General . 7
6.2 System concepts . 7
6.3 Life cycle concepts . 7
6.4 Process concepts . 8
6.5 Project concepts . 8
6.6 Information item concepts . 8
6.6.1 General . 8
6.6.2 Concept of Plans . 9
6.6.3 Software development plans . 9
6.7 Management concepts . 10
6.7.1 General . 10
6.7.2 Project management . 10
6.7.3 Technical management . 10
6.8 Software development model concepts . 10
6.8.1 General . 10
6.8.2 Once-Through software development model . 11
6.8.3 Evolutionary software development model . 11
6.8.4 Incremental software development model . 11
7 Software life cycle processes and software development planning . 12
7.1 General . 12
7.2 Agreement processes . 12
7.3 Organizational project-enabling processes . 12
7.4 Technical management processes . 13
7.5 Technical processes . 13
8 Software development planning . 13
9 Process Execution . 14
9.1 Overview . 14
9.2 Project planning process . 14
9.2.1 General . 14
9.2.2 Responsibility for planning . 14
9.2.3 Project scope . 15
9.2.4 Work Breakdown Structure . 16
iii
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

9.2.5 Project estimation . 16
9.2.6 Relationship management . 18
9.2.7 Risk Management . 19
9.2.8 Configuration management . 19
9.2.9 Information management . 19
9.2.10 Quality Assurance . 19
9.3 Project and software measurement . 19
9.3.1 Measurement overview . 19
9.3.2 Project measures . 20
9.3.3 Software measures . 20
9.4 Project assessment and control . 21
9.4.1 Overview . 21
9.4.2 General guidance . 21
9.4.3 Project assessment and control process . 23
9.5 Decision management . 25
10 Information items: Technical plans . 26
10.1 Software Development Plan related to other plans . 26
10.2 Content of the Software Development Plan . 27
10.2.1 Content Overview . 27
10.2.2 Detailed content of the SDP . 27
Annex A (informative) Generic content for a plan . 30
Annex B (informative) Sample Software Development Plan outline . 31
Annex C (informative) Application of related standards . 35
Bibliography . 37
iv
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

Foreword
Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO
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 nongovernmental, 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.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

Attention is called to the possibility that implementation of this standard may require the use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. ISO/IEEE is not responsible for identifying essential patents
or patent claims for which a license may be required, for conducting inquiries into the legal validity or scope of
patents or patent claims or determining whether any licensing terms or conditions provided in connection with
submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form, if any, or in any
licensing agreements are reasonable or non‐discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own
responsibility. Further information may be obtained from ISO or the IEEE Standards Association.

Use of IEEE Standards documents is wholly voluntary. IEEE documents are made available for use subject to
important notices and legal disclaimers (see http://standards.ieee.org/IPR/disclaimers.html for more
information).
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee
SC 7, Systems and software engineering, in cooperation with IEEE Computer Society Systems and Software
Engineering Standards Committee, under the Partner Standards Development Organization cooperation
agreement between ISO and IEEE.
A list of all parts in the ISO/IEC/IEEE 24748 series can be found on the ISO website.
v
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

Introduction
ISO/IEC/IEEE 24748 provides unified and consolidated guidance on the life cycle management of systems and
software. This document draws on key aspects of the former IEEE J‐Std‐016 Standard for information technology
software — Software life cycle processes — Software development — Acquirer-supplier agreement. The IEEE has
identified the need for a non‐military standard to guide managers of software systems in software development
planning.
Taken together, the parts of ISO/IEC/IEEE 24748 are intended to facilitate the joint usage of the process content
of ISO/IEC/IEEE FDIS 12207 Systems and software engineering — Software life cycle processes and ISO/IEC/IEEE
15288, Systems and software engineering — System life cycle processes, which in turn may be used together with
related standards, such as for Information Technology (IT) service management and various lower‐level process
standards.
The acquisition or supply of a software system is usually done within a project. A project prepares and
implements the technical plans and schedules necessary to guide the project toward accomplishment of its
objectives and proper conclusion. Given the project’s authorization and objectives, the project should establish
plans for the technical management of activities as necessary for the software development effort.
This document unifies technical and management requirements and guidance from several sources to specify the
requirements for software engineering planning, including software development plans or software engineering
plans. This document also identifies the processes as defined in ISO/IEC/IEEE FDIS 12207 to perform the
necessary project planning activities to accomplish the project's technical effort and to develop the software
project's technical management and development plans.
This document focuses on the processes required for successful planning and management of the project's
software development effort and for development of the software development plan (SDP) as a vehicle for
representing a project's application of software life cycle processes. The SDP is a top level technical planning
document for a project which addresses technical management processes established by three principal sources
(the project’s agreement, applicable organizational and technical management processes, and the software
development project team) as necessary to successfully accomplish the software development related tasks of the
project.
vi
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE FDIS 24748-5
Systems and software engineering — Life cycle management —
Part 5: Software development planning
1 Scope
This document provides a common framework for planning and controlling the technical processes and activities
to produce and sustain software products. The complete life cycle is covered by this document, from idea
conception to the retirement of a software product. The framework described by this document provides for best
practices in communication and cooperation among parties that plan for, develop, utilize, and manage modern
software.
This document:
— specifies the required information items to be produced through the implementation of the required
planning and control processes;
— specifies the required content of the required information items;
— gives guidelines for the format and content of the required and related information items; and
— details the processes necessary to develop and implement a software plan.

This document is intended to provide guidance for parties involved in the planning of software engineering at all
stages of the software life cycle. It is intended to provide a common framework for two‐party and multi‐party
collaborations and can be applied where the parties are from the same organization. This document can also be
used by a single party.
This document is applicable to:
— those who use ISO/IEC/IEEE FDIS 12207 on projects dealing with software products and services related
to those products;
— those who are responsible for the technical management of the development of software systems;
— organizations and individuals performing software development activities; and
— organizations and individuals developing information items during the development of software.

2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments) applies.

ISO/IEC/IEEE FDIS 12207:2017, Systems and software engineering — Software life cycle processes

3 Terms, definitions and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE FDIS 12207, ISO/IEC TS
24748‐1:2016, and the following apply.

For additional terms and definitions, consult ISO/IEC/IEEE 24765, available at www.computer.org/sevocab.
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following addresses:

Under preparation. (Stage at time of publication ISO/IEC/IEEE FDIS 12207)
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

— 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://dictionary.ieee.org

3.1
acceptance
action by an authorized representative of the acquirer by which the acquirer assumes ownership of products as
partial or complete performance of an agreement
3.2
audit
independent examination of a work product or set of work products to assess compliance with specifications,
standards, contractual agreements, or other criteria
Note 1 to entry: Independent assessment of software products and processes conducted by an authorized person in order
to assess compliance with requirements.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.10]
3.3
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
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.13]
3.4
document
uniquely identified unit of information for human use, such as a report, specification, manual or book, in printed or
electronic form
[SOURCE: ISO/IEC/IEEE 15289:2015, 5.10]
3.5
estimation
process of developing a quantitative assessment of the likely amount or outcome
3.6
evaluation
systematic determination of the extent to which an entity meets its specified criteria
Note 1 to entry: The entity can be an item or activity.
[SOURCE: ISO/IEC 25001:2014, 4.1]
3.7
information item
separately identifiable body of information that is produced, stored, and delivered for human use
[SOURCE: ISO/IEC/IEEE 15289:2015, 5.13]
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

3.8
plan
information item that presents a systematic course of action for achieving a declared purpose, including when,
where, how, and by whom specific activities are to be performed
Note 1 to entry: The plan can also state artifacts that are to be created.
Note 2 to entry: Annex A provides contents of a generic plan.
[SOURCE: ISO/IEC/IEEE 15289:2011, 5.16]
3.9
planning
activities concerned with the specification of a plan
3.10
project manager
stakeholder with overall responsibility for the planning, execution, and closure of a project
Note 1 to entry: According to ISO/IEC/IEEE FDIS 12207, the project closure is performed in the Portfolio Management
process.
3.11
project management plan
information item that describes how the project will be executed, monitored, and controlled
Note 1 to entry : The plan typically describes the work to be done, the resources required, the methods to be used, the
procedures to be followed, the schedules to be met, and the way that the project is organized.
[SOURCE: ISO/IEC/IEEE 24765, modified – to distinguish between the technical and management approaches. See
also software development plan.]
3.12
record, verb
set down in a manner that can be retrieved and viewed
3.13
record, noun
set of related data items treated as a unit
[SOURCE: ISO/IEC/IEEE 15289:2015, 5.22]
3.14
software development environment
facilities, hardware, software, procedures, and documentation needed to perform software development
Note 1 to entry: Elements can include computer‐aided software engineering (CASE) tools, compilers, assemblers, linkers,
loaders, operating systems, debuggers, simulators, emulators, documentation tools, and database management systems.
Note 2 to entry: Plans for software development environments can include where the specified environment is to be
constructed, when sites provide different environments or facilities. For example, different testing environments can be
requested to be constructed at the acquirer's site and the supplier's site.
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

3.15
software development plan
SDP
information item that describes the technical approach to be followed for a software development effort
Note 1 to entry: The software development plan presents how the organization or project plans to conduct development
activities. A distinction is being made between the technical and management approaches. See also project management plan.

3.16
software engineering
systematic application of scientific and technological knowledge, methods, and experience to the design,
implementation, testing, and documentation of software
[SOURCE: ISO/IEC/IEEE 24765]
3.17
software item
item
identifiable part of a software product
EXAMPLE Source code, object code, control code, control data, or a collection of these items
Note 1 to entry: A software item can be viewed as a system element of ISO/IEC/IEEE 15288:2015.
[SOURCE: ISO/IEC/IEEE 15289:2015, 5.26]

3.18
software product
set of computer programs, procedures, and possibly associated documentation and data
3.19
software quality characteristic
category of software quality attributes that bears on software quality
[SOURCE: ISO/IEC 25000:2015, 4.52]

3.20
software system
system for which software is of primary importance to the stakeholders
3.21
software unit
atomic software component of the software architecture that can be subjected to stand‐alone testing
3.22
technical manager
stakeholder with responsibility for decisions relating to product content and quality achievement
Note 1 to entry: Technical decisions include definition and tailoring of life cycle processes, design of measurement systems,
and product implementation decisions
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

3.23
work breakdown structure
hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the
project objectives and create the required deliverables
Note 1 to entry: It organizes and defines the total scope of the project.

4 Abbreviations
CI configuration item
CM configuration management
COTS commercial off the shelf
ICWG interface control working group
IT information technology
LOC lines of code
SDP software development plan
SEMP systems engineering management plan
TPM technical performance measure
WBS work breakdown structure
5 Conformance
5.1 General
This document may be used as a conformance or a guidance document for projects and organizations claiming
conformance to ISO/IEC/IEEE FDIS 12207.

To claim conformance to this document, having tailored the selected software life cycle processes, the users of this
document shall prepare the information items identified in this document applicable to the selected and tailored
ISO/IEC/IEEE FDIS 12207 processes.

The generic and specific record and information item contents in Clauses 8 and 9 of this document may be tailored
to satisfy requirements of an organization, its projects, or agreements based on the tailored conformance to
ISO/IEC/IEEE FDIS 12207. In tailoring, information item titles and contents provided in this document may be
modified (added to, combined or retitled). The contents of the information items shall correspond to the selected
and tailored processes.
NOTE ISO/IEC/IEEE FDIS 12207:2017, Annex A, provides requirements for the Tailoring process.
Throughout this document, “shall” is used to express a provision that is normative, “should” to express a
recommendation among other possibilities, and “may” to indicate a course of action permissible within the limits
of this document.
The verb “include” used in this document indicates that either:
a) the information is present; or
b) a reference to the information is listed.

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

5.2 Intended usage
This document:
— specifies the required set of processes or activities that deal with the technical planning of a software
development effort and that are detailed during the evolution of the software development plan, and
— provides normative definition of the content of the information items that result from the implementation
of these processes.
Users of this document can claim conformance to the process provisions or to the information item provisions, or
both.
The requirements in this document are contained in Clauses 6, 8, 9, and 10.

5.3 Conformance to processes
This document provides requirements for the processes to be selected from ISO/IEC/IEEE FDIS 12207, necessary
for planning the technical management of software development, and suitable for usage during the life cycle of a
software system or product.
The process requirements in this document are contained in Clause 9.

NOTE A claim to tailored conformance to ISO/IEC/IEEE FDIS 12207 does not necessarily imply conformance to the
processes in this document. When claiming tailored conformance to the processes, the directions given in ISO/IEC/IEEE FDIS
12207:2017, 2.3, apply.
5.4 Conformance to information item content
This document provides requirements for a number of information items to be produced during the life cycle of a
software system or product.
In this document, for simplicity of reference, each information item is described as if it were published as a
separate document. However, information items shall be considered as conforming if they are unpublished but
available in a repository for reference, divided into separate documents or volumes, or combined with other
information items into one document. Use of the nomenclature of the specific records or the information item
titles is not required to claim conformance with this document.

A claim of conformance to the information item provisions of this document means that:
— the required information items stated in this document are produced; and
— the information items produced during the processes demonstrate conformity to the content requirements
defined in this document.
The requirements for the content of the information items in this document are contained in 6.6.

NOTE If a user of this document claims full conformance to ISO/IEC/IEEE 15289, it does not imply that the user can
claim conformance to the information items and information item content in this document. The reasons for this are:
1) ISO/IEC/IEEE 15289 does not contain requirements for all the specific information items listed in this document; and
2) ISO/IEC/IEEE 15289 does not contain normative requirements for all the content of the information items listed in
this document.
5.5 Full conformance
A claim of full conformance to this document is the equivalent of claiming conformance to all of the requirements
("shall" statements).
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

5.6 Tailored conformance
When this document is used as a basis for establishing a set of information items that do not qualify for full
conformance, the clauses of this document are selected or modified in accordance with the tailoring process
prescribed in ISO/IEC/IEEE FDIS 12207:2017, Annex A. The tailored text, for which tailored conformance is
claimed, shall be declared. Tailored conformance is achieved by demonstrating that requirements for the
information items, as tailored, have been satisfied using the outcomes of the Tailoring process as evidence.

6 Concepts
6.1 General
This clause presents essential concepts on which this document is based. These concepts apply to, and are
necessary for, understanding the technical planning of a software development effort, as well as the related
information items that are to be produced.

NOTE Annex C provides guidance on how related standards discuss these concepts.

6.2 System concepts
Technical planning of a software development effort assumes an understanding of system concepts. This
document is intended to provide guidance for the key stakeholders involved in designing, developing, and
delivering systems.
The systems described in this document are designed and developed for the benefit of users, acquirers, and other
stakeholders. A system is delivered to solve a problem or provide a service described by the acquirer, and it meets
a set of requirements customized to the acquirer’s needs. It may include software, hardware, data, processes,
materials, and naturally occurring entities.

A system is designed and its deliverables developed and tested. Technical planning accounts for all of the
activities, tasks, and efforts required to develop a system that meets a set of requirements.

NOTE System and software concepts are introduced in ISO/IEC/IEEE FDIS 12207:2017, 5.2. Additional discussion, such
as systems and system structure, is provided in ISO/IEC TS 24748‐1:2016, 3.1.

6.3 Life cycle concepts
Technical planning of a software development effort assumes an understanding of life cycle concepts.

Every software system has a life cycle. A life cycle can be described using an abstract functional model that
represents the conceptualization of a need for the system, its realization, utilization, evolution and disposal.

Technical planning takes into consideration the entire life cycle of a system, from conception to retirement. This
document provides guidance for the initial design and development effort, often the most laborious component of
planning. However, this document also provides guidance for further efforts, including iterative improvements to
a system and retirement of a system.

NOTE 1 Life cycle concepts are introduced in ISO/IEC/IEEE FDIS 12207:2017, 5.4. Additional discussion is in ISO/IEC TR
24748‐3.
NOTE 2 INCOSE Systems Engineering Handbook discusses system life cycle concepts in terms of business, budget and
technical aspects, and project cycles in terms of decision gates. Discussion of different methods, implementation strategies and
case studies highlight some of decisions facing organizations and projects in determining appropriate system and life cycle
models to employ.
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

6.4 Process concepts
Technical planning for a software development effort assumes an understanding of process concepts. Technical
planning includes the planning for and evaluation of the processes that an organization employs to meet the
requirements specified for a system.

This document provides requirements and guidance for the processes that can be performed during the life cycle
of a software system. Effective processes should be recommended to all stakeholders involved in the development
effort. Stakeholders adhere to the accepted processes to increase the efficiency and effectiveness of the
development effort.
The Software Development Plan (SDP) acts as a repository for processes specific to a project or organization.
Other processes may be introduced external to the SDP, as part of the culture and Standard Operating Procedure
of the organization.
NOTE 1 Process concepts are introduced in ISO/IEC/IEEE FDIS 12207:2017, 5.5 and ISO/IEC TS 24748‐1:2016, 3.3.
NOTE 2 Process concepts as related to software are discussed in ISO/IEC TR 24748‐3:2011, 4.4.

6.5 Project concepts
Technical planning of a software development effort assumes an understanding of project concepts. As defined in
ISO/IEC/IEEE FDIS 12207, a project is an endeavor with defined start and finish criteria undertaken to create a
product or service in accordance with specified resources and requirements, while a project portfolio is a
collection of projects that addresses the strategic objectives of the organization.

A project may be viewed as a unique process comprising coordinated and controlled activities and may be
composed of activities from the Technical Management processes and Technical processes defined in
ISO/IEC/IEEE FDIS 12207. In ISO/IEC/IEEE FDIS 12207 and in this document, the project has been chosen as the
context for describing processes concerned with planning, assessment and control.

There need not be a one‐to‐one relationship between a software development effort and the projects related to
the effort. However, for the purpose of this document, software development is done within a project.

NOTE 1 Project concepts are discussed in ISO/IEC/IEEE TR 24748‐3:2011, 4.6.
NOTE 2 ISO/IEC TS 24748‐1:2016, 3.1.4, provides more detail on structure in systems and projects, and 3.1.5 provides
more detail on enabling systems.
NOTE 3 ISO/IEC/IEEE 16326 provides more information on project management and the project management plan.
th
NOTE 4 Software Extension to the PMBOK® Guide, 5 edition, provides more information on projects and project
management.
6.6 Information item concepts
6.6.1 General
ISO/IEC/IEEE FDIS 12207 defines an information management process, but does not detail documentation in
terms of name, format, explicit content, and recording media. ISO/IEC/IEEE FDIS 12207 establishes a common
framework for software life‐cycle processes and requires a number of information items. It does not always
specify when software information items are to be prepared, nor does it identify information item contents.

NOTE 1 ISO/IEC/IEEE 15289 provides a mapping of ISO/IEC/IEEE FDIS 12207 clauses with a set of information items. It
specifies how life cycle data is managed in information items. ISO/IEC/IEEE 15289:2015, 6.1, provides requirements for life
cycle data characteristics.
For each life‐cycle process, it would be possible to prepare a plan, procedures, and reports, as well as numerous
records, requests, descriptions and specifications. Such an elaboration of the documentation schema would be
© ISO/IEC 2017 ‐ All rights reserved
© IEEE 2017 – All rights reserved

more rigorous than specified by ISO/IEC/IEEE FDIS 12207. ISO/IEC/IEEE FDIS 12207 does not detail the life‐cycle
processes in terms of methods or procedures required to meet the requirements and outcomes of a process. Thus,
information items may be combined or subdivided as needed for project or organizational purposes.
Information item content is information included in an information item, associated with a system, product or
service, to satisfy a requirement or need.

An information item has to be consistent with an information item generic type. An information item type is a
group of information items consistent with a pre‐arranged set of generic criteria.

NOTE 2 ISO/IEC/IEEE 15289:2015, Clause 7, provides more information on contents of generic information types.

ISO/IEC/IEEE 15289 makes a distinction between records and documents (which includes plans). Each
information item produced as a document supports certain life cycle data characteristics. A document is a generic
term for separately identifiable, published (in electronic or printed media) information. Documents are produced
and communicated for human use and contain formal elements (such as purpose, scope, and summary), intended
to make them usable by their intended audience.

In this document, for simplicity of reference, each information item is described as if it was published as a single
document. However, the information items may be considered as conforming if it is unpublished but available in a
repository for reference, divided into separate documents or volumes, or combined with other information items
into one document.
6.6.2 Concept of Plans
A Systems Engineering Management Plan (SEMP) is a top‐level technical planning document for a project which
addresses technical management processes as necessary to successfully accomplish the systems engineering‐
related tasks of the project. The technical management processes are typically established by three principal
sources:
1) the project’s contract or agreement;
2) applicable organizational processes; and
3) the systems engineering project team.
NOTE Annex A provides guidance for a generic plan.

6.6.3 Software development plans
The plan addressed in this document is often called the Software Development Plan (SDP), Software Engineering
Management Plan, or Software Engineering Plan. The SDP presents how the organization or project plans to
conduct software development or software engineering activities (the software implementation strategy). It is a
comprehensive, composite artifact that contains all information required to manage the software development
activities.
The SDP itself, coupled with the process of developing it, helps an organization produce a software system in a
more structured, predictable, and efficient way. It provides documented confirmation of project details, which
helps ensure a common understanding of the project among a varied group of stakeholders. It helps an
organization to estimate time and resources required to develop the project from specifications. Finally, the SDP
also contributes to clarity of roles and responsibilities and establishes continuity in the event of changes to project
requirements.
NOTE The required content of the SDP is in 9.2; Annex B provides an example outline of an SDP.

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

6.7 Management concepts
6.7.1 General
This document describes two management roles: project and technical. Technical management and project
management are collaborative efforts that, taken together, manage a software development project. The role of a
project manager is distinct from that of a technical manager. For the purpose of this document, the project
manager is responsible for all tasks related to project management, including s
...