ISO/IEC JTC 1/SC 7 - Software and systems engineering

This document specifies general concepts in software testing and presents key concepts for the ISO/IEC/IEEE 29119 series.

This document provides guidance for the maintenance of software, based on the maintenance process and its activities and tasks defined in ISO/IEC/IEEE 12207:2017, 6.4.13. Moreover, this document describes the maintenance process in greater detail and establishes definitions for the various types of maintenance. This includes maintenance for multiple software products with the same maintenance resources. “Maintenance” in this document means software maintenance unless otherwise stated. The document does not address the operation of software and the operational functions, e.g. backup, recovery, system administration, which are normally performed by those who operate the software. However, it does include the related disposal process defined in ISO/IEC/IEEE 12207:2017, 6.4.14. This document is written primarily for managers, maintenance organizations, quality managers, users and acquirers of systems containing software. Many of the activities and tasks discussed in this document apply equally to maintenance services, as well as to maintained software products. For example, in a COTS intensive system, maintenance services are performed to sustain the product in operations. While the scope of this document is software maintenance, hardware and hardware costs are important considerations for maintenance.

This document covers the development process for designers and developers of information for users of software. It describes how to establish what information users need, how to determine the way in which that information should be presented, and how to prepare the information and make it available. It is not limited to the design and development stage of the life cycle, but includes information on design throughout the life cycle, such as design strategy and maintaining a design. This document provides requirements for the structure, information content, and format of information for users of software. This document can be applied to developing the following types of information, although it does not cover all aspects of them: — information for users of products other than software; — multimedia systems using animation, video, and sound; — computer-based training (CBT) packages and specialized course materials intended primarily for use in formal training programs; — maintenance information describing the internal operation of systems software; — information for users incorporated into the user interface itself. This document is applicable to information architects and information developers, including a variety of specialists: — information architects who plan the structure and format of information products; — usability specialists and business analysts who identify the tasks that the intended users can perform with the software; — developers and editors of the written content of information for users; — graphic designers with expertise in electronic media; — user interface designers and ergonomics experts working together to design the presentation of the information on the screen. This document is also a reference for those with other roles and interests in the process of developing information for users: — managers of the software development process or the information-development process; — acquirers of information for users prepared by suppliers; — usability testers, reviewers of information for users, subject-matter experts; — developers of tools for creating information for users; — human-factors experts who identify principles for making information for users more accessible and easily used.

This document defines enrichments, extensions and structuring mechanisms of Petri nets, applied on the definitions proposed in ISO/IEC 15909-1. This document facilitates the definitions of new kinds of Petri nets and their interoperability, while remaining compatible with those defined in ISO/IEC 15909-1. This document is written as a reference for designers of new Petri net variants, by defining common enrichments, extensions and structuring mechanisms, as well as a generalized process for defining new ones. This document is applicable to a wide variety of concurrent discrete event systems and in particular distributed systems. Generic fields of application include: — requirements analysis; — development of specifications, designs and test suites; — descriptions of existing systems prior to re-engineering; — modelling business and software processes; — providing the semantics for concurrent languages; — simulation of systems to increase confidence; — formal analysis of the behaviour of systems; — and development of Petri net support tools. This document can be applied to the design of a broad range of systems and processes, including aerospace, air traffic control, avionics, banking, biological and chemical processes, business processes, communication protocols, computer hardware architectures, control systems, databases, defence command and control systems, distributed computing, electronic commerce, fault-tolerant systems, games, hospital procedures, information systems, Internet protocols and applications, legal processes, logistics, manufacturing systems, metabolic processes, music, nuclear power systems, operating systems, transport systems (including railway control), security systems, telecommunications and workflow.

This document defines test design techniques that can be used during the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2. Each technique follows the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2 and shown in Figure 1. This document is intended for, but not limited to, testers, test managers, and developers, particularly those responsible for managing and implementing software testing.

This document specifies test processes that can be used to govern, manage and implement software testing for any organization, project or testing activity. It comprises generic test process descriptions that define the software testing processes. Supporting informative diagrams describing the processes are also provided. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers and project managers, particularly those responsible for governing, managing and implementing software testing.

This document specifies software test documentation templates that can be used for any organization, project or testing activity. It describes the test documentation that is an output of the processes specified in ISO/IEC/IEEE 29119-2. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers, and project managers, particularly those responsible for governing, managing, and implementing software testing.

This document provides an overview of agile readiness factors that are likely to determine whether an organization, project, product or team is ready to start the transition to using an agile approach to their system and software development and maintenance activities. This document provides a general approach that is applicable to all agile methodologies and does not cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).

