ISO/IEC 29110-5-1-2:2025

International
Standard
ISO/IEC
29110-5-1-2
First edition
Systems and software
2025-02
engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-1-2:
Software engineering guidelines for
the generic Basic profile
Reference number
© ISO/IEC 2025
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
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 1
3  Terms and definitions . 1
4  Naming, diagramming and definitions conventions . 8
4.1 General .8
4.2 Naming, diagramming and definition conventions .8
4.3 Abbreviated terms .10
5 Overview .11
5.1 General .11
5.2 Entry conditions to use the software Basic profile .11
5.3 Processes and activities of the software Basic profile .11
6 Project management (PM) process .12
6.1 PM process purpose . 12
6.2 PM process outcomes . 12
6.3 PM roles involved . 13
6.4 PM activities and tasks. 13
6.4.1 Overview of the PM process . 13
6.4.2 PM activities .14
6.4.3 Incorporation to project repository . 22
7 Software implementation (SI) process .22
7.1 SI process purpose . 22
7.2 SI process outcomes . 23
7.3 SI Roles involved . 23
7.4 SI activities and tasks . 23
7.4.1 Overview of the SI process . 23
7.4.2 SI activities .24
7.4.3 Incorporation to the project repository . 35
8 Description of roles .36
9 Description of work products .37
10 Software tools .51
10.1 General .51
10.2 Project management process tools.51
10.3 Software implementation process tools .51
Annex A (informative)  Support process for the software Basic profile .53
Annex B (informative)  Additional testing tasks to the software Basic profile .62
Annex C (informative)  Accessibility tasks to the software Basic profile . 74
Annex D (informative)  Security addition for the software engineering Basic profile .82
Annex E (informative)  Deployment packages for the software Basic profile .90
Bibliography .92

© ISO/IEC 2025 – All rights reserved
iii
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.
This first edition replaces the ISO/IEC TR 29110-5-1-2:2011, which has been technically revised.
The main changes are as follows:
— Many task statements have been reworded to facilitate their understanding.
— Conditional tasks have been added to develop optional work products (e.g. operation guide) that have
been requested by a customer. This notation replaces the ‘Optional’ notation [e.g. *(optional)] used in the
TR that caused ambiguities.
— Terms have been added to Clause 3 such that this document is self-contained.
— A few terms have been modified to align this document with the updated version of standards such as
the ISO/IEC/IEEE 12207 and the ISO/IEC/IEEE 15289.
— Texts have been added for giving additional information intended to assist the understanding or use of
the text of the document.
— Annex A has been added to describe a process, which can be added to the software Basic profile, to
enable VSEs to support the software product which they developed.
— Annex B has been added to describe a set of tasks which can be added to the software Basic profile for
VSEs with the aim to better support software testing.
— Annex C has been added to describe a set of tasks, which can be added to the software Basic profile, to
enable VSEs to add accessibility tasks to the software implementation process.
— Annex D has been added to describe a set of tasks which can be added to the Basic profile to integrate
security related tasks.
© ISO/IEC 2025 – All rights reserved
iv
A list of all parts in the ISO/IEC 29110 series can be found on the ISO and IEC websites.
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.

