Purpose
  • To verify that the design model fulfills the requirements on the system, and that it serves as a good basis for its implementation.
  • To ensure that the design model is consistent with respect to the general design guidelines.
  • To ensure that the design guidelines fulfill their objectives.
Steps
Input Artifacts: Resulting Artifacts:
Worker: Design Reviewer
Participants: Architect, Designer
Work Guidelines:
  • Conduct reviews in a meeting format, although the participants of the meetings might prepare some reviews on their own.
  • Continuously monitor quality during design to prevent large numbers of defects from remaining hidden until the reviews. In each activity in design, the checkpoints listed below are referenced to reinforce this; use them for informal review meetings or in daily work.

Arrange one review of the design model per iteration in the Elaboration and Construction phases, where you review the work in progress. Then, in the iteration in the Construction phase, where the design model is considered to be more or less complete, you should arrange a detailed review of the design model. You should also arrange one review meeting per iteration in the other phases (Inception and Transition) when the design model is refined.

The participants of the review meetings will ultimately approve the design model. Before that, you will probably have to review the system several times, because results from a review will undoubtedly result in changes to the model.

Review the design as a whole   To top of page

Purpose
  • To ensure that the overall structure for the Design Model is well-formed.
  • To detect large-scale quality problems not visible by looking at lower-level elements.
Guidelines: Checkpoints: Design Model

The Design Model as a whole must be reviewed to detect glaring problems with layering and responsibility partitioning. The purpose of reviewing the model as a whole is to detect large-scale problems that a more detailed review would miss.

Review each use-case realization To top of page

Purpose
  • To ensure that the behavior of the system (as expressed in Use Case Realizations) matches the required behavior of the system (as expressed in Use Cases), i.e. is it complete?
  • To ensure that the behavior is allocated appropriately among model elements, i.e. is it correct?
Guidelines: Checkpoints: Use-Case Realizations

Once the structure of the Design Model is reviewed, the behavior of the model needs to be reviewed. First, make sure that there is no missing behavior by checking to see that all scenarios for the current iteration have been completely covered by Use-Case Realizations. All of the behavior in the relevant Use-Case Sub-flows must be described in the completed Use-Case Realizations.

Next, make sure the behavior of the Use-Case Realization is correctly distributed between model elements in the Realizations: make sure the operations are used correctly, that all parameters are passed, and that return values are of the correct type.

Review each subsystem (and its contents) or class (if the system is small) To top of page

Purpose
  • To ensure that the internal implementation of the subsystem or class performs the behavior required of it.
Guidelines:

For each model element to which behavior is allocated, the internal design of the model element must be reviewed. For subsystems, this means ensuring that the behavior specified in the interfaces the subsystem realizes has been allocated to one or more contained classes or subsystems. For classes, this means that the description of each operation is sufficient defined so that it may be implemented unambiguously.

Review the design guidelines To top of page

Purpose
  • To ensure that the Design Guidelines remain current, and to correct defects in the Guidelines where they exist.
Guidelines: Checkpoints: Design Guidelines

On the basis of the Design review, look for defects in the Design Guidelines:

  • Were they followed?  If not, why?
  • Are they correct?  Were systematic defects detected that were introduced by erroneous guidelines?
  • Are they complete?  Would systematic defects have been reduced if the guidance was provided?

Prepare review report and document defects To top of page

Purpose
  • To document the review results.
  • To ensure that identified defects are documented.

Following each review meeting, the results of the meeting must be documented in a Review Report. In addition, defects must be documented (and eventually assigned to someone to own and drive to resolution).

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)