ソフトウェア テストにおけるラショナル ユニファイド プロセス

RUP (Rational Unified Process) 方法論はその設計においてオブジェクト指向アプローチを使用し、UML (Unified Modeling Language) 記法を使用して、動作中のプロセスを図解化し文書化されています。 商業的に証明されたテクニックとプラクティスを使用しています。

これは、重く、できれば大規模な開発チームや大規模なプロジェクトに適用できるプロセスと考えられていますが、広範囲にカスタマイズ可能であるという事実により、あらゆる規模のプロジェクトに適応させることができるのです。

Specifics

プロジェクト管理のために、RUP (Rational Unified Process) モデルは、ソフトウェア開発組織内で概説されるタスクや責任などの規律あるソリューションを提供します。 これはモジュール化され自動化されており、その方法論全体はIBMが「Rational Suites」を通じて統合・販売しているいくつかの開発ツールによってサポートされています。

ソフトウェアエンジニアリングの分野における競争の手法は、「クリーンルーム」（重いと考えられている）と、エクストリームプログラミング (XP-Extreme Programming) 、スクラム、FDDなどのアジャイル（軽い）とが含まれます。

RUPによって、生産サイクルのスタッフのために、定義されている特定のガイドラインとテンプレートがあります：クライアントの一部と、その管理者によるプロジェクトの進捗状況の評価。 これは、開発者がプロジェクトに集中し続けるのに役立ちます。

Management Requirements

適切な文書は、あらゆる大規模プロジェクトに不可欠です。RUPでは、機能、システムの制限、設計上の制限、およびビジネス要件を文書化する方法を説明していることに留意してください。

ユースケースとシナリオは、従属プロセスの成果物の例であり、機能要件を捕らえるのに、より効果的と考えられている。

コンポーネントベースのアーキテクチャの使用

コンポーネントベースのアーキテクチャは、簡単に拡張できるシステムを作り、再利用とソフトウェアの直観的理解を促進させる。

RUPはこの種のシステムを構築する体系的な方法を提供し、プロジェクトの初期段階、つまり大規模なリソースを投入する前に、実行可能なアーキテクチャを作成することに重点を置いています。

ここでいうコンポーネントは一般に、すでにその場に存在するインフラストラクチャに含まれています。 これらのインフラストラクチャには、CORBAだけでなく、COM（Component Object Model）も含まれます。

RUPモデルにおけるビジュアルソフトウェアモデルの使用

コードのプログラミングを抽象化し、グラフィカルなビルディングブロックを使用して表現することにより、RUPはソリューションの概要をつかむのに有効な方法となり得るのです。

また、視覚的なモデルを使用することにより、（クライアントとして）技術的なプロファイルが低い個人でも、与えられた問題についてよりよく理解することができ、したがって、プロジェクト全体により関与することができます。

UMLモデリング言語はプロジェクトを表すための業界標準となり、RUPで広く使用されている！

Know More..: アジャイルテストの独占的な詳細について読む

ソフトウェアの品質を確認する

ソフトウェアの品質を確保できないことは、すべてのコンピュータシステムのプロジェクトで最も一般的な失敗です。 通常、1つは、プロジェクトの完了後にソフトウェアの品質について考えるか、または品質が別のチームの開発チームの責任です。

管理と制御変更ソフトウェア

すべてのソフトウェアプロジェクトでは、変更の存在が避けられないです。 RUPでは、変更を管理・監視するための方法を定義している。

RUP（ラショナル統一プロセス）はまた、別のシステムの変更があなたのシステムに影響を与えないことをプログラマに保証する作業とセキュリティの領域を定義します。

RUP方法論のフェーズ

ここまではこれらのガイドラインは、プロジェクトサイクルの寿命を介して固執することは一般的です。 フェーズ（下図参照）は、ある瞬間にプロジェクトで与えられた重点を示している。

開始または設計: システムの規模の重点;

準備: 建築の重点;

建設: 開発の重点;

Transition: 適用に重点を置いています。

RUP はまた、4つのP:

• People
• Design
• Product
• Process

レイヤーは反復で構成されています。 反復は時間の窓であり、フェーズが目的であるように反復は用語を定義している。

すべてのフェーズは成果物を生成する。 これらは次のフェーズで使用され、プロジェクトを文書化し、よりよいフォローアップを可能にする。

設計フェーズ

設計または開始フェーズには、プロジェクトの目的、アーキテクチャ、および計画について利害関係者の合意に必要なワークフローが含まれる。 これらの関係者が十分な知識を持っていれば、分析する必要はない。 そうでなければ、より精緻な分析が必要となる。

この段階では、システムの本質的な要件がユースケースに変換される。 目的はそれらをすべて閉じることではなく、意見を形成するために必要なものだけです。