This document defines a method for the sizing of non-functional software requirements. It complements ISO/ IEC 20926:2009, which defines a method for the sizing of functional user requirements (FUR).1 This document also describes the complementarity of functional and non-functional sizes, so that sizing both functional and non-functional requirements (NFR) do not overlap. It also describes how non-functional size, together with functional size, should be used for measuring the performance of software projects, setting benchmarks, and estimating the cost and duration of software projects. In general, there are many types of non-functional software requirements. Moreover, non-functional aspects evolve over time and may include additional aspects in the as technology advances. This standard does not intend to define the type of NFR for a given context. Users may choose ISO 25010:2011 or any other standard for the definition of NFR. It is assumed that users will size the NFR based on the definitions they use. This document covers a subset of non-functional types. It is expected that, with time, the state of the art can improve and that potential future versions of this standard can define an extended coverage. The ultimate goal is a version that, together with ISO/IEC 20926:2009, covers every aspect that may be required of any prospective piece of software, including aspects such as process and project directives that are hard or impossible to trace to the software's algorithm or data. The combination of functional and non-functional size would then correspond to the total size necessary to bring the software into existence. Calculating the effort and duration of the implementation of the NFR is outside the scope of this standard.

This document elaborates requirements and recommendations for certifications schemes based on ISO/IEC 24773-1, which are specific to the domain of systems engineering.

This document provides guidance for the application of ISO/IEC/IEEE 29119 (all parts) in agile life cycles. This document is intended for (and not limited to) testers, test managers, business analysts, product owners, Scrum masters and developers involved in agile projects. The mappings provided in this document are designed to benefit any team or organization that is either moving away from traditional/waterfall life cycles and into agile or vice versa as well as new organizations that are commencing agile as their chosen life cycle. It is designed to be understandable regardless of the reader's familiarity with ISO/IEC/IEEE 29119 (all parts).

This document specifies requirements and provides guidance for certification bodies providing audit and certification of an ITAMS in accordance with ISO/IEC 19770-1. It does not change the requirements specified in ISO/IEC 19770-1. This document can also be used by accreditation bodies for the accreditation of certification bodies. However, this document does not specify requirements or provides guidance for accreditation bodies to audit certification bodies. A certification body providing ITAMS certification is expected to be able to demonstrate fulfilment of the requirements specified in this document, in addition to the requirements in ISO/IEC 17021-1.

This document provides guidance and recommendations for assurance of a selected claim about the system-of-interest by achieving the claim and showing the achievement. The guidance and recommendations are given in a system assurance process view on top of ISO/IEC/IEEE 15288 and a software assurance process view on top of ISO/IEC/IEEE 12207.

This document provides an explanation of considerations involved in defining a process. This document gives requirements and recommendations for the description of processes by identifying elements and rules for their formulation. This document also describes the use of process views. This document explains how conformance to a process can be defined, when the process is described in accordance with this document. This document does not describe how processes are composed or otherwise aggregated into larger frameworks or life cycle models. Nor does the document cover how to assess or evaluate the performance of a process, or the output (products) of a process. NOTE Two prominent International Standards in process description for software and system engineering are ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288. These two standards have very similar process models. The information items associated with their process definitions are given in ISO/IEC/IEEE 15289. Other International Standards provide further characterization of a single life cycle process by elaborating the process elements and levying specific requirements on the execution of the process. This document is applicable when processes are described for various process definitions in any party, organization or standard relating to systems and software engineering processes.

This document is a specialization of the more general reference model for software and systems product line engineering and management described in ISO/IEC 26550. The specialization defined herein addresses a class of methods and tools referred to as feature-based software and systems product line engineering, or feature-based PLE, which has emerged as a proven and repeatable product line engineering and management (PLE) practice supported by commercial tool providers. This document: — provides the terms and definitions specific to feature-based PLE; — defines how feature-based PLE is a specialization within the general ISO/IEC 26550 reference model for product line engineering and management; — defines a reference model for the overall structure and processes of feature-based PLE and describes how the elements of the reference model fit together; — defines interrelationships and methods for applying the elements and tools of the product line reference model; — defines required and supporting tool capabilities. In this document, products of feature-based PLE include digital work products that support the engineering of a system. Some of the artefacts are actually part of the delivered products, while other artefacts can be non-deliverable, such as physical or digital design models. The intended audience for this document comprises: — technology providers who wish to provide automated tool support for the reference model and processes described in this document; — champions within an organization who wish to introduce feature-based PLE throughout that organization; — IT staff within a PLE organization who will introduce and maintain the necessary technology to support feature-based PLE; — practitioner stakeholders who will use the provided technology to practice feature-based PLE; — technical and business managers who will sponsor and direct the methods necessary to practice feature-based PLE; — university professors, researchers, corporate trainers, and other educators who will create and share pedagogical materials about feature-based PLE and its benefits.

This document defines a process assessment model for software life cycle processes, conformant with the requirements of ISO/IEC 33004, for use in performing a conformant assessment in accordance with the requirements of ISO/IEC 33002.

