术语表 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应回答以下问题：
“企业想要做什么？”

根据投资回报率和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支持人员上线计划 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

这一组文档涵盖了功能性要求和非功能性要求，以及估计的工作量。

可用支持资源上线 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活动。 工作流概念概述了：