字彙表 glossary

此辭匯表列出（可分享） 專案檢查清單.

業務利害關係人的接受 acceptance-from-business-stakeholders

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

接受測試 acceptance-tests

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

接受測試用於確認：

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

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

協調訪問測試系統 access-to-test-system-coordinated

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

Adobe安全性檢查清單 adobe-security-checklist

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

Adobe支援門戶項目設定 adobe-support-portal-project-set-up

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

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

AEM管理員培訓 aem-administrator-training

為解決方案的行政人員提供培訓。 請參閱 Adobe培訓服務 以取得更多資訊。

AEM作者訓練 aem-author-training

為將為解決方案製作（製作）內容的員工提供培訓。 請參閱 Adobe培訓服務 以取得更多資訊。

AEM認證考試 aem-certification-exam

確保註冊適當人員以取得相關 認證考試.

AEM認證 aem-certified

確保適當角色已通過相關 認證考試.

AEM技術培訓 aem-technical-training

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

關於定義為專案目標的KPI的協定 agreement-on-kpis-defined-as-goals-for-the-project

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

協調業務和效能KPI align-business-and-performance-kpis

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

內容架構與KPI的協調 alignment-of-content-architecture-with-kpis

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

使客戶路線圖與項目時間表保持一致 alignment-of-the-customer-roadmap-with-project-timeline

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

應用程式體系結構定義 application-architecture-definition

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

重點在於：

已定義應用程式特定維護任務 application-specific-maintenance-tasks-defined

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

經過適當培訓的工作人員 appropriately-trained-staff

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

架構圖 architecture-diagram

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

架構草稿 architecture-draft

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

架構審核板簽核 architecture-review-board-sign-off

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

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

與KPI相比，適合實際內容和結果的自動化測試套裝 automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

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

自動化測試策略 automated-testing-strategy

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

自動測試策略針對真實和預期負載而驗證 automated-testing-strategy-validated-against-realistic-and-expected-load

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

自動化策略 automation-strategy

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

了解通信計畫 aware-of-communication-plan

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

了解成功定義和條件 aware-of-success-definitions-and-criteria

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

備份和恢復概念 backup-and-restore-concept

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

已測試備份和還原 backup-and-restore-tested

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

業務案例 business-case-s

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

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

業務分析師了解項目範圍和期望 business-analyst-understands-scope-of-project-and-expectations

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

業務KPI business-kpis

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

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

業務需求檔案 business-requirements-documentation

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

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

對已識別並符合ROI和KPI期望的解決方案或體系結構進行任何必要調整後，獲得業務批准 business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

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

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

快取策略 caching-strategy

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

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

編碼准則 coding-guidelines

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

《通信操作手冊》 communicate-operations-manual

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

通信效能測試報告 communicate-performance-test-report

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

傳達發行說明 communicate-release-notes

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

向團隊傳達範圍和期望 communicate-scope-and-expectations-to-team

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

傳達培訓材料和使用手冊 communicate-training-materials-and-user-guides

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

遵守客戶安全要求 compliance-with-customer-security-requirements

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

遵守安全概念 compliance-with-security-concept

確保安全概念已就緒。

元件和模板關係概念 components-and-templates-relationship-concept

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

元件和模板關係規範 components-and-templates-relationship-specification

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

元件規格 components-specification

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

外部介面模型的概念 concept-for-mock-ups-of-external-interfaces

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

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

內容架構檔案 content-architecture-document

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

經過驗證的遷移內容 content-validated-for-migration

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

合同草稿 contract-draft

法律合同的初稿。

目前的內容結構和格式 current-content-structure-and-format

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

客戶備份和還原策略 customer-backup-and-restore-policy

客戶的政策：

客戶編碼准則 customer-coding-guidelines

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

客戶部署/發行原則 customer-deployment-release-policies

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

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

客戶監控政策或要求 customer-monitoring-policies-or-requirements

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

客戶生產發行排程 customer-production-release-schedule

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

客戶報告政策和要求 customer-reporting-policies-and-requirements

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

客戶藍圖 customer-roadmap

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

客戶安全性原則 customer-security-policies

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

客戶規格指南 customer-specification-guidelines

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

客戶測試報表 customer-test-reports

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

影響升級的自訂和Hotfix已記錄 customizations-and-hotfixes-that-affect-upgrades-documented

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

每日使用者接受測試報表 daily-user-acceptance-test-report

由使用者接受測試(UAT)產生的報表或會議。 他們應詳細說明：

已啟用預設安全性 default-security-enabled

請確定已啟用/實作AEM的預設安全性設定。

部署/發行策略和流程 deployment-release-policies-and-processes

