字彙表

本辭彙表列出項目核對表中所有交付項文檔的詳細資訊。

業務利益相關方的接受

業務利益相關方的接受確認，作為關鍵利益相關方，他們與解決方案保持一致，並已就業務需求如何滿足業務案例給予批准。

接受測試

當應用程式可供生產時，就會執行驗收測試。 測試是由代表各種類型使用者的群組使用實際案例來執行。

驗收測試用於確認：

• 項目滿足客戶的要求。
• 解決方案是適合用途的。
• 使用者接受此解決方案，並可設想使用它。
• 客戶接受專案。

您規劃和設計驗收測試的時間越早，最終部署就越輕鬆。 應與客戶和您的品質保證團隊一起定義。

雖然您可能無法在專案開始時定義所有詳細資訊，但應討論並同意初始定義。 驗收測試可能會以基本要求（功能和效能）為基礎。

訪問協調的測試系統

確保系統訪問權限的必要級別已授予所有角色。

Adobe安全性檢查清單

Adobe安全性檢查清單是提供的正式檢查清單，以確保AEM在安裝時安全無虞。 它包含您需要執行的安全措施和驗證步驟，以確保實例的完整性。

Adobe支援入口網站專案設定

Adobe支援入口網站可讓實作合作夥伴和客戶將AEM實作設定為支援入口網站中的專案。

可以註冊細節；例如，關於實作的技術和版本。 這可讓客戶和Adobe之間透明。

AEM管理員訓練

針對解決方案的行政人員進行培訓。 如需詳細資訊，請參閱Adobe訓練服務。

AEM Author Training

針對將要製作（編寫）解決方案內容的員工進行培訓。 如需詳細資訊，請參閱Adobe訓練服務。

AEM認證測驗

請確定已註冊適當的人員，以參加相關的認證測驗。

AEM Certified

請確定適當的人物已通過相關認證測驗。

AEM Technical Training

為適當人物提供技術培訓；例如，開發人員、建築師、工程師和商業從業者。

關於定義為項目目標的KPI的協定

關鍵績效指標(KPI)可協助組織定義並衡量邁向組織目標的進度。 一旦一個組織分析其使命並確定其目標，就需要衡量實現這些目標的進展。 KPI提供測量機制。

協調業務和效能KPI

業務與績效的協調關鍵績效指標(KPI)有助於將組織內所有相關人員和流程匯集在一起。 這進而有助於減少實現業務目標和實現建議目標所需的時間和精力。

內容體系結構與KPI的協調

確保建議的內容體系結構與相關的關鍵績效指標(KPI)一致。

客戶路線圖與項目時間表的協調

客戶路線圖由高級別里程碑和業務目標組成。 項目時間表必須遵守並符合此策略，因此必須強調和追蹤任何潛在風險和／或可能的偏差。

應用程式體系結構定義

應用程式架構應清楚定義建議應用程式的行為。

重點是：

• 他們如何與彼此及使用者互動。
• 應用程式要消耗和產生的資料，而非其內部結構。

應用程式特定維護任務已定義

除了標準Adobe Experience Manager(AEM)維護工作外，您還需要定義任何其他作業工作，以便執行解決方案的持續維護。

經過適當培訓的工作人員

確保您的團隊由擁有適當培訓的員工組成。 對於項目團隊，建議您具備下列所有功能：

• 至少有一名AEM認證的Lead Developer

• 至少有一位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（效能或其他）和／或單元測試的開發人員和／或角色。

開發環境就緒

確保開發環境已配置為自動化部署所需的整合工具。

開發團隊瞭解項目範圍和期望

開發團隊應確認他們完全瞭解：

• 項目範圍
• 所有客戶期望
• 這是項目中每個階段根據個人做出的所有決定的基礎

對話框規範

解決方案所需對話方塊的詳細資訊。

文檔開發環境設定

開發環境的檔案。

文檔生產環境設定

生產環境的說明檔案。

文檔測試環境設定

測試環境的檔案。

耐久性測試

