Rational Method Composer 入門

Key Concept編 2

Comments

主な用語と概念について(後編)

メソッド・コンテンツ

開発メソッドを習得するには、資料を調べたり、トレーニングを受けたりします。書籍、記事、トレーニング教材、標準と規制など、さまざまな形式の文書で多くの開発メソッドが説明されています。 通常、これらの情報源がメソッドを文書化する方法は異なっていますが、そのほとんどに、一般的な環境下で特定の開発目標を達成するための特定の方法がステップごとに説明されています。 例えば、「要求文書を分析モデルに変換する」、「機能要求および非機能要求に基づいてアーキテクチャーのメカニズムを定義する」、「開発の反復用にプロジェクト計画を作成する」、「機能要求に対する品質保証計画を定義する」、「新しい戦略方針に沿ってビジネス組織を再設計する」などがあります。

Rational Method Composer(以下、RMC)は、このようなコンテンツを、事前に定義したスキーマを使用してある特定の方法で構造化します。このスキーマは、Unified Method Architecture(以下、UMA)(注記1) で定義されます。これはSPEM 1.1 OMG標準(注記2)をベースにしたRational Unified Process(以下、RUP)2003 スキーマを発展させたものです (メタモデルとも呼ばれます)。UMAは、IBM Global Service Method、またはRational Summit Ascendantなどの他のIBMメソッド・スキーマとも統合されています。 このスキーマは、大規模な編成の開発メソッドおよびプロセスの記述をサポートします。 このようなメソッド・コンテンツとプロセスは、ソフトウェア・エンジニアリングだけでなく、メカニカル・エンジニアリング、ビジネス・トランスフォーメーション、セールス・サイクルなどの、他の設計やエンジニアリングの作業分野にも対応できます。

RMCでは、このUMAスキーマに従い、メソッド・コンテンツは、開発スキルとワーク・プロダクトの責任者を定義するロールの構成体として表現されます。このワーク・プロダクトは、ロールがワーク・プロダクトを入出力とするタスクを実行すると作成されます。図1は、メソッド・コンテンツの典型的なソースと、メソッド・コンテンツがRMCでどのように表示されるかを示しています。図1のRMCの画面イメージでは、メソッド・コンテンツ要素の編成方法が左側のツリー・ブラウザーで表示されています。ライブラリーと同様、このツリー・ブラウザーには選択可能な要素に迅速にアクセスできるようにさまざまなインデックスが用意されています。画面イメージの右側には、タスク表示の例が示されています。このタスク表示では、タスクの目的を達成するためにどのステップを実行しなければならないかという観点でタスクが定義されています。タスクにはさまざまな関連があることもわかります。例えば、タスクの実行者となるロールへの関連や、タスクへの入出力となるワーク・プロダクトへの関連などがあります。RMCでは、これらの関連を、各要素を互いに結ぶハイパーリンクとして維持および表示します(タスク、ロール、およびワーク・プロダクトについては、ヘルプ内の関連トピックも参照下さい。今後、連載予定の、後編の記事でも取り扱う予定です。)。 ロール、タスク、ワーク・プロダクトに加えて、RMCは追加のガイダンス要素もサポートします。ガイダンスとは、ホワイト・ペーパー、概念の説明、ガイドライン、テンプレート、サンプルなど、フリー・フォームの補足文書です。

図1:RMCで表示されるタスク
図1
図1

メソッド・コンテンツは、ソフトウェア・エンジニアリング・メソッドに関する書籍や出版物に含まれています。 Rational Method Composerは、タスク、ロール、ワーク・プロダクト、およびガイダンスなどの概念を使用してメソッド・コンテンツを表します。この図は、タスクがRMCでどのように表示されるかを示しています。

プロセス

開発プロセスは、ロールによって作業が実行される順序、ワーク・プロダクトが作成される順序、およびワーク・プロダクトが時間の経過と共に発展していく順序を定義します。図2は、プロセスが通常ワークフローまたはブレークダウン・ストラクチャーとして表されることを示しています。

図2:RMCで表示されるプロセス
図2
図2

RMCでは、プロセスはワークフローまたはブレークダウン・ストラクチャーとして表されます。 プロセスはメソッド・コンテンツを使用し、プロセスが記述するプロジェクトのライフ・サイクルを通してメソッドがどのように適用されるかを定義します。

