Quality Management / Platform Quality Management Plan#
Platform Quality Management Plan
|
status: valid
security: YES
safety: ASIL_B
|
||||
Purpose#
The purpose of this document is to define a quality strategy and an approach for the platform. This includes an approach to providing an independent and objective assurance that work products and processes comply with predefined provisions and plans and that non-conformance is resolved and further prevented. This document includes quality assurance activities, roles and responsibilities, goals, schedule, etc. and a general strategy to implement quality assurance process in this platform. The quality assurance is ensured by automated checks and restrictions, manual checks which includes to proof that there is no manipulation of the workflows.
Statement of Independence#
The rl__quality_manager provides support to the project by consulting on quality improvements for the project/platform product. The Quality Manager is independent of the product delivery process. The quality report is approved by the rl__project_lead.
In S-CORE we have different Tier and OEM stakeholder involved: Every solution will be checked by the other stakeholders. This is another strong independent mechanism to ensure quality.
Objectives and scope#
3.1 Quality Objectives#
# |
Standard Name |
Version |
|---|---|---|
1 |
Automotive SPICE PAM |
4.0 |
2 |
ISO 262626:2018 |
2018 |
3 |
ISO/SAE 21434:2021 |
2021 |
4 |
ISO PAS 8926:2024 (will be integrated into ISO 26262 3rd edition as updated part 8 clause 12) |
2024 |
3.2 Quality Performance Objectives#
# |
Activities |
Cadence |
|---|---|---|
1 |
Platform process audit |
Once for every platform release or on demand |
2 |
Feature process conformance checks |
Once for every feature release |
3 |
Work product review |
Once for every feature release |
4 |
Platform release verification and approval |
Once for every release |
5 |
Process consulting / Quality trainings |
Continuously |
6 |
Process monitoring / Process improvement |
Continuously |
3.3 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 quality management, wf__exe_pltprocess_audit - Platform process audit is available |
2 |
One process conformance check for every feature release |
Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements |
One process conformance check has been done for every stable feature release |
Feature is released as experimental |
Ensured by the process quality management, wp__qms_report - Process conformance 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 verification, wp__verification_platform_ver_report - Verification report contains the verification results of the work products |
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, wp__platform_sw_release_note contain the verification and approval of the quality-assurance |
5 |
Only quality-trained personnel are part of the rl__committer |
Automotive Safety Integrity... (stkh_req__dependability__automotive_safety), Stakeholder Requirements |
100% of personnel are trained as per committer role description in rl__committer |
None |
Ensured by the process platform management, 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, wp__issue_track_system contain improvements and non-conformance |
3.4 Work Product Quality Goals#
For all generated work products, the following quality goals are defined:
Quality Criteria
All work products have to be available and valid. Templates, checklists, and guidelines shall be used. Plans have to be up to date.
The training material shall be available in the training path. The issues in the issue tracking system following the planning strategy.
Target value
The target value for all work products is 100%.
Allowed variation
There is no allowed variation for the work products.
Metric
The metric for the work products is ensured by the process that contains the work product. Only valid work products can be merged. Reviews are required and therefore checklists are prepared. If applicable, script based checks are implemented.
3.5 Quality Management Scope#
There is no deviation from the scope defined in the Project Management Plan (doc__project_mgt_plan). 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. Responsibilities 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 the documentation. The project is stewarded by the Eclipse Foundation and so the Eclipse Foundation Project Handbook applies.
Project Roles
The project roles are defined in the processes and are aligned to Eclipse roles.
Title |
ID |
Tags |
|---|---|---|
Architecture Community Member |
architecture_design |
|
Committer |
development |
|
Contributor |
development |
|
Delivery Team |
cross_functional |
|
Infrastructure Tooling Community Member |
development |
|
Platform Team |
cross_functional |
|
Process Community Member |
process_management |
|
Project Lead |
process_management |
|
Project Security Team |
verification; security_analysis |
|
Quality Manager |
quality_management |
|
Release Team |
cross_functional |
|
Safety Engineer |
safety_analysis |
|
Safety External Auditor |
safety_management |
|
Safety Manager |
safety_management |
|
Security Engineer |
security_analysis |
|
Security External Auditor |
security_management |
|
Security Manager |
security_management; security_management |
|
Testing Community Member |
verification |
Skills
The main quality related project roles are the rl__quality_manager and the rl__project_lead. These also have to have
the (Eclipse) committer role. As defined in Committer Training the committers are elected in a meritocratic 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, S-CORE defines that each committer has to prove his knowledge in quality SW development by:
by attending the project’s ASPICE 4.0 SW management and development training.
The successful checking of the committers’ skills and the independent roles is ensured by the rl__project_lead and rl__quality_manager who record/check this 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 rl__quality_manager role for the approvals
4 Quality Management Planning#
4.1 Quality Resources#
Dedicated rl__quality_manager are elected, following a methodology as done for the committers, which means in a meritocratic manner on project level.
The rl__quality_manager, supported by the rl__project_lead, and all other stakeholders, will ensure that quality activities are actively planned, developed, analyzed, verified, tested, and managed throughout the life cycle of the project.
Resources and milestones are planned in Github Issues for all activities. 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 their workflows are described in the platform management plan.
For quality relevant issue types the
qualitylabel 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 - Messenger Services e.g., Slack, Microsoft Teams, Github Notifications
Ad-hoc quality related meetings are set up for clarification topics.
Reporting
The quality management status wp__qms_report is reported as defined in the platform management plan.
Escalation
If needed a escalation can be done in three steps. First rl__quality_manager shall escalate to the rl__project_lead. Then to the project lead circle, documented in Project Management Plan (doc__project_mgt_plan). Finally to the Eclipse Foundation if the rules of the Eclipse handbook are not followed.
Examples for valid escalation causes are:
Conflict between rl__quality_manager and rl__committer regarding quality issues.
Quality issues cannot be resolved on feature level or with the available resources.
There are conflicting points of view between the rl__project_lead, rl__safety_manager, rl__security_manager and the rl__quality_manager.
4.3 Quality Management Specifics#
None
4.4 Quality Relevant Work Products#
The work products listed below are needed for every development, independent of its safety or security classification. Safety and security specific work products are defined in the Safety management / Platform Safety Plan, the Security management / Platform Security Plan and the module safety/security plans (see gd_temp__module_safety_plan, gd_temp__module_security_plan).
Platform Work Products#
Needed once for the platform.
Workproduct Id |
Link to WP |
|---|---|
Feature Work Products#
Needed for each feature.
Workproduct Id |
Link to WP |
|---|---|
Module Work Products#
Needed for each module.
Workproduct Id |
Link to WP |
|---|---|
Component Work Products#
Needed for each component of a module.
Workproduct Id |
Link to WP |
|---|---|