チェックリスト - 詳細情報

役割

これらは、明確に定義され、プロジェクトに関わるすべてのユーザーに知らせる必要があります。 さらに、次の項目をハイライトすることをお勧めします。

• 意思決定者
• 連絡先

責務

• 各役割に対して、プロジェクトに関連する責任を明確に定義することで、混乱を防ぐことができます。

関与

できるだけ早く関係者を巻き込むことで、関係者になれるように促すことができます 関係者 このプロジェクトでは、成功への取り組みを増やしています。

• 顧客側では、作成者が含まれます。作成者は、日々システムを使用する必要があります。
• 独自のプロジェクトチーム内に、品質保証に責任を持つ担当者も含まれます。顧客の要件を理解するほど、テストの計画がより適切になります。

通信のパス

• これらを過度に正式に定義するべきではありませんが、具体的な定義は、主要な人々が常に情報を提供し、その結果、最新の状態に保つようにする必要があります。外部の関係者とのコミュニケーションには、特に注意が必要です。

プロセス

定義するプロセスは、個々のプロジェクトに応じて異なります。再度、以下を考慮して、これらのシンプルな設定を維持するようにしてください。

• 任意のサードパーティとやり取りするためのプロセス（および通信のパス）の定義例：設計代理店やサードパーティのソフトウェアサプライヤーなど。
• 多くの場合、顧客は独自のプロジェクト管理およびレポート作成の手順とツールを持ちます。

トラッキングツール

バグ、タスク、およびプロジェクトのその他の側面に関する情報を追跡するために利用できるツールは多数あります。詳しくは、 使用可能なツールの概要 を参照してください。

• ここで注意すべき重要な点は、情報のコピーを 1 つだけ保持し、情報を共有することです（したがって、使用中のツールにアクセスする）。これにより、メンテナンスが容易になり、不一致を防ぐのに役立ちます。

範囲

様々なレベルで、プロジェクトでカバーする内容を明確に定義します。

• 個々のリリース（反復リリースプロセスを使用する場合、顧客に提供されるか社内テストチームに提供されるかに関係なく）。
• AEMプロジェクト。
• プロジェクト全体（サードパーティ製ソフトウェア、テストへの影響、組織の問題、その他多くを含みます）。
• 特定の側面で、何が not （プロジェクトの範囲内） これは、必須の問題に限定する必要がありますが、混乱や誤った前提を防ぐのに役立ちます。

レポート

どの情報をどの形式、どの頻度、誰に報告するかを明確に定義します。

用語

• 使用する略語や顧客固有の用語を定義します。

前提

• 行われる仮定を定義します。

ビジネス:

• 主要なビジネス目標の測定に使用します。
• ビジネスやシナリオに適した KPI を、その概要、測定方法、使用方法、使用者に関する明確な定義を含めて選択することが重要です。

パフォーマンス：

• システムのパフォーマンスを測定する方法を定義します。
• 例として、ページ読み込み時間、サーバー応答時間、データベースクエリのパフォーマンスなどがあります。

「私たちのサイトは 遅すぎる 今日」 — いつ 遅い 条件を満たす？

「すべて」 歯止めをかける 同僚が「」にログインすると、システムは何人の同時ユーザーをサポートできますか。

「私が探すとき、システムは 歯止めをかける " — どの種類の検索リクエストがシステムに影響を与えていますか？

「要る 年齢 「」 — （通常のネットワーク条件下で）許容可能なダウンロード時間はどれくらいか。

個々のページの応答時間（アカウントを考慮）

• オーサー環境での応答時間
• パブリッシュ環境での応答時間

検索リクエストの応答時間

オーサー環境

この環境は、コンテンツの入力や更新をおこなう作成者が使用するので、次の操作が必要です。

• コンテンツページとそのページ上の個別の要素を更新する際に多数のリクエストを生成する、少人数のユーザー向けに作成する
• コンテンツを Web サイトに取り込むための生産性を最大限に高めるためにできるだけ早く

パブリッシュ環境

この環境には、ユーザー向けに提供するコンテンツが置かれます。

• 速度はまだ不可欠ですが、多くの場合、オーサー環境よりも遅くなります

• パフォーマンス強化メカニズムの追加は、多くの場合、次のように適用されます。

  • コンテンツがキャッシュされる
  • 負荷分散が適用される

AEM request.log を使用した応答時間の監視

