作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: 推敲フェーズと作成のフェーズで反復ごとに 1 回の設計モデルのレビューを計画し、進行中の作業を見直す。次に、設計モデルがだいたい完成していると考えられる作成フェーズの反復で、設計モデルの詳細なレビューを計画する。また、設計モデルが洗練されるその他のフェーズ (方向づけと移行) でも、反復ごとに 1 回のレビュー会合を計画する。
最終的には、レビュー会合の参加者が設計モデルを承認する。レビューの結果、確実にモデルを変更することになるので、レビューの前にシステムを数回レビューする必要がある。 |
|
役割: テクニカル レビュー担当者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
目的 | 各レビューの一般的な推奨事項を提供する。 |
目的 | 設計モデル全体の構造がうまく形成されていることを確認する。 低レベルの要素を見ただけではわからない大規模な品質問題を検出する。 |
レイヤリングと責務分担についての明らかな問題を検出するには、設計モデル全体をレビューする必要があります。モデルを全体としてレビューする目的は、詳細なレビューでは見落とされるような大規模な問題を検出するためです。
方向づけフェーズと推敲フェーズの初期では、このレビューはモデルの全体構造に焦点を合わせ、特にレイヤリングとインターフェイスに重点を置きます。パッケージ要素間では結合が緩やかになるように、パッケージとサブシステムの依存関係を検査します。パッケージとサブシステムの内容を検査して、パッケージ要素内の凝集度が緊密であることを確認します。一般に、要素が明確で適切な責務を持ち、その名前が責務を反映するためには、すべての要素を検査する必要があります。
最低でも、アーキテクチャ プロトタイプが開発された時点で、より包括的な設計のレビューを行います。まず、モデル全体の完全度についてレビューし、次に障害を見つけるために注意深くレビューします。
目的 | システムの振る舞い (ユース ケースの実現で表現される) が、必要なシステムの振る舞い (ユース ケースで表現される) と一致している、つまり、完全かどうかを確認する。 振る舞いがモデル要素に適切に割り当てられている、つまり、適正かどうかを確認する。 |
設計モデルの構造をレビューしたら、次にモデルの振る舞いをレビューする必要があります。まず、現在の反復のすべてのシナリオが、ユース ケースの実現で完全に網羅されているかどうかを確認して、振る舞いの欠落がないようにします。関係するユース ケースのサブフローのすべての振る舞いが、完成したユース ケースの実現で記述されていなければなりません。
システムの振る舞いがイベント駆動型である場合、ユース ケースの振る舞いを記述するためにステートチャート図が使用されている場合があります。ステートチャート図を使用した場合は、それらが正しい振る舞いを記述していることを確認するために検査する必要があります。詳しくは、「ガイドライン: ステートチャート図」を参照してください。
次に、ユース ケースの実現の振る舞いが、実現におけるモデル要素の間で正しく分散されるようにします。また、操作が正しく使用され、すべてのパラメータが渡され、戻り値が正しい型であることを確認します。
目的 | 設計要素の内部実装が、必要な振る舞いを実行することを確認する。 |
振る舞いが割り当てられている各モデル要素 (設計クラスや設計サブシステムなど) について、内部設計をレビューする必要があります。設計サブシステムの場合、このことは、公開されたインターフェイスで指定された振る舞いが、1 つ以上の包含される設計要素に割り当てられていることを確認することを意味します。設計クラスの場合は、操作を明白に実装できるように、各操作の記述が十分に定義されていることを確認することを意味します。
目的 | 設計に関連するプロジェクト固有のガイドラインが常に最新であるようにすることと、ガイドラインに障害がある場合は、それを訂正する。 |
設計レビューに基づいて、次のように設計ガイドラインの障害を探します。
目的 | レビュー結果を文書化する。 識別された障害を確実に文書化する。 |
各レビュー会合の後、会合の結果をレビュー記録に文書化します。また、プロジェクトの変更管理プロセスに従って、障害も文書化します。
Rational Unified Process
|