Concept Description#

Concept Description
status: valid
status: valid
tags: problem_resolution
relates to: wf__problem__create_pr, wf__problem__analyse_pr, wf__problem__initiate_monitor_pr, wf__problem__close_pr
doc_concept__problem__process
Concept Definition

In this section a concept for the Problem Resolution will be discussed. Inputs for this concepts are both the requirements of ISO26262 Part-2 and ASPICE Requirements from SUP.9 additionally including the requirements of the different stakeholders for the Problem Resolution process.

Key concept#

A Problem Report is the ONLY way to report (compare Contribution Request Guideline (gd_guidl__contr_request_guideline)) deviations of an expected result for existing features in the S-CORE project. Deviations include problems found by user, bugs found during verification activites by tester, quality issues found by quality checks, safety anomalies, vulnerabilites or any other malfunction.

Inputs#

  1. Stakeholders for the Problem report?

  2. Which categories are required?

  3. Which attributes are required?

  4. Which activities are required?

Stakeholders for the Problem Report#

  1. Contributor (rl__contributor)

    • Contributes features and components to grow the S-CORE content

  2. Committer (rl__committer)

    • Verifies that the contribution fulfills the S-CORE policies

    • Approves the contribution

Standard Requirements#

Also requirements of standards need to be taken into consideration:

  • ISO 26262

  • ASPICE

  • ISO SAE 21434

Problem Report Categories#

User: Problems relating to requirements, design, or code found by user of the platform.

Bug: Problems found by contributor based on component, feature or platform integration tests including verification and quality assurance activities.

Problem Report Attributes#

The required attributes for the Problem Report are defined here: Problem Attributes.

Activities for Problem Resolution#

Creation of the Problem Report#

Use the Problem Report Template to create the Problem Report.

In case safety or security is affected, in addition the impact analysis template : Impact Analysis Template can be used to detail out the impact on safety/security as part of the description.

Anaylsis of the Problem Report#

Based on the analysis results decision about the acceptance or rejection must be taken by authorized persons.

Authorized person includes

  1. Technical Lead (rl__technical_lead)

  2. Module Lead (rl__module_lead)

  3. Safety Manager (rl__safety_manager)

  4. Security Manager (rl__security_manager)

  5. Quality Manager (rl__quality_manager)

Further prioritization must be done, e.g. based on release planning.

Implementation and Monitoring of the Problem Resolution#

If the Problem Report is accepted, the implementation of the resolution must be initiated and monitored.

The Problem Resolution implementation must be tracked until it is closed.

The status of the Problem Report must be communicated by the Technical Lead (rl__technical_lead) or Module Lead (rl__module_lead) until the implementation is completed and confirmed.

Closing of the Problem Resolution#

Use the Problem Report Checklist to control the completeness of the Problem Report to be closed.

Especially the effectiveness of the solution measures must be shown, based on convincing arguments, e.g. verification measures must be used to confirm the implementation.