耐久性測試顯示瞭解決方案在特定負載下的效能。 測試會評估提交至臨界負載時解決方案的存活時間，以及效能等級。

執行的耐久性測試

執行耐久性測試。

錯誤處理概念

錯誤處理是指程式設計、應用程式和通訊錯誤的預期、偵測和解決方式。

處理文檔時出錯

根據錯誤處理概念，詳細說明建議的錯誤處理。

呈報程式

所有呈報程式的定義。 每個專案層級都會有不同的程式：

• 專案團隊
• 客戶
• Adobe

建立定期質量審查會話

與適當的團隊成員定期舉行質量審查會議。

現有權限結構

說明為舊版解決方案或組織內部定義的現有權限和群組集。

現有系統映射

現有系統和從屬關係的圖（或一組圖）。

預期的成功定義與標準

專案發起人會收集與專案成功相關的商業期望。 在項目開始時，必須有一整套期望，因為這些期望應影響整個實施過程中作出的所有決定。

預期可包括：

• 特定KPI，例如所服務頁面的百分比增加
• 發佈內容的時間較短
• 更高級別的目標，例如易於使用的介面

體驗設計需求

對解決方案完整體驗的需求。 這包括個人化、跨裝置永續性和使用者體驗等因素。

體驗規格

體驗設計需求的詳細資訊。

外部系統和用戶依賴／系統上下文

概述解決方案完整生態系統的圖表（或一組圖表）。 這應包括外部整合、介面、相依性和網路等元素。

備援系統和程式

備援系統的定義：

• 業務關鍵功能，在出現嚴重故障時必須保持運行
• 備援時所需的程式

已測試備援系統和過程

備援系統的端對端測試。

從業務利益相關方簽署備援系統

從業務利益相關方處簽署備援系統和相關程式，以確保關鍵業務功能。

KPI的可行性確認

對AEM和高級解決方案設計的可行性研究結果。 應根據KPI來衡量這些指標，以確保這些指標能夠得到滿足。

已完成的合同

在繼續進行項目之前，需要已完成並簽署的合同。 這是基於合同草稿。

利益相關方接受的解決方案功能

確認利益相關方完全接受：

• 解決方案功能
• 解決方案中任何已知問題

上線時間表

下列活動所需的時間表和排程：

• 準備上線
• 實際上線

已定義快樂路徑

快樂路徑是預設藍本，沒有例外或錯誤條件。 它由當一切如預期般進行時執行的活動序列組成。

硬體估計

下列各項的初步估計：

• 基本AEM安裝所需的硬體
• 任何其他需求，以高階解決方案設計為基礎

硬體將可滿足要求

確認所有環境都將有最低要求的硬體。

高級要求

對高級別需求的定義提供了對系統需求的廣義劃分，涵蓋以下方面：

• 業務流程
• 主要系統功能

這些函式的基本細節通常已知，因此本檔案不應是估計。

高級解決方案設計

高階解決方案設計說明將用來開發解決方案的架構。 體系結構圖提供了整個系統的概述，確定了將為產品及其介面開發的主要元件。

高級系統映射

此系統地圖應提供系統的高層圖。 它與「解決方案上下文」不同，它是所有涉及系統的廣義映射，此圖上沒有介面。

歷史內容結構

舊系統的內容結構定義。 這將在準備遷移策略時用於參考。

歷史績效和歷史績效KPI

您需要從舊式系統收集並記錄績效統計資料和績效KPI。 然後，這些參數將用作參考點，並用於對新解決方案進行基準測試。

確定關鍵解決方案／功能

關鍵業務功能的清單。

實施——根據滲透率測試結果進行的變更

根據滲透測試結果，對解決方案實施所有必要的變更（已簽署）。

實施——自動化測試策略

設定支援自動化測試所需的工具和程式。

實施——自動化策略

設定支援自動化所需的工具集和流程。

實施——內容架構

實施內容架構、標籤概念及重複使用內容。

實施——體驗設計

實作支援體驗設計的需求。

實施——備援系統和程式

備援系統及相關程式的實作。

實施——整合

