< Previous | Contents | Next >
work product
artifact resulting from the execution of a process
[Sevocab]
Both terms are used in different context in an assessment:
Information items are defining relevant pieces of information used by the assessors to judge the achievement of process attributes.
work product are produced by the organization assessed when performing, managing, establishing, analyzing and innovating processes.
Information items (together with their characteristics) are provided as guidance for “what to look for” when examining the work products available in the assessed organization. The extent of implementation of an information item (inline with its defined characteristics) in a related work product serves as objective evidence supporting the assessment of a particular process. A documented process and assessor judgment is needed to ensure that the process context (application domain, business purpose, development methodology, size of the organization, etc.) is considered when using this information.
Information items shall therefore not be mistaken for the work product generated by the assessed organization itself. There is no 1:1 relationship between an information item and the work product taken as sample evidence by the assessor when assessing the achievement of a process outcome. An output generated by a process may comprise multiple information item characteristics and multiple outputs may also contain the same information item characteristics.
Information item characteristics should be considered as indicators when considering whether, given the context, a work product is contributing to the intended purpose of the process.
3.3.2.2. Types of work products
A work product to be considered as evidence when rating a process attribute may not necessary be outputs from the processes assessed but can also be originated from other processes of the organization. Once such a work product is used in the performance of a process under assessment, it may be considered by the assessor as objective evidence.
In a lot of cases work products are comprising documentation aspects, such as specifications, reports, records, architectural designs, software code etc.
Examples of work products not comprising any documentation aspects are software binaries, raw data, or a physical electronic hardware.
What is to be done
Why it has to be done
What are the technical dependencies
The term "process" can be understood at three levels of abstraction. Note that these levels of abstraction are not meant to define a strict black-or-white split, nor is it the aim to provide a scientific classification schema – the message here is to understand that, in practice, when it comes to the term "process" there are different abstraction levels, and that a PAM resides at the highest.
Process Assessment Model(s)
The "What" (Goals of the process)
Methods
Execution
The "How"
Methods, tools, templates, metrics
Definitions of logical order, concrete workflows
Authority and competence definitions
(How to achieve the goals)
Tailoring
Setup
Performance according to the tailored method
The "Doing"
(Performing the tasks to achieve the goals by using the methods)
Figure 4 — Possible levels of abstraction for the term "process"
Capturing experience acquired during product development (i.e. at the DOING level) in order to share this experience with others means creating a HOW level. However, a HOW is always specific to a particular context such as a company, an organizational unit, or a product line. For example, the HOW of a project, organizational unit, or company A is potentially not applicable as is to a project, organizational unit, or company B. However, both might be expected to adhere the principles represented by PAM indicators for process outcomes and process attribute achievements. These indicators are at the WHAT level while deciding on solutions for concrete templates, proceedings, and tooling etc. is left to the HOW level.
Methods
Process Assessment Model(s)
Execution
Performing interviews on the actual "Doing",
Investigating work products and tool repositories, …
Reading through the defined "How"
2
1
3
… and determine the capability profile.
… mapping the information to the indicators ...
Figure 5 — Performing a process assessment for determining process capability
In contrast, a PRM/PAM according to ISO/IEC 33004 (formerly ISO/IEC 15504-2) is at the level of the WHAT by abstracting from any HOW level, see Figure 4 in Section 0. In Automotive SPICE® v2.5, v3.0 and v3.1, this is indicated by the process MAN.3 Project Management requiring in BP2 “Define project life cycle”. A PRM/PAM groups a set of coherent and related characteristics of a particular technical topic and calls it ‘process’; in different terms, a process in a PRM represents a ‘distinct conceptual silo’. In this respect, a PRM/PAM neither predefines, nor discourages, any order in which PRM processes, or Base Practices, are to be performed; ultimately, in Automotive SPICE consistency must be fulfilled as required by the traceability/consistency Base Practices in MAN.3 or SYS.x, SWE.x, and HWE.X.
In this respect, a PRM or PAM further is not supposed to represent a product element hierarchy either.