統合プロセスの 4 つのフェーズの相対的なサイズを示す一般的なプロジェクトのプロファイル。

統一ソフトウェア開発プロセス（Unified Software Development Process、またはUnified Process）は、反復的かつ増分的なソフトウェア開発プロセスフレームワークです。この統一プロセスの最もよく知られ、広く文書化された改良版は、Rational Unified Process（RUP）です。その他の例としては、OpenUPやAgile Unified Processなどがあります。

概要

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

Rational Unified ProcessではなくUnified Processという名称は、一般的に、ほとんどの改良に共通する要素を含む汎用的なプロセスを指すために使用されます。Rational Unified ProcessとRUPはIBMの商標であるため、商標権侵害の潜在的な問題を回避するためにもUnified Processという名称が使用されています。このプロセスを解説した最初の書籍は、『The Unified Software Development Process』（ISBN 978-4-8232-1111）でした。 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 がリリースされました。

統一されたプロセス特性

反復的かつ漸進的

統合プロセスは、反復的かつ漸進的な開発プロセスです。推敲段階、構築段階、移行段階は、一連のタイムボックス化された反復に分割されます。（大規模プロジェクトでは、開始段階も反復に分割される場合があります。）各反復は、前回のリリースと比較して機能の追加または改善を含むシステムのリリースである増分となります。

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

建築中心

統合プロセスでは、アーキテクチャがプロジェクトチームのシステム構築における取り組みの中心となることを重視しています。システムのあらゆる側面を網羅するには単一のモデルだけでは不十分であるため、統合プロセスでは複数のアーキテクチャモデルとビューをサポートします。

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

リスク重視

統合プロセスでは、プロジェクトチームはプロジェクトライフサイクルの早い段階で、最も重大なリスクへの対処に注力する必要があります。各イテレーション、特に詳細化フェーズにおける成果物は、最も重大なリスクが最初に対処されるように選定する必要があります。

ユースケース主導

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

プロジェクトライフサイクル（統一プロセスのフェーズ）

統一されたプロセスでは、プロジェクトを 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が開発した軽量版
Eclipse Process Framework ソフトウェア開発プロセスである Open Unified Process (OpenUP)
Rational統合プロセス（RUP）、IBM / Rationalソフトウェア開発プロセス
Oracle 統合メソッド(OUM)、Oracle の開発および実装プロセス
Rational Unified Process-System Engineering (RUP-SE) は、 Rational Softwareが System Engineering向けにカスタマイズした RUP のバージョンです。

参考文献

クロール、ペル、クルヒテン、フィリップ (2003). 『Rational Unified Process を簡単に：RUP 実践ガイド』ISBN 0-321-16609-4。
クルヒテン、フィリップ（2004年）『ラショナル・ユニファイド・プロセス入門』（第3版）ISBN 0-321-19770-4。
アンブラー、スコット（2002年）『アジャイルモデリング：エクストリームプログラミングと統合プロセスのための効果的な実践』J. Wiley. ISBN 0-471-20282-7. 2019年8月8日時点のオリジナルよりアーカイブ。2014年2月5日閲覧。
スコット、ケンドール（2002年）『統一プロセスの解説』ISBN 0-201-74204-7。
ベルグストロム、ステファン、ラバーグ、ロッタ (2004). Rational Unified Process の導入：RUP による成功. ISBN 0-321-20294-5。
アンブラー、スコット、コンスタンティン、ラリー（2002年）『統一プロセス移行と生産段階』CMPブックス、ISBN 1-57820-092-X. 2019年7月14日時点のオリジナルよりアーカイブ。2014年2月5日閲覧。
ラーマン、クレイグ（2004年）『アジャイルと反復開発：マネージャーのためのガイド』 ISBN 0-13-111155-8。