用語集

最終更新日: 2023-05-04
  • トピック:
  • Deploying
    このトピックの詳細を表示
  • 作成対象:
  • User
注意

AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

この用語集には、プロジェクトチェックリストのすべての成果物ドキュメントの詳細が(アルファベット順に)記載されています。

ビジネス関係者からの受け入れ

ビジネス関係者からの受け入れは、主要な関係者として、ソリューションに合致し、ビジネス要件がビジネスケースをどのように満たすかについて、承認を与えていることを確認します。

受け入れテスト

受け入れテストは、アプリケーションの実稼動準備が整ったときに実行されます。 テストは、実際のシナリオを使用して、様々なタイプのエンドユーザーを表すグループによって実行されます。

受け入れテストは、次の点を確認するために使用されます。

  • プロジェクトが顧客の要求を満たしている。
  • ソリューションは、目的に適しています。
  • ユーザーはソリューションを受け入れ、ソリューションの使用を想定できます。
  • 顧客がプロジェクトを承認します。

受け入れテストの計画と設計が早ければ早いほど、最終的な導入が容易になります。 顧客および品質保証チームと共に定義する必要があります。

プロジェクトの最初にすべての詳細を定義できない場合もありますが、初期の定義については議論し、合意を得る必要があります。受け入れテストは、おそらく、基本的な要件(機能とパフォーマンス)に基づいて行われます。

テストシステムへのアクセスが調整されました

必要なレベルのシステムアクセスがすべての役割に付与されていることを確認します。

Adobeセキュリティチェックリスト

この Adobeセキュリティチェックリスト は、インストール時にAEMが安全であることを確認するために提供されている公式チェックリストです。 インスタンスの整合性を確保するために行う必要のあるセキュリティ対策や検証手順が含まれています。

Adobeサポートポータルプロジェクトの設定

Adobeサポートポータルを使用すると、実装パートナーやお客様は、AEM実装をサポートポータルのプロジェクトとして設定できます。

詳細は登録することができます。例えば、実装されたテクノロジーとバージョンについてです。 これらは、顧客とAdobeの間の透明性を提供します。

AEM管理者トレーニング

ソリューションの管理スタッフ向けトレーニング。 詳しくは、 Adobeトレーニングサービス を参照してください。

AEM オーサートレーニング

ソリューションのコンテンツを作成(オーサリング)するスタッフ向けのトレーニング。 詳しくは、 Adobeトレーニングサービス を参照してください。

AEM認定試験

適切なペルソナが適切な 認定試験.

AEM Certified

適切なペルソナが、 認定試験.

AEM Technical Training

開発者、アーキテクト、エンジニアおよびビジネス従事者など、適切なペルソナにテクニカルトレーニングを提供します。

プロジェクトの目標として定義された 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 を、その概要、測定方法、使用方法、使用者に関する明確な定義を含めて選択することが重要です。

ビジネス要件ドキュメント

ビジネス要件ドキュメント (BRD) は、プロジェクトのビジネスソリューションの詳細を記述し、お客様のビジネスニーズと期待事項を明確に定義します。 また、BRD は、ビジネスソリューションと技術ソリューションを区別します。

ビジネスソリューションを調査する場合、BRD は次の質問に答える必要があります。
「ビジネスで実現したいことは何か」

ROI と KPI の期待値に対して特定され、調整されたソリューションやアーキテクチャに対する必要な調整に関するビジネスの承認

リスク評価と侵入テストのプロセスによって、ソリューションのアーキテクチャや開発で対処する必要のある問題と結果が生じる可能性があります。

これらのプロセスによって生じる調整は、ビジネスによって確認および承認され、全体的な目標に照らし合わせる必要があります。

キャッシュ方法

キャッシュ方法では、エンドユーザーに対してキャッシュする内容の概要を説明します。 パフォーマンス KPI に準拠している必要があります。

例えば、画像、JavaScript、その他のサーバーファイルなどの要素をキャッシュして、ソリューションのパフォーマンスを向上させることができます。

コーディングのガイドライン

コーディングガイドラインでは、ソリューションを開発する際に開発者が準拠する必要がある基本原則を定義します。 これには、次のようなものが含まれます。

  • 命名規則
  • サービス使用状況
  • ライブラリ使用状況

運用マニュアルの伝達

適切なすべてのペルソナ/役割が運用マニュアルを受け取っていることを確認します。

パフォーマンステストレポートの伝達

適切なすべてのペルソナ/役割がパフォーマンステストレポートを受け取ったことを確認します。

リリースノートの伝達

該当するすべてのペルソナまたは役割がリリースノートを受け取っていることを確認します。

範囲と期待事項をチームに伝える

プロジェクトチームが、配信の範囲と期待事項を完全に認識し、それに沿っていることを確認します。

トレーニング資料およびユーザーガイドについて

適切なすべてのペルソナ/役割がトレーニング資料とユーザーガイドを受け取るようにします。

顧客セキュリティ要件への準拠

お客様のセキュリティ要件がすべて満たされていることを確認します。

セキュリティ概念への準拠

セキュリティの概念が正しく設定されていることを確認します。

コンポーネントとテンプレートの関係の概念

新しいアプリケーションで使用されるテンプレートとコンポーネントの概要です。 継承ルール、権限、関係などの詳細が含まれます。

構成部品とテンプレートの関係仕様

コンポーネントとテンプレートの関係の概念の詳細。

コンポーネント仕様

実装する各コンポーネントの仕様詳細。

