Process ID

SUP.1

Process name

Quality Assurance

Process purpose

The purpose of the Quality Assurance Process is to provide independent and objective assurance that work products and processes comply with predefined provisions and plans and that non-conformances are resolved and further prevented.

Process outcomes

As a result of successful implementation of this process:

1) a strategy for performing quality assurance is developed, implemented, and maintained;

2) quality assurance is performed independently and objectively without conflicts of interest;

3) non-conformances of work products, processes, and process activities with relevant requirements are identified, recorded, communicated to the relevant parties, tracked, resolved, and further prevented;

4) conformance of work products, processes and activities with relevant requirements is verified, documented, and communicated to the relevant parties;

5) authority to escalate non-conformances to appropriate levels of management is established; and

6) management ensures that escalated non-conformances are resolved.

Base practices

SUP.1.BP1: Develop a project quality assurance strategy. Develop a strategy in order to ensure that work product and process quality assurance is performed at project level independently and objectively without conflicts of interest. [OUTCOME 1, 2]

NOTE 1: Aspects of independence may be financial and/or organizational structure.

NOTE 2: Quality assurance may be coordinated with, and make use of, the results of other processes such as verification, validation, joint review, audit and problem management.

NOTE 3: Process quality assurance may include process assessments and audits, problem analysis, regular check of methods, tools, documents and the adherence to defined processes, reports and lessons learned that improve processes for future projects.

NOTE 4: Work product quality assurance may include reviews, problem analysis, reports and lessons learned that improve the work products for further use.

SUP.1.BP2: Assure quality of work products. Perform the activities according to the quality assurance strategy and the project schedule to ensure that the work products meet the defined work product requirements and document the results. [OUTCOME 2, 3, 4]

NOTE 5: Relevant work product requirements may include requirements from applicable standards.

NOTE 6: Non-conformances detected in work products may be entered into the problem resolution management process (SUP.9) to document, analyze, resolve, track to closure and prevent the problems.

SUP.1.BP3: Assure quality of process activities. Perform the activities according to the quality assurance strategy and the project schedule to ensure that the processes meet their defined goals and document the results. [OUTCOME 2, 3, 4]

NOTE 7: Relevant process goals may include goals from applicable standards.

NOTE 8: Problems detected in the process definition or implementation may be entered into a process improvement process (PIM.3) to describe, record, analyze, resolve, track to closure and prevent the problems.

SUP.1.BP4: Summarize and communicate quality assurance activities and results. Regularly report performance, deviations, and trends of quality assurance activities to relevant parties for information and action according to the quality assurance strategy. [OUTCOME 3, 4]

SUP.1.BP5: Ensure resolution of non-conformances. Deviations or non-conformance found in process and product quality assurance activities should be analyzed, tracked, corrected, and further prevented. [OUTCOME 3,6]

SUP.1.BP6: Implement an escalation mechanism. Establish and maintain an escalation mechanism according to the quality assurance strategy that ensures that quality assurance may escalate problems to appropriate levels of management and other relevant stakeholders to resolve them. [OUTCOME 5, 6]

Output work products

08-13 Quality plan

13-04 Communication record

→

→

[Outcome 1, 2]

[OUTCOME 3, 4, 5]

13-07 Problem record

→

[Outcome 3, 5]

13-18 Quality record

→

[OUTCOME 2, 3, 4]

13-19 Review record

→

[OUTCOME 2, 3, 4]

14-02 Corrective action register

→

[OUTCOME 3, 5, 6]

18-07 Quality criteria

→

[Outcome 1]

Process ID

SUP.2

Process name

Verification

Process purpose

The purpose of the Verification Process is to confirm that each work product of a process or project properly reflects the specified requirements.

Process outcomes

As a result of successful implementation of this process:

1) a verification strategy is developed, implemented and maintained;

2) criteria for verification of all required work products are identified;

3) required verification activities are performed;

4) defects are identified, recorded and tracked; and

5) results of the verification activities are made available to the customer and other involved parties.

Base practices

SUP.2.BP1: Develop a verification strategy. Develop and implement a verification strategy, including verification activities with associated methods, techniques, and tools; work product or processes under verification; degrees of independence for verification and schedule for performing these activities. [OUTCOME 1]

NOTE 1: Verification strategy is implemented through a plan.

NOTE 2: Software and system verification may provide objective evidence that the outputs of a particular phase of the software development life cycle (e.g. requirements, design, implementation, testing) meet all of the specified requirements for that phase.

