トピック

ワークフローの実行方法の決定 ページの先頭へ

「分析/設計」作業分野のワークフローに関しては、以下の決定を行う必要があります。

  • ワークフローの実行方法を決定します。これは、分析/設計: ワークフローを見て行います。ダイアグラムとそのガード条件 およびガイドラインについて学びます。どのワークフローが、どのような順序で実行の詳細を記述するのかを決定します。 
  • 分析/設計ワークフローのどの部分によって実行の詳細が記述されるのかを決定します。以下の部分は、他の部分から比較的独立して導入できます。

ワークフローの一部

コメント

ユーザー・インターフェース設計 プロジェクトによっては、ユーザー・インターフェース設計を行わないこともあります。理由の 1 つは、ユーザー・インターフェースの開発が容易である場合です。ユーザー・インターフェース設計を行わないことに決定した場合、ナビゲーション・マップやユーザー・インターフェース・プロトタイプを開発しないことになります。 
データベース設計 エンティティーがデータベースに保存される場合にのみ使用します。データベース設計をしないことに決定した場合は、データ・モデルをまったく開発しないことになります。 

  • プロジェクトのライフ・サイクルのどの時期に、ワークフローのそれぞれの部分を導入するのかを決定します。分析/設計の作業分野の導入を、推敲フェーズまで待てることもあります。例えば、よく理解された分野で開発を行い、性能上の要求などの機能外要求がなく、適切に設計されたアーキテクチャーに基づいている場合は、方向づけの際にプロトタイプを作成する必要はほとんどありません。

決定事項を」 という見出しの下に文書化します。

成果物の使用方法の決定 ページの先頭へ

どの成果物をどのように使用するのかを決定します。次の表は、必須の成果物と、場合によって使用する成果物を示しています。各成果物のカスタマイズ方法、その特定の成果物の利点、または欠点の議論について詳しくは、各成果物の『カスタマイズ』の項を参照してください。

各成果物について、成果物の使用方法を決定します。必須、重要、任意、または、なしで表します。

成果物 目的

カスタマイズ (オプション、推奨)

分析モデル (分析クラス) 分析モデルは、設計を決定する前に、要件の理解を深める上で有効です。複雑なシステムの場合は、システムの概念上の概観を得られるように整備します。

オプション

多くのプロジェクトでは、初期の設計モデルを分析モデルの代わりに使用します。

分析モデルを作成するプロジェクトでは、通常、設計モデルに発展させる一時的な成果物です。

ナビゲーション・マップユーザー・インターフェース・プロトタイプ

大規模で複雑なユーザー・インターフェースを持つプロジェクトは、ユーザー・インターフェースの設計を十分検討する必要があります。

オプション

比較的小規模な開発作業では、略式のユーザー・インターフェース設計で十分な場合もあります。

設計モデル

大部分のシステム (小規模なシステムも含む) は、設計の誤りによって再作業のコストが発生するのを避けるため、実装する前に設計が必要です。ビジュアル・モデリングを使用すると、設計の伝達性が高まります。フォワード・エンジニアリングおよびリバース・エンジニアリングのツールによって、実装モデルとの整合性を確保し、省力化をはかることができます。

大部分のプロジェクトに対して推奨されます。

小規模なプロジェクトでは、自動化ツールの使用は必須ではありませんが、長期的な生産性の点でメリットがある場合があります。

設計クラス設計パッケージ

クラスとパッケージは、オブジェクト指向設計の基本的な部分です。オブジェクト指向設計は、ほとんどのプロジェクトで使用される標準的な設計方法です。

大部分のプロジェクトに対して推奨されます。

カスタマイズの主要な問題は、使用するステレオタイプを決定することです (これは、設計ガイドラインで取り込むことができます)。

ユース・ケースの実現

ユース・ケースから設計への橋渡しになります。

大部分のプロジェクトに対して推奨されます。

インターフェース

インターフェースは、普通、振る舞いを実現する大まかなコンポーネントとは独立して振る舞いを定義するために使用します。

大部分のプロジェクトに対して推奨されます。

コンポーネント・ベースの設計は、標準的な設計方法になりつつあります。

設計サブシステム

設計サブシステムは、インターフェースを提供するパッケージの内部に振る舞いをカプセル化するために使用します。クラスや他のサブシステムの相互作用をカプセル化するために使用します。

大部分のプロジェクトに対して推奨されます。

サブシステムは、設計の抽象性のレベルを上げるためによく使用されます。 使用すれば、システムがより簡単になります。

イベント

多数の外部イベントに応答するシステムに対して役に立つ場合があります。

シグナル

並行性が必要でイベント駆動のシステムに対して、役に立つ場合があります。

リアルタイム・システムに対しては推奨されます。

並行性が必要でイベント駆動のシステムに対して、役に立つ場合があります。

