このワークフローの詳細の目的は、要求によって提供される振る舞いの記述を変換し、設計の基になる要素のセットを作成することです。

トピック


      ソフトウェア要求
ソフトウェア要求
  ナビゲーション マップ
ナビゲーション
マップ
 
         
 
ユーザー インターフェイス設計者
ユーザー インターフェイス設計者
 

 
ユーザー インターフェイスの設計
ユーザー インターフェイスの設計

 
ユーザー インターフェイスのプロトタイプの作成
ユーザー インターフェイスのプロトタイプの作成

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

      分析クラス
分析クラス
 
       
 
ソフトウェア アーキテクト
ソフトウェア アーキテクト
 

 
設計要素の識別
設計要素の識別

 
       
      設計サブシステム
設計サブシステム
設計モデル
設計モデル
 
      設計パッケージ
設計パッケージ
シグナル
シグナル
 
      イベント
イベント
設計クラス
設計クラス
 
      Enterprise Java Beans (EJB)
Enterprise
Java Beans
(EJB)
インターフェイス
インターフェイス
 

      ナビゲーション マップ
ナビゲーション
マップ
設計モデル
設計モデル
 
       
 
テクニカル レビュー担当者
テクニカル レビュー担当者
 

 
設計レビュー
設計レビュー

 
       
      レビュー記録
レビュー記録
 

      ユース ケース
ユース ケース
 
       
 
設計者
設計者
 

 
ユース ケース分析
ユース ケース分析

 
       
      分析クラス
分析クラス
ユース・ケースの実現
ユース・ケースの実現
 
      分析モデル
分析モデル
 


説明 ページの先頭へ

このワークフローの詳細は、分析と設計が必要な振る舞いの要求がある各反復で発生します。

振る舞いの要求の分析には、次のことが含まれます。

  • 要求された振る舞いを満たす分析クラスを識別する
  • 識別した分析クラスが、論理的なアーキテクチャ (主要なサブシステムとクラス) にどのように適合するかを決定する。分析クラスが、既存のサブシステムに属すか、新しいサブシステムの作成を必要とするか、既存のサブシステムとそのインターフェイスを再定義するかが決定されます。

このワークフローの詳細には、ユーザー インターフェイスのモデリングとプロトタイプ作成も含まれることがあります。

関連情報 ページの先頭へ

このワークフローの詳細に関連する追加情報へのリンクを提供します。

タイミング ページの先頭へ

推敲フェーズで開始し、作成フェーズと移行フェーズで繰り返します。

オプション度 ページの先頭へ

必須

要員配置方法 ページの先頭へ

大規模なプロジェクトでは特に、ユーザー インターフェイス設計とプロトタイプ作成が、別のグループの人によって実行され、システムの使いやすさとユーザー インターフェイスのみに重点が置かれます。ただし、このグループは、開発チームのほかのメンバー (特に、要求とビジネス論理を担当するメンバー) と緊密に協力して、ユーザー インターフェイスがユーザーの期待に添うものになるように、そして (内容とユーザー アクションの点で) ユーザー インターフェイスに必要なものをビジネス論理が提供するようにする必要があります。

作業: ユース ケース分析」の実行に最も適しているのは、さまざまなスキルのメンバーを配置した小さいグループです。要員配置のガイドラインについては、「ガイドライン: ユース ケース分析検討会議」を参照してください。「作業: 設計要素の識別」には、アーキテクチャについてのより広い観点、ほかのユース ケース分析検討会議の結果が必要であり、プロジェクトに使用される実装技術とフレームワークの経験を必要とします。レビューを担当する要員は、実装技術の詳しい知識と、問題ドメインの理解の両方を持つメンバーを配置する必要があります。

作業ガイドライン ページの先頭へ

作業: ユーザー インターフェイスの設計」と「作業; ユーザー インターフェイスのプロトタイプの作成」は、推敲の反復全体で繰り返し実行されます。初期の反復で重点が置かれるのは、初期のユーザー インターフェイスの設計です。具体的には、主要なユーザー インターフェイス要素の識別と設計、その要素間の移動パスなどです。「../../workguid/wg_stbd.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません絵コンテ」は、ユーザー インターフェイスがどのように振る舞うべきかをよりよく理解するために、ユーザー インターフェイス設計の間に使用できる効果的な手法です。初期のユーザー インターフェイス設計について意見が一致すると、実行可能なユーザー インターフェイスのプロトタイプの開発が開始されます。プロトタイプについてのフィードバックがユーザー インターフェイス設計に (そして可能であれば要求にも) 反映されます。初期のプロトタイプは、通常はシステムの機能のサブセットのみをサポートします。以降の反復では、このプロトタイプを展開し、システムの機能を徐々に追加していきます。ユーザー インターフェイス設計の間に非機能的バージョンのユーザー インターフェイスを作成することの主な利点は、機能的ユーザー インターフェイスのプロトタイプは複雑で高コストなので、全体的なユーザー インターフェイス設計について意見が一致するまで、機能的ユーザー インターフェイスへの投資を先延ばしにできることです。システムの使いやすさの確認と検証をするには、ユーザー インターフェイスの設計とプロトタイプ作成の際に、システムのユーザーやユーザーになる可能性のある人と緊密に協力することが重要です。

複数のユース ケース分析検討会議を並行して組織でき、これを制限する条件は、使用可能なリソース プールと参加者のスキルだけです。各ユース ケース分析検討会議の後にできるだけ早く、会議のメンバー数名とアーキテクチャ チームのメンバー数名が協力し、会議の結果を「作業: 設計要素の識別」にマージする必要があります。両方のチームのメンバーが協力することが不可欠です。ユース ケース分析チームのメンバーは、分析クラスが識別されたコンテキストを理解し、アーキテクチャ チームは、設計のより幅広いコンテキストと、既に識別されたその他のユース ケースを理解しています。

設計作業が成熟して安定するにつれて、レビューが可能でレビューが必要な部分が徐々に大きくなります。小規模で重点を絞ったレビューのほうが、大規模で包括的なレビューより優れています。非常に限定された側面に重点を絞って 2 時間のレビューを 16 回行うほうが、2 日にわたる 1 回のレビューよりもはるかに優れています。重点を絞ったレビューでは、レビューの重点を絞る目的を定義し、その目的に応じて、レビューに適したスキルを持つ小規模なレビュー チームがそのレビューを行えるように手配します。初期のレビューで主に重点を置く必要があるものは、設計内のレイヤリングとパッケージ化の整合性、インターフェイスの安定性と品質、ユース ケースの振る舞いの完全な適用です。以降のレビューでは、パッケージとサブシステムまで掘り下げて、定義されたインターフェイスをこれらの内容が完全かつ正確に実現していること、設計の要素間の依存と関連が必要で十分で正しいことを確認します。それぞれの設計成果物のチェックポイントを調べて、特定のレビュー ポイントを探します。



Rational Unified Process   2003.06.15