統一されたプロセス

統合ソフトウェア開発プロセスまたは統合プロセスは、反復的かつ増分的な ソフトウェア開発プロセスフレームワークです。統合プロセスの最もよく知られ、広く文書化された改良版は、合理的統合プロセス(RUP) です。その他の例としては、OpenUP やアジャイル統合プロセスがあります。

統合プロセスは単なるプロセスではなく、特定の組織やプロジェクトに合わせてカスタマイズできる拡張可能なフレームワークです。同様に、合理的な統合プロセスもカスタマイズ可能なフレームワークです。その結果、プロセスの改良が UP から派生したものか RUP から派生したものかを判断できないことが多く、名前は互換的に使用される傾向があります。

統一プロセスという名前は、合理統一プロセスとは対照的に、ほとんどの改良に共通する要素を含む一般的なプロセスを説明するのに一般的に使用されます。また、 Rational Unified ProcessおよびRUPはIBMの商標であるため、商標侵害の潜在的な問題を回避するためにも統一プロセスという名前が使用されます。このプロセスを説明した最初の本は、The Unified Software Development Process ( ISBN 0-201-57169-2 ) と題され、1999 年にIvar Jacobson、Grady Booch、およびJames Rumbaughによって出版されました。それ以来、Rational Softwareと提携していないさまざまな著者がUnified Processという名前を使用して本や記事を出版していますが、Rational Softwareと提携している著者はRational Unified Processという名前を好んでいます。  

2012 年に、統合プロセス、スクラム、エクストリーム プログラミング、およびその他の方法 の戦略を採用して拡張するハイブリッド フレームワークである、Disciplined Agile Delivery Framework がリリースされました。

統合プロセスは、反復的かつ増分的な開発プロセスです。詳細化、構築、移行の各フェーズは、一連のタイムボックス化された反復に分割されます。(大規模プロジェクトの場合、開始フェーズも反復に分割されることがあります。) 各反復の結果、増分が生成されます。増分は、前回のリリースと比較して追加または改善された機能を含むシステムのリリースです。

ほとんどの反復には、ほとんどのプロセス分野 (要件、設計、実装、テストなど) の作業が含まれますが、相対的な労力と重点はプロジェクトの進行中に変化します。

統合プロセスでは、アーキテクチャがプロジェクト チームのシステム構築作業の中心にあると強調されています。システムのすべての側面をカバーするには 1 つのモデルだけでは不十分であるため、統合プロセスでは複数のアーキテクチャ モデルとビューがサポートされます。

このプロセスの最も重要な成果物の 1 つは、詳細化フェーズで作成される実行可能なアーキテクチャ ベースラインです。このシステムの部分的な実装は、アーキテクチャを検証し、残りの開発の基盤として機能します。

統合プロセスでは、プロジェクト チームは、プロジェクト ライフサイクルの早い段階で、最も重要なリスクに対処することに重点を置く必要があります。各反復の成果物、特に詳細化フェーズでは、最大のリスクが最初に対処されるように選択する必要があります。

ユースケースは、システム機能を定義するための主要なモデリング ツールです。また、技術系および非技術系のチーム メンバーにとって、直接的なコミュニケーション手段としても機能します。

統一されたプロセスでは、プロジェクトを 4 つのフェーズに分割します。

• インセプション
• 詳細化（マイルストーン）
• 建設（リリース）
• 移行（最終製品リリース）

各フェーズには通常、複数の反復が含まれます (UP フェーズの図では、I1、E1、E2、C1 などと名付けられています)。各フェーズの反復の正確な数は、プロジェクトの規模と性質によって異なります。この UP フェーズの図には、4 つのフェーズで正確に 1、2、4、2 の反復が含まれていますが、これは特定のプロジェクトがどのようになるかを示した単なる例です。

開始フェーズはプロジェクトの中で最も短いフェーズであり、理想的には非常に短いものであるべきです。開始フェーズが長い場合、それは統合プロセスの精神に反する過剰な事前仕様を示している可能性があります。

システムのおおよそのビジョンを策定し、ビジネスケースを作成し、範囲を定義し、大まかなコスト見積もりとプロジェクト スケジュールを作成します。

詳細化フェーズでは、プロジェクト チームはシステム要件の大部分を把握することが期待されます。ただし、詳細化の主な目的は、既知のリスク要因に対処し、システム アーキテクチャを確立して検証することです。このフェーズで実行される一般的なプロセスには、ユース ケース図、概念図 (基本的な表記法のみのクラス図)、パッケージ図(アーキテクチャ図) の作成が含まれます。

