ISO/IEC TR 24774:2010
(Main)Systems and software engineering — Life cycle management — Guidelines for process description
Systems and software engineering — Life cycle management — Guidelines for process description
An increasing number of international, national and industry standards describe process models. These models are developed for a range of purposes including process implementation and assessment. The terms and descriptions used in such models vary in format, content and level of prescription. ISO/IEC TR 24774:2010 presents guidelines for the elements used most frequently in describing a process: the title, purpose, outcomes, activities, task and information item. Whilst the primary purpose of ISO/IEC TR 24774:2010 is to encourage consistency in standard process reference models, the guidelines it provides can be applied to any process model developed for any purpose.
Ingénierie du logiciel et des systèmes — Gestion du cycle de vie — Lignes directrices pour la description des processus
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
24774
Second edition
2010-09-15
Systems and software engineering — Life
cycle management — Guidelines for
process description
Ingénierie du logiciel et des systèmes — Gestion du cycle de vie —
Lignes directrices pour la description des processus
Reference number
ISO/IEC TR 24774:2010(E)
©
ISO/IEC 2010
---------------------- Page: 1 ----------------------
ISO/IEC TR 24774:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 24774:2010(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Terms and definitions .1
3 Characterizing the elements.3
3.1 Introduction.3
3.2 The title element .4
3.3 The purpose element .4
3.4 The outcomes element.5
3.5 The activities element .7
3.6 The task element .7
3.7 The information item element .8
3.8 Use of notes .9
4 Using process views.9
4.1 Introduction.9
4.2 The process view concept.9
4.3 Process viewpoint.10
4.4 Process view.10
Annex A (informative) Example process description.11
A.1 Introduction.11
A.2 Disposal process.11
A.2.1 Purpose.11
A.2.2 Outcomes.11
A.2.3 Activities and tasks .11
Annex B (informative) Example process view .13
B.1 Introduction.13
B.2 Specialty engineering process view.13
B.2.1 Purpose.13
B.2.2 Outcomes.13
B.2.3 Processes, activities and tasks .14
Bibliography.15
© ISO/IEC 2010 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 24774:2010(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report
of one of the following types:
⎯ type 1, when the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts;
⎯ type 2, when the subject is still under technical development or where for any other reason there is the
future but not immediate possibility of an agreement on an International Standard;
⎯ type 3, when the joint technical committee has collected data of a different kind from that which is
normally published as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether
they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to
be reviewed until the data they provide are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 24774, which is a Technical Report of type [1/2/3], was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering.
This second edition cancels and replaces the first edition (ISO/IEC TR 24774:2007), which has been
technically revised.
iv © ISO/IEC 2010 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 24774:2010(E)
Introduction
For an organization to function effectively, it has to determine and manage numerous linked activities. An
activity or set of activities using resources, and managed in order to enable the transformation of inputs into
outputs, can be considered a process. Often the output from one process forms the input to the next.
A number of international, national and industry standards describe process reference models. The process
descriptions used in such models vary in format, content and level of prescription. The purpose of this
Technical Report is to encourage uniformity in the description of processes. Uniform description of processes
across process reference models allows the combination of processes from different reference models, eases
the development of new models and facilitates comparison of models.
In order for future standards and revisions of current standards to select the appropriate forms of process
description and apply them in a consistent fashion, it is desirable to develop a common characterization of all
of these forms of process description. This Technical Report presents guidelines for the description of
processes in terms of their format, content and level of prescription.
Within the International Standards arena the definition of life cycle processes for systems and software falls
within the scope of ISO/IEC JTC 1/SC 7/WG 7. The existing International Standards in this area are
ISO/IEC 12207, Software life cycle processes, and ISO/IEC 15288, System life cycle processes. The
information items associated with these process definitions are given in ISO/IEC 15289, Content of systems
and software life cycle process information products (Documentation). Other International Standards, such as
ISO/IEC 15939, Measurement process, and ISO/IEC 16085, Risk management, provide further
characterization of a single life cycle process by elaborating the process elements and levying specific
requirements on the execution of the process. The decomposition is described by use of the activity element.
When instantiated for an organization or project, other details are added (entrance/exit criteria, actors,
artefacts).
The assessment of process capability falls within the scope of ISO/IEC JTC 1/SC 7/WG 10. The existing
International Standard in this area is ISO/IEC 15504-2, Process assessment – Performing an assessment. It
provides requirements for assessing the capability of processes defined in external process models;
processes can be assessed providing there is a description of them in terms of Title, Purpose, and Outcomes
and the description satisfies the criteria for a “process reference model” as stated in ISO/IEC 15504-2. In
addition to the elements described in this Technical Report, ISO/IEC 15504 defines and uses the element
Assessment Indicator. An assessment indicator is a source of objective evidence used to support an
assessor's judgement in rating process elements. Examples include work products, practices and resources.
ISO/IEC JTC 1/SC 7/WG 19 covers the fields of Open Distributed Processing and Modelling Languages. The
International Standards developed in that working group provide notations that might be useful in detailed
process description for other purposes.
The guidelines in this Technical Report are those applied in ISO/IEC JTC 1/SC 7. They align with those used
in ISO/TC 176 (the committee responsible for ISO 9001). The guidelines can be applied to any process model
developed for any purpose. The guidelines have been made publicly available as a Technical Report with the
intention of establishing a uniform description of processes across all process models, from all sources, for all
purposes.
The intended audience for this Technical Report is the editors, working group members, reviewers and other
participants in the development of process standards and technical reports. It is intended that they will select
the process description elements suitable for their project from those described in this Technical Report. It is
further intended that, having selected the appropriate elements, users of this Technical Report will apply them
in a manner consistent with the guidance provided by this Technical Report.
This Technical Report is also intended for use by all parties that define process models, for example other
international standards groups, national standards, sector or special interest groups, professional standards
groups, researchers, process assessors. These process models can be for the purpose of process definition,
implementation or assessment.
© ISO/IEC 2010 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 24774:2010(E)
Systems and software engineering — Life cycle management —
Guidelines for process description
1 Scope
This Technical Report provides guidelines for the description of processes by identifying descriptive elements
and rules for their formulation. It characterizes the following elements of process description:
⎯ Title;
⎯ Purpose;
⎯ Outcomes;
⎯ Activities;
⎯ Tasks;
⎯ Information items.
In addition process views are described.
It does not describe how processes are composed or otherwise aggregated into larger frameworks or
architectures.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
activity
set of cohesive tasks of a process
[ISO/IEC 15288:2008]
2.2
information item
separately identifiable body of information that is produced and stored for human use during a system or
software life cycle
[ISO/IEC 15289:2006]
2.3
life cycle
evolution of a system, product, service, project or other human-made entity from conception through
retirement
[ISO/IEC 15288:2008]
© ISO/IEC 2010 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC TR 24774:2010(E)
2.4
life cycle model
framework of processes and activities concerned with the life cycle that may be organized into stages, which
also acts as a common reference for communication and understanding
[ISO/IEC 15288:2008]
2.5
process
set of interrelated or interacting activities which transforms inputs into outputs
[ISO 9000:2005]
2.6
process purpose
high level objective of performing the process and the likely outcomes of effective implementation of the
process
NOTE The implementation of the process should provide tangible benefits to the stakeholders.
[ISO/IEC 12207:2008]
2.7
process outcome
observable result of the successful achievement of the process purpose
[ISO/IEC 12207:2008]
2.8
product
result of a process
[ISO 9000:2005]
2.9
system
combination of interacting elements organized to achieve one or more stated purposes
[ISO/IEC 15288:2008]
2.10
task
requirement, recommendation, or permissible action, intended to contribute to the achievement of one or more
outcomes of a process
[ISO/IEC 15288:2008]
2.11
view
representation of a whole system from the perspective of a related set of concerns
[ISO/IEC 42010:2007, IEEE Std 1471-2000]
NOTE In standards being developed in ISO/IEC JTC 1/SC 7, the "system" (system of processes) referenced in the
definition is the collection of system and software life cycle processes provided by ISO/IEC 15288 and ISO/IEC 12207.
2.12
viewpoint
specification of the conventions for constructing and using a view
[ISO/IEC 42010:2007, IEEE Std 1471-2000]
2 © ISO/IEC 2010 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 24774:2010(E)
NOTE 1 A viewpoint is a pattern or template from which to develop individual views by establishing the purposes and
audiences for a view, and the techniques for its creation and analysis.
NOTE 2 For a detailed explanation of view and viewpoint and how they can be defined and used, see ISO/IEC 42010,
Recommended practice for architectural description of software-intensive systems.
3 Characterizing the elements
3.1 Introduction
To enable uniform description additional characterization of the elements is helpful. The remainder of this
Technical Report provides that characterization.
This Technical Report describes the following process elements:
⎯ The title is a descriptive heading for a process;
⎯ The purpose describes the goal of performing the process;
⎯ The outcomes express the observable results expected from the successful performance of the process;
⎯ The activities are a list of actions that may be used to achieve the outcomes. Each activity may be further
elaborated as a grouping of related lower level actions;
⎯ The tasks are specific actions that may be performed to achieve an activity. Multiple related tasks are
often grouped within an activity;
⎯ The information items are separately identifiable bodies of information produced and stored for human
use during a system or software life cycle.
To prevent confusion and to encourage consistency the use of alternative terms for these elements is strongly
discouraged.
Figure 1 is a UML representation, adapted from Figure C.1 of ISO/IEC 15288:2008, depicting the relationships
among the elements of a process as discussed in this International Technical Report.
NOTE A process view has the same component entities.
Annex A presents an example of a process described using the guidelines in this Technical Report.
© ISO/IEC 2010 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC TR 24774:2010(E)
0.*
Process
Name, Purpose,
Outcome(s)
1 11
1.*
Activity
Name
0.*
1
0.*
Information item
Task
Name
Figure 1 — UML representation of the component entities of a process
Not all elements need to be treated in all standards. Some standards will treat only process Title, Purpose,
and Outcomes, for example, leaving the activities for further elaboration by other standards.
The goals and objectives of performing a process can be described by using the elements of Title, Purpose,
and Outcomes. These elements are used to describe intended results without the necessity of performing
structural decomposition of the process. Processes defined using Title, Purpose, and Outcomes provide a
common starting point for process implementation and process assessment.
NOTE The distinction between a process and a procedure is a simple one. A procedure is a set of steps to be
followed that, when completed, might or might not achieve the intended objective. This is similar to following a recipe when
cooking. On the other hand, a process is executed with knowledge of the intended purpose and outcomes to achieve the
desired result.
3.2 The title element
The title of a process description is a short noun phrase that presents a descriptive heading for the process.
The title identifies the principle concern of the process and distinguishes the process from other processes in
the model. Because of the latter criterion, it may sometimes be necessary to change the title of a process. For
example, one might have a "software design process" which is later renamed as a "software detailed design
process" to distinguish it from a newly-invented "software architectural design process".
NOTE 1 Process descriptions may be used both to describe generic objects of a particular type (for example "project
management process"), and to describe a particular instance of a generic type (for example "project management process
for project A"). For a process model or a standard the type description is sufficient, but in other cases (for example project
planning) generic process types are instantiated with respect to resources and time. When both generic types and
particular instances are described, in order to differentiate between the two a typographical convention may be adopted
(for example the title of the specific instance may be set in italic font).
NOTE 2 The intent is to give a title not a summary. Noun-verb or verb-noun phrases lead to an attempt to summarise
the purpose or process so that the title can stand for the purpose. This is often misleading. A descriptive noun phrase - the
name of the process - is less open to misinterpretation and the temptation to let it stand in for the purpose.
3.3 The purpose element
The purpose of the process is stated as a high level, overall goal for performing the process. In cases where
processes might be thought to overlap, the purpose should be used to characterize the scope or bounds of
the process.
Whenever possible, the purpose should be succinctly captured in a single sentence. Summarizing the
activities or outcomes of the process in the purpose statement should be avoided. Use of the conjunction
"and" to connect multiple clauses should be avoided as it would indicate that the description is being written
4 © ISO/IEC 2010 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 24774:2010(E)
as an aggregation of marginally-related outcomes rather than as a statement of a single purpose. The
purpose element shall begin with the words, "The purpose of the xxx process is … ". The phrase, "in order to"
may be useful in recording the objective of the process.
If any further explanation of the purpose of a process is desirable, it should be placed in informative Notes.
3.4 The outcomes element
An outcome is an observable result of the successful achievement of the process purpose. Outcomes are
measurable, tangible, technical or business results that are achieved by a process, for example the results
that are used by other processes. Outcomes are observable and assessable.
Outcomes should be differentiated from benefits, which are positive achievements from the execution of a
process, often spread broadly across the business and not necessarily related to the technical or business
intent of executing a process. Benefits are not usually assessable, or at least not assessable using process
assessment approaches. A benefit might provide the motivation to execute a process, but it might not be the
primary reason to do so. Benefits may be described in an informative note to the purpose statement.
a) The list of outcomes associated with a process shall be prefaced by the text, "As a result of successful
implementation of this process.".
b) An outcome shall be phrased as a declarative sentence using a verb in the present tense. For example, if
the preceding sentence was phrased as an outcome, it might read, "Outcomes are phrased as
declarative sentences using verbs in the present tense." Typically, the verb is "is" or "are" although others
may be used when appropriate.
c) Outcomes should be expressed in terms of a positive, observable objective, e.g. the production of an
artefact, the provision of a service, a significant change of state, the successful maintenance of a desired
state (e.g. safety), or the meeting of specified constraints (such as requirements, goals, etc).
d) Outcome statements should be no longer than two lines of text, about twenty words.
e) The number of outcomes for a process should fall within the range 3 to 7.
f) Although an outcome should express an observable result, it is not necessary to express the outcome as
the production of a document, record of other item of information.
g) An outcome should express a single result. Hence, the use of the word "and" or "and/or" to conjoin
clauses should be avoided; such constructions are better expressed as multiple outcomes.
h) Outcomes should be written so that it should not require the implementation of a process at any capability
level higher than 1 to achieve all of the outcomes, considered as a group.
NOTE 1 Capability levels are defined in ISO/IEC 15504-2, Process assessment – Performing an assessment, as
points on the six-point ordinal scale of process capability that represents the capability of the process; each level
builds on the capability of the level below.
NOTE 2 In some cases (for example when the process goals and requirements are set by other standards, such
as ISO/IEC 20000) the process outcomes cannot cover all of the process requirements and remain at level 1. In
these cases the higher level outcomes can be indicated (for example by placement in a separate list, or in notes, or
described in an annex) such that it is possible to identify and exclude or otherwise account for these outcomes in
process assessments.
i) Outcomes should be written in a manner that is meaningful for any scope of applicability, e.g., for
organizations of any relevant domain or size.
j) Outcomes should avoid requiring any specific method, technique or tool.
k) Outcomes should avoid requiring any specific process measures or management methods.
© ISO/IEC 2010 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC TR 24774:2010(E)
l) Outcomes should avoid presuming any particular sequence of execution and the reader should not be
expected to presume any sequence.
m) There is no need to make a one-to-correspondence between outcomes and activities; in particular, it is
not necessary to specify an activity for every outcome of a process or an outcome for every activity. The
desired relationship is that the execution of the activities, considered as a group, should produce the set
of outcomes, considered as a group.
n) Although outcomes should be meaningful and understandable when viewed in isolation, they should be
based on terminology and concepts that are further explained by other material in the document.
o) As a test of completeness, the set of outcomes should be sufficient to achieve the stated purpose of the
process.
p) As a test of relevancy, each outcome should be phrased so that it is necessary to the achievement of the
purpose of the process.
A before-and-after example of applying these guidelines is shown in Figure 2.
This description of a Supplier monitoring
process is taken from
PDAM1 of
Purpose:
ISO/IEC 12207:1995
The purpose of Supplier monitoring is to track and assess performance of the
supplier against agreed requirements.
Outcomes:
⎯ joint activities between customer and supplier shall be performed as
needed;
⎯ information on technical progress shall be exchanged regularly with the
supplier;
⎯ performance of the supplier shall be monitored against the agreed
requirements.
Supplier Monitoring
Applying these rules,
the statement could
be improved as Purpose:
shown here.
The purpose of Supplier Monitoring is to keep up communication with the
supplier in order to maintain visibility of progress, risks and commitments.
Outcomes:
As a result of successful implementation of this process:
⎯ Joint activities between customer and supplier are performed.
⎯ Information on technical progress is exchanged regularly with the supplier.
⎯ Performance of the supplier is monitored against the agreed requirements.
Figure 2 — Example of application of the guidelines for drafting of outcomes
6 © ISO/IEC 2010 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 24774:2010(E)
3.5 The activities element
Rather than describing the results of executing a process, activities describe a set of actions that might be
undertaken to execute the process.
Activities are constructs for grouping together related tasks (see below). The activities provide a means to look
at related tasks within the process to improve understanding and communication of the process. If an activity
is cohesive enough, it can be converted to a lower-level process by defining a purpose and a set of outcomes.
NOTE Decompositions of more than three levels of process are likely to be confusing and hard to use.
The set of lower-level processes and activities associated with a process should "cover" the process. In other
words, the set of lower-level processes and activities should, when considered as a group, address the
achievement of all process outcomes and the satisfaction of the purpose of the process. Alternatively stated,
any action falling within the scope of a process must fall within the scope of one of the lower-level processes
or activities of the process.
Ide
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.