Quality Management / Generic Quality Plan

Project Quality Plan		status: draft safety: ASIL_B
status: draft tags: platform_management realizes: wp__qlm_plan_definitions safety: ASIL_B
doc__project_quality_plan		Generic Document

Purpose

The purpose of this document is to is to define a quality strategy and an approach for the project/platform. This includes an approach to provide an independent and objective assurance that work products and processes comply with predefined provisions and plans and that non-conformances are resolved and further prevented. This document includes quality assurance activities, roles and responsibilities, goals, schedule, tools, etc. and a general strategy to implement quality assurance process in this project/platform.

Statement of Independence

The Quality Manager (rl__quality_manager) provides only support to the project with consulting them to improve the quality of the project/platform product.

Although the quality report is also sent to the Technical Lead (rl__technical_lead), the Quality Manager (rl__quality_manager) is independent of the delivery of the product.

Objectives and scope

3.1 Quality Objectives

Table 40 Standards to comply with

#	Standard Name	Version
1	Automotive SPICE PAM	4.0
2	ISO 262626:2018	2018
3	ISO 21434:2021	2021
4	ISO PAS 8926:2024	2024

3.2 Quality Performance Objectives

Table 41 Quality assurance activities and frequence of performing them

#	Activities	Cadence
1	Platform Process audit	Once for every platform release or on demand
2	Feature Process compliance checks	Once for every feature release
3	Feature Work product review	Once for every feature release
4	Platform Release verification and approval	Once for every release
5	Process consulting	Continuously
6	Process monitoring	Continuously

3.3 Quantitative Quality Goals

Table 42 Quantitative Quality Goals

#	Quality Criteria	Source	Target value	Allowed variation	Metric
1	One platform process audit per release	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	100% of the platform process audit has be done for every release	Delta audit allowed to achieve 100%	Ensured by the process process management, Process Improvement Report (wp__process_impr_report) - Platform process audit is available
2	One process compliance check for every feature release	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	One process compliance check has been done for every stable feature release	Feature is released as experimental	Ensured by the process quality and tool management, Quality report (wp__qms_report) - Process compliance is available
3	Only quality-assured project/platform work products are delivered to the community	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	100% of project/platform work products are quality-assured	Feature is released as experimental	Ensured by the process quality and tool management, Platform Verification Report (wp__verification__platform_ver_report) - Work products contain the verification of the quality assurance
4	Only quality-assured project/platform releases are delivered to the community	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	100% of project/platform releases delivered to the community are quality-assured	Feature is released as experimental	Ensured by the process release management, Platform Release Notes (wp__platform_sw_release_note) contain the verification and approval of the quality-assurance
5	Only quality-trained personnel are part of the Committer (rl__committer)	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	100% of personnel are trained	None	Ensured by the process platform management, Training path (wp__training_path) contain the training material and evidences for conducted trainings
6	No overdue quality assurance closure activities	Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements	100% of the quality improvement, non-conformance issues are closed	None	Ensured by the process quality management, Issue tracking system (wp__issue_track_system) contain improvments and non-coformancees

3.4 Work Product Quality Goals

Table 43 Work Product Quality Goals