© ISO/IEC 2025 – All rights reserved
v
Introduction
0.1  Introduction to the ISO/IEC 29110 series
For the purpose of the ISO/IEC 29110 series, a very small entity VSE is an enterprise, organization (e.g.
government agency, non-profit organization), department or project having up to 25 people. Many VSEs
develop and/or maintain systems and the software components used in those systems, either as independent
products or incorporated into the larger system. Due to this, a recognition of VSEs as suppliers of high-
quality products is required.
VSEs around the world are creating valuable products and services. According to the World Bank, small and
medium enterprises (SMEs) account for about 90 % of enterprises worldwide. According to the Organisation
for Economic Co-operation and Development (OECD), SMEs represent 99 % of all businesses and generate
about 60 % of employment. Almost one person out of three is employed in a micro firm with less than 10
employees. The European Union reports that micro firms, with fewer than 10 persons, account for 93,5 % of
all enterprises and small firms, with 10 to 49 employees, account for 5,5 % of all enterprises. The challenge
facing OECD governments is to provide a business environment that supports the competitiveness of this
large heterogeneous business population and that promotes a vibrant entrepreneurial culture.
From studies and surveys conducted, it is clear that the majority of International Standards do not address
the needs of VSEs. Implementation of and conformity with these standards is difficult, if not impossible.
Consequently, VSEs have no, or very limited, ways to be recognized as entities that produce quality systems/
system elements including software in their domain. Therefore, VSEs are excluded from some economic
activities.
It has been found that VSEs find it difficult to relate International Standards to their business needs and
to justify the effort required to apply standards to their business practices. Most VSEs can neither afford
the resources, in terms of number of employees, expertise, budget and time, nor do they see a net benefit in
establishing over-complex systems or software life cycle processes. To address some of these difficulties,
a set of guidelines has been developed based on a set of VSE characteristics. The guidelines are based on
subsets of appropriate standards processes, activities, tasks, and outcomes, referred to as Profiles. The
purpose of a profile is to define a subset of International Standards relevant to the VSEs' context; for example,
processes, activities, tasks, and outcomes of ISO/IEC/IEEE 12207 for software; and processes, activities,
tasks, and outcomes of ISO/IEC/IEEE 15288 for systems; and information products (documentation) of
ISO/IEC/IEEE 15289 for software and systems.
VSEs can achieve recognition through implementing a profile and by being audited against ISO/IEC 29110
specifications.
The ISO/IEC 29110 series can be applied at any phase of system or software development within a life
cycle. The ISO/IEC 29110 series is intended to be used by VSEs that do not have experience or expertise in
adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 standards to the needs of a specific project.
VSEs that have expertise in adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 are encouraged
to use those standards instead of the ISO/IEC 29110 series.
The ISO/IEC 29110 series is intended to be used with any life cycle, such as waterfall, iterative, incremental,
evolutionary or agile.
Systems, in the context of the ISO/IEC 29110 series, are typically composed of hardware and software
components.
The ISO/IEC 29110 series, targeted by audience, has been developed to improve system or software and/
or service quality, and process performance. Figure 1 describes the ISO/IEC 29110 series and positions the
parts within the framework of reference.

© ISO/IEC 2025 – All rights reserved
vi
Figure 1 — The ISO/IEC 29110 series
ISO/IEC 29110-1-1 introduces processes, life cycle and standardization concepts, the taxonomy (catalogue) of
ISO/IEC 29110 profiles and the ISO/IEC 29110 series. ISO/IEC 29110-1-1 also introduces the characteristics
and needs of a VSE, and clarifies the rationale for specific profiles, documents, standards and guidelines.
ISO/IEC 29110-1-2 defines the terms common to the ISO/IEC 29110 series. ISO/IEC 29110-1-1 and
ISO/IEC 29110-1-2 are targeted at VSEs and their customers, assessors, standards producers, tool vendors
and methodology vendors.
ISO/IEC 29110-2 introduces the concepts for systems and software engineering profiles for VSEs. It
establishes the logic behind the definition and application of profiles. For standardized profiles, it specifies
the elements common to all profiles (structure, requirements, conformity, and assessment). For domain-
specific profiles (profiles that are not standardized and developed outside of the ISO process), it provides
general guidance adapted from the definition of standardized profiles. ISO/IEC 29110-2 is targeted at profile
producers, tool vendors and methodology vendors.
ISO/IEC 29110-3 defines certification schemes, assessment guidelines and compliance requirements for
process capability assessment, conformity assessments, and self-assessments for process improvements.
ISO/IEC 29110-3 also contains information that can be useful to developers of certification and assessment
methods and developers of certification and assessment tools. ISO/IEC 29110-3 is addressed to people
who have direct involvement with the assessment process, for example, the auditor, certification and
accreditation bodies and the sponsor of the audit, who need guidance on ensuring that the requirements
for performing an audit have been met. ISO/IEC 29110-3 is targeted at VSEs and their customers, assessors,
accreditation bodies.
ISO/IEC 29110-4 provides the specifications for all generic profiles of the Generic profile group that are
based on subsets of appropriate standards elements. ISO/IEC 29110-4 is targeted at VSEs, customers,
standards producers, tool vendors and methodology vendors.