This document provides a profile specification for the organizational management profile. The organizational management profile applies to VSEs involved in systems engineering and/or software engineering development. This document provides links to the subset of ISO/IEC/IEEE 12207 and ISO 9001 organizational, resources, processes and project portfolio process elements from the organizational perspective.

This document defines quality measures useful for requirements and evaluation of IT service quality in terms of characteristics and sub-characteristics defined in ISO/IEC TS 25011. This document contains a basic set of quality measures for each characteristic and sub-characteristic. This document does not assign ranges of values of the quality measures to rated levels or to grades of compliance. Such values are defined based on the nature of the IT service, and so depends on factors such as category of the IT service or users' needs. Some attributes can have a desirable range of values, which does not depend on specific user needs but generic factors, for example, service downtime. This document includes, in Annex A, considerations for the selection and application of quality measures. The quality measures in this document are primarily intended to be used for quality evaluation and improvement of IT services during or after the development life cycle. The main users of this document are people carrying out quality requirements specification and evaluation activities for IT services as part of the following: — development: including requirements analysis, design, implementation, testing and deployment during the development life cycle; — quality management: monitoring activities of quality assurance and performing quality control of an IT service; — supply: making a contract with the user for supplying an IT service under the terms of a contract; — acquisition: including IT service selection, when acquiring or procuring an IT service from a service provider; — maintenance: improvement of an IT service based on quality measurement. The relationship of this document to domain-specific IT service quality model and its precedence over this document is determined by the user in a specific context of use.

This document provides a framework for assessor training aimed at training providers who design, develop, and/or deliver training courses for assessors conducting assessments conformant with ISO/IEC 33002. The document defines four training course elements: — Foundation — Process assessment model — Assessor — Practical assessment performance Whilst the training is defined as separate training course elements, the elements can be combined into one or more training courses for delivery. Furthermore, training modules and learning objectives can be addressed in training courses in any combination or sequence.

This document: — provides risk management elaborations for the processes described in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, — provides the users of ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207 and their associated elaboration standards with common terminology and specialized guidance for performing risk management within the context of systems and software engineering projects, — specifies the required information items that are to be produced through the implementation of risk management process for claiming conformance, and — specifies the required contents of the information items. This document provides a universally applicable standard for practitioners responsible for managing risks associated with systems and software over their life cycle. This document is suitable for the management of all risks encountered in any organization or project appropriate to the systems or software projects regardless of context, type of industry, technologies utilized, or organizational structures involved. This document does not provide detailed information about risk management practices, techniques, or tools which are widely available in other publications. Instead this document focuses on providing a comprehensive reference for integrating the large and wide variety of processes, practices, techniques, and tools encountered in systems and software engineering projects and other lifecycle activities into a unified approach for risk management, with the purpose of providing effective and efficient risk management while meeting the expectations and requirements of organization and project stakeholders.

This document defines the capabilities of issue management tools and is used to select the most appropriate one from many issue management tools. The evaluation and selection of the issue management tools is performed in accordance with ISO/IEC 20741 which defines the general evaluation selection process and evaluation characteristics. Issue management is based on the tasks described in several activities in their processes (e.g. project assessment and control, decision management, and system/software requirements definition) of ISO/IEC/IEEE 12207. This document is independent of development methodology or approaches (e.g. Waterfall or Agile) or lifecycle processes (e.g. implementation or operation).

This document provides an introduction to AI-based systems. These systems are typically complex (e.g. deep neural nets), are sometimes based on big data, can be poorly specified and can be non-deterministic, which creates new challenges and opportunities for testing them. This document explains those characteristics which are specific to AI-based systems and explains the corresponding difficulties of specifying the acceptance criteria for such systems. This document presents the challenges of testing AI-based systems, the main challenge being the test oracle problem, whereby testers find it difficult to determine expected results for testing and therefore whether tests have passed or failed. It covers testing of these systems across the life cycle and gives guidelines on how AI-based systems in general can be tested using black-box approaches and introduces white-box testing specifically for neural networks. It describes options for the test environments and test scenarios used for testing AI-based systems. In this document an AI-based system is a system that includes at least one AI component.