外部インターフェイスのモックアップの概念

開発環境またはテスト環境で開かれたり使用できない可能性のある外部インターフェイスに対して開発およびテストする方法の概念。

テストが実稼動環境に近い動作を可能な限り確実にするために、これらのインターフェイスのモックアップを計画/実装します。

コンテンツアーキテクチャドキュメント

提案されたコンテンツのアーキテクチャのドキュメント。 詳細には、次の内容を含める必要があります。

  • コンテンツツリー
  • タグ付けの概念
  • コンテンツの再利用の戦略

移行用に検証されたコンテンツ

レガシーシステムコンテンツを確認し、選択したコンテンツを新しいソリューションに移行する際に検証します。

契約下書き

法的契約の最初の草案。

現在のコンテンツの構造と形式

現在のコンテンツのアーキテクチャと形式に関するドキュメント。 これは、将来のコンテンツアーキテクチャの生成に使用されます。 移行の概念にも使用されます。

お客様のバックアップ/復元ポリシー

次に関するお客様のポリシー:

  • データとソリューションの両方のバックアップ・プロセス
  • バックアップのストレージ
  • バックアップが期待どおりに動作していることを確認
  • 回復,失敗の場合

カスタマーコーディングガイドライン

開発の方法に関するお客様からのガイドライン/要件。

お客様の導入/リリースポリシー

デプロイメント/リリースを実行する方法とタイミングを定義する、お客様のポリシー。

これには、多くの場合、タイムライン、スケジュール設定およびサインオフ要件が含まれます。

顧客監視ポリシーまたは要件

監視する対象に関する顧客のポリシーおよび要件。 これらは、監視概念で指定された推奨事項に加えておこなわれます。

顧客の実稼動リリーススケジュール

実稼動環境へのリリースに関して顧客が定義するスケジュール。

顧客レポートのポリシーと要件

レポートに関して顧客が持つポリシーまたは要件。 次のものが含まれます。

  • 特定のレポートを配信する頻度
  • 特定のレポートの形式
  • 特別要件

顧客ロードマップ

実装すべき主要なマイルストーンのロードマップを作成し、技術とビジネスの両方を行う。 このロードマップは、お客様に伝えられます。

顧客セキュリティポリシー

お客様(ビジネスおよび IT)は、ソリューションに必要なセキュリティレベルを定義するポリシーを持ちます。 次のものが含まれます。

  • リスクアセスメントに合格するための要件。
  • 侵入テストに合格するための要件。
  • 特定のセキュリティ要件例えば、すべての入力フィールドのエスケープ、暗号化の使用 (SSL)、証明書、認証とセッション。

顧客仕様ガイドライン

仕様の形式、配信、および承認に関する顧客のガイドライン。

顧客テストレポート

ユーザー受け入れテスト (UAT) 期間中に顧客から品質リードにレポートします。

アップグレードに影響するカスタマイズとホットフィックスについて説明

今後のアップグレードに影響が及ぶ可能性があるので、カスタマイズや適用済みのホットフィックスは、ドキュメントに記載する必要があります。

  • AEMは、ビジネスニーズに合わせて大幅にカスタマイズできます。 アップグレードに影響する可能性のあるカスタマイズはすべて完全に文書化しておく必要があります。例えば、AEM のユーザーインターフェイス(UI)を大きく変更した場合などです。

  • 現在のソリューションに必要な更新は、すべて文書化する必要があります。次のものが含まれます。

    • 累積修正パック (CFP)
    • サービスパック (SP)
    • hotfixs
    • アップグレード

日別ユーザー受け入れテストレポート

ユーザー受け入れテスト (UAT) によって生じたレポートまたは会議。 詳細は次のとおりです。

  • 報告された問題
  • これらの問題の優先順位付け

デフォルトのセキュリティが有効

AEMのデフォルトのセキュリティ設定が有効化/実装されていることを確認します。

デプロイメント/リリースのポリシーとプロセス

プロジェクトのデプロイメントとリリースの両方をカバーする形式化されたポリシー。 次のものが含まれます。

  • リリース時間
  • 休暇計画
  • 頻度
  • そして問題の環境に依存する

デプロイメントケイデンスが確立されました

環境をまたいだデプロイメントに必要な頻度を定義する。

開発手法

ソフトウェア開発手法では、ソフトウェア開発作業のプロセス全体を個別のフェーズ(またはステージ)に分割し、それぞれが個別のアクティビティを持つようにします。 その目的は、計画と管理の改善です。

方法を定義する場合は、プロジェクトチームが作成し、完了した特定の成果物とアーティファクトを事前に定義して、アプリケーションを開発または保守する必要があります。

開発ロールの定義

IT(パフォーマンスなど)テストや単体テストをソリューション内で実行している開発者や役割を定義します。

開発環境の準備完了

デプロイメントの自動化に必要な統合ツールを使用して開発環境を設定する。

開発チームがプロジェクトの範囲と期待事項を理解

開発チームは、以下を完全に理解していることを確認する必要があります。

  • プロジェクトの範囲
  • すべての顧客の期待
  • これは、ペルソナごと、プロジェクトのフェーズごとにおこなわれたすべての決定の基礎となります。

ダイアログの仕様

ソリューションに必要なダイアログの詳細。

ドキュメント開発環境の設定

開発環境のドキュメント。

ドキュメント実稼動環境の設定

実稼動環境のドキュメント。

テスト環境の設定のドキュメント化

テスト環境のドキュメント。