涵蓋項目部署和發行的正式化策略。 這些包括：

已建立部署順序 deployment-cadence-established

定義各環境間部署的必要頻率。

開發方法 development-methodology

軟體開發方法涉及將軟體開發工作的整個過程分解為不同的階段（或階段），每個階段都有不同的活動。 目標是改進規劃和管理。

在定義方法時，您應預先定義項目團隊建立和完成的特定交付件和對象，以開發或維護您的應用程式。

開發角色定義 development-role-definition

定義在解決方案內執行IT（效能或其他）和/或單元測試的開發人員和/或角色。

開發環境就緒 development-environment-ready

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

開發團隊了解項目範圍和期望 development-team-understands-scope-of-project-and-expectations

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

對話框規範 dialogs-specification

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

文檔開發環境設定 document-development-environment-setup

開發環境的檔案。

記錄生產環境設定 document-production-environment-setup

生產環境檔案。

文檔測試環境設定 document-test-environment-setup

測試環境的檔案。

耐久性測試 durability-test

耐久性測試顯示解決方案在特定負載下的效能。 測試會衡量提交到臨界負載時，解決方案的存留時間，以及效能等級。

已執行耐用性測試 durability-test-executed

執行耐久性測試。

錯誤處理概念 error-handling-concept

錯誤處理是指程式設計、應用和通信錯誤的預測、檢測和解決。

錯誤處理檔案 error-handling-documentation

基於錯誤處理概念的建議錯誤處理的詳細文檔。

呈報流程 escalation-processes

所有升級流程的定義。 每個專案層級會有不同的程式：

建立定期質量審查會議 establish-regular-quality-review-sessions

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

現有權限結構 existing-permissions-structure

針對舊版解決方案或組織內定義的現有權限集和群組檔案。

現有系統圖 existing-systems-map

現有系統和依賴項的圖（或一組圖）。

預期成功定義和條件 expected-success-definitions-and-criteria

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

期望包括：

Experience Designs需求 experience-designs-requirements

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

體驗規格 experience-specifications

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

外部系統和用戶依賴項/系統上下文 external-system-and-user-dependencies-system-context

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

備援系統和程式 fallback-system-and-procedure

後援系統的定義：

後援系統和過程已測試 fallback-system-and-procedure-tested

備援系統的端對端測試。

從業務利害關係人處簽發備援系統 fallback-system-sign-off-from-business-stakeholders

請業務利害關係人簽核，備援系統和相關程式將確保關鍵業務功能。

關於KPI的可行性確認 feasibility-confirmation-on-kpis

對AEM和高級解決方案設計進行可行性研究的結果。 這些量度應根據KPI來測量，以確保符合這些量度。

已完成的合同 finalized-contract

在繼續執行項目之前，需要最後確定並簽署合同。 這是以 合同草稿.

利益相關方接受的解決方案的功能 functionality-of-the-solution-accepted-by-stakeholders

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

上線時間表 go-live-schedule

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

定義的快樂路徑 happy-paths-defined

快樂路徑是預設案例，沒有例外或錯誤條件。 它包含當一切如預期般運作時執行的活動順序。

硬體估計 hardware-estimates

以下各項初步估計：

硬體將可滿足要求 hardware-will-be-available-to-fulfill-requirements

確認所有環境都具備所需的最低硬體。

高級要求 high-level-requirements

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

這些函式的基本詳細資訊通常為已知，因此本檔案不應是預估值。

高級解決方案設計 high-level-solution-design

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

高級系統圖 high-level-system-map

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

歷史內容結構 historical-content-structure

舊版系統的內容結構的定義。 這可供參考，也可供準備移轉策略時參考。

歷史績效與歷史績效KPI historical-performance-and-historical-performance-kpis

您需要從舊版系統收集並記錄效能統計資料和效能KPI。 然後，這些資料會作為參考點，並用於為新解決方案設定基準。

識別關鍵關鍵解決方案/功能 identify-critical-key-solutions-functionalities

關鍵業務功能的清單。

實作 — 根據滲透測試結果進行的變更 implementation-changes-based-on-penetration-test-results

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

實作 — 自動化測試策略 implementation-automated-testing-strategy

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

實作 — 自動化策略 implementation-automation-strategy

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

實作 — 內容架構 implementation-content-architecture

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

實作 — 體驗設計 implementation-experience-design

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

實作 — 備援系統和程式 implementation-fallback-system-and-procedures

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

實作 — 整合 implementation-integration

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

實作 — 移轉策略 implementation-migration-strategy

移轉，以及驗證新解決方案的內容和其他成品。

實作 — 角色和權限 implementation-roles-and-rights

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

實作 — 安全性概念 implementation-security-concept

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