パフォーマンス分析は、リクエストログから始めることをお勧めします。この情報を使用して、個々のリクエストの応答時間を確認できます。詳しくは、パフォーマンスの最適化を参照してください。

応答時間の監視 (HTMLコメント )

*HTML comments* can be used to include response time information within the source of each page:

</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

実際の検索の応答時間

• 高速検索機能は、Web サイトの品質の目標です

一般的なパフォーマンスへの影響

• 検索機能は、コンテンツの（場合によっては大きな）セクションまたは特別に抽出されたインデックスをスキャンする必要があるので、最適化されていない場合は、システム全体のパフォーマンスに影響を与える可能性があります

AEM request.log を使用した検索応答時間の監視

この場合も、 request.log を使用して、検索リクエストの応答時間を監視できます。参照 パフォーマンスの最適化 を参照してください。

検索応答時間を測定するためのプログラムされたメカニズム

検索リクエストに関して収集する情報とそのパフォーマンスをカスタマイズするには、プロジェクトのソースコードに情報収集を含めることをお勧めします。参照 パフォーマンスの最適化 を参照してください。

オーサー環境

• 通常、同時ユーザー数は正確に見積もることができます。同時にアクティブとなる作成者の数は把握できなくても、作成者の総数はわかります。

パブリッシュ環境

• これは予測が難しいので、ターゲット値を選択する必要があります。これも、現在の web サイトでの経験と、新しい web サイトに対する現実的な期待に基づくものにする必要があります。
• 特別なイベント（例えば、新しい非常に人気の高いコンテンツを公開する場合）は、期待を上回る場合や、機能（特定のイベントのチケットが販売可能になった場合にプレスで報告される場合など）もあります。

音量

• システムが処理および配信する出力の量。

処理能力

• ボリュームを配信するシステムの能力。
• 次の表に示すように、処理能力とボリュームの測定方法は各手順で異なります。最高のパフォーマンスを得るには、処理能力が各手順のボリュームに釣り合い、処理能力とボリュームの両方がすべての手順で共有されていることを確認します。例えば、要求ごとにサーバー上で計算する代わりに、クライアントコンピューター上でナビゲーションを計算したり、キャッシュに格納したりできます。

容量とボリューム

開発

• 最初にベースアーキテクチャを定義します。

• 開発には、いくつかの反復（スプリント）を使用します。

  • 最初のスプリントは、最初の完全な開発サイクルと同じです。
  • 最初のスプリントは、テスト環境に最初にデプロイされます。
  • すべてのスプリントに実行可能な結果があります。
  • 各スプリントには、顧客のサインオフ（フィードバックを含む構造化テストの最低数）が送られます。

• プロジェクトの進行中に利用可能な AEM バージョンが最終的に更新されるように計画します。

• スプリント中のテストと最適化を計画します。

• 安定化と最適化フェーズの計画。

• 今後のリリースに予定する項目のログを作成します。

• パートナーの関与と引き継ぎの計画。

インフラ

• 最初にベースアーキテクチャを定義します。

  • パフォーマンス要件を定義します。
  • パフォーマンス目標を定義します（つまり、期待値を明確に定義します）。
  • ハードウェアとインフラストラクチャのアーキテクチャの定義サイズ変更を含めます。
  • デプロイメントを定義します。

• 複数の反復を使用する。最初のスプリントと初期設定の準備について：

  • 開発環境.
  • 開発プロセス。
  • テスト環境。
  • デプロイメントプロセス（設定管理を含む）。

• 複数の負荷テストを計画します。

• スプリント中のテストと最適化を計画します。

• 安定化と最適化フェーズの計画。

• 可能な限り早く実稼動環境にデプロイします（運用チームが体験を得るためにシステムを設定できます）。

• 特定のユーザーと定義された役割をできるだけ早く使用します。

• トレーニングの計画（管理者トレーニングなど）。

• 業務への引き渡しの計画

コンテンツ

• 基本アーキテクチャは次のとおりです。

  • コンテンツ階層を動かします。
  • コンテンツの概念の定義に役立ちます。
  • MSM の使用とレイアウトを定義します。
  • 役割、グループ、ワークフローおよび権限を定義します。

• オフラインページの作成が有用かどうかを検討します。

• 最初のページとコンテンツの早期作成を計画します（テストおよびフィードバックで使用）。

• 既存のコンテンツの移行を計画します。

• リファクタリング後の「スプリント内移行」の計画

• 「コンテンツのバーンダウン」（実稼動コンテンツ用のサイトマップ）を計画します。