概念: e-ビジネス ソリューションの開発

トピック
ライフサイクルで行う作業
概念
ホワイト ペーパー

概論 ページの先頭へ

e-ビジネス アプリケーションの構築は、インターネット ソリューションを構築してビジネス プロセスを実装することを意味します。これには、e-コマースだけでなく、組織全体のすべてのビジネス プロセスが含まれます。

e-ビジネス システムは次のように区分できます。

  • Web を使用して情報を公開するだけの第 1 世代システム。
  • e- コマースと単純なトランザクション モデルを実装する第 2 世代システム。
  • プロセスを完全にリエンジニアリングして、高度にカスタマイズされた (ビジネス対顧客、またはビジネス対ビジネス) ソリューションを提供する第 3 世代システム。多くの場合、従来のシステムやインターネット デバイスと統合され、完全なビジネス プロセスに適応して、これを自動化します。

システムの世代が進むほど、その開発はより複雑になります。

方向づけ フェーズの作業 ページの先頭へ

方向づけフェーズの基本ワークフローは、次のように拡張または変更して適用します。

要求

この作業は、それほど重要ではありません。

この作業はそれほど重要ではありません。利害関係者のニーズの多くは、ビジネス モデリングにおいて検出されています。ただし、システムの機能外要求の検出を重視した作業を実行する必要があります。

この作業はそれほど重要ではありません。システムの境界はビジネスの境界で定義されます。従来のアプリケーションの場合よりも、システムはビジネスを綿密に反映します (場合によっては、システムがビジネスになります)。

分析と設計

作業: ユーザー インターフェイスの設計では、ナビゲーション マップが生成されます。ナビゲーション マップは、サイトのユーザーの移動方法を示す 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 アプリケーション アーキテクチャのモデリング」を参照してください。

  • ../process/workflow/environm/wfs_env1.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: 環境の準備

    ユーザー インターフェイスのガイドラインを作成することに加え、Web 設計要素 (サイトの Web ページを構成する個々のグラフィック画像) を作成します。Web サイト全体でユーザー インターフェイスの一貫性を維持することは、使いやすさのために必須です。Web サイトが、一貫したユーザー体験を提供するようにします。このために、プロジェクトでは、サイト全体で標準的なグラフィック要素を一貫して使用する必要があります。

    これらの要素の開発はその使用方法に関するガイドラインも作成します。すべてのチーム メンバーに、これらの要素の使用場所や使用方法を理解させます。Web 設計要素には、ナビゲーションの手段やページの背景などのグラフィック要素が含まれます。品質の高い標準のグラフィック要素をサイト全体で再利用することで、一貫性の維持、市場投入までの時間の短縮、開発コストの削減が可能です。また、高品質で小規模な要素のセットを導入することで、品質を向上できます。

    ガイドラインの準備は、初期の Web ユーザー インターフェイスのプロトタイプの開発と共に行われ、ここでサイトのスタイル ガイドが生成されます。このスタイル ガイドでは、特に、Web 設計要素を使用する状況、配色、フォント、Cascading Style Sheets、ナビゲーション要素の機能と配置の詳細について指定します。

  • ワークフローの詳細: アーキテクチャの洗練

    作業: 設計メカニズムの識別では、システムの機能外要求を、Web 開発フレームワークに用意されたメカニズムに割り当てることに注目します。フレームワークで提供されないメカニズムが存在する場合は、このメカニズムを明確にして、代替ソリューションを見つける必要があります。

    作業: 実行時アーキテクチャの記述では、Web サーバー層やアプリケーション サーバー層 (「概念: 分散パターン」を参照)、アプリケーションの並行性を管理するために使用されるプロセスとスレッドに注目します。一般的に、クライアント側のコンピュータのプロセスはほとんど、またはまったく制御できません。

    作業: 分散性の記述では、注目箇所が、「サーバー ノードに必要な種類」を決定することから、「各種類のサーバー ノードの数」を決定することに移ります。一般的に Web 開発フレームワークでは、サーバーの種類 (Web サーバー、アプリケーション サーバー、メール サーバー、通信ゲートウェイ サーバーなど) の数は固定され、機能的な境界も比較的はっきりと定義されています。結果として、使用可能なサーバーを使用してスケーラビリティとフォールト トレランスをどのように処理するかについては、ソフトウェア アーキテクトの技術が重要となります。通常は、必要になる各サーバーの数を判断して、これらの要求を処理します。また、追加サーバーが必要になる場合を判断できるように、測定計画書を作成する必要があります。

  • ../process/workflow/test/wfs_dfnevlmsn.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: 評価目標の決定

    計画では性能テストに大きく焦点を当て、同時ユーザー数が大きく増大した場合にも、Web アプリケーションが対応できるようにします。結果的に、テスト ワークフローの詳細の../process/workflow/test/wfs_tstandevl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテストと評価../process/workflow/test/wfs_achmsnacp.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません受け入れ目標の達成では、性能テストがより重視され、アーキテクチャがスケーラブルであることが確認されます。

    その他の../process/workflow/test/co_tytst.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテストの種類には、使いやすさのテスト../process/workflow/test/co_stru.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません構造テストがあります。ユーザーとのやり取りをテストして、ユーザーに対して Web アプリケーションの構造が適切であるかどうかを検証する必要があります。場合によっては、アプリケーションをインターネット上に配置して、ユーザーがアプリケーションを利用する状況を監視する必要があります。

    また、時間のかかるテストとして、ブラウザ テストがあります。ブラウザ間やブラウザのバージョン間の互換性によって、ユーザー インターフェイスの設計が制限される場合があります。

  • ワークフローの詳細: コンポーネントの実装各サブシステムの統合システムの統合

    プロジェクトのアーキテクチャに関する決定を検証するために、1 つ以上のアーキテクチャ プロトタイプを開発して、これをテストします。これには、ワークフローの詳細: コンポーネントの実装ワークフローの詳細: 各サブシステムの実装ワークフローの詳細: システムの統合の継続的な実行が含まれます。前に説明したように、テストでは特に、システム負荷が予想外に増大した場合のアプリケーションのスケーラビリティを重視します。

作成フェーズの作業 ページの先頭へ

作成フェーズの基本ワークフローは、次のように拡張または変更して適用します。

移行 フェーズの作業 ページの先頭へ

  • 現在は、Web 環境での製品リリースが増加傾向にあり、従来のメディアによる配布は減少しつつあります。リリース計画は、このような傾向に応じて調整する必要があります。
  • Web 環境でのユーザー教育は、サイトを直感的に使用できるように、Web サイト自体の設計に組み込まれる傾向があります。従来の教材、ユーザー マニュアル、文書などは作成する機会が減り、プロセスのフロントエンドにおけるグラフィックやコンテンツの設計に重点が置かれるようになっています。
  • Web 環境での製品アプリケーション サポートは、予想外の負荷が生じた場合でも、高い利用可能性を維持できるようにする必要があります。プライマリ サーバーに障害が発生しても継続して稼働できる機能を提供したり、システムを稼働したままサーバーのアップグレードを行える機能も必要です。
  • 開発チームから製品サポート チームに情報を引き継いで、製品サポート チームのスタッフがシステムを稼働させ、定期的な保守を実行できるようにする必要があります。
  • ユーザーによるアプリケーションの使用状況を調査します。この情報は、アプリケーションを誰が使用しているのか、どのように使用されているのかを把握するために利用できます。これらの調査結果は、将来のリリースでユーザーの操作性を向上するために役立ちます。

 

このページの一部は、Context Integration 社の協力により作成されています。


Rational Unified Process   2003.06.15