Rational Method Composer 入門

メソッド・コンテンツとプロセスのオーサリング編 2

Comments

Rational Method Composerでのプロセスの管理

前回の記事では、Rational Method Composer(以下、RMC)におけるプロセスの全般的な概要について説明しました。 このセクションでは、プロセスの作成の詳細を見ていきます。 RMCが、ケーパビリティー・パターンおよびメソッド・コンテンツとして表される再使用可能なビルディングブロックにより、プロセスの調整作業を容易にする仕組みについて説明します。また、暗黙的なメソッド・コンテンツでアジャイル型プロセスを作成する方法、および具体的なメソッド・コンテンツを参照する拡張されたプロセスを示します。特に、メソッド・コンテンツに対して定義された関係がプロセスを体系的に実行できるようにする仕組みを確認します。

RMC のプロセス表現および表示の根拠

開発プロセスは、開発プロジェクトを実行すべき方法を定義します。文献でのプロセスのさまざまな定義のうち最も一般的な特性の1つは、開発中のプロダクトのライフ・サイクルを表すフェーズとマイルストーンの順序付けです。また、プロセスは、あるマイルストーンから次のマイルストーンにどのように到達するかも定義します。このために、通常は時間や専門技術などのリソースを必要とし、また何らかの結果を生成する作業、操作、または事象の順序を定義します。

CMMIなどの開発プロセスの参照フレームワークは、プロセスのさまざまなレベルの成熟度を定義します。各レベルは、プロセス定義のさまざまな特性、およびレベルごとの組織またはプロジェクトでの制定を必要とします。例えば、CMMIは開発プラクティスの実装として認識できる、実行されたアクティビティーとして「管理対象プロセス」を定義します。そのようなプロセスには特定の特性があります。つまり、ポリシーに従って計画および実行され、制御された出力を生成するために適したリソースを備えた熟達した人材が採用され、関連する利害関係者が関与します。また、モニター、制御、およびレビューされ、プロセス記述に準拠しているかについて評価されます。それに反して、「定義対象プロセス」は、組織の調整ガイドラインに従って組織の一連の標準プロセスから調整される管理対象プロセスです。定義対象プロセスでは、プロセス記述が保守され、ワーク・プロダクト、基準、およびその他のプロセス改善の情報を組織のプロセス資産に提供します。このセクション全体を通しておわかりのように、RMCプロセスはこれらの数多くの特性をサポートします。

前のセクションで確認したように、メソッド・コンテンツは孤立したコンテンツとして定義されます。これは、タスクを特定の開発目標を達成するための一種のユースケースとして扱います。プロセスを作成するためには、開発ライフ・サイクル内にそのようなメソッドを適用し、順序付ける方法を定義する必要があります。図1は、3つの主要な要素(または次元)であるタスク、ロール、およびワーク・プロダクトによって定義されたメソッド・コンテンツを時系列(4番目の次元)にプロセスで適用する方法を概念的に表しています。

図1:プロセスでのメソッド・コンテンツの適用。この図は、タスク、ロール、およびワーク・プロダクトで定義されたメソッド・コンテンツをプロセスで順序付ける方法を示しています。
図1
図1

従来のウォーターフォール・ベースで開発されたプロセスは、実行するタスクを多かれ少なかれ直線的に定義することができるのに対して、RUP、スクラム、およびXPなどの最新の反復型開発プロセスでは、開発の追加を表すためにより複雑な構造が必要です。これらの構造では、作業は、タスクが並行して繰り返し実行される、反復可能なチャンクにパッケージされます。

これらのさまざまな開発アプローチでは、プロセスの記述に必要な形式性と詳細のレベルもさまざまです。従来の開発プロセスでは、定義済みの納入物のタイプを基にしてフェーズを定義し、これらの納入物を作成する作業の順序について厳密な記述が提供されます。アジャイル型開発プロセスでは、自己組織化チームはガイダンスと制御なしで作業を実行できるという前提であるため、開発目標が定義されると、必要なのは略式の作業の記述のみです。 また、納入物より機能を重視する(結果ベース)マイルストーンを使用した作業の反復の範囲決定に重点を置きます。さらに、最新のスケーラブルな反復プロセスでは、プロジェクトのタイプおよび組織の成熟度に応じて詳細レベルを変更および調整し、実行すべき作業の明示的な記述を提供します。RMCは、これらの3つのアプローチをすべてサポートすることを目指しています。