實施 — 安全軟體 implementation-security-software

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

實作 — 系統架構安全性概念 implementation-system-architecture-security-concept

系統安全的實現。

實作 — URL處理 implementation-url-handling

URL處理概念的實作。

實作 — 工作流程 implementation-workflows

實作設計的工作流程。

實作概念 implementation-concept

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

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

通知Adobe支援「上線」排程 inform-adobe-support-about-the-go-live-schedule

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

初始體驗設計 initial-experience-designs

體驗設計的初步概念。

整合測試 integration-testing

測試所有內部和外部整合，以及隨後的確認。

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

問題追蹤程式 issue-tracking-process

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

問題追蹤系統和程式 issue-tracking-system-and-processes

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

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

例如Atlassian JIRA和HP Quality Center。

已設定並整合問題追蹤系統程式 issue-tracking-system-process-is-set-up-and-integrated

所選工具已完全整合，且可授予所有必要角色的存取權。

舊系統 legacy-system

對於您的項目，舊系統是將由新解決方案替換的現有技術、電腦系統或應用程式。

應收集舊式系統的詳細資訊，以便您知道可以淘汰的內容、停用的時間，以及對任何其他系統的影響。

要使用的開發工具清單 list-of-development-tools-to-be-used

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

需要訪問Adobe支援門戶的用戶清單 list-of-users-that-require-access-to-adobe-support-portal

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

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

記錄檔分析 log-file-analysis

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

維護任務(AEM特定)已測試並啟用 maintenance-tasks-aem-specific-tested-and-enabled

測試並啟用AEM維護任務，例如：

遷移計畫 migration-plan

記錄移轉；包括

移轉策略 migration-strategy

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

此外，建議如何在移轉和新系統實際上線期間，讓內容保持最新（或盡可能保持最新）。 這可能表示內容凍結、雙重發佈或維護Alpha系統。

監視 — CPU monitoring-cpu

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

監視 — 磁碟I/O monitoring-disk-i-o

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

監視 — 磁碟空間 monitoring-disk-space

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

您應監控使用方式：

監控 — 外部系統 monitoring-external-system-s

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

監控 — 網路頻寬 monitoring-network-bandwidth

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

監控 — 請求 monitoring-requests

監控向解決方案提出的請求。

監控 — 安全點 monitoring-security-points

在定義的安全點進行監視。

監控 — 系統 monitoring-system

監控整個系統；例如：

監控 — 閾值和干預 monitoring-threshold-and-intervention

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

監控概念 monitoring-concept

要套用至解決方案的監控概念；併入：

監控潛在弱點 monitoring-potential-weak-points

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

範例包括（其中包括）:

向系統工程師傳達的監控策略 monitoring-policy-communicated-to-system-engineer

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

監控報表 — 現有結構 monitoring-reports-structure-in-place

定義：

操作任務文檔 operational-tasks-documentation

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

操作手冊 operations-manual

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

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

準備包 package-prepared

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

滲透測試 penetration-tests

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

滲透測試 — 通過 penetration-tests-passed

會傳遞所有必要條件。

滲透測試 — 結果 penetration-tests-results

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

效能和可擴充性概念 performance-and-scalability-concept

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

效能基準 performance-benchmark

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

效能KPI performance-kpis

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

效能測試 — 報告 performance-tests-report

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

效能測試 — 結果符合效能KPI performance-tests-results-match-performance-kpis

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

基於角色的測試概念 persona-based-testing-concept

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

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

POC根據要求文檔測試和驗證 poc-tested-and-verified-against-requirement-documentation

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

部署後檢查清單 post-deployment-checklist

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

部署前檢查清單 pre-deployment-checklist

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

生產環境基準效能測試 production-environment-baseline-performance-tests

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

生產環境就緒 production-environment-ready

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

從業務利害關係人處簽發生產 production-sign-off-from-business-stakeholders

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

生產簽核流程和政策 production-sign-off-process-and-policy

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

項目通信計畫 project-communication-plan

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

項目工作 — 最終估計 project-efforts-final-estimates

此 初始估計 是高水準的，根據執行的高水準要求而定。

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

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

項目工作 — 初步估計 project-efforts-initial-estimates

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

專案組織 project-organization

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

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

項目範圍文檔 project-scope-document

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

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

定義順序中的專案狀態報表 project-status-reports-within-a-defined-cadence

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

概念驗證(POC) proof-of-concept-poc

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

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

清除規則 purge-rules

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

品質報表格式和順序 quality-report-format-and-cadence

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

協調發行 release-coordinated

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

發行說明 release-notes

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

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

在生產環境中執行的版本 release-running-on-production-environment

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

