字彙表

此辭匯表列出了項目清單中所有可交付項文檔的詳細資訊。

業務利益相關方的接受

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

接受測試

當應用程式準備好投入生產時，會執行驗收測試。 這些測試由代表各種類型的最終用戶的組執行，使用真實情況。

接受測試用於確認：

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

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

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

訪問協調的測試系統

確保將所需的系統訪問級別授予所有角色。

Adobe安全性檢查清單

Adobe安全性檢查清單是為確保AEM在安裝時安全而提供的官方檢查清單。 它包含您執行以確保執行個體完整性所需的安全措施和驗證步驟。

Adobe支援門戶項目設定

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

可以註冊詳細資訊；例如，關於實作的技術和版本。 這為客戶和Adobe提供了透明度。

AEM管理員培訓

為解決方案的行政人員提供培訓。 如需詳細資訊，請參閱Adobe培訓服務 。

AEM作者訓練

為將為解決方案製作（製作）內容的員工提供培訓。 如需詳細資訊，請參閱Adobe培訓服務 。

AEM認證考試

確保註冊相應角色以參加相關的認證考試。

AEM認證

確保適當角色通過相關的認證考試。

AEM技術培訓

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

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

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

協調業務和效能KPI

協調您的業務和績效關鍵績效指標(KPI)有助於將組織內所有相關人員和流程集中起來。 這反過來又有助於減少實現業務目標和實現擬議目標所需的時間和精力。

內容架構與KPI的協調

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

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

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

應用程式體系結構定義

應用程式架構應明確定義建議應用程式的行為。

重點在於：

• 他們如何彼此互動以及與使用者互動。
• 應用程式使用和生成的資料，而不是其內部結構。

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

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

受過適當培訓的工作人員

確保您的團隊由員工組成，並接受適當的培訓。 若為專案團隊，建議您具備下列所有條件：

• 至少一個AEM認證的主要開發人員

• 至少一個AEM認證架構師

• 至少75%的開發人員獲得AEM認證；

  這可讓經過認證的開發人員指導初級開發人員，並確保知識共用和透明

架構圖

架構圖是架構的圖形表示。 包括：

• 概念
• 他們的原則
• 屬於架構一部分的元素和元件

架構草稿

這可提供系統和解決方案架構的概觀。 在現階段，將在以後階段審查和完善這一草案。

架構審核板簽收

架構審核委員會是一個跨組織機構，它可：

• 監督一項連貫戰略的實施
• 確保系統符合性

審查委員會應代表與該架構有關的所有主要利益攸關方。 通常，他們將由一組負責審查和維護總體架構的高管組成。

與KPI相比，適合實際內容和結果的自動測試套裝

自動化指令碼和基本的自動化使用案例：

• 適合生產內容
• 根據KPI檢查

自動測試策略

此策略定義了可重複使用的自動化指令碼的框架，以及品質保證(QA)團隊規劃的方法。 它概述了自動化測試的總體計畫，以幫助確保：

• 投資報酬率(ROI)
• 更多測試覆蓋
• 提高了質量重複性的測試可靠性

自動測試策略已針對實際和預期負載進行驗證

必鬚根據解決方案上的內容和預期負載來驗證和調整自動測試策略。

自動化策略

部署的自動化可確保部署更快且一致。 《自動化戰略》概述了任何此類自動化機制的配置；包括：

• 頻率
• 要使用的工具
• 要部署到

了解通信計畫

整個項目團隊和所有利益相關方必須確認他們了解：

• 報告結構
• 報告順序
• 通信渠道

了解成功定義和條件

整個項目團隊和所有利益相關方必須確認他們了解：

• 成功定義
• 成功標準

備份和恢復概念

「備份和還原概念」概述了將在解決方案中實施的技術功能。 公司備份和還原策略需要此策略。

已測試的備份和恢復

基於備份和還原概念的完整端到端測試。

業務案例

業務案例文檔介紹了與採取行動、採取替代行動（如果可用）或不採取任何行動相關的論點。 辯論應根據具體事實（盡可能/相關）進行平衡，並強調所有案件的好處和風險。

商業案例檔案應是所有選擇的明確定義，最後應有令人信服的理由來實施擬議的解決方案。

業務分析師了解項目範圍和期望

業務分析人員應確認他們完全了解：

• 項目範圍
• 所有客戶期望
• 這是項目各階段按個人作出的所有決定的基礎

業務KPI

組織使用關鍵績效指標(KPI)來評估其達到目標時的成功。

業務KPI定義可衡量的價值，以展示公司如何有效地實現關鍵業務目標。 請務必以清楚的定義選擇適合您的業務/情境的KPI，以判斷KPI是什麼、如何衡量、如何使用以及由誰使用。