従来の反復型開発プロセスは、さまざまなレベルの形式性だけでなく複雑なプロセス構造をサポートするために、ネストされたワークフロー表現を使用してモデリングされます。これにより、複雑なプロセス構造をネストされた図の階層として定義できます。その場合、各図ノードをまったく新しい図によって洗練または詳細化することもできます。例えば、RUPは常に、UMLのようなアクティビティー図を使用してそのプロセスを定義します。アクティビティー図では、フォーク・ノード、マージ・ノード、および結合ノードを使用して作業の並列性を表現できます。また、制御フローを使用して順序付けを表現することもできます。

反復型と従来のウォーターフォール型の開発プロセスで次によく使用される表現は、ワーク・ブレークダウン・ストラクチャー(WBS)です。ブレークダウン・ストラクチャーは、ネストすることで作業定義を洗練させることができるという点で、ネストされたアクティビティー・グラフと似ています。 これは、制御フローに似た「先行タスクの依存関係」と呼ばれるものを使用して、作業を順序付けするための簡単な方法を提供します。先行タスクによって関連付けられていないすべての要素は、自由に並行して実行できます。ブレークダウン・ストラクチャー表現のもう1つの利点は、 Rational Portfolio ManagerやMicrosoft® Projectなどのプロジェクトの制定および管理アプリケーションで非常によく使用されているということです。RMCでブレークダウン・ストラクチャーを使用すると、プロジェクトでのプロセス定義とプロセス制定のギャップを埋めることができます。RMCは、これらの2つの一般的なプロセス表現であるアクティビティー図とブレークダウン・ストラクチャーを1つの形式に統合して、プロセスを表現するために内部で維持管理します。図2のように、RMCではこの形式を基にしてどちらも表示することができます。

図2:同じプロセス構造の2つの表示
図2:同じプロセス構造の2つの表示
図2:同じプロセス構造の2つの表示

プロセスの方向付けフェーズ反復は、一貫してブレークダウン・ストラクチャーおよびアクティビティー図ビューで保守されます。あるビューでの変更は、可能な場合はもう1つのビューに変換されます。アクティビティー図の同期バーなどの表示固有の要素は、ブレークダウン・ストラクチャーには表示されませんが、該当する先行タスクの依存関係情報は、単純なマッピング規則に従って図から得ることができます。

ここに示されている例は、Eclipse Process FrameworkのOpenUP/Basic(*1)からの方向付けフェーズ反復のプロセスを両方の表示で表しています。RMCプロセス作成者は、これらの2つのプロセス表示のいずれかで作業することができ、RMCの他のビューでの変更を自動的に反映します。これは、両方のビューが基礎となるデータ構造から提供されているためです。もちろん、両方の表示は完全に同等ではなく、図7の図にある同期バーやブレークダウン・ストラクチャーで使用できない決定ポイントなど、他の表示に含まれていない情報があります。この場合、他の表示ビューはこの情報を省略しますが、図2に示されている先行タスクの依存関係で確認できるように、その情報に関する一貫性のあるマッピングを提供します。例えば、あるアクティビティーから別のアクティビティーへの制御フロー・リンクを直接、または同期バーを使用して作図することによって、ブレークダウン・ストラクチャー表示のアクティビティー間に終了-開始の先行タスク依存関係が作成されます。図2の上部で確認できるように、先行タスクは図の制御フローに従ってリストされます。例えば、「要求管理」および「アーキテクチャー実現可能性の決定」は、アクティビティー「プロジェクトの開始」である要素(4)を先行タスクとして参照しています。

ブレークダウン・ストラクチャーでのプロセスの作成

デリバリー・プロセスやケーパビリティー・パターンなどのプロセス(この記事の第1回で説明)は、ネストされたアクティビティーの明細として RMCのプロセス・エディターで作成されます。前のセクションで説明したように、この明細のすべてのアクティビティーは、アクティビティー図を使用してそのサブアクティビティーを示すことができます。