#	Work Product	Quality Criteria	Target value	Allowed variation	Metric
1	Feature Request (wp__feat_request)	Feature request is reviewed and accepted	100%	None	Ensured by process livecycle concept, evidences for participants available, feedback of participants documented
2	Stakeholder Requirements	All stakeholder requirements are reviewed and valid All stakeholder requirements are at least satisfied by one feature requirement	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
3	<Link WP_TOOL_REQ>`	All tool requirements are reviewed and valid All tool requirements have bidirectional traceability to and from process requirements or guidance	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
4	Feature Requirements (wp__requirements__feat)	All feature requirements are reviewed and valid All feature requirements have bidirectional traceability to and from stakeholder requirements	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
5	Component Requirements (wp__requirements__comp)	All component requirements are reviewed and valid All component requirements have bidirectional traceability to and from feature requirements	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
6	Feature Assumptions of Use (wp__requirements__feat_aou)	All feature aou are reviewed and valid All feature aou have bidirectional traceability to and from feature requirements	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
7	Component Assumptions of Use (wp__requirements__comp_aou)	All component aou are reviewed and valid All component aou have bidirectional traceability to and from feature requirements	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
8	Hardware-software interface... (wp__hsi)	Hardware and Software interaction is specified and consistent with the technical safety concept All component HW parts that are controlled by the software are included All HW ressources that support the SW executen are included	100%	None	Ensured by quality management, only verified and valid documents can be merged, review required
9	Requirements Inspection (wp__requirements__inspect)	All requirements were inspected by review with inspection checklist.	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
10	Feature Architecture (wp__feature_arch)	All feature architectures are reviewed and valid All feature architectures have bidirectional traceability to and from feature requirements	100%	None	Ensured by process configuration and tool management, only valid requirements can be merged, review required, script based check
11	Feature Safety Analysis (wp__feature_safety_analysis)	Inductive (bottom-up) safety analysis e.g. FMEA is completed. Analysis verifies the feature architecture. All detection and prevention mitigations are linked to Software Feature Requirements or Assumptions of use.	100%	None	Ensured by process configuration and tool management, only valid safety analysis can be merged, review required, script based check
12	Component Architecture (wp__component_arch)	All component architectures are reviewed and valid All component architectures have bidirectional traceability to and from components requirements or feature architectures	100%	None	Ensured by process configuration and tool management, only valid architecture can be merged, review required, script based check
13	Component Safety Analysis (wp__sw_component_safety_analysis)	Inductive (bottom-up) safety analysis e.g. FMEA is completed. Analysis verifies the component architecture. All detection and prevention mitigations are linked to Software Component Requirements or Assumptions of use.	100%	None	Ensured by process configuration and tool management, only valid safety analysis can be merged, review required, script based check
14	Architecture Verification (wp__sw_arch_verification)	Architecture verification is available and valid.	100%	None	Ensured by process configuration and tool management, only valid architecture can be merged, review required, script based check
15	Implementation (wp__sw_implementation)	Implementation of source code has been done after creation of detailed design. SW configuration is described.	100%	None	Ensured by process configuration and tool management, only valid Detailed Design and Code can be merged, verification required, script based check
16	Unit test (wp__verification__sw_unit_test)	Detailed design is verified by unit testing.	100%	None	Ensured by process configuration and tool management, only valid Detailed Design and Code can be merged, verification required, script based check
17	Implementation Inspection (wp__sw_implementation_inspection)	Inspection is done by inspection checklist.	100%	None	Ensured by process configuration and tool management, only valid Detailed Design and Code can be merged, verification required, script based check
18	Feature Integration test (wp__verification__feat_int_test)	All interfaces from static view and all flows from dynamic view are valid and reviewed. Performance expectations (RAM, processor usage, ..) on reference hardware are described.	100%	None	Ensured by process configuration and tool management, only valid features can be merged, verification required, script based check
19	Component Integration test (wp__verification__comp_int_test)	All interfaces from static view and all flows from dynamic view are valid and reviewed. Integration of units into components is based on the detailed design.	100%	None	Ensured by process configuration and tool management, only valid components can be merged, verification required, script based check
20	Component test (wp__verification__component_test)	All component requirements are valid and reviewed.	100%	None	Ensured by process configuration and tool management, only valid components can be merged, verification required, script based check
21	Module Verification Report (wp__verification__module_ver_report)	Module verification report is available and valid for every module.	100%	None	Ensured by process configuration and tool management, only valid components can be merged, verification required, script based check
22	Software component classifi... (wp__sw_component_class)	Software component classification is available and valid.	100%	None	Ensured by process configuration and tool management, only valid components can be merged, verification required, script based check
23	Training path (wp__training_path)	All training material is available and valid, training planned and executed All training paths has been scheduled and executed	100%	None	Ensured by process platform management, evidences for participants available, feedback of participants documented
24	Issue tracking system (wp__issue_track_system)	All issues follow the planning strategy defined in the project/platform management plan	100%	None	Ensured by project management and tool management, only issues following the strategy can be part of any PR
25	Platform Management Plan (wp__platform_mgmt)	All findings from work product review are resolved anf reviewed. Document is valid.	100%	None	Ensured by project management, only verified and valid documents can be merged, review required
26	Process Definition (wp__process_definition)	All findings from platform audit are resolved and reviewed. Document is valid.	100%	None	Ensured by process management and tool management, only verified and valid documents can be merged, review required
27	Process Improvement Report (wp__process_impr_report)	Process improvement report is available and valid for every platform release.	100%	None	Ensured by quality management and tool management, only verified and valid documents can be merged, review required
28	Process Management Strategy (wp__process_plan)	The process strategy is defined, available and valid.	100%	None	Ensured by process management and tool management, only verified and valid documents can be merged, review required
29	Module Safety Plan (wp__module_safety_plan)	All findings from work product review are resolved and reviewed. Document is valid.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
30	:need:<wp__module_safety_case>	All findings from work product review are resolved and reviewed. Document is valid.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
31	Platform Safety Plan (wp__platform_safety_plan)	All findings from work product review are resolved and reviewed. Document is valid.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
32	:need:<wp__platform_safety_case>	All findings from work product review are resolved and reviewed. Document is valid.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
33	:need:<wp__cmr_reports>	CMR reports (Safety Plan, Safety Case, Safety Analyses and DFA) are available and valid for every platform release.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
34	<Link WP_ASSESSMENT_REPORT>	Functional Safety assessment report is available and valid for every platform release.	100%	None	Ensured by safety management, only verified and valid documents can be merged, review required
35	Feature DFA (wp__feature_dfa)	DFA on platform/feature level is available and valid. All detection and prevention mitigations linded to Software Feature Requirements or Assumtions oa Use.	100%	None	Ensured by process configuration and tool management, only valid safety analysis can be merged, review required, script based check
36	Component DFA (wp__sw_component_dfa)	DFA on component/module level is available and valid. All detection and prevention mitigations linded to Software Component Requirements or Assumtions oa Use.	100%	None	Ensured by process configuration and tool management, only valid safety analysis can be merged, review required, script based check
37	Module Build Configuration (wp__module_sw_build_config)	Build configuration is capable to create the SEooC Library on the reference HW, module level.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
38	Module Safety Manual (wp__module_safety_manual)	Safety Manual for every module is available, up to date and vaild.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
39	Module Release Notes (wp__module_sw_release_note)	All known bugs are described with a clear statement that these bugs do not lead to violation of any safety requirements or corresponding workarround measures.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
40	Software Development Plan (wp__sw_development_plan)	SW Development Plan is available, up to date and valid.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
41	Verification Plan (wp__verification__plan)	Verification Plan is available, up to date and valid.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
42	:need:<wp__tool_eval>	All tool conficence levels (TCL) are determined. Appropiate qualification methods are applied.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
43	Tailoring Documents (wp__tailoring)	Argumentation for all tailored (not needed) work products in the project is availabe and valid.	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check
44	Quality Management Plan (wp__qms_plan)	Quality Management Plan is availabe, up to date and valid	100%	None	Ensured by process configuration and tool management, only valid documents can be merged, review required, script based check

3.5 Quality Management Scope

There is no deviation from the scope defined in the Introduction.

The platform and its components are developed, and integrated for an assumed technical system, for functional safety purposes as Safety Element out of Context (SEooC).

The development of the platform and its components follows the defined processes.

Responsibilites for management, development, implementation, integration and verification are also defined in the processes.

The SW platform consists of features, which are based on a set of requirements and are developed in parallel.

Tailoring of quality assurance activities

* The tailoring is divided into project wide and feature specific rules.

* Project wide tailoring is documented in ASPICE 4.0 - this is based on the development of a SW element

3.6 Quality Management Organization

It is the project strategy to qualify the platform or components of the platform to the appropriate international standards and directives.

Therefore the project approach to facilitate a common culture regarding quality, safety and security is part of our documentation.

The project will be under the Eclipse Foundation and so the Eclipse Foundation Project Handbook applies.

Eclipse Roles

Contributors can be everyone and we will not discourage the open source community from this. As the contributor cannot merge code (or any other workproduct) directly into the project’s codebase, the quality development competence of the contributor is irrelevant.

Committers play the main development role in the project and are ultimately responsible for the project repository content, as only they are allowed to merge, so they are the ultimate responsibles for the project’s repository content.

The Eclipse Project Lead(s) and Committers has the quality manager role.

Project Roles

Roles are defined and matched to Eclipse roles.

Critical dependencies

The project has not implemented a quality management system yet.

But it aims to be conformant to ASPICE, as defined in the management system.

Continuous improvement is part of all processes. Improvements are handled in the scope of Quality Management.

Risk

Organization and management system is currently not mature.

Skills

The main quality related project roles are the project manager and the quality manager and these also have to have the (Eclipse) committer role.

As defined in Committer Training the committers are elected in a meritrocatic manner, meaning those have to show their skills and understanding of the project processes in several previous pull requests.

As each project can adopt additional criteria for the committers election, we define the following:

- each committer has to prove his knowledge in quality SW development by

- an passed training in ASPICE (or equivalent standard, at least 16h of SW management and development specific training by a trusted training provider) and

- by attending the projects’s ASPICE SW management and development training (given by a project lead, quality manager or safety team member)

Additionally the project repository is organized in “CODEOWNER” sections. These “CODEOWNERS” need to approve any pull request modifying a file in their area before it is merged.

In case of quality related “CODEOWNER” sections (e.g. any documentation artefacts) the persons having “CODEOWNER” rights need to have:

- At least one year of professional practice of quality related SW development (or management) relevant for the section content with demonstrable and verifiable results.

The successful checking of committers and CODEOWNERS skills is ensured by the project and quality manager and documented in the role assignment document.

Note

The identity of the committer by applying the GitHub digital signature mechanism will be used to confirm the authenticity of the quality manager role for the approvals

1. Quality Management Planning

4.1 Quality Ressources

A dedicated Quality Manager is defined as part of the Maintainer role.

The Quality Manager, supported by the Project Manager, and all other stakeholders, will ensure that

quality activities are actively planned, developed, analyzed, verified and tested and managed throughout the life cycle of the project.

As all the implementation takes place within feature development, there is a quality manager appointed in the feature development plan.

Resources and milestones are planned in Github Issues for all activities.

There are issue templates for sagas (covering one feature development) and for epics (covering one development workproduct each).

Resource and milestone planning is done as defined in the Project management plan.

Tools

The whole development and thus all work products are located in Github. The development is automated as much as possible and follows the defined processes.

Github issues are used for planning.

The issue types and issue types workflows are described in the platform management plan.

For quality relevant issue types a quality label is used.

4.2 Quality Management Communication

To exchange general information and to clarify general topics, the following communication channels are used:

* Regular (online) meetings

* E-Mails

* Messager Services e.g., Slack, Microsoft Teams, Github Notifications

Ad-hoc quality related meetings are set up for clarification topics.

Reporting

The quality management status is reported as defined in the platform management plan.

The status report includes at least the defined Quality Criteria defined in this document.

Escalation

- Quality Manager to Steering Council

Examples for valid escalation causes are:

* Quality issues cannot be resolved on feature level or with the available resources.

* There are conflicting points of view between the Project Manager, Safety Manager and the Quality Manager

5. Quality Management Specifics

None

6. Quality Management Generic workproducts

Table 44 Quality related work products

Workproduct Id	Link to process	Process status	Link to issue	Link to WP	WP status
wp__module_sw_release_note	Release management	<automated>		Module Release Notes (wp__module_sw_release_note)	<automated>
wp__process_impr_report	Quality Management / Generic Quality Plan	<automated>		Process Improvement Report (wp__process_impr_report)	<automated>
wp__qms_report	Quality Management / Generic Quality Plan	<automated>		Quality report (wp__qms_report)	<automated>
wp__verification__platform_ver_report	Software verification	<automated>		Platform Verification Report (wp__verification__platform_ver_report)	<automated>
wp__training_path	n/a	n/a	n/a	not open sourced	to be shown to assessor
wp__issue_track_system	Platform Management Plan	<automated>	n/a	Issue tracking system (wp__issue_track_system)	established