Fix audit 2 findings

[aschemmel-tech]

In incubation phase the planned processes (areas safety mangement, change management, requirements, architecture and verification management) for S-CORE were audited (two sessions). The findings (no deviation / major) of the respective audit report need to be fixed before the first development release (incl. confirmation by the auditors). For better tracking those are copied here (in brackets the person planned to fix):

Safety Management:

• Action: The related page for safety culture / project communication cannot be found on the Eclipse web site. Cybersecurity is not yet addressed. The topic needs to be re-addressed. - see create safety management process description score#329
• Action: The related page for safety anomlaies cannot be found on the Eclipse web site. The topic needs to be re-addressed. see create safety management process description score#329
• Finding: The role descriptions in “SCORE Management Roles“ are not detailed enough. The roles and their responsibility shall be clearly and precisely described. (MarkusS)
• Finding: Not all roles and responsibilities are configured yet in with the eclipse environment yet. The linkage of roles to work products and process is missing - done for safety management roles, workproducts and workflows: create safety management process description score#329
• Action: It need to be clarified which part of ISO 26262-4 §7 are judged to be applicable. (The related ISO Requirements need then to be added to the audit checklist below.) - tailored completely, commented in create safety management process description score#329
• Action: The related page for Platform Safety Plan cannot be found on the Eclipse web site. The topic needs to be re-addressed. - see process: define safety_management plan score#399
• Action: A Safety Plan describes the objectives of the planning activity (to plan, to monitor and to measure), but it remains unclear how the objectives are reached - should be covered by issue planning
• Action: The tool evaluation is still in progress. (subject of later audit)
• Action: it needs to be checked if the classification is ISO PAS 8926 compliant. - we think it is
• Finding: A qualification process based on the software component’s classification is not yet described. - see module safety plan, now also referenced in the safety management guideline
• Action: The related page for the classification of software components cannot be found on the Eclipse web site. The topic needs to be re-addressed. - see create safety management process description score#329

Change Mgt:

• Finding: Evidence missing that "A contributor cannot approve his own change request" applies to all roles. (JochenH)

Requirements (prio 1):

• Finding: Tool is not yet implemented to create the hash attribute (197)
• Finding: It’s not clear when a requirement has been created or updated. It’s recommended to surface these attributes in Eclipse.
• Finding: The content of “process/process_model/guidance/requirements/index.html#concept-description” cannot be found at “https://eclipse-score.github.io/score (tbd)
• Action: Requirements related to tools need to be audited. (subject of later audit)
• Action: AoU (Assumption of Use) requirements need to be audited. (subject of later audit)
• Finding: The AoUs shall be automatically populated into the Safety Manuals. (AlexanderS)
• Action: It need to be clarified if the Safety Manuals for the Feature level are missing in the upper picture. (AlexanderS)
• Finding: The requirements formulation template should include subjects for tool requirements (AlexanderS)
• Recommendation: A (tool supported) process is needed for the ASIL inheritance for decomposed requirements in future if ASIL B is not the maximum ASIL anymore. Hint: even in today’s safety concepts ASIL decomposition is sometimes used to reach ASIL B. (not relevant now)
• Finding: The requirement “GD_REQ_linkage_safety” shall be changed. The requirements that at least one parent requirement shall have the same ASIL level the downstream requirement shall be deleted. It might be the case that the platform supports higher ASILs than needed by a project. (JochenH)
• Finding: The Checklist question 2 of the requirements review checklist needs to be reformulated. The ISO terms of the characteristics are not suitable for a checklist. The checklist shall ask questions which then lead to the compliance of the requirement with being unambiguous, comprehensible, etc. (AlexanderS)
• Finding: The chapter Requirements Guidelines need to be changed. The statement that “The ID consists of an 8 digit hex value.” is not valid anymore. (JochenH)
• Finding: The requirements inspection checklist question 5 need to be reclassified. The need for timing requirements shall be asked for all ASIL / QM levels. Potentially the ASIL classification column can be deleted. (AlexanderS)
• Finding: The formal inspection review process needs to be audited. (AlexanderS to define the process)
• Finding: The Configuration Management of the requirements needs to be audited. Baselines of a complete set of requirements shall be described, not only the version management of single requirements. (AlexanderS)

Architecture:

• Finding: The use of UML shall be specified in order to limit the definition of UML to a useful subset. (AlexanderS)
• Finding: It’s not specified at which level dynamic views are expected. (Trivial views (e.g., function call) may be excluded. (AlexanderS)
• Finding: It should be specified that negative cases in dynamics views should be documented. (AlexanderS)
• Finding: The traceability concept description shall take the traceability of the requirement to the design into account. (MarkusS)
• Finding: The ASIL allocation of the architectural elements shall be visible in the diagrams (JochenH)
• Finding: The language interface (Rust, C++) should be visible within the interfaces. (JochenH)
• Finding: Criteria shall be defined, in which cases dynamic views are required on Feature (and Component) level. (same as 2nd finding above)
• Finding: It shall be defined what a sub-component is. (AlexanderS)
• Finding: The caption of Fig. 19 “Definition of the static model architecture” should be changed as the architecture is based on components (and not on modules). (JochenH)
• Finding: Traceability from/ to the architecture to/ from the code is not given yet. (MarkusS)
• Finding: Formal Inspection Reviews shall be defined for the Software Design. (tbd)
• Finding: The complexity criteria (e.g. number of interfaces, size of interfaces) shall be specified (ARC_03_03). (tbd)
• Recommendation: Review checklist questions shall not only be answered by yes / no. (AlexanderS)
• Recommendation: Checklists consist of a ASIL/ QM classification which should be removed. (AlexanderS)
• Finding: There shall be a thorough description of how to work with checklists (../process/process_model/guidance/architecture/checklists/architecture_inspection_checklist.html) (AlexanderS)
• Finding: Checklist shall be listed in the directory (document management) (tbd, doc indexing tool issue)

Verification Mgt:

• Action: An argument shall be provided which covers the ISO 26262 requirement that all test levels are executed in a target near environment. (PhilippA)
• Finding: The methods of ISO 26262 shall be explained: E.g. what is meant with “static code analysis”? (PhilippA)
• Finding: The Coverage target values as listed by table 37 need to described in more detail. E.g. what is meant by “Coverage of detailed/architectural design” (Sequence diagram coverage?) (PhilippA)
• Finding: It needs to be clarified where the reference system is located physically (affecting e.g. access rights). (PhilippA)
• Action: The tool Bazel needs to be evaluated as it may not be able to see the dependencies of changes in requirements, code and tests and may skip some tests. Define the counter measurements. (tbd)
• Finding: The test shall have an attribute which level the test case belongs to. Second it‘s not clear which test belongs to which level; this shall be fixed. Third, the application of the test methods must be recognizable (e.g. boundary value analysis, equivalence class definition, interface-based testing, ...). (PhilippA)
• Finding: The Verification Plan does not define the required review activities (for reuse of OSS existing tests). (tbd)
• Finding: The independence of the verification team is not yet described in the Verification Plan (tbd)
• Finding: It remains unclear how much Verification reports will be created (one per module?) (AlexanderS)

Notes:

• Findings shall be resolved (and presented in follow-up audit)
• Recommendations may be resolved, if not comment here in the ticket
• Actions are usually "reminders" for the auditors in follow-up audit because the topic could not be presented already (gap in process)