目次


Rational Method Composer 入門

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

Comments

はじめに

この記事は、IBM Rational Method Composer(以下、RMC)について2回に分けて紹介する連載企画の第2回目の記事です。第1回では、「Rational Method Composer 入門〜Key Concept編〜」としてRMCの主要な概念と典型的な使用シナリオについて説明しました。今回は、第2回として、RMCでメソッド・コンテンツとプロセスを定義する概念についてより詳しく説明します。 まず、メソッド・コンテンツを作成するための主要な3つの要素、ロール、タスク、ワーク・プロダクトとその関係を確認します。次に、RMCでサポートされるさまざまな種類のガイダンスについて説明します。 また、標準カテゴリーおよびカスタム・カテゴリーを使用して、メソッド・コンテンツのカタログを編成する方法を示します。その後、RMCでのプロセス定義に移ります。ここでは、RMCのプロセス表現の根拠について説明し、RMCで使用および作成できるさまざまなプロセスの例を1つずつ見ていきます。

知的資本と資産をメソッド・コンテンツおよびガイダンスとして管理する

メソッド・コンテンツを作成するための主要な3つの要素、ロール、タスク、およびワーク・プロダクトとその関係について考えてみましょう。

ロール、タスク、ワーク・プロダクト

ソフトウェア・エンジニアリングの文献で最も一般的に引用されるフレーズの1つに、「ソフトウェア開発はチームスポーツである」(*1) というものがあります。これは、ソフトウェアを (いまだに) 作成するのは人間の開発者であり、彼らは開発タスクを行ううえで緊密に協調し互いの作業結果を交換するということを表しています。 その意味で RMC は、開発メソッドを定義するためのきわめて一般的な、標準とさえ言える方法 (*2) を適用しています。これは、図1に示されているような、開発チームの関連スキル、コンピテンシー、および責務の組み合わせを表す開発の各ロールを識別することによって行われます。これらのロールは、特定のタイプのワーク・プロダクトを担当します。例えば、開発者はソース・コードを担当し、システム分析者はユースケース仕様書を担当します。ワーク・プロダクトの作成や変更を行うには、特定のタイプのワーク・プロダクトを入出力として持つタスクを実行するロールを割り当てます。

図1:ロール、タスク、およびワーク・プロダクトの主要なメソッド・コンテンツの概念を簡略化した概念・モデル
図1

Rational Unified Process® (以下、RUP®)の経験があるユーザーなら、前のバージョンのRUPでは「タスク」ではなく「アクティビティー」という用語が使用されていたことに気が付くでしょう。これらの用語は、第1回の『メソッド・コンテンツ』で説明したUnified Method Architecture(以下、UMA)およびSPEM 2.0の作業の一部として、業界での使用状況を反映し、プロセス制定とプロジェクト管理の方法をより緊密に結び付けるために変更されました。

RMCの新機能では、前のバージョンのRUPとは対照的に、タスクに複数のロールを割り当てることができます。多くのタスクでは、異なるスキル、経歴、および利害を持つ人が一緒に作業する必要があるため、ソフトウェア・エンジニアリングが本来持っているコラボレーションの性質が重視されます。 例えば、「要求の優先順位付け」というタスクでは、さまざまなロールからスキルと専門技術・知識を組み合わせる必要があります。エンド・ユーザーのニーズと優先順位を表すには、システム・アナリストのスキルが必要です。プロジェクト管理者が費用対効果比率を定義できるようにするために、機能の実現可能性と費用を評価するには、アーキテクトのスキルが必要です。また、要求の実現をさまざまな反復に割り振って優先順位を付けし、使用可能な開発リソースとスキルのレベルを評価するには、プロジェクト管理者のスキルが必要です。そのため、要求の優先順位付けでは、これらの異なるスキルを持ち、それぞれのロールを担う個人同士のコラボレーションが必要になります。過去のバージョンのRUPを使用したモデリング・メソッドでは、そのようなタスクをこれらの3つのロールの1つのみに割り当てるか、これらのスキルを組み合わせた新しいロールを作成しなければならなかったため、数多くのきわめて専門的なロールが作成されました。RMCでは、必要なすべてのロールをタスクに割り当てて、作業を行うために必要なスキルを明確に定義します。 プロジェクトで実際にこの作業を実行するときは、プロジェクト管理者は、ロールにつき1人を割り当てるか、1人が複数のロールを同時に実行するかを決定することができます。

