ISO/IEC/IEEE 24774:2021 pdf download – Systems and software engineering — Life cycle management — Specification for process description.
There is no fixed dividing line between what constitutes a process and what is considered as a sub- process or an activity within a process. Typically, processes are achieved through the performance of activities comprising groups of related tasks. A significant activity of interest with numerous tasks can also be described as a process if it were useful to treat the activity of interest in detail. The limits of a process generally are determined by the production of a major output and outcomes, rather than the intermediate outputs produced by activities within the process. Additionally, if processes are highly automated and require little human control or intervention, it can be appropriate to combine several processes into one process description. NOTE 1 Often a set of processes are developed; and some processes are decomposed into more than one level. However, decomposition of processes into more than three levels is likely to be confusing and hard for humans to use. Procedures differ from process descriptions in that procedures are written in steps to be followed in order. Procedures can be written as instructions to the persons performing the procedure. Procedures can also be written to assist an evaluator or auditor to understand the procedure, especially its controls or outputs. NOTE 2 ISO/IEC/IEEE 82079-1 provides detailed requirements for writing instructions. Required activities are stated in process descriptions using either the imperative (as a command), or as a ‘shall’ statement. NOTE 3 Annex A shows different examples of the expression of mandatory/required process elements as used in sample process descriptions. Complete processes generally involve several types of generic activities (Table 1).
Generally, several software or systems engineering processes are performed concurrently during a life cycle stage. However, concurrent activities (e.g. installation and quality assurance inspections) are not necessarily part of the same process, since their purpose, resources, methods, outputs, and outcomes are different. Process descriptions may be used either to describe generic processes (for example “project management process”) or to describe a particular instance of a generic type (for example “project management process for project A”). For specific process descriptions, generic process descriptions may be instantiated with respect to roles or responsibilities, resources, required inputs and outputs, constraints and controls, and time. Annex A provides examples of process descriptions used to develop a process model. Annex B provides a technique for demonstration of process traceability between elements, using an example process from Annex A. Processes are often combined to form a process model (framework of related processes). ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, for example, provide life cycle process reference models for systems and software in which outcomes are defined and activities grouped for generic life cycle process description. Based on ISO/IEC/IEEE 15288:2015, Annex A and ISO/IEC/IEEE 12207:2017, Annex A, organizations or projects can apply process tailoring to suit the nature of the effort.