耐久性テスト

耐久性テストでは、特定の負荷下でのソリューションのパフォーマンスを示します。 テストでは、しきい値の負荷に送信されたときにソリューションが存続する時間、およびパフォーマンスレベルを測定します。

耐久性テストが実行されました

耐久性テストの実行。

エラー処理の概念

エラー処理とは、プログラミング、アプリケーション、通信エラーの予測、検出、解決を指します。

エラー処理に関するドキュメント

エラー処理の概念に基づく、提案されたエラー処理の詳細なドキュメント。

エスカレーションプロセス

すべてのエスカレーションプロセスの定義。 プロジェクトレベルごとに個別のプロセスが存在します。

  • プロジェクトチーム
  • 顧客
  • アドビ

定期的な品質レビューセッションの確立

適切なチームメンバーとの定期的な品質レビュー会議を確立します。

既存の権限構造

レガシーソリューションまたは組織内で定義された既存の権限およびグループのセットに関するドキュメント。

既存のシステムマップ

既存のシステムと依存関係の図(または図のセット)。

期待される成功の定義と条件

プロジェクトスポンサーは、プロジェクトの成功に関連するビジネスの期待事項を収集します。プロジェクトの開始時に、すべての期待事項を揃えておくことが重要です。実装時に下されるすべての決断に影響することだからです。

式には次のものが含まれます。

  • 提供されるページの増加率など、特定の KPI
  • コンテンツの公開時間を短くする
  • 簡単に使用できるインターフェイスなど、より高レベルの目標

エクスペリエンスデザインの要件

ソリューションの全体的な経験に対する要件。 これには、パーソナライゼーション、クロスデバイスの永続性、ユーザーエクスペリエンスなどの要因が含まれます。

エクスペリエンスの仕様

エクスペリエンスデザイン要件の詳細。

外部システムとユーザーの依存関係/システムコンテキスト

ソリューションの完全なエコシステムの概要を示す図(または一連の図)です。 これには、外部統合、インターフェイス、依存関係、ネットワークなどの要素が含まれる必要があります。

代替システムと手順

フォールバックシステムの定義:

  • 重大な障害が発生した場合に動作を続ける必要があるビジネスクリティカルな機能
  • フォールバックの場合に必要なプロセス

フォールバックシステムと手順のテスト

フォールバックシステムのエンドツーエンドテスト。

ビジネス関係者からの代替システムの承認

フォールバックシステムと関連する手順によって、ビジネス関係者から重要なビジネス機能が確実に使用されるようにサインオフします。

KPI の実行可能性の確認

AEMと高レベルのソリューション設計の両方に関する実行可能性スタディの結果。 これらを KPI に照らして測定し、KPI を満たすようにする必要があります。

確定した契約

プロジェクトを続行する前に、確定し署名済みの契約が必要です。 これは、 契約下書き.

関係者が受け入れたソリューションの機能

関係者が以下を完全に受け入れることを確認します。

  • ソリューション機能
  • ソリューションの既知の問題

Go Live スケジュール

以下に必要なアクティビティのタイムラインとスケジュール

  • 運用準備
  • 実際の運用開始

定義済みハッピーパス

ハッピーパスは、例外的な状態やエラー状態のないデフォルトのシナリオです。 これは、すべてが期待どおりに進んだ場合に実行される一連のアクティビティで構成されます。

ハードウェア見積もり

以下の初期見積もり。

  • 基本的なAEMのインストールに必要なハードウェア
  • 高レベルのソリューション設計に基づくその他の要件

要件を満たすハードウェアが利用可能

すべての環境に最低限必要なハードウェアが配備されることを確認します。

要件の概要

高レベル要件の定義により、次のような側面をカバーし、システムの要件が一般的に分類されます。

  • ビジネスプロセス
  • 主なシステム機能

これらの関数の基本的な詳細は通常知られているので、このドキュメントは見積もりではありません。

ソリューション設計の概要

高レベルのソリューション設計では、ソリューションの開発に使用されるアーキテクチャを説明しています。 アーキテクチャ図は、システム全体の概要を示し、製品用に開発される主要なコンポーネントとそのインターフェイスを特定します。

概要システムマップ

このシステムマップは、システムの非常に高いレベルの図を提供する必要があります。 ソリューションコンテキストとは異なり、関連するすべてのシステムの一般化されたマップであり、この図にはインターフェイスがありません。

履歴コンテンツ構造

レガシーシステムのコンテンツ構造の定義。 これは、参照用に、また、移行戦略を準備する際にも使用されます。

実績 KPI と実績 KPI

レガシーシステムからパフォーマンスの統計とパフォーマンスの KPI を収集し、文書化する必要があります。 これらは基準点として使用され、新しいソリューションのベンチマークに使用されます。

重要な主要なソリューション/機能の特定

ビジネスクリティカルな機能のリスト。

実装 — 侵入テスト結果に基づく変更

侵入テストの結果に基づいて、ソリューションに対する必要なすべての変更(サインオフ済み)の実装。

実装 — 自動テスト戦略

自動テストのサポートに必要なツールとプロセスの設定。

実装 — 自動化戦略

自動化のサポートに必要なツールセットとプロセスの設定。

実装 — コンテンツアーキテクチャ

コンテンツアーキテクチャの実装、タグ付けの概念およびコンテンツの再利用。

実装 — エクスペリエンスデザイン

エクスペリエンスデザインをサポートするための要件の実装。

実装 — フォールバックシステムと手順

