术语表 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 Certified 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)期间，从客户向“质量潜在客户”报告。

记录了影响升级的自定义和修补程序 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

此系统图应提供系统的非常高级别的图表。 它与Solution Context的不同之处在于，它是涉及的所有系统的广义映射，此图上没有接口。

历史内容结构 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-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

“质量线索”的部分职责是确保在测试时有可用资源支持任何用户。 例如，帮助用户在测试时、在报告问题时，以及帮助根据测试环境验证问题。

支持流程和访问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活动。 工作流概念概述：