また、RUPユーザーは、図1に示されているように、成果物ではなくワーク・プロダクトの概念が使用されていることに気が付くでしょう。RUPでも引き続き成果物を定義しますが、汎化としてワーク・プロダクトの概念が導入され、納入物と結果という2つのタイプのワーク・プロダクトが加えられ、サポートされます。納入物は、他のワーク・プロダクトを内部または外部の関係者へのデリバリー用にパッケージ化するために使用されます。納入物は、デリバリー用に選択された一連のワーク・プロダクトと納入物ごとに固有の資料という形式を持つ、標準的または推奨されるコンテンツとして定義されます。結果とは、インストールされたサーバーや最適化されたネットワークなど、結果または状態という無形のワーク・プロダクトです。 結果と成果物の主な相違点は、結果は、再利用可能な資産として扱うことができない点です。

メソッド・コンテンツへのメソッド記述のマッピング

この記事の第1回では、メソッド・コンテンツのことを、ソフトウェア・エンジニアリングの文献から取り入れた基本的な開発メソッドと技法をロール、タスク、およびワーク・プロダクトの概念を使用してRMC内で表現するための方法として説明しました。RUPには、例えば、ほとんどの重要な開発作業分野について、あらゆる開発メソッドが含まれています。以下に、例を示します。

ユースケース分析

このテーマに関する数多くの書籍(*3)に、設計者がユースケース仕様書からオブジェクト指向の分析モデルを体系的に作成する方法が説明されています。

開発構想の策定とスコープ設定

他の著者(*4)は、プロジェクトのスコープ設定に使用される、利害関係者の問題をビジネス・ニーズ、さらにそれに対応するシステム機能(要求)にマップし伝えるメソッドを定義してします。

テスト

Cem Kaner他の著書では、テストの体系的な計画、テスト構想の明確化と設計、および体系的なレグレッション・テストの実施のためのさまざまなメソッドを定義しています(*5)。 このようなメソッドは、RUPコンテンツ・チームによってソースから1つ以上のタスクにマップされます。図2に示すように、すべてのタスクは、実行ロールと入出力ワーク・プロダクト、および追加の背景情報と詳細を提供するガイダンスに関連付けられた一連のステップに編成されます。

図2:RMCでタスクとして表されるユースケース分析の実行方法
図2
図2

この例では、タスクをHTMLにして、RMCユーザーに対して表示する方法を示しています。 詳細なステップの記述は、縮小表示可能なセクションにあります。 この図の青色のテキストはすべて、関連するメソッド・コンテンツ要素のページへのハイパーリンクを表します。

例えば、図2は、ユースケース分析メソッドが、ロール設計者によって実行されるタスクとしてRUPでどのように表示されるかを示しています。タスクには、必須入力のワーク・プロダクトのユースケースがあります。ユースケースの実現、分析クラス、用語集など、その他の任意入力のワーク・プロダクトもあります。 出力ワーク・プロダクトとしてのタスクは、ユースケースの実現、および分析クラスで構成される分析モデルを定義します。タスクは、チェックリストなどのさまざまなガイダンス要素にリンクされています。例えば、ユースケース分析検討会議の実施など特定の技法に関するガイドライン、ユースケースの実現や分析クラスなどのワーク・プロダクトの詳細を説明するガイドラインなどです。 最後に、IBM Rational Rose、XDE、またはSoftware Architectなどのツールを使用してユースケース分析を実行する方法を説明するツール・メンターがあります。

タスク自体は、複数のステップに構造化されています。ただし、これらのステップを正確な順序で実行する必要はありません。実際には、ステップによっては特殊な状況でのみ実行されるものもあり、すべてのユースケースを対象としていないことがあります。例えば、「分析ユースケースの実現の調整」のステップでは、このタスクを既に複数回実行していて、調整対象のユースケースの実現がいくつか存在している必要があります。そのため、ステップは、タスク実行者が作業の実行時に選択できるタスク内の作業単位を示します。『Rational Method Composerでのプロセスの管理』セクションで説明するように、これは、どのステップをどの時点で実行すべきかを実際に定義するプロセスです。タスクとそのステップは、ユースケース分析のメソッドを実行するためのすべてのバリエーションを使用してメソッドを定義し、タスクの目的を達成するために、開発ライフ・サイクルを通して実行されるすべての作業を記述します。これは、メソッド要素をプロセスに適用するものであり、プロセスに実際にメソッドのどの部分をライフ・サイクル内のどの時点で実行しているのかを判断できるようにするコンテキストを提供します。

RMCで意図的にタスクを定義して使用することは、ソフトウェア・エンジニアリングでユースケースを定義して使用する方法と多くの共通点が数多くあります。 ユースケースとして、タスクは明快な目的を提供し、それを実行するロールが利害関係者に価値をもたらすという明確な目標を達成する必要があります。上の例の「分析ユースケースの実現の作成」など、タスクの個々のステップは、単独では価値を提供しません。ユースケース実現の概念は、分析によって識別される分析要素のコンテナーを表すものでしかありません。 つまり、これは、図2の上部にリストされている分析タスクの目的を達成するための手段なのです。