業務要求文檔

業務需求檔案(BRD)詳細說明了項目的業務解決方案，為客戶的業務需求和期望提供了明確的規格說明。 BRD也區分商業解決方案與技術解決方案。

在審查商業解決方案時，BRD應該回答以下問題：「企業想做什麼？」

對已識別並與ROI和KPI預期相協調的解決方案或體系結構進行任何必要調整後進行業務簽核

風險評估和滲透測試過程可能產生需要在解決方案的架構或開發中處理的問題和結果。

由這些流程產生的任何調整都需要由企業審查和批准，並根據總體目標進行評估。

快取策略

快取策略概述將快取給一般使用者的內容。 它必須符合效能KPI。

例如，可快取影像、javascript和其他伺服器檔案等元素，以改善解決方案的效能。

編碼指南

編碼准則定義了開發人員在開發解決方案時應遵循的基本原則。 其中包括：

• 命名慣例
• 服務使用
• 程式庫使用狀況

通信操作手冊

確保所有適當的角色/角色都收到《操作手冊》。

通信效能測試報告

請確定所有適當的角色/角色均已收到效能測試報告。

溝通發行說明

確認所有適當的角色/角色皆已收到發行說明。

向團隊傳達範圍和期望

確保項目團隊充分了解並符合項目範圍和交付期望。

傳達培訓資料和使用手冊

確保所有適當的角色/角色都獲得培訓材料和使用手冊。

遵守客戶安全要求

確保客戶的所有安全要求都到位。

符合安全概念

確保安全概念已就緒。

元件和模板關係概念

將用於新應用程式的模板和元件的大綱。 包括繼承規則、權限和關係等詳細資訊。

元件和模板關係規範

元件和範本關係概念的詳細資訊。

元件規範

要實施的每個元件的規格詳細資訊。

外部介面模型的概念

如何針對開發或測試環境可能無法開啟/使用的任何外部介面進行開發和測試的概念。

規劃/實作這些介面的模型，以確保測試盡可能接近生產型行為。

內容體系結構文檔

建議內容架構的檔案。 詳情應包括（其中包括）:

• 內容樹
• 標籤概念
• 重複使用內容的策略

已驗證遷移的內容

會審查舊版系統內容，並驗證所選內容以便遷移到新解決方案。

合同草稿

法律合同的初稿。

當前內容結構和格式

目前內容架構和格式的檔案。 這將用於產生未來的內容架構。 此外也會用於移轉概念。

客戶備份和還原策略

客戶的政策：

• 資料和解決方案的備份過程
• 備份的儲存
• 確認備份正如預期運行
• 恢復，如果失敗

客戶編碼指南

客戶關於如何開發的任何准則/需求。

客戶部署/發行策略

客戶提供的原則，定義部署/發行的方式和時機。

這些通常包括時間表、排程和簽核要求。

客戶監控策略或要求

客戶應監控的政策和要求。 這些是「監控概念」中指定的任何建議之外。

客戶生產發行計畫

由客戶定義的發行至生產環境的排程。

客戶報告策略和要求

客戶在報告方面的任何政策和/或要求。 這些包括：

• 特定報表的傳送頻率
• 特定報表的格式
• 特殊要求

客戶路線圖

制定技術和業務上要實施的主要里程碑的路線圖。 然後，此路線圖將傳達給客戶。

客戶安全策略

客戶（業務和IT）將制定策略來定義解決方案所需的安全級別。 這些包括：

• 通過風險評估的要求。
• 透過測試的要求。
• 任何特定的安全要求；例如，逸出所有輸入欄位、加密使用(SSL)、憑證，以及驗證和工作階段。

客戶規範指南

客戶有關規格格式、交付和簽核的任何准則。

客戶測試報表

在用戶接受測試(UAT)期間從客戶報告到質量銷售線索。

影響升級的自定義和Hotfix已記錄

所套用的任何自訂和/或套用的Hotfix都必須記錄下來，因為它們可能會影響未來的升級：

• AEM可大量自訂以符合業務需求。 任何可能影響升級的自定義必須完整記錄。 例如，對AEM的使用者介面(UI)進行任何重大變更。

• 必須完整記錄當前解決方案所需的任何更新；這些包括：

  • cumulative fix pack(CFP)
  • 服務包(SP)
  • hotfix
  • 升級

每日用戶接受測試報告

