术语表 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

业务分析师应确认其完全理解：

业务关键绩效指标 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）阶段，客户提交给质量负责人的测试报告。

影响升级的自定义和热修复补丁记录 customizations-and-hotfixes-that-affect-upgrades-documented

所有自定义和/或已应用的热修复补丁都必须记录在案，因为它们可能影响未来的升级：

每日用户验收测试报告 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 Support 上线计划 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

渗透测试（通常称为 Pen Test）是一种针对计算机系统的攻击模拟，用于查找安全漏洞，并可能获取对计算机功能和数据的访问权限。

渗透测试 - 通过 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-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

基于角色与权限概念所制定的详细规范。

安全架构建议 security-architecture-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

质量负责人的一项职责是确保在测试过程中有资源可为任何用户提供支持。例如，在用户进行测试、报告问题时给予协助，并在测试环境中帮助验证相关问题。

支持流程以及对 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 活动的自动化。工作流概念应概述：