ワークフローの詳細:
|
このワークフローの詳細の目的は、システムの設計を洗練することです。 |
|||||||||||||||||||||||||||||||
トピック |
|
このワークフローの詳細の目標は次のとおりです。
このワークフローの詳細に関連する追加情報へのリンクを提供します。
推敲フェーズで開始します。作成フェーズと移行フェーズで繰り返します。
必須
通常は、1 人の人または小さいチームが 1 セットの設計の要素 (普通は、その他の設計の要素が含まれる 1 つ以上のパッケージまたはサブシステム) を担当します。この人またはチームは、パッケージまたはサブシステムに含まれる要素の設計の詳細の肉付けを行い、すべての操作定義とほかの設計の要素との関係の定義を完了します。「作業: クラス設計」では、 クラスの設計の要素の設計の洗練に重点を置き、「作業: サブシステム設計」では、サブシステムそのものにマッピングされる振る舞いを、中に含まれる設計の要素 (中に含まれるクラスまたはサブシステム) に割り当てることに重点を置きます。
クラスの設計を担当する個人は、実装言語、パッシブ クラスに使用されるアルゴリズムや技術にも精通している必要があります。サブシステムを担当する個人またはチームは、ゼネラリストである必要があり、設計の要素間での機能の適切なパッケージ分割について決定を下すことができ、さまざまな代替の設計に伴う固有のトレードオフを理解できる必要があります。
個別の設計の要素を洗練する一方で、設計の要素の責務の発展を反映するように、ユース ケースの実現を洗練しなければなりません。通常は、1 人の人または小さいチームが、1 つ以上の関連するユース ケースの実現の洗練を担当します。設計の要素が追加、洗練されるにつれて、ユース ケースの実現が古くなるか、設計モデルの改善によってユース ケースの実現の単純化が可能になるので、ユース ケースの実現を再検討して発展させる必要があります。ユース ケースの実現を担当する個人またはチームは、ユース ケースに必要な振る舞いについて、また、この振る舞いを設計の要素の中で割り当てるさまざまな方式のトレードオフについて、幅広く理解する必要があります。さらに、この個人またはチームは、ユース ケースを実行する要素の選択を担当しているので、設計の要素そのものの外部の (公開の) 振る舞いについて深く理解する必要があります。
通常、ここでの作業は、個人または小さいチームによって行われ、チーム間で変更を伝達するために必要な場合は、非公式のグループ間相互作用を行います。設計の要素が洗練されるにつれて、多くの場合、チーム間で責務が移動し、複数の設計の要素とユース ケースの実現に同時に変更を加える必要が出てきます。責務が相互に影響するので、設計チームのメンバーが完全に単独で作業することはほとんど不可能になります。(ユース ケースの実現で表現された) システムに必要な振る舞いに重点を置いた設計作業を続けるために、たとえば次のような典型的なパターンの相互作用が行われます。
プロセスそのものが反復的なので、「その回の反復に必要なすべての振る舞い」の基準は、ライフサイクルの中での位置に応じて次のように異なります。
1 回の反復の設計は、実装とテストの作業を始める前に完全にする必要はありません。1 回の反復の中でも、設計が発展するにつれて部分的に実装とテストを行うことは、設計の検証と洗練の効果的な方法になります。
Rational Unified Process
|