開発プロセスは、そのフレームワークに従うプロジェクトのニーズを満たす、基本の RUP フレームワークの構成です。プロジェクトのコンテキストでは、この成果物は一般にプロジェクト固有のプロセスと呼ばれます。
役割:  プロセス エンジニア 
オプション度 / 使用時期:  すべてのプロジェクトは開発プロセスに従うべきものです。プロジェクト固有のプロセスは多くの場合、Web サイトを通してプロジェクトのメンバーに通達されます。
テンプレートとレポート: 
 
例:   
UML の表現:  なし
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

開発プロセス (プロジェクト固有のプロセス) の目的は、プロジェクトのメンバーにガイダンスを提供して作業を支援することです。「すぐに手に入る情報」は、この成果物の目的をよく表すたとえです。

概要 ページの先頭へ

選択した配布メカニズムに応じて、プロセスの概要は多くの形式をとる可能性があります。RUP のような Web ベースのプロセスに関しては、そのサイトマップ、またはツリー ブラウザの上から 2 番目までの階層を眺めることによって、その全体的な内容をよく把握することができます。

プロパティ ページの先頭へ

開発プロセスには UML のプロパティはありません。次に示すのは、ソフトウェア開発プロセスの重要なプロパティである特徴と機能の一覧です。

  • 役割、作業、成果物などのプロセスの中心的な要素の、入念に定義された構造。この構造を中心に、プロセス記述の残りの部分を補っていきます。
  • プロセスの説明的なガイダンス。たとえば、プロセスの要素、概念、ホワイト ペーパーについての紹介目的での記述。
  • プロセスの規範的なガイダンス。たとえば、成果物の作成時に担当者を支援するための、ステップごとのガイドライン、チェック リスト、ツール メンター。
  • ライフサイクル モデル。RUP では、4 つのフェーズの記述と各フェーズ内の反復の概念によって、反復的かつインクリメンタルなライフサイクルを定義します。
  • プロジェクト成果物の作成を手早く始めるための補助的リソース。再利用可能な資産、テンプレート、サンプルなど。
  • プロセスのガイダンスをそのユーザーに向けて提示するためのメカニズム。RUP では、次の特徴を持つ、ナビゲーション性に優れた Web サイトの形式を採用しています。
    • ユーザーが必要なときに、自分の作業に関連するガイドラインを簡単に見つけることのできる検索メカニズム。
    • プロセスを論理的に参照するためのメニュー。RUP Web サイトの画面左のツリー ブラウザなど。
    • プロセス製品を日々使用する中で、ユーザーが自分に直接関係のない情報を非表示にするためのフィルタ メカニズム。
    • プロセスの記述に使用される用語を定義する用語集。
  • 補助ツールについての記述と、それらのツールへのリンク。
  • プロジェクトに固有のニーズに合わせてプロセスを修正する方法のガイダンス。

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

特定のプロジェクト向けにカスタマイズされたプロセスは通常、プロジェクトの開始時点、または時としてプロジェクトの開始に先立ってなされる作業の結果です。プロジェクトのための環境を準備する一環として、基本のプロセスのさまざまなビューを提供したり、基本のプロセスから逸脱した状況をより詳細に記述したりすることが必要な場合があります。プロジェクト固有のプロセスは通常、プロジェクト全体を通して必要に応じて更新されます。そのような更新の 1 つの例として、次の反復期間に予定されている作業に必要な個別のガイドラインとテンプレートを準備する、ということが挙げられます。

責務 ページの先頭へ

この成果物に責任を持つのは主に、プロセス エンジニアの役割にある人物です。責務には次のものが含まれます。

  • 各自の仕事を効率的に、許容可能な品質で成し遂げられるように、関連するプロセスについての十分なガイダンスをプロジェクト メンバーに提供すること
  • その内容をスムーズに参照するための直感的な手段を含めて、使いやすい形にプロセスを整備すること
  • プロジェクトのメンバーに、プロセスの内容を確実かつ適切に理解させること
  • プロセスに関するフィードバックを集め、プロセスを必要に応じて更新すること

カスタマイズ ページの先頭へ

ソフトウェア開発プロジェクトのための適切なプロセスに関する決定を下すときには、成果物に求められる形式性、チームのメンバー数、期間、予算などの尺度で測ったプロジェクトの規模、プロジェクト メンバーのプロセス成熟度などの、個別の要因を考慮するようにします。RUP フレームワークはさまざまなタイプのプロジェクトに対応しているため、プロジェクト固有のニーズに合わせて常にプロセスをカスタマイズする必要があります。

プロジェクト固有のプロセスは、基本のプロセス フレームワークの最表面にあるフィルタリング層として機能する、開発個別構想書だけで構成される場合があります。小規模な開発組織では、組織全体のプロセスの作成という目的だけに割くことのできるリソースはなく、それよりも RUP Builder 製品を使用して、プロジェクト向けの開発プロセスを発行するのが一般的です。

より大規模な開発組織や、プロジェクト間でのプロセスの相互再利用とプロセスの改良に特に重点的に取り組む組織では、対象組織について複数の構成を作成するのが一般的です。プロジェクト固有のプロセスは、一致する組織構成を基に実体化されます。開発組織の設定におけるプロセス構成について、詳しくは RPW (Rational Process Workbench) 製品に関する説明を参照してください。

この成果物のカスタマイズについて、詳しくは「作業: プロジェクトのプロセスのカスタマイズ」を参照してください。



Rational Unified Process   2003.06.15