シナリオ: 小規模プロジェクトでの RUP の採用

トピック

プロジェクトの概要 ページの先頭へ

../process/artifact/ar_devcs.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんここでは、ABC Company のプロジェクト X のシナリオを示します。プロジェクト X は、プロジェクト管理者 (ジル) と 4 人のプログラマ (アンガス、デビット、スーザン、フィリップ) で構成されるチームです。プロジェクトの期間は 4 か月です。

ジルは、プロジェクトのソフトウェア開発プロセスの基本として RUP を使用することを考えています。彼女は、RUP をインストールします。デフォルトでは、「Classic RUP」プロセス構成がインストールされます。Classic RUP の、プロジェクトに対するプロセスのカスタマイズに関する部分を調べます。

まず、チームと相談して、プロジェクトに対するプロセスのニーズを評価することから始めます。評価の結果は次のとおりです。

  • 構成管理用の既存のプロセスやツールは十分に機能する。したがって、プロセスのこれらの面は変更せずに、現在のまま残すことができる。
  • チームは、ユース ケースやコンポーネント アーキテクチャについていくらか経験があるが、これらの分野に関するガイダンスを使用している
  • 主なプロジェクト リスクを早期に削減するという意味で、反復開発の恩恵を受けられる
  • 利害関係者には、開発チームと作業に関して親密なよい関係がある。正式な契約やレビューの必要性はない。利害関係者は開発期間を通して確認を行える。チームのスキルは高く、十分に訓練されており、過去に正式なプロセスを使用せずに品質の高い製品を作成している。
  • プロジェクトに短い期間を設けて、ツールセットにわずかな変更だけを行う
  • ツールの利点や再利用の可能性を調査したり、将来のプロジェクトのためにプロセスを洗練するために、別の作業を並行して行う

ジルは続いて、チームに対して適切なプロセスのカスタマイズ作業に取りかかります。

基本的なカスタマイズ ページの先頭へ

ジルは、RUP Builder を起動して、まず Small Project テンプレートの構成を開始します。コンポーネントとプラグインを取捨選択して、プロセスの大まかな構成を行います。たとえば、プロセス コンポーネントの「データベース設計」は除外します。このプロジェクトではデータ モデリングを行いません。

結果的に、プロセスはプロジェクトのニーズに近いものになりましたが、まだ少し足りない部分があります。ジルは、プロセス ビューに次のようなプロジェクト固有のページを追加して、プロセスをさらに洗練します。

  • プロジェクトで使用するツールに関するガイドライン
  • 以前の類似プロジェクトから再利用したガイドライン (設計ガイドラインと構成と変更管理ガイドラインなど)
  • レビューと評価のガイドライン

ジルは、Getting Started ビューに「プロジェクト X プロセスの概要」というページを追加します。このページで、構成したプロセスの基本的な見解を説明します。たとえば、含まれるテンプレートは内容の手引きとなるが、形式についてはオプションであること、などを記述します。また、プロジェクトの主な成果物の現行バージョンがどこに保管されているかも記述します。

次に、ジルは構成を「ABC プロジェクト X」として保存し、公開します。

役割とライフサイクルページの先頭へ

プロジェクト X は小規模なチームです。したがって、チームの各人は RUP のさまざまな役割を担当します。ジルは、各メンバーの責務をソフトウェア開発計画書に記述します。たとえば、プロジェクト X において、ジルはプロジェクト管理者とプロセス エンジニアの役割を担当します。

また、プロジェクトのライフサイクルもソフトウェア開発計画書に記述します。フェーズ、反復、主要なマイルストーンもここで示します。

レビュー ページの先頭へ

ジルは、構成した RUP、開発個別定義書、ソフトウェア開発計画書の草案を、チームとその他の利害関係者にレビュー用に示します。チームはプロセスに従って作業を開始します。間違いがあれば、プロセスは洗練されます。最終的にプロジェクトは成功し、チームは将来的なプロジェクトに適用できる調整されれたプロセスを入手できます。

Rational Unified Process   2003.06.15