フォールバックシステムと関連する手順の実装。

実装 — 統合

必要なすべての外部システムとの統合の実装。

実装 — 移行戦略

新しいソリューションのコンテンツやその他のアーティファクトの検証と共に移行します。

実装 — 役割と権限

役割および権限、ユーザーおよびグループの実装。

実装 — セキュリティ概念

AEMのデフォルトを含む、すべてのセキュリティ対策の実装。

実装 — セキュリティソフトウェア

ソフトウェアアプリケーションセキュリティの実装。

実装 — システムアーキテクチャのセキュリティ概念

システムセキュリティの実装。

実装 — URL の処理

URL 処理の概念の実装。

実装 — ワークフロー

設計されたワークフローの実装。

実装の概念

実装の概念は、実装全体のガイド原則を提供します。 次の点を考慮に入れる必要があります。

  • 運用
  • メンテナンス
  • 互換性
  • 再利用性
  • セキュリティ
  • スケーラビリティ

この概念は、ソリューションで使用されるフレームワーク、ライブラリ、その他のアーティファクトの概要を説明することもできます。

Go Live スケジュールに関するAdobeサポートへの通知

Adobeサポートに問い合わせて、運用中に必要なサポートを有効にできることを確認します。

初期エクスペリエンスデザイン

エクスペリエンスのデザインに関する事前の概念。

統合テスト

内部と外部の両方のすべての統合をテストし、その結果確認します。

システムの安定性を確保するために、これは自動化し、頻繁に実行する必要があります。

問題追跡プロセス

明確なプロセスでは、発生したすべての問題を記録し、すべての問題に確実に対処することを目的として進行中のアクティビティを追跡します。

問題追跡のシステムとプロセス

トラッキングシステムは、必要なプロセスと共に、発生したすべての問題を記録し、すべての問題に対処するために進行中のアクティビティを追跡します。

プロジェクトのステータスの透明性を高めるために、すべてのプロジェクト関係者がアクセスできる必要があります。

例としては、Atlassian JIRA や HP Quality Center などがあります。

問題追跡システムプロセスの設定と統合

選択したツールは完全に統合され、必要なすべてのロールに対してアクセス権が付与されます。

レガシーシステム

プロジェクトのレガシーシステムは、新しいソリューションに置き換わる既存のテクノロジー、コンピューターシステム、またはアプリケーションプログラムです。

旧システムの詳細を収集し、廃止できる内容、いつ、他のシステムに与える影響を把握する必要があります。

使用する開発ツールのリスト

実装で使用されるツールの概要。ツールには以下が含まれます。

  • ドキュメントツール
  • 問題追跡ツール
  • 導入ツール
  • ビルドツール

Adobe・サポート・ポータルへのアクセスを必要とするユーザのリスト

Adobeサポートポータルへのアクセスが必要なすべてのユーザーと役割のリストです。

このリストは、通常、ソリューションアーキテクトやお客様の IT スタッフで構成されます。

ログファイルの分析

分析と、結果のレコメンデーションを組み合わせて、ソリューションを監視するためにログに記録する必要があるものを定義します。

  • ログに記録するアクティビティ
  • 精度のレベル
  • 各アクティビティに記録された情報

メンテナンスタスク (AEM固有 ) テスト済みおよび有効

次のようなAEMメンテナンスタスクをテストして有効にします。

  • 圧縮
  • システムクリーン
  • ワークフローのパージ

移行プラン

移行を文書化する。含む

  • 移行のタイムライン
  • 移行戦略に従ったコンテンツメンテナンスプラン

移行戦略

新しいソリューションにマッピングされた既存のコンテンツ、コンテンツのアーキテクチャおよび形式についての完全な説明です。 対象は次のとおりです。

  • 可能な場合は自動移行の技術的詳細
  • 移行後に実行するスモークテストを行い、移行されたコンテンツを検証します。

また、移行から新しいシステムの実際の運用開始までの間、コンテンツを最新の状態(または可能な限り最新の状態)に保つ方法もお勧めします。 これは、コンテンツのフリーズ、ダブルパブリッシング、アルファシステムのメンテナンスを意味する場合があります。

監視 — CPU

システム CPU のソリューションの使用状況を監視する:

  • 平均
  • ピーク

監視 — ディスク I/O

ソリューションのディスク入力率と出力率の監視:

  • 平均
  • ピーク

監視 — ディスク容量

ソリューションのディスク容量使用量の監視:

  • 平均
  • 時間の経過に伴う成長

次の方法で使用を監視する必要があります。

  • リポジトリ
  • ログファイル

監視 — 外部システム

ソリューションと外部システム間の接続を監視します。

  • トラフィック率
  • ピーク
  • 安定性

監視 — ネットワーク帯域幅

ネットワーク帯域幅のソリューションの使用状況を監視します。

  • 平均トラフィック率
  • ピーク
  • 安定性

監視 — リクエスト

ソリューションに対しておこなわれたリクエストを監視します。

監視 — セキュリティポイント

定義されたセキュリティポイントで監視します。

監視 — システム

システム全体を監視する。例:

  • 可用性
  • 平均実績
  • パフォーマンスピーク
  • アラート

監視 — しきい値と介入

負荷を軽減する介入手順の実装と共に、ソリューションの定義済みしきい値を監視する。

監視の概念

ソリューションに適用する監視概念。組み込み:

  • AEM standard 監視
  • システム監視
  • 顧客固有の監視要件

潜在的な弱点の監視