This document is a guideline for the application of ISO/IEC/IEEE 12207:2017. This document establishes guidance to implement a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. This document provides guidance on defining, controlling, and improving software life cycle processes within an organization or a project. This document recommends methods and approaches suitable for a variety of life cycle models. The guidance emphasizes the importance of establishing a strategy, planning, and the involvement of stakeholders, with the ultimate goal of achieving customer satisfaction. This document applies to the acquisition, supply, design and development, transition, operation, maintenance, and disposal (whether performed internally or externally to an organization) of software systems, products, and services (including software as a service (SaaS)), and the software portion of any system. Software includes the software portion of firmware. The guidance on processes, activities, and tasks in this document can also be applied during the acquisition of a system that contains software. The guidance in this document can also be used as a basis for selecting, establishing, and improving organizational environments, e.g., methods, procedures, techniques, tools, and trained personnel. In the context of this document, there is a continuum of human-made systems from those that use little or no software to those in which software is the primary interest. It is rare to encounter a complex system without software, and all software systems require physical system components (hardware) to operate, either as part of the software system-of-interest (SoI) or as an enabling system or infrastructure. Thus, the choice of whether to apply this document for guidance to the software life cycle processes, or ISO/IEC/IEEE 24748-2, depends on the SoI. At a high level, both documents have the same life cycle process framework, but differ in guidance for activities and tasks to perform software engineering or systems engineering, respectively. The processes and process groups in this document are identical in their purpose and outcomes with those in ISO/IEC/IEEE 12207:2017 and in ISO/IEC/IEEE 15288:2015, with one exception: the System/Software Requirements Definition process of ISO/IEC/IEEE 12207:2017 and this document has a different name from the System Requirements Definition process of ISO/IEC/IEEE 15288:2015. Use of the guidance in this document is appropriate regardless of software system size or complexity or organizational size. The process outcomes from the ISO/IEC/IEEE 12207:2017 life cycle processes are meant to be generic and applicable to the engineering of any software system in any size organization. This document does not prescribe nor detail a specific software life cycle model, development methodology, method, modelling approach, or technique and method. The variety of ways for implementing software (e.g., development of new code, integration of existing open source components and commercial products, or modifications to existing software, including transition to new platforms) make it impossible to detail specific procedures. This document does not establish a management system or provide guidance on the use of any management system standard. However, it is intended to be compatible with the quality management system specified by ISO 9001, the service management system specified by ISO/IEC 20000-1, the IT asset management system specified by ISO/IEC 19770 (all parts), and the information security management system specified by ISO/IEC 27000. Clause 6 provides guidance on aspects of purposes, outcomes, activities, and tasks in ISO/IEC/IEEE 12207:2017. However, this document does not repeat the detailed requirements and recommendations for purposes, outcomes, activities, and tasks for each life cycle process found in ISO/IEC/IEEE 12207:2017. Clause 6 also pr

This document provides the mapping expressing corresponding relations between software life cycle processes in ISO/IEC/IEEE 12207:2017 and the processes in ISO/IEC 12207:2008. These relations are demonstrated by means of mapping tables that show relationships between activities and tasks, and process outcomes. This mapping assists users of ISO/IEC 12207:2008 to transition to using ISO/IEC/IEEE 12207:2017. This document will help users understand the differences between the reference processes and requirements of the two editions of ISO/IEC/IEEE 12207, and any potential gaps or process enhancements that can be needed in seeking conformance to and/or using ISO/IEC/IEEE 12207:2017. Also, this document provides to such users the mapping which helps to identify corresponding process outcomes, activities and tasks of processes for software systems in ISO/IEC/IEEE 12207:2017. The mapping between ISO/IEC/IEEE 12207:2017 and ISO/IEC 12207:2008 in this document can be used as a basis to continuously conduct, improve and extend current process assets including software specific process assets based on ISO/IEC 12207:2008 for effective implementation of ISO/IEC/IEEE 12207:2017. These process activities and tasks can be applied iteratively.

This document specifies the capabilities of a tool to support review work. The evaluation and selection of the review tools are performed in accordance with ISO/IEC 20741 which defines the general evaluation selection process and evaluation characteristics. This document defines capabilities specific to review tools in the process. By using these two standards together, it is possible to derive objective and reasonable results of the evaluation and selection of review tools. The review work is based on the process, activities, and tasks defined in ISO/IEC 20246. It is also assumed that the review targets are defined in ISO/IEC 20246. The review work in this document is assumed not to be performed by a 3rd party, but within a project. The review tool capabilities specified in this document harmonize with the review process defined in ISO/IEC 20246. This document does not include automated process, activities, or tasks for conducting reviews such as automated source code checkers defined in ISO/IEC 30130. Issues which are identified in the review are recorded and managed by the tool; but defects found in tests and issues found in general except for reviews are out of the scope of this document.

This document specifies requirements for the vendors and gives guidelines for both the users and the developers of software safety and security verification tools. The users of such tools include, but are not limited to, bodies performing verification and software developers who need to be aware and pay attention to safety and/or security of software. This document guides the verification tool vendors to provide as high-quality products as possible and helps the users to understand the capabilities and characteristics of verification tools. This document introduces use cases for software safety and security verification tools and entity relationship model related to them. This document also introduces tool categories for software safety and security verification tools and gives category specific guidance and requirements for the tool vendors and developers.

This document defines a process reference model for the domain of service management. The model specifies a process architecture for the domain and comprises a set of processes. Each process is described in terms of process purpose and outcomes. The process reference model in this document is directed at assessment sponsors and competent assessors who wish to select a model, and associated documented process method, for assessment (for either capability determination or process improvement).