ウォーターフォール・モデルのように順序を厳密に定義することは、並行処理でセミオーダーの反復順序を定義する場合とまったく同じプロセスです。 異なるのは表している開発アプローチだけです (注記3)。プロセスの定義では、作業をどのように編成するかを時系列に指定する構造にメソッド・コンテンツを組み込むことができます。これによって、オンライン・システム用ソフトウェアや組み込みシステム用のソフトウェアとハードウェアなど、特定のタイプの開発プロジェクトによるニーズを満たすことができるのです。

RMCは、さまざまな開発アプローチに基づいてプロセスをサポートし、ウォーターフォール、インクリメンタル、または反復ライフ・サイクルなどのさまざまなライフ・サイクル・モデルを定義するために使用できます。RMCは、ワーク・ブレークダウン・ストラクチャー(WBS)やワークフロー表示など、プロセス用のさまざまな表示もサポートします。アジャイルな自己組織化チームのために、メソッド・コンテンツを最小限しか、またはまったく使用しないプロセスをRMCで定義することもできます(これに関しては、今後、連載予定の、後編の記事で詳しく取り扱う予定です)。

図2のRMCの画面イメージの右側は、ネストされたアクティビティーのブレークダウン・ストラクチャーとして表示されたプロセスの例です。また、このブレークダウン・ストラクチャーと同期して、方向付けフェーズにおけるアクティビティーのワークフローであるアクティビティー図も表示されています。図2には、図1からの「ユースケースの詳細の作成」という特定のタスクがプロセスで2回適用されていることが2つの青い矢印で示されています。1つは方向付けフェーズの「システムの定義」アクティビティーの下に、もう1つは推敲フェーズの「システム定義の洗練」アクティビティーの下に示されています。RMCではこれらのタスクはタスク記述子として表示され、その下にそれぞれ実行ロールと入出力ワーク・プロダクトがリスト表示されます。詳細に見ると、この2つのタスク記述子リストには違いがあることがわかります。ライフ・サイクルを通して行われるユースケースの詳細作成に相違点があります。さまざまなロールが関与し、入力のリストにおける変更を考慮し、出力を作成または更新しなければならないことがわかります。この例では、変更はこのプロセスを作成した作成者によって定義され、ライフ・サイクルのこの特定のポイントに生じたそれぞれの事象に対するタスク・パフォーマンスが確実に着目されるよう表示されています。タスク記述子に対するロールと入出力ワーク・プロダクトの更新に加えて、追加のテキスト記述を提供し、タスクの中から、このタスクで特定の事象が発生したときに実行すべきステップ、または実行してはいけないステップを選択することができます。

まとめ

図3は、RMCの主要な概念がメソッド・コンテンツとプロセスの分離にどのように関連するかを示しています。この図のように、メソッド・コンテンツは、基本的にワーク・プロダクト、ロール、タスク、およびガイダンスを使用して表されます。

図3:RMCの概念に使用される用語の概要
図3
図3

チェックリスト、サンプル、ロードマップなどのガイダンスを定義して、プロセスのバックグラウンドや模範的なウォークスルーを提供することもできます。図3の右側には、RMCでのプロセスを示すために使用される概念が表示されています。主となる概念はアクティビティーで、ネストしてブレークダウン・ストラクチャーを定義することができます。アクティビティーは互いに関連付けられ、作業の流れを定義します。アクティビティーにはメソッド・コンテンツを参照する記述子が含まれ、RMCがサポートする2つの主なタイプのプロセス(デリバリー・プロセスとケーパビリティー・パターン)を定義するために使用されます。デリバリー・プロセスは、特定のタイプのプロジェクトを実行するための完全で統合されたプロセス・テンプレートを表します。このプロセスは、完全にエンドツーエンドのプロジェクト・ライフ・サイクルを表し、同様の特徴を持つ実行中のプロジェクトから参照されます。ケーパビリティー・パターンは作業分野やベスト・プラクティスのような関心の高い分野に対するプロセスに関する知識を表すプロセスです。このパターンは、作業の指針としてプロセス担当者によって直接使用されます。また、デリバリー・プロセスまたはより大規模なケーパビリティー・パターンを構築するためのビルディング・ブロックとして使用されます。これにより作成した主なプラクティスの最適な再利用および適用を確実に行うことができます。

RMCを使用した典型的な使用シナリオ

