概念:
|
ホワイト ペーパー: |
RUP (Rational Unified Process) は、小規模から大規模までの—すべてのタイプのソフトウェア プロジェクトに幅広く使用されてきた Rational™ Software が長年にわたって洗練を重ねたプロセス フレームワークです。最近では、—XP (eXtreme Programming)、SCRUM、FDD (Feature-Driven Development)、Crystal Clear Methodology など—増加している「アジャイルな」プロセスが、小規模システムを構築するための効果的な方法として重要視されつつあります。(アジャイルな連携について詳しくは、「www.agilealliance.org」を参照してください。)
以下の各セクションは、プロジェクト チームが、これらの方法のいずれかで発見される一部の「アジャイルな」実践原則を評価して、RUP で定義されたより完全なソフトウェア開発プロセスによってそれらがどのように処理されるかを確かめるのを支援することを目的とします。
アジャイルなコミュニティは、小規模な同一の場所に配置されたプロジェクト チームに特に適用できる多数の「最善の実践原則」を総合的に扱っています。RUP はどんな規模のプロジェクト チームも対象にしていますが、小規模なプロジェクトのほうがうまく適用できます。一般に、RUP とアジャイルなコミュニティのプロセスは、高品質のソフトウェアを開発するために必要な主要な最善の実践原則の視点が類似しています。—たとえば、反復的開発を適用し、エンド ユーザーを重視することなど。
以下の各セクションでは、アジャイルなコミュニティで特定された「最善の実践原則」を、RUP に基づくプロジェクトに適用する方法を説明します。この場合、正確には焦点は XP (eXtreme Programming) 方法論によって提示されるその実践原則にあります。(XP について詳しくは、Web サイト: http://www.extremeprogramming.orgを参照してください。)
XP には 4 つの基本的な「作業」(コーディング、テスト、リスニング、設計) が含まれます。これらの作業は実際には RUP の作業分野とより緊密に連携します。これらの XP の作業は、追加の作業の性能が必要である実践原則セットを使用して実行されて、RUP の一部の他の作業分野にマッピングします。『Extreme Progamming Explained』によれば XP の実践原則は、以下のものになります。
たとえば、「計画ゲーム」の実践原則の結果として実行される作業は、主として RUP のプロジェクト管理の作業分野にマッピングします。ただし、ビジネス モデリング、リリースされたソフトウェアの導入など一部の RUP のトピックは、XP の範囲外になります。顧客が要求を定義し提供するので、要求の導出は主として XP の範囲外になります。対処するのがより簡単な開発プロジェクトのため、RUP が構成と変更管理の作業分野、環境の作業分野で詳細にカバーする問題を XP は非常に容易に処理することができます。
XP と RUP で重複する作業分野では、XP で説明した以下の実践原則が、RUP で採用されます—すでに採用されている場合もあります—。
優れたプロセスは「ミクロ」レベルで実施される必要があるという意見は、受け入れがたい場合もあり、一部の企業文化に合わないこともあります。したがって、RUP では厳格な施行を提唱してはいません。ただし、状況によっては、ペアでの作業—と XP が提唱するチームに基づく他の実践原則の一部—は、以下のような場合に、各チーム メンバーが他方を助けることができるので、明らかに好都合です。
以下の XP の実践原則は、大規模なシステムには十分に対応していません (XP でもその点については明言していません)。したがって、RUP ではこの但し書きを条件として XP の実践原則を利用します。
最終的に、一見したところでは RUP で使用できそうに思える XP の実践原則—シンプルな設計—でも、一般的に適用される場合は多少の推敲と注意が必要です。
ここに、RUP で「機能外」要求と呼ぶものを処理するうえで、局地的最適化の問題と同様の問題があります。これらの要求は、顧客にビジネス価値を提供しますが、それらはストーリーとして表現するのがより困難です。XP で制約と呼ぶものの一部が、このカテゴリに入ります。RUP では、どんな種類の理論的方法でも必要である以上の設計を支持しませんが、モデルが機能外要求を満たすために重要なものの 1 つであるという考え方からアーキテクチャ モデルを使用して設計するのを支持します。
したがって、RUP は、「シンプルな設計」にすべてのテストの実行を含める必要があるという点では XP と合致しますが、ソフトウェアが機能外要求を満たすことを実証するテストを含めるという追加条項があります。一方、これは、システム サイズと複雑さが増すにつれ、またはアーキテクチャが前例のないものであるか、機能外要求が厄介な場合に、重要な問題として浮上するだけです。たとえば、(異種分散環境で操作するために) データを整列させる必要性は、コードを過度に複雑にするように思われますが、それはまだプログラム全体にわたって必要です。
小規模プロジェクトのために RUP をカスタマイズし、それに応じて成果物要求を減らす場合、XP プロジェクトの成果物に相当するものとの対比はどのようになるでしょうか。RUP の「小規模プロジェクトの開発個別定義書の例」を見ると、サンプルの RUP 構成が (表 1 に示されているように) より少ない成果物を生成するように構成されていることがわかります。
XP の成果物
|
RUP の成果物
(「 ![]() |
---|---|
ストーリー 会話からの追加の文書 |
開発構想 用語集 ユース ケース モデル |
制約 | 補足仕様書 |
受け入れテストと単体テスト テスト データとテスト結果 |
|
ソフトウェア (コード) | 実装モデル |
リリース | ![]() ![]() |
メタファ | ソフトウェア アーキテクチャ説明書 |
設計 (CRC、UML スケッチ) 技術的タスクとそのほかのタスク 最後に生成される設計文書 サポート文書 |
設計モデル |
コーディング標準 | ![]() |
ワークスペース テストのフレームワークとツール |
![]() ![]() |
リリース計画書 反復計画書 ストーリー見積もりとタスク見積もり |
ソフトウェア開発計画書 反復計画書 |
全体的な計画と予算 | 開発企画書 リスク リスト |
進捗に関するレポート タスク作業に関する時間記録 メトリクス データ (リソース、範囲、品質、時間を含む) 結果の追跡 会合に関するレポートと注記 |
ステータス評価 反復評価 レビュー記録 |
障害 (と関連データ) | 変更依頼 |
コード管理ツール | プロジェクト リポジトリ ![]() |
スパイク (ソリューション) | |
XP 自体 (推奨かつガイダンス) | |
[XP には含まれていない] |
表 1: 小規模プロジェクトの成果物の XP から RUP へのマッピング
成果物の粒度は両サイドで異なりますが、一般に小規模プロジェクトの RUP の成果物 (XP が十分に対応できるタイプ) は、XP プロジェクトの成果物に問題なくマッピングします。
小規模プロジェクトの開発個別定義書の例には、XP でカバーされていないが、多数のプロジェクトで必要である成果物も含まれていることに注意してください。その中には、データ モデルと、
エンドユーザー サポート文書などの導入に関連する成果物も含まれます。
RUP では役割によって実行される作業として作業を定義します—入力成果物を使用し変換するにせよ、新規 / 変更した出力成果物を生成するにせよ。次にこれらの作業を列挙し、それらを RUP の作業分野に応じて分類します。それらの作業分野には、(特に) ビジネス モデリング、要求、分析と設計、導入、プロジェクト管理などがあります。
作業は、それらが生成し、消費する成果物を通じて時間に関連しています。成果物は論理的に、その入力が利用可能で (かつ適切な成熟状態に) あるときに始めることができます。つまり、成果物状態が許可するなら、生産者-消費者の作業ペアが時を違えず重複することができます。それらは厳格に順序付けられる必要はありません。作業は、成果物の生成方法についての強力なガイダンスを提供するよう意図されており、プロジェクト管理者の計画を支援するために使用されることもあります。
ライフサイクル、成果物、作業の観点から説明されているように RUP を通じて組み入れられるのが「最善の実践原則」です。つまり、予測できるスケジュールと予算に合わせて構築される高品質のソフトウェアを生み出すことが立証されたソフトウェア エンジニアリング原則。RUP はその作業 (と関連している成果物) を通じて、これらの最善の実践原則をサポートし実現します-それらは RUP を貫くテーマです。XP では「実践原則」の概念も使用しますが、RUP の最善の実践原則の概念と正確に一致しているわけではないことに注意してください。
XP では、4 つの基本的な作業—コーディング、テスト、リスニング、設計—を行うときにソフトウェア開発の魅力的なシンプルなビューを提供します。(「第 9 章 Extreme Programming Explained」で説明されているように) 一部のサポートしている実践原則に従って 4 つの作業を有効にし、構成することができます。実際には、前に示したように、XP の作業は RUP の作業よりも RUP の作業分野の範囲に密接しており、(4 つの基本的な作業のほかに) XP プロジェクトで発生するものの多くは、その実践原則の推敲と適用によってもたらされるものです。
したがって、XP には RUP の作業と同等のものがありますが、XP の「作業」はそういうものとして正式に特定または説明されません。たとえば、『Extreme Programming Installed』の「第 4 章 User Storie」を見ると、「Define requirements with stories, written on cards」という見出しがあり、第 4 章全体にわたって、ユーザー ストーリーが何であり、どのように (誰が) それらを生成するかについてのガイダンスとプロセスの記述があります。そのほかにも、(成果物と作業関連のものが混在する見出しの下の) XP booksのさまざまなセクションに、「生成されるもの」と「行うこと」の両方が、さまざまな度合いの規範と詳細にわたって説明されています。
RUP の明らかに高度な規範は、作業とその入力 / 出力の処理における完成度と格式度の高さに起因します。XP は規範が欠如してはいませんが、軽量のまま残そうとする試みでは、格式度と詳細が単に省略される可能性があります。特異性の欠如は利点でも弱点でもありませんが、XP における詳細情報の欠如を簡素さと混同しないようにしてください。詳細がないことは、経験を積んだ開発者にとって良い場合もありますが、多くの場合、詳細が多いことは、新しいチーム メンバーと、チームのソフトウェア開発のアプローチに追いつこうとしているチーム メンバーにとって非常に役に立ちます。
成果物と同様に作業に関しても、達成しようとしていることに焦点をあわせ続けることは重要です。やみくもに作業を実行することは、良いやり方ではありません。作業と関連ガイドラインは、目的を達成するためにそれらが必要な場合に見るように存在しますが、何を達成しようとしているのかをはっきりさせる必要がないことの口実として使用すべきではありません。この精神は XP で十分に明確に示されており、RUP のすべてのユーザーがそれを適用する必要があると確信しています。
RUP では、作業は役割 (またはもっと正確には役割を果たす個人かグループ) によって実行されると言われています。役割には、特定の成果物に対する責務があります。責任ある役割が、通常、成果物を作成し、(多少なりと認められている場合) 他の役割によって行われた変更が成果物を破壊しないようにします。一個人またはグループが、1 つだけの役割を実行することも、複数の役割を実行することもできます。役割を、組織内の 1 つだけの役職または「地位」にマッピングする必要はありません。
『Extreme Programming Explained』では、XP に適用できる役割—プログラマ、顧客、テスト担当者、トラッカ、コーチ、コンサルタント、ビッグ ボス—を特定し、それらを実行する人に必須の責務と能力について説明しています。そのほかの一部のXP booksでも、これらの役割について言及しています。XP と RUP の役割の数の違いは、以下のように簡単に説明できます。
RUP の役割を小規模プロジェクトにマッピングするとき、それらが相当する XP のような役割の数は、役職または肩書きの数が 5 というように、かなり減少されます。(RUP をもとに作成された) 表 3 に、このマッピングと、対応する XP の役割を示します。
XP の役割 | RUP の小規模プロジェクトのチーム メンバーの例 | RUP の役割 |
コーチ コンサルタント ビッグ ボス |
サリー スラローム、上級管理者 | プロジェクト管理者![]() 技術的レビュー担当者 構成管理者 変更管理責任者 |
顧客 | 利害関係者 (開発構想に文書化されているとおり) |
管理レビュー担当者 技術的レビュー担当者 (要求) |
顧客 ビッグ ボス トラッカ |
トム テレマーク、上級ソフトウェア エンジニア | システム分析者 ユース ケース定義者 ユーザー インターフェイス設計者 ソフトウェア アーキテクト 技術的レビュー担当者 テスト管理者 ![]() ほかにも開発者の役割があります。 |
プログラマ テスト担当者 |
スーザン スノー、ソフトウェア エンジニア ヘンリー ハーフパイプ、初級ソフトウェア エンジニア |
設計者 実装担当者 技術的レビュー担当者 統合担当者 ![]() ![]() ![]() |
トラッカ | パトリック パウダー、管理アシスタント | プロジェクト Web サイトの保守、作業の計画とスケジュールの作成におけるプロジェクト管理者の補助、成果物の変更管理における変更管理責任者の補助を担当します。必要に応じて、そのほかの役割の補助も行うことがあります。 |
表 3: 小規模プロジェクトにおける XP 役割の RUP 役割へのマッピング
RUP は、特定のプロセスを構成してインスタンス化することができるプロセス フレームワークです。RUP を構成する必要があります—これは RUP 自体で定義される必須手順です。厳密に言うと、そのとき、XP と RUP のカスタマイズされたバージョンを比較する必要があります—つまり、XP が明示的に構築するプロジェクトの特性 (と推論できるもの) に合わせて RUP はカスタマイズされます。そのようなカスタマイズされた RUP プロセスは、多数の XP の実践原則 (ペア プログラミング、テスト先行設計、リファクタリングなど) に適応することができましたが、アーキテクチャ、抽象化 (モデリングでの)、リスク、時間 (フェーズと反復) で異なる構造などの重要性に RUP は重きを置いているので、まだ XP と同一ではありません。
XP は意図的に、小規模プロジェクトの軽量プロセスを実装することに方向づけられます。そうする際に、完全に詳細化されてはいない (少なくとも本の) 説明も含まれます。XP の実装では、進行中に発見、考案、または定義する必要があるものが常にあります。RUP は、規模と種類の点で XP の範囲内と範囲外の双方のプロジェクトに適応します。このロードマップが示すように、RUP は実際には XP の反復で記述されるほとんどの実践原則と互換性があります。
XP の本質は、組織、人、カルチャーを重視していることに留意してください。このことはすべてのプロジェクトで重要であり、RUP を使用しているプロジェクトにも当てはまります。小規模プロジェクトは、これらの実践原則を一緒に使用することで大きな利益を得ることができます。
Rational Unified Process
|