AEM 作成者トレーニング
ソリューションのコンテンツを生成（オーサリング）するスタッフ向けのトレーニングです。詳しくは、アドビのトレーニングサービスを参照してください。
AEM の認定試験
関連する認定試験を受けるために、適切なペルソナが登録されていることを確認します。
AEM 認定
適切なペルソナが、関連する認定試験に合格していることを確認します。
AEM テクニカルトレーニング
開発者、アーキテクト、エンジニアおよびビジネス従事者など、適切なペルソナにテクニカルトレーニングを提供します。
プロジェクトの目標として定義された KPI に関する合意
主要業績評価指標（KPI）は、組織が組織の目標を定義し、その進行状況を測定するのに役立ちます。組織は、そのミッションを分析し、目標を定義したら、それらの目標に向けた進捗状況を測定する必要があります。KPI は測定のためのメカニズムを提供します。
ビジネス KPI とパフォーマンス KPI の一致
ビジネスとパフォーマンスの主要業績評価指標（KPI）を一致させると、組織内の関係者や関係プロセスをまとめるのに役立ちます。これにより、ビジネス目標への到達や提案された目的の達成に必要な時間と労力を削減できます。
コンテンツアーキテクチャと KPI の整合性
提案されたコンテンツアーキテクチャが、関連する主要業績評価指標（KPI）と一致していることを確認します。
顧客ロードマップとプロジェクトタイムラインの整合性
顧客ロードマップは、高レベルのマイルストーンとビジネス目標で構成されています。プロジェクトタイムラインは、この戦略に従い、整合させる必要があり、潜在的なリスクや偏差があれば、それを強調表示して追跡する必要があります。
アプリケーションアーキテクチャの定義
アプリケーションアーキテクチャでは、提案されたアプリケーションの動作を明確に定義する必要があります。
次に焦点を当てます。
- アプリケーション間およびアプリケーションとユーザーのやり取りの方法。
- 内部構造ではなく、アプリケーションによって消費および生成されるデータ。
アプリケーション固有のメンテナンスタスクの定義
標準の Adobe Experience Manager（AEM）メンテナンスタスク以外にも、ソリューションの継続的なメンテナンスのために実行する必要があるその他の運用タスクを定義する必要があります。
適切なトレーニングを受けたスタッフ
チームが適切なトレーニングを受けたスタッフで構成されていることを確認します。プロジェクトチームの場合、次のすべての条件を満たしていることが推奨されます。
- 少なくとも 1 人の AEM 認定リード開発者
- 少なくとも 1 人の AEM 認定アーキテクト
- 開発者の少なくとも 75 ％が AEM 認定を受けていること。
これにより、認定開発者が後輩の開発者を指導し、知識の共有と透過性を確保することができます
アーキテクチャ図
アーキテクチャ図は、アーキテクチャを図で表現したものです。次の表現が含まれます。
- 概念
- 概念の原則
- アーキテクチャの一部である要素およびコンポーネント
アーキテクチャのドラフト
システムおよびソリューションのアーキテクチャの概要を提供します。この段階ではドラフトであり、後続の段階でレビューされ、改善されます。
アーキテクチャレビューボードの承認
アーキテクチャレビューボードは、組織を横断する体制であり、次の役割を担っています。
- 一貫した戦略の実装を監督
- システムのコンプライアンスを確認
レビューボードは、アーキテクチャに関与するすべての主要な関係者の代表である必要があります。通常は、アーキテクチャ全体のレビューやメンテナンスを担当する幹部のグループで構成されます。
自動化テストスイートの実際のコンテンツへの適合および結果と KPI の比較
自動化スクリプトおよび基本的な自動化のユースケースは次のとおりです。
- 実稼動コンテンツに適合
- KPI と比較して確認
自動テスト戦略
この戦略では、品質保証（QA）チームが計画したアプローチと共に、再利用可能な自動スクリプトのフレームワークを定義します。自動テストの全体的な計画の概要を説明し、次を実現できるようにします。
- 投資利益率（ROI）の向上
- テスト範囲の拡大
- 質の高いテストを繰り返すことによるテストの信頼性の向上
自動テスト戦略を実際に想定される負荷に対して検証
自動テスト戦略は、ソリューションのコンテンツおよび想定される負荷に従って検証し、調整する必要があります。
自動化戦略
デプロイメントを自動化して、迅速で一貫性のあるデプロイメントを実現します。自動化戦略では、このような自動化メカニズムの設定の概要を説明します。これには、以下の内容が含まれます。
- 頻度
- 使用するツール
- デプロイ先の環境
コミュニケーションプランの認識
プロジェクトチーム全体およびすべての関係者は、以下の点を認識していることを確認する必要があります。
- レポート構造
- レポートの頻度
- コミュニケーションのチャネル
成功の定義と基準の認識
プロジェクトチーム全体およびすべての関係者は、以下の点を認識していることを確認する必要があります。
- 成功の定義
- 成功の基準
バックアップと復元の概念
バックアップと復元の概念では、ソリューションに実装される技術的機能の概要を説明します。会社のバックアップおよび復元ポリシーで必要です。
バックアップと復元のテスト
バックアップと復元の概念に基づいた完全なエンドツーエンドのテストです。
ビジネスケース
ビジネスケースドキュメントでは、アクションの実行、代替アクションの実行（可能な場合）、または何のアクションも実行しないことに関する論拠を示します。論拠はバランスの取れたものであるとともに、具体的な事実に（可能な限り、関連性がある場合は）基づいており、あらゆるケースについてメリットとリスクの両方を強調する必要があります。
ビジネスケースドキュメントでは、すべてのオプションを明確に定義し、提案されたソリューションの実装に対して説得力のある論拠でまとめる必要があります。
ビジネスアナリストによるプロジェクトの範囲および期待の理解
ビジネスアナリストは、次の点を完全に理解していることを確認する必要があります。
- プロジェクトの範囲
- 顧客のあらゆる期待事項
- これが、ペルソナごと、プロジェクトのフェーズごとに下されるすべての決定の基礎となること
ビジネス KPI
組織は、目標達成の成功度合いを評価するために、主要業績評価指標（KPI）を使用します。
ビジネス KPI は、企業が主要なビジネス目標をいかに効果的に達成しているかを示す測定可能な値を定義するものです。実際のビジネスやシナリオに適した KPI を選択することが重要です。何が KPI であるか、どのように測定するか、誰がどのように使用するかを明確に定義する必要があります。
ビジネス要件ドキュメント
ビジネス要件ドキュメント（BRD）では、プロジェクトのビジネスソリューションの詳細を記述し、お客様のビジネスニーズと期待事項を明確に定義します。また、BRD では、ビジネスソリューションと技術ソリューションを区別します。
ビジネスソリューションを調査する場合、BRD は次の質問に答える必要があります。
「ビジネスで実現したいことは何ですか？」
ソリューションまたはアーキテクチャに対して必要な調整を特定し、ROI と KPI の期待値を調整した上で、ビジネスが承認
リスク評価と侵入テストのプロセスで発生した問題や結果は、ソリューションのアーキテクチャや開発で対処する必要がある場合があります。
これらのプロセスによって生じる調整は、ビジネスが確認および承認し、全体的な目標に照らして実施される必要があります。
キャッシュ戦略
キャッシュ戦略では、エンドユーザー向けにキャッシュされる内容について概要を説明します。パフォーマンス KPI に準拠する必要があります。
例えば、画像、JavaScript、その他のサーバーファイルなどの要素がキャッシュされることで、ソリューションのパフォーマンスを向上させることができます。
コーディングのガイドライン
コーディングのガイドラインでは、ソリューションを開発する際に開発者が準拠する必要がある基本原則を定義します。これには、次のものが含まれます。
- 命名規則
- サービスの使用状況
- ライブラリの使用状況
運用マニュアルの伝達
該当するすべてのペルソナまたは役割が運用マニュアルを受け取っていることを確認します。
パフォーマンステストレポートの伝達
該当するすべてのペルソナまたは役割がパフォーマンステストレポートを受け取っていることを確認します。
リリースノートの伝達
該当するすべてのペルソナまたは役割がリリースノートを受け取っていることを確認します。
チームへの範囲および期待事項の伝達
配信するプロジェクトの範囲および期待事項についてプロジェクトチームが完全に認識し、準拠していることを確認します。
トレーニング資料およびユーザーガイドの伝達
該当するすべてのペルソナまたは役割がトレーニング資料とユーザーガイドを受け取ることを確認します。
顧客セキュリティ要件への準拠
顧客のセキュリティ要件が揃っていることを確認します。
セキュリティ概念への準拠
セキュリティ概念が揃っていることを確認します。
コンポーネントとテンプレートの関係の概念
新しいアプリケーションで使用されるテンプレートとコンポーネントの概要です。継承ルール、権限、関係などの詳細が含まれます。
コンポーネントとテンプレートの関係の仕様
コンポーネントとテンプレートの関係の概念の詳細です。
コンポーネントの仕様
実装する各コンポーネントの仕様の詳細です。
外部インターフェイスのモックアップの概念
開発環境またはテスト環境で開かれない、または使用できない可能性のある外部インターフェイスに対処するための開発方法およびテスト方法に関する概念です。
テストが可能な限り実稼動に近い動作になるように、これらのインターフェイスのモックアップを計画および実装します。
コンテンツアーキテクチャドキュメント
コンテンツの提案されたアーキテクチャに関するドキュメントです。詳細には、次の内容を含める必要があります。
- コンテンツツリー
- タグ付けの概念
- コンテンツの再利用の戦略
コンテンツを移行するための検証
新しいソリューションに移行するために、レガシーシステムのコンテンツを確認し、選択したコンテンツを検証します。
契約のドラフト
法的な契約の最初のドラフトです。
現在のコンテンツの構造と形式
現在のコンテンツのアーキテクチャと形式に関するドキュメントです。これは、今後のコンテンツアーキテクチャの生成に使用されます。また、移行の概念にも使用されます。
顧客のバックアップと復元のポリシー
以下に関する顧客のポリシーです。
- データとソリューションの両方のバックアッププロセス
- バックアップのストレージ
- バックアップが期待どおりに動作していることの確認
- 復元（障害が発生した場合）
顧客のコーディングガイドライン
開発の方法に関する顧客からのガイドラインおよび要件です。
顧客のデプロイメント／リリースポリシー
デプロイメント／リリースを実行する方法とタイミングが定義された顧客のポリシーです。
多くの場合、タイムライン、スケジュール、承認の要件が含まれます。
顧客の監視ポリシーまたは要件
監視対象に関する顧客のポリシーおよび要件です。監視の概念で指定されている推奨事項に追加して指定されます。
顧客の実稼動リリーススケジュール
実稼動環境へのリリースに関して顧客が定義するスケジュールです。
顧客のレポートのポリシーと要件
レポートに関して顧客が定めているポリシーや要件またはその両方。これには次の内容が含まれます。
- 特定のレポートの提供頻度
- 特定のレポートの形式
- 特別な要件
顧客ロードマップ
技術とビジネスの両面で、実装する主要なマイルストーンのロードマップを策定します。このロードマップは、その後顧客に伝達されます。
顧客のセキュリティポリシー
顧客（ビジネスおよび IT）は、ソリューションに必要なセキュリティレベルを定義するポリシーを定めます。これには次の内容が含まれます。
- リスク評価にパスするための要件。
- 侵入テストにパスするための要件。
- すべての入力フィールドのエスケープ、暗号化の使用（SSL）、証明書、認証とセッションなどの具体的なセキュリティ要件。
顧客の仕様ガイドライン
仕様の形式、提供および承認に関連する顧客のガイドラインです。
顧客のテストレポート
ユーザー受け入れテスト（UAT）期間中の、顧客から品質リードへのレポートです。
アップグレードに影響するカスタマイズやホットフィックスの文書化
今後のアップグレードに影響する可能性があるので、カスタマイズや適用されているホットフィックスはすべて文書化する必要があります。
-
AEM は、ビジネスニーズに合わせて大幅にカスタマイズできます。アップグレードに影響する可能性のあるカスタマイズはすべて完全に文書化しておく必要があります。例えば、AEM のユーザーインターフェイス（UI）を大きく変更した場合などです。
-
次のような現在のソリューションに必要なアップデートはすべて完全に文書化する必要があります。
- 累積修正パック（CFP）
- サービスパック（SP）
- ホットフィックス
- アップグレード
ユーザー受け入れテストの日別レポート
ユーザー受け入れテスト（UAT）の結果のレポートまたは会議です。以下の詳細を説明する必要があります。
- 報告対象の問題
- これらの問題の優先順位
デフォルトのセキュリティの有効化
AEM のデフォルトのセキュリティ設定が有効化／実装されていることを確認します。
デプロイメント／リリースのポリシーおよびプロセス
プロジェクトのデプロイメントとリリースの両方に対応する、形式化されたポリシーです。これには次の内容が含まれます。
- リリースの時期
- 休日計画
- 頻度
- 対象となる環境に依存する内容
デプロイメントのサイクルの確立
複数の環境にまたがったデプロイメントに必要な頻度を定義します。
開発方法
ソフトウェア開発方法では、ソフトウェア開発作業のプロセス全体を個別のフェーズ（または段階）に分割し、それぞれに個別のアクティビティを指定することが含まれます。計画や管理をしやすくすることが目的です。
方法を定義するときは、アプリケーションの開発や保守のためにプロジェクトチームが作成し完成させる特定の成果物およびアーティファクトを、事前に定義する必要があります。
開発の役割の定義
ソリューションの中で、IT（パフォーマンスその他）テストや単体テストを実施する開発者や役割を定義します。
開発環境の準備
デプロイメントの自動化に必要な統合ツールを使用して開発環境が設定されていることを確認します。
開発チームによるプロジェクトの範囲と期待事項の理解
開発チームは、以下を完全に理解していることを確認する必要があります。
- プロジェクトの範囲
- 顧客のあらゆる期待事項
- ペルソナごと、プロジェクトのフェーズごとに下されるすべての決定の基礎
ダイアログの仕様
ソリューションに必要なダイアログの詳細です。
開発環境の設定の文書化
開発環境のドキュメントです。
実稼動環境の設定の文書化
実稼動環境のドキュメントです。
テスト環境の設定の文書化
テスト環境のドキュメントです。
耐久性テスト
耐久性テストでは、特定の負荷下でのソリューションのパフォーマンスを示します。このテストでは、しきい値の負荷を受けたときに、ソリューションがどのくらいの時間、どのようなパフォーマンスレベルで存続するかを測定します。
耐久性テストの実施
耐久性テストを実施します。
エラー処理の概念
エラー処理とは、プログラミング、アプリケーション、通信エラーの予測、検出および解決を指します。
エラー処理に関するドキュメント
エラー処理の概念に基づいて提案されたエラー処理に関する詳細なドキュメント。
エスカレーションプロセス
すべてのエスカレーションプロセスを定義します。プロジェクトレベルごとに個別のプロセスが存在します。
- プロジェクトチーム
- 顧客
- アドビ
定期的な品質レビューセッションの確立
適切なチームメンバーとの定期的な品質レビュー会議を確立します。
既存の権限の構造
レガシーソリューション用に、または組織内で定義されている、一連の権限およびグループに関するドキュメントです。
既存のシステムマップ
既存のシステムと依存関係の図（または図のセット）です。
期待される成功の定義と基準
プロジェクトスポンサーは、プロジェクトの成功に関連するビジネスの期待事項を収集します。プロジェクトの開始時に、すべての期待事項を揃えておくことが重要です。実装時に下されるすべての決断に影響することだからです。
期待事項は次のとおりです。
- 提供されるページの増加率といった特定の KPI
- コンテンツの公開までの時間の短縮
- 簡単に使用できるインターフェイスなど、より高レベルの目標
エクスペリエンスデザインの要件
ソリューションの全体的なエクスペリエンスに対する要件です。これには、パーソナライズ機能、クロスデバイスの永続性、ユーザーエクスペリエンスなどの要素が含まれます。
エクスペリエンスの仕様
エクスペリエンスデザインの要件の詳細です。
外部システムとユーザーの依存関係／システムのコンテキスト
ソリューションの完全なエコシステムの概要を示す図（または図のセット）です。これには、外部統合、インターフェイス、依存関係、ネットワークなどの要素が含まれます。
フォールバックシステムと手順
フォールバックシステムでは以下が定義されます。
- 重大な障害が発生した場合でも動作の継続が求められるビジネスクリティカルな機能
- フォールバックの発生時に必要なプロセス
フォールバックシステムと手順のテスト
フォールバックシステムのエンドツーエンドのテストです。
ビジネス関係者からのフォールバックシステムの承認
フォールバックシステムおよび関連する手順によってビジネスのクリティカルな機能が確保されるという、ビジネス関係者からの承認。
KPI の実行可能性の確認
AEM と高レベルのソリューション設計の両方に関する実行可能性調査の結果です。これらを KPI に対して測定し、達成可能であることを確認する必要があります。
最終決定された契約
プロジェクトを進行させるには、最終決定され、署名された契約が必要です。これは契約のドラフトに基づきます。
関係者によるソリューション機能の受け入れ
関係者が以下を完全に受け入れることを確認します。
- ソリューションの機能
- ソリューションの既知の問題
運用開始のスケジュール
以下のために必要なアクティビティのタイムラインとスケジュールです。
- 運用開始の準備
- 実際の運用開始
ハッピーパスの定義
ハッピーパスとは、例外やエラーの状態のないデフォルトのシナリオのことです。すべてが期待どおりに進んだ場合に実行される一連のアクティビティで構成されます。
ハードウェアの見積もり
以下の項目の初期の見積もりです。
- 基本的な AEM インストールに必要なハードウェア
- 高レベルのソリューション設計に基づくその他の要件
要件を満たすハードウェアが利用可能
すべての環境に最低限必要なハードウェアが配備されることを確認します。
全体的な要件
全体的な要件を定義することにより、システムの要件が全般的に分類され、以下のような点をカバーします。
- ビジネスプロセス
- 主なシステム機能
これらの機能に関する基本的な詳細は一般的に知られているので、このドキュメントは見積もりとしては使用できません。
高レベルのソリューションデザイン
高レベルのソリューションデザインでは、ソリューションの開発に使用するアーキテクチャについて説明します。アーキテクチャ図によってシステム全体の概要を示し、製品とそのインターフェイス用に開発された主要コンポーネントを特定します。
全体的なシステムマップ
このシステムマップは、システムの概要図を提供する必要があります。ソリューションコンテキストと異なる点は、関連するすべてのシステムの全般的なマップであり、この図にはインターフェイスが表示されないことです。
過去のコンテンツ構造
レガシーシステムのコンテンツ構造を定義したものです。これは参照用に、また移行戦略を準備する際にも使用されます。
過去のパフォーマンスと過去のパフォーマンス KPI
パフォーマンス統計およびパフォーマンス KPI をレガシーシステムから収集して、文書化します。これらは後に、基準点として使用されるか、または新しいソリューションのベンチマーク用に使用されます。
キーとなる最も重要なソリューションや機能を特定
ビジネスクリティカルな機能のリストです。
実装 - 侵入テストの結果に基づく変更
必要なすべての変更（承認済みのもの）を、侵入テストの結果に基づいてソリューションに実装します。
実装 - 自動テスト戦略
自動テストのサポートに必要なツールとプロセスを設定します。
実装 - 自動化戦略
自動処理のサポートに必要なツールセットとプロセスを設定します。
実装 - コンテンツアーキテクチャ
コンテンツアーキテクチャ、タグ付けの概念およびコンテンツの再利用を実装します。
実装 - エクスペリエンスデザイン
エクスペリエンスデザインをサポートするための要件を実装します。
実装 - フォールバックシステムと手順
フォールバックシステムおよび関連する手順を実装します。
実装 - 統合
必要なすべての外部システムとの統合を実装します。
実装 - 移行戦略
新しいソリューションのコンテンツおよびその他のアーティファクトの移行と検証を行います。
実装 - 役割と権限
役割と権限、ユーザー、グループを実装します。
実装 - セキュリティ概念
AEM のデフォルトを含めて、すべてのセキュリティ対策を実装します。
実装 - セキュリティソフトウェア
ソフトウェアアプリケーションのセキュリティを実装します。
実装 - システムアーキテクチャのセキュリティ概念
システムセキュリティを実装します。
実装 - URL 処理
URL 処理の概念を実装します。
実装 - ワークフロー
デザインされたワークフローを実装します。
実装の概念
実装の概念は、実装全体の指針を示すものです。次の点を考慮する必要があります。
- 運用
- メンテナンス
- 互換性
- 再利用性
- セキュリティ
- スケーラビリティ
この概念では、ソリューションで使用するフレームワーク、ライブラリおよびその他のアーティファクトの概要も説明します。
運用開始のスケジュールをアドビサポートに通知
アドビサポートに連絡して、運用開始時に必要なサポートが有効になるようにします。
初期エクスペリエンスデザイン
エクスペリエンスのデザインに関する予備概念です。
統合テスト
内部と外部両方のすべての統合をテストし、結果を確認します。
自動化し、頻繁に実行して、システムの安定性を確保する必要があります。
問題追跡プロセス
明確なプロセスにより、発生するすべての問題の記録と継続中のアクティビティの追跡を行い、すべての問題に確実に対処できるようにします。
問題追跡システムとプロセス
追跡システムと必要なプロセスを同時に使用することにより、発生するすべての問題の記録と継続中のアクティビティの追跡を行い、すべての問題に確実に対処できるようにします。
プロジェクトのステータスの透過性を促進するために、プロジェクトの全関係者にアクセス権が必要です。
例として、Atlassian JIRA や HP Quality Center があります。
問題追跡システムプロセスの設定と統合
選択したツールは完全に統合され、必要なすべての役割に対してアクセス権が付与されます。
レガシーシステム
プロジェクトのレガシーシステムは、既存のテクノロジー、コンピューターシステムまたはアプリケーションプログラムで、新しいソリューションに置き換えられます。
レガシーシステムの詳細を収集して、いつ何を使用停止にするかや、他のシステムへの影響を把握する必要があります。
使用する開発ツールのリスト
実装で使用する、次のようなツールの概要を示します。
- ドキュメントツール
- 問題追跡ツール
- デプロイメントツール
- ビルドツール
アドビのサポートポータルへのアクセスが必要なユーザーのリスト
アドビのサポートポータルへのアクセスが必要なすべてのユーザーおよび役割のリストです。
このリストは通常、ソリューションアーキテクトや顧客の IT スタッフで構成されます。
ログファイルの分析
分析およびその結果の推奨事項です。ソリューションを監視するには何をログに記録する必要があるかを定義します。
- ログに記録するアクティビティ
- 精度のレベル
- 各アクティビティに関してログに記録する情報
メンテナンスタスク（AEM 固有）のテストと有効化
次のような AEM メンテナンスタスクをテストして有効にします。
- コンパクション
- システムクリーン
- ワークフローのパージ
移行プラン
次を含めて、移行を文書化します。
- 移行のタイムライン
- 移行戦略に従ったコンテンツメンテナンス計画
移行戦略
既存のコンテンツ、コンテンツアーキテクチャおよび新しいソリューションにマップする形式を詳細に説明します。次のような内容も記載します。
- 可能な場合は自動移行の技術的詳細
- 移行されたコンテンツを検証するために移行後に実行するスモークテスト
また、移行から新しいシステムの実際の運用開始までの間、コンテンツを最新の状態（または可能な限り最新の状態）に保つ方法を記載することも推奨します。つまり、コンテンツのフリーズ、二重公開、アルファシステムのメンテナンスなどが必要な場合があります。
監視 - CPU
ソリューションのシステム CPU 使用率を監視します。
- 平均
- ピーク
監視 - ディスク I/O
ソリューションのディスク入出力率を監視します。
- 平均
- ピーク
監視 - ディスク容量
ソリューションのディスク容量の使用状況を監視します。
- 平均
- 時間の経過に伴う増加
次の方法で使用状況を監視する必要があります。
- リポジトリ
- ログファイル
監視 - 外部システム
ソリューションと外部システム間の接続を監視します。
- トラフィック率
- ピーク
- 安定性
監視 - ネットワーク帯域幅
ネットワーク帯域幅のソリューションの使用状況を監視します。
- 平均トラフィック率
- ピーク
- 安定性
監視 - リクエスト
ソリューションに対するリクエストを監視します。
監視 - セキュリティポイント
定義されたセキュリティポイントで監視します。
監視 - システム
システム全体を監視します。以下に例を示します。
- 可用性
- 平均パフォーマンス
- パフォーマンスのピーク
- アラート
監視 - しきい値と介入
ソリューションで定義されているしきい値と、負荷を削減するための介入手順の実装を監視します。
監視の概念
ソリューションに適用する監視概念です。以下のものが組み込まれます。
- AEM 標準監視
- システム監視
- 顧客に固有の監視要件
潜在的な弱点の監視
障害が発生しやすい点を特定し、定義する必要があります。これらに関連する監視タスクも定義する必要があります。
以下に例を示します。
- 主要なワークフロー
- トランザクション処理
- 統合ポイント
監視ポリシーをシステムエンジニアに伝達
システムエンジニアおよび運用スタッフが監視ポリシーを熟知し、理解していることを確認します。
監視レポート - 構造の準備
以下の事項を定義します。
- 監視レポートをいつ生成するか
- 監視レポートを誰に提供するか
運用タスクのドキュメント
すべての運用タスクを、頻度を定義して文書化します。
運用マニュアル
ソリューションの正常な運用とメンテナンスに必要なすべての情報を提供するマニュアルです。
- すべての運用タスク
- 主要な連絡先
- デプロイメント計画
- デプロイメントの前と後のチェックリスト
- その他の重要なタスク
また、次の点に関する実装の概念も詳細に説明します。
- パフォーマンス KPI を満たすこと
- KPI を継続して満たすようにソリューションをスケーリングすること
パッケージの準備
ソフトウェアパッケージをビルドして提供し、デプロイメントの準備を整えます。
侵入テスト
侵入テストでは、コンピューターシステムを攻撃してセキュリティの弱点を探し、場合によってはコンピューターの機能やデータにアクセスします。
侵入テスト - パス
必要なすべての条件にパスしています。
侵入テスト - 結果
侵入テストの結果を説明するレポートがビジネス用に作成されます。
パフォーマンスとスケーラビリティの概念
実装がパフォーマンス KPI を満たすようにする方法、および KPI を継続して満たすようにソリューションをスケーリングする方法に関する概念ドキュメントです。
パフォーマンスベンチマーク
パフォーマンスベンチマークは、パフォーマンステスト、耐久性テストおよび監視を定義する際に使用します。ソリューションやシステムハードウェアのパフォーマンス特性を評価することによって定義します。
パフォーマンス KPI
システムのパフォーマンスの測定に必要な主要業績評価指標（KPI）を定義します。例として、ページの読み込み時間、サーバーの応答時間、データベースのクエリパフォーマンスなどがあります。
パフォーマンステスト - レポート
ビジネス用に作成されるレポートで、パフォーマンステストの結果を詳細に説明します。
パフォーマンステスト - 結果がパフォーマンス KPI に一致
結果は、パフォーマンスに定義されている KPI および期待値に一致する必要があります。
ペルソナベースのテストの概念
ペルソナベースのテストは、エクスペリエンスデザインで概要を説明した様々なペルソナに基づいたメソッドです。アカウントおよび関連する権限レベルもテストします。
多くの場合、これはユーザー受け入れテスト（UAT）で使用されます。
要件ドキュメントに対する POC のテストおよび検証
要件に対して概念実証（POC）を測定して、両方が整合するようにします。
デプロイメント後のチェックリスト
各デプロイメント後に実行する一連のチェックやタスクを定義するチェックリストです。
デプロイメント前のチェックリスト
各デプロイメント前に実行する一連のチェックやタスクを定義するチェックリストです。
実稼動環境のベースラインパフォーマンステスト
通常、ベースラインテストは AEM の標準インストールで実行します。これはその後、実装とハードウェアをテストするためのベンチマークとして使用されます。
実稼動環境の準備完了
実稼動環境の準備が整い、自動デプロイメントが設定されていることを確認します。
ビジネス関係者からの実稼動の承認
実稼動環境で運用を開始する前に、実稼動の承認（PSO）を受ける必要があります。これは、実稼動に移行するリリースおよび既知の問題のレビューの結果を判断して行われます。承認は、運用開始スケジュールの一環として与えられます。
実稼動の承認のプロセスとポリシー
パッケージを実稼動環境に移行する前に、実稼動の承認を得るために必要なポリシーとプロセスです。
プロジェクトのコミュニケーション計画
ビジネス関係者とプロジェクトチーム双方のコミュニケーション計画を定義します。
プロジェクトの労力 - 最終見積もり
初期見積もりは、大まかな見積もりであり、実装の大まかな要件に従って行われたものです。
初期見積もりをレビュー、改善し、発展させ、最終見積もりを提供します。見積もりは、プロジェクト管理、コンサルティング、アーキテクチャ、テスト、開発などを担当するそれぞれのプロジェクトリードが提供する必要があります。
これらの見積もりは、リソース配置や予算策定に使用されます。
