作業:
|
目的
|
|
役割: プロセス エンジニア | |
頻度: 作業のほとんどはプロジェクトの開始時に行う。 必要に応じて、反復で繰り返す。 | |
手順 | |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: | |
詳細情報: |
ワークフローの詳細: |
目的: | 目前にある問題と、プロジェクトに投入できる要員を大まかに把握する。 |
プロジェクトが成功するためには、その開発プロセスが、目前のプロジェクトと、プロジェクトの規模と形式性の要求にとって適切であることが不可欠です。 プロセスがあまりに多いと、創造性や効率性が損なわれる結果を招く場合があります。 プロセスが少なすぎると、無秩序な環境につながる場合があります。一般的に、個々のプロジェクト・メンバーが局所的に決定を行うため、非効率的で、一貫性がなく、予測不可能な結果が生じることになります。
プロセスの作法は開発組織ごとに大きく異なります。ある組織では、プロセスに関して成熟した手法を持ち、専門のプロセス グループが、組織全体を通じた開発プロセスの定義と改善を担当します。別の組織では、プロジェクト固有のカスタマイズだけに関与します。これらのプロジェクトは通常、RUP 製品に付属する定義済みの構成を使用して開始され、プロジェクトごとにプロセスがインスタンス化されます。プロジェクトのプロセスをカスタマイズするためのアプローチは、以下に示す複数の要素に大きく依存します。
詳しくは、「ガイドライン: プロセスの識別」を参照してください。
目的: | プロジェクト固有のプロセスでカバーするプロセス領域を定義する。 |
プロジェクトの要員と、それらの要員が持つ同様のソフトウェア開発プロジェクトの経験を分析した結果は、カスタマイズ作業の範囲を特定する上で役に立ちます。プロジェクト固有のプロセスは、RUP のすべての作業分野を含んでいる必要はありません。また、RUP で定義されているすべての役割をカバーする必要もありません。RUP は、さまざまなタイプのプロジェクトに適したプロセス フレームワークであり、1 つの特定のプロジェクトで準拠するには範囲が広すぎることを覚えておいてください。プロジェクトのプロセスでカバーするためにどの領域を選択するかは、プロジェクト メンバーの既存のスキル セットと、目前のプロジェクトの性質に大きく依存します。カスタマイズ作業の範囲を定義するときの一般的な検討事項を以下に示します。
割り出された改善領域は、同じプロジェクトで初めて導入されるものとは限りません。既知の要素の数を削減し、開発組織が過去に最も困難を経験した領域に焦点を当てます。概念: プロジェクトでのプロセスの実装で説明されている通り、RUP を反復的に実装することをお勧めします。複数の作業分野で改善の必要な領域が発見される場合がありますが、それらすべてを一度に変更するのではなく、複数のプロジェクトに渡って反復的に導入するオプションを検討します。
そのようなトレードオフの一例として、要求をユース ケースと共に導入し、新しい構成管理プロセスの導入を延期することがあります。これは、以前のプロジェクトで不明確または不十分な要求のために困難を味わったり、納品した製品がニーズを満たしていないというエンドユーザーからの苦情があったりした場合に行います。
行ったトレードオフは文書化し、範囲に関する決定を外部の利害関係者に伝える必要があります。 RUP Builder 製品で構成を作成すると、これらの決定を構成の説明として文書化でき、発行済みの Web サイトに掲載されます。
目的: | プロジェクト固有のプロセスに対し、RUP プロセス フレームワークでは十分にカバーされないと思われるプロジェクトの領域について、プロセスのノウハウを追加する。 |
RUP プロセス・フレームワークの強みとして、幅広い範囲のプロジェクトと環境に適用できることが挙げられます。しかし、このことは同時に短所として捉えられる場合もあります。プロセス説明が一般的になり過ぎるためです。RUP プラグイン技術は、ツールまたは技術のベンダーや個々の企業が、プラグインを通じてより特化したプロセス説明を作成できるようにすることによって、これらの問題の一部を解決するために設計されています。developerWorks®: Rational® の RUP セクションには、ダウンロード可能な最新プラグインのリストがあります。
Rational Process Workbench™
(RPW) 製品 は、RUP プラグイン技術を使用して RUP 拡張の作成を可能にします。
この技術の推奨事項に従うと、RUP フレームワークを 2 つの方法で拡張できます。
構造的プラグインを作成して RUP プロセス・モデルを拡張するか、シン・プラグインを通じてプロジェクトに開発組織の関連する再利用可能な資産を提供する拡張を作成します。
RUP プラグイン (構造) の作成は、個別の計画、予算、管理メカニズムが用意された、独立したプロジェクトとして扱う必要があります。投資効果分析に基づいて、このプラグインの開発企画書を作成する必要があります。プラグインの実際の開発は、RUP のライフサイクルと作業分野に従うことによって恩恵を得ることができます。実際のプロジェクトでは、プラグインの背景にある主なアイデアを試してみてから、開発に着手することをお勧めします。
詳しくは、「ガイドライン: RUP のカスタマイズ」の「RUP フレームワークの拡張」を参照してください。
目的: | プロジェクトの本当のニーズをサポートするためのプロセスの規模を正しく設定する。 |
RUP フレームワークは、一連のプロセス コンポーネントとプラグインで構成されます。各コンポーネントには、関連する一連のプロセス要素が含まれます。RUP 構成を作成することは、一連のプロセス コンポーネントの中から必要なコンポーネントを選択することを意味します。特定のプロジェクトにとって正しいコンポーネント セットを選択することは、簡単な作業ではありません。プロセスが効果的であるためには、プロジェクトの規模 (要員と所要日数)、形式性、技術プラットフォーム、ドメインなどの異なる特性について、適切で、正しい規模である必要があります。
RUP の構成について詳しくは、以下を参照してください。
目的: | 構成済みのプロセスをプロジェクトに適用する方法を定義する。 |
プロジェクトについて構成されたプロセス説明は、多くの場合、すぐに適用できるほど詳細なレベルには達していません。たとえば、プロセスでは、適切なプロセス コンポーネントの選択 (前の項で紹介した「RUP 構成の作成」で説明) に基づいて、使用する成果物セットが定義されますが、特定のプロジェクトの成果物を使用するタイミングや形式性の要求は指定されていません。慣例的なガイドラインや部分的にインスタンス化された成果物テンプレートも、プロジェクト固有のインスタンス化されたプロセスの一部として見なされます。このステップを実行するために必要な作業は、構成済みのプロセスの精度に大きく依存します。基礎になるプロセスからの逸脱は、正当化し、プロジェクト固有のプロセスの一部として文書化する必要があります。
サブトピック:
プロジェクトに対して構成されたプロセスをインスタンス化する作業には、プロジェクトで従うライフサイクル モデルを決定し、フェーズや反復に分解することも含まれます。カスタマイズ作業のこの部分では、プロセス エンジニアはプロジェクト管理者と密接に連携して作業する必要があります。選択されたライフサイクル モデルは、プロジェクト計画プロセスの基盤になるからです。プロジェクトの性質によっては、RUP ライフサイクルを特定のニーズに合わせて調整する必要が生じる場合もあります。たとえば、ゼロから始める開発では、方向付けフェーズで保守プロジェクトより多くの作業が必要です。そのため、ライフサイクルの説明をプロジェクトの性質に従って調整する必要があります。ライフサイクル モデルのさまざまなタイプについて詳しくは、「概念: 反復」を参照してください。
構成済みのプロセスには、プロジェクトによって作成される成果物の説明が含まれます。構成は特定タイプのプロジェクトに適合するように定義されるので、選択はインスタンス化プロセスの一部として取りかかる必要があります。なぜ成果物が必要なのかを説明できない場合は、その作成を計画しないでください。成果物には以下のような情報を付加する必要があります。
これらの情報は、プロセスの Web サイトからアクセスできるスプレッドシートまたは文書に記録されます。プロセス説明の主要部分にすることもできます。
プロジェクト固有の任意のプロセスの一部として、プロジェクト成果物の作成に向けて、特定の補助資料や参考資料を提供するためにカスタマイズされたリソース セットが用意されている必要があります。たとえば次のようなリソースがあります。
プロジェクトの開始時、プロジェクト管理者は通常、プロセス エンジニアと共同で作業して、適切なリソース セットを選択し、プロジェクトのメンバーがそれらをプロジェクト固有のプロセスの一部として利用できるようにします。追加リソースが必要かどうかは、各反復の開始時に再検討します。
目的: | プロジェクト固有のプロセスをプロジェクトのメンバーが利用できるようにする。 |
初期のカスタマイズ作業が終わったら、完成したプロセスを使用可能な形式に発行する必要があります。RUP Builder 製品では、構成済みのプロセスを発行する手段を提供しており、選択されたプロセス・コンポーネントとリソースだけを含む RUP Web サイトにすることができます。 プロセス・エンジニアはプロジェクト管理者と共同で作業して、プロジェクト固有のプロセスを公開し、プロジェクト・メンバーの教育方法を決定します。教育方法は、非公式で短時間のプレゼンテーションから、より公式のトレーニングまで、さまざまです。プロジェクトの規模と、プロジェクト・メンバーが持つ同様の開発プロセスの経験に応じて異なります。プロジェクトのライフサイクルでプロセスの重要な更新が行われた場合は、そのたびにプロジェクトに再導入し、変更に焦点を当てる必要があります。
プロジェクト固有のプロセスの Web サイトは、組織ネットワークの Web サーバーで発行したり、各チーム メンバーのコンピュータにインストールしたりできます。プロジェクトのメンバーがネットワークに常時接続している場合は、RUP Web サイトを Web サーバーに配置して、プロジェクトのライフサイクルで行われるプロセスの更新に関連するオーバーヘッドを回避することをお勧めします。
カスタマイズ作業のほとんどはプロジェクトの初期に行いますが、プロジェクト・チームがプロジェクトの過程で障害やその他の問題を発見するたびに、継続的に実行する必要があります。プロジェクトで行った評価は、プロセスを改善するための重要な入力情報です。小規模な調整は通常、プロジェクトで処理し、プロジェクト固有のプロセスに対する更新は、次回の反復の開発環境準備の一部として行います。 より複雑な問題は、プロセスに対する変更依頼として提起されます。 変更依頼は通常、プロジェクト外部のプロセス・グループによって処理されます。プロセス・グループは、組織全体のソフトウェア開発プロセスに対する責務があります。
反復型開発の大きな利点の 1 つとして、プロジェクト チームがソフトウェア開発方法を徐々に改善できるという点が挙げられます。すべてのプロジェクトで、以下のステップで構成されるプロセス エンジニアリングの小サイクルを取り入れることをお勧めします。
Rational Process Workbench 製品内のプロセス エンジニアリング プロセスには、組織設定でのプロセス改善に関する情報が含まれています。
Rational Unified Process
|