障害の影響を受けやすい特定のポイントを特定し、定義する必要があります。 これらに関連する監視タスクも定義する必要があります。

以下に例を示します。

  • 主要ワークフロー
  • トランザクション処理
  • 統合ポイント

監視ポリシーがシステムエンジニアに伝達されました

システムエンジニアおよび運用スタッフが監視ポリシーを把握し、理解していることを確認します。

レポートの監視 — 構造を実装する

定義:

  • 監視レポートをいつ生成するか
  • 誰に配達すべきか

運用タスクのドキュメント

すべての運用タスクをドキュメント化し、頻度を定義しました。

運用マニュアル

ソリューションの正常な運用とメンテナンスに必要なすべての情報を手動で提供する。

  • すべての運用タスク
  • 主要連絡先
  • 導入計画
  • デプロイ前/デプロイ後のチェックリスト
  • その他の重要なタスク

また、次の実装概念についても詳しく説明する必要があります。

  • パフォーマンス KPI の設定
  • これらの KPI を引き続き満たすためにソリューションをスケーリングする

パッケージの準備

ソフトウェアパッケージが構築され、展開の準備が整いました。

侵入テスト

侵入テスト(ペンテストとも呼ばれます)は、セキュリティの弱点を探し、潜在的にコンピュータの機能やデータにアクセスするコンピュータシステムへの攻撃です。

侵入テスト — 合格

必要な条件がすべて満たされます。

侵入テスト — 結果

侵入テスト結果を説明するビジネス用に作成されたレポート。

パフォーマンスと拡張性の概念

実装がパフォーマンス KPI を満たすようにする方法に関する概念的なドキュメント、および KPI を満たし続けるようにソリューションを拡張する方法に関する概念的なドキュメントです。

パフォーマンスベンチマーク

パフォーマンスベンチマークは、パフォーマンステスト、耐久性テスト、および監視を定義するために使用されます。 ソリューションやシステムハードウェアのパフォーマンス特性を評価することによって定義します。

パフォーマンス KPI

これらは、システムのパフォーマンスを測定するために必要な主要業績評価指標 (KPI) を定義します。 例として、ページ読み込み時間、サーバー応答時間、データベースクエリのパフォーマンスなどがあります。

パフォーマンステスト — レポート

ビジネス用に作成されたレポート。パフォーマンステストの結果の詳細を示します。

パフォーマンステスト — 結果がパフォーマンス KPI に一致する

結果は、定義された KPI と、パフォーマンスに対する期待値に一致する必要があります。

ペルソナベースのテストの概念

ペルソナベースのテストは、エクスペリエンスデザインで概要を説明する様々なペルソナに基づくメソッドです。 また、アカウントとそれに関連する権限レベルもテストします。

これは、多くの場合、ユーザー受け入れテスト (UAT) で使用されます。

要件ドキュメントに照らしてテストおよび検証された POC

概念実証 (POC) は、両方が一致するように要件に対してゲージ化されます。

デプロイ後のチェックリスト

各デプロイメント後に実行する一連のチェックとタスクを定義するチェックリストです。

デプロイメント前のチェックリスト

各デプロイメントの前に実行する一連のチェックとタスクを定義するチェックリストです。

実稼動環境のベースラインパフォーマンステスト

AEMの標準インストールでベースラインテストを実行するのが通常です。 これは、実装とハードウェアをテストするためのベンチマークとして使用されます。

実稼動環境の準備完了

実稼動環境が準備され、自動デプロイメントが実行されていることを確認します。

ビジネス関係者からの実稼動の承認

実稼動環境に移行する前に、実稼動のサインオフ (PSO) を許可する必要があります。 これは、実稼動環境に移行されるリリースのレビューと、既知の問題の結果です。 サインオフは、Go Live スケジュールの一部として指定されます。

実稼動のサインオフプロセスとポリシー

パッケージを実稼動環境に移動する前に、実稼動のサインオフを取得するために必要なポリシーとプロセスです。

プロジェクト通信計画

ビジネス関係者とプロジェクトチームの両方に対してコミュニケーション計画を定義します。

プロジェクトの取り組み — 最終見積もり

この 初期見積もり は高いレベルであり、実装の高いレベル要件に従っておこなわれます。

これらは、最終的な見積もりを提供するために、レビュー、絞り込み、拡張されました。 見積もりは、プロジェクト管理、コンサルティング、アーキテクチャ、テスト、開発など、適切なプロジェクトリードごとに提供する必要があります。

これらの見積もりは、リソースの割り当てと予算の割り当てに使用されます。

プロジェクトの取り組み — 初期見積もり

初期見積もりは高レベルで、実装の高レベル要件に従っておこなわれます。 これは後の段階でレビューおよび絞り込まれます。

プロジェクト組織

プロジェクトとチームの組織とレポート構造の概要を説明するために必要なドキュメント。

多くの場合、タイムラインと責務の視覚的な概要を示すグラフをフォームに記述し、含めます。 これに役立つツールが多数あります。

プロジェクト範囲ドキュメント

プロジェクト範囲ドキュメントでは、次のリストを特定し、ドキュメント化する必要があります。

  • 特定のプロジェクト目標
  • 成果物
  • 機能
  • 関数
  • タスク
  • 期限
  • 計画された作業

プロジェクトを提供するために何を達成する必要があるかを、実行する必要がある作業と共に説明します

定義済みのケイデンス内のプロジェクトステータスレポート

同意されたスケジュールに従って、必要な形式で配信されるプロジェクトステータスレポート。

