字彙表 glossary

此字彙表列出專案檢查清單中所有交付專案檔案的詳細資料（按字母順序）。

業務利害關係人的認可 acceptance-from-business-stakeholders

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

驗收測試 acceptance-tests

驗收測試會在應用程式準備好生產時執行。 這些測試由代表各種型別一般使用者的群組執行，使用現實生活情境。

驗收測試用於確認：

您計畫及設計驗收測試的時間越早，最終部署就越容易。 應該與客戶及您的品質保證團隊一起定義。

雖然您可能無法於專案一開始定義所有詳細資訊，但應討論並同意初始定義。 驗收測試可能會根據基本需求（功能與效能）進行。

已協調測試系統的存取權 access-to-test-system-coordinated

確保已經為所有角色授與必要的系統存取層級。

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

Adobe安全性檢查清單是提供的正式檢查清單，用於確保Adobe Experience Manager (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，並清楚定義其內容、測量方式、使用方式及使用對象。

業務需求檔案 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-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

角色型測試是根據體驗設計中概述的不同角色的方法。 它也會測試帳戶及其相關許可權層級。

這通常用於使用者驗收測試(UAT)。

根據需求檔案進行POC測試及驗證 poc-tested-and-verified-against-requirement-documentation

概念證明(POC)會根據需求進行評量，以確保兩者保持一致。

Post部署檢查清單 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

本檔案集涵蓋功能性需求和非功能性需求，以及預估的工作。

可支援Go Live的資源 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活動。 工作流程概念概述：