Problem Resolution Plan		status: draft safety: ASIL_B
status: draft tags: platform_management realizes: wp__prm_plan safety: ASIL_B

doc__platform_problem_resolution_plan		Generic Document

Problem Resolution / Problem Resolution Plan#

This document implements parts of the Platform Management Plan (wp__platform_mgmt).

Purpose#

The purpose of the Problem Resolution is to guide the resolution of project problems including their creation, analysis, resolution, and control. Where a problem is defined as a deviation of an expected result.

Objectives and Scope#

Problem Resolution Goals#

Problems are recorded, identified and classified.
Problems are analyzed and assessed to determine an appropriate solution.
Problem resolutions are initiated and monitored.
Problem resolutions are closed and communicated to affected parties.

Approach#

Problem Resolution Execution#

Contributions in general to the S-CORE project are described here (compare Contribution Request Guideline (gd_guidl__contr_request_guideline)).

A Problem Resolution is a specific contribution, and it is the ONLY way to report problems in the S-CORE project.

Problem Resolution Infrastructure#

GitHub Issues (ISSUE) (gd_guidl__issue_guideline) are used for managing problems and their potential resolution. The tool is used to create, analyse, initiate and to monitor the problem reported within S-CORE.

The next figure gives an overview, how problems are created in S-CORE. An ISSUE is used to create a problem report including required attributes as defined in the Problem Process Requirements. Therefore the Problem Template Problem Report Template shall be used.

Problem Resolution Attributes#

Problem Attributes are implemented as follows:

Problem attribute: UID is identical to the ISSUE number.

Problem attribute: status is defined by the combination of the ISSUE state and the state in the Projects dashboard view. The PR status is also used, if applicable.

Table 39 Problem Status#
Status	Issue status	Projects dashboard status	Linked PR status
open	`Open`	`No Status`	na
in review	`Open`	`Todo`	na
in implementation	`Open`	`In Progress`	`Draft` or `Open`
closed	`Closed`	`Done`	`Merged`
rejected	`Closed`	any beside `Done`	na

Problem attribute: title is identical to the ISSUE title.

Problem attribute: description is defined in the description part of the ISSUE using the Problem Template Problem Report Template.

Problem attribute: analysis... is defined in the description part of the ISSUE using the Problem Template Problem Report Template.

Problem attribute: stakeholder is defined in the description part of the ISSUE using the Problem Template Problem Report Template. For S-CORE stakeholder use pre-defined labels for Communities or Cross Functional Teams (Feature Owner).

Problem attribute: classifi... is defined in the description part of the ISSUE using the Problem Template Problem Report Template. For S-CORE labels are defined as:

Table 40 Problem Classification#
Classification identifier	Label
minor	`minor`
major	`major`
critical	`critical`
blocker	`blocker`

Problem attribute: category is defined in the description part of the ISSUE using the Problem Template Problem Report Template. For S-CORE labels are defined as:

Table 41 Problem Categories#
Category	Description	Infrastructure
User	Created by any user or Contributor (rl__contributor) to report potential identified problems	ISSUE with type BUG
Bug	Created by Contributor (rl__contributor) to report problems found during verification	ISSUE with type BUG and with label `<test level>`

Problem attribute:: safety ..., Problem attribute:: securit..., Problem attribute:: quality... are defined in the description part of the ISSUE using the Problem Template Problem Report Template. For S-CORE labels are defined to mark affected ISSUEs: safety, security, quality

Combinations of them are allowed.

Problem attribute: milestone is defined by the Milestone of a ISSUE.

Problem Resolution Workflow#

In general, every Problem Resolution follows the following steps:

(color is refering to the following figure: Problem Resolution Simple Workflow Overview)

1. Create the Problem report (grey color)
1. Analyse the Problem report (blue color)
1. Initiate the implementation of the Problem Resolution and track it to closure (yellow color)
1. Close Problem Resolution (purple color)

To 1. Create the Problem Report:

An ISSUE is the ONLY way to create and manage a Problem in S-CORE.

The figure below shows the workflow for the simplest case of a Problem Resolution workflow.

An ISSUE with the type Bug is created in status Open. The title of the ISSUE reflects the potential problem. Further add here the Problem Template (gd_temp__problem__template) and fill it out accordingly.

Planning is done by setting the milestone of the ISSUE accordingly.

Problem status: open is implemented as ISSUE status Open and Projects status No Status.

To trigger the next step: Problem status: in review keep the ISSUE status Open and set the Projects status Todo.

To reject the problem report: Problem status: rejected set the ISSUE status to Closed.

Fig. 24 Problem Resolution Simple Workflow Overview#

To 2. Analyse the Problem Report:

The Problem Report is reviewed and analysed from the Committer (rl__committer) and the review results are resolved by the Contributor (rl__contributor). The results are documented in the ISSUE. As long as the information is not sufficient, the related ISSUE is kept in status Open and Projects status Todo, means in review.

If the information is sufficient and it is decided to initiate the problem resolution, the ISSUE status is kept Open and the Projects status is set to In Progress.

Problem Checklist can help to verify whether the information is complete.

In case affected parties need to be informed Technical Lead (rl__technical_lead) or Module Lead (rl__module_lead) will notfiy them.

Otherwise, if no Problem Resolution is planned, the problem is rejected. To reject the Problem Report: Problem status: rejected set the ISSUE status to Closed.

To 3. Initiate and Monitor the Problem Resolution:

Contributor (rl__contributor) starts all required activities to resolve the problem. These may include starting Change Requests or in general plannig activites by creating ISSUEs and required PRs.

All ISSUEs or PRs created to resolve the problem are linked to the Problem Report ISSUE to enable monitoring of the activities.

All activities defined are tracked until closure, means that all linked ISSUEs or PRs are closed or merged, respectively.

If all are closed or merged Contributor (rl__contributor) sets Projects status to Done to trigger the final review from the Committer (rl__committer) to close the Problem Resolution.

The Problem Resolution may also rejected in this phase, then the ISSUE status is set to Closed.

To 4. Close the Problem Resolution:

Committer (rl__committer) checks finally if the problem is completely resolved. In this case all linked ISSUEs or PRs are closed or merged, respectively.

Especially the solution measure must be checked for their effectivness and the argumentation is convincing.

Problem Checklist can help to verify whether it can be closed.

If this is the case the ISSUE status is set to Closed, otherwise the Projects status is set back to In Progress.

Problem Resolution SW Platform Work Products#

not applicable