導入
統合プロセス ( Unified Processの英語では PU または UP) は、オブジェクト指向ソフトウェアのソフトウェアのライフサイクル、つまり開発をサポートする方法です。これは、逐次的な Merise メソッド (SADT) とは異なり、一般的で反復的な増分メソッドです。
PU は UML モデルのシステムを完成させます。これは、オブジェクト指向アプリケーションの最初の開発手法の 1 つである Objectory Process 手法 (1987 年) の基礎となるエリクソンのアプローチの進化の最終結果です。 Objectory Process (1995 年のバージョン 1 ～ 3.8) 自体は、Rational 社が 1998 年の RUP の直接の親である Rational Objectory Process (1997) (バージョン 4.1) を作成するための基礎として機能しました。
使用される略語
- PU: 統一プロセス。メソッドの一般的な原則を指定します。
- UP: Unified Process 、英語名。
- RUP : Rational Unified Process、UP 原則の Rational Software (IBM) によるインスタンス化。
- EUP: エンタープライズ統合プロセス、実装後のフェーズを統合し、ソフトウェアのライフサイクルを説明するインスタンス化。
- XUP: エクストリーム ユニファイド プロセス、UP とエクストリーム プログラミングを統合するハイブリッドインスタンシエーション。
- AUP: アジャイル統合プロセス。開発の機敏性を可能にする UP 原則の一部であり、理論モデルよりも現場での最適化と効率を重視したメソッドの部分的なインスタンス化です。
- 2TUP: Two Tracks Unified Process、企業のISの永続的かつ急速な変化に関連する危険性と制約を考慮してValtechが提案したUPのインスタンス化。
- EssUP: 特に UML と RUP の創始者であるIvar Jacobsonによる、必須の統合プロセス。 Ivar は、彼の会社である Ivar Jacobson Consulting を通じて、アジャイル手法の特定の概念とプロセス改善の支持者からのアイデアを統合したバージョンの統合プロセスを提供しています。 Ivar は現在、 Microsoftで EssUP を同社の共同作業ツール (Visual Studio Team System) に統合するために働いています。
- DCU: ユースケース図、PU の基本と考えられる UML モデル。
- アジャイル手法:アジャイル モデリング。アプリケーション開発における俊敏性を説明する原則を形式化し、一覧表にまとめることを試みます。
注: 便宜上、略語が使用されます。一般的な概念やインスタンス化されていないメソッドについて話すときは、フランス語に翻訳した形で頭字語を使用することを推奨します。逆に、インスタンスについて話すために、アングロサクソンの用語をそのまま使用します。
機能している
ユース ケース図 ( DCU ) による制御には具体的な意味があります。DCU から、分析、設計、展開モデルを描画する必要があります。これらは実装されるものであり、テスト ラインの開発を管理するのは計画されたユース ケースです。ユース ケースは最終的に新しいソフトウェアによって有効になる必要があります。 DCU は、開発プロセスの一貫性を保証するモデルです。彼らこそが団結するのです。最後に、DCU はその性質上、システムのアーキテクチャに本質的にリンクされています。
これは、最初から非常に実用的な方法で設計されています。作業環境、ユーザーのニーズ、ライブラリまたは既存の「ブリック」の再利用 (再利用) の可能性に適応しています。
アーキテクチャの開発は、最初は大まかでユース ケースとは独立しています (ただし、ユース ケースの実現が妨げられないようにします)。次に、重要な機能のサブセットが特定され、このセットに従ってアーキテクチャが繰り返され、詳細が説明されます。仕様からケースの精度に至るまで、アーキテクチャは進化し、最終的には新しいケースが追加されるなどして、アーキテクチャが十分に高く安定した開発レベルに達し、クライアントに提示されるプロトタイプの開発が完了します。反復。
反復とは、アクティビティの一連のステップです。増分は、開発段階における一歩前進です。各反復で、要件仕様 (開始)、開発、実行可能なプロトタイピングまでのフェーズがわかります。新しいイテレーションでは、たとえばプロトタイプをユーザーにデモンストレーションした後、仕様を明確にするか修正することで仕様を取り上げ、開発を再開します。
増分はプロジェクトによって定義され、増分ごとに新しい機能が追加されます。たとえば、増分はさまざまな使用例に従うことができます。困難は、サブプロジェクトまたは増分を最終的に結合し、それらの相互依存性と想定される製品の全体的な一貫性を尊重することにあります。したがって、これはコンポーネントの形での開発も提案されています。オブジェクト技術の貢献を最大限に活用します。
PU は、ニーズに関連した方向転換のリスクと、無限、無期限、不十分に定義された、または未完成の開発のリスクを最小限に抑えることを目的として、2 つの目的を統合します。ここで、ユーザーはプロトタイプ上で開発の方向性を自分で修正できます。たとえそれが単なるプロトタイプであっても、最初から具体的な結果が得られます。一部の PU 実装では、プロトタイプを最終システムの本格的なバージョンとみなします。このような観点からすると、従属機能は、コストや期限などの理由で途中で放棄される可能性があります。最後に、開発中にユーザーのニーズが変化した場合、この進化をある程度まで統合することができます。これは、逐次開発の場合には当てはまりません。
PU は、反復 (仕様 + 分析 + 設計 +実装+ テスト) がアクティビティ カテゴリにグループ化される全体的なライフ サイクルを提供します。これらのアクティビティは、初期 (作成)、中間 (開発、構築)、または最終 (ユーザーまたは実稼働への移行) のいずれかです。これらのアクティビティのカテゴリは、製品の生産を時間的な連続 (シーケンス) として分割しますが、プロジェクトのすべての構造化タスク (連続する改良、反復) を含み、提供されるアクティビティの総量のマトリックス組織化を提案します。作成フェーズでは、テストよりもニーズの分析に多くの時間が費やされます。逆に、移行段階では、構築段階からニーズ分析とその改良が理論的には完了しているものの、テストはまだ進行中です。
ファイル:Rup-fr.png
EUP (エンタープライズ PU) は、ソフトウェアが運用環境から削除されるまでの運用環境でのソフトウェアの存続期間を説明するアクティビティ カテゴリを追加します。