RMCまたはEclipse Process Framework(以下、EPF)の最も典型的な使用シナリオを見てみましょう。RMCは強力なプロセス・オーサリング環境ですが、RMCの機能を使用するオーサリングや方法のレベルはさまざまです。RMCには、すぐに使用可能なメソッドやプロセス・コンテンツが多数含まれています。このため、多くの場合、実際にはオーサリングはそれ程必要ではありません。ユーザーのニーズに合わせて既存のコンテンツを選択、構成、および調整するだけで十分です。

RMCの最も簡単な使用シナリオは、出荷された状態、つまりすぐに使用可能なプロセスを単に使用することです。RMCの製品バージョンには、RUPフレームワーク(RUP v7.0)の完全なソースが含まれています。このフレームワークは、多種多様な開発環境に対応した数千ものメソッドやプロセス要素で構成されています。また、Java Enterprise Edition(以下、JEE)のような特定のテクノロジーに対応した開発や、COTS(市販の既成ソフトウェア)を採用したさまざまな開発環境に対応した開発など、特定の分野に特化した追加を行ってRUPを拡張する、さまざまなメソッド・プラグインも含まれます。EPFのライブラリーは、プロジェクトへの参加者によって提供されるコンテンツによって急速に拡大しています。

しかし、組織やプロジェクトでこの資料が一度にすべて必要となるわけではありません。すべてではなく、メソッド構成と呼ばれる特定のサブセットを使用し、特定のニーズに合わせてプロセスを調整する必要があるのです。アクティビティーを選択し調整する間も、独自のコンテンツやリンクを既存の使用可能な資料へ組み込みたい場合もあるでしょう。このような場合、RMCのオーサリング機能が提供する使いやすい強力なエディターを使用して、シームレスに実行することができます。

提供される明示的なメソッド定義を使用せずに、RMCで最初から作成することもできます。この場合、実行するすべてのプロセス・オーサリングで、リリース、フェーズ、反復、スプリント、またはその他のライフ・サイクル構成要素を使用してライフ・サイクル構造を定義し、そのライフ・サイクル構造に、ハイ・レベル・アクティビティー、マイルストーン、そしておそらくは主要な納入物の定義も取り込むことになります。

次に、RMCに関する典型的な使用シナリオの概要を説明します(注記4)。

既存のメソッド・コンテンツおよびプロセスの選択と構成

ここでは、RMC使用シナリオの中で最も簡単なものを1つ説明します。RUP 2003のユーザーは、「RUP ビルダー」シナリオとしてご存じでしょう。RMCメソッド・ライブラリーを表示して、ニーズに合ったプロセスとその基礎となるメソッド・コンテンツを選択します。RMCメソッド・ライブラリーには、購入したすべてのコンテンツと共に、RMCリソース・センター(注記5)またはEPFコミュニティーからダウンロードしたコンテンツが含まれます。ニーズを十分に満たすものが見つかったら、このプロセス(図4で説明)の構成を開始します。まず、「メソッド・パッケージ」を選択または選択解除します。メソッド・パッケージを削除すると、そのパッケージのコンテンツへのすべての参照が、プロセスのあらゆる場所から削除されます。例えば、実行しない作業の要素を含むパッケージを削除することによって、プロセスがそのコンテンツの最小サブセットしか含まないようにスリム化することができます。または、プロセスがオプションとしてサポートする特定の分野に特化されたコンテンツを持つメソッド・パッケージを追加することもできます(例えば、「一般的な」J2EEに対するSOA固有のコンテンツ向けJ2EEなど)。

図4:メソッド構成の切り替え
図4
図4

プロセスが参照する(参照しない)メソッド・パッケージを選択(選択解除)することによって、プロセスとメソッド・コンテンツを構成します。RMCのメソッド・ライブラリー全体に対するフィルターを定義したメソッド構成を複数作成することができます。ツールバーのコンボ・ボックスを使用して、さまざまなメソッド構成を素早く切り替えることができます。左下の「構成」ビューには、メソッド構成の結果であるコンテンツが常に表示されます。

RMCでは、メソッド・コンテンツやプロセスは、構成をわかりやすくするために、論理単位が作成される方法に従って編成されます。例えば、要求または変更管理などの1つの特定の作業分野に属するすべてのコンテンツが、1つのメソッド・パッケージに存在する場合があります。各パッケージは、こうした作業分野の特定のプラクティスに対応したサブパッケージにさらに分割される場合もあります。例えば、RUPの要求作業分野では、ユースケース関連の全コンテンツは別個のパッケージに分割されます。このように、ユースケース・メソッド・パッケージまたは要求パッケージを選択または選択解除して、マウスを1回クリックするだけで、プロセスからユースケース・プラクティスのみ、または要求管理の作業分野全体を簡単に追加したり削除したりすることができます。