ユースケースの場合と同様、タスクも、明確な目的または目標を持ってタスクを定義すると、識別して管理しやすくなります。 プロセスの実装担当者や開発者などの利害関係者は、各作業を実行する理由など、目的のより広範なコンテキストを確認できるため、タスクに関わりやすくなります。詳細な作業単位をあまりに多く定義して人々に割り当てると、管理とコミュニケーションが困難になります。また、タスクのコミュニケーションと教育が、明確な開発目標に合った粒度を満たしていれば非常にやりやすくなります。その結果、タスクの実行に必要な時間は数時間から数日まで幅広い範囲に及ぶ場合があります。したがって、タスクの数だけではプロセスを見積もることはできません。すべてのタスクの見積もりを個別に検討して行う必要があります。(ただし、プロセス内でのタスクの出現数を考慮して見積もりを定義することをお勧めします。これについては、上述のとおり、より具体的なコンテキストが既に提供されています。)

タスクの粒度に関するもう1つの規則は、通常、影響を受けるワーク・プロダクトは1つまたはごく少数でなければならないという点です。すなわち、タスクに、多くの異なるタイプの出力ワーク・プロダクトがあってはならないということです。そのような場合は、本来は結合すべきワーク・プロダクトを、特定の目的に対処するためにあまりにも細かく定義してしまった可能性があります。また、複数の開発メソッドを含む作業がタスクで実行されている可能性もあります。このような作業は、タスクの再利用性を向上させて特定の目標に集中するために、別個の作業にリファクタリングする必要があります。

ユースケースと同じく、タスクの狙いは目標達成のために実行しなければならないすべての作業手順について完全な定義を提供することです。これには、代替およびオプションのステップが含まれます。この意味で、タスクのステップはユースケース・フローに対応し、さまざまな「シナリオ」(この場合は開発シナリオ)を導き出すために、プロセス内にある多くの異なる組み合わせに加えることができます。入出力ワーク・プロダクト関係のタスクへの割り当ては、図3に示されています。最後に、ユースケースに当てはめて考える場合、タスクの実行ロールはユースケースのアクターには対応しないことに注意してください。これは、アクターが外部ユーザーであるためです。ロールは、実際の作業を実行する開発者を表します。そのため、ロールは、分析ユースケースの実現におけるコントロール・オブジェクト、またはビジネス・ユースケースの実現におけるビジネス・ワーカーと似ています。

図3:「追加」ボタンと「除去」ボタン、およびダイアログのみを使用した、RMCタスク・エディターでの入出力ワーク・プロダクトの関係のタスクへの割り当て
図3
図3

ガイダンスとカテゴリー

ガイダンスの要素を使用すると、メソッド・コンテンツに情報を追加してより完全なものにし、図4のように別個の記述に分解できます。RMCでサポートされる具体的なガイダンスの種類には、ホワイト・ペーパー、チェックリスト、テンプレート、または用語定義の追加が含まれます。サポートされるガイダンスの種類の全リストについては、以下の表1を参照してください。

図4:ガイダンスは、特定のフォーム・ベースのエディターを使用してRMCで作成されます。この図には、ガイドライン類のためエディターが表示されています。これは、基本的には、ホワイト・ペーパーのような資料を編集可能なフリー・フォームのテキスト・フィールドで構成されます。その他の種類のガイドラインには、より特化したエディターが提供されます。例えば、チェックリスト類は、チェック項目エディターで編集されます。

図4:ガイダンス
図4
図4

RMCでは、図4に示されているように、フォーム・ベースのエディターを使用したこうしたガイダンス要素のオーサリングがサポートされています。シンプルなダイアログを使用して、ロール、タスク、またはワーク・プロダクトにガイダンスを関連付け、(例えば、ステップ記述、ワーク・プロダクト定義、またはその他のガイダンス要素のテキスト内にある)資料へのインライン・リンクを作成するか、または図2の例に表示されている「詳細情報」セクションなどの別個の参照セクション内にリンクを作成することができます。

表1:RMCでサポートされるさまざまなガイダンスの種類のリスト

さまざまなガイダンスの種類を異なる要素に関連付けることができます。例えば、テンプレートは通常ワーク・プロダクトのみに関連付けられ、タスクまたはロールには関連付けられません。RUPは、許可される関係の詳細な概要を提供します。