概念実証(POC)

概念実証 (POC) は、ソリューションに対して限られた範囲の関数を実装します。

ソリューションの実現可能性を実証し、必要な目的を満たすことができることを確認し、使用される可能性があることを証明する必要があります。

ルールをパージ

AEMでは、複数のバージョンのアセットやコンテンツを管理しています。 パージルールは、リポジトリの正常性とサイズを維持するために、古いバージョンを定期的に削除するように設計および設定されています。

品質レポートの形式とケイデンス

品質レポートの必要なコンテンツと形式と、配信頻度を定義します。

連携リリース

プロジェクトマネージャーは、実稼動環境へのリリースに必要なすべての役割を調整します。

リリースノート

リリースノートは、このリリースのドキュメントの一部です。 リリースノートでは、次の内容を扱う必要があります。

  • 前提条件
  • 含まれる要件
  • 解決された問題
  • リリースの既知の問題

Runbook と共に使用して、インストール前と後の手順と確認を実行します。

メモ

例については、AEM のリリースノートを参照してください。

実稼動環境で実行されているリリース

最終リリースが実行され、実稼動環境でアクティブになっています。

関連する契約条件

プロジェクトの実装に関連する特定の契約条件を強調する必要があります。契約上のマイルストーン、請求書の期間、スタッフの要件など。

レポート頻度

顧客と共に、顧客に配信するレポートの頻度を定義します。

リポジトリの最適化

tar ファイルではデータが上書きされることはなく、既存のデータを更新するだけでもディスク使用量が増加します。

リポジトリのサイズが増え続けるのに対処するために、古いデータを削除するための最適化戦略が導入されています。

Adobeサポートポータルでのプロジェクトセクションの設定のリクエスト

Adobeサポートポータルでプロジェクトをセットアップするための公式リクエスト。

要件ドキュメント

この一連のドキュメントでは、機能要件と機能しない要件、および推定される労力をカバーしています。

Go Live をサポートするために利用できるリソース

運用開始に必要なすべての役割がスタッフを配置し、使用可能であることを確認します。

リスク評価

リスク評価は、お客様の IT 部門やセキュリティ部門が実行します。

プロジェクトの技術的リスクとビジネス上のリスクを評価します。 この評価は、セキュリティポリシーへのコンプライアンスを確保するために、ソリューションに必要です。

リスク軽減計画

リスク軽減計画には、リスクアセスメントが含まれます。 2 つのカテゴリーで構成される内容は次のとおりです。

  • 特定されているリスク
  • 導入時に発生するリスクに対して考えられる解決策

ROI の期待値

ソリューションに付随する投資利益率 (ROI) の期待値を定義します。

また、予想投資に対して期待される利益と利益を定義し、経済的にソリューションの効率を示すことを目的としています。

役割と権限の概念

新しいアプリケーションに必要な役割とアクセス権に関する概念の詳細な仕様(以下の概要を含む)。

  • 役割
  • グループ
  • ユーザー
  • 権限
  • ユーザー管理とプロビジョニング

セキュリティガイドラインを満たす役割と権利の概念

役割と権限の概念をレビューし、セキュリティポリシーを満たしていることを確認します。

役割と権限の指定

役割と権限の概念に基づく詳細な仕様です。

セキュリティアーキテクチャRecommendations

Recommendationsは、ソフトウェアとハードウェアアーキテクチャのセキュリティに関連しています。

セキュリティに基づくコーディングガイドライン

以下のガイドラインは、次のようなセキュリティ要件に基づいて、開発コーディングの実行方法を定義します。

  • 命名規則
  • ライブラリ
  • フレームワークのガイドライン
  • API の使用

セキュリティチェックリスト

セキュリティ概念に基づくプロジェクト固有の項目のチェックリストと、ソリューションのコンプライアンスを確保するために必要な追加のポリシー。

多くの場合、これはランブックのデプロイ後の手順の一部としても含まれます。

セキュリティ概念

アプリケーション、アーキテクチャおよびインフラストラクチャに必要なセキュリティ設定の詳細を定義して文書化します。

セキュリティ概念下書き

次のセキュリティ設定に関する概要です。

  • アプリケーション
  • アーキテクチャ
  • インフラ

表示および評価されたセキュリティ上の問題

このソリューションのセキュリティ上の問題は、すべてリストされ、評価されました。労力の見積もりも含む

ビジネス関係者からのセキュリティの承認

セキュリティ実装がポリシーや期待に準拠していることを確認するには、関係者からサインオフします。

サポートプロセスの設定

必要なサポートプロセスを設定します。

サードパーティシステムの SLA

実装とサポートの際に使用する SLA(Service Level Agreement) が使用可能で、開発チームと運用チームの両方に伝達されていることを確認します。

スモークテストの概念

スモークテストは、ソリューションの主要な機能をテストし、ソリューションの基本的な操作と機能を確実に確認する、定義された一連のステップで構成されます。

これらは、インストール後またはデプロイ後に、どの環境でも実行されます。

システム検証で実行される煙テスト

スモークテストは、すべてのシステムで実行し、インストールまたは環境への導入時にソリューションの基本機能が正しく動作することを確認する必要があります。

ソフトウェアアーキテクチャ戦略

ソフトウェアアーキテクチャの高度な戦略サービス、サーブレット、フレームワークおよびその他の実装の決定を含みます。

ソリューションレビューボードの確立と会議ケイデンスセット

ソリューションレビューボードは、通常、お客様の関係者で構成されます。

