概念:
|
ライフサイクルで行う作業 |
概念ホワイト ペーパー |
e-ビジネス アプリケーションの構築は、インターネット ソリューションを構築してビジネス プロセスを実装することを意味します。これには、e-コマースだけでなく、組織全体のすべてのビジネス プロセスが含まれます。
e-ビジネス システムは次のように区分できます。
システムの世代が進むほど、その開発はより複雑になります。
方向づけフェーズの基本ワークフローは、次のように拡張または変更して適用します。
この作業は、それほど重要ではありません。
この作業はそれほど重要ではありません。利害関係者のニーズの多くは、ビジネス モデリングにおいて検出されています。ただし、システムの機能外要求の検出を重視した作業を実行する必要があります。
この作業はそれほど重要ではありません。システムの境界はビジネスの境界で定義されます。従来のアプリケーションの場合よりも、システムはビジネスを綿密に反映します (場合によっては、システムがビジネスになります)。
作業: ユーザー インターフェイスの設計では、ナビゲーション マップが生成されます。ナビゲーション マップは、サイトのユーザーの移動方法を示す Web ソリューションの観点です。多くの場合、階層「ツリー」図で表現されます。ダイアグラムの各レベルは、その画面またはページを表示するために必要なクリック数を表します。一般的には、Web サイトで最も重要な領域に、最初のページ (一般的な呼び方で「ホーム ページ」) から 1 回のクリックで移動できるようにします。実際には、ナビゲーション マップは絵コンテの要約です。ユース ケースそれぞれの主要なウィンドウや Web ページを識別することから始め、ユーザーがこれらの要素間をどのように移動するかを考察します。
推敲フェーズの基本ワークフローは、次のように拡張または変更して適用します。
作業: アーキテクチャ分析では、Web アプリケーションが比較的確立されたアーキテクチャを持つという事実を利用します。これには、確立されたメカニズム (Web ブラウザ、Java アプレットとサーブレット、ASP と JSP など) が含まれます。通常は、Web アプリケーション開発フレームワークが特殊でなければ、「概念: レイヤリング」で説明した単純なレイヤリング構造で十分です。多くの場合は、購入したり以前の Web 開発プロジェクトから再利用できる、定義済みの既製のアーキテクチャがあります。IBM 社の WebSphere や Microsoft 社の Windows DNA などの Web アプリケーション フレームワークは、この種のアーキテクチャ テンプレートを提供します。
一般的に Web アプリケーションでは、休止時間が計画されることはありません。アーキテクチャでは、システムを稼働したままシステムをアップグレードしたり、プライマリ サーバーに障害が発生した場合や、サーバーの保守またはアップグレード中に予備サーバーに切り替える機能を提供する必要があります。Web アプリケーション フレームワークによっては、製品をサポートするツールが提供されます。アプリケーションに高い利用可能性の要求がある場合は、この要求をサポートするために必要なインフラストラクチャを購入または構築し、この機能のサポートをアーキテクチャに統合するための計画が必要になります。
推敲の反復では、作業: ユーザー インターフェイスの設計を繰り返し実行します。この作業の初期の段階では、「設計案」を生成することに集中し、サイトの主要な Web ページ設計を表現するものを作成します。一般的にこれらの「案」は、ブラウザ ウィンドウのグラフィックにはめ込まれた通常の画像で、ブラウザ ウィンドウの見た目を表します。「設計案」を利用する主な利点は、サイトのグラフィックの方向性に関して同意が得られるまで、さらなる推敲や費用のかかる HTML プロトタイプへの投資を延期できることです。
「設計案」の作成では、最も重要なユース ケースのインターフェイス要求を検討し、その外観と操作性に関して多くの案 (多くの場合、10 件以上) を開発します。これらの設計案から有望なものを 3 つ選択し、利害関係者に提示します。この作業は、最終的な Web 設計に関して同意が得られるまで繰り返され、作業の結果として絵コンテとナビゲーション マップが作成されます。
同意を得て、承認を受けると、設計案は作業: ユーザー インターフェイスのプロトタイプの作成の繰り返しを通じて、機能的なユーザー インターフェイスのプロトタイプに展開されます。通常、初期の Web ユーザー インターフェイスのプロトタイプは、システムの一部 (最も重要で、アーキテクチャ上重要なユース ケース) しかサポートしません。ユーザー インターフェイスから機能が決定されるのではなく、機能によってユーザー インターフェイスのレイアウトが決定されるように、プロトタイプを開発する前に、ユース ケースのイベント フローを適切に構成することが重要です。
その後の反復で、Web プロトタイプが拡張され、ユース ケースの範囲が広くなり、アーキテクチャの動作が詳細化されます。
作業: ユース ケース分析は比較的変更されませんが、GUI の振る舞いだけでなく、基礎的なビジネス論理 (通常、Web サーバーやアプリケーション サーバーで実行される部分) にも焦点を当てることが重要です。ビジネス論理を考慮しなければ、システムの振る舞いの最も重要な部分を見過ごすことになります。Web ページ自体は「バウンダリ」クラス、データ要素は「エンティティ」クラス、サーバー側の振る舞い (アクティブ サーバー ページやサーブレットなど) は「コントロール」オブジェクトとして表現されます。
ユース ケース分析の後に、作業: 設計要素の識別で成果物: 分析クラスを洗練します。この作業では、分析クラスを Web 開発フレームワークの既存のメカニズムに割り当て、以前のプロジェクトや反復の既存の設計要素を再利用します。多くの場合、目標とする再利用レベルを達成するために、識別された分析クラスの範囲と定義を再調整する必要があります。
UML を使用した Web アプリケーションの記述方法について詳しくは、「UML を使用した Web アプリケーション アーキテクチャのモデリング」を参照してください。
ユーザー インターフェイスのガイドラインを作成することに加え、Web 設計要素 (サイトの Web ページを構成する個々のグラフィック画像) を作成します。Web サイト全体でユーザー インターフェイスの一貫性を維持することは、使いやすさのために必須です。Web サイトが、一貫したユーザー体験を提供するようにします。このために、プロジェクトでは、サイト全体で標準的なグラフィック要素を一貫して使用する必要があります。
これらの要素の開発はその使用方法に関するガイドラインも作成します。すべてのチーム メンバーに、これらの要素の使用場所や使用方法を理解させます。Web 設計要素には、ナビゲーションの手段やページの背景などのグラフィック要素が含まれます。品質の高い標準のグラフィック要素をサイト全体で再利用することで、一貫性の維持、市場投入までの時間の短縮、開発コストの削減が可能です。また、高品質で小規模な要素のセットを導入することで、品質を向上できます。
ガイドラインの準備は、初期の Web ユーザー インターフェイスのプロトタイプの開発と共に行われ、ここでサイトのスタイル ガイドが生成されます。このスタイル ガイドでは、特に、Web 設計要素を使用する状況、配色、フォント、Cascading Style Sheets、ナビゲーション要素の機能と配置の詳細について指定します。
作業: 設計メカニズムの識別では、システムの機能外要求を、Web 開発フレームワークに用意されたメカニズムに割り当てることに注目します。フレームワークで提供されないメカニズムが存在する場合は、このメカニズムを明確にして、代替ソリューションを見つける必要があります。
作業: 実行時アーキテクチャの記述では、Web サーバー層やアプリケーション サーバー層 (「概念: 分散パターン」を参照)、アプリケーションの並行性を管理するために使用されるプロセスとスレッドに注目します。一般的に、クライアント側のコンピュータのプロセスはほとんど、またはまったく制御できません。
作業: 分散性の記述では、注目箇所が、「サーバー ノードに必要な種類」を決定することから、「各種類のサーバー ノードの数」を決定することに移ります。一般的に Web 開発フレームワークでは、サーバーの種類 (Web サーバー、アプリケーション サーバー、メール サーバー、通信ゲートウェイ サーバーなど) の数は固定され、機能的な境界も比較的はっきりと定義されています。結果として、使用可能なサーバーを使用してスケーラビリティとフォールト トレランスをどのように処理するかについては、ソフトウェア アーキテクトの技術が重要となります。通常は、必要になる各サーバーの数を判断して、これらの要求を処理します。また、追加サーバーが必要になる場合を判断できるように、測定計画書を作成する必要があります。
計画では性能テストに大きく焦点を当て、同時ユーザー数が大きく増大した場合にも、Web アプリケーションが対応できるようにします。結果的に、テスト ワークフローの詳細のテストと評価、
受け入れ目標の達成では、性能テストがより重視され、アーキテクチャがスケーラブルであることが確認されます。
その他のテストの種類には、使いやすさのテストと
構造テストがあります。ユーザーとのやり取りをテストして、ユーザーに対して Web アプリケーションの構造が適切であるかどうかを検証する必要があります。場合によっては、アプリケーションをインターネット上に配置して、ユーザーがアプリケーションを利用する状況を監視する必要があります。
また、時間のかかるテストとして、ブラウザ テストがあります。ブラウザ間やブラウザのバージョン間の互換性によって、ユーザー インターフェイスの設計が制限される場合があります。
プロジェクトのアーキテクチャに関する決定を検証するために、1 つ以上のアーキテクチャ プロトタイプを開発して、これをテストします。これには、ワークフローの詳細: コンポーネントの実装、ワークフローの詳細: 各サブシステムの実装、ワークフローの詳細: システムの統合の継続的な実行が含まれます。前に説明したように、テストでは特に、システム負荷が予想外に増大した場合のアプリケーションのスケーラビリティを重視します。
作成フェーズの基本ワークフローは、次のように拡張または変更して適用します。
作業: サブシステム統合計画と作業: システム統合計画では、作成フェーズで作成するさまざまな実装要素を扱う必要があります。
作業: 設計要素の実装では、さまざまな種類の要素に注目します。
- ブラウザ環境で「実行」される Web ページ、アプレット、スクリプト、グラフィック、その他の要素
- Web サーバー環境で「実行」される、サーバー側のページ、スクリプト、サーブレット、その他の要素
- 従来のアプリケーションに対する実行可能コードの改良
- データベース管理システムで実行される、データベース テーブル、トリガ、ストアド プロシージャ、その他の要素
ツールの相違や、これらの種類の異なる要素間の導入技術の違いは、作業: 設計要素の実装に多くのバリエーションがあることを示しています。ワークフローの詳細: 各サブシステムの統合やワークフローの詳細: システムの統合でも、同様の調整を行います。
テスト計画では引き続き性能テストが重視されますが、機能テストの重要性も増していきます。Web アプリケーションを構成する要素の種類ごとに、必要なテスト手法はいくらか異なります。テスト ワークフロー詳細の テストと評価、
受け入れ目標の達成 でも、同様の調整を行います。これらの作業では、重点がアーキテクチャの性能に関するテストから機能テストへと移り、システムの振る舞いが適切であることを確認します。
このページの一部は、Context Integration 社の協力により作成されています。 | ![]() |
Rational Unified Process
|