アーキテクチャは、主に実行可能なアーキテクチャ ベースラインの実装を通じて検証されます。これは、アーキテクチャ上最も重要なコア コンポーネントを含むシステムの部分的な実装です。これは、一連の小さな時間制限付き反復で構築されます。詳細化フェーズの終了までに、システム アーキテクチャが安定し、実行可能なアーキテクチャ ベースラインによって、アーキテクチャが主要なシステム機能をサポートし、パフォーマンス、スケーラビリティ、コストの点で適切な動作を示すことが実証される必要があります。

最終的な詳細化フェーズの成果物は、建設フェーズの計画 (コストとスケジュールの見積もりを含む) です。この時点での計画は、詳細化フェーズの経験に基づいている必要があり、重要なリスク要因は詳細化フェーズ中に対処されているはずなので、正確で信頼できるものでなければなりません。

構築はプロジェクトの最大のフェーズです。このフェーズでは、推敲で築いた基盤の上にシステムの残りの部分を構築します。システム機能は、一連の短い時間制限付きの反復で実装されます。各反復により、ソフトウェアの実行可能リリースが完成します。構築フェーズではフルテキストのユースケースを記述するのが通例で、各ユースケースが新しい反復の始まりとなります。このフェーズで使用される一般的な統一モデリング言語(UML) ダイアグラムには、アクティビティ図、シーケンス図、コラボレーション図、状態遷移図、相互作用概要図などがあります。リスクが低く簡単な要素については反復実装が行われます。構築フェーズの最終的な成果物は、移行フェーズで展開できるソフトウェアです。

プロジェクトの最終段階は移行です。この段階では、システムが対象ユーザーに展開されます。最初のリリース (または複数のリリース) から受け取ったフィードバックにより、移行段階の複数の反復を通じてさらに改良が加えられる場合があります。移行段階には、システムの変換とユーザー トレーニングも含まれます。

統合プロセスの改良版は、プロジェクト分野またはワークフローを分類する方法がそれぞれ異なります。合理的な統合プロセスでは、ビジネス モデリング、要件、分析と設計、実装、テスト、展開、構成と変更管理、プロジェクト管理、環境の9 つの分野が定義されています。エンタープライズ統合プロセスでは、8 つの「エンタープライズ」分野を追加して RUP を拡張しています。OpenUP/Basic などの UP のアジャイル改良版やアジャイル統合プロセスでは、分野の数を減らすことで RUP を簡素化しています。

改良では、さまざまなプロジェクト成果物に重点を置く点も異なります。アジャイル改良では、ワークフローを簡素化し、予想される成果物の数を減らすことで、RUP を合理化します。

改良点によって、移行フェーズ後に何が起こるかの指定も異なります。合理的統合プロセスでは、移行フェーズの後には通常、新しい開始フェーズが続きます。エンタープライズ統合プロセスでは、移行フェーズの後に生産フェーズが続きます。

統合プロセスの改良とバリエーションの数は無数にあります。統合プロセスを利用する組織は、必ず独自の変更と拡張を取り入れます。以下は、よく知られている改良とバリエーションの一部です。

• アジャイル統合プロセス(AUP) は、スコット・W・アンブラーが開発した軽量版です。
• 基本統合プロセス (BUP) はIBMが開発した軽量版で、OpenUP の前身です。
• エンタープライズ統合プロセス（EUP）、合理的統合プロセスの拡張
• エッセンシャル統合プロセス(EssUP)、 Ivar Jacobsonが開発した軽量版
• オープン統合プロセス (OpenUP)、Eclipse Process Framework ソフトウェア開発プロセス
• Rational 統合プロセス(RUP)、IBM / Rational ソフトウェア開発プロセス
• Oracle 統合メソッド(OUM)、Oracle の開発および実装プロセス
• Rational Unified Process-System Engineering (RUP-SE)、 Rational Software for System Engineeringがカスタマイズした RUP のバージョン

• Kroll, Per; Kruchten, Philippe (2003)。 『Rational Unified Process Made Easy: A Practitioner 's Guide to the RUP』。ISBN 0-321-16609-4。 
• Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (第 3 版). ISBN 0-321-19770-4 . 
• アンブラー、スコット(2002)。アジャイルモデリング: エクストリームプログラミングと統合プロセスのための効果的な実践。J. Wiley。ISBN 0-471-20282-7。
• スコット、ケンドール（2002年）。『統一プロセスの説明』。ISBN 0-201-74204-7。 
• Bergstrom, Stefan; Raberg, Lotta (2004). Rational Unified Processの採用: RUP による成功ISBN 0-321-20294-5 . 
• アンブラー、スコット、コンスタンティン、ラリー（2002）。「統一されたプロセス移行と生産フェーズ」CMPブックス。ISBN 1-57820-092-X。
• ラーマン、クレイグ (2004)。アジャイルおよび反復開発:マネージャー向けガイド。ISBN 0-13-111155-8。