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