|
Serge Charbonneau
Xelaration Software Corporation
2004年5月3日
「The Rational Edge」より転載: この記事では、ラショナル統一プロセス(RUP)とPMIの「Project Management Body of Knowledge」(PMBOK)を比較して、RUPプロジェクト管理の原則における最善の実践原則とPMBOKのベスト・プラクティス最善の実践原則との対応を示します。
多くの組織では、ソフトウェア・エンジニアリングの原則やプロジェクト管理(PM)の原則の標準化を望んでいますが、これらの領域では周知の2つのプロセスをそれぞれに利用できます。IBMR RationalR Unified ProcessR (RUPR)は、ソフトウェア・エンジニアリングの最善の実践原則に基づき標準化を図る規範的なアプローチであり、Project Management InstituteR (PMIR) によるProject Management Body of KnowledgeR (PMBOKR)のガイドは、プロジェクト管理のベスト・プラクティスに基づき標準化を行う記述的アプローチです。組織ではこれら両アプローチが使用可能なことから、比較は可能なのかという問いが生まれます。もちろん答は「Yes」です。
この文書では、この問いに対して、RUPプロジェクト管理(PM)の原則の最善の実践原則をPMBOKのベスト・プラクティスに対応させながら、詳細な回答を示します。このマッピングでは、両者間の類似点と相違点を強調したいと思います。基本的に、RUPはソフトウェア開発と配置プロジェクトに関連してPMの最善の実践原則を強調するのに対し、PMBOKのベスト・プラクティスは汎用的な原則で、あらゆる適用領域に-橋の建設から企業の新しいビジネス・プロセスの導入まで-適用されます。このため、適用領域の観点からは、RUP PMの原則は、PMBOKの汎用PMベスト・プラクティスのインスタンスであると言えます。
この文書であげるRUP PMの最善の実践原則とは、RUP1のPMの原則以下に述べられた原則です。何かしらの形でPMに関連した他の最善の実践原則は、ビジネス・モデリング、要求、分析と設計、実装、テスト、配置、および構成と変更管理など、他のRUP原則以下に述べられており、本文書では必要に応じてこれらの原則についても触れることにします。また、ここであげるPMI PMベスト・プラクティスは、PMBOK2に記載されています。
RUPの概要
RUPは、ソフトウェアの開発および配置プロジェクトにおいて誰が何をいつどのような方法で行うかを記述したソフトウェア・エンジニアリング・プロセスです。ユース・ケース駆動、アーキテクチャー中心、リスク駆動、反復型という特性を持ちます。
これらの重要な各特性を考えてみましょう。RUPを使用したプロジェクトでは、ユース・ケースの形で表現された機能要求は、アプリケーションの実行可能なアーキテクチャーの実現の推進力となります。また、プロセスにおいては、アプリケーションの重要な振る舞いおよび構造上の要素(アーキテクチャー要素)の構築にチーム作業の重点を置き、重要性の低い要素の構築は後から行われます。最も重要なリスク要素の軽減は、そのライフサイクルの初期反復の範囲を定義する推進力となります。そして、RUPではソフトウェア開発のライフサイクルは、実行可能アプリケーションのインクリメンタル・バージョンを作成する反復へと分割されています。
RUPは、以下のソフトウェア・エンジニアリング最善の実践原則を実装しています。
- 反復的に開発すべし
- 要求を管理すべし
- コンポーネントに基づくアーキテクチャを使用すべし
- ビジュアルにモデリングすべし
- 継続的に品質を検証すべし
- 変更を管理すべし
RUPにおける次元
RUPでは、上記の最善の実践原則を2次元のプロセスで実装します。一方の次元で作業分野を記述しながら、もう一方の次元ではプロセスのライフサイクルにおける「フェーズ」を記述します。図1は、プロセスを高レベルなグラフィック表現で表したものです。
図1: ラショナル統一プロセス
RUPの作業分野
RUPの作業分野は、6つの最善の実践原則と明らかな関連を持ちますが、全開発チーム内のメンバーやサブグループの個々の役割をより密接に表すものです。これらの原則には、以下があります。
- ビジネス・モデリング
- 要求
- 分析／設計
- 実装
- テスト
- 導入
- プロジェクト管理
- 環境
- 構成と変更管理
RUPにおける各作業分野は、役割(誰がタスクを行うか)、作業(どのようにタスクを行うか)、および成果物(作業で何を達成するか)によって表されます。役割は、作業および成果物に対して責任を持つ個人またはグループの振る舞いと責務を定義します。作業は、役割による責務の対象となり実行を要求されるタスクで、成果物の作成または更新のために必要なステップを記述します。成果物は、作業の入力/出力です。他にもこれら3つの主要な要素を補うものとして、概念、作業ガイドライン、ツール・メンター、レポート、成果物ガイドライン、テンプレート、およびチェック・ポイントなどがあります。
図2に、役割、成果物、作業、およびRUPの他の補足要素を示します。
RUPのライフサイクル
先述のとおり、RUPのライフサイクルは反復型で、そのライフサイクルの次元は4つのフェーズに分かれます。
- 方向付け
- 推敲
- 作成
- 移行
各フェーズは、明確に定義された目標を持ち、主要マイルストーンの完了により終了します。各フェーズ最後のマイルストーンには、以下があります。
- 方向付けフェーズ最後でのライフサイクル目標マイルストーン
- 推敲フェーズ最後でのライフサイクル・アーキテクチャーマイルストーン
- 作成フェーズ最後での初期運用能力マイルストーン
- 移行フェーズ最後での製品リリースマイルストーン
方向付けの目標は、プロジェクトの範囲の定義です。推敲ではアプリケーションの実行可能アーキテクチャーを構築し、作成ではアーキテクチャーの骨組みにアプリケーションのほとんどの機能を盛り込んで具体化することが目標となります。最後に、移行では、エンド・ユーザー・コミュニティーに向けてアプリケーションを送り出します。
RUPの各フェーズはさらに、それぞれマイナー・マイルストーンにより終了する反復へと分割されます。
RUP プロジェクト管理の作業分野
先述のとおりRUPの作業分野については、プロジェクト管理(PM)の原則に基づき話を進めます。RUPでは、ソフトウェアのプロジェクト管理を、目標の達成、リスクの管理、そして制約の克服を考慮しながら顧客(開発対象のソフトウェアを要求する側)とソフトウェア・ユーザーの両者のニーズを満たす製品を提供する技法と定義されています。
RUP プロジェクト管理の作業分野は、以下を提供します。
- ソフトウェア集約型のプロジェクトを管理するフレームワーク
- プロジェクトの計画、要員配置、実行、および監視のための実際的なガイドライン
- リスク軽減のためのフレームワーク
この作業分野では主に、反復型の開発プロセスの重要な側面に注目します。
- リスク管理
- ライフサイクル全域にわたり、特に反復に焦点を当てた、反復型プロジェクトの計画
- 反復型プロジェクトの進行状況、メトリクスの監視
RUPとPMBOKの比較
ここでは、管理のいくつかの領域で、RUP プロジェクト管理の作業分野の範囲を外れ、PMBOKの原則で扱われるものを説明します。
- 人員の管理: 雇用、トレーニング、コーチング(PMBOK プロジェクトの人材管理の知識エリアに対応)
- 予算の管理: 定義、割り振りなど(PMBOK プロジェクトのコスト管理の知識エリアに対応)
- 契約の管理: サプライヤーおよび顧客(PMBOK プロジェクトの調達管理の知識エリアに対応)
以降のセクションでは、PMBOKの知識エリアについて詳述します。今のところ、9つのPMBOK知識エリアのうち3つ(人材管理、コスト管理、調達管理)には、対応するRUPの作業分野はありません。ただし、人材管理の組織計画プロセスは、プロジェクトの役割と責務を識別し、文書化して割り当てることを目的としており、RUPにおける「役割」に対応します。
主なRUP プロジェクト管理の成果物
RUP プロジェクト管理の原則では、多数の成果物が作成されます。以下に示す主な成果物には、一般的なプロジェクトで作成されるインスタンスの数を括弧内に記しています。
- ソフトウェア開発計画書(1)
- 品質保証計画書
- リスク管理計画書
- 測定計画書
- 製品検収計画書
- 問題解決計画書
- 開発企画書(1)
- 反復計画書(複数)
- 反復評価書(複数)
- ステータス評価書(複数)
- リスク・リスト(1)
- 作業指示書(複数)
- 問題点リスト(1)
- プロジェクト測定(複数)
RUPの特性をPMBOKにおける特性に対応させるため、上記の成果物を詳細に検討して、そのうち4つの性質について述べたいと思います。
1.ソフトウェア開発計画書:
- 方向付けフェーズで作成。
- ライフサイクルを通じて更新する。
- アウトライン:
- プロジェクトの概要
- プロジェクトの目的、開発範囲、および目標
- 前提および制約事項
- プロジェクトの成果物
- プロジェクトの編成
- 管理プロセス
- プロジェクト見積もり
- プロジェクト計画
- 反復計画
- プロジェクトのモニタリングおよび管理
- その他の計画
2、反復計画は:
- プロジェクト管理の成果物ではない(要求の成果物)
- 方向付けフェーズで作成します
- アウトライン:
- 位置付け
- 利害関係者およびユーザーの説明
- 利害関係者の説明
- ユーザーの説明
- 利害関係者のニーズ
- 製品の概要
- 製品の特徴
- 制約
- その他の情報
- 方向付けフェーズで作成します。
- アウトライン:
- 製品の説明
- ビジネス・コンテキスト
- 製品の目標
- 財務予測
- 制約
PMBOKの概要
次にPMBOKを見てみましょう。PMBOKには、ソフトウェアの開発および導入プロジェクトをはじめ、あらゆるタイプのプロジェクトの管理でPM実践者が使用することのできる、一般的に認知された原則が記述されています。
PMBOKでは、プロジェクトは「固有の製品またはサービスを作成するために行われる一時的活動」として定義されており、PMは「プロジェクトの要件を満たすため、知識、スキル、ツール、および技法をプロジェクトに適用すること」とされています。
PMBOKの次元
PMBOKでは、PMの原則を論理グループとして表しています。一つの次元は「知識エリア」を記述し、もう一方の次元では、5つのプロセス・グループに分けられたプロジェクト管理プロセスを記述しています。図3は、39のすべてのPMプロセスを高レベルなグラフィック表現で表したものです。3
| プロセスグループ |
Initiating |
Planning |
Executing |
Controlling |
Closing |
| 知識エリア |
| 4.プロジェクト統合マネジメント |
|
4.1 プロジェクト計画の策定 |
4.2 プロジェクト計画の実施 |
4.3 統合変更管理 |
|
| 5.プロジェクト・スコープ・マネジメント |
5.1 立ち上げ |
5.2 スコープ計画
5.3 スコープの定義 |
|
5.4 スコープの検証
5.5 スコープの変更管理 |
|
| 6.プロジェクト・タイム・マネジメント |
|
6.1 活動の定義
6.2 活動の順序設定
6.3 活動の所要期間見積り
6.4 スケジュール作成 |
|
6.5 スケジュール管理 |
|
| 7.プロジェクト・コスト・マネジメント |
|
7.1 資源計画
7.2 コスト見積り
7.3 コストの予算化 |
|
7.4 コスト管理 |
|
| 8.プロジェクト・品質・マネジメント |
|
8.1 品質計画 |
8.2 品質保証 |
8.3 品質管理 |
|
| 9.プロジェクト・人的資源・マネジメント |
|
9.1 組織計画
9.2 要員調達 |
9.3 チームの育成 |
|
|
| 10.プロジェクト・コミュニケーション・マネジメント |
|
10.1 コミュニケーション計画 |
10.2 情報配布 |
10.3 実績報告 |
10.4 完了手続き |
| 11.プロジェクト・リスク・マネジメント |
|
11.1 リスク・マネジメント計画
11.2 リスクの識別
11.3 定性的リスク分析
11.4 定量的リスク分析
11.5 リスク対応の計画 |
|
11.6 リスクの監視・コントロール |
|
| 12.プロジェクト・調達・マネジメント |
|
12.1 調達計画
12.2 引合計画 |
12.3 引合
12.4 発注先選定
12.5 契約管理 |
|
12.6 契約完了 |
|
図3: PMBOK PMプロセス
PMBOK知識エリアとプロセス・グループ
PMBOKの知識エリアは次のとおりです。
- プロジェクトの統合マネジメント
- プロジェクトのスコープマネジメント
- プロジェクトのタイムマネジメント
- プロジェクトのコストマネジメント
- プロジェクトの品質マネジメント
- プロジェクトの人的資源マネジメント
- プロジェクトのコミュニケーションマネジメント
- プロジェクトのリスクマネジメント
- プロジェクトの調達マネジメント
PMBOKの各知識エリアは、1つ以上のプロセスからプロジェクト管理の知識と実践について記述しています。各プロセスはさらに、入力、出力、およびツールと技法により記述されます。入力と出力は、文書または文書項目です。ツールと技法は、出力を作成するために入力に適用されるメカニズムです。
これら39のプロセスは、5つのプロセス・グループに分けられます。
- 立ち上げプロセス
- 計画プロセス
- 実行プロセス
- コントロール・プロセス
- 終結プロセス
図4に、5つのプロセス・グループを示します。
図4: PMBOKプロセス・グループ
PMBOKのライフサイクル
PMBOKでは、プロジェクトに特定のライフサイクルを規定せず、プロジェクトのライフサイクルをフェーズに分けるよう指定しています。フェーズの数は、プロジェクトの範囲と適用領域により異なります。あらゆるタイプのプロジェクトについて、4〜9つのフェーズが一般的であると示されています。
PMBOKの成果物
PMBOKでは、成果物を「実現可能性の探求や、詳細設計、作業プロトタイプなど、具体的な検証可能な作業結果」と定義しています。
PMBOKの主な成果物に、以下があります。
- プロジェクト計画(参考となる詳細含む)
- 作業結果と変更要求
- 是正措置と教訓
- プロジェクト憲章(制約と仮定を含む)
プロジェクト計画:
- プロジェクトのライフサイクル初期にプロジェクト計画の作成プロセスで作成
- プロジェクトのライフサイクルを通じて更新
- 概略:
- プロジェクト憲章
- プロジェクト管理のアプローチまたは戦略
- スコープ記述
- WBS (Work Breakdown Structure)
- 成果物のコスト見積もり、スケジュールと責務の割り当て
- スコープ、スケジュール、コストの測定ベースライン
- 主要マイルストーンおよび目標期日
- 必要な要員
- その他計画
プロジェクト計画の特性の1つであるプロジェクト憲章について考えてみましょう。プロジェクト憲章には、次のように独自の特性があります
- プロジェクトに正式の権限を与える
- プロジェクトのライフサイクル初期に立ち上げプロセスで作成される
- アウトライン:
PMBOKとRUPのマッピング
以下のセクションでは、RUPとPMBOKとのマッピングを示します。ほとんどの場合、RUP要素を完全にPMBOK要素に対応させることはできず、その逆も同じです。この文書で示したマッピングは、私の視点からこれら2つの標準を相互に対応させたもので、若干異なるマッピングも存在します。4
RUPとPMBOKを対応させるにあたり、両者のうちより一般的なPMBOKを基準にしてRUPを対比させています。
共通の特性
RUPおよびPMBOKはともに、プロジェクト管理を反復型の作業と認識しています。PMBOKでは、以下の項に記されています。
プロジェクト管理の多くのプロセスは本来反復するものと認識することが重要です。これは一部に、プロジェクトではライフサイクルを通じて段階的に推敲を行うことと、またその必要があることによるものです。つまり、プロジェクトの理解が深まるほど、管理が行き届きます。
表1に、PMBOKとRUPの主な特性の対応を示します。
| PMBOK |
RUP |
| すべてのタイプのプロジェクト |
ソフトウェアに特化したプロジェクト |
| プロジェクト管理に関するプラクティスのみ |
プロジェクト管理とそのほかのソフトウェア開発に関するプラクティス |
| プロジェクト管理のすべての側面をカバー |
プロジェクト管理のいくつかの側面をカバー |
| 説明的 |
規範的 |
| フェーズは適用領域に依存 |
フェーズと反復はソフトウェア開発に特化 |
|
表1: PMBOKとRUPの主な特性
PMBOKとRUPのメタモデル・マッピング
RUPとPMBOKはともに、作業を構造上のグループと時間的なグループに分類しています。RUPには、作業分野と呼ばれる作業の構造グループと、ワークフローと呼ばれる作業の時間グループが存在します。PMBOKには、作業エリアと呼ばれるプロセスの構造グループと、プロセス・グループとされるプロセスの時間グループがあります。
表2は、RUPとPMBOKのメタモデル間の対応を示します。
| プロジェクトタイプ |
すべてのタイプのプロジェクト |
ソフトウェア開発とデプロイメントのプロジェクト |
| プロジェクトのライフサイクル |
フェーズに分割されます。
通常4か5で、最大時9以上の場合もあります。
各フェーズは1つ以上の成果物の完了によってマークされます。 |
方向付け、推敲、作成、移行の４つのフェーズに分割されます。各フェーズはすべての作業分野に基づくアクティビティを含む１から複数の反復に分割されます。
各反復ではソフトウェアやシステムの実行可能なバージョンを提供します。 |
| フェーズの終了 |
マイルストーン |
メジャーなマイルストーン |
| フェーズ成果物の終了 |
納品物 |
成果物 |
| アクティビティ |
入力、出力、ツールテクニックで記述される内容で処理する |
成果物は入力成果物、出力成果物、ツールメンターとガイドラインによるステップで記述されます。 |
| 入力成果物 |
入力 |
入力成果物 |
| 出力成果物 |
出力 |
結果となる成果物 |
| フェーズの終了時のレビュー |
フェーズの出口、ステージの出入口、中断点 |
ライフサイクルメイルストーンのレビュー |
| 構造的なアクティビティのグループ |
知識エリア |
作業分野 |
| 時間的なアクティビティのグループ |
プロセスグループ |
ワークフロー |
|
表2: PMBOKとRUPのメタモデル・マッピング
PMBOK知識エリアとRUP作業分野のマッピング
表3は、PMBOK知識エリアとRUPの作業分野との対応を示します。
| PMBOK 知識エリア |
RUP 作業分野 |
| プロジェクト統合マネジメント |
・プロジェクト管理
・要求
・導入
・構成と変更管理 |
| プロジェクト・スコープ・マネジメント |
・プロジェクト管理
・要求
・構成と変更管理 |
| プロジェクト・タイム・マネジメント |
プロジェクト管理 |
| プロジェクト・コスト・マネジメント |
プロジェクト管理 |
| プロジェクト品質マネジメント |
・プロジェクト管理
・構成と変更管理 |
| プロジェクト人的資源マネジメント |
プロジェクト管理 |
| プロジェクト・コミュニケーション・マネジメント |
プロジェクト管理 |
| プロジェクト・リスク・マネジメント |
プロジェクト管理 |
| プロジェクト調達マネジメント |
要求 |
|
表3: PMBOK知識エリアとRUP作業分野のマッピング
PMBOKプロセスとRUP作業のマッピング
表4は、PMBOKプロセスとRUP作業との対応を示します。PMBOKプロセスは、<PMBOKセクション番号> <知識エリア> → <プロセス>の形式で、知識エリアごとにまとめられています。対応するRUP作業は、<作業分野> → <作業>の形式で示されています。
表4: PMBOKプロセスとRUP作業のマッピング
| PMBOK Process |
RUP Activities |
| 4. 1 プロジェクト統合マネジメント → プロジェクト計画の策定 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復計画書の作成 |
| プロジェクト管理 → 製品検収計画書の作成 |
| プロジェクト管理 → ソフトウェア開発計画書の編集 |
| プロジェクト管理 → 開発企画書の作成 |
| 要求 → 開発構想の作成 |
| 導入 → 導入計画書の作成 |
| 環境のすべてのアクティビティ |
| 4. 2 プロジェクト統合マネジメント → プロジェクト計画の実施 |
プロジェクト管理 → プロジェクトのステータスの監視 |
| プロジェクト管理 → 作業のスケジュール作成と割り当て |
| プロジェクト管理 → ステータスのレポート |
| プロジェクト管理 → 例外と問題の処理 |
| 構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 識別されていないすべてのビジネスモデリング、要求、分析・設計、実装、テスト、導入、構成と変更管理のすべてのアクティビティ |
| 4. 3 プロジェクト統合マネジメント → 統合変更管理 |
構成と変更管理 → 変更依頼のレビュー |
| 構成と変更管理 → 重複または却下された変更依頼の確認 |
| 「4. 1 プロジェクト統合マネジメント→プロジェクト計画の策定」を参照 |
| プロジェクト管理 → ステータスのレポート |
| プロジェクト管理 → 反復の評価 |
| 5. 1 プロジェクトスコープマネジメント → 立ち上げ |
プロジェクト管理 → プロジェクトの開始 |
| プロジェクト管理 → 反復の開始 |
| プロジェクト管理 → 開発企画書の作成 |
| 要求 → 開発構想の作成 |
| 5.2 プロジェクトスコープマネジメント - スコープ計画 |
プロジェクト管理 → 問題分析計画書の作成 |
| 要求 → 要求管理計画書の作成 |
| 構成と変更管理 → 構成管理計画書の作成 |
| 要求 → 開発構想の作成 |
| 要求 → アクターとユースケースの獲得 |
| 要求 → ユースケースの詳細の作成 |
| 要求 → ソフトウェア要求の詳細の作成 |
| 要求 → 共通語彙の把握 |
| 5.3 プロジェクトスコープマネジメント → スコープの定義 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復の計画立案 |
| 要求 → 開発構想の作成 |
| 要求 → アクターとユースケースの獲得 |
| 要求 → ユースケースの詳細の作成 |
| 要求 → ソフトウェア要求の詳細の作成 |
| 要求 → 共通語彙の把握 |
| 5.4 プロジェクトスコープマネジメント → スコープの検証 |
プロジェクト管理 → ライフサイクルマイルストーンのレビュー |
| 要求 → 要求のレビュー |
| 5.5 プロジェクトスコープマネジメント → スコープの変更管理 |
プロジェクト管理 → ステータスのレポート |
| プロジェクト管理 → 反復の評価 |
| プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復計画書の作成 |
| 構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 要求 → 開発構想の作成 |
| 要求 → アクターとユースケースの獲得 |
| 要求 → ユースケースの詳細の作成 |
| 要求 → ソフトウェア要求の詳細の作成 |
| 要求 → 共通語彙の把握 |
| 6. 1 プロジェクトタイムマネジメント → 活動の定義 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復の計画立案 |
| 6. 2 プロジェクトタイムマネジメント → 活動の順序設定 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復計画書の作成 |
| 6. 3 プロジェクトタイムマネジメント → 活動の所要期間見積 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復計画書の作成 |
| 6.4 プロジェクトタイムマネジメント → スケジュール作成 |
プロジェクト管理 → フェーズと反復の計画立案 |
| プロジェクト管理 → 反復計画書の作成 |
| プロジェクト管理 → 問題分析計画書の作成 |
| 6. 5 プロジェクトタイムマネジメント → スケジュール管理 |
プロジェクト管理 → ステータスのレポート |
| プロジェクト管理 → 反復の評価 |
| 7. 1 プロジェクトコストマネジメント → 資源計画 |
プロジェクト管理 → 要員の確保 |
| 7.2 プロジェクトコストマネジメント → コスト見積 |
プロジェクト管理 → フェーズと反復の計画立案 |
| 7.3 プロジェクトコストマネジメント → コストの予算化 |
RUPとのマッピングなし |
| 7.4 プロジェクトコストマネジメント → コスト管理 |
RUPとのマッピングなし |
| 8. 1 プロジェクト品質マネジメント → 品質計画 |
プロジェクト管理 → 品質保証計画書の作成 |
| プロジェクト管理 → モニタリングおよび管理プロセスの作成 |
| プロジェクト管理 → 測定計画書の作成 |
| 8. 2 プロジェクト品質マネジメント → 品質保証 |
構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 8. 3 プロジェクト品質マネジメント → 品質管理 |
構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| すべての作業分野のレビューに関するアクティビティ |
| すべてのテストのアクティビティ |
| 9. 1 プロジェクト人的資産マネジメント → 組織計画 |
プロジェクト管理 → プロジェクト組織と要員配置の決定 |
| 9.2 プロジェクト人的資産マネジメント → チームの育成 |
プロジェクト管理 → 要員の確保 |
| 9.3 プロジェクト人的資産マネジメント → チームの育成 |
RUPとのマッピングなし |
| 10. 1 プロジェクトコミュニケーションマネジメント → コミュニケーション計画 |
プロジェクト管理 → ソフトウェア開発計画書の編集 |
| 10.2 プロジェクトコミュニケーションマネジメント → 情報配布 |
プロジェクト管理 → ステータスのレポート |
| プロジェクト管理 → 反復の評価 |
| 10.3 プロジェクトコミュニケーションマネジメント → 実績報告 |
プロジェクト管理 → モニタリングおよび管理プロセスの作成 |
| 構成と変更管理 → 変更管理の登録 |
| 構成と変更管理 → 変更管理の更新 |
| 10.4 プロジェクトコミュニケーションマネジメント → 完了手続き |
プロジェクト管理 → 反復の評価 |
| プロジェクト管理 → フェーズ終了の準備 |
| プロジェクト管理 → プロジェクト終了の準備 |
| 11.1 プロジェクトリスクマネジメント → リスクマネジメント計画 |
プロジェクト管理 → リスク管理計画書の作成 |
| 11.2 プロジェクトリスクマネジメント → リスクの識別 |
プロジェクト管理 → リスクの割り出しと評価 |
| 構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 11.3 プロジェクトリスクマネジメント → 定性的リスク分析 |
プロジェクト管理 → リスクの割り出しと評価 |
| 11.4 プロジェクトリスクマネジメント → 定量的リスク分析 |
プロジェクト管理 → リスクの割り出しと評価 |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 |
プロジェクト管理 → リスクの割り出しと評価 |
| 構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール |
プロジェクト管理 → リスクの割り出しと評価 |
| 構成と変更管理 → 変更依頼の登録 |
| 構成と変更管理 → 変更依頼の更新 |
| 12.1 プロジェクト調達マネジメント → 調達計画 |
RUPとのマッピングなし |
| 12.2 プロジェクト調達マネジメント → 引合計画 |
要求 → 開発構想の作成 |
| 12.3 プロジェクト調達マネジメント → 引合 |
RUPとのマッピングなし |
| 12.4 プロジェクト調達マネジメント → 発注先選定 |
RUPとのマッピングなし |
| 12.6 プロジェクト調達マネジメント → 契約完了 |
RUPとのマッピングなし |
| 12.5 プロジェクト調達マネジメント → 契約管理 |
RUPとのマッピングなし |
|
PMBOKプロセスの出力とRUP成果物のマッピング
表5は、PMBOKプロセスの出力とRUP成果物との対応を示します。PMBOK出力は、<PMBOKセクション番号> <知識エリア> → <プロセス> → <出力>の形式で示されています。対応するRUP成果物は、<作業分野> → <出力成果物> (<成果物の状態>) [<成果物セクション>]の形式で示されています。
表5: PMBOKプロセスの出力とRUP成果物のマッピング
| PMBOK Outputs |
RUP Artifacts |
| 4. 1 プロジェクト統合マネジメント → プロジェクト計画の策定 → プロジェクト計画書 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 開発企画書 |
| プロジェクト管理 → 反復計画書 |
| 要求 → 開発構想書 |
| 環境 → 開発個別定義書 |
| 4. 1 プロジェクト統合マネジメント → プロジェクト計画の策定 → 詳細バックアップ資料 |
プロジェクト管理 → リスク管理計画書 |
| プロジェクト管理 → 測定計画書 |
| プロジェクト管理 → 製品検収計画書 |
| プロジェクト管理 → 品質保証計画書 |
| プロジェクト管理 → 問題解決計画書 |
| 要求 → 要求管理計画書 |
| 構成と変更管理 → 構成管理計画書 |
| 環境 → ビジネスモデリングガイドライン |
| 環境 → ユーザインターフェースガイドライン |
| 環境 → ユースケースモデリングガイドライン |
| 環境 → 設計ガイドライン |
| 環境 → プログラミングガイドライン |
| 環境 → テストガイドライン |
| 環境 → マニュアルスタイルガイド |
| 環境 → ツールガイドライン |
| 4.2 プロジェクト統合マネジメント → プロジェクト計画の実施 → 作業結果 |
すべてのRUPの成果物 |
| 4.2 プロジェクト統合マネジメント → プロジェクト計画の実施 → 変更要求 |
構成と変更管理 → 変更依頼 |
| 4. 3 プロジェクト統合マネジメント → 統合変更管理 → プロジェクト計画書（更新） |
構成と変更管理 → 変更依頼 |
| 「4. 1 プロジェクト統合マネジメント → プロジェクト計画の策定 → プロジェクト計画書」参照 |
| 「4. 1 プロジェクト統合マネジメント → プロジェクト計画の策定 → 詳細バックアップ資料」参照 |
| 4. 3 プロジェクト統合マネジメント → 統合変更管理 → 是正処置 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 4.3 プロジェクト統合マネジメント → 統合変更管理 → 教訓 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 5. 1 プロジェクトスコープマネジメント → 立ち上げ → プロジェクト憲章 |
プロジェクト管理 → 開発企画書 |
| 要求 → 開発構想書 |
| 5. 1 プロジェクトスコープマネジメント → 立ち上げ → プロジェクトマネージャーの識別と任命 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 5. 1 プロジェクトスコープマネジメント → 立ち上げ → 制約条件 |
プロジェクト管理 → ソフトウェア開発計画書（前提条件と制約条件） |
| 5. 1 プロジェクトスコープマネジメント → 立ち上げ → 前提条件 |
プロジェクト管理 → ソフトウェア開発計画書（前提条件と制約条件） |
| 5.2 プロジェクトスコープマネジメント → スコープ計画 → スコープ記述 |
要求 → 開発構想書 |
| 要求 → ソフトウェア要求仕様書 |
| 5.2 プロジェクトスコープマネジメント → スコープ計画 → 詳細バックアップ資料 |
要求 → 用語集 |
| 5.2 プロジェクトスコープマネジメント → スコープ計画 → スコープ・マネジメント計画書 |
要求 → 要求管理計画書 |
| 構成と変更管理 → 構成管理計画書 |
| プロジェクト管理 → 問題解決計画書 |
| 5.3 プロジェクトスコープマネジメント → スコープ定義 → WBS |
プロジェクト管理 → ソフトウェア開発計画書 |
|
プロジェクト管理 → 反復計画書 |
| 5.3 プロジェクトスコープマネジメント → スコープ定義 → スコープ記述の更新 |
要求 → 開発構想書 (更新) |
| 要求 → ソフトウェア要求仕様書 (更新) |
| 5.4 プロジェクトスコープマネジメント → スコープの検証 → 公式の受け入れ |
方向付けフェーズの終わりで到達するライフサイクル目標マイルストーンとレビュー記録 |
| 5.5 プロジェクトスコープマネジメント → スコープの変更管理 → スコープ変更 |
構成と変更管理 → 変更依頼（承認済み） |
| 5.5 プロジェクトスコープマネジメント → スコープの変更管理 → 是正措置 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 5.5 プロジェクトスコープマネジメント → スコープの変更管理 → 教訓 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 5.5 プロジェクトスコープマネジメント → スコープの変更管理 → 調整されたベースライン |
プロジェクト管理 → ソフトウェア開発計画書（新ベースライン） |
| プロジェクト管理 → 反復計画書（新ベースライン） |
| 要求 → 開発構想書（新ベースライン） |
| 要求 → ソフトウェア要求仕様書（新ベースライン） |
| 6. 1 プロジェクトタイムマネジメント → 活動の定義 → 活動リスト |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6. 1 プロジェクトタイムマネジメント → 活動の定義 → 詳細バックアップ資料 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6. 1 プロジェクトタイムマネジメント → 活動の定義 → WBSの更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書（更新） |
| 6.2 プロジェクトタイムマネジメント → 活動の順序設定 → プロジェクト・ネットワーク図 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6.2 プロジェクトタイムマネジメント → 活動の順序設定 → 活動リストの更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書（更新） |
| 6. 3 プロジェクトタイムマネジメント → 活動の所要期間見積 → 活動の所要期間見積り |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6. 3 プロジェクトタイムマネジメント → 活動の所要期間見積 → 見積りの根拠 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6. 3 プロジェクトタイムマネジメント → 活動の所要期間見積 → 活動リストの更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書 (更新) |
| 6.4 プロジェクトタイムマネジメント → スケジュール作成 → プロジェクトスケジュール |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6.4 プロジェクトタイムマネジメント → スケジュール作成 → 詳細バックアップ資料 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 6.4 プロジェクトタイムマネジメント → スケジュール作成 → スケジュール・マネジメント計画書 |
プロジェクト管理 → 問題解決計画書 |
| 6.4 プロジェクトタイムマネジメント → スケジュール作成 → 資源要件の更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新j） |
| プロジェクト管理 → 反復計画書 (更新) |
| 6.5 プロジェクトタイムマネジメント → スケジュール管理 → スケジュールの更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書 (更新) |
| 6.5 プロジェクトタイムマネジメント → スケジュール管理 → 是正措置 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 6.5 プロジェクトタイムマネジメント → スケジュール管理 → 教訓 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 7. 1 プロジェクトコストマネジメント → 資源計画 → 資源要件 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 7.2 プロジェクトコストマネジメント → コスト見積 → コスト見積 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 7.2 プロジェクトコストマネジメント → コスト見積 → 詳細バックアップ資料 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 7.2 プロジェクトコストマネジメント → コスト見積 → コストマネジメント計画書 |
プロジェクト管理 → 問題解決計画書 |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → コストベースライン |
プロジェクト管理 → ソフトウェア開発計画書（ベースライン化） |
| プロジェクト管理 → 反復計画書 (ベースライン化) |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → 改訂されたコスト見積り |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書 (更新) |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → 予算の更新 |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書(更新） |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → 是正措置 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → 完成時総コスト見積り |
プロジェクト管理 → ソフトウェア開発計画書（更新） |
| プロジェクト管理 → 反復計画書 (更新) |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → プロジェクトの終結 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 7.4 プロジェクトコストマネジメント → コストの予算化 → 教訓 |
プロジェクト管理 → ソフトウェア開発計画書 |
| プロジェクト管理 → 反復計画書 |
| 8. 1 プロジェクト品質マネジメント → 品質計画 → 品質マネジメント計画書 |
プロジェクト管理 → 品質保証計画書 |
| 8. 1 プロジェクト品質マネジメント → 品質計画 → 運用基準 |
プロジェクト管理 → 測定計画書 |
| 8. 1 プロジェクト品質マネジメント → 品質計画 → チェックリスト |
RUPのチェックポイント |
| 8. 1 プロジェクト品質マネジメント → 品質計画 → 他プロセスへの入力 |
RUPとのマッピングなし |
| 8. 2 プロジェクト品質マネジメント → 品質保証 → 品質改善 |
構成と変更管理 → 変更依頼 |
| 8.3 プロジェクト品質マネジメント → 品質管理 → 品質改善 |
構成と変更管理 → 変更依頼 |
| 8.3 プロジェクト品質マネジメント → 品質管理 → 受入れの決定 |
プロジェクト管理 → レビュー記録 |
| 8.3 プロジェクト品質マネジメント → 品質管理 → 手直し |
いくつかの成果物の更新 |
| 8.3 プロジェクト品質マネジメント → 品質管理 → 完成したチェックリスト |
RUPのチェックポイント |
| 8.3 プロジェクト品質マネジメント → 品質管理 → プロセスの調整 |
構成と変更管理 → 変更依頼 |
| 環境 → 開発個別定義書 (更新) |
| 9.1 プロジェクト人的資産マネジメント → 組織計画 → 役割と責任の配分 |
プロジェクト管理 → ソフトウェア開発計画書 |
| 9.1 プロジェクト人的資産マネジメント → 組織計画 → 要員マネジメント計画書 |
プロジェクト管理 → ソフトウェア開発計画書（要員計画と調達計画） |
| 9. 1 プロジェクト人的資産マネジメント → 組織計画 → 組織図 |
プロジェクト管理 → ソフトウェア開発計画書 |
| 9. 1 プロジェクト人的資産マネジメント → 組織計画 → 詳細バックアップ資料 |
RUPの役割 |
| プロジェクト管理 → ソフトウェア開発計画書（教育計画） |
| 9.2 プロジェクト人的資産マネジメント → 要員調達→ プロジェクト要員の任命 |
プロジェクト管理 → ソフトウェア開発計画書 |
| 9.2 プロジェクト人的資産マネジメント → 要員調達→ プロジェクト・チーム名簿 |
プロジェクト管理 → ソフトウェア開発計画書 |
| 9.3 プロジェクト人的資産マネジメント → チームの育成→ パフォーマンスの改善 |
RUPとのマッピングなし |
| 9.3 プロジェクト人的資産マネジメント → チームの育成→ パフォーマンス評価への入力 |
RUPとのマッピングなし |
| 10. 1 プロジェクトコミュニケーションマネジメント → コミュニケーション計画 → コミュニケーション・マネジメント計画書 |
プロジェクト管理 → ソフトウェア開発計画書（レポート計画） |
| 10.2 プロジェクトコミュニケーションマネジメント → 情報配布 → プロジェクト記録 |
RUPとのマッピングなし |
| 10.2 プロジェクトコミュニケーションマネジメント → 情報配布 → プロジェクト報告書 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 10.2 プロジェクトコミュニケーションマネジメント → 情報配布 → プロジェクトプレゼンテーション |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 10.3 プロジェクトコミュニケーションマネジメント → 実績報告 → パフォーマンス報告書 |
プロジェクト管理 → ステータス評価書 |
| プロジェクト管理 → 反復評価書 |
| 10.3 プロジェクトコミュニケーションマネジメント → 実績報告 → 変更依頼 |
構成と変更管理 → 変更依頼 |
| 10.4 プロジェクトコミュニケーションマネジメント → 完了手続き → プロジェクトの公式記録 |
構成と変更管理 →プロジェクトリポジトリ |
| 10.4 プロジェクトコミュニケーションマネジメント → 完了手続き → プロジェクト終結 |
プロジェクト管理 → ステータス評価書 |
|
プロジェクト管理 → 反復評価書 |
| 10.4 プロジェクトコミュニケーションマネジメント → 完了手続き → 教訓 |
プロジェクト管理 → ステータス評価書 |
|
プロジェクト管理 → 反復評価書 |
| 11.1 プロジェクトリスクマネジメント → リスクマネジメント計画 → リスクマネジメント計画書 |
プロジェクト管理 → リスク管理計画書 |
| 11.2 プロジェクトリスクマネジメント → リスクの識別 → リスク |
プロジェクト管理 → リスクリスト |
| 11.2 プロジェクトリスクマネジメント → リスクの識別 → トリガー |
プロジェクト管理 → リスクリスト |
| 11.2 プロジェクトリスクマネジメント → リスクの識別 → 他プロセスへの入力 |
構成と変更管理 → 変更依頼 |
| 11.3 プロジェクトリスクマネジメント → 定性的リスク分析 → プロジェクトにおける全般的なリスク順位 |
プロジェクト管理 → リスクリスト |
| 11.3 プロジェクトリスクマネジメント → 定性的リスク分析 → List of Prioritized Risks |
プロジェクト管理 → リスクリスト |
| 11.3 プロジェクトリスクマネジメント → 定性的リスク分析 → 追加の分析と管理のためのリスクリスト |
プロジェクト管理 → リスクリスト |
| 11.3 プロジェクトリスクマネジメント → 定性的リスク分析 → 定性的分析結果における傾向 |
プロジェクト管理 → リスクリスト |
| 11.4 プロジェクトリスクマネジメント → 定量的リスク分析 → 定量化されたリスクの優先順位リスト |
プロジェクト管理 → リスクリスト |
| 11.4 プロジェクトリスクマネジメント → 定量的リスク分析 → プロジェクトの確率論的解析 |
プロジェクト管理 → リスクリスト |
| 11.4 プロジェクトリスクマネジメント → 定量的リスク分析 → コスト・時間の目標達成確率 |
プロジェクト管理 → リスクリスト |
| 11.4 プロジェクトリスクマネジメント → 定量的リスク分析 → 定量的リスク分析結果の傾向 |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → リスク対応計画書 |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → 未解決のリスク |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → 二次的リスク |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → 契約上の協定 |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → コンティンジェンシー予備必要額 |
プロジェクト管理 → リスクリスト |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → 他プロセスへの入力 |
構成と変更管理 → 変更依頼 |
| 11.5 プロジェクトリスクマネジメント → リスク対応の計画 → 改訂されたプロジェクト計画への入力 |
構成と変更管理 → 変更依頼 |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → 迂回策の計画 |
プロジェクト管理 → リスクリスト |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → 是正措置 |
プロジェクト管理 → リスクリスト |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → プロジェクトの変更依頼 |
構成と変更管理 → 変更依頼 |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → リスク対応計画の更新 |
プロジェクト管理 → リスクリスト |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → リスクデータベース |
プロジェクト管理 → リスクリスト |
| 11.6 プロジェクトリスクマネジメント → リスクの監視・コントロール → リスク識別チェックリストの更新 |
プロジェクト管理 → リスクリスト |
| 12.1 プロジェクト調達マネジメント → 調達計画 → 調達マネジメント計画書 |
RUPとのマッピングなし |
| 12.1 プロジェクト調達マネジメント → 調達計画 → 作業範囲記述 |
RUPとのマッピングなし |
| 12.2 プロジェクト調達マネジメント → 引合計画 → 調達書類 |
RUPとのマッピングなし |
| 12.2 プロジェクト調達マネジメント → 引合計画 → 評価基準 |
RUPとのマッピングなし |
| 12.2 プロジェクト調達マネジメント → 引合計画 → 作業範囲記述の更新 |
RUPとのマッピングなし |
| 12.3 プロジェクト調達マネジメント → 引合 → 提案書 |
RUPとのマッピングなし |
| 12.4 プロジェクト調達マネジメント → 発注先選定 → 契約 |
RUPとのマッピングなし |
| 12.5 プロジェクト調達マネジメント → 契約管理 → 対応 |
RUPとのマッピングなし |
| 12.5 プロジェクト調達マネジメント → 契約管理 → 契約変更 |
RUPとのマッピングなし |
| 12.5 プロジェクト調達マネジメント → 契約管理 → 支払請求 |
RUPとのマッピングなし |
| 12.6 プロジェクト調達マネジメント → 契約完了 → 契約ファイル |
RUPとのマッピングなし |
| 12.6 プロジェクト調達マネジメント → 契約完了 → 公式な受け入れと終結 |
RUPとのマッピングなし |
|
まとめ
RUPとPMBOKとの比較に基づき、2つの標準の間には基本的に相容れない点は存在しないことが分かりました。この記事にあげたように、意味的に類似または同一の概念の記述に異なる用語が使用されていますが、RUPのいずれの要素もPMBOKの原則と矛盾することはなく、PMBOKの要素もRUPの原則と矛盾するものではありません。
注
1Rational Unified Process 2003.06.01.06を参照。Kruchten, P. The Rational Unified Process: An Introduction. Reading, MA: Addison-Wesley, Inc., 2000およびRoyce, W. Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley, Inc, 1998も参照。
2 Project Management Institute (PMI), A Guide to the Project Management Body of Knowledge (PMBOK), 2000.
3図3は、A Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition, Project Management Institute, 2000刊より抜粋。PMIの許可を得て掲載しています。
4著者注: ここもあげたように、この他のRUPとPMBOKとのマッピング方法としては、Bill Cottrellの記事「Standards, Compliance, and the Rational Unified Process ? Part I: Integrating RUP and the PMBOK」(「The Rational Edge」本号に掲載)に説明があります。
著者について
Serge Charbonneauは、Xelaration Software Corporationのプリンシパル・コンサルタントで創設者でもあります。Charbonneau氏の専門分野は、ソフトウェア・エンジニアリングにおける機能改善イニシアティブの計画とイニシアティブの実現です。Charbonneau氏は、プロジェクト管理、要求管理、オブジェクト指向の分析と設計、プロセス・エンジニアリング分野でのスキルと経験を持ちます。Xelaration Software創立前は5年にわたってRational Softwareに勤務し、Rationalツール・スイートを使用した組織でのラショナル統一プロセス(RUP)実装の支援を行いました。Rational Software以前は、航空、軍事、通信および医療業界向けのシステム開発会社でさまざまな職種を経験しています。
|