データ・モデル 永続的情報の論理構造や、場合によっては物理構造の記述に使用します。

データベースを使用するプロジェクトでは推奨されます。

配置モデル 実行時の処理ノードの構成、ノード間の通信リンク、およびノードに常駐するコンポーネントのインスタンスとオブジェクトを表示します。

オプション。

多くのシステムには複数の処理ノードがあるので、配置モデルを使用する必要があります。ただし、ソフトウェア・アーキテクチャー説明書の節として作成してもよく、独立した成果物として存在する必要はありません。

アーキテクチャー上の概念の検証 アーキテクチャーの点で重要な要求を満たすソリューションが存在するかどうかを判断するために使用します。 大部分のプロジェクトに対して推奨されます。

多くのプロジェクトでは、要求の実現可能性を決定するために使用します。次のような形式を使用できます。

  • ソリューションに適していると思われる既知の技術のリスト
  • ソリューションの概念モデルのスケッチ
  • ソリューションのシミュレーション
  • 実行可能なプロトタイプ
参照アーキテクチャー 実績のあるソリューションを再利用することで、開発を短縮し、リスクを軽減します。

大部分のプロジェクトに対して推奨されます。

適切な参照アーキテクチャーの資料があれば、開発速度の向上とリスク軽減に劇的な効果があります。

SAD (ソフトウェア・アーキテクチャー説明書) システムの総合的なソフトウェア・アーキテクチャーの概要を示すために使用します。この概要は、システムを理解し、アーキテクチャーに関する重要な決定事項を把握するために役に立ちます。

大部分のプロジェクトに対して推奨されます。

ソフトウェア・アーキテクチャーの高レベルの概要は、極度に小さなシステムを除くすべてのシステムで役に立ちます。一般に、複雑なシステムでは、小さなプロジェクトと比べて、より高いレベルの詳細さと、より多くのビューが必要です。

ユーザー・インターフェースのプロトタイプ 実際の開発を開始する前に、機能性と使用可能度を明らかにし、テストするために使用します。多くの時間を浪費する前に設計を検証するための効果的な手段です。

大部分のプロジェクトに対して推奨されます。


プロジェクトのニーズに合わせて各成果物をカスタマイズします。カスタマイズに関する考慮事項については、成果物の説明のカスタマイズに関する節、

使用するレポートの決定 ページの先頭へ

使用するレポートの決定は、プロジェクトで利用できる報告ツールに依存します。レポート生成ツールを利用できる場合は、設計クラスやユース・ケースの実現などのモデル指向の成果物に対するレポートを生成することが推奨されます。RUP 構成の既存のレポートは、成果物の説明ページから利用できます。また、ツリー・ブラウザーの関連する成果物の下にまとめられています。

レビュー方法の決定 ページの先頭へ

各成果物のレビュー・レベルを決定し、 分析/設計の結果のレビューと承認の方法と、レビューの範囲を決定します。

設計レビューの利点は次のとおりです。

  • テストでの検出が不可能な (または非常に難しい) 問題を検出できます。例えば、スタイルやレイアウトの問題です。 
  • レビューによりモデリング・スタイルの統一を強化でき、メンバーが相互に学習する機会を得ることができます。 
  • また、レビューを行わなければプロジェクトの終盤のテスト段階まで検出できないバグを、ここで検出できます。

設計レビューの欠点は次のとおりです。

  • 時間と資源がかかります。 
  • 運用が適切でないと、有効に利用できません。

変更可能な要素としては、レビューの技法、リソース、範囲があります。 プロジェクトで決定する要素の例を次に挙げます。

  • サブシステムへのローカルな変更のレビューは、1 人の同僚のみが行うかどうかを決定します。この場合は、同僚が検査を行い、結果を書類にまとめます。
  • 設計の中でまったくレビューしない部分を決定します。例えば、プロジェクトの各メンバーの一部のクラスのみをレビューし、そのスタイルが残りの結果についても同様の品質であることが保証されることを期待します。
  • ソフトウェア・アーキテクチャー説明書を、別の会合で顧客側がレビューすることを決定します。
  • 重要なインターフェースを変更する際に正式なレビュー会合を開催することを決定します。例えば、複数のプロジェクト・メンバーの作業に影響を与えるインターフェースなどです。

レビューやさまざまな種類のレビューについて詳しくは、『../workguid/wg_rview.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません作業ガイドライン: レビュー』を参照してください。

コードを生成するかどうかの決定 ページの先頭へ

設計方法は、コードを設計モデルから生成するかどうかによって異なります。コードを生成する場合、設計は非常に詳細に行う必要があります。 それに対し、設計に基づいてコードを生成しない場合は、それほど詳細に設計する必要はありません。ただし、設計の詳細は手作業でコードと同期化させる必要があります。



Rational Unified Process   2003.06.15