ISO/IEC TR 7052:2023
(Main)Software engineering — Controlling frequently occurring risks during development and maintenance of custom software
Software engineering — Controlling frequently occurring risks during development and maintenance of custom software
This document: — describes frequently occurring risks during development and maintenance of custom software; — describes possible controls for frequently occurring risks; — describes the related: — activities, facilities and roles typically used for these controls; — properties of products and processes; — standards, measurements, testing and assessment of the properties of products and processes.
Ingéniérie du logiciel — Contrôle des risques fréquents au cours du développement et de la maintenance d'un logiciel sur mesure
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 7052
First edition
2023-09
Software engineering — Controlling
frequently occurring risks during
development and maintenance of
custom software
Ingéniérie du logiciel — Contrôle des risques fréquents au cours du
développement et de la maintenance d'un logiciel sur mesure
Reference number
ISO/IEC TR 7052:2023(E)
© ISO/IEC 2023
---------------------- Page: 1 ----------------------
ISO/IEC TR 7052:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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 at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 7052:2023(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms .11
5 Explanatory note on terms .11
5.1 The term risk . 11
5.2 The term control . 11
6 Risks .12
6.1 General .12
6.2 Product-related risks . 13
6.2.1 General .13
6.2.2 Risk 01: The quality of the software is reduced because of modifications to
it . 13
6.2.3 Risk 02: The quality of the software is reduced because of modifications to
the environment in which it runs . 13
6.3 Project-related risks . 14
6.3.1 General . 14
6.3.2 Risk 03: Planned functionality is not completed on time because of
underestimation of the amount of work involved . 14
6.3.3 Risk 04: The product is not delivered on time and within budget because
the scope is changed . 14
6.3.4 Risk 05: The software does not meet the requirements laid down because
the team does not have the required expertise .15
6.3.5 Risk 06: The product does not offer the right functionality because of
inadequate management of the work . 15
6.3.6 Risk 07: The product lacks the right non-functional properties because
functional requirements were given too much priority . 16
6.3.7 Risk 08: Misunderstandings occur because the communication between
stakeholders is poor . 16
6.3.8 Risk 09: Custom software does not (demonstrably) meet obligations
because development, use and maintenance were not sufficiently auditable . 17
6.3.9 Risk 10: The product is not delivered on time because a great deal of time
was needed to set up for software development . 17
7 Controls . .18
7.1 General . 18
7.2 Project-related controls . 18
7.2.1 General . 18
7.2.2 Project preparation . 19
7.2.3 Project execution .23
7.2.4 Completion of development and/or maintenance . . 27
7.3 Organization-related controls .28
7.3.1 Control 16: Supporting teams with specialist knowledge and tools .28
7.3.2 Control 17: Continuous risk management .29
Annex A (informative) Overview of risks and controls .31
Annex B (informative) Assessment tool .33
Bibliography .35
iii
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC TR 7052:2023(E)
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.
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 or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of
any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC
had not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, 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
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 7052:2023(E)
Introduction
Information and communication technology (ICT) projects run many risks. ICT projects often have to
contend with delay, budget overruns, and an end result of low quality.
ICT projects in which custom software is developed and/or maintained often run extra risks, on top
[31]
of the risks that are part and parcel of ICT projects in general . This seems to be caused by the sheer
size and complexity of such custom software projects, and by a failure to mitigate the risks inherent to
software development in general, despite the fact that they are well known, and that there are suitable
controls for their management.
This document describes controls for some of the risks inherent in custom software development.
The purpose of this document is that during the development of custom software stakeholders can
avail themselves of a collection of suitable controls. The controls included are common of themselves,
making this collection of controls a logical starting point for assuring the quality of custom software
development. Controls were selected for inclusion based on the experience and opinion of the subject
matter experts contributing to this document.
Two target groups are important when mitigating risks during the development of custom software:
a) the software development acquirers and suppliers;
b) the end users and maintainers of the software developed.
This document details risks and controls specific to custom software development. Risk management
in the context of software development is covered in ISO/IEC/IEEE 12207 and its elaboration standard
ISO/IEC/IEEE 16085. Generic risk management is covered by ISO 31000 and its related standards.
This document is based on NPR 5326 developed by Royal Netherlands Standardization Institute
Foundation (NEN, https://www.nen.nl/).
v
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 7052:2023(E)
Software engineering — Controlling frequently occurring
risks during development and maintenance of custom
software
1 Scope
This document:
— describes frequently occurring risks during development and maintenance of custom software;
— describes possible controls for frequently occurring risks;
— describes the related:
— activities, facilities and roles typically used for these controls;
— properties of products and processes;
— standards, measurements, testing and assessment of the properties of products and processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
acceptance test-driven development
ATDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly write the acceptance tests prior to development of the relevant functionality
Note 1 to entry: Although the name of the method, acceptance test-driven development, suggests that ATDD
is a specialization of test-driven development (3.46) (TDD), this is not the case. Rather, TDD focuses on driving
development by writing unit tests (3.48) first and ATDD focuses on driving development by writing acceptance
tests first.
[SOURCE: NEN NPR 5326:2019, 3.1, modified —Added note 1 to entry.]
3.2
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.44)
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/
organizational sponsor.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.1]
1
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC TR 7052:2023(E)
3.3
agile development
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 continuous stakeholder feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — In note 1 to entry, removed the reference to
ISO/IEC/IEEE 26515:2018, Annex A.]
3.4
backlog
collection of agile features or stories of both functional and non-functional requirements that are
typically sorted in an order based on value priority
Note 1 to entry: This can be used as a list of product requirements and deliverables (3.13) not part of current
work, to be prioritized and completed.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.4, modified — Removed note 1 to entry.]
3.5
behaviour-driven development
BDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly describe the behaviour of the intended functionality prior to development of
the relevant functionality
[SOURCE: NEN NPR 5326:2019, 3.5]
3.6
burndown
indicator of the work completed and estimate of remaining work to be completed or remaining effort
needed to complete a product development iteration cycleNote 1 to entry: Work is measured as all work
done to deliver story points, stories, features, functions, function points (3.25), user stories (3.50), use
cases (3.49), or requirements during a product development iteration.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.437, modified — Restructured into definition and note 1 to
entry.]
3.7
burndown chart
graph that represents the work remaining to do on a project
Note 1 to entry: See Figure 1 for an example of a burndown chart.
2
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 7052:2023(E)
Key
1 solid line, representing the actual work-remaining
2 stippled line, representing the ideal burndown of the work
Figure 1 — Example of a burndown chart with time on the horizontal axis and work-remaining
on the vertical axis
Note 2 to entry: This can be used as a chart to show the amount of the work done versus the amount of the work
still to do.
Note 3 to entry: This can be presented per sprint (3.42), as well as per release or iteration.
Note 4 to entry: For example, user story points (3.51) or function points (3.25) can be used to measure the amount.
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.6, modified — Added the example figure and notes to entry.]
3.8
business impact analysis
process of analysing the impact over time of a disruption on the organization
Note 1 to entry: The outcome is a statement and justification of business continuity requirements.
[SOURCE: ISO 22300:2021, 3.1.24]
3.9
code review
activity where one or more developers (3.18) establish the quality (3.35) of (part of) the source code
(3.41) by going through it
Note 1 to entry: There are a variety of ways to conduct code reviews which range from formal to very informal
and from discrete to continuous.
[SOURCE: NEN NPR 5326:2019, 3.10, modified — Modified definition and added note 1 to entry.]
3.10
configuration management database
CMDB
database that is used by an organization to store information about the hardware and software in use
[SOURCE: NEN NPR 5326:2019 3.11]
3
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 7052:2023(E)
3.11
consequence
outcome of an event (3.23) affecting objectives (3.30)
Note 1 to entry: An event can lead to a range of consequences.
Note 2 to entry: A consequence can be certain or uncertain and can have positive or negative effects on objectives.
Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.
Note 4 to entry: Initial consequences can escalate through knock-on effects.
[SOURCE: ISO Guide 73:2009, 3.6.1.3]
3.12
control
measure that is modifying risk (3.37)
Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.
Note 2 to entry: Controls cannot always exert the intended or assumed modifying effect.
[SOURCE: ISO Guide 73:2009, 3.8.1.1, modified — In note 2 to entry, changed “may not” to “cannot”.]
3.13
custom software
software product developed for a specific application from a user requirements specification
[SOURCE: ISO/IEC 25000:2014, 4.3]
3.14
data protection impact assessment
DPIA
tool described in the General Data Protection Regulation (3.27) (GDPR) to assess in advance the privacy
risks of data processing and then to be able to implement controls (3.12) to reduce the risks (3.37)
Note 1 to entry: See https:// gdpr .eu/ article -35 -impact -assessment/ .
[SOURCE: NEN NPR 5326:2019 3.12, modified — Changed “take measures” to “implement controls”.
Added note 1 to entry with link to the GDPR Article 35.]
3.15
deliverable
any unique and verifiable product, result, or capability to perform a service that must be produced to
complete a process, phase, or project
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1098, definition 1]
3.16
Delphi method
information-gathering technique used as a way to reach consensus of experts on a subject
Note 1 to entry: The Delphi method is applied as consensus tool for determining weights of indicators/sub-
indicators in this document.
Note 2 to entry: A facilitator uses a questionnaire to solicit ideas about the important project points related to the
subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus
can be reached in a few rounds of this process.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1102, modified — Restructured into definition and notes to
entry.]
4
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 7052:2023(E)
3.17
design thinking
methodology for solving (very complex) problems where these are defined from the human needs
Note 1 to entry: In design thinking solutions are determined with brainstorming sessions, where prototypes
(3.34) are produced to test the intended solution in practice.
[SOURCE: NEN NPR 5326:2019, 3.15]
3.18
developer
individual or organization that performs development activities (including requirements analysis,
design, testing through acceptance) during the system or software life-cycle process
Note 1 to entry: Activities of the developer of custom software (3.13) include setup and analysis of functional and
non-functional system and software requirements, design, programming and testing.
Note 2 to entry: Designers, programmers and testers are therefore all developers.
[SOURCE: ISO/IEC 25000:2014, 4.6. modified — Added notes to entry.]
3.19
development pipeline
build pipeline
set of tools aimed at the managed and controlled build of a package with which an application can be
taken into use
Note 1 to entry: As part of this various tests are carried out to determine and assess quality (3.35).
[SOURCE: NEN NPR 5326:2019, 3.30]
3.20
development team
team that develops and/or maintains software
Note 1 to entry: The acquirer (3.2), product owner (3.33) and future maintainer can form part of the development
team.
Note 2 to entry: Development teams can be broken down by function (e.g. a team of designers, a team of
programmers, a team of testers) or be multidisciplinary (each team has e.g. design, programming and test
expertise).
[SOURCE: NEN NPR 5326:2019, 3.31]
3.21
DevOps
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems products
and services, and continuous improvements in all aspects of the life cycle
[SOURCE: IEEE 2675-2021 3.1]
3.22
distributed denial of service attack
DDoS attack
unauthorized access to a system resource or the delaying of system operations and functions in the way
of compromising multiple systems to flood the bandwidth or resources of the targeted system, with
resultant loss of availability to authorized users
[SOURCE: ISO/IEC 27039:2015, 3.7]
5
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 7052:2023(E)
3.23
event
occurrence or change of a particular set of circumstances
Note 1 to entry: An event can be one or more occurrences and can have several causes.
Note 2 to entry: An event can consist of something not happening.
Note 3 to entry: An event can sometimes be referred to as an ‘incident’ or ‘accident’.
Note 4 to entry: An event without consequences (3.11) can also be referred to as a ‘near miss’, ‘accident’, ‘near hit’
or ‘close call’.
[SOURCE: ISO Guide 73:2009, 3.5.1.3]
3.24
extreme programming
XP
form of agile software development where procedures for iterative planning and working are combined
with technical procedures, such as test-driven design and pair programming
[SOURCE: NEN NPR 5326:2019, 3.20]
3.25
function point
FP
unit of measure for functional size
[SOURCE: ISO/IEC 20926:2009, 3.35, modified — removed “as defined within this International
Standard”.]
3.26
function point analysis
FPA
method for measuring functional size
[SOURCE: ISO/IEC 20926:2009, 3.36, modified — removed “as defined within this International
Standard”.]
3.27
General Data Protection Regulation
GDPR
European Regulation that standardizes the rules for processing personal data by private businesses
and government bodies in the whole European Union
Note 1 to entry: See https:// gdpr .eu.
[SOURCE: NEN NPR 5326:2019, 3.3]
3.28
integration testing
testing in which software components, hardware components, or both are combined and tested to
evaluate the interaction between them
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2034, modified — Removed note 1 to entry.]
6
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 7052:2023(E)
3.29
minimum viable product
MVP
version of a work product with just enough features and requirements to satisfy early customers and/
or provide feedback for future development
[SOURCE: IEEE 2675-2021, 3.1]
3.30
objective
predetermined result to be achieved
Note 1 to entry: To achieve an objective several tools and activities are generally needed, one of which can be
custom software (3.13).
[SOURCE: NEN NPR 5326:2019, 3.18]
3.31
performance test
test type conducted to evaluate the degree to which a test item accomplishes its designated functions
within given constraints of time and other resources
Note 1 to entry: A distinction is often made between load, stress and endurance tests. Load tests simulate a
normal load on the system. Stress tests allow the load to increase to determine the maximum load at which the
system still functions. Endurance tests load the system for a longer period in order to discover memory leaks or
other problems which only manifest themselves after some time.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.58, modified — Changed the term from "performance testing"
to "performance test"; changed "type of testing" to "test type"; added note 1 to entry.]
3.32
product breakdown structure
PBS
decomposition of the product into its components
Note 1 to entry: The PBS begins with the complete product at the top of the hierarchy and below this the main
components, which can also each be broken down again into components, etc.
[SOURCE: ISO 21511:2018, 3.7, modified — Added the abbreviated term and note 1 to entry.]
3.33
product owner
stakeholder responsible for the capabilities, acceptance and use of a product
Note 1 to entry: The product owner shares the product vision, required features and their priorities, and
acceptance criteria.
[SOURCE: ISO/IEC TR 24587:2021, 3.12]
3.34
prototype
model or preliminary implementation suitable for evaluation of system design, performance, and
production potential, or for better understanding or determination of the requirements
[SOURCE: ISO/IEC 2382:2015, 2122670, modified — Removed notes to entry.]
3.35
quality
ability of a product, service, system, component, or process to meet customer or user needs,
expectations, or requirements
Note 1 to entry: For the quality of software and IT systems, ISO/IEC 25010 offers a breakdown into aspects, such
as:
7
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC TR 7052:2023(E)
— reliability;
— security;
— usability;
— functional suitability;
— maintainability;
— portability;
— performance efficiency;
— compatibility.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3259, definition 2, modified — Added note 1 to entry.]
3.36
regression test
test type used following modifications to a test item or to its operational environment, to identify
whether regression failures occur
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.64, modified — Changed to term from "regression testing" to
"regression test"; changed "testing performed" to "test type used"; changed "failures in unmodified
parts of the test item" to " regression failures": removed notes to entry.]
3.37
risk
effect of uncertainty on objectives (3.30)
[SOURCE: ISO Guide 73:2009, 1.1, modified — Notes to entry removed]
3.38
risk treatment
process to modify a risk (3.37)
Note 1 to entry: Risk treatment can involve:
— avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
— taking or increasing risk in order to pursue an opportunity;
— removing the risk source;
— changing the likelihood;
— changing the consequences (3.11);
— sharing the risk with another party or parties (including contracts and risk financing and;
— retaining the risk based on an informed decision.
Note 2 to entry: Risk treatment that deal with negative consequences is sometimes referred to as ‘risk mitigation’,
‘risk elimination’, ‘risk prevention’ or ‘risk reduction’.
Note 3 to entry: Risk treatment can create new risks or modify existing risks.
[SOURCE: ISO Guide 73:2009, 3.8.1]
3.39
Scrum
iterative project management framework used in agile development (3.3), in which a team agrees on
development items from a requireme
...
ISO/IEC DTR2 DTR 7052:202x(X)
ISO JTC 1/SC 7 N9089
ISO/IEC JTC 1/SC 7/WG 7 N2935
2023-01-16
Secretariat: BIS
Date: 2023-05-31
Software engineering -- Risk management– Controlling frequently
occurring risks during development and maintenance of custom
software
DTR2Ingéniérie du logiciel – Contrôle des risques fréquents au cours du développement et
de la maintenance d'un logiciel sur mesure
FDIS stage
Warning for WDs and CDs
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
change without notice and may not be referred to as an International Standard.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 1 ----------------------
© ISO 20XX
---------------------- Page: 2 ----------------------
ISO/IEC DTR2DTR 7052:202x (en:(E)
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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 at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland
© ISO/IEC 2022 2023 – All rights reserved iiiv
---------------------- Page: 3 ----------------------
ISO/IEC DTR2DTR 7052:202x (en:(E)
Contents
Foreword . vi
Introduction .vi i
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 12
5 Explanatory note on terms . 13
5.1 The term risk . 13
5.2 The term control . 13
6 Risks . 14
6.1 General . 14
6.2 Product-related risks . 14
6.2.1 General . 14
6.2.2 Risk 01: The quality of the software is reduced because of modifications to it . 15
6.2.3 Risk 02: The quality of the software is reduced because of modifications to the environment in
which it runs . 15
6.3 Project-related risks . 16
6.3.1 General . 16
6.3.2 Risk 03: Planned functionality is not completed on time because of underestimation of the
amount of work involved . 16
6.3.3 Risk 04: The product is not delivered on time and within budget because the scope is changed
16
6.3.4 Risk 05: The software does not meet the requirements laid down because the team does not
have the required expertise . 17
6.3.5 Risk 06: The product does not offer the right functionality because of inadequate management
of the work . 17
6.3.6 Risk 07: The product lacks the right non-functional properties because functional requirements
were given too much priority . 18
6.3.7 Risk 08: Misunderstandings occur because the communication between stakeholders is poor
18
6.3.8 Risk 09: Custom software does not (demonstrably) meet obligations because development, use
and maintenance were not sufficiently auditable . 19
6.3.9 Risk 10: The product is not delivered on time because a great deal of time was needed to set up
for software development. 19
7 Controls . 20
7.1 General . 20
7.2 Project-related controls . 20
7.2.1 General . 20
7.2.2 Project preparation . 21
7.2.3 Project execution . 25
iv iv © ISO/IEC 2022 2023 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC DTR2DTR 7052:202x (en:(E)
7.2.4 Completion of development and/or maintenance . 29
7.3 Organization-related controls . 30
7.3.1 Control 16: Supporting teams with specialist knowledge and tools . 30
7.3.2 Control 17: Continuous risk management . 31
Annex A (informative) Overview of risks and controls . 33
Annex B (informative) Assessment tool . 35
Bibliography . 38
© ISO/IEC 2022 2023 – All rights reserved vv
---------------------- Page: 5 ----------------------
ISO/IEC DTR2DTR 7052:202x (en:(E)
Foreword
ISO (the International Organization for Standardization) is a and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide federation of national
standardsstandardization. National bodies (that are members of ISO member bodies). The work of
preparing or IEC participate in the development of International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a established by
the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committee has been established has the right to be represented on that committee.
Internationalcommittees 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. ISO
collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documentsdocument 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 or
www.iec.ch/members_experts/refdocs).
Attention is drawnISO and IEC draw attention to the possibility that some of the elementsimplementation
of this document may beinvolve the subjectuse of (a) patent(s). ISO and IEC take no position concerning
the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of
publication of this document, ISO and IEC had not received notice of (a) patent(s) which may be required
to implement this document. However, implementers are cautioned that this may not represent the latest
information, which may be obtained from the patent database available at www.iso.org/patents and
https://patents.iec.ch rights. ISO. ISO and IEC 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 ).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, 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
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
vi iv © ISO/IEC 2022 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC DTR2DTR 7052:202x (en:(E)
Introduction
Information and communication technology (ICT) projects run many risks. ICT projects often have to
contend with delay, budget overruns, and an end result of low quality.
ICT projects in which custom software is developed and/or maintained often run extra riskrisks, on top
[31[32] ]
of the risks that are part and parcel of ICT projects in general . . This would seemseems to be caused
by the sheer size and complexity of such custom software projects, and by a failure to mitigate the risks
inherent to software development in general, despite the fact that they are well known, and that there
are suitable controls for their management.
This document describes controls for some of the risks inherent in custom software development. The
purpose of this document is that during the development of custom software stakeholders can avail
themselves of a collection of suitable controls. The controls included are each common of themselves,
making this collection of controls a logical starting point for assuring the quality of custom software
development. Controls were selected for inclusion based on the experience and opinion of the subject
matter experts contributing to this document.
Two target groups are important when mitigating risks during the development of custom software:
a) (i) the software development acquirers and suppliers, and (ii) ;
a)b) the end users and maintainers of the software developed.
This document details risks and controls specific to custom software development. Risk management in
the context of software development is covered in ISO/IEC/IEEE 12207 and its elaboration standard
ISO/IEC/IEEE 16085. Generic risk management is covered by ISO 31000 and its related standards.
This document is based on NPR 5326 developed by Royal Netherlands Standardization Institute
Foundation (NEN, https://www.nen.nl/).
© ISO/IEC 2022 2023 – All rights reserved viiv
---------------------- Page: 7 ----------------------
ISO/IEC DTR 7052:(E)
Software engineering -- Risk management– Controlling frequently
occurring risks during development and maintenance of custom
software
1 Scope
This document:
— describes frequently occurring risks during development and maintenance of custom software;
— describes possible controls for frequently occurring risks;
— describes the related:
— activities, facilities and roles typically used for these controls;
— properties of products and processes;
— standards, measurements, testing and assessment of the properties of products and
processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1
acceptance test-driven development
ATDD
development method where team members with various backgrounds [developers (3.18(3.18),), testers
and business analysts)] jointly write the acceptance tests prior to development of the relevant
functionality
Note 1 to entry: Although the name of the method, acceptance test-driven development, suggests that ATDD is a
specialization of test-driven development (3.46(3.49)) (TDD), this is not the case. Rather, TDD focuses on driving
development by writing unit tests (3.48) first and ATDD focuses on driving development by writing acceptance tests
first.
[SOURCE: NEN NPR 5326:2019, 3.1, modified – —Added Notenote 1 to entry.]
3.2
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.44(3.47))
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or
internal/organizational sponsor.
© ISO/IEC 2023 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/IEC DTR 7052:(E)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.1]
3.3
agile development
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 continuous stakeholder feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1], modified — In note 1 to entry, removed the reference to
ISO/IEC/IEEE 26515:2018, Annex A.]
3.4
backlog
collection of agile features or stories of both functional and non-functional requirements that are typically
sorted in an order based on value priority
Note 1 to entry 1: : This can be used as a list of product requirements and deliverables (3.13(3.13)) not part of
current work, to be prioritized and completed.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.4], modified — Removed note 1 to entry.]
3.5
behaviour-driven development
BDD
development method where team members with various backgrounds [developers (3.18(3.18),), testers
and business analysts)] jointly describe the behaviour of the intended functionality prior to development
of the relevant functionality
[SOURCE: NEN NPR 5326:2019, 3.5]
3.6
burndown
indicator of the work completed and an estimate of remaining work to be completed or remaining effort
needed to complete a product development iteration cycle.cycleNote 1 to entry: Work is measured as all
work done to deliver story points, stories, features, functions, function points (3.25(3.26),), user stories
(3.50(3.53),), use cases (3.49(3.52),), or requirements during a product development iteration.
[SOURCE: Software Extension to the PMBOK® Guide – Fifth Edition]
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.437, modified — Restructured into definition and note 1 to
entry.]
3.7
burndown chart
graph that represents the work remaining to do on a project
2 © ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC DTR 7052:(E)
Note 1 to entry: See Figure 1
[SOURCE: Niessink, F., ICTU, The Hague]
Figure for an example of a burndown chart.
Key
1 solid line, representing the actual work-remaining
2 stippled line, representing the ideal burndown of the work
Figure 1 — Example of a burndown chart with time on the horizontal axis and work-remaining
on the vertical axis. The solid line represents the actual work-remaining and the stippled line
represents the ideal burndown of the work.
Note 1 2 to entry: This can be used as a chart to show the amount of the work done versus the amount of the work
still to do.
Note 2 3 to entry: This can be presented per sprint (3.42(3.35),), as well as per release or iteration.
© ISO/IEC 2023 – All rights reserved 3
---------------------- Page: 10 ----------------------
ISO/IEC DTR 7052:(E)
Note 3 4 to entry: For example, user story points (3.51(3.54)) or function points (3.25(3.26)) can be used to measure
the amount.
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.6. Modified – Notes, modified — Added the example figure and
notes to entry and figure added.]
3.8
business impact analysis
process of analysing the impact over time of a disruption on the organization
Note 1 to entry: The outcome is a statement and justification of business continuity requirements.
[SOURCE: ISO 22300:2021, 3.1.24]
3.9
code review
activity where one or more developers (3.18(3.18)) establish the quality (3.35(3.38)) of (part of) the
source code (3.41(3.44) ) by going through it
Note 1 to entry: There are a variety of ways to conduct code reviews which range from formal to very informal and
from discrete to continuous.
[SOURCE: NEN NPR 5326:2019, 3.10., modified — Modified definition and added note 1 to entry added].]
3.10
configuration management database
CMDB
database that is used by an organization to store information about the hardware and software in use
[SOURCE: NEN NPR 5326:2019 3.11]
3.11
consequence
outcome of an event (3.23(3.24)) affecting objectives (3.30(3.32))
Note 1 to entry: An event can lead to a range of consequences.
Note 2 to entry: A consequence can be certain or uncertain and can have positive or negative effects on objectives.
Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.
Note 4 to entry: Initial consequences can escalate through knock-on effects.
[SOURCE: ISO Guide 73:2009, 3.6.1.3]
3.12
control
measure that is modifying risk (3.37(3.40))
Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.
Note 2 to entry: Controls cannot always exert the intended or assumed modifying effect.
[SOURCE: ISO Guide 73:2009, 3.8.1.1, modified – Note— In note 2 to entry modified from, changed “may
not” to “cannot”.]
4 © ISO/IEC 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC DTR 7052:(E)
3.13
custom software
software product developed for a specific application from a user requirements specification
[SOURCE: ISO/IEC 25000:2014, 4.3]
3.14
data protection impact assessment
DPIA
tool described in the General Data Protection Regulation (3.27(3.28)) (GDPR) to assess in advance the
privacy risks of data processing and then to be able to implement controls (3.12(3.12)) to reduce the risks
(3.37(3.40) )
Note 1 to entry: See https://gdpr.eu/article-35-impact-assessment/.
[SOURCE: NEN NPR 5326:2019 3.12, modified –— Changed “take measures” to “implement controls”.
Added Notenote 1 to entry with link to the GDPR Article 35.]
3.15
deliverable
any unique and verifiable product, result, or capability to perform a service that must be produced to
complete a process, phase, or project
[SOURCE: A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Sixth Edition]
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1098, definition 1]
3.16
Delphi method
information-gathering technique used as a way to reach consensus of experts on a subject
Note 1 to entry: The Delphi method is applied as consensus tool for determining weights of indicators/sub-
indicators in this document.
Note 2 to entry: A facilitator uses a questionnaire to solicit ideas about the important project points related to the
subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus
can be reached in a few rounds of this process.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1102, restructuredmodified — Restructured into definition and
Notesnotes to entry].]
3.17
design thinking
methodology for solving (very complex) problems where these are defined from the human needs
Note 1 to entry: In design thinking solutions are determined with brainstorming sessions, where prototypes
(3.34(3.37)) are produced to test the intended solution in practice.
[SOURCE: NEN NPR 5326:2019, 3.15]
3.18
developer
individual or organization that performs development activities (including requirements analysis,
design, testing through acceptance) during the system or software life-cycle process
Note 1 to entry: Activities of the developer of custom software (3.13(3.13)) include setup and analysis of functional
and non-functional system and software requirements, design, programming and testing.
© ISO/IEC 2023 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO/IEC DTR 7052:(E)
Note 2 to entry: Designers, programmers and testers are therefore all developers.
[SOURCE: ISO/IEC 25000:2014, 4.6. modified –— Added Notesnotes to entry.]
3.19
development pipeline
build pipeline
set of tools aimed at the managed and controlled build of a package with which an application can be
taken into use
Note 1 to entry: As part of this various tests are carried out to determine and assess quality (3.35(3.38).).
[SOURCE: NEN NPR 5326:2019, 3.30]
3.20
development team
team that develops and/or maintains software
Note 1 to entry: The acquirer (3.2(3.2),), product owner (3.33(3.35)) and future maintainer can form part of the
development team.
Note 2 to entry: Development teams can be broken down by function (for examplee.g. a team of designers, a team
of programmers, a team of testers) or be multidisciplinary (each team has for examplee.g. design, programming and
test expertise).
[SOURCE: NEN NPR 5326:2019, 3.31]
3.21
DevOps
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems products and
services, and continuous improvements in all aspects of the life cycle
[SOURCE: IEEE 2675-2021 3.1]
3.22
distributed denial of service attack
DDoS attack
unauthorized access to a system resource or the delaying of system operations and functions in the way
of compromising multiple systems to flood the bandwidth or resources of the targeted system, with
resultant loss of availability to authorized users
[SOURCE: ISO/IEC 27039:2015, 3.7]
3.23
earned value management
management methodology for integrating scope, schedule, and resources; for objectively measuring
project performance and progress; and for forecasting project outcome
[SOURCE: Project Management Institute, Practice Standard for Earned Value Management - Second
Edition (2011)]
3.24
event
occurrence or change of a particular set of circumstances
Note 1 to entry: An event can be one or more occurrences and can have several causes.
6 © ISO/IEC 2023 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC DTR 7052:(E)
Note 2 to entry: An event can consist of something not happening.
Note 3 to entry: An event can sometimes be referred to as an ‘incident’ or ‘accident’.
Note 4 to entry: An event without consequences (3.11(3.11)) can also be referred to as a ‘near miss’, ‘accident’, ‘near
hit’ or ‘close call’.
[SOURCE: ISO Guide 73:2009, 3.5.1.3]
3.2524
extreme programming
XP
form of agile software development where procedures for iterative planning and working are combined
with technical procedures, such as test-driven design and pair programming
[SOURCE: NEN NPR 5326:2019, 3.20]
3.2625
function point
FP
unit of measure for functional size
[SOURCE: ISO/IEC 20926:2009, 3.35, modified — removed “as defined…” clause.] within this
International Standard”.]
3.2726
function point analysis
FPA
method for measuring functional size
[SOURCE: ISO/IEC 20926:2009, 3.36, modified — removed “as defined…” clause.] within this
International Standard”.]
3.2827
general data protection regulation
General Data Protection Regulation
GDPR
European Regulation that standardizes the rules for processing personal data by private businesses and
government bodies in the whole European Union
Note 1 to entry: See https://gdpr.eu.
[SOURCE: NEN NPR 5326:2019, 3.3]
3.2928
integration testing
testing in which software components, hardware components, or both are combined and tested to
evaluate the interaction between them
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2034]
3.30
lean start-up
set of practices for helping entrepreneurs increase their odds of a building a successful start-up
© ISO/IEC 2023 – All rights reserved 7
---------------------- Page: 14 ----------------------
ISO/IEC DTR 7052:(E)
‘’[SOURCE: Ries, 2011, p. 27, modified — spelling changed from “lean startup”Removed note 1 to “lean
start-up”.]entry.]
3.3129
minimum viable product
MVP
version of a work product with just enough features and requirements to satisfy early customers and/or
provide feedback for future development
[SOURCE: IEEE 2675-2021, 3.1]
3.3230
objective
predetermined result to be achieved
Note 1 to entry: To achieve an objective several tools and activities are generally needed, one of which can be custom
software (3.13(3.13).).
[SOURCE: NEN NPR 5326:2019, 3.18]
3.3331
performance test
test type conducted to evaluate the degree to which a test item accomplishes its designated functions
within given constraints of time and other resources
Note 1 to entry: A distinction is often made between load, stress and endurance tests. Load tests simulate a normal
load on the system. Stress tests allow the load to increase to determine the maximum load at which the system still
functions. Endurance tests load the system for a longer period in order to discover memory leaks or other problems
which only manifest themselves after some time.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.58. Added Note, modified — Changed the term from
"performance testing" to "performance test"; changed "type of testing" to "test type"; added note 1 to
entry.]
3.3432
product breakdown structure
PBS
decomposition of the product into its components
Note 1 to entry: The PBS begins with the complete product at the top of the hierarchy and below this the main
components, which can also each be broken down again into components, etc.
[SOURCE: ISO 21511:2018, 3.7, modified – added Note— Added the abbreviated term and note 1 to
entry.]
3.3533
product owner
stake
...
FINAL
TECHNICAL ISO/IEC DTR
DRAFT
REPORT 7052
ISO/IEC JTC 1/SC 7
Software engineering – Controlling
Secretariat: BIS
frequently occurring risks during
Voting begins on:
2023-06-15 development and maintenance of
custom software
Voting terminates on:
2023-08-10
Ingéniérie du logiciel – Contrôle des risques fréquents au cours du
développement et de la maintenance d'un logiciel sur mesure
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC DTR 7052:2023(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS. © ISO/IEC 2023
---------------------- Page: 1 ----------------------
ISO/IEC DTR 7052:2023(E)
FINAL
TECHNICAL ISO/IEC DTR
DRAFT
REPORT 7052
ISO/IEC JTC 1/SC 7
Software engineering – Controlling
Secretariat: BIS
frequently occurring risks during
Voting begins on:
development and maintenance of
custom software
Voting terminates on:
Ingéniérie du logiciel – Contrôle des risques fréquents au cours du
développement et de la maintenance d'un logiciel sur mesure
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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 at the address below
or ISO’s member body in the country of the requester.
RECIPIENTS OF THIS DRAFT ARE INVITED TO
ISO copyright office
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
CP 401 • Ch. de Blandonnet 8
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
CH-1214 Vernier, Geneva
DOCUMENTATION.
Phone: +41 22 749 01 11
IN ADDITION TO THEIR EVALUATION AS
Reference number
Email: copyright@iso.org
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
ISO/IEC DTR 7052:2023(E)
Website: www.iso.org
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
Published in Switzerland
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN
DARDS TO WHICH REFERENCE MAY BE MADE IN
ii
© ISO/IEC 2023 – All rights reserved
NATIONAL REGULATIONS. © ISO/IEC 2023
---------------------- Page: 2 ----------------------
ISO/IEC DTR 7052:2023(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms .11
5 Explanatory note on terms .11
5.1 The term risk . 11
5.2 The term control . 11
6 Risks .12
6.1 General .12
6.2 Productrelated risks . 13
6.2.1 General .13
6.2.2 Risk 01: The quality of the software is reduced because of modifications to
it . 13
6.2.3 Risk 02: The quality of the software is reduced because of modifications to
the environment in which it runs . 13
6.3 Projectrelated risks . 14
6.3.1 General . 14
6.3.2 Risk 03: Planned functionality is not completed on time because of
underestimation of the amount of work involved . 14
6.3.3 Risk 04: The product is not delivered on time and within budget because
the scope is changed . 14
6.3.4 Risk 05: The software does not meet the requirements laid down because
the team does not have the required expertise .15
6.3.5 Risk 06: The product does not offer the right functionality because of
inadequate management of the work . 15
6.3.6 Risk 07: The product lacks the right nonfunctional properties because
functional requirements were given too much priority . 16
6.3.7 Risk 08: Misunderstandings occur because the communication between
stakeholders is poor . 16
6.3.8 Risk 09: Custom software does not (demonstrably) meet obligations
because development, use and maintenance were not sufficiently auditable . 17
6.3.9 Risk 10: The product is not delivered on time because a great deal of time
was needed to set up for software development . 17
7 Controls . .18
7.1 General . 18
7.2 Projectrelated controls . 18
7.2.1 General . 18
7.2.2 Project preparation . 19
7.2.3 Project execution .23
7.2.4 Completion of development and/or maintenance . . 27
7.3 Organizationrelated controls .28
7.3.1 Control 16: Supporting teams with specialist knowledge and tools .28
7.3.2 Control 17: Continuous risk management .29
Annex A (informative) Overview of risks and controls .31
Annex B (informative) Assessment tool .33
Bibliography .35
iii
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC DTR 7052:2023(E)
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 nongovernmental, in liaison with ISO and IEC, also take part in the
work.
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 or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of
any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC
had not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, 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
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understandingstandards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/nationalcommittees.
iv
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC DTR 7052:2023(E)
Introduction
Information and communication technology (ICT) projects run many risks. ICT projects often have to
contend with delay, budget overruns, and an end result of low quality.
ICT projects in which custom software is developed and/or maintained often run extra risks, on top
[31]
of the risks that are part and parcel of ICT projects in general . This seems to be caused by the sheer
size and complexity of such custom software projects, and by a failure to mitigate the risks inherent to
software development in general, despite the fact that they are well known, and that there are suitable
controls for their management.
This document describes controls for some of the risks inherent in custom software development.
The purpose of this document is that during the development of custom software stakeholders can
avail themselves of a collection of suitable controls. The controls included are common of themselves,
making this collection of controls a logical starting point for assuring the quality of custom software
development. Controls were selected for inclusion based on the experience and opinion of the subject
matter experts contributing to this document.
Two target groups are important when mitigating risks during the development of custom software:
a) the software development acquirers and suppliers;
b) the end users and maintainers of the software developed.
This document details risks and controls specific to custom software development. Risk management
in the context of software development is covered in ISO/IEC/IEEE 12207 and its elaboration standard
ISO/IEC/IEEE 16085. Generic risk management is covered by ISO 31000 and its related standards.
This document is based on NPR 5326 developed by Royal Netherlands Standardization Institute
Foundation (NEN, https://www.nen.nl/).
v
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC DTR 7052:2023(E)
Software engineering – Controlling frequently occurring
risks during development and maintenance of custom
software
1 Scope
This document:
— describes frequently occurring risks during development and maintenance of custom software;
— describes possible controls for frequently occurring risks;
— describes the related:
— activities, facilities and roles typically used for these controls;
— properties of products and processes;
— standards, measurements, testing and assessment of the properties of products and processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
acceptance test-driven development
ATDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly write the acceptance tests prior to development of the relevant functionality
Note 1 to entry: Although the name of the method, acceptance test-driven development, suggests that ATDD
is a specialization of test-driven development (3.46) (TDD), this is not the case. Rather, TDD focuses on driving
development by writing unit tests (3.48) first and ATDD focuses on driving development by writing acceptance
tests first.
[SOURCE: NEN NPR 5326:2019, 3.1, modified —Added note 1 to entry.]
3.2
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.44)
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/
organizational sponsor.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.1]
1
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC DTR 7052:2023(E)
3.3
agile development
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 continuous stakeholder feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — In note 1 to entry, removed the reference to
ISO/IEC/IEEE 26515:2018, Annex A.]
3.4
backlog
collection of agile features or stories of both functional and non-functional requirements that are
typically sorted in an order based on value priority
Note 1 to entry: This can be used as a list of product requirements and deliverables (3.13) not part of current
work, to be prioritized and completed.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.4, modified — Removed note 1 to entry.]
3.5
behaviour-driven development
BDD
development method where team members with various backgrounds [developers (3.18), testers and
business analysts] jointly describe the behaviour of the intended functionality prior to development of
the relevant functionality
[SOURCE: NEN NPR 5326:2019, 3.5]
3.6
burndown
indicator of the work completed and estimate of remaining work to be completed or remaining effort
needed to complete a product development iteration cycleNote 1 to entry: Work is measured as all work
done to deliver story points, stories, features, functions, function points (3.25), user stories (3.50), use
cases (3.49), or requirements during a product development iteration.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.437, modified — Restructured into definition and note 1 to
entry.]
3.7
burndown chart
graph that represents the work remaining to do on a project
Note 1 to entry: See Figure 1 for an example of a burndown chart.
2
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC DTR 7052:2023(E)
Key
1 solid line, representing the actual workremaining
2 stippled line, representing the ideal burndown of the work
Figure 1 — Example of a burndown chart with time on the horizontal axis and work-remaining
on the vertical axis
Note 2 to entry: This can be used as a chart to show the amount of the work done versus the amount of the work
still to do.
Note 3 to entry: This can be presented per sprint (3.42), as well as per release or iteration.
Note 4 to entry: For example, user story points (3.51) or function points (3.25) can be used to measure the amount.
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.6, modified — Added the example figure and notes to entry.]
3.8
business impact analysis
process of analysing the impact over time of a disruption on the organization
Note 1 to entry: The outcome is a statement and justification of business continuity requirements.
[SOURCE: ISO 22300:2021, 3.1.24]
3.9
code review
activity where one or more developers (3.18) establish the quality (3.35) of (part of) the source code
(3.41) by going through it
Note 1 to entry: There are a variety of ways to conduct code reviews which range from formal to very informal
and from discrete to continuous.
[SOURCE: NEN NPR 5326:2019, 3.10, modified — Modified definition and added note 1 to entry.]
3.10
configuration management database
CMDB
database that is used by an organization to store information about the hardware and software in use
[SOURCE: NEN NPR 5326:2019 3.11]
3
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC DTR 7052:2023(E)
3.11
consequence
outcome of an event (3.23) affecting objectives (3.30)
Note 1 to entry: An event can lead to a range of consequences.
Note 2 to entry: A consequence can be certain or uncertain and can have positive or negative effects on objectives.
Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.
Note 4 to entry: Initial consequences can escalate through knock-on effects.
[SOURCE: ISO Guide 73:2009, 3.6.1.3]
3.12
control
measure that is modifying risk (3.37)
Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.
Note 2 to entry: Controls cannot always exert the intended or assumed modifying effect.
[SOURCE: ISO Guide 73:2009, 3.8.1.1, modified — In note 2 to entry, changed “may not” to “cannot”.]
3.13
custom software
software product developed for a specific application from a user requirements specification
[SOURCE: ISO/IEC 25000:2014, 4.3]
3.14
data protection impact assessment
DPIA
tool described in the General Data Protection Regulation (3.27) (GDPR) to assess in advance the privacy
risks of data processing and then to be able to implement controls (3.12) to reduce the risks (3.37)
Note 1 to entry: See https:// gdpr .eu/ article 35 impact assessment/ .
[SOURCE: NEN NPR 5326:2019 3.12, modified — Changed “take measures” to “implement controls”.
Added note 1 to entry with link to the GDPR Article 35.]
3.15
deliverable
any unique and verifiable product, result, or capability to perform a service that must be produced to
complete a process, phase, or project
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1098, definition 1]
3.16
Delphi method
information-gathering technique used as a way to reach consensus of experts on a subject
Note 1 to entry: The Delphi method is applied as consensus tool for determining weights of indicators/sub-
indicators in this document.
Note 2 to entry: A facilitator uses a questionnaire to solicit ideas about the important project points related to the
subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus
can be reached in a few rounds of this process.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1102, modified — Restructured into definition and notes to
entry.]
4
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC DTR 7052:2023(E)
3.17
design thinking
methodology for solving (very complex) problems where these are defined from the human needs
Note 1 to entry: In design thinking solutions are determined with brainstorming sessions, where prototypes
(3.34) are produced to test the intended solution in practice.
[SOURCE: NEN NPR 5326:2019, 3.15]
3.18
developer
individual or organization that performs development activities (including requirements analysis,
design, testing through acceptance) during the system or software life-cycle process
Note 1 to entry: Activities of the developer of custom software (3.13) include setup and analysis of functional and
non-functional system and software requirements, design, programming and testing.
Note 2 to entry: Designers, programmers and testers are therefore all developers.
[SOURCE: ISO/IEC 25000:2014, 4.6. modified — Added notes to entry.]
3.19
development pipeline
build pipeline
set of tools aimed at the managed and controlled build of a package with which an application can be
taken into use
Note 1 to entry: As part of this various tests are carried out to determine and assess quality (3.35).
[SOURCE: NEN NPR 5326:2019, 3.30]
3.20
development team
team that develops and/or maintains software
Note 1 to entry: The acquirer (3.2), product owner (3.33) and future maintainer can form part of the development
team.
Note 2 to entry: Development teams can be broken down by function (e.g. a team of designers, a team of
programmers, a team of testers) or be multidisciplinary (each team has e.g. design, programming and test
expertise).
[SOURCE: NEN NPR 5326:2019, 3.31]
3.21
DevOps
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems products
and services, and continuous improvements in all aspects of the life cycle
[SOURCE: IEEE 26752021 3.1]
3.22
distributed denial of service attack
DDoS attack
unauthorized access to a system resource or the delaying of system operations and functions in the way
of compromising multiple systems to flood the bandwidth or resources of the targeted system, with
resultant loss of availability to authorized users
[SOURCE: ISO/IEC 27039:2015, 3.7]
5
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC DTR 7052:2023(E)
3.23
event
occurrence or change of a particular set of circumstances
Note 1 to entry: An event can be one or more occurrences and can have several causes.
Note 2 to entry: An event can consist of something not happening.
Note 3 to entry: An event can sometimes be referred to as an ‘incident’ or ‘accident’.
Note 4 to entry: An event without consequences (3.11) can also be referred to as a ‘near miss’, ‘accident’, ‘near hit’
or ‘close call’.
[SOURCE: ISO Guide 73:2009, 3.5.1.3]
3.24
extreme programming
XP
form of agile software development where procedures for iterative planning and working are combined
with technical procedures, such as testdriven design and pair programming
[SOURCE: NEN NPR 5326:2019, 3.20]
3.25
function point
FP
unit of measure for functional size
[SOURCE: ISO/IEC 20926:2009, 3.35, modified — removed “as defined within this International
Standard”.]
3.26
function point analysis
FPA
method for measuring functional size
[SOURCE: ISO/IEC 20926:2009, 3.36, modified — removed “as defined within this International
Standard”.]
3.27
General Data Protection Regulation
GDPR
European Regulation that standardizes the rules for processing personal data by private businesses
and government bodies in the whole European Union
Note 1 to entry: See https:// gdpr .eu.
[SOURCE: NEN NPR 5326:2019, 3.3]
3.28
integration testing
testing in which software components, hardware components, or both are combined and tested to
evaluate the interaction between them
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2034, modified — Removed note 1 to entry.]
6
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC DTR 7052:2023(E)
3.29
minimum viable product
MVP
version of a work product with just enough features and requirements to satisfy early customers and/
or provide feedback for future development
[SOURCE: IEEE 26752021, 3.1]
3.30
objective
predetermined result to be achieved
Note 1 to entry: To achieve an objective several tools and activities are generally needed, one of which can be
custom software (3.13).
[SOURCE: NEN NPR 5326:2019, 3.18]
3.31
performance test
test type conducted to evaluate the degree to which a test item accomplishes its designated functions
within given constraints of time and other resources
Note 1 to entry: A distinction is often made between load, stress and endurance tests. Load tests simulate a
normal load on the system. Stress tests allow the load to increase to determine the maximum load at which the
system still functions. Endurance tests load the system for a longer period in order to discover memory leaks or
other problems which only manifest themselves after some time.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.58, modified — Changed the term from "performance testing"
to "performance test"; changed "type of testing" to "test type"; added note 1 to entry.]
3.32
product breakdown structure
PBS
decomposition of the product into its components
Note 1 to entry: The PBS begins with the complete product at the top of the hierarchy and below this the main
components, which can also each be broken down again into components, etc.
[SOURCE: ISO 21511:2018, 3.7, modified — Added the abbreviated term and note 1 to entry.]
3.33
product owner
stakeholder (3.16) responsible for the capabilities, acceptance and use of a product
Note 1 to entry: The product owner shares the product vision, required features and their priorities, and
acceptance criteria.
[SOURCE: ISO/IEC TR 24587:2021, 3.12]
3.34
prototype
model or preliminary implementation suitable for evaluation of system design, performance, and
production potential, or for better understanding or determination of the requirements
[SOURCE: ISO/IEC 2382:2015, 2122670, modified — Removed notes to entry.]
3.35
quality
ability of a product, service, system, component, or process to meet customer or user needs,
expectations, or requirements
Note 1 to entry: For the quality of software and IT systems, ISO/IEC 25010 offers a breakdown into aspects, such
as:
7
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC DTR 7052:2023(E)
— reliability;
— security;
— usability;
— functional suitability;
— maintainability;
— portability;
— performance efficiency;
— compatibility.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3259, definition 2, modified — Adde
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.