Sun Java System Portal Server 7.1 配備計画ガイド

付録 C ポータル配備ワークシート

この付録は、ポータルの配備処理に役立つワークシートを提供します。

この付録で説明する内容は次のとおりです。

ポータル評価ワークシート

このワークシートを使用して、組織の業務のニーズとポータルの配備の問題になる可能性のある部分についてさらに学びます。

表 C–1 一般的な質問

ポータルが必要な業務上の理由を確認します。該当するものにすべてチェックマークを付け、詳しく検討します。 

  • 調達コストを削減する

  • 顧客、サプライヤ、またはパートナーとの情報共有のコストを削減する

  • 新しい業務サービスの配備の時間を削減する

  • 多数の個別目的のソリューションを維持するためのコストをなくす

  • サービスの対象の顧客ベースを拡大する

  • データおよびサービスへのアクセスをセキュリティー保護する

  • インターネットによる顧客との取り引きを容易にする

  • 業務サービスのサプライヤおよびパートナーとの統合の費用および時間を削減する

  • 政府の規制に従う

  • ユーザーの体感をパーソナライズする

  • サービスの使用についてのビジネスインテリジェンスを収集する必要がある

  • ユーザーがコミュニティーを設定して、ほかのコミュニティーメンバーとやり取りをする方法を提供する

組織にはいくつのポータルがすでにありますか。 

複数のポータルがある場合は、数を減らす、統合する、または連携する必要がありますか。 

それらのポータルの種類は、企業対社員、企業対顧客、企業間、ISP のどれですか。 

部門ごとのポータルがありますか。 

どの程度 Web に参加していますか。Web サイトをいくつ持っていますか。 

パートナーにアクセス可能にする、価値のある上位 10 個のアプリケーションサービスを挙げてください。サプライヤ、顧客、従業員にアクセス可能にするアプリケーションサービスについても同様に挙げてください。 

ポータルの対象コミュニティーはどこですか。 

表 C–2 組織に関する質問

このポータルの関係者はだれですか。 

ポータルを使用して所有するコンテンツまたはアプリケーションサービスを公開する、組織内の業務情報の所有者 (部門、組織、または個人) はだれですか。 

このポータルを使用して公開されるアプリケーションサービスは、部門間の業務プロセスによって管理されるさらに小規模なアプリケーションから構成されていますか。 

このポータル (インフラストラクチャー) を「所有」するのはだれですか。 

コンテンツを所有するのはだれですか。 

ポータルにコンテンツやアプリケーションを提供するように、組織内の業務情報の所有者をどのようにさらに募集する計画ですか。 

このポータルの開発の支援に、どのプロジェクト管理リソース、アーキテクトリソース、および技術実装リソースを利用できますか。 

見た目と使い心地やプレゼンテーションなどの Web サイトの特性のポリシーを設定するのは誰ですか。 

表 C–3 ビジネスサービスレベルの期待に関する質問

開発プロジェクトに一貫性がありますか。開発プロジェクトのリスク管理を行いますか。 

開発チームはどのようにテストグループ、配備グループ、および運用グループと連携しますか。 

組織は現在いくつのプラットフォームをサポートしていますか。 

情報はどの程度保護されていますか。セキュリティーはどの程度整合性がとれていますか。 

それらの課題は改善されていますか、あるいは悪化していますか。 

表 C–4 コンテンツの管理に関する質問

コンテンツまたはドキュメント管理システムがありますか。 

コンテンツの開発および公開を管理するためのワークフローを定義していますか。 

分類を定義していますか。 

情報にどの程度適切にタグが付けられ、分類されていますか。 

企業コンテンツはどのように開発、管理、追跡、および公開されますか。 

ポータルにシンジケートコンテンツが必要ですか。そうである場合、それはどのようなものですか。 

コンテンツの動的な部分と静的な部分の割合はどのようになっていますか。 

表 C–5 ユーザーの管理とセキュリティーに関する質問

ユーザーコミュニティーをどのように区分、分離、および関係付け (階層的に) ますか。 

現在および将来のセキュリティーポリシーは何ですか。 

さまざまな部門において非公開の顧客の情報を所有または管理していますか。 

企業ディレクトリがありますか。 

表 C–6 ビジネスインテリジェンスに関する質問

企業の意思決定のための情報の収集、保存、分析、および提供を行う必要がありますか。 

データ分析ツールまたは OLAP ツールをすでに使用していますか。 

どのレベル (企業全体、部門、部、プロジェクト、1 回だけのイベント) で業務情報を収集する必要がありますか。 

表 C–7 アーキテクチャーに関する質問

すでにアーキテクチャーの方針を決めていますか。 

新しい IT アーキテクチャーの実現の成功を妨げるような組織の問題がありますか。 

新しいアーキテクチャーソリューションを実装する能力がありますか。 

現在どのような技術を使用していますか。 