そのため「アクティビティー」は、プロセスを定義するための主要な概念になります。プロセス・エディター内に表示される数多くの要素は、アクティビティーの概念から派生しています。すなわち、アクティビティーを特化したものです。ケーパビリティー・パターンなどのプロセス自体は、実際は、プロセスをアクティビティー内にネストできる特殊なアクティビティーにほかなりません。これは、ケーパビリティー・パターンを使用して定義したプロセス・パターンのメカニズムの実現を提供します。また、フェーズおよび反復が、RMCのプロセス・エディター内のアクティビティーとして作成されます。アクティビティーではないRMCのプロセスにおける概念は、記述子(後述)およびマイルストーンのみです。RMCでライフ・サイクル・モデルを使用してプロセスを作成することは、計画ツールでの計画の作成とよく似ています。図3は、フェーズ、反復、およびマイルストーンを定義することによって、RUPまたはOpenUP/Basicに似たプロセスの開発を開始する方法例を表しています。

図3:RMCでのブレークダウン・ストラクチャーエディターを使用したRUPのようなプロセスのライフ・サイクル・モデルの作成
図3
図3

また、この画面イメージは、「RUPベース・プロセス」という名前の最上位アクティビティーのアクティビティー図、およびブレークダウン・エディターで現在選択されているアクティビティーを文書化できるプロパティー・ウィンドウを示しています。

スクラムに似たプロセス・ライフ・サイクルを表示した図3(この記事の第1回)を見ればわかるように、RMCではほとんどすべての種類のライフ・サイクル・モデルを作成できるため、RUPに似たライフ・サイクル・モデルを使用しなければならないという制限は受けません。

図3のプロセス例は、RUPライフ・サイクル・モデルに従っているため、4つのフェーズを定義しています。この4つのフェーズは、例のなかで定義されている先行タスクの依存関係が表す順序で実行する必要があります。デリバリー・プロセスの各フェーズでは、反復にサブアクティビティー(またはサブプロセス)を使用することができます。4つのフェーズのなかでは、例えば、作業の実行やワーク・プロダクトの発展という点においてフェーズが互いに異なるのであれば、後半の推敲反復に対して前半の推敲反復プロセスをモデリングすることができます。例えばRUPでは、作業環境および初期の実行可能なアーキテクチャーの設定において、前半の推敲作業に後半の推敲作業より多くのオーバーヘッドが生じます。

先に述べたように、記述子とマイルストーンを除けば、図4に示すようにこの明細にリストされているすべての要素がアクティビティーであり、独自のアクティビティー図を持つことができるため、アクティビティーが増えればその分洗練される可能性があります。図4は、方向付け反復が、これらのタイプの反復で実行しなければならない上位作業を定義する4つのアクティビティーによって、どのように洗練されたのかを示しています。

図4:このタイプの反復の上位作業を定義するアクティビティーによって、方向付け反復アクティビティーがどのように洗練されたかを示す詳細なプロセス。
図4:このタイプの反復の上位作業を定義するアクティビティーによって、方向付け反復アクティビティーがどのように洗練されたかを示す詳細なプロセス。
図4:このタイプの反復の上位作業を定義するアクティビティーによって、方向付け反復アクティビティーがどのように洗練されたかを示す詳細なプロセス。

右側の列に示されている情報にも注意してください。先行タスク情報に加えて、これらのアクティビティーを作成したプロセス作成者は、特定のアクティビティーが進行中(このプロセスから派生した計画では、これらのアクティビティーは親アクティビティーと同じ期間を動的に使用する)、反復可能(順序どおりに数回実行される可能性がある)、または複数の出現がある(異なるチームによって並行して数回実行される可能性がある)と見なされることも指定しました。

