統一されたプロセス

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

統合ソフトウェア開発プロセスまたは統合プロセスは、反復型の増分 ソフトウェア開発プロセスフレームワークです。統一プロセスの最もよく知られており、広く文書化されている改良点は、Rational Unified Process(RUP)です。他の例は、OpenUPアジャイル統一プロセスです。

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

概要

統合プロセスは単なるプロセスではなく、特定の組織やプロジェクトに合わせてカスタマイズする必要のある拡張可能なフレームワークです。同様に、Rational UnifiedProcessはカスタマイズ可能なフレームワークです。その結果、プロセスの改良がUPに由来するのか、RUPに由来するのかを判断できないことが多く、名前は同じ意味で使用される傾向があります。

Rational UnifiedProcessではなくUnifiedProcessという名前は、一般的に、ほとんどの改良に共通する要素を含む一般的なプロセスを説明するために使用されます。Rational Unified ProcessRUPIBMの商標であるため、UnifiedProcessの名前は商標侵害の潜在的な問題を回避するためにも使用されます。このプロセスを説明した最初の本は、The Unified Software Development ProcessISBN 0-201-57169-2)というタイトルで、1999年にIvar JacobsonGrady BoochJamesRumbaughによって発行されました。 それ以来、 Rational Softwareとは関係のないさまざまな著者が、 Unified Processという名前を使用して本や記事を公開していますが、 Rational Softwareと関係のある著者は、Rational UnifiedProcessという名前を支持しています。

2012年に、Disciplined Agile Deliveryフレームワークがリリースされました。これは、Unified Process、Scrum、XP、およびその他の方法の戦略を採用および拡張するハイブリッドフレームワークです。

統合プロセスの特性

反復型および増分型

プロジェクトの過程でさまざまな分野の相対的な強調がどのように変化するかを示す図
プロジェクトの過程でさまざまな分野の相対的な強調がどのように変化するかを示す図

統合プロセスは、反復型の段階的な開発プロセスです。精緻化、構築、移行の各フェーズは、一連のタイムボックス化された反復に分割されます。(開始フェーズは、大規模なプロジェクトの反復に分割することもできます。)反復ごとに増分が発生します。これは、以前のリリースと比較して追加または改善された機能を含むシステムのリリースです。

ほとんどのイテレーションには、ほとんどのプロセス分野(要件、設計、実装、テストなど)での作業が含まれますがプロジェクトの過程で相対的な努力と重点が変化します。

アーキテクチャ中心

統合プロセスは、アーキテクチャがシステムを形成するためのプロジェクトチームの取り組みの中心にあると主張しています。システムのすべての側面をカバーするのに十分な単一のモデルはないため、UnifiedProcessは複数のアーキテクチャモデルとビューをサポートします。

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

リスク重視

統合プロセスでは、プロジェクトチームは、プロジェクトのライフサイクルの早い段階で最も重大なリスクに対処することに集中する必要があります。最大のリスクに最初に対処するために、特に精緻化フェーズでの各反復の成果物を選択する必要があります。

プロジェクトのライフサイクル(統合プロセスのフェーズ)

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

  • インセプション
  • 精緻化(マイルストーン)
  • 建設(リリース)
  • 移行(最終製品リリース)

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

開始フェーズ

インセプションはプロジェクトの最小フェーズであり、理想的にはかなり短いはずです。開始フェーズが長い場合は、統一プロセスの精神に反する、過剰な事前仕様を示している可能性があります。

開始フェーズの一般的な目標は次のとおりです。

  • 設立
  • 予備的なプロジェクトスケジュールとコスト見積もりを準備する
  • 実現可能性
  • 購入または開発する

ライフサイクル目標マイルストーンは、開始フェーズの終わりを示します。

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

精緻化フェーズ

精緻化フェーズでは、プロジェクトチームはシステム要件の健全な大部分を獲得することが期待されます。ただし、エラボレーションの主な目標は、既知のリスク要因に対処し、システムアーキテクチャを確立して検証することです。このフェーズで行われる一般的なプロセスには、ユースケース図、概念図(基本的な表記のみのクラス図)、およびパッケージ図(アーキテクチャ図)の作成が含まれます。

アーキテクチャは、主に実行可能アーキテクチャベースラインの実装を通じて検証されます。これは、アーキテクチャ上最も重要なコアコンポーネントを含むシステムの部分的な実装です。これは、一連の小さなタイムボックス化された反復に組み込まれています。精緻化フェーズの終わりまでに、システムアーキテクチャは安定し、実行可能なアーキテクチャベースラインは、アーキテクチャが主要なシステム機能をサポートし、パフォーマンス、スケーラビリティ、およびコストの観点から適切な動作を示すことを実証する必要があります。

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

建設段階

建設はプロジェクトの最大の段階です。このフェーズでは、システムの残りの部分は、Elaborationで構築された基盤の上に構築されます。システム機能は、一連の短いタイムボックス化された反復で実装されます。反復するたびに、ソフトウェアの実行可能リリースが生成されます。構築段階でフルテキストのユースケースを作成するのが通例であり、それぞれが新しいイテレーションの始まりになります。このフェーズで使用される一般的な統一モデリング言語(UML)の図には、アクティビティ図シーケンス図コラボレーション図状態遷移図、および相互作用の概要図が含まれます。より低いリスクとより簡単な要素のための反復的な実装が行われます。最終的な構築フェーズの成果物は、移行フェーズで展開する準備ができているソフトウェアです。

移行フェーズ

プロジェクトの最終段階は移行です。このフェーズでは、システムがターゲットユーザーに展開されます。初期リリース(または初期リリース)から受け取ったフィードバックにより、いくつかの移行フェーズの反復の過程でさらに改良が組み込まれる可能性があります。移行フェーズには、システム変換とユーザートレーニングも含まれます。

改良とバリエーション

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

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

改良は、移行フェーズ後に何が起こるかについての仕様も異なります。Rational Unified Processでは、通常、移行フェーズの後に新しい開始フェーズが続きます。事業体統一プロセスでは、移行フェーズの後に本番フェーズが続きます。

ユニファイドプロセスの改良とバリエーションの数は無数にあります。統合プロセスを利用している組織は、常に独自の変更と拡張機能を組み込んでいます。以下は、よく知られている改良点とバリエーションのリストです。

参考文献