新しいアーキテクチャーソリューションを実装する担当者がいますか。 

ポータルを使用して配備する必要がある上位 10 個のサービスに、どのプラットフォームとアーキテクチャーをサポートする必要がありますか。 

それらのサービスはどのようにユーザーを認証し、アクセス制御を管理しますか。 

どのようにしてそれらのサービスにプログラムでアクセスできますか。 

現在および将来のメッセージング (電子メール) およびコラボレーションアーキテクチャーはどのようなものですか。 

現在および将来の企業ディレクトリアーキテクチャーはどのようなものですか。 

アプリケーションの統合には、どのような技術を使用しますか。 

対象のユーザーコミュニティーの規模はどの程度ですか。 

同時に使用するユーザー数はどの程度ですか。 

ポータルの使用範囲はどの程度ですか。 

ユーザーベースの地理的分布はどのようになっていますか。 

Web でないアクセス (ワイヤレス、音声/IVR) が現在または将来必要ですか。 

顧客ベースがコンテンツおよびサービスの国際化を必要としますか。 

どのようなサーバープラットフォーム技術を使用しますか。 

どのような開発環境、開発ツールを使用しますか。 

どのような開発方法論を採用しますか。 

ポータル設計作業リスト

表 C–8 は、ポータルの主な開発段階と設計作業を示しています。この作業リストを使用して、ポータルのプロジェクトの計画を立てます。

作業は組織や各配備の規模によって異なりますが、ワークシートはもっとも一般的な段階と作業を示します。

この表は、2 列からなります。最初の列は、主な作業を示しています。2 列目は、主な各作業を構成する個々の作業を示しています。

表 C–8 設計作業のリスト

主な段階と作業 

個々の作業 

1. プロジェクトの開始と調整

 

プロジェクトの計画 

  • 一般的なプロジェクトの管理を実行します。

プロジェクトの計画の見直し 

  • 事前実装を見直します。

  • 業務要件を見直します。

  • 技術要件を見直します。

  • アーキテクチャーの文書を見直します。

  • ハードウェアおよびインフラストラクチャーを見直します。

リソースの調整 

  • 必要なスキルを確認します。

  • リソースを確認します。

  • リソースをスケジュールします。

  • プロジェクトチームのメンバーを集めます。

  • プロジェクトチームのメンバーと作業計画を見直します。

要件の定義 

  • 業務要件を収集します。

  • 要件を要約します。

  • 機能要件を確認します。

  • 技術要件を収集します。

  • 技術要件を要約します。

  • 技術要件を確認します。

  • 要件をまとめた文書を準備します。

  • 要件を伝えます。

2. 設計

 

ソリューションアーキテクチャーの開発 

  • ソフトウェアのアーキテクチャーを設計します。

  • サーバーのトポロジを設計します。

  • アーキテクチャーの文書を作成します。

ポータルの統合方法の開発 

  • システムの統合について理解します。

  • コンテナとチャネルレイアウトを定義します。

  • コンテンツの集約を定義します。

  • SSO の方法を定義します。

  • カスタム Netlet モジュールおよびカスタム認証モジュールを開発します。

ユーザーインタフェースの設計 

  • ユーザーインタフェースの設計を準備または変更します。

  • 画面の仕様を開発または更新します。

  • ユーザーインタフェースモデルを見直し、承認します。

ディレクトリの設計 

データの設計 

  • スキーマの設計

  • ディレクトリツリーの設計

  • トポロジの設計

  • レプリケーションの設計

  • セキュリティーの設計

  • チューニングおよび最適化

  • オペレーションおよび決定

3. 開発および統合

 

テスト環境へのソフトウェアのインストール 

  • サポート Directory Server をインストールします。

  • 適切な Web コンテナ (Application Server または Web Server) をインストールします。

  • Access Manager をインストールします。

  • Sun Java System Portal Server ソフトウェア、またオプションとして Sun Java System Portal Server Secure Remote Access ソフトウェアをインストールします ( 適切なサポートソフトウェアをインストールする)。

  • その他のソフトウェアをインストールします。

  • サーバーソフトウェアを設定します。

  • サーバーソフトウェアのコンポーネントをテストします。

  • テスト結果の文書を作成します。

開発環境へのサーバーソフトウェアのインストール 

  • サポート Directory Server をインストールします。

  • 適切な Web コンテナ (Application Server または Web Server) をインストールします。

  • Access Manager をインストールします。

  • Portal Server、またオプションとして Portal Server Secure Remote Access をインストールします。

  • その他のソフトウェアをインストールします。

  • サーバーソフトウェアを設定します。

  • サーバーソフトウェアのコンポーネントをテストします。

  • テスト結果の文書を作成します。

ソフトウェアの設定 

  • 特定のソフトウェア設定要件を適用します。

  • 製品設定マトリックスを作成します。