NOTE 3: Verification methods and techniques may include inspections, peer reviews (see also SUP.4), audits, walkthroughs and analysis.

SUP.2.BP2: Develop criteria for verification. Develop the criteria for verification of all required technical work products. [OUTCOME 2]

SUP.2.BP3: Conduct verification. Verify identified work products according to the specified strategy and to the developed criteria to confirm that the work products meet their specified requirements. The results of verification activities are recorded. [OUTCOME 3]

SUP.2.BP4: Determine and track actions for verification results. Problems identified by the verification should be entered into the problem resolution management process (SUP.9) to describe, record, analyze, resolve, track to closure and prevent the problems. [OUTCOME 4]

SUP.2.BP5: Report verification results. Verification results should be reported to all affected parties. [OUTCOME 5]

Output work products

13-04 Communication record → [OUTCOME 5]

13-07 Problem record → [OUTCOME 3, 4, 5]

13-25 Verification results → [OUTCOME 2, 3, 4, 5]

14-02 Corrective action register → [OUTCOME 4]

18-07 Quality criteria → [OUTCOME 2]

19-10 Verification strategy → [OUTCOME 1]

Process ID

SUP.4

Process name

Joint Review

Process purpose

The purpose of the Joint review process is to maintain a common understanding with the stakeholders of the progress against the objectives of the agreement and what should be done to help ensure development of a product that satisfies the stakeholders. Joint reviews are at both project management and technical levels and are held throughout the life of the project.

Process outcomes

As a result of successful implementation of this process:

1) management and technical reviews are held based on the needs of the project;

2) the status and products of an activity of a process are evaluated through joint review activities between the stakeholders;

3) review results are made known to all affected parties;

4) action items resulting from reviews are tracked to closure; and

5) problems are identified and recorded.

NOTE 1: Joint review should be performed at specific milestones during project/product development. The scope and the goals of joint review may be different dependent on project/product development phase (for example, in the early stage of a project joint review may be "conceptual" in order to analyze the customer requirements; in later stages joint review may be concerned with the implementation).

NOTE 2: Joint review should be performed to verify different aspects (for example: hardware resources utilization; the introduction of new requirements and new technologies; modification to the working team structure; technology changes).

Base practices

SUP.4.BP1: Define review elements. Based on the needs of the project, identify the schedule, scope and participants of management and technical reviews, agree all resources required to conduct the reviews (this includes personnel, location and facilities) and establish review criteria for problem identification, resolution and agreement. [OUTCOME 1]

SUP.4.BP2: Establish a mechanism to handle review outcomes. Establish mechanisms to ensure that review results are made available to all affected parties that problems detected during the reviews are identified and recorded and that action items raised are recorded for action. [OUTCOME 3]

SUP.4.BP3: Prepare joint review. Collect, plan, prepare and distribute review material as appropriate in preparation for the review. [OUTCOME 1]

NOTE 1: The following items may be addressed: Scope and purpose of the review; Products and problems to be reviewed; Entry and exit criteria; Meeting agenda; Roles and participants; Distribution list; Responsibilities; Resource and facility requirements; Used tools (checklists, scenario for perspective based reviews etc.).

SUP.4.BP4: Conduct joint reviews. Conduct joint management and technical reviews as planned. Record the review results. [OUTCOME 1, 2]

SUP.4.BP5: Distribute the results. Document and distribute the review results to all the affected parties. [OUTCOME 3]

SUP.4.BP6: Determine actions for review results. Analyze the review results, propose actions for resolution and determine the priority for actions. [OUTCOME 4]

SUP.4.BP7: Track actions for review results. Track actions for resolution of identified problems in a review to closure. [OUTCOME 4]

SUP.4.BP8: Identify and record problems. Identify and record the problems detected during the reviews according to the established mechanism. [OUTCOME 5]

Output work products

13-04 Communication record → [OUTCOME 3]

13-05 Contract review record → [OUTCOME 1, 2, 3]

13-07 Problem record → [OUTCOME 3, 5]

13-09 Meeting support record → [OUTCOME 1, 2] 13-19 Review record → [OUTCOME ALL] 14-02 Corrective action register → [OUTCOME 3, 4, 5]

14-08 Tracking system → [OUTCOME 3, 4, 5]

15-01 Analysis report → [OUTCOME 3, 5]

15-13 Assessment/audit report → [OUTCOME 1, 2]

