目的
  • プロジェクトの特定のニーズに従って、ソフトウェア開発プロセスの規模を正しく設定する。
  • プロジェクトのメンバーに対し、適切で、利用可能なプロセス説明を提供する。
役割:  プロセス エンジニア 
頻度: 作業のほとんどはプロジェクトの開始時に行う。 必要に応じて、反復で繰り返す。
手順
入力とする成果物:   結果となる成果物: 
ツール・メンター: 
詳細情報: 

ワークフローの詳細: 

プロジェクトの分析 ページの先頭へ

目的:  目前にある問題と、プロジェクトに投入できる要員を大まかに把握する。

プロジェクトが成功するためには、その開発プロセスが、目前のプロジェクトと、プロジェクトの規模と形式性の要求にとって適切であることが不可欠です。 プロセスがあまりに多いと、創造性や効率性が損なわれる結果を招く場合があります。 プロセスが少なすぎると、無秩序な環境につながる場合があります。一般的に、個々のプロジェクト・メンバーが局所的に決定を行うため、非効率的で、一貫性がなく、予測不可能な結果が生じることになります。

プロセスの作法は開発組織ごとに大きく異なります。ある組織では、プロセスに関して成熟した手法を持ち、専門のプロセス グループが、組織全体を通じた開発プロセスの定義と改善を担当します。別の組織では、プロジェクト固有のカスタマイズだけに関与します。これらのプロジェクトは通常、RUP 製品に付属する定義済みの構成を使用して開始され、プロジェクトごとにプロセスがインスタンス化されます。プロジェクトのプロセスをカスタマイズするためのアプローチは、以下に示す複数の要素に大きく依存します。

  • 開発組織のプロセスに関する成熟度
  • 所要日数と開発要員の数から見たプロジェクトの規模
  • 同様のプロセスに関するプロジェクト メンバーの経験
  • プロジェクトの形式性要件

詳しくは、「ガイドライン: プロセスの識別」を参照してください。

プロセスの範囲の定義 ページの先頭へ

目的:  プロジェクト固有のプロセスでカバーするプロセス領域を定義する。

プロジェクトの要員と、それらの要員が持つ同様のソフトウェア開発プロジェクトの経験を分析した結果は、カスタマイズ作業の範囲を特定する上で役に立ちます。プロジェクト固有のプロセスは、RUP のすべての作業分野を含んでいる必要はありません。また、RUP で定義されているすべての役割をカバーする必要もありません。RUP は、さまざまなタイプのプロジェクトに適したプロセス フレームワークであり、1 つの特定のプロジェクトで準拠するには範囲が広すぎることを覚えておいてください。プロジェクトのプロセスでカバーするためにどの領域を選択するかは、プロジェクト メンバーの既存のスキル セットと、目前のプロジェクトの性質に大きく依存します。カスタマイズ作業の範囲を定義するときの一般的な検討事項を以下に示します。

  • プロジェクトのメンバーが共通の作業方法で既に作業しており、新しいプロセスやツールを導入する必要がない領域。たとえば、テスト方法がわかっている場合は、RUP のテスト作業分野を導入して、新しい要素の数を制限することが推奨されます。RUP の一部の部分を導入することに焦点を当て、その既存プロセスで問題を修正できます。 詳しくは、 ../workflow/environm/co_iproj.htm#Improving Process and Tools -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: プロジェクトでのプロセスの実装の「プロセスとツールの改善」を参照してください。  
  • 作業方法が確立されていないために、プロジェクトで新しいプロセスやツールを導入しなければならない領域 (作業分野)。利用できる既存のプロセスやツールが存在しない場合は、サポート・ツールと共に、大部分の RUP を導入する必要があります。詳しくは、 ../workflow/environm/co_iproj.htm#Change Everything -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: プロジェクトでのプロセスの実装の「全変更」を参照してください。  
  • 既存のプロセスにおける問題点。組織が過去に問題を経験した領域の改善に焦点を当てます。
  • 使用するツール。プロジェクトで特定のツールを使用することを決定した場合、開発プロセスでは通常、RUP の対応する領域をカバーする必要があります。
  • 変化に対するプロジェクトの対応能力。組織の問題に関しては、特にそれらの問題の多くが同時に発生するような場合は、すべてを一度に修正しようとする傾向があります。 通常、これは致命的な誤りとなります。 組織も個人と同様、変更に適応する能力はありますが、その程度は限られています。 変更に対する対応能力が低い場合は、あまり急に変更を行わず、最初のプロジェクトでは RUP の 1 つか 2 つの作業分野のみを導入するようにします。
  • プロジェクトのメンバーが知識を欠いているか、専門ではない領域。開発プロセスでこれらの領域をカバーします。RUP で適切な情報を簡単に見つけることができることを確認します。

