合理的な統一プロセス

Rational Unified Process ( RUP ) は、 2003 年にIBMの一部門であるRational Software Corporationによって作成された反復的な ソフトウェア開発プロセスフレームワークです。 ^[1] RUP は単一の具体的な規定プロセスではなく、開発組織やソフトウェア プロジェクト チームがニーズに適したプロセス要素を選択してカスタマイズすることを目的とした、適応性の高いプロセスフレームワークです。RUP はUnified Processの特定の実装です。

Rational Software は、もともとソフトウェア プロセス製品として Rational Unified Process を開発しました。この製品には、サンプル成果物とさまざまな種類のアクティビティの詳細な説明を含むハイパーリンクされた知識ベースが含まれています。RUP は、プロセスのカスタマイズを可能にする IBM Rational Method Composer (RMC) 製品に含まれています。

経験豊富な Rational の技術担当者であるPhilippe Kruchtenが、最初の RUP チームを率いる任務を負いました。

これらの初期バージョンでは、Rational Software 組織のオブジェクト指向システム構築に関する広範な現場経験 (Rational の現場スタッフは Rational Approach と呼んでいます) と、ユースケースなどの実践に関する Objectory のガイダンスが組み合わされ、Jim Rumbaugh のObject Modeling Technology (OMT) モデリング手法、Grady Booch のBooch メソッド、および新しくリリースされたUML 0.8 からの広範なコンテンツが組み込まれました。^{[2] [3]}

この増大する知識ベースをよりアクセスしやすくするために、Philippe Kruchten は、最新のソフトウェア エンジニアリング用の明示的なプロセス フレームワークの組み立てを担当しました。この作業では、 Objectory によって開発されたHTMLベースのプロセス配信メカニズムが採用されました。その結果生まれた「Rational Unified Process」(RUP) により、Rational の戦略的な三脚が完成しました。

• 開発を導くカスタマイズ可能なプロセス
• そのプロセスの適用を自動化するツール
• プロセスとツールの両方の導入を加速するサービス。

このガイダンスは、Rational が買収した企業の経験に基づく知識によって、その後のバージョンで強化されました。

1997 年には、要件とテストの規律がこのアプローチに追加されました。追加資料の多くは、Requisite, Inc. の Dean Leffingwell らが開発した Requirements College メソッドと、SQA Inc. で開発された SQA Process メソッドから取得されました。両社とも Rational Software に買収されました。

1998 年に Rational Software は次の 2 つの新しい分野を追加しました。

1. ビジネスモデリングでは、この内容の多くはすでにオブジェクトプロセスに含まれていました
2. Pure Atria Corporation の買収を通じて獲得した構成および変更管理分野。

これらの追加により、Rational によって定義され、RUP 内で現代のソフトウェア エンジニアリングの 6 つのベスト プラクティスとして明確に示された包括的な一連の原則が生まれました。

1. リスクを主な反復の原動力として反復的に開発する^[4]
2. 要件を管理する
3. コンポーネントベースのアーキテクチャを採用する
4. ソフトウェアを視覚的にモデル化する
5. 品質を継続的に検証する
6. コントロールの変更

これらのベスト プラクティスは Rational の製品ラインと密接に連携しており、Rational 製品の継続的な開発を推進するとともに、Rational の現場チームによって使用され、顧客のソフトウェア開発作業の品質と予測可能性の向上に役立っています。

パフォーマンス テスト、UI デザイン、データ エンジニアリングなどの追加テクニックが組み込まれ、UML 1.1 の変更を反映する更新も行われました。

1999 年には、プロジェクト管理の規律が導入され、リアルタイム ソフトウェア開発をサポートする手法や UML 1.3 を反映する更新も導入されました。さらに、このプロセスを説明した最初の書籍であるIvar Jacobson、Grady Booch、James Rumbaughによる『The Unified Software Development Process 』 ( ISBN  0-201-57169-2 ) が同じ年に出版されました。

2000 年から 2003 年にかけて、RUP インスタンスの有効化と RUP フレームワークのカスタマイズのためのツール サポートに加えて、反復開発に関する Rational の現場経験からのガイダンスが導入され、いくつかの変更が行われました。これらの変更には次のものが含まれます。

1. エクストリーム プログラミング (XP) などのアプローチの概念とテクニックの導入。これらは後にアジャイル メソッドとして総称されるようになりました。これには、ペア プログラミング、テスト ファースト設計などのテクニックや、RUP によって XP を大規模プロジェクトで使用できるように拡張する方法を説明した論文などが含まれます。
2. さまざまな反復開発コンテキストでテスト作業がどのように実施されたかをより適切に反映するために、テスト規律を全面的に見直しました。
3. さまざまなツールで RUP プラクティスを実施するためのサポート ガイダンス (「ツール メンター」と呼ばれる) の導入。これらは基本的に、Rational ツールのユーザーにステップ バイ ステップの方法サポートを提供します。
4. RUP のカスタマイズを自動化することで、顧客が RUP プロセス フレームワークからパーツを選択し、その選択内容を独自の追加機能でカスタマイズし、さらに Rational の後続リリースでの改善点を組み込むことができるようになります。