15-16 Improvement opportunity → [OUTCOME 3, 4]

Process ID

SUP.7

Process name

Documentation

Process purpose

The purpose of the Documentation Process is to develop and maintain the recorded information produced by a process.

Process outcomes

As a result of successful implementation of this process:

1) a strategy identifying the documentation to be produced during the life cycle of the product or service is developed;

2) the standards to be applied for the development of the documentation are identified;

3) documentation to be produced by the process or project is identified;

4) the content and purpose of all documentation is specified, reviewed and approved;

5) documentation is developed and made available in accordance with identified standards; and

6) documentation is maintained in accordance with defined criteria.

Base practices

SUP.7.BP1: Develop a documentation management strategy. Develop a documentation management strategy which addresses where, when and what should be documented during the life cycle of the product/service. [OUTCOME 1]

NOTE 1: A documentation management strategy may define the controls needed to approve documentation for adequacy prior to issue; to review and update as necessary and re-approve documentation; to ensure that changes and the current revision status of documentation are identified; to ensure that relevant versions of documentation are available at points of issue; to ensure that documentation remain legible and readily identifiable; to ensure the controlled distribution of documentation; to prevent unintended use of obsolete documentation ; and may also specify the levels of confidentiality, copyright or disclaimers of liability for the documentation.

SUP.7.BP2: Establish standards for documentation. Establish standards for developing, modifying and maintaining documentation. [OUTCOME 2]

SUP.7.BP3: Specify documentation requirements. Specify requirements for documentation such as title, date, identifier, version history, author(s), reviewer, authorizer, outline of contents, purpose, and distribution list. [OUTCOME 2]

SUP.7.BP4: Identify the relevant documentation to be produced. For any given development life cycle, identify the documentation to be produced. [OUTCOME 3]

SUP.7.BP5: Develop documentation. Develop documentation at required process points according to established standards and policy, ensuring the content and purpose is reviewed and approved as appropriate. [OUTCOME 4, 5]

SUP.7.BP6: Check documentation. Review documentation before distribution, and authorize documentation as appropriate before distribution or release. [OUTCOME 5]

NOTE 2: The documentation intended for use by system and software users should accurately describe the system and software and how it is to be used in clear and useful manner for them.

NOTE 3: Documentation should be checked through verification or validation process.

SUP.7.BP7: Distribute documentation. Distribute documentation according to determined modes of distribution via appropriate media to all affected parties, confirming delivery of documentation, where necessary. [OUTCOME 5]

SUP.7.BP8: Maintain documentation. Maintain documentation in accordance with the determined documentation strategy. [OUTCOME 6]

NOTE 4: If the documentation is part of a product baseline or if its control and stability are important, it should be modified and distributed in accordance with process SUP.8 Configuration management.

Output work products

08-26 Documentation plan → [OUTCOME 1, 2]

13-01 Acceptance record → [OUTCOME 4, 5]

13-19 Review record → [OUTCOME 4, 5]

14-01 Change history → [OUTCOME 5, 6]

14-11 Work product list → [OUTCOME 3]

Process ID

SUP.8

Process name

Configuration Management

Process purpose

The purpose of the Configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.

Process outcomes

As a result of successful implementation of this process:

1) a configuration management strategy is developed;

2) all configuration items generated by a process or project are identified, defined and baselined according to the configuration management strategy;

3) modifications and releases of the configuration items are controlled;

4) modifications and releases are made available to affected parties;

5) the status of the configuration items and modifications is recorded and reported;

6) the completeness and consistency of the baselines is ensured; and

7) storage of the configuration items is controlled.

Base practices

SUP.8.BP1: Develop a configuration management strategy. Develop a configuration management strategy, including

 responsibilities;

 tools and repositories;

 criteria for configuration items;

 naming conventions;

 access rights;

 criteria for baselines;

 merge and branch strategy;

 the revision history approach for configuration items

[Outcome 1]

NOTE 1: The configuration management strategy typically supports the handling of product/software variants which may be caused by different sets of application parameters or by other causes.

NOTE 2: The branch management strategy specifies in which cases branching is permissible, whether authorization is required, how branches are merged, and which activities are required to verify that all changes have been consistently integrated without damage to other changes or to the original software.

SUP.8.BP2: Identify configuration items. Identify and document configuration items according to the configuration management strategy. [OUTCOME 2]

NOTE 3: Configuration control is typically applied for the products that are delivered to the customer, designated internal work products, acquired products, tools and other configuration items that are used in creating and describing these work products.