This document: — defines a process assessment model that relies on the process reference model published as ISO/IEC TS 33054 that meets the requirements of ISO/IEC 33004 and that supports the performance of an assessment by providing indicators for guidance on the interpretation of the process purposes and outcomes and the process attributes as defined in ISO/IEC 33020; — provides guidance, by example, on the definition, selection and use of assessment indicators. A process assessment model comprises a set of indicators of process performance and process capability. The indicators are used as a basis for collecting the objective evidence that enables an assessor to assign ratings. The set of indicators included in this document is not intended to be an all-inclusive set. The process assessment model in this document is directed at assessment sponsors and competent assessors who wish to select a model, and associated documented process method, for assessment (for either capability determination or process improvement). Additionally, it can be of use to developers of assessment models in the construction of their own model, by providing examples of good service management practices. It can be used by: a) service providers to assess and improve a service management system (SMS); b) service providers to demonstrate their capability for the planning, design, development, transition and delivery of services that meet agreed service management requirements. Any process assessment model meeting the requirements defined in ISO/IEC 33004 concerning models for process assessment can be used for assessment. Different models and methods can be needed to address differing business needs. The assessment model in ISO/IEC TS 33074 is provided as an assessment model meeting all the requirements expressed in ISO/IEC 33004.

This document defines the process assessment guidelines needed to meet the purpose of defined VSE profiles. It is applicable to all VSE profiles and is compatible with ISO/IEC 33002. The possible uses of this document are as follows. a) Assessment to evaluate the process capabilities. Use when an organization wants an assessment of profile conformance (basic, etc.) of the implemented processes. b) Supplier's capability assessment. Use when a customer asks for a third party to conduct an assessment in order to obtain a profile (basic, etc.) of the implemented process by the system or software development and maintenance supplier.

This document defines a process assessment model for system life cycle processes, conformant with the requirements of ISO/IEC 33004, for use in performing a conformant assessment in accordance with the requirements of ISO/IEC 33002.

This document defines requirements, guidelines, formats and approaches for use when producing a mapping document that defines how industry practices map to/from the ISO/IEC 19770 series. This edition is focused solely on mappings to/from both the second edition of ISO/IEC 19770-1 that was published in 2012, or the third edition of ISO/IEC 19770-1 that was published in 2017. However, the title of this document is deliberately more general as it is expected that future editions of this document also include mapping frameworks related to other parts of the ISO/IEC 19770 series. In this document where reference is made to ISO/IEC 19770-1 without the specification of an edition number or a publication year, then the text applies to all editions of ISO/IEC 19770-1.

1.1 Purpose This document is intended to aid project managers in managing to successful conclusion those projects concerned with systems, including software systems. This document specifies the required content of the project management plan (PMP). This document also quotes the extracted purpose and outcome statements from the technical management processes of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, and adds detailed guidance for managing projects that use these processes for systems, including software systems. 1.2 Field of application This document is written for those who use or plan to use ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 on projects dealing with systems, including software systems, regardless of project scope, products, methodology, size or complexity. The field of application of this document spans the whole system or software life cycle and addresses all project management roles, specifically: — those responsible for establishing and continuously improving their organization's policies for implementing ISO/IEC/IEEE 15288 system life cycle processes and ISO/IEC/IEEE 12207 software life cycle processes; — those responsible for executing any ISO/IEC/IEEE 15288 system life cycle process or ISO/IEC/IEEE 12207 software life cycle process at a project level. — organizations or individuals subcontracting a project management effort. In many organizations, the various responsibilities of project management are assigned to more than one person. Where the term "project manager" is used in this document, the guidance, advice or normative requirement is taken as applying to the applicable role within the organization. This document is intended to provide guidance for two-party situations and can be equally applied where the two parties are from the same organization. This document can also be used by a single party as self-imposed tasks. This document can also serve as guidance in multi-party situations, where high risks are inherent in the supply and integration of complex software-based systems, and procurement can involve several vendors, organizations or contracting parties. 1.3 Limitations The normative content specifications for PMPs and the guidance for application of the technical management processes have general application across the scope of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, but are developed with a focus on projects dealing with systems with a significant software element, and software systems.

This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of systems (SoS). The scope of this document is the same as ISO/IEC/IEEE 15288, which addresses more than systems engineering activities. NOTE 1 Throughout the document, there is mixed use of "system of systems" and "systems of systems". "SoS" could refer to a system of systems or systems of systems. Similarly, "CS" could refer to a constituent system or constituent systems. This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes and process outcomes unique to SoS can still be needed and are not covered by this document. This document explores the similarities and differences between systems and SoS and, by extension, the similarities and differences between engineering of systems and SoS. The guidance contained in this document is expected to evolve as the discipline matures. NOTE 2 In many cases, this document notes that ISO/IEC/IEEE 15288 processes or process outcomes "? applies as stated to SoS." Some interpretation within the context of SoS can still be needed.

