process: general traceability concept #343
Conversation
masc2023
force-pushed
the
masc2023_create_general_concepts
branch
from
c52dee6 to
c70e771
Compare
|
The created documentation from the pull request is available at: docu-html |
There was a problem hiding this comment.
In our architecture discussions we talked about linking component requirements to componenents and not subcomponents?
Same applies for the implementation. Also do we need the implementation as an integral part of our traceability concept? Or do we use the link to the implementation only for "user convenience"? Shall we also explicitly mention that implementation includes tests?
There was a problem hiding this comment.
Implementation includes Detailed Design and Source Code, shall be part of our integral part of our traceability, compare ASPICE standard. Test are mentioned in addition, Unit Test or Component Integration Test.
Sub-components are part of a takeover, needs discussion, let's setup a special meeting to discuss that
There was a problem hiding this comment.
Linking to components req: done in our pilot component (json reader) from component and from sub-component. And it made sense to do this as part of architecture work.
There was a problem hiding this comment.
I assume we would also have test cases for feature requirements? So do we need to show how to link those to "implementation" as well?
There was a problem hiding this comment.
We need to discuss feature and module definition again, seems not clear yet to everyone, also work products need re-visit, if you agree the we can add here the examples from POC here?
There was a problem hiding this comment.
As I understand this view the feature integration tests are omitted in this picture on purpose. These are in wp_overview. In wp_overview "Component Integration Test" are in my opinion linked wrongly to "Implementation" because those test the integration of the sub-components to components, i.e. the Component Architecture and not the Detailed Design (part of Implementation). If there is no component architecture there also are no component integration tests. Maybe we need to show both situations?
There was a problem hiding this comment.
Currently we aligned with the tool team that we would try to skip the tool requirements
There was a problem hiding this comment.
Yes, can delete that
| requirements level. Starting from top, the platform level, going down to feature, component | ||
| to the bottom the unit level. The concept is based on the classical V-Cylce approach. | ||
|
|
||
| .. figure:: _assets/score_traceability_model_wp_overview.svg |
There was a problem hiding this comment.
Any reason you are not using .drawio.svg as shown here: https://eclipse-score.github.io/score/main/guidance/docs-as-code.html#draw-io
There was a problem hiding this comment.
Was not part of discussion we used that already in the POC, why did you not consider that?
There was a problem hiding this comment.
Does this docs-as-code guideline request to use VS code? Cannot another drawio app be used?
There was a problem hiding this comment.
Does this docs-as-code guideline request to use VS code?
That's not intentional. I'll have a look.
Cannot another drawio app be used?
Yes, but generally we want to have .drawio.svg files. I'm not sure whether those are technically different than .svg files, or whether that's purely a naming convention. We use .drawio.svg to clearly identify that those files can be edited via draw io.
There was a problem hiding this comment.
Update: I've tried editing your .svg files. I can edit them. So it's purely a naming convention to store drawio-svgs as .drawio.svg.
docs/process/general_concepts/_assets/score_traceability_model_cmp_overview.svg
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Do we have sub-component requirements?
There was a problem hiding this comment.
Under discussion as take-over from POC
There was a problem hiding this comment.
No we do not have sub-component requirements, but these may be detailed enough to link to single sub-components
docs/process/general_concepts/_assets/score_traceability_model_cmp_overview.svg
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
how about simple components which do not have sub-components?
Sorry about all the questions, maybe this is the wrong place.
There was a problem hiding this comment.
Simple components are no problem, will add the examples images from the POC to make the definition more clear soon
There was a problem hiding this comment.
as suggested above: maybe we add a traceability picture also for the components without sub-components.
There was a problem hiding this comment.
I cannot find the difference between a component and a module anywhere in the documentation?
There was a problem hiding this comment.
Need to take over examples images from the POC
There was a problem hiding this comment.
this difference will be documented in detail in the architecture guidance, but maybe we need to spend a few words on the "modules" i.e. that they are the "bazel modules" containing the components?
|
The created documentation from the pull request is available at: docu-html |
1 similar comment
|
The created documentation from the pull request is available at: docu-html |
Document general concept for traceability of work products Resolves: #319
masc2023
force-pushed
the
masc2023_create_general_concepts
branch
from
af9459b to
2cce93e
Compare
|
The created documentation from the pull request is available at: docu-html |
Document general concept for traceability of work products
Resolves: #319