SUP.8.BP3: Establish a configuration management system. Establish a configuration management system according to the configuration management strategy. [OUTCOME 1, 2, 3, 4, 6, 7]

SUP.8.BP4: Establish branch management. Establish branch management according to the configuration management strategy where applicable for parallel developments that use the same base. [OUTCOME 1, 3, 4, 6, 7]

SUP.8.BP5: Control modifications and releases. Establish mechanisms for control of the configuration items according to the configuration management strategy, and control modifications and releases using these mechanisms. [OUTCOME 3, 4, 5]

SUP.8.BP6: Establish baselines. Establish baselines for internal purposes and for external delivery according to the configuration management strategy. [OUTCOME 2]

NOTE 4: For baseline issues refer also to the product release process SPL.2.

SUP.8.BP7: Report configuration status. Record and report status of configuration items to support project management and other relevant processes. [OUTCOME 5]

NOTE 5: Regular reporting of the configuration status (e.g. how many configuration items are currently under work, checked in, tested, released, etc.) supports project management activities and dedicated project phases like software integration.

SUP.8.BP8: Verify the information about configured items. Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines. [OUTCOME 6]

NOTE 6: A typical implementation is performing baseline and configuration management audits.

SUP.8.BP9: Manage the storage of configuration items and baselines. Ensure the integrity and availability of configuration items and baselines through appropriate scheduling and resourcing of storage, archiving (long term storage) and backup of the used CM systems. [OUTCOME 4, 5, 6, 7]

NOTE 7: Backup, storage and archiving may need to extend beyond the guaranteed lifetime of available storage media. Relevant configuration items affected may include those referenced in note 2 and note 3. Availability may be specified by contract requirements.

Output work products

06-02 Handling and storage guide → 08-04 Configuration management plan →

[OUTCOME 3, 4, 5, 7]

[OUTCOME 1, 2, 7]

08-14 Recovery plan →

[Outcome 1, 7]

13-08 Baseline →

[OUTCOME 2, 3, 4, 5, 6]

13-10 Configuration management record →

[OUTCOME 2, 5, 7]

14-01 Change history →

[Outcome 3]

16-03 Configuration management system →

[OUTCOME 1, 3, 4]

Process ID

SUP.9

Process name

Problem Resolution Management

Process purpose

The purpose of the Problem Resolution Management Process is to ensure that problems are identified, analyzed, managed and controlled to resolution.

Process outcomes

As a result of successful implementation of this process:

1) a problem resolution management strategy is developed;

2) problems are recorded, uniquely identified and classified;

3) problems are analyzed and assessed to identify an appropriate solution;

4) problem resolution is initiated;

5) problems are tracked to closure; and

6) the status of problems and their trend are known.

Base practices

SUP.9.BP1: Develop a problem resolution management strategy. Develop a problem resolution management strategy, including problem resolution activities, a status model for the problems, alert notifications, responsibilities for performing these activities and an urgent resolution

strategy. Interfaces to affected parties are defined and definitions are maintained. [OUTCOME 1]

NOTE 1: Problem resolution activities can be different during the product life cycle, e.g. during prototype construction and series development.

SUP.9.BP2: Identify and record the problem. Each problem is uniquely identified, described and recorded. Supporting information should be provided to reproduce and diagnose the problem. [OUTCOME 2]

NOTE 2: Supporting information typically includes the origin of the problem, how it can be reproduced, environmental information, by whom it has been detected, etc.

NOTE 3: Unique identification supports traceability to changes made.

SUP.9.BP3: Record the status of problems. A status according to the status model is assigned to each problem to facilitate tracking. [OUTCOME 6]

SUP.9.BP4: Diagnose the cause and determine the impact of the problem. Investigate the problem and determine its cause and impact in order to categorize the problem and to determine appropriate actions. [OUTCOME 2, 3]

NOTE 4: Problem categorization (e.g. A, B, C, light, medium, severe) may be based on severity, impact, criticality, urgency, relevance for the change process, etc.

SUP.9.BP5: Authorize urgent resolution action. If according to the strategy a problem requires an urgent resolution, authorization shall be obtained for immediate action also according to the strategy. [OUTCOME 4]

SUP.9.BP6: Raise alert notifications. If according to the strategy the problem has a high impact on other systems or other affected parties, an alert notification needs to be raised also according to the strategy. [OUTCOME 4]