構成したプロセスは、HTMLでチームに公開およびデプロイしたり(図2参照)、プロジェクト管理ツールにエクスポートしたりできるようになります。プロセスのメソッド構成は、このように開発ライフ・サイクル全体にまたがるプロセスに対して作成することもできますが、1つまたは複数のフェーズ、反復、アクティビティーなどに対して行うこともできます。したがって、ライフ・サイクル全体を事前に定義しておく必要はありません。その代わりに、プロセスの構成は必要に応じて繰り返し行うことができます。

既存プロセスの調整

プロセスは、単に構成するだけではなく、RMCのさまざまなエディターを使用し、特定のニーズにより合ったものにするために積極的に修正することができます。既存のプロセスについて「プロセス・コントリビューション」と呼ばれるものを作成し、そのプロセスへの変更による差異を定義することができます。プロセス内の要素は、直接追加、削除、または置換することができます。つまり、構成を変更するのに対し(プロセス全体が変更される)、変更が必要な部分にのみ個別に変更を定義することができます。RMCには高度な動的リンク機能が備わっており、元のプロセス定義と分離して変更を行うことができるため、基礎となるプロセスを変更する場合も、既に行った変更を失うことなく簡単にアップグレードできます(今後、連載予定の後編の記事では、プロセスの調整の例について説明します)。

新規プロセスの作成

既存のプロセスを調整する代わりに、まったく新しいプロセスを最初から作成したり、1つ以上の既存のプロセスから構成要素を再利用して新しいプロセスを作成したりすることができます。再利用できる構成要素が1つもない場合は、まったく新しいプロセスを最初から作成することができます。しかしほとんどの場合、メソッド・コンテンツやケーパビリティー・パターンと呼ばれる定義済みプロセスのパターンからビルディング・ブロックを再利用して構築し、独自のプロセスを作成します。ケーパビリティー・パターンは、再利用可能なアクティビティーのクラスターを定義する小さいプロセスです。このクラスターは、通常、一般的な分野のプロセスで繰り返し実行されるものです。ケーパビリティー・パターンには、「ユースケース・ベースの要求管理」、「コンポーネント開発」、「ビルドの検証」、「継続的な管理およびサポート」などがあります。RMCでは、パターンによって記述された作業を実行するたびにそのパターンが複製されるだけではなく、これらのパターンをプロセスに動的にリンクすることができます。そのパターンが変更されると、適用されたパターンもすべて自動的に更新されます。

『主な用語と概念の概要』で説明したように、RMCのプロセス・オーサリング機能では、メソッド・コンテンツとプロセスを完全に分離して利用することができます。プロセスを作成する際、まず独自のライフ・サイクル・モデルを定義し、次に、独自に定義したか、メソッド・ライブラリーから再利用したメソッド・コンテンツやケーパビリティー・パターンを体系立てて取り込みます。 図5は、EPFの一例で、異なるライフ・サイクル・モデルを持つ2つのプロセスの中でメソッド・コンテンツとケーパビリティー・パターンがどのように再利用されているかを示しています。

図5: メソッド構成の切り替え 2つの異なるプロセスを持つ2つのプロセスに同じケーパビリティー・パターンとメソッド・コンテンツを適用した例
図5
図5

図5の右側に、2つのブレークダウン・ストラクチャー・プロセス・エディターが表示されています。上側は、アジャイル用にRUPを軽量化したOpenUP/Basicが定義されています(注記6)。下側は、Scrumに似たプロセスが定義されています。それぞれのプロセスが異なるライフ・サイクル・モデルを持っています。OpenUP/Basicは4つのRUPフェーズ(方向付け、推敲、作成、移行)を使用し、各フェーズの反復を定義します。Scrum・プロセスは、スプリントとも呼ばれる反復で編成されています。図5の2つのプロセスをよく見てみると、プロセス独自の相違点だけでなく、共通点もあることが分かります。「反復の管理」や「スプリントの管理」などのアクティビティーでは、それぞれのプロセスが別の管理方法を採っているため、リストに表示されるタスクが異なります。これらのタスクは、そのプロセスのためだけに作成されたものです。

一方、「開発ソリューション」や「ビルドの検証」など一部のアクティビティーは、両方のプロセスで共通しています。

