Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Design review structure
SM-2904
-
Define design review structure for ARCH process area
Finished
Content
1. Proposed overall structure
This diagram only shows the design reviews proposed for the ARCH process area. Before issuing specifications, further reviews will be needed, and these will belong to GEN process area.
The structure of capabilities and capability sets is shown below. These definitions are important for understanding the scope of the reviews defined.
2. Design review matrix - overall questions answered
Note: the question of versions and variants is not covered here. It is possible that a particular capability x could be included in multiple packages (consolidated reviews) at different versions or for different environmental variations. This would be dealt with separately in the feature modelling work and is not differentiated in the review structure.
Feature | Consolidated | Handover | |
---|---|---|---|
Operational | For a single operational capability, were the process steps completed? | For all completed operational capabilities, is the operational architecture fit to be transferred to the system architecture? | N/A |
System | For a single system capability, were the process steps completed? | For all completed system capabilities, is the system functionality fit to be transferred to the logical architecture? | Is the integrated system functionality fit to be simulated/converted into a system specification? |
Logical | For a single logical capability realisation, were the process steps completed? | For all completed capability realisations, is the logical architecture fit to be transferred to the physical architecture? | N/A |
Physical | For a single physical capability realisation, were the process steps completed? | For all completed capability realisations, is the physical architecture complete and integrated into tenderable subsystems? | Is the integrated subsystem functionality fit to be simulated/converted into a subsystem specification? |
3. Generic design review workflow (for instantiation for all design reviews)
SM-3480
-
Create generic process flow for any review
Finished
3.1.
Explanatory notes
ARCH.R.x.1 Check artefacts against modelling rules ARCH.R.x.2 Check artefacts against content criteria | Before organising a review with the expert reviewers and the design authority, the review applicant should satisfy themselves that the modelling rules and content criteria have been fulfilled. There is no requirement to record this stage of the review; it is left to the review applicant to decide how best to manage any actions that arise at this point. |
---|---|
ARCH.R.x.3 Organise the review | The following main actions are required to organise the review:
|
ARCH.R.x.9 Record non-blocking corrective actions | Suggested way of working is to create a new Jira ticket on the to-do list for the corresponding epic, and to close the original ticket to show that it was considered SETT in this review. These actions can then be done at a time that suits the owning team. Alternatively, where the owner of the capability intends to close out these actions immediately (that is, before closing the review), the non-blocking corrective actions can be entered by adding a comment to the original ticket, and that ticket can be moved back to In Progress. |
ARCH.R.x.11 Record blocking corrective actions | Blocking corrective actions should be entered as comments on the original ticket, and that ticket should be moved back to In Progress. |
ARCH.R.x.12 Record completion of blocking corrective actions | Completed blocking corrective actions should be noted as comments on the corresponding ticket. When all blocking corrective actions are complete, the ticket should be moved back to Ready for review. |
3.2. Workflow
4. Ticketing in Jira
A capability set is a grouping of capabilities that must be delivered at a certain milestone and in the context of a certain set of environmental characteristics. A capability set will correspond to features defined in the feature tree.
5. How to manage ticket status during a design review
Narrative | Ticketed activity from process (individual issue) | Single capability ticket / Capability set ticket (epic) | Design review ticket (individual issue, special type) |
---|---|---|---|
Starting a set of activities that produce an artefact used by a review | CREATED → IN IMPLEMENTATION | TO DO → IN PROGRESS | (not yet created) |
Finishing the draft of all the artefacts needed for the epic | IN IMPLEMENTATION → READY FOR REVIEW | IN PROGRESS | CREATED |
Prepare for the design review: begin by checking model rules and content within the producing team (ARCH.R.x.1, ARCH.R.x.2) Correct anything found to be a problem before continuing into design review | READY FOR REVIEW → IN PEER REVIEW IN PEER REVIEW → DONE | IN PROGRESS | CREATED → IN PREPARATION |
Gather the artefacts and organise availability of expert reviewers and design authority (ARCH.R.x.3) | DONE | IN PROGRESS | IN PREPARATION |
Expert reviewers and design authority evaluate the content (ARCH.R.x.4-11) | DONE | IN PROGRESS | IN PREPARATION → REVIEW IN PROGRESS |
If required: Carry out & record completion of blocking corrective actions (as new tickets) (any ARCH as required, ARCH.R.x.12) When all done, go back to ARCH.R.x.3 | CREATED → IN IMPLEMENTATION IN IMPLEMENTATION → READY FOR REVIEW READY FOR REVIEW → IN PEER REVIEW IN PEER REVIEW → DONE | IN PROGRESS | REVIEW IN PROGRESS → CORRECTIONS CORRECTIONS → IN PREPARATION |
Design authority signs off the review (ARCH.R.x.13) | DONE | IN PROGRESS → DONE | REVIEW IN PROGRESS → CONCLUDED |