與所有必要外部系統整合的實作。

實施——遷移策略

移轉，並驗證新解決方案的內容和其他工件。

實施——角色和權限

角色和權限、使用者和群組的實作。

實施——安全性概念

實作所有安全性措施，包括AEM預設值。

實施——安全軟體

軟體應用程式安全性的實作。

實施——系統體系結構安全概念

系統安全的實現。

實施- URL處理

URL處理概念的實作。

實施——工作流程

設計工作流程的實作。

實施概念

實施理念為整個實施提供了指導原則。 它應該考慮到：

• 運作
• 維護
• 相容性
• 可重用性
• 安全性
• 可擴充性

此概念也可說明解決方案中使用的架構、程式庫和其他工件。

通知Adobe支援人員上線計畫

請連絡Adobe支援，以確保在上線時可啟用所需的支援。

初始體驗設計

體驗設計的初步概念。

整合測試

測試所有整合（包括內部和外部），以及產生的確認。

這應該是自動的，並經常運行，以確保系統穩定性。

問題追蹤程式

明確的流程記錄了所遇到的所有問題，並跟蹤正在進行的活動，以確保所有問題都得到解決。

問題跟蹤系統和進程

一個跟蹤系統，連同所需的程式，記錄所遇到的所有問題並跟蹤正在進行的活動，以確保所有問題都得到解決。

所有項目利益攸關方都應有權訪問，以便促進項目狀況的透明度。

範例包括Atlassian JIRA和HP Quality Center。

已設定並整合問題跟蹤系統進程

所選工具已完全整合，並授予所有必要角色訪問權限。

舊系統

對於您的專案，舊版系統是現有的技術、電腦系統或應用程式，將會由新解決方案取代。

應收集舊式系統的詳細資訊，以便您知道哪些系統可以退役，何時退役以及對任何其他系統的影響。

要使用的開發工具清單

實施中將使用的工具概要；工具應包括：

• 檔案工具
• 問題追蹤工具
• 部署工具
• 建置工具

需要存取Adobe支援入口網站的使用者清單

需要存取Adobe支援入口網站的所有使用者和角色清單。

該清單通常由解決方案架構師和／或客戶IT人員組成。

日誌檔案分析

分析以及產生的建議，定義需要記錄哪些項目才能監控解決方案：

• 要記錄的活動
• 詳細程度
• 記錄的每個活動的資訊

維護工作（AEM特定）已測試並啟用

測試並啟用AEM維護工作，例如：

• 壓實
• 系統清潔
• 工作流程清除

遷移計畫

記錄移轉；包括

• 移轉時間表
• 內容維護計畫，根據遷移策略

遷移策略

完整說明對應至新解決方案的現有內容、內容架構和格式。 它應涵蓋：

• 自動遷移的技術詳細資訊（如果可能）
• 在移轉後執行煙霧測試，以驗證已移轉的內容

它還建議如何在移轉和新系統實際上線期間，讓內容保持最新（或盡可能保持最新）。 這可能意味著內容凍結、雙重發佈或維護alpha系統。

監視- CPU

監控解決方案對系統CPU的使用：

• 平均
• 峰

監視——磁碟I/O

監控解決方案的磁碟輸入和輸出速率：

• 平均
• 峰

監視——磁碟空間

監控解決方案對磁碟空間的使用：

• 平均
• 隨時間的增長

您應監控使用者：

• 儲存庫
• 日誌檔案

監視——外部系統

監控解決方案與外部系統之間的任何連接：

• 流量率
• 峰
• 穩定性

監控——網路頻寬

監控解決方案對網路頻寬的使用：

• 平均流量
• 峰
• 穩定性

監控——請求

監控對解決方案提出的要求。

監控——安全點

在定義的安全點監控。

監控——系統

監控整個系統；例如：

• 可用性
• 平均效能
• 效能峰值
• 警報

監控——閾值和干預

監控解決方案定義的閾值，並實施干預步驟以減少負載。

監控概念

將監控概念應用到您的解決方案；合併：

• AEM標準監控
• 系統監控
• 客戶特定監控需求