これらのアクティビティーは、OpenUP/Basicの基本ビルディング・ブロックとして定義されたケーパビリティー・パターンを表しています。これらは、図5の左側のツリー・ブラウザーにリストされています。Scrum・プロセスの作成者は、こちらのパターンをドラッグ・アンド・ドロップするだけでプロセスに適用して再利用することができます。熱心なScrum信奉者は、自己組織化チームを前提としないで、このように明示的な作業タスクを追加するのであれば、そのプロセスはScrumの原則に反すると言うかもしれません。しかし、このサンプルの目的は、RMCのプロセス・オーサリング機能を使用すれば、ガイダンスとなるパターンやタスクを再利用するだけで、経験の浅いチームに厳密な作業指示をしなくてもScrumのようなプロセスが簡単に拡張できることを示すことです。

メソッド・コンテンツの開発とプロセスの作成または拡張

最後のシナリオでは、RMCやサード・パーティーのメソッド・コンテンツを再利用してプロセスを作成または調整する機能に加え、ユーザー独自のメソッド・コンテンツを開発し、それを使用して既存プロセスの調整や新規プロセスの作成を行う機能について説明します。

メソッド・コンテンツを作成する際にも、まったく新しいコンテンツを定義するか、既存のメソッド・コンテンツを拡張することができます。独自のロールを定義する必要がある場合、ワーク・プロダクトの種類を追加する場合、ユーザー独自の開発メソッドを追加する場合、または単に別のガイダンス(例えばホワイト・ペーパー、組織独自の規則やガイドライン、独自のワーク・プロダクト・テンプレートまたはチェックリストなど)を提供する場合は、新しいメソッド・コンテンツを開発します。メソッド・ライブラリー内にある既存のメソッド・コンテンツを単に修正したい場合(ワーク・プロダクト責任者をロールに追加、タスクへのステップ追加、既存のチェックリストへのチェックポイント追加など)、RMC固有のメソッド・プラグインや柔軟な変更機能を使用して行うことができます。この柔軟性により、元のコンテンツを直接修正しないで、既存のコンテンツを変更することができます。例えば、RUPへのメソッド・プラグインを作成し、その中でタスク・コントリビューションとして既存のタスクに複数の新規ステップを追加することができます。また、プラグインに定義したワーク・プロダクトでRUPのワーク・プロダクトを置き換え、独自のバリアントを定義することもできます。例えば、置き換わった後のワーク・プロダクトが、カスタマイズされた記述やガイダンスの他に、異なる名前、構造、およびテンプレートを持っているかもしれません。他のRUP要素から元のワーク・プロダクトへの参照は、すべて自動的に独自の要素への参照に置き換えられます。これにより、メソッド構成を使用して独自の拡張機能のオン/オフを任意に切り替えたり、元の要素の最新バージョンへ簡単にアップグレードしてから変更を再適用したりすることができます。

RMCでは、フォーム・ベースの直感的なエディターを使用してメソッド・コンテンツの定義と文書化を行います。このエディターは簡単に習得できますが、適切にフォーマットされたリッチ・テキスト文書を作成できる強力な機能を備えています。

図6は、ワーク・プロダクトの定義に使用するエディターを示します。新規ワーク・プロダクトのタイプは、その要素をメソッド・パッケージ内に作成するだけで定義できます。タイプの文書化は、エディターを使用してフォーム・フィールドに入力し、選択ダイアログとコンボ・ボックスを使用して関連を作成するだけです。RMCは、バックグラウンドでHTMLを作成、管理し、図5(タスク文書化ページのプレビュー)のように、適切にフォーマットしてハイパーリンクを付けた文書を提供します。

図6:ワーク・プロダクトのためのフォーム・ベースのエディター
図6
図6

ワーク・プロダクトのためのフォーム・ベースのエディター。すべてのフォーム・フィールドはフルサイズのリッチ・テキスト・エディターに拡張することができ、テキストのフォーマットや、テーブルの処理、画像の挿入などを行うことができます。

メソッド・コンテンツの要素を一度作成すれば、前述の『既存プロセスの調整』または『新規プロセスの作成』シナリオを使用して、その要素をメソッド構成に組み込み、独自のプロセスや再利用したプロセスに追加することができます。 以上で、最も一般的なRMCの使用シナリオの概要説明を終わります。

連載におつきあいくださり、どうもありがとうございます。


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


関連トピック


コメント

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

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