Legal information

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. 


FeatureConsolidatedHandover
OperationalFor 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
SystemFor 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?
LogicalFor 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
PhysicalFor 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:

  • Assemble all the artefacts to be reviewed, as specified by the artefacts list on the review's Confluence page;
  • Secure time from the expert reviewers and the design authority for their review
  • Set an appointment for discussing the results of 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 actionsBlocking 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

NarrativeTicketed 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

CREATEDIN IMPLEMENTATION

TO DOIN PROGRESS

(not yet created)
Finishing the draft of all the artefacts needed for the epic

IN IMPLEMENTATIONREADY 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 REVIEWIN PEER REVIEW

IN PEER REVIEWDONE

IN PROGRESS

CREATEDIN 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 PREPARATIONREVIEW 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 REVIEWIN PEER REVIEW

IN PEER REVIEWDONE

IN PROGRESS

REVIEW IN PROGRESSCORRECTIONS

CORRECTIONSIN PREPARATION

Design authority signs off the review (ARCH.R.x.13)

DONE

IN PROGRESSDONE

REVIEW IN PROGRESSCONCLUDED