割り出された改善領域は、同じプロジェクトで初めて導入されるものとは限りません。既知の要素の数を削減し、開発組織が過去に最も困難を経験した領域に焦点を当てます。../workflow/environm/co_iproj.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: プロジェクトでのプロセスの実装で説明されている通り、RUP を反復的に実装することをお勧めします。複数の作業分野で改善の必要な領域が発見される場合がありますが、それらすべてを一度に変更するのではなく、複数のプロジェクトに渡って反復的に導入するオプションを検討します。

そのようなトレードオフの一例として、要求をユース ケースと共に導入し、新しい構成管理プロセスの導入を延期することがあります。これは、以前のプロジェクトで不明確または不十分な要求のために困難を味わったり、納品した製品がニーズを満たしていないというエンドユーザーからの苦情があったりした場合に行います。

行ったトレードオフは文書化し、範囲に関する決定を外部の利害関係者に伝える必要があります。 RUP Builder 製品で構成を作成すると、これらの決定を構成の説明として文書化でき、発行済みの Web サイトに掲載されます。

プロセス・フレームワークの拡張 (オプション) ページの先頭へ

目的:  プロジェクト固有のプロセスに対し、RUP プロセス フレームワークでは十分にカバーされないと思われるプロジェクトの領域について、プロセスのノウハウを追加する。

RUP プロセス・フレームワークの強みとして、幅広い範囲のプロジェクトと環境に適用できることが挙げられます。しかし、このことは同時に短所として捉えられる場合もあります。プロセス説明が一般的になり過ぎるためです。RUP プラグイン技術は、ツールまたは技術のベンダーや個々の企業が、プラグインを通じてより特化したプロセス説明を作成できるようにすることによって、これらの問題の一部を解決するために設計されています。developerWorks®: Rational® の RUP セクションには、ダウンロード可能な最新プラグインのリストがあります。

../res_processworkbench.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんRational Process Workbench™ (RPW) 製品 は、RUP プラグイン技術を使用して RUP 拡張の作成を可能にします。 この技術の推奨事項に従うと、RUP フレームワークを 2 つの方法で拡張できます。 構造的プラグインを作成して RUP プロセス・モデルを拡張するか、シン・プラグインを通じてプロジェクトに開発組織の関連する再利用可能な資産を提供する拡張を作成します。

RUP プラグイン (構造) の作成は、個別の計画、予算、管理メカニズムが用意された、独立したプロジェクトとして扱う必要があります。投資効果分析に基づいて、このプラグインの開発企画書を作成する必要があります。プラグインの実際の開発は、RUP のライフサイクルと作業分野に従うことによって恩恵を得ることができます。実際のプロジェクトでは、プラグインの背景にある主なアイデアを試してみてから、開発に着手することをお勧めします。

詳しくは、../workflow/environm/co_polpr.htm#Extend -- このハイパーリンクは、生成されたこの Web サイト内に存在しません「ガイドライン: RUP のカスタマイズ」の「RUP フレームワークの拡張」を参照してください。

プロセスの構成ページの先頭へ

目的:  プロジェクトの本当のニーズをサポートするためのプロセスの規模を正しく設定する。

RUP フレームワークは、一連のプロセス コンポーネントとプラグインで構成されます。各コンポーネントには、関連する一連のプロセス要素が含まれます。RUP 構成を作成することは、一連のプロセス コンポーネントの中から必要なコンポーネントを選択することを意味します。特定のプロジェクトにとって正しいコンポーネント セットを選択することは、簡単な作業ではありません。プロセスが効果的であるためには、プロジェクトの規模 (要員と所要日数)、形式性、技術プラットフォーム、ドメインなどの異なる特性について、適切で、正しい規模である必要があります。

RUP の構成について詳しくは、以下を参照してください。

プロジェクトのプロセスの準備ページの先頭へ

目的:  構成済みのプロセスをプロジェクトに適用する方法を定義する。

プロジェクトについて構成されたプロセス説明は、多くの場合、すぐに適用できるほど詳細なレベルには達していません。たとえば、プロセスでは、適切なプロセス コンポーネントの選択 (前の項で紹介した「RUP 構成の作成」で説明) に基づいて、使用する成果物セットが定義されますが、特定のプロジェクトの成果物を使用するタイミングや形式性の要求は指定されていません。慣例的なガイドラインや部分的にインスタンス化された成果物テンプレートも、プロジェクト固有のインスタンス化されたプロセスの一部として見なされます。このステップを実行するために必要な作業は、構成済みのプロセスの精度に大きく依存します。基礎になるプロセスからの逸脱は、正当化し、プロジェクト固有のプロセスの一部として文書化する必要があります。

サブトピック:

ライフサイクル分解の定義「プロジェクトのプロセスの準備」へ

