ガイドライン
|
ワークフローの一部 |
コメント |
---|---|
ユーザー・インターフェース設計 | プロジェクトによっては、ユーザー・インターフェース設計を行わないこともあります。理由の 1 つは、ユーザー・インターフェースの開発が容易である場合です。ユーザー・インターフェース設計を行わないことに決定した場合、ナビゲーション・マップやユーザー・インターフェース・プロトタイプを開発しないことになります。 |
データベース設計 | エンティティーがデータベースに保存される場合にのみ使用します。データベース設計をしないことに決定した場合は、データ・モデルをまったく開発しないことになります。 |
決定事項を」 という見出しの下に文書化します。
どの成果物をどのように使用するのかを決定します。次の表は、必須の成果物と、場合によって使用する成果物を示しています。各成果物のカスタマイズ方法、その特定の成果物の利点、または欠点の議論について詳しくは、各成果物の『カスタマイズ』の項を参照してください。
各成果物について、成果物の使用方法を決定します。必須、重要、任意、または、なしで表します。
成果物 | 目的 |
カスタマイズ (オプション、推奨) |
---|---|---|
分析モデル (分析クラス) | 分析モデルは、設計を決定する前に、要件の理解を深める上で有効です。複雑なシステムの場合は、システムの概念上の概観を得られるように整備します。 |
オプション 多くのプロジェクトでは、初期の設計モデルを分析モデルの代わりに使用します。 分析モデルを作成するプロジェクトでは、通常、設計モデルに発展させる一時的な成果物です。 |
大規模で複雑なユーザー・インターフェースを持つプロジェクトは、ユーザー・インターフェースの設計を十分検討する必要があります。 |
オプション 比較的小規模な開発作業では、略式のユーザー・インターフェース設計で十分な場合もあります。 |
|
設計モデル |
大部分のシステム (小規模なシステムも含む) は、設計の誤りによって再作業のコストが発生するのを避けるため、実装する前に設計が必要です。ビジュアル・モデリングを使用すると、設計の伝達性が高まります。フォワード・エンジニアリングおよびリバース・エンジニアリングのツールによって、実装モデルとの整合性を確保し、省力化をはかることができます。 |
大部分のプロジェクトに対して推奨されます。 小規模なプロジェクトでは、自動化ツールの使用は必須ではありませんが、長期的な生産性の点でメリットがある場合があります。 |
|
クラスとパッケージは、オブジェクト指向設計の基本的な部分です。オブジェクト指向設計は、ほとんどのプロジェクトで使用される標準的な設計方法です。 |
大部分のプロジェクトに対して推奨されます。 カスタマイズの主要な問題は、使用するステレオタイプを決定することです (これは、設計ガイドラインで取り込むことができます)。 |
|
ユース・ケースから設計への橋渡しになります。 |
大部分のプロジェクトに対して推奨されます。 |
|
インターフェースは、普通、振る舞いを実現する大まかなコンポーネントとは独立して振る舞いを定義するために使用します。 |
大部分のプロジェクトに対して推奨されます。 コンポーネント・ベースの設計は、標準的な設計方法になりつつあります。 |
|
設計サブシステムは、インターフェースを提供するパッケージの内部に振る舞いをカプセル化するために使用します。クラスや他のサブシステムの相互作用をカプセル化するために使用します。 |
大部分のプロジェクトに対して推奨されます。 サブシステムは、設計の抽象性のレベルを上げるためによく使用されます。 使用すれば、システムがより簡単になります。 |
|
多数の外部イベントに応答するシステムに対して役に立つ場合があります。 | |
|
並行性が必要でイベント駆動のシステムに対して、役に立つ場合があります。 |
リアルタイム・システムに対しては推奨されます。 並行性が必要でイベント駆動のシステムに対して、役に立つ場合があります。 |
データ・モデル | 永続的情報の論理構造や、場合によっては物理構造の記述に使用します。 |
データベースを使用するプロジェクトでは推奨されます。 |
配置モデル | 実行時の処理ノードの構成、ノード間の通信リンク、およびノードに常駐するコンポーネントのインスタンスとオブジェクトを表示します。 |
オプション。 多くのシステムには複数の処理ノードがあるので、配置モデルを使用する必要があります。ただし、ソフトウェア・アーキテクチャー説明書の節として作成してもよく、独立した成果物として存在する必要はありません。 |
アーキテクチャー上の概念の検証 | アーキテクチャーの点で重要な要求を満たすソリューションが存在するかどうかを判断するために使用します。 | 大部分のプロジェクトに対して推奨されます。
多くのプロジェクトでは、要求の実現可能性を決定するために使用します。次のような形式を使用できます。
|
参照アーキテクチャー | 実績のあるソリューションを再利用することで、開発を短縮し、リスクを軽減します。 |
大部分のプロジェクトに対して推奨されます。 適切な参照アーキテクチャーの資料があれば、開発速度の向上とリスク軽減に劇的な効果があります。 |
SAD (ソフトウェア・アーキテクチャー説明書) | システムの総合的なソフトウェア・アーキテクチャーの概要を示すために使用します。この概要は、システムを理解し、アーキテクチャーに関する重要な決定事項を把握するために役に立ちます。 |
大部分のプロジェクトに対して推奨されます。 ソフトウェア・アーキテクチャーの高レベルの概要は、極度に小さなシステムを除くすべてのシステムで役に立ちます。一般に、複雑なシステムでは、小さなプロジェクトと比べて、より高いレベルの詳細さと、より多くのビューが必要です。 |
ユーザー・インターフェースのプロトタイプ | 実際の開発を開始する前に、機能性と使用可能度を明らかにし、テストするために使用します。多くの時間を浪費する前に設計を検証するための効果的な手段です。 |
大部分のプロジェクトに対して推奨されます。 |
プロジェクトのニーズに合わせて各成果物をカスタマイズします。カスタマイズに関する考慮事項については、成果物の説明のカスタマイズに関する節、
使用するレポートの決定は、プロジェクトで利用できる報告ツールに依存します。レポート生成ツールを利用できる場合は、設計クラスやユース・ケースの実現などのモデル指向の成果物に対するレポートを生成することが推奨されます。RUP 構成の既存のレポートは、成果物の説明ページから利用できます。また、ツリー・ブラウザーの関連する成果物の下にまとめられています。
各成果物のレビュー・レベルを決定し、 分析/設計の結果のレビューと承認の方法と、レビューの範囲を決定します。
設計レビューの利点は次のとおりです。
設計レビューの欠点は次のとおりです。
変更可能な要素としては、レビューの技法、リソース、範囲があります。 プロジェクトで決定する要素の例を次に挙げます。
レビューやさまざまな種類のレビューについて詳しくは、『作業ガイドライン: レビュー』を参照してください。
設計方法は、コードを設計モデルから生成するかどうかによって異なります。コードを生成する場合、設計は非常に詳細に行う必要があります。 それに対し、設計に基づいてコードを生成しない場合は、それほど詳細に設計する必要はありません。ただし、設計の詳細は手作業でコードと同期化させる必要があります。
Rational Unified Process
|