This document defines a process reference model for the domain of quality management. The model specifies a process architecture for the domain and comprises a set of processes. Each process is described in terms of process purpose and outcomes. NOTE Users of this document can freely reproduce the detailed descriptions contained in this process reference model as part of any tool or other material to support the performance of process assessments, so that it can be used for its intended purpose.

This document, within the context of methods and tools for supporting the diagnosis of the organization's capability to adopt or improve software and systems product line engineering: — defines processes for product line technical probe; those processes are described in terms of purpose, inputs, tasks and outcomes; — defines method capabilities to support the defined tasks of each process; and — defines tool capabilities that automate or semi-automate tasks and methods. This document does not concern processes and capabilities of tools and methods for a single system but rather deals with those for a family of products.

This document, within the context of methods and tools for supporting the transitioning the organization's current development approach to software and systems product line engineering: — defines processes for product line transition management. Those processes are described in terms of purpose, inputs, tasks and outcomes; — defines method capabilities to support the defined tasks of each process; — defines tool capabilities that automate or semi-automate tasks and methods. This document does not concern processes and capabilities of tools and methods for a single system but rather deals with those for a family of products.

This document defines a process measurement framework that supports the assessment of process capability, in accordance with the requirements of ISO/IEC 33003. The process measurement framework provides a schema that can be used to construct a process assessment model conformant with ISO/IEC 33004 which can be used in the performance of assessment of process capability according to the requirements of ISO/IEC 33002. In the context of this document and related standards, process capability is a process quality characteristic related to the ability of a process to consistently meet current or projected business goals. The process measurement framework defined in this document forms a structure which a) facilitates self-assessment, b) provides a basis for use in process improvement and process quality determination, c) is applicable across all application domains and sizes of organization, d) produces a set of process (capability) attribute ratings (process profile), and e) derives a process capability level. This document also includes as informative annexes a set of assessment indicators of process capability that can be used in the construction of a process assessment model using this process measurement framework, and guidance on the meaning of the process capability levels and the achievement of the process attributes.

1.1 Fields of application This document provides management and engineering guidance within the Intermediate profile for the Business Management, Project Management, System Definition and Realisation and Acquisition Management processes. This document is applicable to Very Small Entities (VSEs). VSEs are enterprises, organisations, departments or projects having up to 25 people. The lifecycle processes described in the ISO/IEC 29110 series are not intended to preclude or discourage their use by organisations bigger than VSEs. This document has been developed using the management and engineering guide from the systems engineering Basic profile. Elements were added or modified (e.g. process, task, work product, role) to support VSEs involved in the development of more than one project in parallel with more than one work team. This guide is oriented towards the management of more than one project in parallel with more than one work team. This document applies for the development of non-critical systems. Using this document, a VSE can obtain benefits in the following aspects: — An agreed set of project requirements (technical part of contract) and expected work products are agreed by the Acquirer. — A disciplined management process, that provides project visibility and corrective actions of project problems and deviations, is performed. — A systematic System Definition and Realisation process, that satisfies Acquirer needs and helps ensure quality work products, is followed. Once the system, developed by a VSE, has been accepted by their customers, the VSE that wants to provide after delivery services can refer to ISO/IEC TR 29110-5-3. In the context of systems engineering, that is the System Definition and Realisation (SR) process, the group that is part of the VSE responsible for developing software elements that are part of the system are encouraged to use the management and engineering guide of the software engineering Intermediate profile (ISO/IEC TR 29110-5-1-3). 1.2 Target audience This document is targeted at VSEs that do not develop critical systems and have little or no experience with systems engineering (SE) process planning and implementation using ISO/IEC/IEEE 15288. This document is also targeted to VSEs which are familiar with management and engineering guide of the systems engineering Basic profile (ISO/IEC TR 29110 5-6-2) for their system development projects and are involved in the development of more than one project in parallel with more than one work team. This document is intended to be used with any processes, techniques and methods that enhance the VSE's Stakeholder satisfaction and productivity.

This document provides guidance on the relationship between ISO/IEC 16350:2015 and a commonly used application management framework, ASL. It can be used by any organization or person wishing to understand how ASL can be used with ISO/IEC 16350:2015, including: a) an internal or external application management organization that has demonstrated or intends to demonstrate conformity to the requirements specified in ISO/IEC 16350:2015 and is seeking guidance on the use of ASL to establish and improve an AMS and the processes; b) an application management organization that already uses ASL and is seeking guidance on how ASL can be used to support efforts to demonstrate conformity to the requirements specified in ISO/IEC 16350:2015; c) an assessor or auditor who wishes to understand the use of ASL as support to achieve the requirements specified in ISO/IEC 16350:2015. The correlations provided in this document relate to the 2nd version of ASL® (ASL2). Clause 4 describes how ASL® can support the demonstration of conformity to ISO/IEC 16350:2015. Clause 5 relates chapters in ASL® to clauses in ISO/IEC 16350:2015.