Portal Server、Application Server およびその他のソフトウェアの変更 

  • 組織の要件と期待を見直します。

  • ソフトウェアの変更を定義します。

  • ソフトウェアの変更の方法を定めます。

  • ソフトウェアの変更計画を立てます。

  • ソフトウェアの変更を設計します。

  • ソフトウェアの変更チームを編成します。

  • 変更を行います。

  • 変更をテストします。

  • 該当する関係者および組織に変更を見直してもらい承諾を得ます。

LDAP ディレクトリの設定 

  • 適切なスキーマを設定するために関係者と話し合います。

  • ソフトウェアの変更を定義します。

  • ソフトウェアの変更の方法を定めます。

  • ソフトウェアの変更計画を立てます。

  • ソフトウェアの変更を設計します。

  • ソフトウェアの変更チームを編成します。

  • スキーマを作成します。

  • LDAP を設定します。

  • データを受け取り、検証します。

  • LDAP に要求されるようにマッピングを変更します。

  • データ更新方法を定めます。

  • ディレクトリをテストします。

  • 更新方法についてのクライアントユーザー用の文書を作成します。

旧バージョンのソフトウェアの統合 (PeopleSoft、SAP など) 

  • 統合を行います。

  • パッケージの統合テストの計画を準備します。

  • 統合テストを実施します。

  • パッケージの統合テストの結果を出します。

レポート 

  • 組織のレポートの要件を定めます。

  • レポートの計画を立てます。

  • レポートチームを編成します。

  • レポートを設計します。

  • レポートを作成します。

  • レポートをテストします。

  • レポートを顧客と見直します。

  • レポートツールの情報とトレーニングを提供します。

テスト 

  • テストの計画を立てます。

ユーザー受け入れテストの計画 

  • ユーザー受け入れテストのマネージャーを定めます。

  • ユーザー受け入れのテストの方針と手順を作成します。

  • 方針と手順を顧客と見直します。

  • 方針および手順の承諾を得ます。

  • ユーザー受け入れテストのロールと責任を定めます。

  • 統合テストのシナリオを入手します。

  • テスト条件と受け入れ基準を見直し、修正します。

  • ユーザー受け入れテストのスケジュールを立てます。

  • 受け入れテストのログを準備し、テストのシナリオの指定で更新します。

ユーザー受け入れテストの実施 

  • ユーザー受け入れテストを実施します。

  • ユーザー受け入れテストの矛盾を特定し、文書を作成します。

  • ユーザー受け入れテストの矛盾を解決します。

  • ユーザー受け入れテストを再度実行して、ユーザー受け入れテストの進捗状況を追跡します。

  • 既知の制限とテスト中に確認したプロセスの改善可能な部分を分類し、優先順位を割り当てます。

  • テストの結果を品質保証アドバイザと見直し、結果を要約して関係者に伝えます。

  • 関係者から受け入れテストの承認を得ます。

統合およびシステムのテストの実施 

  • 統合テスト環境を整備します。

  • テストチームを指名し、テストのシナリオの所有権を割り当てます。

  • チームに対して統合テスト手順、ロール、および責任のトレーニングを行います。

  • 必要に応じて、統合テストの実施スケジュールを見直して修正します。

  • 統合テストを実施します。

  • 統合テストの矛盾を特定し文書を作成します。

  • 統合テストの矛盾を解決し文書を作成します。

  • 必要な変更 (設定の改善、インタフェース、レポートなど) を特定します。

  • 統合テストを再度実施します。

  • 必要に応じて更新します。

  • テストの進捗状況を追跡します。

  • テストの承認を得ます。

  • 結果を要約し関係者に伝えます。

4. 配備の実施

 

確認方法 

  • 実装の場所と構成を関係者と見直し、定めます。

  • 実装の方法を定めます。

  • 開発用ハードウェアおよびソフトウェアのインストール作業の中で該当するものを繰り返します。

配備の見直しと更新 

  • テスト結果の既存の文書を見直します。

  • 範囲、目的、および重要な成功の要因を検証します。

  • 配備の方法を更新します。

  • 配備を見直し、承認します。

配備の実装 

  • システムのオペレーションを見直し、調整します。

  • 組織およびシステムの手順を見直します。

  • 本稼働に昇格させます。

  • 現在のオペレーションを更新します。

  • システムのリリースを改訂し、配備の資料も新しいものにします。

  • 移行を支援します。

トレーニング 

  • 組織の約束と期待を確認します。

  • すべての担当者のトレーニング要件を定めます。

  • トレーニングのスケジュールを立てます。

  • トレーニングの担当者を決定します。

  • トレーニングに必要なものを準備します。

  • 管理者をトレーニングします。

  • 保守プロバイダをトレーニングします。

  • トレーニングの参加者から意見を聞きます。

  • トレーニングの改善のために参加者の意見を反映させます。

ポータルの文書の作成 

  • システム管理者用の「運用書」を作成します。