アジャイル型自己組織化チームを扱うプロセス作成者は、図4のこのプロセスを停止して、終了したと見なすかもしれません。ここでは、フェーズ、さまざまな反復の種類、マイルストーン、および実行する上位のアクティビティーを定義することで、完全な開発プロセスが提供されます。アジャイル型プロジェクトに必要なレベルの詳細および形式性を提供することができます。ただし、次のセクションでは、メソッド・コンテンツをプロセスに適用する方法を説明します。そのようなメソッド・コンテンツでは、どのワーク・プロダクトを作成するのか、またはこれらのアクティビティーの一部としていつタスクを実行するのかを定義することができます。また、そのようなメソッド参照は、プロセスの計画および実行に使用できる別のレベルの詳細を提供します。さらに、プロジェクト計画書で計画および追跡した作業に、このレベルの詳細をマップしたくない開発チームのためのガイダンスとしての役割も果たします。

メソッド・コンテンツ記述子によるプロセスの洗練

RMCでのアクティビティーは、他のネストされたアクティビティーや記述子と呼ばれるメソッド・コンテンツへの参照、あるいはその両方の組み合わせで洗練させることができます。記述子は基本的にアクティビティー内のタスクやワーク・プロダクトなどのメソッド・コンテンツ要素の出現を表す、プロセス内の参照オブジェクトですが、他方では、メソッド・コンテンツ要素のこの特定の出現がデフォルト定義とどのように異なるかを定義する、独自の関係および文書の属性を持ちます。

例えば、図5(第1回)に示されているように、RMCでは、タスクはアクティビティーの上にドラッグするだけでプロセスに適用することができます。ただし、タスクのコピーを作成する代わりに、タスク記述子が作成されます。 この記述子は、拡張および上書き可能なプロパティーと関係をタスクから継承します。その結果、すべてのアクティビティーが、記述子の独自のローカル・セットを定義します。そのようなアクティビティー内のすべての記述子には、適用されるプロセスの特定の状況またはコンテキストに固有の関係および情報のみが含まれています。 例えば、「プロジェクト管理者」のロールは通常、多種多様なワーク・プロダクト、つまりプロジェクト計画、反復計画、リスク・リスト、作業項目リストなどを担当します。メソッド・コンテンツ要素のプロジェクト管理者のロールは、これらのすべての関係をリストして、プロジェクト管理者が担当するワーク・プロダクトの完全なリストを提供します。ただし、特定のアクティビティーのコンテキストでは、プロジェクト管理者のロール記述子はプロセスのその時点におけるその1つのアクティビティーのコンテキストで、管理者が担当するワーク・プロダクトのみをリストします。例については、図6の上部のプロセス・ビューを参照してください。ここでは、プロジェクト管理者のロールは、「プロジェクトの管理」アクティビティーおよび「プロジェクトの開始」で記述子によって表されています。最初のアクティビティーのコンテキストでは、「反復計画」および「作業項目」リストに対するプロジェクト管理者の責務のみが該当します。2番目のアクティビティーは、これらの成果物をまったく処理しないため、「プロジェクト計画書」に対する責務のみが、このロール記述子で表示されます。

記述子をプロセスに追加する場合は、図1の概念の概要に示されている3つのどの次元でも開始することができます。RMCは、ワーク・ブレークダウン中心、ワーク・プロダクト中心、またはロール中心の方法で作業できる3つのプロセス・ビューを提供します。どこで開始するかに関係なく、RMCは、他の2つの次元での情報作成をサポートします。RMCは、図1の左側で説明されている関係に基づいてメソッド・コンテンツから情報を動的に取得して、追加の記述子を作成するための候補を提案する対話式のウィザードを使用します。

例えば、図5は、プロセスの作成者が「プロジェクト管理者」の役割をアクティビティー「反復の管理」にドラッグするシナリオを示しているため、このロールがこのアクティビティーで作業を実行していることを表します。

図5:プロジェクト管理者の役割をアクティビティーに適用した後で、RMCは、このロールが通常担当するワーク・プロダクトをプロセスに追加するかどうかをユーザーに尋ねます。メソッド・コンテンツで定義された関係を検査することで、この情報を取得します。ユーザーがワーク・プロダクトを選択した後で、RMCはワーク・プロダクト記述子としてプロセスに追加して、ワーク・プロダクト間の責務関係を設定します。
図5
図5

