作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
役割: テクニカル レビュー担当者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
目的 | 各レビューの一般的な推奨事項を提供する。 |
要求の結果をレビューする際に便利なガイドラインを次に示します。
以下の役割はレビュー会合に参加する必要があります。要求レビュー担当者は、ビジネス領域または技術領域の基礎知識や、簡素化の応用とモデリング手法に関する深い知識が必要です。
また、フェーズの最初や最後などのマイルストーンでは、レビュー会合に次の役割参加を考慮する必要があります。
望ましいレビュー参加者を含めることと、レビューの管理可能性と生産性を維持することの間で適切なバランスを取ることが重要です。レビューの目的達成に貢献できる参加者だけを含めるように、注意を払う必要があります。通常、参加者の多いレビューを 1 回開くより、焦点を絞った、参加者の少ないレビュー セッションを数回開くほうがより生産的です。
目的 | レビューの範囲と目標を定義する。 範囲 / 目標の特定の組み合わせごとに使用するアプローチを定義する。 |
通常、レビューは以下の会合に分割する必要があります。
1 回の会合で必要なことはすべてレビューできたとしても、結論について 1 回で承認を得られることはないでしょう。ユース ケース モデルの新バージョンごとに、新しいレビューを実行する準備をしておきます。
方向づけフェーズと推敲フェーズ内の各反復で、進行中の作業をレビューするユース ケース モデルのレビューを 1 回実行するように計画することを推奨します。これは、誤ったユース ケースの開発にリソースを費やさないようにするため、ユース ケースを詳細に開発する前に、最初にユーザーによって実行、終了される非常に重要なマイルストーンです。次に、推敲フェーズの最後に、ユース ケース モデルの詳細なレビューを計画します。推敲フェーズの最後に、ユース ケース モデルが完成している必要があること、また、おそらく用語集を表すドメイン モデルも 80% 完成していなければならないことに注意してください。ユース ケース モデルを洗練する際は、作成フェーズと移行フェースでも、その反復ごとに 1 回のユース ケース モデルのレビューを計画します。レビューでは、その反復で開発されている、ユース ケース モデルの部分に集中します。
目的 | レビュー結果を文書化する。 識別された障害を確実に文書化する。 |
各レビュー会合の後、会合の結果をレビュー記録に文書化します。また、プロジェクトの変更管理プロセスに従って、障害も文書化します。
参考資料 [BIT03] の第 11 章を参照してください。
Rational Unified Process
|