由使用者接受測試(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 standard監視
• 系統監控
• 客戶特定監控需求

監控潛在弱點

應確定和定義可能發生故障的特定點。 也應定義與這些相關的任何監控任務。

範例包括（其中包括）:

• 關鍵工作流程
• 交易處理
• 整合點

通知系統工程師的監控策略

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

監控報表 — 就地結構

定義：

• 何時應產生監控報表
• 他們應該送給誰

操作任務文檔

所有操作任務都記錄在案，其頻率已定義。

操作手冊

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

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

也應詳細說明下列項目的實作概念：

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

已準備包

已構建並交付的軟體包，可供部署。

滲透測試

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

滲透測試 — 通過

會傳遞所有必要條件。

滲透測試 — 結果

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

效能和可擴充性概念

關於如何確保實作符合效能KPI，以及如何調整解決方案規模，使其持續符合這些KPI的概念檔案。

效能基準

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

效能KPI

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

效能測試 — 報告

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

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

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

基於角色的測試概念

以人設為基礎的測試是以Experience Designs中概述的不同角色為基礎的方法。 它也會測試帳戶及其相關權限層級。

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

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

概念驗證(POC)根據要求進行測量，以確保兩者保持一致。

部署後檢查清單

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

部署前檢查清單

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

生產環境基準效能測試

通常在標準安裝AEM上執行基線測試。 然後，這會作為測試實作和硬體的基準。

生產環境就緒

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

從業務利益相關方簽發生產簽字

上線至生產環境之前，必須授予生產簽核(PSO)。 這是將投入生產的版本審查結果，以及任何已知問題。 「上線」排程會提供「註銷」功能。

生產簽核流程和策略

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

項目通信計畫

為業務利害關係人和項目團隊定義溝通計畫。

項目工作 — 最終估計

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

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

這些估計數用於資源籌措和預算編製。

項目工作 — 初始估計

初步估計數是高水準的，是根據執行方面的高水準要求作出的。 將在後期審查和完善這一機制。

項目組織

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

通常會以圖表的形式或包含，以呈現時間表和責任的視覺概覽。 有許多工具可協助您完成此作業。

項目範圍文檔

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

• 特定專案目標
• 交付件
• 功能
• 函數
• 任務
• 截止日期
• 計畫工作

它涵蓋了交付項目必須達到的目標以及必須完成的工作

定義順序中的項目狀態報告

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

概念證明(POC)

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

它應旨在演示該解決方案的可行性，驗證其能夠滿足所需目的，並證明其有可能被使用。

清除規則

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

品質報表格式和順序

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

已協調釋放

專案管理員負責協調發行至生產環境所需的所有角色。

發行說明

發行說明是此版本檔案的一部分。 發行說明應涵蓋：

• 必要條件
• 包括的需求
• 已解決的問題
• 發行中的已知問題

它與Runbook一起使用，以執行安裝前和安裝後步驟和檢查。

在生產環境上運行的版本

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

相關合同條款

您應強調與實施項目相關的具體合同條款；例如合同里程碑、發票期或工作人員要求。

報表順序

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

儲存庫優化

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

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

請求在Adobe支援門戶中設定項目部分

在Adobe支援入口網站中設定專案的官方請求。

要求檔案

這套檔案包括功能和非功能需求，以及估計的工作。

可用於支援上線的資源

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

風險評估

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

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

風險緩解計畫

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

• 已識別風險
• 在實施中出現這些風險的可能解決辦法

ROI預期

定義附加至解決方案的投資回報(ROI)預期。

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

角色和權限概念

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

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

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

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

角色和權限規範

基於角色和權限概念的詳細說明。

安全體系結構Recommendations

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

基於安全性的編碼指南

這些准則根據安全性需求(例如：

• 命名慣例
• 資料庫
• 框架指南
• API使用情況

安全檢查清單

項目特定項目清單，基於安全概念，以及確保符合解決方案要求的任何其他策略。

這通常也包括在Runbook中部署後步驟中。

安全概念

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

安全概念草稿

涵蓋以下安全設定的高級大綱：

• 應用程式
• 架構
• 基礎結構

列出並評估的安全問題

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

從業務利益相關方簽發安全簽名

從利益相關方簽收，以確保安全性實施符合政策和期望。

設定支援流程

設定所需的支援流程。

第三方系統的SLA

確保服務級別協定(SLA)可用並傳達給開發和運營團隊，以便在實施和支援期間使用。

煙霧測試概念

煙霧測試由一組定義的步驟組成，這些步驟可測試解決方案的關鍵功能，以確保解決方案的基本操作和功能。

在安裝或部署後，會在任何環境上執行。

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

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

軟體體系結構策略

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

已建立解決方案審查委員會並會議規則集

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

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

解決方案Runbook

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

解決方案簽核和驗收流程

簽核和接受程式概述了必須滿足的標準，才能將解決方案發佈到生產環境中。

它也可作為合約里程碑。

特殊功能概念

任何特殊功能的初始概念，在AEM平台上的正常開發範圍之外。

特殊功能規範

任何特殊功能的詳細資訊，這些功能被視為不在AEM平台正常開發範圍之內。

規範指南

客戶關於如何進行規範的任何指導。

定義並傳遞規範審核和審批流程

應為客戶簽署規格制定明確的流程。 這一過程確保了要求的明確性和牢固性。

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

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

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

需要培訓的內部員工，以編寫解決方案。

利害關係人

利益相關方是對項目有重大利益的關鍵人士和/或角色。 有些將為項目預算捐款。

利益相關方可以是內部和/或外部。

利害關係人了解成功定義和標準

確認實際實施團隊以外的所有利害關係人都了解：

• 成功定義
• 成功標準

利益相關方了解項目和期望

確認實際實施團隊以外的所有利害關係人，無論是在專案團隊內部還是在客戶內部，都符合整體專案和期望。

狀態報表格式定義

狀態報告是溝通的關鍵工具。 格式應與客戶的任何報表需求一致。

成功標準和定義

客戶、項目發起人、項目經理或顧問應當指定：

• 為項目定義成功結果的內容。
• 符合成功定義所需的特定條件。

這些用於確保符合成功標準：

• 作為KPI的基礎。
• 在實施期間進行決策時。

支援驗證回報的問題

Quality Lead的部分職責是確保有可用資源支援任何用戶進行測試。 例如，協助使用者進行測試時、回報問題時，以及協助根據測試環境驗證問題。

支援流程和Adobe支援門戶的訪問

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

應將存取權分配給團隊的關鍵成員。

系統體系結構定義

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

系統體系結構文檔

詳細說明系統架構的文檔；包括所有環境的介面、網路位置和整合，以及其他資訊。

系統體系結構安全概念

概述如何使系統體系結構符合任何安全策略。 這可涵蓋：

• 防火牆和防火牆規則
• 安全區
• 當地及一般流量管理員
• 網站伺服器
• 代理與反向代理

已識別並驗證系統風險因素

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

• 每一項中隱含的風險水準
• 加上針對實施所需的任何變更，預估的投入。

團隊了解成功定義和條件

確認整個團隊都了解成功定義和條件。

團隊了解通信計畫

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

團隊了解項目和期望

符合整體專案和期望，包括專案團隊內部和客戶內部。

技術要求

這些要求特定於支援該解決方案的服務的技術實施。

驗證的技術風險因素

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

• 跨網站指令碼
• 最終用戶面對輸入欄位
• 基礎結構
• 技術時代
• 整合數
• 和相依性

技術規範

《技術規範》包括（其中包括資訊）:

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

模板規範

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

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

測試案例

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

測試內容

測試內容應盡可能接近生產內容。 它的選擇範圍必須足夠廣，以允許測試所有情況。

測試環境就緒

確保測試環境已就緒，並部署自動化部署，以確保所有發行候選程式碼都為測試的最新版本。

測試報表

詳細說明測試結果的報告；包括：

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

應當指出：

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

測試套裝

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

已選擇測試工具套裝

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

測試概念

「測試概念」是項目測試的非常高級的概要；包括QA、UAT、效能、安全性和整合測試。

測試計畫

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

測試範圍

這些要求特定於支援該解決方案的服務的技術實施。

測試策略

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

第三方整合概念

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

第三方整合規範

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

第三方安全概念

確保任何協力廠商整合安全性的概念。 必須符合適當的安全策略。

整合的第三方系統

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

已啟用第三方系統訪問

授予與協力廠商系統一起使用之個別角色的必要存取權限。

第三方測試概念

定義：

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

閾值定義

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

例如：

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

時間軸和里程碑

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

• 開具發票。
• 與成功定義、成功標準和KPI保持一致。

項目工作總數

應綜合從項目的每個領導中得出的所有努力估計；包括開銷、開發、系統工程、架構和測試工作。

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

培訓材料

用於培訓課程的材料。 材料應專為解決方案建立，並設計為與使用手冊搭配使用。

了解項目範圍和期望

適當的角色應確認他們完全了解：

• 項目範圍
• 所有客戶期望
• 這是項目各階段按個人作出的所有決定的基礎

URL處理概念

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

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

該概念還應包括：

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

使用案例

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

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

測試案例以技術和業務使用案例為基礎。 它們用來測試解決方案行為是否如預期般運作。

使用手冊

使用手冊為解決方案的使用者提供資訊和協助：

• 作者
• 高級用戶
• 管理員

已驗證的預算計畫

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

白盒測試結果

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

工作流規範

這些規範應根據工作流程概念詳細定義將建立完整工作流程的步驟。

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

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

工作流程概念

工作流程可讓您自動執行AEM活動。 工作流程概念概述：

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