This document provides the framework for quality requirements for systems, software products and data, which includes concept of the quality requirements, and requirements and recommendations for the processes and methods to elicit, define, use and govern them. Intended readers of this document include, but are not limited to: — acquirers: evaluate if the system/software products/data fulfills their value proposition, i.e., meets the expected quality, — developers: design, implement and test the system/software products/data to ensure that it meets the expected quality, — testers: verify and validate that the system/software products/data meets the expected quality, — project managers: plan, monitor and control the achievement of the expected quality, and — independent evaluators: evaluate the system/software products/data with the objective criteria. This document complies with the technical processes defined in ISO/IEC/IEEE 15288, which are relevant for elicitation of stakeholders' quality needs and for defining, analyzing and maintaining quality requirements. In this document, the quality models in ISO/IEC 25010 and ISO/IEC 25012 are used to categorize quality requirements and to provide a basis for quantifying them in terms of quality measures in the quality measure division of ISO/IEC 2502n. This document does not cover specification of the other requirements (such as functional requirements, process requirements, etc.), and prescribes neither any specific quality measure nor any specific development process.

This document defines a Petri net modeling language or technique, called high-level Petri nets, including its syntax and semantics. It provides a reference definition that can be used both within and between organizations, to ensure a common understanding of the technique and of the specifications written using the technique. This document also facilitates the development and interoperability of Petri net computer support tools. This document is applicable to a wide variety of concurrent discrete event systems and in particular distributed systems. Generic fields of application include: — requirements analysis; — development of specifications, designs and test suites; — descriptions of existing systems prior to re-engineering; — modeling business and software processes; — providing the semantics for concurrent languages; — simulation of systems to increase confidence; — formal analysis of the behavior of systems; — and development of Petri net support tools. This document can be applied to the design of a broad range of systems and processes, including aerospace, air traffic control, avionics, banking, biological and chemical processes, business processes, communication protocols, computer hardware architectures, control systems, databases, defense command and control systems, distributed computing, electronic commerce, fault-tolerant systems, games, hospital procedures, information systems, Internet protocols and applications, legal processes, logistics, manufacturing systems, metabolic processes, music, nuclear power systems, operating systems, transport systems (including railway control), security systems, telecommunications and workflows.

This document provides guidance on the application of the results of a process assessment for process risk determination. The guidance provided does not presume specific organizational structures, management philosophies, life cycle models or development methods. In relation to process risk determination, this guidance is applicable within any customer?supplier relationship, and to any organization wishing to perform a process risk determination of its processes.

This document specifies the means to organize and record architecture evaluations for enterprise, systems and software fields of application. The aim of this document is to enable architecture evaluations that are used to: a) validate that architectures address the concerns of stakeholders; b) assess the quality of architectures with respect to their intended purpose; c) assess the value of architectures to their stakeholders; d) determine whether architecture entities address their intended purpose; e) provide knowledge and information about architecture entities; f) assess progress towards achieving architecture objectives; g) clarify understanding of problem space and of stakeholder needs and expectations; h) identify risks and opportunities associated with architectures; and i) support decision making where architectures are involved. NOTE This document addresses the evaluation of an architecture and not an evaluation of the architecture description's suitability. Matters concerning the evaluation of the architecture description fall within the scope of the architecture conceptualization and architecture elaboration processes as defined in ISO/IEC/IEEE 42020. However, it is sometimes the case that the architecture description is evaluated concurrently with the evaluation of the architecture itself. The entity being evaluated can be of several kinds, as illustrated in the following examples: enterprise, organization, solution, system, subsystem, business, data (as a data element or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, etc. The kind of entity can also be a product line, family of systems, system of systems, etc. It also spans the variety of applications that utilize digital technology such as mobile, cloud, big data, robotics, Internet of Things (IoT), web, desktop, embedded systems, and so on. The generic Architecture Evaluation (AE) framework specified in this document can be used in support of the Architecture Evaluation process defined in ISO/IEC/IEEE 42020. Specific frameworks can be derived from this generic framework, which can provide a mapping to the system life cycle processes in ISO/IEC/IEEE 15288 or to the software life cycle processes in ISO/IEC/IEEE 12207.

1.1 Purpose This document provides a set of critical system of systems (SoS) considerations to be addressed at key points in the life cycle of the system of interest (SoI). This document refers to considerations that apply to an SoI that is a constituent system that interacts in an SoS. The considerations and life cycle model align with those which are already defined in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 24748-1. Selected subsets of these considerations can be applied throughout the life of systems through the involvement of stakeholders. The ultimate goal is to achieve customer satisfaction, so that when delivered, the SoI will operate effectively in the operational or business environment which is typically characterized as one or more systems of systems. This document concerns those systems that are man-made and are configured with one or more of the following: hardware, software, humans, procedures and facilities. 1.2 Field of application This document addresses SoS considerations that apply to systems at each stage of their respective life cycles. There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty, adaptability, quantities, locations, life spans and evolution. This document is concerned with describing the system of systems considerations that apply to a system that is the SoI; that is a constituent system within a system of systems. It applies to one-of-a-kind systems, mass produced systems or customized, adaptable systems. 1.3 Limitations This document does not detail the approach to addressing system of systems considerations in terms of methods or procedures. This document does not detail the described documentation in terms of name, format, explicit content and recording media of documentation.