© ISO/IEC 2025 – All rights reserved
vii
ISO/IEC TR 29110-5 provides a management, engineering and service delivery guidelines for profiles of the
Generic profile group. ISO/IEC 29110-5 is targeted at VSEs and their customers.
ISO/IEC 29110-6 provides the specifications for Specific profiles that are based on subsets of appropriate
standards elements. ISO/IEC 29110-6 is targeted at VSEs, customers, standards producers, tool vendors and
methodology vendors.
ISO/IEC 29110-7 provides a guideline for each profile of the specific profile group. ISO/IEC 29110-7 is
targeted at VSEs and their customers.
If a new profile is needed, ISO/IEC 29110-4, ISO/IEC 29110-6, ISO/IEC 29110-7 or ISO/IEC 29110-5, or all, can
be developed with minimal impact to existing documents.
Since a VSE may be an enterprise, a project or a department of an organization, a customer of a VSE can be
internal or external to the organization.
0.2  Introduction to this document
This document is the second software profile of a four-profile software engineering roadmap (i.e. Entry,
Basic, Intermediate and Advanced).
This document is intended to be used by VSEs to support the software product which they developed.
This document is intended to be used by VSEs to add accessibility tasks to the software implementation
process.
This document is intended to be used with any processes, techniques and methods that enhance the VSE's
customer satisfaction and productivity.
The life cycle processes described in the ISO/IEC 29110 series are not intended to preclude or discourage
their use by organizations larger than VSEs.
Using this document, a VSE can obtain the following benefits:
— an agreed set of project requirements and expected work products is delivered to the customer;
— a disciplined management process that provides project visibility and corrective actions of project
problems and deviations is performed;
— a systematic software implementation process that satisfies customer needs and ensures quality work
products is followed.
VSEs that develop systems that have software components are invited to use the systems engineering Basic
profile guideline of the ISO/IEC 29110 series (i.e. ISO/IEC 29110-5-6-2).
In this document, Annex A describes a process, which can be added to the Basic profile, to enable a VSE to
support the software product which they developed. Annex B adds a set of tasks, one role and several work
products to the software Basic profile for a VSE with the aim to better support software testing. Annex C
describes a set of additional tasks for a VSE that should add accessibility to a software product. Annex D
integrates security-related tasks and work products in the Basic profile for software engineering. Annex E
describes the deployment packages for the software Basic profile.
Conformity requirements for implementations of this document can be found in ISO/IEC 29110-4-1.

© ISO/IEC 2025 – All rights reserved
viii
International Standard ISO/IEC 29110-5-1-2:2025(en)
Systems and software engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-1-2:
Software engineering guidelines for the generic Basic profile
1 Scope
This document provides management and engineering guidelines to the software Basic profile specified in
ISO/IEC 29110-4-1 through project management and software implementation processes.
This document applies to VSEs that do not develop safety-critical software.
This document applies for software development projects, which can fulfil an external or internal agreement.
This document is applicable to VSEs developing a single product by a single work team.
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 testing
testing (3.47) conducted to determine whether a system satisfies its acceptance criteria and to enable the
customer (3.10) to determine whether to accept the system
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.34]
3.2
accessibility
extent to which products, systems, services, environments and facilities can be used by people from a
population with the widest range of characteristics and capabilities to achieve a specified goal in a specified
context of use
3.3
activity
set of cohesive tasks (3.41) of a process (3.18)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.3]

© ISO/IEC 2025 – All rights reserved
3.4
adaptive strategies
techniques that people with disabilities use to improve interaction with the web
EXAMPLE Increasing the font size in a common browser.
[SOURCE: W3C Web Accessibility Initiative – Planning and Policies – Involving Users]
3.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.5]
3.6
assistive technology
equipment, product system, hardware, software or service that is used to increase, maintain or improve
capabilities of individuals
Note 1 to entry: Assistive technology is an umbrella term that is broader than assistive products.
Note 2 to entry: Assistive technology can include assistive services, and professional services needed for assessment,
recommendation and provision.
[SOURCE: ISO/IEC GUIDE 71:2014, 2.16]
3.7
baseline
formally approved version of a configuration item, regardless of media, formally designated and fixed at a
specific time during the configuration item’s life cycle
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.11]
3.8
Basic profile
profile (3.21) targeted at VSEs (3.52) developing a single product by a single work team
[SOURCE: ISO/IEC 29110-1-2:2024, 4.14]
3.9
conditional task
task (3.37) that can be mandatory under some specified condition(s), can be optional under other specified
conditions, and can be out of scope or not applicable under other specified conditions
Note 1 to entry: These are to be observed if the specified condition(s) apply.
3.10
customer
person or organization that could or does receive a product or a service that is intended for or required by
this person or organization
EXAMPLE Consumer, client, end-user, retailer, receiver of product or service from an internal process (3.18),
beneficiary and purchaser.
Note 1 to entry: A customer can be internal or external to the organization.
[SOURCE: ISO 9000:2015, 3.2.4]