ユーザーが知識構造を基にアクティビティーを実行できるように、メソッド・コンテンツでRMCを使用することができます。またRMCは、プロセスの作成者が、プロジェクト管理者が通常担当するワーク・プロダクトをさらにアクティビティーに追加できることを提案します。図5の場合は、プロセスの作成者は、「作業項目リスト」と「反復計画」の2つの成果物を選択しました。RMCは、これらの2つのワーク・プロダクトの記述子を同じアクティビティー「反復の管理」に追加して、プロジェクト管理者の記述子を、これらのワーク・プロダクト記述子の担当のロールにします。これらの新規ワーク・プロダクト記述子をプロセスに追加した後で、RMCは提案を続けます(図5には表示されていません)。今回は、選択したワーク・プロダクトを出力としてリストするすべてのタスクのプロンプトを出します。これは、これらのタスクがプロセスに追加するのにも適した候補であるためです。

ただし、タスク、ワーク・プロダクト、およびロール記述子が含まれた完全なプロセスを常に作成するために、RMCで記述子を追加することを選択する必要はありません。また、アクティビティーで作業するワーク・プロダクトのみを含むよりアジャイル型軽量のプロセス、および図6の例に示されているようにこれらのワーク・プロダクトを担当するロールを作成することもできます。この例では、各アクティビティー内にあるそれぞれのワーク・プロダクト記述子の開始状態と終了状態と呼ばれるものが下部のビューに示されています。

図6:タスク記述子のない軽量のプロセス
図6:タスク記述子のない軽量のプロセス
図6:タスク記述子のない軽量のプロセス

この図には、同じプロセスの2つのビューが表示されています。上部の「統合ビュー」には、このプロセスに対して定義された明細が表示されています。すべてのアクティビティーが、実行ロールおよびロールが担当するワーク・プロダクトを定義します。下部の「ワーク・プロダクトの使用状況」のビューには、プロセスのワーク・プロダクトが表示され、ワーク・プロダクト記述子ごとに、すべてのアクティビティーの開始および終了時の状態を定義します。このプロセスでは、関連付けられるロールはワーク・プロダクトの開始状態から終了状態への変換を担当します。

開始状態は、アクティビティーで作業を開始する前のワーク・プロダクトの状態を表し、終了状態は、アクティビティーが完了したと見なすことができる前のワーク・プロダクトの状態を定義します。このようなプロセスでは、ロールは、規定の正式なタスク記述に従わずに、要求されたワーク・プロダクトの状態を達成するための独自のメソッドを選択することができます。ただし、このようなプロセスには依然として、どのロールがどのワーク・プロダクトを担当していて、どのような結果が期待されているのかを定義するための十分な形式性があります。

まとめ

この事では2回に分けて、RMCと、提供されるEclipse Process Framework(EPF)ツールの概要を紹介しました。主要な概念と機能の概要を示し、詳細な概念やツール固有の記述によってこうした概念を繰り返し洗練させました。

RMCおよびEPFツールをはじめて使用する際は、ツールのオンライン・ヘルプを調べてみることをお勧めします。ヘルプには複数の対話式のチュートリアルが含まれており、この記事で説明したシナリオを実行する方法が段階的に説明されています。

この最初の資料では、RMCの追加のアプリケーションと機能は対象外としましたが、「The Rational Edge」またはIBM developerWorks/Rationalの記事として今後提供する予定です。これ以外のトピックとしては、リッチ・テキスト文書のインポートおよび作成方法、別のソース (特に、RMCの先行タスク、Rational Process Workbench) からのコンテンツの移行方法、公開済みの構成のカテゴリーおよびナビゲーション構造の作成方法、プロセスを迅速に構築して調整するために動的なパターン・バインディング機能を使用する方法、サード・パーティーのコンテンツおよびプロセスを拡張するために可変性およびプラグインのメカニズムを使用する方法、プロセスを計画テンプレートとしてRMCからRational Portfolio Managerにインポートする方法、およびRational ClearCaseまたはCVSなどのバージョン管理システムとともにRMCを使用する方法などがあります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=312435
ArticleTitle=Rational Method Composer 入門
publish-date=08302007