相關合同條款 relevant-contract-terms

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

報表順序 reporting-cadence

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

存放庫最佳化 repository-optimization

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

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

要求在Adobe支援入口網站中設定專案區段 request-for-setting-up-project-section-in-adobe-support-portal

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

需求檔案 requirements-documentation

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

可用於支援上線的資源 resources-available-to-support-go-live

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

風險評估 risk-assessment

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

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

風險緩解計畫 risk-mitigation-plan

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

ROI期望 roi-expectations

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

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

角色與權限概念 roles-and-rights-concept

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

角色與權限概念符合安全性准則 roles-and-rights-concept-meets-security-guidelines

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

角色和權限規範 roles-and-rights-specification

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

安全架構Recommendations security-architecture-recommendations

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

基於安全性的編碼指南 security-based-coding-guidelines

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

安全性檢查清單 security-checklist

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

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

安全性概念 security-concept

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

安全概念草案 security-concept-draft

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

列出和評估的安全問題 security-issues-listed-and-assessed

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

業務利益相關方的安全簽核 security-sign-off-from-business-stakeholders

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

設定支援流程 set-up-support-processes

設定所需的支援流程。

適用於協力廠商系統的SLA slas-for-third-party-systems

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

煙霧測試概念 smoke-test-concept

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

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

為系統驗證而執行的煙霧測試 smoke-tests-executed-for-system-validation

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

軟體體系結構策略 software-architecture-strategy

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

已建立解決方案審查委員會並會議會議紀要 solution-review-board-established-and-meeting-cadence-set

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

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

解決方案Runbook solution-runbook

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

解決方案簽核和接受流程 solution-sign-off-and-acceptance-process

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

它也可作為合約里程碑。

特殊功能概念 special-functionality-concept

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

特殊功能規範 special-functionality-specification

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

規格指南 specification-guidelines

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

定義並傳遞規範審核和審批流程 specification-review-and-approval-process-defined-and-communicated

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

為AEM管理員培訓選擇的員工 staff-selected-for-aem-administrator-training

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

為作者和最終用戶培訓選擇的工作人員 staff-selected-for-author-and-end-user-training

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

利害關係人 stakeholders

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

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

利害關係人了解成功定義和標準 stakeholders-are-aware-of-success-definitions-and-criteria

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

利害關係人了解專案和期望 stakeholders-understand-project-and-expectations

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

狀態報表格式定義 status-report-format-definition

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

成功標準和定義 success-criteria-and-definition

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

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

支援驗證回報的問題 support-in-validation-of-reported-issues

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

支援流程和Adobe支援門戶的訪問 support-processes-and-access-to-adobe-support-portal

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

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

系統架構定義 system-architecture-definition

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

系統架構檔案 system-architecture-documentation

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

系統架構安全概念 system-architecture-security-concept

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

已識別並驗證系統風險因素 system-risk-factors-identified-and-verified

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

團隊了解成功定義和條件 team-is-aware-of-success-definitions-and-criteria

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

團隊了解通信計畫 team-is-aware-of-the-communication-plan

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

團隊了解項目和期望 team-understands-project-and-expectations

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

技術需求 technical-requirements

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

已驗證的技術風險因素 technical-risk-factors-verified

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

技術規範 technical-specification

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

模板規範 template-specification

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

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

測試案例 test-cases

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

測試內容 test-content

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

測試環境就緒 test-environment-ready

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

測試報表 test-reports

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

應當指出：

測試套裝 test-suite

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

已選取測試工具套裝 test-tooling-suite-selected

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

測試概念 testing-concept

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

測試計畫 testing-plans

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

測試範圍 testing-scope

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

測試策略 testing-strategy

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

協力廠商整合概念 third-party-integration-concept

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

第三方整合規格 third-party-integration-specification

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

第三方安全概念 third-party-security-concept

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

協力廠商整合系統 third-party-system-for-integration

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

已啟用第三方系統訪問 third-party-systems-access-enabled

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

第三方測試概念 third-party-testing-concept

定義：

臨界值定義 threshold-definition

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

例如：

時間表和里程碑 timeline-and-milestones

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

項目工作總量 total-project-efforts

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

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

培訓材料 training-materials

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

了解項目範圍和期望 understands-scope-of-project-and-expectations

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

URL處理概念 url-handling-concept

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

該概念還應包括：

使用案例 use-cases

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

轉換為測試案例的使用案例 use-cases-converted-into-test-scenarios

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

使用手冊 user-guides

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

已驗證的預算計畫 validated-budget-plan

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

白盒測試結果 white-box-test-results

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

工作流程規格 workflow-specifications

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

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

工作流程概念 workflows-concept

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