This document establishes a set of process descriptions for the governance and management of a collection of architectures and the architecting of entities. This document also establishes an enablement process description that provides support to these other architecture processes. The processes defined in this document are applicable for a single project, as well as for an organization performing multiple projects. These processes are applicable throughout the life of an architecture or a collection of architectures. These processes are applicable for managing and performing the activities within any stage in the life cycle of the architecture entities. Annex D describes the relationships between this document and other standards.

This document defines a normalized taxonomy for systems of systems (SoS) to facilitate communications among stakeholders. It also briefly explains what a taxonomy is and how it applies to the SoS to aid in understanding and communication.

This document specifies the purpose and content of all identified systems and software life‐cycle and service management information items (documentation). The information item contents are defined according to generic document types, as presented in Clause 7, and the specific purpose of the document, as presented in Clause 10. This document assumes an organization is performing life‐cycle processes, or delivering system or software engineering services, using either or both of the following: — ISO/IEC/IEEE 12207:2017 software life cycle processes; — ISO/IEC/IEEE 15288:2015 system life cycle processes. ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 define an Information Management process, but do not "detail information items in terms of name, format, explicit content, and recording media" (ISO/IEC/IEEE 12207:2017, 1.4). These standards identify, recommend or require a number of documentation items. This document provides a mapping of processes from the above standards to a set of information items. It provides a consistent approach to meeting the information and documentation requirements of systems and software engineering and engineering service management. The generic document types defined in this document are used to identify the information necessary to support the processes required by ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015. The generic document types (which can be referred to as information item types) are used to identify the information necessary to support the processes. For each life‐cycle process or service, it would be possible to prepare a policy, plan, procedures and reports, as well as numerous records, requests, descriptions and specifications. Such an elaboration of the documentation schema would be more rigorous than specified by ISO/IEC/IEEE 12207:2017 or ISO/IEC/IEEE 15288:2015. As ISO/IEC/IEEE 15288:2015, 1.4 points out, "The users of this document are responsible for selecting a life cycle model for the project and mapping the processes, activities, and tasks in this document into that model. The parties are also responsible for selecting and applying appropriate methodologies, methods, models and techniques suitable for the project." Thus, information items are combined or subdivided consistent with the life cycle model, as needed for project or organizational purposes, as further defined in Clause 4 and Clause 5. This document is not a management system standard and does not establish a service management system, quality management system, or asset management system. The scope of this document does not include the following: a) the format or content of recommended input data or input information items, except for the content of those input items that are also output information items; b) instructions on combining or subdividing information items and information item contents of a similar nature; c) guidance on selecting an appropriate presentation format, delivery media and maintenance technology for systems or software life‐cycle data, records, information items or documentation, such as electronic publishing systems, content management systems or data repositories; NOTE ISO/IEC/IEEE 26531 provides requirements for content management and component content management systems. ISO/IEC 26514 provides guidance on formats for user documentation (information for users). d) detailed content for information items related to general business, contractual, organizational and financial management that is not specific to systems and software engineering and engineering service management, such as business strategies, contract change notices (agreement change report), human resources and investment policies, personnel selection criteria, financial budgeting and accounting policies and procedures, cost reports, or payroll data; e) information items showing only approval of an ISO/IEC/IEEE 12207:2017 or ISO/IEC/IEEE 15288:2015 subclause, such as ISO/IEC/IEEE 12207:2017, 6.4.10.3 c) 3

This document provides a framework for developing quality measurement. The contents of this document are as follows: — quality measurement reference model; — relationships among different types of quality measures; — guidelines for selecting quality measures; — guidelines for constructing quality measures; — guidelines for planning and performing measurements; — guidelines for the application of measurement results. It includes considerations for selecting quality measures and quality measure elements (Annex A), assessing the reliability of measurement and the validity of quality measures (Annex B), elements for documenting quality measures (Annex C), normalized measurement function for quality measures (Annex D) and the measurement information model in ISO/IEC/IEEE 15939 (Annex E). This document can be applied for designing, identifying, evaluating and executing the measurement model of system and software product quality, quality in use, data quality and IT service quality. This reference model can be used by developers, acquirers, quality assurance staff and independent evaluators—essentially by people responsible for specifying and evaluating the quality of information and communication technology (ICT) systems and services.

This document provides general and specific guidance for the competency of assessors performing assessments in accordance with the ISO/IEC 330xx family of standards.