監控潛在弱點

應確定和界定可能容易發生故障的具體點。 還應定義與這些任務相關的任何監視任務。

範例包括（其中包括）:

• 關鍵工作流程
• 事務處理
• 整合點

向系統工程師傳達的監控策略

確保系統工程師和操作人員瞭解並瞭解任何監控策略。

監控報告——就地結構

定義：

• 何時應產生監視報告
• 應將其傳送給

操作任務文檔

記錄了所有操作任務，並定義了其頻率。

操作手冊

手動提供解決方案成功運行和維護所需的所有資訊：

• 所有操作任務
• 關鍵聯繫人
• 部署計畫
• 部署前／部署後檢查清單
• 其他關鍵任務

還應詳細說明下列項目的實施概念：

• 滿足效能KPI
• 擴展解決方案以繼續滿足這些KPI

包已準備

建立並提供的軟體套件可供部署。

滲透測試

滲透測試（非正式稱為筆式測試）是對電腦系統的攻擊，它會尋找安全性弱點，可能會存取電腦的功能和資料。

滲透率測試——通過

會傳遞所有必要的條件。

滲透率測試——結果

為企業建立的報表，說明滲透率測試結果。

效能和可擴充性概念

概念性檔案，說明如何確保您的實作符合效能KPI，以及如何擴充解決方案，以持續符合這些KPI。

效能基準

效能基準用於定義效能測試、耐久性測試和監控。 它通過評估解決方案和系統硬體的效能特性來實現。

績效KPI

這些指標定義了衡量系統效能所需的關鍵績效指標(KPI)。 例如頁面載入時間、伺服器回應時間和資料庫查詢效能。

效能測試——報告

為業務建立的報告，詳述效能測試的結果。

效能測試——結果匹配效能KPI

結果必須符合已定義的KPI和績效預期。

基於角色的測試概念

基於角色的測試是以「體驗設計」中概述的不同角色為基礎的方法。 它也會測試帳戶及其相關權限層級。

這常用於使用者接受測試(UAT)。

POC根據要求文檔進行測試和驗證

概念證明(POC)根據要求進行評估，以確保兩者一致。

部署後檢查清單

一個檢查清單，用來定義每次部署後要執行的一系列檢查和任務。

部署前檢查清單

一個檢查清單，用來定義在每次部署前要執行的一系列檢查和任務。

生產環境基準效能測試

對AEM的標準安裝執行基準測試通常很常見。 然後，這將用作測試實施和硬體的基準。

生產環境就緒

確認生產環境已就緒，並已部署自動化。

企業利益相關方的生產簽名

在「上線」至生產環境之前，必須先授與「生產簽署」(PSO)。 這是對即將投入生產的版本以及任何已知問題的審查的結果。 「上線」排程會提供「登出」。

生產簽出流程和策略

在將套件移至生產環境之前，先取得生產簽名所需的政策和程式。

項目通信計畫

為業務利益相關方和項目團隊定義溝通計畫。

項目工作——最終估計

初始估計數是高水準的，根據執行的高水準要求作出。

現在，對這些項目進行審查、改進和擴大，以提供最終估計。 估計應由每個適當的項目負責人提供，包括項目管理、咨詢、體系結構、測試和開發。

該等估計乃用作資源及預算。

項目工作——初始估計

初步估計是高水準的，根據執行的高水準要求作出。 這將在後期階段進行審查和改進。

項目組織

概述項目和團隊的組織和報告結構所需的文檔。

通常以圖表的形式或包含圖表來呈現時間軸和責任的視覺化概述。 有許多工具可協助您完成這項工作。

項目範圍文檔

項目範圍文檔要求您確定並記錄以下清單：

• 特定專案目標
• 交付項
• 功能
• 函數
• 任務
• 期限
• 計畫的工作

它涵蓋了交付項目必須取得的成果以及必須完成的工作

定義的Cadence中的項目狀態報告

根據商定的時間表和所需格式提供項目狀態報告。

概念證明(POC)

