Process Model review

[dcalavrezo-qorix]

Perform a review of the process model and list the findings in this issue

use mandatory, minor and remark

[dcalavrezo-qorix]

Minor

https://eclipse-score.github.io/score/main/process/introduction/index.html

rephrase to: "establish traceability from the beginning "

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/introduction/index.html

You provide a list of standards, but there is no explicit mapping to them in the diagram nor in the description.

For example: it is stated iterative collaboration model initiated by contribution requests - you could emphasis that RASIC matrices are being used ( they are depicted in the diagram) and that it ensures compliance with ASPICE and ISO 21434’s process requirements.

[dcalavrezo-qorix]

Mandatory

https://eclipse-score.github.io/score/main/contribute/contribution_request/contribution_request.html#gd_guidl__contr_request_guideline

Define clear roles and responsibilities: use a RASIC matrix to define roles in the contribution process, ensuring clarity in responsibilities.

TBH, I personally don't know which roles and responsibilities we have at the moment, so that would be helpful

Later edit: the roles are defined https://eclipse-score.github.io/score/main/process/roles/index.html#rl__contributor but I still didn't find a RASIC matrix.

Here is a possible example:

RASIC Matrix for SCORE Process Contributions

Activity	Contributor	Committer	Technical Lead	Project Lead	Quality Manager	Reviewer
Submit a contribution request	R	I	C	I	I	I
Implement a new feature	R	S	S	I	I	I
Perform code review	S	R	I	I	A
Approve a merge request	I	R	C	A	C	C
Conduct safety & security assessment	I	C	I	I	R
Define and update process guidelines	C	C	A	R	C	I
Perform compliance checks	I	C	C	C	R	S
Merge an approved pull request	I	R	I	A	I	I

RASIC Key:

• R (Responsible): Performs the task.
• A (Approver): Reviews and approves the work.
• S (Support): Assists in task completion.
• I (Informed): Needs to be updated on progress.
• C (Consulted): Provides input before decisions are made.

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/contribute/contribution_request/contribution_request.html#gd_guidl__contr_request_guideline

Based on the comment from above and this statement
Required reviewers will be automatically assigned based on the contributed content (via CODEOWNERS)

... maybe a Reviewer role should also be defined?

[dcalavrezo-qorix]

Mandatory

https://eclipse-score.github.io/score/main/contribute/contribution_request/contribution_request.html#gd_guidl__contr_request_guideline

I think we should mention here the branching strategy and what exactly means to merge a PR

https://eclipse-score.github.io/score/main/contribute/contribution_request/contribution_request.html#detailed-score-pull-request-workflow

Check this link

Strategy	Pros	Cons
Trunk-Based Development	✅ Continuous integration ensures fewer merge conflicts ✅ Simplifies release management	❌ Harder to track individual company contributions ❌ High coordination effort
Feature-Branch Development (Git-Flow)	✅ Clear isolation of features ✅ Easier tracking of company contributions ✅ Maintains stable main	❌ Can lead to long-lived branches, increasing merge complexity
Alternative: Company-Specific Feature Branching	✅ Each company works in their own branch ✅ Clear contribution ownership ✅ Still allows rebasing on the latest main ✅ Preserves a stable baseline	❌ Requires structured merging to avoid divergence

[dcalavrezo-qorix]

Mandatory

https://eclipse-score.github.io/score/main/process/workproducts/index.html#

I don't see the tools specified in here. We do develop in-house tools ( copyright checkers, licensing checkers, etc) - I think that tools should be specified and Part 8 of ISO 26262 should be added.

[dcalavrezo-qorix]

Minor

https://eclipse-score.github.io/score/main/process/workproducts/index.html#

In the Platform Management Plan it is stated that Documentation guideline requirements must be defined for each WP. Each work product or document must include a title, author and approver, unique revision identification, change history, and status.

Shouldn't the Review information also be present? It should comprise from

• Assigned Reviewers
• Review Date
• Review Outcome

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/workproducts/index.html#process

Maybe add a short description for Process Definition and Process improvement report ? (even if they are still in draft )

[dcalavrezo-qorix]

Minor

https://eclipse-score.github.io/score/main/process/workproducts/index.html#

Feature Safety Analyses not sure why plural is used

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/workproducts/index.html#supporting-activities

A Software tool criteria evaluation report is mentioned as a WP, but where exactly is the tool evaluation process defined?

same as this comment.

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/general_concepts/score_lifecycle_concept.html

Maybe add a feedback loop from the maintenance phase to the other two ( concept and development) ?

This would adhere to the ASPICE Continuous Improvement model.
Also real-world failures should be fed back into the hazard analysis.

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/general_concepts/score_building_blocks_concept.html#building-blocks-meta-model

Find a better way to reference part of the image

The following figure gives an overview about the building blocks of the S-CORE Platform (blue box, top, 2nd column). The objectives of the platform of the S-CORE platform include enabling of feature integration for different use cases and domains. This includes safety-critical applications. Thus the intention is, that the platform can be developed as a Safety Element out of Context (SEooC) (green box, top, 1 column). The objectives of the platform are expressed as concrete Stakeholder Requirements (blue box, top, 2nd column), which can be tested by provided Platform Tests (blue box, top, 5nd column) for reference hardware platforms. The platform consists of Features (yellow box, middle, 2nd column).

It might be possible inside the PlantUML diagram to define links

@startuml
rectangle "Work Products" as WP [[#workproducts]]
@enduml

which in the SVG become hyperlinked elements that we could refrence.

[dcalavrezo-qorix]

Remark

https://eclipse-score.github.io/score/main/process/general_concepts/score_building_blocks_concept.html#building-blocks-meta-model

Shouldn't we have a hierarchical decomposition of building blocks for the whole project?

Something like:

S-CORE Building Block	Real-World Representation	Example
Platform	Entire S-CORE system	Eclipse S-CORE GitHub organization
Feature	A specific safety monitoring feature	safety-monitoring GitHub repository
Software Module	A logical module inside the repository	safety_analysis/ subdirectory
Component	Individual files implementing the feature	fault_detection.cpp
Unit	The smallest testable software element	FaultDetection::AnalyzeFailure()