同委員会は、現在範囲を定めた要件と関連仕様を継続的にレビューするための定期的な会議を開催しています。 この目的は、成功の定義と条件との整合性を確保し、要件の開発に関する情報を提供することです。

ソリューション Runbook

ソリューションのインストール手順と、インストール時に実行する基本的な操作タスク。

ソリューションの承認および承認プロセス

承認と受け入れのプロセスでは、ソリューションを実稼動環境にリリースする前に満たす必要のある条件の概要を説明します。

契約上のマイルストーンとしても機能します。

特殊機能の概念

AEMプラットフォームでの通常の開発範囲外と見なされる、特別な機能に対する初期概念です。

特殊機能仕様

AEMプラットフォーム上での通常の開発範囲外と見なされる特別な機能の詳細。

仕様ガイドライン

仕様の実行方法に関するお客様からのガイドライン。

定義済みおよび伝達済みの仕様レビューおよび承認プロセス

顧客が仕様を承認するための明確なプロセスを実施する必要があります。 このプロセスにより、要件の範囲が明確で確実になります。

AEM Administrator Training 用に選択されたスタッフ

ソリューションの管理にトレーニングが必要な社内スタッフ。

作成者およびエンドユーザートレーニング用に選択されたスタッフ

ソリューションの作成に必要なトレーニングを受ける社内スタッフ。

関係者

関係者は、プロジェクトに大きな関心を持つキーパーソンや役割です。 プロジェクト予算に貢献する人もいます。

利害関係者は、内部の場合も外部の場合もあります。

関係者が成功の定義と条件を認識する

実際の実装チーム以外のすべての関係者が以下を認識していることを確認します。

  • 成功の定義
  • 成功の基準

関係者がプロジェクトと期待事項を理解する

実際の実装チーム以外のすべての関係者が、プロジェクトチーム内部およびお客様側の両方で、プロジェクト全体および期待に沿っていることを確認します。

ステータスレポート形式の定義

ステータスレポートは、コミュニケーションの主要ツールです。 形式は、お客様のレポート要件に合わせる必要があります。

達成基準と定義

お客様、プロジェクトスポンサー、プロジェクトマネージャーまたはコンサルタントは、次を指定する必要があります。

  • 何がプロジェクトの成功の結果を定義しますか。
  • 成功の定義を満たすために必要な特定の条件。

これらは、成功の基準を確実に満たすために使用されます。

  • KPI の基準として。
  • 実装全体を通じて意思決定をおこなう場合。

報告された問題の検証におけるサポート

品質リードの責任の一部は、テスト時にユーザーをサポートするリソースがあることを確認することです。 例えば、テスト時、問題の報告時、テスト環境に対する問題の検証に役立つように、ユーザーを支援します。

サポートプロセスとAdobeサポートポータルへのアクセス

Adobeサポートポータルへのアクセスは、実装時に発生する可能性のある製品ベースの問題に関するチケットを送信する上で重要です。

アクセスは、チームの主要メンバーに割り当てる必要があります。

システムアーキテクチャの定義

ソリューションのすべての環境に対するアーキテクチャの初期の提案と定義。

システムアーキテクチャのドキュメント

システムアーキテクチャを詳しく説明するドキュメントすべての環境用のインターフェイス、ネットワークの場所、統合などの情報を含みます。

システムアーキテクチャのセキュリティ概念

システムアーキテクチャをセキュリティポリシーに準拠させる方法の概要です。 対象となる内容は次のとおりです。

  • ファイアウォールとファイアウォールの規則
  • セキュリティゾーン
  • ローカルおよび一般的なトラフィックマネージャー
  • web サーバー
  • プロキシとリバースプロキシ

特定および検証されたシステムリスク要因

リスク評価(またはその他のレビュー)で見つかったリスク要因を特定し、評価します。

  • それぞれに含まれるリスクのレベル
  • およびそれに対処するために必要な実装の変更に対する推定された作業。

チームは成功の定義と条件を認識しています

チーム全体が成功の定義と条件を認識していることを確認します。

チームがコミュニケーションプランを認識

チームのすべてのメンバーが、顧客とのコミュニケーションが必要な相手と、その方法とタイミングの詳細を認識していることを確認します。

チームがプロジェクトと期待を理解する

プロジェクトチーム内部およびお客様に対する全体的なプロジェクトおよび期待との整合性。

技術要件

これらの要件は、ソリューションをサポートするサービスの技術的な実装に固有です。

技術的リスク要因の検証

潜在的な技術的リスクを特定し、検証します。 技術的リスクには、次のものが含まれます。

  • クロスサイトスクリプティング
  • ユーザーが入力フィールドに対して表示するエンド
  • インフラ
  • 技術年齢
  • 統合数
  • 依存関係

技術仕様

技術仕様では、次の情報を扱います。

  • インターフェイス
  • 設定
  • API
  • ソリューションの要件をサポートするサービス

テンプレートの指定

必要なテンプレートの仕様。 parsys、ブループリント、継承マッピングなどの詳細をカバーする必要があります。

これらの仕様は、ビジネス要件とエクスペリエンス要件に基づいています。

テストケース

テストケース(ソリューションの機能テストの実行に必要な詳細な手順)

コンテンツをテスト

テストコンテンツは、可能な限り実際のコンテンツに近付ける必要があります。すべてのシナリオを十分にテストできるように幅広く選択する必要があります。

テスト環境の準備完了