© ISO/IEC 2025 – All rights reserved
3.11
defect
imperfection or deficiency in a work product (3.53) where that work product does not meet its requirements
(3.26) or specifications and needs to be either repaired or replaced
[SOURCE: IEEE 1044:2009]
3.12
deployment package
DP
set of artefacts developed to facilitate the implementation of a set of practices, of the selected framework, in
a very small entity (3.52)
[SOURCE: ISO/IEC 29110-1-2:2024, 3.35]
3.13
expected result
observable predicted behaviour of the test item (3.43) under specified conditions based on its specification
or another source
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.35]
3.14
generic profile group
profile (3.21) group applicable to VSEs (very small entities) (3.52) that do not develop safety-critical systems
or software products (3.32) and have typical situational factors
[SOURCE: ISO/IEC 29110-1-2:2024, 4.28]
3.15
incident
unplanned interruption to a service, a reduction in the quality of a service or an event that has not yet
impacted the service to the customer (3.10) or user
[SOURCE: ISO/IEC 20000-10:2018, 3.2.5]
3.16
integration testing
testing (3.47) in which software components, hardware components, or both are combined and tested to
evaluate the interaction among them
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2034, modified — Note 1 to entry has been removed.]
3.17
persona
representation of a type of user that includes a concise summary of the characteristics and the behaviour of
the user that is most informative to the design or illustrative of specific user requirements (3.26)
[SOURCE: ISO/IEC 25063:2014, modified — Note 1 to entry has been removed.]
3.18
process
set of interrelated or interacting activities (3.3) that transforms inputs into outputs
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.33]
3.19
process purpose
high-level objective of performing the process (3.18) and the likely outcomes of effective implementation of
the process
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.12]

© ISO/IEC 2025 – All rights reserved
3.20
process outcome
observable result of the successful achievement of the process (3.18)
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.11]
3.21
profile
subset of appropriate standards’ processes (3.18) and their outcomes, activities (3.3) and tasks (3.37)
combined to accomplish a particular function
Note 1 to entry: The base standards used to develop profiles for VSEs (3.52) are the ISO/IEC/IEEE 12207, the
ISO/IEC/IEEE 15288 and the ISO/IEC/IEEE 15289
[SOURCE: ISO/IEC 29110-1-2:2024, 3.70]
3.22
project
endeavour with defined start and finish dates undertaken to create a product or service in accordance with
specified resources and requirements (3.26)
Note 1 to entry: A project is sometimes viewed as a unique process (3.18) comprising coordinated and controlled
activities (3.3) and composed of activities from the technical management processes and technical processes defined
in this document.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.37]
3.23
report
information item that describes the results of activities (3.3) such as investigations, observations,
assessments, or tests
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.22]
3.24
review
process (3.18) or meeting during which a work product (3.53), or set of work products, is presented to project
(3.22) personnel, managers, users, customers (3.10), or other interested parties for comment or approval
[SOURCE: ISO/IEC 29110-1-2:2024, 4.51]
3.25
risk
effect of uncertainty on objectives
Note 1 to entry: An effect is a deviation from the expected — positive and/or negative.
Note 2 to entry: Objectives can have different aspects (such as financial, health and safety, and environmental goals)
and can apply at different levels (such as strategic, organization-wide, project (3.22), product and process (3.18)).
Note 3 to entry: Risk is often characterized by reference to potential events and consequences, or a combination of these.
Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes
in circumstances) and the associated likelihood of occurrence.
Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or
knowledge of, an event, its consequence, or likelihood.
[SOURCE: ISO 31073:2022, 3.1.1]

© ISO/IEC 2025 – All rights reserved
3.26
requirement
statement that translates or expresses a need and its associated constraints and conditions
Note 1 to entry: A constraint is externally imposed limitation on the software, its design, or implementation or on the
process (3.18) used to develop or modify a software.
Note 2 to entry: A condition is a measurable qualitative or quantitative attribute that is stipulated for a requirement
and that indicates a circumstance or event under which a requirement applies.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.44, modified — Notes to entry have been added.]
3.27
safety-critical software
software whose failure or malfunction can result in death or serious injury to people, loss of or severe
damage to equipment or property, or damage to the natural environment
3.28
security
protection against intentional subversion or forced failure, containing a composite of four attributes:
confidentiality, integrity, availability, and accountability, plus aspects of a fifth, usability, all of which have
the related issue of their assurance
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.49]
3.29
security control
safeguard or countermeasure prescribed for an information system or an organization, designed to protect
the confidentiality, integrity, and availability of its information and to meet a set of defined security (3.28)
requirements (3.26)
[SOURCE: IEEE 7002:2022, 3, IEEE dictionary]
3.30
service level agreement
SLA
documented agreement (3.5) between the organization and the customer (3.10) that identifies services and
their agreed performance
Note 1 to entry: A service level agreement can also be established between the organization and an external supplier,
an internal supplier or a customer acting as supplier.
Note 2 to entry: A service level agreement can be included in a contract or another type of documented agreement.
[SOURCE: ISO/IEC 20000-10:2018, 3.2.20]
3.31
small and medium enterprise
SME
enterprise with less than 250 persons employed
[SOURCE: ISO/IEC 29110-1-2:2024, 3.92]
3.32
software product
set of computer programs, procedures, and possibly associated documentation and data
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.54, modified — Note 1 to entry has been removed.]
3.33
software support
continued provision of services and material necessary for the use and improvement of an implemented system

