You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: process/process_areas/quality_management/guidance/quality_plan_guideline.rst
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,25 +29,25 @@ Guideline Quality Management Plan
29
29
|As starting point for Quality Culture we define a Committer selection process to already have professionals with quality experience in the teams.
30
30
|
31
31
|Quality Management:
32
-
|ASPICE 4.0 standard is selected for quality management. Processes will always link to the :ref:`standard_iso26262` standard, :ref:`standard_isopas8926` standard, :ref:`standard_isosae21434` and to the :ref:`standard_aspice_40` standard.
32
+
|ASPICE 4.0 standard is selected for quality management. Processes will always link to the :ref:`standard_iso26262` standard, :ref:`standard_isopas8926` standard, :ref:`standard_isosae21434` and to the <add link to aspice> standard.
33
33
|
34
34
|Communication:
35
-
|Cross functional teams are interdisciplinary, so the regular (sprint) planning and review meetings enable communication. The organization of the project is described in the Project Management Plan :need:`doc__project_mgt_plan`. Another main communication means are the Pull Request (PR) reviews.
35
+
|Cross functional teams are interdisciplinary, so the regular (sprint) planning and review meetings enable communication. The organization of the project is described in the Project Management Plan. Another main communication means are the Pull Request (PR) reviews.
36
36
|Also the standard Eclipse Foundation communication strategies are used (e.g. mailing lists, Slack channel).
37
37
|
38
38
|Quality issues, non-conformances and improvements:
39
39
|Feedback from the field, but also during development of change requests to existing features, bug reporting by the Open Source community or integration of existing SW components into new features may lead to the discovery of issues, non-conformances or improvements.
40
40
|Non-conformance can also be deviations from the development process with impact on safety or security.
41
41
|If these are known at the time of creation of a release they will be part of the :need:`wp__platform_sw_release_note` for the feature.
42
-
|Other issues and non-conformances relevant for already delivered releases will be identified as such and communicated (as defined in Problem Resolution part of :need:`doc__project_mgt_plan`) via the :need:`wp__issue_track_system`.
42
+
|Other issues and non-conformances relevant for already delivered releases will be identified as such and communicated (as defined in Problem Resolution part of the Project Management Plan) via the :need:`wp__issue_track_system`.
43
43
|
44
44
|**Tailoring quality activities:**
45
45
|Main tailoring driver is that the SW platform is pure SW development and is provided as "SW element" - this explains mainly the generic, platform wide tailoring.
46
-
|Tailoring is done for the whole SW platform by defining only the relevant processes and their resulting outcomes and an argumentation why the others are not needed in :ref:`standard_aspice_40`.
46
+
|Tailoring is done for the whole SW platform by defining only the relevant processes and their resulting outcomes and an argumentation why the others are not needed in <add link to aspice>.
47
47
|
48
48
|**Planning quality activities:**
49
49
|In the Quality Management Plan the nomination of the quality manager and the project manager is documented.
50
-
|The planning of quality activities is done using issues in the :need:`wp__issue_track_system` as specified in the Project Management part of :need:`doc__project_mgt_plan`
50
+
|The planning of quality activities is done using issues in the :need:`wp__issue_track_system` as specified in the Project Management part of the Project Management Plan.
51
51
|It contains for each issue
52
52
|* objective - as part of the issue description
53
53
|* dependencies on other activities or information - by links to the respective issues
@@ -57,18 +57,18 @@ Guideline Quality Management Plan
57
57
|* UID of the resulting work products - stated in the issue title
58
58
|
59
59
|The planning of quality activities is part of
60
-
|* generic planning, dealing with all work products needed only once for the platform. This is included in :need:`doc__platform_quality_plan`
60
+
|* generic planning, dealing with all work products needed only once for the platform. This is included in the Quality Management Platform Plan.
61
61
|
62
62
|**Planning supporting processes:**
63
-
|Supporting processes (Requirements Management, Configuration Managment, Change Management, Documentation Management, Tool Management) are planned within the :need:`doc__project_mgt_plan`
63
+
|Supporting processes (Requirements Management, Configuration Managment, Change Management, Documentation Management, Tool Management) are planned within the Project Management Plan.
64
64
|
65
65
|**Planning integration and verification:**
66
66
|Integration on the target hardware is not done in the scope of the SW platform project, but SW/SW integration up to the feature level is performed and its test results are part of the :need:`wp__verification__platform_ver_report`.
67
67
|The integration on the target hardware done by the distributor or OEM is supported by delivering a set of HW/SW integration tests which were already run successfully on a reference HW platform.
68
68
|This is planned by the respective workproducts:
69
69
|* :need:`wp__verification__feat_int_test`
70
-
|* :need:`wp__verification__platform_test`
70
+
|* Platform verification integration test
71
71
|Verification planning is documented in :need:`wp__verification__plan`
72
72
|
73
73
|**Scheduling of audits, conformance checks, work product reviews, release verification and approval:**
74
-
|Scheduling is done in the same way as for all work products definition by issues. The respective work products are listed :ref:`workproduct_list_quality_review` here.
74
+
|Scheduling is done in the same way as for all work products definition by issues. The respective work products are listed :need:`doc_concept__wp_inspections` here.
0 commit comments