テスト環境の準備が整い、自動デプロイメントがおこなわれていることを確認し、すべてのリリース候補コードがテスト用に最新の状態になっていることを確認します。

テストレポート

テストの結果を詳しく説明するレポート次を含む:

  • 発生した欠陥
  • 実行されたテストケースのステータス
  • その他の品質関連トピック

次のことに注意してください。

  • テストチームは、中立を保ち、テスト結果を提供する必要があります。
  • 結果の影響を評価し、適切な行動を決定するのは、プロジェクトマネージャーの責任です。

テストスイート

自動化スイートとツールの選択。 これらは、使用例のテストを含め、テストの自動化に使用されます。

テストツールスイートが選択されました

ユースケースの自動化やその他のテスト実行タスクのために選択された自動化スイートおよびツール。

テストの概念

テストの概念は、プロジェクトのテストの非常に大まかな概要です。これには、QA、UAT、パフォーマンス、セキュリティ、統合テストが含まれます。

テスト計画

これらのプランは、開発の各段階でのテストの実行の詳細を示し、 テスト戦略.

テスト範囲

これらの要件は、ソリューションをサポートするサービスの技術的な実装に固有です。

テスト戦略

テスト戦略は、品質保証とユーザー受け入れテストに関する高レベルの戦略を概説しています。 これには、タイムライン、レポートサイクル、実行が含まれます。

サードパーティ統合の概念

サードパーティ製システムとの統合に関するアーキテクチャおよびシステムレベルの概念。

サードパーティ統合仕様

サードパーティ製システムのサポートされる機能と統合に関する要件(機能と機能以外の両方)の詳細。

サードパーティのセキュリティ概念

サードパーティ統合のセキュリティを確保するための概念。 適切なセキュリティポリシーに準拠している必要があります。

統合のためのサードパーティシステム

統合の実装に関して、適切なドキュメントと共に、すべてのサードパーティ製システムが使用可能であることを確認します。

サードパーティシステムのアクセスが有効

サードパーティ製システムと組み合わせて使用されるそれぞれの役割に対して付与される必要なアクセス権。

サードパーティのテストの概念

定義:

  • 統合をテストするためのユースケース
  • サードパーティアプリケーションに関連する機能

しきい値の定義

システム内の監視ポイントのキー値を定義します。

次は例です。

  • 未送信のログの KB(キロバイト)数が、プリンシパルサーバーインスタンスで警告を生成します
  • プリンシパルサーバーで警告が生成される前に許容されるトランザクションごとの平均遅延時間(ミリ秒)

タイムラインとマイルストーン

これにより、以下に使用するプロジェクトのタイムラインと契約上のマイルストーンを定義する必要があります。

  • 請求。
  • 成功の定義、達成基準および KPI との整合性。

プロジェクトの取り組みの合計

プロジェクト上の各リードから見積もられるすべての労力は、統合される必要があります。これには、オーバーヘッド、開発、システムエンジニアリング、アーキテクチャおよびテストの取り組みが含まれます。

契約にサポートレベルが含まれている場合は、サポートと運用の取り組みも含まれる必要があります。

トレーニング資料

トレーニングセッションで使用する資料。 マテリアルは、ソリューション専用に作成され、ユーザーガイドと共に使用するように設計する必要があります。

プロジェクトの範囲と期待事項の理解

適切なペルソナが、以下を完全に理解していることを確認する必要があります。

  • プロジェクトの範囲
  • すべての顧客の期待
  • これは、ペルソナごと、プロジェクトのフェーズごとにおこなわれたすべての決定の基礎となります。

URL 処理の概念

URL 処理の概念では、次のようなAEM固有の URL 機能をカバーする必要があります。

  • バニティ URL
  • リンクの外部化
  • エラーページ
  • マッピング

概念は次のこともカバーする必要があります。

  • 書き換えルール
  • web サーバー上の仮想ホスト
  • SEO に関する考慮事項(robots.txt など)
  • サイト地図

ユースケース

ユースケースとは、目標の達成に必要なアクションまたはイベントステップのリストです。 通常は、役割とソリューションの間のやり取りを定義します。 役割は、ユーザーまたは外部システムにすることができます。

テストシナリオに変換されたユースケース

テストシナリオは、技術的およびビジネス的なユースケースに基づいています。 これらは、ソリューションの動作が期待どおりであることをテストするために使用されます。

ユーザーガイド

ユーザーガイドは、ソリューションのユーザーに対して、次の情報と支援を提供します。

  • 作成者
  • パワーユーザ
  • 管理者

検証済みの予算計画

予算計画は、すべての関係者が確認し、検証する必要があります。 請求、金額、予算報告の方法/時期などの詳細を確認する必要があります。

ホワイトボックステスト結果

ホワイトボックステストは、機能とは異なり、アプリケーションの内部構造や動作をテストするメソッドです。 ホワイトボックステストは、ソフトウェアテストプロセスの単位、統合、およびシステムレベルで適用できます。

ワークフローの仕様

ワークフローの概念に基づき、これらの仕様では、完全なワークフローを作成する手順を詳細に定義する必要があります。

各ワークフローの仕様には、少なくとも次の内容を含める必要があります。

  • 使用例
  • 役割
  • 手順
  • 結果
  • エラー処理

ワークフローの概念

ワークフローを使用すると、AEMアクティビティを自動化できます。 ワークフローの概念では、次の概要が説明されます。

  • 自動化が必要なプロセス
  • 影響を受けるAEMのサービスと役割

このページ