IBM は 2003 年 2 月に Rational Software を買収しました。

2006年にIBMはアジャイルプロジェクトの配信に合わせてRUPのサブセットを作成し、 Eclipseウェブサイトを通じてOpenUPと呼ばれるオープンソースの方法としてリリースしました。^[5]

RUP は、作成する内容、必要なスキル、および特定の開発目標の達成方法を段階的に説明する一連のビルディング ブロックとコンテンツ要素に基づいています。主なビルディング ブロック、つまりコンテンツ要素は次のとおりです。

• 役割 (誰) - 役割は、関連するスキル、能力、責任のセットを定義します。
• 作業成果物 (何) - 作業成果物は、プロセスの実行中に作成されたすべてのドキュメントとモデルを含む、タスクの結果として生じたものを表します。
• タスク (方法) - タスクは、意味のある結果をもたらすロールに割り当てられた作業単位を表します。

各反復内で、タスクは次の 9 つの分野に分類されます。

• 6つの「工学分野」
  • ビジネスモデリング
  • 要件
  • 分析と設計
  • 実装
  • テスト
  • 展開
• 3つの支援分野
  • 構成と変更管理
  • プロジェクト管理
  • 環境

RUP は、4 つのフェーズから成るプロジェクト ライフ サイクルを定めています。これらのフェーズにより、ウォーターフォール スタイルのプロジェクトと同様に、プロセスを高レベルで提示できますが、本質的には、プロセスの鍵はすべてのフェーズに含まれる開発の反復にあります。また、各フェーズには 1 つの主要な目標があり、最後には、目標が達成されたことを示すマイルストーンがあります。RUP フェーズと分野を時間経過とともに視覚化したもの、これを RUPハンプチャートと呼びます。

主な目的は、初期コストと予算を検証するための基礎として、システムを適切に範囲指定することです。このフェーズでは、ビジネス コンテキスト、成功要因 (予想収益、市場認知度など)、財務予測を含むビジネス ケースが作成されます。ビジネス ケースを補完するために、基本的なユース ケース モデル、プロジェクト計画、初期リスク評価、プロジェクトの説明 (コア プロジェクト要件、制約、主要機能) が生成されます。これらが完了したら、プロジェクトは次の基準に照らしてチェックされます。

• 範囲の定義とコスト/スケジュールの見積もりに関する利害関係者の合意。
• 主要なユースケースの忠実度によって証明される要件の理解。
• コスト/スケジュールの見積り、優先順位、リスク、開発プロセスの信頼性。
• 開発されたあらゆる建築プロトタイプの深さと幅。
• 実際の支出と計画された支出を比較するためのベースラインを確立します。

プロジェクトがライフサイクル目標マイルストーンと呼ばれるこのマイルストーンを通過しない場合は、キャンセルするか、基準をより適切に満たすように再設計した後に繰り返すことができます。

主な目的は、このフェーズの終わりまでに分析によって特定された主要なリスク項目を軽減することです。詳細化フェーズでは、プロジェクトが具体化され始めます。このフェーズでは、問題領域の分析が行われ、プロジェクトのアーキテクチャが基本的な形になります。

詳細化フェーズの結果は次のとおりです。

• ユースケースとアクターが特定され、ユースケースの説明の大部分が開発されているユースケース モデル。ユースケース モデルは 80% 完了している必要があります。
• ソフトウェア システム開発プロセスにおけるソフトウェア アーキテクチャの説明。
• アーキテクチャ的に重要なユースケースを実現する実行可能なアーキテクチャ。
• 改訂されたビジネスケースとリスクリスト。
• プロジェクト全体の開発計画。
• 特定された各技術的リスクを明らかに軽減するプロトタイプ。
• 予備ユーザーマニュアル（オプション）

このフェーズでは、次の質問に答えてライフサイクル アーキテクチャ マイルストーンの基準に合格する必要があります。

• 製品のビジョンは安定していますか?
• アーキテクチャは安定していますか?
• 実行可能なデモンストレーションは、主要なリスク要素が対処され、解決されていることを示していますか?
• 建設段階の計画は十分に詳細かつ正確ですか?
• すべての関係者は、現在のアーキテクチャのコンテキストで現在の計画を使用して現在のビジョンを達成できることに同意していますか?
• 実際のリソース支出と計画されたリソース支出は許容範囲内ですか?

プロジェクトがこのマイルストーンを通過できない場合、キャンセルまたは再設計する時間はまだあります。ただし、このフェーズを過ぎると、プロジェクトは変更がはるかに困難で、変更を加えると損害が発生する高リスクの運用に移行します。

詳細化のための重要なドメイン分析は、システム アーキテクチャです。