このステップは通常短く、プロジェクトを継続することが可能かどうかを定義し、最後のリスクとコストを定義するために使用されます。 クライアントに承認してもらうためにプロトタイプを作ることもできる。 RUPが引用しているように、理想は反復を行うことであり、その量と目的に関して十分に定義されていなければならない。

Elaboration Phase

準備はシステムの設計のために、使用事例の調査や文書化の補完として、システムのアーキテクチャの前で、プロジェクトのビジネスモデルを見直し、ユーザーマニュアルを作成するために開始することである。 受け入れなければならない。 製品の説明（増加＋統合）が安定していること、プロジェクト計画が信頼できること。 コストは適格であるか。

構築フェーズ

構築フェーズでは、ソフトウェアの物理的な開発が始まり、プロダクションコード、アルファテストが行われる。 ベータテストは、移行フェーズの開始時に実施した。

あなたは、テスト、安定した、テストプロセスを受け入れる必要があり、システムコードは “ベースライン “です。

移行フェーズ

この段階では、展開と配信計画、監視、ソフトウェアの品質を実施し、ソフトウェアの配信（ “デサイン”）されています。 製品（リリース、バージョン）が配信されるようになり、顧客満足度を配置します。 この段階では、ユーザーのトレーニングも行われます。

RUP (Rational Unified Process) Methodologyの分野

The Business Modeling Discipline

組織はますますITシステムに依存しているので、情報システムエンジニアがアプリケーションを組織の開発に統合する方法を知ることは不可欠である。 企業は、テクノロジーによる付加価値の競争優位性を理解し、IT に投資します。

ビジネス モデリングの目標は、まずビジネス エンジニアリングとソフトウェア エンジニアリングの間のより良い理解とコミュニケーションを確立することです。

ビジネスを理解することは、ソフトウェア エンジニアがターゲット企業（クライアント）の構造とダイナミクス、組織が直面している現在の問題、および修正を加えるための潜在的方法と戦略について理解しなければならないということを意味します。

また、開発者、顧客、エンドユーザーなどの関係者が、組織について明確な理解を持っていることも重要な点であり、この理解の重要な特徴は、関係者間で共通でなければならないということです。

ビジネス・モデリングは、システムが実装される組織のビジョンをどのように記述し、このビジョンを基にプロセス、機能、責任をどのように記述するかを説明するものである。

コース要求

利害関係者（以下「利害関係者」）から要求を引き出し、構築するシステムの中で製品が動作するための要件に変換し、システムに必要なものの詳細要件を提供する方法を説明します。

分野の分析・設計（以下「設計」）

分析・設計はシステムがどのように実施されるかを示すことを目的として行われます。

特定の実行環境で、ユースケースの記述で指定されたタスクや機能を実行する

すべてのニーズを満たす

機能要件に変更がない場合、保守が容易で、分析・設計モデルでプロジェクトの結果は、オプションで分析モデルを持つ

設計モデルはソースコードの概念版として利用される、必要最小限だけを表示することだ。 これにより、任意の1つの検査のユーザは、ソースコードがレンダリングされたスタイルを確認することができる。

設計モデルは、設計の異なる部門を含むような方法でレンダリングされる。 これらの部門は明確なサブシステム内に格納される。

すべてのサブシステムは、正確に設計された明確なインターフェイスを持つ。 また、これらのクラスのオブジェクトがユースケースの設計を遂行するためにどのように協力するかについての記述が含まれています。

規律の実装

アプリケーションの効果は：

• アプリケーション用に編成された層状サブシステムを参照して、組織コードが構成されます。
• 異なるクラスまたは部品の部門は実施されている。 これらのコンポーネントは、

1. ソースファイル
2. 実行ファイルと
3. バイナリ

• ユニットとして開発したコンポーネントは

個々の実行者（またはチーム）、によって生成結果を組み込む実行システムでテストされます。

このプロセスは、すでに存在する、または新たに導入されたコンポーネントを再利用するために、利用する正確な手順を定義するという重要な機能を実行することを目的としています。

ディシプリン・テスト

ディシプリン・テストの目的は次のとおりです。

• オブジェクト間の相互作用をチェックする
• すべてのソフトウェアコンポーネントの正しい統合をチェックする
• すべての要件が正しく実行されているかチェックする
• ソフトウェアの実装前に欠陥を特定し確実に対処する
• すべての欠陥が修正されているかどうか確認する。 4243>

まとめ

プロジェクトに欠陥がある場合、その修正が期限内に明るみに出ないために、不必要なコストがかかることがあります。

しかし、もしプロジェクトが全体的にテストされるなら、プロジェクトに忍び込んでいる欠陥を早期に特定し確認することができるので、これは有益なことです。 これは、ラショナル統一プロセスが提案する反復的なアプローチです。

テストが実を結び、可能な限り最高の結果を得るためには、テストは品質の4つのパラメータで実施する必要があり、また、テストに合格したとみなされるために満たす必要のある基準を設定しなければなりません。