© ISO/IEC 2025 – All rights reserved
3.34
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.59, modified — EXAMPLE and note 1 to entry have been removed.]
3.35
system testing
testing (3.47) conducted on a complete, integrated system to evaluate the system's compliance with its
specified requirements (3.26)
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4122]
3.36
support manager
role responsible for production support in the VSE (3.52) who oversees customer (3.10) relationships and
change management within production environments
3.37
task
required, recommended, or permissible action, intended to contribute to the achievement of one or more
outcomes of a process (3.18)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.66]
3.38
test condition
testable aspect of a component or system, such as a function, transaction, feature, quality attribute, or
structural element identified as a basis for testing (3.47)
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.88, modified — Note 1 to entry has been removed.]
3.39
test data
data created or selected to satisfy the input requirements (3.26) for executing one or more test cases
Note 1 to entry: Test data can be stored within the test item (3.43) (e.g. in arrays or flat files), or can come from external
sources, such as other systems, hardware devices, or human operators.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.91]
3.40
test design technique
test technique
procedure used to create or select a test model, identify test coverage items, and derive corresponding test cases
EXAMPLE Equivalence partitioning, boundary value analysis, decision table testing (3.47), branch testing.
Note 1 to entry: The test design technique is typically used to achieve a required level of test coverage.
Note 2 to entry: Some test practices, such as exploratory testing or model-based testing are sometimes referred to as
“test techniques”. Following the definition in the ISO/IEC/IEEE 29119 series, they are not test design techniques as
they are not themselves providing a way to create test cases, but instead use test design techniques to achieve that.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.94]
3.41
test environment
environment containing facilities, hardware, software, firmware, procedures, needed to conduct a test
Note 1 to entry: A test environment can contain multiple environments to accommodate specific test level or test
types (e.g. a unit test environment, a performance test environment).

© ISO/IEC 2025 – All rights reserved
Note 2 to entry: A test environment can comprise several interconnected systems or virtual environments.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.95]
3.42
test execution
process (3.18) of running a test on the test item (3.43), producing actual result(s)
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.99]
3.43
test item
test object
work product (3.53) to be tested
EXAMPLE Software component, system, requirements document, design specification, user guide.
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.107]
3.44
test plan
detailed description of test objectives to be achieved and the means and schedule for achieving them,
organized to coordinate testing (3.47) activities (3.3) for some test item (3.43) or set of test items
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.117, modified — Notes to entry have been removed.]
3.45
test sub-process
test management and dynamic (and static) test process (3.18) used to perform a specific test level [e.g. system
testing (3.35), acceptance testing (3.1)] or test type (e.g. usability testing, performance testing) normally
within the context of an overall test process for a test project (3.22)
3.46
test result
indication of whether or not a specific test case has passed or failed, i.e. if the actual result corresponds to
the expected result (3.13) or if deviations were observed
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.122]
3.47
testing
set of activities (3.3) conducted to facilitate discovery and evaluation of properties of one or more test items (3.43)
[SOURCE: ISO/IEC/IEEE 29119-1:2022, 3.131, modified — "one or more" has been added; note 1 to entry has
been removed.]
3.48
traceability
degree to which a relationship can be established among two or more logical entities, especially entities
having a predecessor-successor or master-subordinate relationship to one another, such as requirements
(3.26), system elements, verifications (3.50), or tasks (3.37)
EXAMPLE Software features and test cases are typically traced to software requirements.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.69]
3.49
validation
confirmation, through the provision of objective evidence, that the requirements (3.26) for a specific intended
use or application have been fulfilled
Note 1 to entry: A system is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder (3.34)
requirements) in the intended operational environment. The right system was built.

