8 Part 8: Annex

8.1 Method References

8.1.9 Process Analysis

Usage

Performing a Process Model Assessment, Preparing Hardware Implementation, Integration and Evaluation Concept, Evaluating Process, Preparing Evaluation Specification Process

Reference

Kne03, Car02, CMMI®, SPICE, DW88, Lev86, MIL-STD 1629A, EFQM, ISO DIS 10011, MIL-STD 1521 B, IEEE-STD 1028-1988, ANSI-Norm N45, Sta95, Car93, Car98, Phi86

Purpose

Process analysis is the evaluation of organization-specific processes, the identification of faults and deficiencies in the development process and the determination of deviations from given standards, guidelines and approaches. Process analysis may be carried out with the following methods:

Assessment Methods:

The assessment method is used to evaluate processes in an organization. For this purpose various assessment models and methods may be used, such as:

• »V-Modell XT Assessment
• »V-Modell XT Compliance Test
• CMMI®: »CMMI® (C apability Maturity Model Integration) is an improved version of the Capability Maturity Model that combines various other frameworks prepared by the Software Engineering Institute. CMMI® allows not only to support software development processes, but is also related to risk management and structured decision-making. It also permits the effective integration of human capability aspects within the software development.
• SPICE (ISO 15504): The »SPICE ( Software Process Improvement Capability dE termination) project is an international initiative for the development of a software process assessment standard. Approximately 40 countries participated actively in the development of this standard, which was headed by the Working Group 10 at ISO (ISO/IEC JTC1/SC7/WG10). The SPICE project is subdivided into six phases that are connected with each other: project initialization, product development, testing, product revision, knowledge and technology transfer, conclusion. The standard includes process evaluation, process improvement and performance evaluation. The primary goals of the standard are to further predictable product quality, to make improvements so that maximum productivity is achieved, to further a replicable software process and continuous process improvement through periodic consistency checks.
• EFQM: The »EFQM -Methodology (European Foundation of Quality Management) is used for the evaluation of a company as a whole. EFQM may be used to evaluate processes, but it provides mostly qualitative and not quantitative information. In the EFQM method also interfaces to not development-relevant business processes are evaluated. A self-check is made by the persons in charge of the businesses. The objective is to identify strengths and improvement potentials through improvement measures and a new self-check after, for example, one year. The EFQM methodology originated from the TQM concept (Total Quality Management). It forces people to consider the company as a whole, takes as a basis a generally accepted business excellence model and offers a generally accepted measure of effectiveness, for example a possibility to make Europe-wide comparisons.

Defect Causal Analysis:

The Defect Causal Analysis is a method that records faults of the product and deficiencies in the preparation process immediately after their occurrence and tests them systematically for their causes. This results in suggestions for corrective measures concerning the process and its environment. The suggested measures are reviewed by the management and their implementation is initiated. After their implementation the measures are tested and their effectiveness is measured. Successful measures will lead to process improvements that are introduced on a broad basis.

Categories of failure causes are:

• Communication problems (e. g. the responsibilities/tasks in the project/team are not clearly defined, points of contact not available because people are absent (vacation, extension training), inadequate communication between participating groups (software/software, software/hardware, development/acquirer, multi-site development),
• Implementation problems (tools, time management),
• Lack of orientation, lack of knowledge (e. g. the design is not understood, knowledge of the programming language is lacking),
• Procedural problems (e. g. the process is not suited for the product, there is a lack of mechanisms for the processing of change requests, etc.)
• Problems caused by unplanned extensions.

Audit:

The objective of the audit is to determine deviations from specified standards, guidelines and approaches when carrying out activities. The task of an audit is in particular to point to possibilities for improvement. The audit is based on the principle that a team led by a audit team leader checks and evaluates on the basis of defined evaluation criteria how the activities are carried out. For tests and evaluations, human faculty of judgment and the interview technique are used. Depending on the extent of the test it is sufficient to have the audit performed not by a team but by an individual person.

FMEA/FMCEA:

For the description of FMEA/FMCEA, see »Fault/Reliability Analysis.