目的
  • 設計モデルがシステム要求を満たすことと、実装の優れた基礎として機能することを検証する。
  • 設計モデルが一般的な設計ガイドラインに関して一貫していることを確認する。
  • 設計ガイドラインがその目的を果たしていることを確認する。
ステップ
入力とする成果物:    結果となる成果物:   
頻度: 推敲フェーズと作成のフェーズで反復ごとに 1 回の設計モデルのレビューを計画し、進行中の作業を見直す。次に、設計モデルがだいたい完成していると考えられる作成フェーズの反復で、設計モデルの詳細なレビューを計画する。また、設計モデルが洗練されるその他のフェーズ (方向づけと移行) でも、反復ごとに 1 回のレビュー会合を計画する。

最終的には、レビュー会合の参加者が設計モデルを承認する。レビューの結果、確実にモデルを変更することになるので、レビューの前にシステムを数回レビューする必要がある。

 
役割:  テクニカル レビュー担当者 
ツール メンター:   
More Information: 

ワークフローの詳細:   

一般的な推奨事項 ページの先頭へ

目的 各レビューの一般的な推奨事項を提供する。

「ピア」レビュー担当者の要員配置プロフィールは、役割: ソフトウェア アーキテクトと同じですが、ソフトウェア アーキテクトより技術的な問題に焦点を絞っています。リーダーシップ、成熟度、実用主義、結果主義などもある程度までは重要ですが、それより重要なことは、レビュー担当者が、プロジェクトの進行の妨げる可能性のある設計の障害を発見することです。また、スケジュールをむやみに進めてプロジェクト チームを誤った方向に向かわせるより、解決できるのであれば、重大な問題を早期に発見して、処理することが大切です。設計レビュー担当者は、プロジェクトの成功に関わる幅広い問題に対して迅速に対応しながらも、コストに対するリスクのバランスを取る必要があります。また、設計レビュー担当者は、微妙な問題を指摘し、検討できる、説得力のある伝達者である必要があります。技術的な知識の面では、設計レビュー担当者には、役割: 設計者と同じ経験が必要です。

設計モデルの全体としてのレビュー ページの先頭へ

目的  設計モデル全体の構造がうまく形成されていることを確認する。
低レベルの要素を見ただけではわからない大規模な品質問題を検出する。 


レイヤリングと責務分担についての明らかな問題を検出するには、設計モデル全体をレビューする必要があります。モデルを全体としてレビューする目的は、詳細なレビューでは見落とされるような大規模な問題を検出するためです。

方向づけフェーズと推敲フェーズの初期では、このレビューはモデルの全体構造に焦点を合わせ、特にレイヤリングとインターフェイスに重点を置きます。パッケージ要素間では結合が緩やかになるように、パッケージとサブシステムの依存関係を検査します。パッケージとサブシステムの内容を検査して、パッケージ要素内の凝集度が緊密であることを確認します。一般に、要素が明確で適切な責務を持ち、その名前が責務を反映するためには、すべての要素を検査する必要があります。

最低でも、アーキテクチャ プロトタイプが開発された時点で、より包括的な設計のレビューを行います。まず、モデル全体の完全度についてレビューし、次に障害を見つけるために注意深くレビューします。

各ユース ケースの実現のレビュー ページの先頭へ

目的 システムの振る舞い (ユース ケースの実現で表現される) が、必要なシステムの振る舞い (ユース ケースで表現される) と一致している、つまり、完全かどうかを確認する。
振る舞いがモデル要素に適切に割り当てられている、つまり、適正かどうかを確認する。 


設計モデルの構造をレビューしたら、次にモデルの振る舞いをレビューする必要があります。まず、現在の反復のすべてのシナリオが、ユース ケースの実現で完全に網羅されているかどうかを確認して、振る舞いの欠落がないようにします。関係するユース ケースのサブフローのすべての振る舞いが、完成したユース ケースの実現で記述されていなければなりません。

システムの振る舞いがイベント駆動型である場合、ユース ケースの振る舞いを記述するためにステートチャート図が使用されている場合があります。ステートチャート図を使用した場合は、それらが正しい振る舞いを記述していることを確認するために検査する必要があります。詳しくは、「ガイドライン: ステートチャート図」を参照してください。 

次に、ユース ケースの実現の振る舞いが、実現におけるモデル要素の間で正しく分散されるようにします。また、操作が正しく使用され、すべてのパラメータが渡され、戻り値が正しい型であることを確認します。

各設計要素のレビュー ページの先頭へ

目的  設計要素の内部実装が、必要な振る舞いを実行することを確認する。 

振る舞いが割り当てられている各モデル要素 (設計クラスや設計サブシステムなど) について、内部設計をレビューする必要があります。設計サブシステムの場合、このことは、公開されたインターフェイスで指定された振る舞いが、1 つ以上の包含される設計要素に割り当てられていることを確認することを意味します。設計クラスの場合は、操作を明白に実装できるように、各操作の記述が十分に定義されていることを確認することを意味します。

設計ガイドラインのレビュー ページの先頭へ

目的 設計に関連するプロジェクト固有のガイドラインが常に最新であるようにすることと、ガイドラインに障害がある場合は、それを訂正する。 


設計レビューに基づいて、次のように設計ガイドラインの障害を探します。

  • 設計ガイドラインに従ったか。従っていない場合、その理由は何か。
  • 設計ガイドラインは正しいか。誤ったガイドラインが原因による系統的な障害が検出されたか。
  • 設計ガイドラインは完全か。ガイダンスが提供されていたら、系統的な障害の軽減は可能であったか。

レビュー記録の準備と障害の文書化 ページの先頭へ

目的 レビュー結果を文書化する。
識別された障害を確実に文書化する。 


各レビュー会合の後、会合の結果をレビュー記録に文書化します。また、プロジェクトの変更管理プロセスに従って、障害も文書化します。



Rational Unified Process   2003.06.15