© ISO/IEC 2025 – All rights reserved
Note 2 to entry: In a life cycle context, validation involves the set of activities (3.3) for gaining confidence that a system
is able to accomplish its intended use, goals and objectives in an environment like the operational environment.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.71]
3.50
verification
confirmation, through the provision of objective evidence, that specified requirements (3.26) have been
fulfilled
Note 1 to entry: Verification is a set of activities (3.3) that compares a system or system element against the required
characteristics. This includes, but is not limited to specified requirements, design, descriptions, and the system itself.
The system was built right.
[SOURCE: ISO 9000:2015, 3.8.12, modified — Notes 1 to 3 to entry have been replaced by a new note 1 to entry.]
3.51
version control
establishment and maintenance of baselines (3.7) and the identification and control of changes to baselines
that make it possible to return to the previous baseline
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.40]
3.52
very small entity
VSE
enterprise, organization (e.g. government agency, non-profit organization), department or project (3.22)
having up to 25 people
[SOURCE: ISO/IEC 29110-1-2:2024, 4.71, modified — "(e.g. government agency, non-profit organization)" has
been added.]
3.53
work product
WP
artefact produced by a process (3.18)
EXAMPLE Project (3.22) plan, requirements (3.26) specification, design documentation, source code, test plan
(3.44), test meeting minutes, schedules, budgets, and incident (3.15) reports (3.23).
Note 1 to entry: A subset of the work products can be baselined to be used as the basis of further work and some form
the set of project deliverables.
[SOURCE: ISO/IEC 20246:2017, 3.20]
4  Naming, diagramming and definitions conventions
4.1 General
Conventions for naming, diagramming, describing and defining profiles are defined in ISO/IEC 29110-2-1:2015.
4.2  Naming, diagramming and definition conventions
The following process structure description and notation are used to describe the processes.
Process name – process identifier, followed by its abbreviation in parenthesis “( )”.
Process purpose – high level objective of performing the process and the likely outcomes of effective
implementation of the process.

© ISO/IEC 2025 – All rights reserved
Process outcomes – observable result of the successful achievement of the process purpose. Outcomes are
identified by the abbreviation of the process name, followed by the letter “O” and a consecutive number, for
example PM.O1, SI.O2.
Input work products – Work products (WP) which can be used to perform the process and its corresponding
source, which can be another process or an external entity to the project, such as the customer. They are
identified by the abbreviation of the process name.
Output work products – Work products generated by the process and its corresponding destination, which
can be another process or an external entity to the project, such as customer. They are identified by the
abbreviation of the process name.
Internal work products – Work products generated (i.e. output work product) and consumed (i.e. input work
product) by the process. An internal work product is not reviewed or approved by the customer.
All work products’ names initiate with capital letters. Some work products should have one or more statuses
attached to the work product name surrounded by square brackets “[ ]” and separated by ”,”. The work
product state may change during the process execution. See Clause 9 for the alphabetical list of the work
products, its descriptions, possible states and the source of the work product. The source can be another
process or an external entity to the project, such as the customer.
Roles involved – Names and abbreviation of the functions to be performed by project team members. Several
roles may be played by a single person and one role may be assumed by several persons. Roles are assigned to
project participants based on the characteristics of the project. The role list is identified by the abbreviation
of the process name and showed as two column table. See Clause 8 for the alphabetical list of the roles and
recommended competencies description.
Diagram – Graphical representation of the processes. The large round-edged rectangles indicate process
or activities, and the smaller square-edged rectangles indicate the work products. The directional or
bidirectional thick arrows indicate the major flow of information between processes or activities. The thin
directional or bidirectional arrows indicate the input or output work products. The notation used in the
diagrams does not imply the use of any specific process life cycle.
Activity – A set of cohesive tasks of a process. The task statements in this document are not imperative. A
process activity is the first level of process workflow decomposition, and the second one is a task. Activities
are identified by process name abbreviation followed by consecutive number and the activity name.
Activity description – Each activity description is identified by the activity name and the list of related
process outcomes surrounded by parenthesis “( )”. For example, PM.01 project planning (PM.O1, PM.O5,
PM.O6, PM.O7) means that the activity PM.01 project planning contributes to the achievement of the listed
objectives: PM.O1, PM.O5, PM.O6 and PM.O7.
Task description – Each task description begins with an active verb (e.g. assign, test) and is followed by
an object (e.g. review the project plan). To facilitate their implementation, a few tasks are broken down in
elementary tasks. The task description doesn’t impose any technique or method to perform it. The selec
...