成果物:
|
![]() |
開発プロセスは、そのフレームワークに従うプロジェクトのニーズを満たす、基本の RUP フレームワークの構成です。プロジェクトのコンテキストでは、この成果物は一般にプロジェクト固有のプロセスと呼ばれます。 |
役割: | プロセス エンジニア |
---|---|
オプション度 / 使用時期: | すべてのプロジェクトは開発プロセスに従うべきものです。プロジェクト固有のプロセスは多くの場合、Web サイトを通してプロジェクトのメンバーに通達されます。 |
テンプレートとレポート: |
|
例: | |
UML の表現: | なし |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
開発プロセス (プロジェクト固有のプロセス) の目的は、プロジェクトのメンバーにガイダンスを提供して作業を支援することです。「すぐに手に入る情報」は、この成果物の目的をよく表すたとえです。
選択した配布メカニズムに応じて、プロセスの概要は多くの形式をとる可能性があります。RUP のような Web ベースのプロセスに関しては、そのサイトマップ、またはツリー ブラウザの上から 2 番目までの階層を眺めることによって、その全体的な内容をよく把握することができます。
開発プロセスには UML のプロパティはありません。次に示すのは、ソフトウェア開発プロセスの重要なプロパティである特徴と機能の一覧です。
特定のプロジェクト向けにカスタマイズされたプロセスは通常、プロジェクトの開始時点、または時としてプロジェクトの開始に先立ってなされる作業の結果です。プロジェクトのための環境を準備する一環として、基本のプロセスのさまざまなビューを提供したり、基本のプロセスから逸脱した状況をより詳細に記述したりすることが必要な場合があります。プロジェクト固有のプロセスは通常、プロジェクト全体を通して必要に応じて更新されます。そのような更新の 1 つの例として、次の反復期間に予定されている作業に必要な個別のガイドラインとテンプレートを準備する、ということが挙げられます。
この成果物に責任を持つのは主に、プロセス エンジニアの役割にある人物です。責務には次のものが含まれます。
ソフトウェア開発プロジェクトのための適切なプロセスに関する決定を下すときには、成果物に求められる形式性、チームのメンバー数、期間、予算などの尺度で測ったプロジェクトの規模、プロジェクト メンバーのプロセス成熟度などの、個別の要因を考慮するようにします。RUP フレームワークはさまざまなタイプのプロジェクトに対応しているため、プロジェクト固有のニーズに合わせて常にプロセスをカスタマイズする必要があります。
プロジェクト固有のプロセスは、基本のプロセス フレームワークの最表面にあるフィルタリング層として機能する、開発個別構想書だけで構成される場合があります。小規模な開発組織では、組織全体のプロセスの作成という目的だけに割くことのできるリソースはなく、それよりも RUP Builder 製品を使用して、プロジェクト向けの開発プロセスを発行するのが一般的です。
より大規模な開発組織や、プロジェクト間でのプロセスの相互再利用とプロセスの改良に特に重点的に取り組む組織では、対象組織について複数の構成を作成するのが一般的です。プロジェクト固有のプロセスは、一致する組織構成を基に実体化されます。開発組織の設定におけるプロセス構成について、詳しくは RPW (Rational Process Workbench) 製品に関する説明を参照してください。
この成果物のカスタマイズについて、詳しくは「作業: プロジェクトのプロセスのカスタマイズ」を参照してください。
Rational Unified Process
|