プロジェクトに対して構成されたプロセスをインスタンス化する作業には、プロジェクトで従うライフサイクル モデルを決定し、フェーズや反復に分解することも含まれます。カスタマイズ作業のこの部分では、プロセス エンジニアはプロジェクト管理者と密接に連携して作業する必要があります。選択されたライフサイクル モデルは、プロジェクト計画プロセスの基盤になるからです。プロジェクトの性質によっては、RUP ライフサイクルを特定のニーズに合わせて調整する必要が生じる場合もあります。たとえば、ゼロから始める開発では、方向付けフェーズで保守プロジェクトより多くの作業が必要です。そのため、ライフサイクルの説明をプロジェクトの性質に従って調整する必要があります。ライフサイクル モデルのさまざまなタイプについて詳しくは、「概念: 反復」を参照してください。

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

構成済みのプロセスには、プロジェクトによって作成される成果物の説明が含まれます。構成は特定タイプのプロジェクトに適合するように定義されるので、選択はインスタンス化プロセスの一部として取りかかる必要があります。なぜ成果物が必要なのかを説明できない場合は、その作成を計画しないでください。成果物には以下のような情報を付加する必要があります。

  • どのフェーズで成果物を作成または更新するか
  • 成果物に必要な形式性は何か (顧客による承認が必要か、など)
  • 成果物を作成するためにどのツールを使用するか

これらの情報は、プロセスの Web サイトからアクセスできるスプレッドシートまたは文書に記録されます。プロセス説明の主要部分にすることもできます。

プロジェクトの成果物リソースの準備 ページの先頭へ

プロジェクト固有の任意のプロセスの一部として、プロジェクト成果物の作成に向けて、特定の補助資料や参考資料を提供するためにカスタマイズされたリソース セットが用意されている必要があります。たとえば次のようなリソースがあります。

  • 特定の成果物の作成方法に関する共通のガイドライン。ユース ケース モデリング ガイドラインなど。
  • プロジェクト間で使用できるようにカスタマイズされたテンプレート。これらはプロジェクト情報を使用して部分的にインスタンス化されます。
  • プロジェクトの定義済み納品可能物セットと、選択された技術に関連する成果物の例。
  • 再利用可能な資産。設計パターンやコード ライブラリなど。

プロジェクトの開始時、プロジェクト管理者は通常、プロセス エンジニアと共同で作業して、適切なリソース セットを選択し、プロジェクトのメンバーがそれらをプロジェクト固有のプロセスの一部として利用できるようにします。追加リソースが必要かどうかは、各反復の開始時に再検討します。

プロジェクト・メンバーへのプロセスの公開 ページの先頭へ

目的:  プロジェクト固有のプロセスをプロジェクトのメンバーが利用できるようにする。

初期のカスタマイズ作業が終わったら、完成したプロセスを使用可能な形式に発行する必要があります。RUP Builder 製品では、構成済みのプロセスを発行する手段を提供しており、選択されたプロセス・コンポーネントとリソースだけを含む RUP Web サイトにすることができます。 プロセス・エンジニアはプロジェクト管理者と共同で作業して、プロジェクト固有のプロセスを公開し、プロジェクト・メンバーの教育方法を決定します。教育方法は、非公式で短時間のプレゼンテーションから、より公式のトレーニングまで、さまざまです。プロジェクトの規模と、プロジェクト・メンバーが持つ同様の開発プロセスの経験に応じて異なります。プロジェクトのライフサイクルでプロセスの重要な更新が行われた場合は、そのたびにプロジェクトに再導入し、変更に焦点を当てる必要があります。

プロジェクト固有のプロセスの Web サイトは、組織ネットワークの Web サーバーで発行したり、各チーム メンバーのコンピュータにインストールしたりできます。プロジェクトのメンバーがネットワークに常時接続している場合は、RUP Web サイトを Web サーバーに配置して、プロジェクトのライフサイクルで行われるプロセスの更新に関連するオーバーヘッドを回避することをお勧めします。

プロセスの維持ページの先頭へ

カスタマイズ作業のほとんどはプロジェクトの初期に行いますが、プロジェクト・チームがプロジェクトの過程で障害やその他の問題を発見するたびに、継続的に実行する必要があります。プロジェクトで行った評価は、プロセスを改善するための重要な入力情報です。小規模な調整は通常、プロジェクトで処理し、プロジェクト固有のプロセスに対する更新は、次回の反復の開発環境準備の一部として行います。 より複雑な問題は、プロセスに対する変更依頼として提起されます。 変更依頼は通常、プロジェクト外部のプロセス・グループによって処理されます。プロセス・グループは、組織全体のソフトウェア開発プロセスに対する責務があります。

反復型開発の大きな利点の 1 つとして、プロジェクト チームがソフトウェア開発方法を徐々に改善できるという点が挙げられます。すべてのプロジェクトで、以下のステップで構成されるプロセス エンジニアリングの小サイクルを取り入れることをお勧めします。

  • プロセスの定義
  • 定義済みのプロセスに基づくプロジェクト作業の実行
  • 作業の評価
  • プロセスの洗練

../res_processworkbench.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんRational Process Workbench 製品内のプロセス エンジニアリング プロセスには、組織設定でのプロセス改善に関する情報が含まれています。



Rational Unified Process   2003.06.15