主な目的は、ソフトウェア システムを構築することです。このフェーズでは、システムのコンポーネントやその他の機能の開発に重点が置かれます。コーディングの大部分は、このフェーズで行われます。大規模なプロジェクトでは、ユース ケースを管理可能なセグメントに分割して実証可能なプロトタイプを作成するために、構築の反復を複数回行う場合があります。

主な目的は、システムを開発から本番環境に「移行」し、エンド ユーザーが利用して理解できるようにすることです。このフェーズのアクティビティには、エンド ユーザーと保守担当者のトレーニング、およびエンド ユーザーの期待に照らしてシステムを検証するためのベータ テストが含まれます。システムは評価フェーズも通過し、必要な作業を行っていない開発者は交代または削除されます。製品は、開始フェーズで設定された品質レベルに対してもチェックされます。

すべての目標が達成されると、製品リリースのマイルストーンが達成され、開発サイクルは終了します。

IBM Rational Method Composer 製品は、プロセスを作成、構成、表示、公開するためのツールです。詳細については、 IBM Rational Method Composer およびオープン ソース バージョンのEclipse プロセス フレームワーク(EPF) プロジェクトを参照してください。

2007年1月に、 IBM Certified Solution Designer - Rational Unified Process 7.0の新しい RUP 認定試験がリリースされました。これは、 IBM Rational Certified Specialist - Rational Unified Processというコースの以前のバージョンに代わるものです。^[6]新しい試験では、RUP コンテンツに関する知識だけでなく、プロセス構造要素に関する知識もテストされます。^[7]

新しいRUP認定試験に合格するには、IBMのテスト839: Rational Unified Process v7.0を受験する必要があります。52問の試験に75分かかります。合格点は62%です。^[8]

ソフトウェアプロジェクトでは、障害を最小限に抑え、生産性を向上させるために、 6つのベストソフトウェアエンジニアリングプラクティスが定義されています。これらは次のとおりです。^{[9] [10]}

反復的に開発する

すべての要件を事前に把握しておくことが最善ですが、多くの場合、そうではありません。開発フェーズの観点からコストを最小限に抑えるソリューションを提供することを目的としたソフトウェア開発プロセスはいくつか存在します。

要件を管理する

ユーザーが設定した要件を常に念頭に置いてください。

コンポーネントを使用する

高度なプロジェクトを細分化することは、推奨されるだけでなく、実際には避けられません。これにより、個々のコンポーネントを大規模なシステムに統合する前にテストできるようになります。また、コードの再利用は大きな利点であり、オブジェクト指向プログラミングを使用することでより簡単に実現できます。

視覚的にモデル化する

図を使用して、すべての主要なコンポーネント、ユーザー、およびそれらの相互作用を表します。「UML」は、Unified Modeling Languageの略で、このタスクをより実行可能にするために使用できるツールの 1 つです。

品質を確認する

いつでもテストをプロジェクトの主要な部分にしてください。テストはプロジェクトが進むにつれて重要になりますが、ソフトウェア製品の作成において常に重要な要素である必要があります。

コントロールの変更

多くのプロジェクトは多くのチームによって作成され、時にはさまざまな場所で作成され、異なるプラットフォームが使用されることもあります。そのため、システムに加えられた変更が常に同期され、検証されていることを確認することが不可欠です。(継続的インテグレーションを参照)。

• マクロスコープ（方法論スイート）
• アジャイルモデリング(AM)
• アジャイル統合プロセス(AUP)
• 規律あるアジャイルデリバリー(DAD)
• 動的システム開発手法(DSDM)
• コンピュータプログラミング
• 機能駆動開発(FDD)
• プロジェクトのライフサイクル
• 品質管理と品質保証
• スケールド アジャイル フレームワーク—エクストリーム プログラミング(XP)などのアジャイル ソフトウェア開発手法を取り入れた RUP の後継フレームワーク
• ソフトウェアアーキテクチャ
• ソフトウェアコンポーネント
• ソフトウェア開発プロセス
• ソフトウェアエンジニアリング
• ソフトウェアテスト
• テスト駆動開発(TDD)
• 教育のための統一プロセス(UPEDU)

• Ivar Jacobson、Grady Booch、James Rumbaugh (1999)。統合ソフトウェア開発プロセス
• Gary Pollice、Liz Augustine、Chris Lowe、Jas Madhur (2003)。小規模チーム向けのソフトウェア開発: RUP 中心のアプローチ
• Per Kroll、Philippe Kruchten (2003)。Rational Unified Process Made Easy: RUP 実践ガイド
• ペル・クロール、ブルース・マック・アイザック (2006)。アジリティと規律を簡単に: OpenUP と RUP の実践
• フィリップ・クルヒテン（1998）「合理的統一プロセス：序論」
• Ahmad Shuja、Jochen Krebs (2007)。RUPリファレンスおよび認証ガイド
• ウォーカー・ロイス、ソフトウェアプロジェクト管理、統一フレームワーク
• ポール・シムコヴィアク、フィリップ・クルクテン（2003）。テスト: RUP の哲学 ^[1]

• IBM Rational Unified Process Web サイト