概念證明(POC)為解決方案實施了有限的功能範圍。

該方案應旨在論證其可行性，驗證其能夠達到預期目的，並證明其有應用潛力。

清除規則

AEM維護多個版本的資產和內容。 清除規則的設計和配置是定期刪除舊版本，以維護儲存庫的運行狀況和大小。

品質報表格式與順序

定義品質報表的必要內容和格式，以及必須傳送的頻率。

協調的發行

項目經理負責協調發放到生產環境所需的所有角色。

發行說明

版本注意事項是本版本檔案的一部分。 發行說明應涵蓋：

• 先決條件
• 包含的需求
• 已解決的問題
• 發行中的已知問題

它可與Runbook搭配使用，以執行安裝前和安裝後步驟及檢查。

在生產環境上運行的版本

最終版本正在運行，並在生產中處於活動狀態。

相關合約條款

您應強調與項目實施相關的特定合約條款；例如合約里程碑、發票期間或員工要求。

報告節奏

與客戶一起定義傳送給他們的報表頻率。

儲存庫優化

tar檔案不會覆寫資料，即使僅更新現有資料，磁碟使用量也會增加。

為了抵消儲存庫不斷增大的規模，制定了一種優化策略來刪除過時資料。

要求在Adobe支援入口網站中設定專案區段

在Adobe支援入口網站中設定專案的正式要求。

需求檔案

本組檔案包括功能和非功能需求以及估計的工作。

支援上線的可用資源

確保所有上線所需的角色都配備了人員，而且可用。

風險評估

風險評估由客戶的IT和／或安全部門執行。

它評估項目的技術和業務風險。 解決方案需要進行評估，以確保符合安全策略。

降低風險計畫

風險緩解計畫包括風險評估。 它們共同涵蓋：

• 已識別風險
• 如在實施中出現這些風險，可採取可能的解決方案

ROI預期

定義與解決方案相連的投資回報(ROI)預期。

它們旨在通過界定與估計投資有關的預期收益／利潤，從經濟角度說明解決方案的效率。

角色和權利概念

詳細說明與新應用程式所需角色和訪問權限相關的概念，包括以下內容的高級概述：

• 角色
• 個群組
• 個使用者
• 權限
• 以及使用者管理與布建

角色和權利概念符合安全准則

審查角色和權利概念，以確保符合安全政策。

角色和權限規範

基於角色和權限概念的詳細規範。

安全體系結構建議

與軟體和硬體架構的安全性相關建議。

安全型編碼准則

