inspection record need type#661
Conversation
Adds the mod_insp need type to the metamodel with evidence and inspects extra links, documents the tool requirement, and adds option tests. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
License Check Results🚀 The license check job ran with the Bazel command: bazel run --lockfile_mode=error //src:license-checkStatus: Click to expand output |
|
The created documentation from the pull request is available at: docu-html |
FScholPer
changed the title
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
Some questions on the usage in the inline comments
| # req-Id: tool_req__docs_common_attr_status | ||
| status: ^(valid|invalid)$ | ||
| # req-Id: tool_req__docs_inspection_record_need | ||
| inspection_type: ^(requirements|architecture|implementation|traceability|safety_analysis|security_analysis|other)$ |
There was a problem hiding this comment.
there are only inspections of type "requirements|architecture|implementation"
| # req-Id: tool_req__docs_inspection_record_need | ||
| inspection_type: ^(requirements|architecture|implementation|traceability|safety_analysis|security_analysis|other)$ | ||
| inspection_state: ^(planned|in_review|rework_required|approved)$ | ||
| checklist_ref: ^.*$ |
There was a problem hiding this comment.
in your example this links to a template (gd_temp), but why have this attribute? information can be derived already from "inspection_type"
| checklist_ref: ^.*$ | ||
| reviewers: ^.*$ | ||
| optional_options: | ||
| checklist_type: ^(req|arc|impl|safety|security|custom)$ |
There was a problem hiding this comment.
somehow a duplicate of "inspection_type"
|
|
||
| # Formal inspection evidence modeled as a first-class artifact. | ||
| # req-Id: tool_req__docs_inspection_record_need | ||
| mod_insp: |
There was a problem hiding this comment.
I do not fully understand how this will be used. My assumption based on the example in eclipse-score/persistency#330 is that it is a part of the verification report but has one instance per each inspection evidence. E.g. in baselibs this would be about ten records for requirements inspections (one per avery component). Comments given based on this assumption.
| status: ^(valid|invalid)$ | ||
| # req-Id: tool_req__docs_inspection_record_need | ||
| inspection_type: ^(requirements|architecture|implementation|traceability|safety_analysis|security_analysis|other)$ | ||
| inspection_state: ^(planned|in_review|rework_required|approved)$ |
There was a problem hiding this comment.
state "planned" is the same as having a checklist document in "draft" state, "in_review" would be as long as the PR to fill out the checklist is in draft/open, "rework_required" would mean checklist has a "NO", "approved" means all checkpoints are "YES". Expect this is filled out automatically?
| approver: ^.*$ | ||
| findings_total: ^[0-9]+$ | ||
| findings_open: ^[0-9]+$ | ||
| pr_link: ^https://github\.com/[^/]+/[^/]+/pull/\d+$ |
There was a problem hiding this comment.
Which PR? What is it needed for?
| findings_total: ^[0-9]+$ | ||
| findings_open: ^[0-9]+$ | ||
| pr_link: ^https://github\.com/[^/]+/[^/]+/pull/\d+$ | ||
| correction_issue: ^https://github\.com/[^/]+/[^/]+/issues/\d+$ |
There was a problem hiding this comment.
is it really needed here? can be seen in checklist (linked in below "evidence")
| findings_open: ^[0-9]+$ | ||
| pr_link: ^https://github\.com/[^/]+/[^/]+/pull/\d+$ | ||
| correction_issue: ^https://github\.com/[^/]+/[^/]+/issues/\d+$ | ||
| inspection_date: ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ |
There was a problem hiding this comment.
what do you use this for? I do not think you can judge from the date if it is still valid.
| inspects: ANY | ||
| optional_links: | ||
| # req-Id: tool_req__docs_inspection_record_need | ||
| contains: ANY |
There was a problem hiding this comment.
"contains" makes no sense in inspection record (at least if it is the same usage as in verification report). Or do you want to pack inspection records in inspection records?
| supported_by: role | ||
| tags: | ||
| - inspection | ||
| - verification_evidence |
There was a problem hiding this comment.
it is not an evidence?
2 participants
Relates to #611
Split out of #612 (inspection part). The verification-report part is in a separate PR.
📌 Description
Adds a machine-readable module inspection record need type to the metamodel.
metamodel.yaml: newmod_inspneed type (prefix: mod_insp__) classifying an inspection byinspection_typeandinspection_state, recordingchecklist_ref/reviewersand optional moderator/approver/findings/date attributes; linksbelongs_toamodandinspectsthe inspected artifacts, with optionalcontains/evidence/approved_by/supported_by. Adds theevidence(evidence/evidence_for) andinspects(inspects/inspected_by) extra links it depends on.requirements.rst: new "Verification Evidence" section withtool_req__docs_inspection_record_need, plus theVerifrow in the requirements overview table.rst/options/test_options_inspection_record.rstcovering a valid record and an invalidinspection_statevalue.🚨 Impact Analysis
✅ Checklist
Frank Scholter Peres frank.scholter_peres@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH
Provider Information