RMCでサポートされるさまざまなガイダンスの種類のリスト
チェックリスト作成または検証する必要がある一連の項目を示します。 チェックリストは、多くの場合、ウォークスルーや検査などのレビューで使用されます。
概念関連項目の基礎をなす基本的原則に関する、主となる考え方の概要を説明します。概念は通常、ガイドラインより一般的なトピックを扱い、複数のワーク・プロダクト、タスク、またはアクティビティー、あるいはそのすべてに及びます。
完了したワーク・プロダクトまたは実行されたタスクとアクティビティーの例を提供します。
ガイドライン特定のタスクの実行またはタスクのグループ化方法に関する詳細の追加を提供するか、ワーク・プロダクトおよびそのプロパティーに関する詳細、規則、および推奨事項の追加を提供します。
実践原則ワーク・プロダクトまたはプロセスの品質にプラスの影響を与える目標を達成するために、作業を実行する場合の実証された方法または方針を示します。実践原則は、メソッドおよびプロセスと直交するように定義されます。メソッドのさまざまな部分または特定のプロセスに影響する局面を要約することもあります。
レポート1つ以上のワーク・プロダクトから抽出された内容を使用して自動的に生成される説明のテンプレート。
再利用可能な資産プリパッケージされたソリューションを与えられたコンテキストでの問題にリンクさせます。資産の例には、設計パターンまたは設計メカニズム、ソリューション・フレームワークなどがあります。資産のパッケージおよび消費は、IBM Rationalの設計ツールおよび作成ツールによって直接サポートされます。
ロードマップ複雑なプロセスまたはアクティビティーの線形のウォークスルー。(これは、プロセス固有のガイダンスです。)
サポート資料他で特に定義されていないその他のタイプのガイダンスをすべて含む。すべての種類のコンテンツ要素に関連していることがあります。
テンプレートワーク・プロダクトに対して、定義済みの目次、セクション、パッケージ、見出しと、標準化されたフォーマット、さらにセクションとパッケージをどのように使用して作成すべきかに関する説明が提供されます。
用語定義用語を定義して、用語集を作成するために使用されます。
ツール・メンタータスクまたはアクティビティーのコンテキストで、またはタスクまたはアクティビティーから独立して作業の一部を完了させるために、特定のツールを使用する方法を示します。
ホワイト・ペーパー概念と似ていますが、外部でレビューまたは発行されます。他の内容要素およびガイダンスとは別に読まれ、理解されることがあります。

ガイダンスで補足として略式のコンテンツを提供するだけでなく、カテゴリーを使用して、図5に示されているように、コンテンツ表示を編成して索引を付けることができます。RMCは、タスクをカテゴリー化する作業分野、ワーク・プロダクトをカテゴリー化するドメイン、関連するロールをグループ化するロール・セットなどのメソッド・コンテンツ要素のための一連の定義済みの標準カテゴリーを提供します。またRMCでは、独自のカスタム・カテゴリーを定義し、それを使用してロール、タスク、ワーク・プロダクト、およびガイダンスの独自の論理的な組織および表示構成を定義することもできます。公開されたRMCコンテンツに表示されるツリー・ブラウザー・ビューはすべて、これらのカテゴリーを基にして生成されます。カテゴリー自体は、カテゴリーを定義および要約するリッチ・テキストの詳細な説明を含むことができるため、コンテンツ要素(カテゴリー自体もカテゴリー化できます)と考えられます。さらに、カスタム・カテゴリーを使用して、使用するコンテンツの独自の索引およびカタログを作成することもできます。例えば、CMMI(*6)レベルまたはプラクティスのカテゴリーを定義して、これらのレベルを基にタスクなどの内容をカテゴリー化することができます。

図5:RUPに対して定義された標準カテゴリーとカスタム・カテゴリーの例。作業分野およびロール・セットは、標準カテゴリーの例です。カスタム・カテゴリーは、コンテンツを分類して、公開済みWebサイトのナビゲーション構造を定義するために使用することができます。

図5:RUPに対して定義された標準カテゴリーとカスタム・カテゴリーの例
図5

注記

  1. 例えば、Walker Royce「Software Project Management: A Unified Framework Addison-Wesley Professional」(1998)を参照。
  2. OMG「Software Process Engineering Metamodel」(バージョン1.1、formal/2005-01-06、2005年)(US)
  3. I.Jacobson他「Object-Oriented Software Engineering:A Use Case Driven Approach」(Addison-Wesley、1992年)、Peter Eeles、Kelli Houston、Wojtek Kozaczynski「Building J2EE Applications with the Rational Unified Process」(Addison-Wesley 2002年)、およびIan Alexander、Neil Maiden Wiley共編「Scenarios, Stories, Use Case」の『Use Case-Based Software Development』の章(拙著、2004年)。
  4. Dean Leffingwell、Don Widrig「Managing Software Requirements:A Use Case Approach, Second Edition」(Addison-Wesley、2003年)、Kurt Bittner、Ian Spence「Use Case Modeling」(Addison-Wesley、2003年)
  5. Cem Kaner、Jack Falk、Hung Quoc Nguyen「Testing Computer Software Second Edition」(Wiley、1999年)
  6. apability Maturity Model Integration。詳しくは、Software Engineering InstituteのWebサイトを参照。
    Software Engineering Institute(US)

後編 「プロセスの管理」


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


関連トピック


コメント

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

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