這些准則定義了如何根據安全性需求(例如：

• 命名約定
• 資料庫
• 框架准則
• API使用

安全檢查清單

根據安全概念以及確保符合解決方案要求的任何其他策略，對項目進行專案檢查清單。

這通常也會包含在操作手冊的部署後步驟中。

安全性概念

定義並記錄應用程式、架構和基礎架構所需安全性組態的詳細資訊。

安全性概念草稿

高級概述，涵蓋以下安全性設定：

• 應用程式
• 架構
• 基礎設施

列出並評估的安全問題

列出並評估解決方案的所有安全問題；包括工作量估計。

來自業務利益相關方的安全簽名

從利益相關方簽署，以確保安全性實作符合政策與期望。

設定支援進程

設定所需的支援流程。

協力廠商系統的SLA

確保服務級別協定(SLA)可供開發和運營團隊在實施和支援期間使用，並與之溝通。

煙霧測試概念

煙霧測試包括一組定義的步驟，這些步驟可測試解決方案的主要功能，以確保解決方案的基本操作和功能。

在安裝或部署後，在任何環境上執行這些動作。

為系統驗證執行的煙霧測試

應在所有系統上運行煙霧測試，以確保解決方案在安裝或部署到任何環境時的基本功能正確運行。

軟體體系結構策略

軟體架構的高層次策略；包括服務、servlet、框架和其他實施決策。

已成立並會見Cadence Set解決方案審查委員會

解決方案審查委員會通常由客戶利益相關方組成。

董事會定期舉行會議，以持續檢討現行規定及相關規格。 目的是確保符合成功定義和標準，並為制定要求提供投入。

解決方案操作手冊

解決方案的安裝說明，以及在安裝時執行的基本操作任務。

解決方案簽署和驗收流程

簽署和接受程式概述了在解決方案發佈到生產環境中之前必須滿足的標準。

它也可以做為合約上的里程碑。

特殊功能概念

AEM平台上任何被視為超出正常開發範圍之特殊功能的初始概念。

特殊功能規格

AEM平台上任何被視為超出正常開發範圍的特殊功能的詳細資訊。

規格指南

客戶關於如何執行規格的任何准則。

已定義並傳達規範審核和批准流程

客戶簽署規格的明確程式應當到位。 此程式可確保要求的範圍清晰和堅定。

為AEM管理員培訓選擇的員工

需要培訓以管理解決方案的內部員工。

為作者和最終用戶培訓選擇的員工

需要培訓才能編寫解決方案的內部人員。

利益相關者

利益相關方是對項目有重大興趣的主要人員及／或角色。 有些人將為項目預算捐款。

利益相關者可以是內部和／或外部。

利益相關方瞭解成功定義和標準

確認實際實施團隊以外的所有利益相關者都瞭解：

• 成功定義
• 成功標準

利益相關者瞭解項目和期望

確認實際實施團隊以外的所有利益相關者都符合整體專案和預期，包括專案團隊內部和客戶。

狀態報告格式定義

狀態報告是溝通的重要工具。 格式應與客戶的任何報告要求一致。

成功標準和定義

客戶、項目贊助商和項目經理或顧問應指定：

• 為項目定義成功結果的因素。
• 符合該成功定義所需的特定條件。

這些用於確保滿足成功標準：

• 作為KPI的基礎。
• 在整個實作中做決策時。

支援驗證已報告的問題

Quality Lead的部分職責是確保在測試時有資源可支援任何使用者。 例如，在測試時協助使用者，在報告問題時協助使用者，並協助根據測試環境驗證問題。

支援程式與Adobe支援入口網站的存取

存取Adobe支援入口網站對於提交有關實施期間可能發生之任何產品問題的票證至關重要。

存取權應分配給團隊的主要成員。

系統體系結構定義

解決方案所有環境體系結構的初步建議和定義。

系統體系結構文檔

詳細描述系統架構的檔案；包括所有環境的介面、網路位置和整合等資訊。

系統體系結構安全概念

概要說明如何使系統體系結構與任何安全策略相容。 這可涵蓋：

• 防火牆和防火牆規則
• 安全區
• 本地和一般流量管理員
• 網路伺服器
• proxy和reverse proxy

已確定並驗證的系統風險因素

在風險評估（或其他審閱）中發現的任何風險因素均予以識別及評估：

• 每一個風險中隱含的風險
• 以及執行中任何需要進行的變更所需的預估努力。

團隊瞭解成功定義和准則

確認整個團隊都瞭解成功定義和准則。

團隊瞭解通信計畫

確認團隊的所有成員都知道應該與客戶進行溝通的人員，以及有關方式和時間的詳細資訊。

團隊瞭解專案和期望

符合整個專案和預期，既包括專案團隊內部，也包括客戶。

技術要求

這些需求是針對支援解決方案之服務的技術實作。

已驗證的技術風險因素

識別並驗證潛在的技術風險。 技術風險可包括：

• 跨網站指令碼
• 最終用戶面向輸入欄位
• 基礎設施
• 技術時代
• 整合數
• 與相依性

技術指標

技術規範涵蓋（其中包括其他資訊）:

• 介面
• 配置
• API
• 支援解決方案需求的服務

模板規範

所需範本的規格。 這些應涵蓋詳細資訊，包括parsys、blueprint和繼承對應等。

規格以業務需求和體驗需求為基礎。

測試案例

測試案例會詳細說明執行解決方案功能測試所需的詳細步驟。

測試內容

測試內容應盡可能接近生產內容。 它必須具備足夠廣泛的選擇範圍，才能測試所有藍本。

測試環境就緒

確保已準備好測試環境，並已部署自動化部署，以確保所有版本候選代碼都是最新的測試代碼。

測試報表

詳細列出測試結果的報告；包括：

• 缺陷
• 已執行的測試案例狀態
• 其他與質量相關的主題

應當指出：

• 任何測試團隊都應能保持中立，並提供測試結果。
• 項目經理有責任評估結果的任何影響並決定採取適當行動。

測試套件

選擇自動化套件和工具。 這些將用於自動化測試，包括使用案例的測試。

已選擇測試工具套件

為使用案例自動化和其他測試執行工作選取的自動化套件和工具。

測試概念

測試概念是項目測試的高層次概要；包括QA、UAT、效能、安全性和整合測試。

測試計畫

這些計畫更詳細地概述了每個開發階段的測試執行情況，並基於測試策略。

測試範圍

這些需求是針對支援解決方案之服務的技術實作。

測試策略

測試策略概述了質量保證和用戶驗收測試的高級策略。 這包括時間軸、報告順序和執行。

協力廠商整合概念

與協力廠商系統整合的架構和系統層級概念。

協力廠商整合規格

協力廠商系統支援功能與整合的需求（功能與非功能）詳細資訊。

協力廠商安全性概念

確保任何第三方整合安全性的概念。 必須符合適當的安全性原則。

協力廠商整合系統

確保所有協力廠商系統都可供使用，並提供適當的檔案，以進行整合實作。

協力廠商系統存取已啟用

授予與第三方系統一起使用之各角色的必要存取權。

第三方測試概念

定義：

• 測試整合的使用案例
• 與任何第三方應用程式相關的功能

閾值定義

定義系統中監控點的關鍵值。

例如：

• 有多少KB(KB)未發送日誌在主伺服器實例上生成警告
• 在主伺服器上生成警告之前，每個事務的平均延遲的毫秒數

時間軸和里程碑

這應該定義項目時間表和用於以下項目的合同里程碑：

• 開立發票。
• 與成功定義、成功標準和KPI對齊。

項目工作總額

所有努力估計，應當從項目上的每個線索中加以匯總；包括開銷、開發、系統工程、建築和測試工作。

如果協定中包括支助級別，也應包括支助和業務工作。

訓練教材

用於培訓課程的教材。 資料應專為解決方案建立，並與使用指南搭配使用。

瞭解項目範圍和期望

適當的角色應該能夠確認他們完全理解：

• 項目範圍
• 所有客戶期望
• 這是項目中每個階段根據個人做出的所有決定的基礎

URL處理概念

您的URL處理概念應涵蓋AEM特定URL功能，包括：

• 虛名URL
• 連結外部化
• 錯誤頁面
• 映射

該概念還應涵蓋：

• 任何重寫規則
• Web伺服器上的虛擬主機
• SEO考量事項，例如robots.txt
• 網站地圖

使用案例

使用案例是達到目標所需動作或事件步驟的清單。 通常，它們會定義角色與解決方案之間的互動。 角色可以是用戶或外部系統。

轉換為測試藍本的使用案例

測試藍本是以技術和商業使用案例為基礎。 他們用來測試解決方案的行為是否如預期。

使用手冊

使用者指南為解決方案的使用者提供資訊與協助：

• 作者
• 用戶
• 管理員

已驗證預算計畫

預算計畫必須由所有利益攸關方審查和驗證。 他們需要檢查詳細資訊，例如開立發票、金額和預算報告的方法／時間。

白盒測試結果

白色方塊測試是測試應用程式內部結構或運作方式的方法，而非其功能。 白盒測試可以應用於軟體測試過程的單元、整合和系統級。

工作流規範

這些規格應根據「工作流概念」詳細定義建立完整工作流的步驟。

每個工作流的規範應包括（至少）:

• 使用案例
• 角色
• 步驟
• 成果
• 錯誤處理

工作流程概念

工作流程可讓您自動化AEM活動。 Workflows Concept概述：

• 需要自動化的流程
• AEM中將受影響的服務和角色