Repository navigation
Doc: Implementation Process Description - #526
Conversation
|
The created documentation from the pull request is available at: docu-html |
82e2575 to
92d3a21
Compare
aschemmel-tech
left a comment
There was a problem hiding this comment.
As this is "Draft" I only leave comments:
- see inline plus some general ones:
- SW development plan document should be mentioned in process and created in this PR
- Metamodel change for DD artefacts is missing
- Detailed_design_checklist is missing (may be reused from incubator)
| | :id: UNIT_DD_STA__<Component>__<Title> | ||
| | :security: <YES|NO> | ||
| | :safety: <QM|ASIL_B|ASIL_D> | ||
| | :satisfies: <link to component requirement id> |
There was a problem hiding this comment.
according to docs/process/general_concepts/_assets/score_building_blocks_meta_model.svg (in #343) we expect "implements" link from DD to Component req and "satisfies" link from DD to Component Architecture.
There was a problem hiding this comment.
Implements link added
There was a problem hiding this comment.
implements link commented out in metamodel, why?
There was a problem hiding this comment.
Jochen will check and improve the metamodel in seperate branch
| :status: valid | ||
| :complies: std_wp__iso26262__software_10, std_req__iso26262__software_29 | ||
|
|
||
| Implementation of a Unit |
There was a problem hiding this comment.
https://github.com/eclipse-score/score/blob/main/docs/process/workproducts/index.rst already defines relevant work products: wp__sw_implementation, wp__sw_unit_test, wp__sw_code_inspect -> expectation is to reuse these and remove from the "general" workproducts/index
There was a problem hiding this comment.
Reuse of wp__sw_implementation, wp__sw_unit_test. Unclear how to proceed with wp__sw_code_inspect
There was a problem hiding this comment.
Now there is a wp__sw_code_design_inspect and a wp__sw_code_inspection - the latter should be deleted.
There was a problem hiding this comment.
Also need a discussion about wp__sw_static_analysis and wp__sw_dynamic_analysis - what is the real work product? My understanding was that it would be a report generated by a tool - and this would be part of wp__module_sw_verification_report
There was a problem hiding this comment.
the workproducts shall comply to iso 26262 wp and not to req
| Workflow Implementation | ||
| ####################### | ||
|
|
||
| .. ? Haben wir einen Workflow für Implementation |
There was a problem hiding this comment.
no, we had not, but we need, please create those workflows for all the work procucts of impl. process
There was a problem hiding this comment.
Workflows for Detailed Design an Unit Test created.
There was a problem hiding this comment.
There is now a workflow for creation of detailed design but not of source code. Likewise there is a code inspection but no DD inspection. Recommend to create a workflow "create implementation" and "verify implementation" with the respective outputs.
There was a problem hiding this comment.
That is not sufficient as a guideline. I expect even three guidelines: Detailed Design, Guideline C++, Guideline Rust
And it should define for example for DD: how to fill the template, e.g. which UML diagrams types to use, do we have also Doxygen Style comments for the DD in code (I thought so) ...
And for the C++ guideline: how do we configure the SW, how do we expect comments, how do we do the MISRA checker annotations ...
There was a problem hiding this comment.
Currently I´m working on those hopefully I can push a draft today. The checker annotations highly depend on a tool which we still have to decide for
License Check Results🚀 The license check preparation job ran successfully. Status: Click to expand output |
3777475 to
6486e0c
Compare
|
@PandaeDo , @vinodreddy-g, can you please open official review and push your branch, at the moment I am not able to build it locally, difficult to review, thank you |
3139d90 to
16f4147
Compare
@masc2023 to build it locally you have clone from here qorix-group:vohae_detailed_design , since creating a branch directly on the main score repo is possible only for the committers. |
3e41405 to
afaa7ab
Compare
| Static Diagrams for Unit Interactions | ||
| ------------------------------------- | ||
|
|
||
| .. unit_dd_sta:: dd example static |
There was a problem hiding this comment.
Shall we create a process requirement for plotting an an automated figure compared to the architecture?
There was a problem hiding this comment.
No , i think creating a static architecture at unit level to reflect a design pattern might be difficult to automate and i think might be better to do it manually to better think of the design.
There was a problem hiding this comment.
Added as process requirements
| - | ||
|
|
||
| * - IMPL_02_01 | ||
| - Is the MISRA report verified for violations which are safety critical? |
There was a problem hiding this comment.
Are all findings of the static code analysis fixed, marked as FP or justified?
There was a problem hiding this comment.
Currently I´m working on those hopefully I can push a draft today. The checker annotations highly depend on a tool which we still have to decide for
| - Are the manual check <TBD> of MISRA rules done? | ||
| - | ||
| - | ||
| - |
There was a problem hiding this comment.
Is the coverage metrics fulfilled?
There was a problem hiding this comment.
Described as discussed.
| :satisfies: wf__impl__detailed_design | ||
| :complies: std_req__iso26262__software_27 | ||
|
|
||
| The Unit Design shall archieve the following properties |
There was a problem hiding this comment.
For process requirements I would expect something which you could test via tools. So is this requirement maybe something which should end up in a checklist?
There was a problem hiding this comment.
Delete it from the Process Requirements and add a question on the checklist.
| :satisfies: wf__impl__detailed_design | ||
| :complies: std_req__iso26262__software_33 | ||
|
|
||
| For structual coverage a branch coverage shall be used. Therefore the tool <TBD> is selected. |
There was a problem hiding this comment.
I would keep the process requirements independent of the tool. The tooling we could document as a some kind of decision
There was a problem hiding this comment.
Tooling switched to SW Dev Plan.
| :satisfies: wf__impl__detailed_design | ||
| :complies: std_req__iso26262__software_29 | ||
|
|
||
| The Unit Design and Implementation shall archieve the following principles |
There was a problem hiding this comment.
Moved to checklist
|
|
||
| We link the unit id to the comments in the code like - | ||
|
|
||
| For cpp using doxygen style comments- |
There was a problem hiding this comment.
The process description should be free from any tool, the tools used should be part of the Software Development Plan in the folder under platform management plan.
|
|
||
| **Purpose** | ||
| The purpose of this checklist is to collect the topics to be checked during implementation. | ||
| It will be filled out within the github "inspection" pull request. |
There was a problem hiding this comment.
again a concrete tool is mentioned, work product to created, e.g. inspection review, how it is done should be part of Software Development Plan
There was a problem hiding this comment.
Remove the mentioned tool.
e85fe24 to
404e5f8
Compare
404e5f8 to
dc8ee58
Compare
Initial Version of the process description for implementation. Resolves: eclipse-score#309 Signed-off-by: Volker <volker.haeussler@qorix.ai>
| **Purpose** | ||
| The purpose of this checklist is to collect the topics to be checked during implementation. | ||
|
|
||
| **Checklist** |
There was a problem hiding this comment.
please align formatting of the table with other checklists (e.g. for architecture)
| - | ||
| - | ||
| * - IMPL_04_01 | ||
| - Are the <TBD> manual checks that are derived from the c++ coding guideline done? |
There was a problem hiding this comment.
please create ticket and add link here.
| - | ||
| - | ||
| * - IMPL_04_01 | ||
| - Are the <TBD> manual checks that are derived from the c++ coding guideline done? |
There was a problem hiding this comment.
do we also need to refer to Rust language here? Do we have different checklst steps for C++ and Rust?
dc8ee58 to
debf410
Compare
| :input: wp__platform_mgmt | ||
| :output: wp__sw_development_plan | ||
| :contains: gd_temp__software_development_plan | ||
| :contains: doc__software_development_plan |
There was a problem hiding this comment.
please remove, contains is only concept or getting starte, doc__ links only from do__ to the wp
There was a problem hiding this comment.
compare meta model in introduction
There was a problem hiding this comment.
Rechanged it to the Template
|
|
||
| **Create/Maintain Software Development Plan** | ||
| Adaption of the Software Development Plan to the Projekt by using the :need:`gd_temp__software_development_plan`. | ||
| Adaption of the Software Development Plan to the Projekt by using the :need:`doc__software_development_plan`. |
There was a problem hiding this comment.
template was correct, the doc_software_development_plan is already the concrete plan, not a template
There was a problem hiding this comment.
Rechanged to Template after I created the Template
833c8d2 to
fa0bcfe
Compare
masc2023
left a comment
There was a problem hiding this comment.
Major concerns have been resolved
d92203c to
b3e50b5
Compare
aschemmel-tech
left a comment
There was a problem hiding this comment.
Good as initial version
| Template | ||
| --------- | ||
|
|
||
| The detailded design template :need:`[[title]] <gd_temp__detailed_design>` shall be used to ensure that the correct syntax and attribute definition is used. |
There was a problem hiding this comment.
| The detailded design template :need:`[[title]] <gd_temp__detailed_design>` shall be used to ensure that the correct syntax and attribute definition is used. | |
| The detailed design template :need:`[[title]] <gd_temp__detailed_design>` shall be used to ensure that the correct syntax and attribute definition is used. |
| Creation of a detailed design by using the Template :need:`[[title]] <gd_temp__detailed_design>`. | ||
| The detailed design shall be so exact, that test and implementation can be run simultaneously. | ||
| The generated code and tests shall run the checks locally before commiting/pushing changes to a | ||
| branch to avoid unnecessary cycles. The checks can be executed by <TBD>. Use the explenations of |
There was a problem hiding this comment.
| branch to avoid unnecessary cycles. The checks can be executed by <TBD>. Use the explenations of | |
| branch to avoid unnecessary cycles. The checks can be executed by <TBD>. Use the explanations of |
| branch to avoid unnecessary cycles. The checks can be executed by <TBD>. Use the explenations of | ||
| the tools. | ||
|
|
||
| In the CI/CDcd pipeline the checks <TBD> are executed. Use the explenations in the pipeline. |
There was a problem hiding this comment.
| In the CI/CDcd pipeline the checks <TBD> are executed. Use the explenations in the pipeline. | |
| In the CI/CD pipeline the checks <TBD> are executed. Use the explanations in the pipeline. |
| Static Diagrams for Unit Interactions | ||
| ------------------------------------- | ||
|
|
||
| .. unit_dd_sta:: dd example static |
There was a problem hiding this comment.
No , i think creating a static architecture at unit level to reflect a design pattern might be difficult to automate and i think might be better to do it manually to better think of the design.
Fixed copyright header Signed-off-by: Dan Calavrezo <dan.calavrezo.ext@qorix.ai>
36a8de5
Initial Version of the process description for implementation.
Fixes #309