SUP.9.BP7: Initiate problem resolution. Initiate appropriate actions according to the strategy to resolve the problem including review of those actions, or initiate a change request. [OUTCOME 4]

NOTE 5: Appropriate actions may include the initiating of a change request. See SUP.10 for managing of change requests.

NOTE 6: The implementation of process improvements (to prevent problems) is done in the process improvement process (PIM.3).The implementation of generic project management improvements (e.g. lessons learned) are part of the project management process (MAN.3). The implementation of generic work product related improvements are part of the quality assurance process (SUP.1).

SUP.9.BP8: Track problems to closure. Track the status of problems to closure including all related change requests. A formal acceptance has to be authorized before closing the problem. [OUTCOME 5, 6]

SUP.9.BP9: Analyze problem trends. Collect and analyze problem resolution management data, identify trends, and initiate project related actions, according to the strategy. [OUTCOME 6]

NOTE 7: Collected data typically contains information about where the problems occurred, how and when they were found, what were their impacts, etc.

Output work products

08-27 Problem management plan → [OUTCOME 1]

13-07 Problem record → [OUTCOME 2, 3, 4, 5]

15-01 Analysis report → [OUTCOME 3]

15-05 Evaluation report → [OUTCOME 3]

15-12 Problem status report → [OUTCOME 6]

Process ID

SUP.10

Process name

Change Request Management

Process purpose

The purpose of the Change Request Management Process is to ensure that change requests are managed, tracked and implemented.

Process outcomes

As a result of successful implementation of this process:

1) a change request management strategy is developed;

2) requests for changes are recorded and identified;

3) dependencies and relationships to other change requests are identified;

4) criteria for confirming implementation of change requests are defined;

5) requests for change are analyzed, and resource requirements are estimated;

6) changes are approved and prioritized on the basis of analysis results and availability of resources;

7) approved changes are implemented and tracked to closure;

8) the status of all change requests is known; and

9) bi-directional traceability is established between change requests and affected work products.

Base practices

SUP.10.BP1: Develop a change request management strategy. Develop a change request management strategy, including change request activities, a status model for the change requests, analysis criteria, and responsibilities for performing these activities. Interfaces to affected parties are defined and maintained. [OUTCOME 1]

NOTE 1: A status model for change requests may contain: open, under investigation, approved for implementation, allocated, implemented, fixed, closed, etc.

NOTE 2: Typical analysis criteria are: resource requirements, scheduling issues, risks, benefits, etc.

NOTE 3: Change request activities ensure that change requests are systematically identified, described, recorded, analyzed, implemented, and managed.

NOTE 4: The change request management strategy may cover different proceedings across the product life cycle, e.g. during prototype construction and series development.

SUP.10.BP2: Identify and record the change requests. Each change request is uniquely identified, described, and recorded according to the strategy, including the initiator and reason of the change request. [OUTCOME 2, 3]

SUP.10.BP3: Record the status of change requests. A status according to the status model is assigned to each change request to facilitate tracking. [OUTCOME 8]

SUP.10.BP4: Analyze and assess change requests. Change requests are analyzed according to the strategy including their dependencies to affected work products and other change requests. Assess the impact of the change requests and establish criteria for confirming implementation. [OUTCOME 3, 4, 5, 9]

SUP.10.BP5: Approve change requests before implementation. Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy. [OUTCOME 6]

NOTE 5: A Change Control Board (CCB) is a common mechanism used to approve change requests.

NOTE 6: Prioritization of change requests may be done by allocation to releases.

SUP.10.BP6: Review the implementation of change requests. The implementation of change requests is reviewed before closure to ensure that their criteria for confirming implementation are satisfied, and that all relevant processes have been applied. [OUTCOME 7, 8]

SUP.10.BP7: Track change requests to closure. Change requests are tracked until closure. Feedback to the initiator is provided. [OUTCOME 7, 8]

SUP.10.BP8: Establish bidirectional traceability. Establish bidirectional traceability between change requests and work products affected by the change requests. In case that the change request is initiated by a problem, establish bidirectional traceability between change requests and the corresponding problem reports. [OUTCOME 9]

NOTE 7: Bidirectional traceability supports consistency, completeness and impact analysis.

Output work products

08-28 Change management plan → [OUTCOME 1]

13-16 Change request → [OUTCOME 2, 3, 4, 5, 6, 7]

13-19 Review record → [OUTCOME 7]

13-21 Change control record → [OUTCOME 8, 9]