术语表

此术语表列出了项目核对清单中所有可交付项文档的详细信息(逐个列出)。

业务利益相关方的接受

业务利益相关方的接受确认,作为关键利益相关方,他们与解决方案保持一致,并已就业务要求如何满足业务案例给予了批准。

验收测试

当申请准备好投产时,将执行验收测试。 测试由代表各种类型最终用户的组使用真实场景来执行。

验收测试用于确认:

  • 项目可满足客户的要求。
  • 解决方案非常适合使用。
  • 用户接受该解决方案,并可以考虑使用它。
  • 客户接受项目。

您计划和设计验收测试的时间越早,最终部署就会越容易。 应与客户和您的质量保证团队一起定义它们。

虽然您可能无法在项目开始时定义所有详细信息,但应讨论并商定初始定义。 验收测试可能基于基本要求(功能和性能)。

协调测试系统的访问

确保为所有角色授予所需级别的系统访问权限。

Adobe安全检查列表

Adobe安全检查表是为确保AEM安装安全而提供的正式检查表。 它包含您需要执行的安全措施和验证步骤,以确保实例的完整性。

Adobe支持门户项目设置

Adobe支持门户允许实施合作伙伴和客户将AEM实施设置为支持门户中的项目。

细节可以登记;例如,关于实施的技术和版本。 这为客户和Adobe之间提供了透明度。

AEM管理员培训

对解决方案的行政人员进行培训。 有关更多信息,请参阅Adobe培训服务

AEM创作培训

为将要为解决方案制作(创作)内容的员工提供培训。 有关更多信息,请参阅Adobe培训服务

AEM认证考试

确保注册相应角色以参加相关的认证考试

AEM Certified

确保相应角色通过了相关的认证考试

AEM技术培训

为适当人物提供技术培训;例如,开发人员、架构师、工程师和业务从业者。

KPI协议,定义为项目目标

关键绩效指标(KPI)可帮助组织定义和衡量在实现组织目标方面的进展。 一旦一个组织分析了其任务并确定了其目标,它就需要衡量在实现这些目标方面的进展。 KPI提供了一种测量机制。

协调业务和绩效KPI

协调业务和绩效关键绩效指标(KPI)帮助将组织内所有涉及的人员和流程汇集在一起。 这反过来又有助于减少实现业务目标和实现拟议目标所需的时间和精力。

将内容架构与KPI保持一致

确保建议的内容架构与相关关键绩效指标(KPI)保持一致。

将客户路线图与项目时间表保持一致

客户路线图由高级别里程碑和业务目标组成。 项目时间表必须遵守并符合此策略,因此必须突出显示和跟踪任何潜在风险和/或可能的偏差。

应用程序架构定义

应用程序架构应明确定义建议应用程序的行为。

重点是:

  • 用户如何彼此进行交互以及如何与用户进行交互。
  • 应用程序使用和生成的数据,而不是其内部结构。

已定义应用程序特定的维护任务

除了标准的Adobe Experience Manager(AEM)维护任务之外,您还需要定义为持续维护解决方案而需要执行的任何其他操作任务。

受过适当培训的工作人员

确保您的团队由受过适当培训的员工组成。 对于项目团队,建议包含以下所有内容:

  • 至少有一个AEM认证的Lead Developer
  • 至少一个AEM certified architect
  • 至少75%的开发人员通过AEM认证;
    这允许经认证的开发人员指导初级开发人员,并确保知识共享和透明

架构图

架构图是架构的图形表示。 其中包括:

  • 概念
  • 他们的原则
  • 构成架构一部分的元素和组件

架构草稿

这提供了系统和解决方案架构的高级视图。 在现阶段,这是一项草案,将在后期阶段加以审查和完善。

架构审核板注销

架构审查委员会是一个跨组织机构,它:

  • 监督一项连贯战略的执行
  • 确保系统的合规性

审查委员会应代表与该架构有关的所有关键利益攸关方。 他们通常由一组负责审查和维护整体架构的高管组成。

与KPI相比,适用于真实内容和结果的自动测试套件

自动脚本和基本的自动用例:

  • 适用于生产内容
  • 针对KPI检查

自动测试策略

此策略为可重复使用的自动脚本定义了一个框架,以及质量保证(QA)团队规划的方法。 它概述了自动化测试的总体计划,以帮助确保:

  • 更高的投资回报(ROI)
  • 更多测试覆盖
  • 提高了质量重复性的测试可靠性

针对实际和预期负载的自动测试策略已验证

必须根据解决方案上的内容和预期负载来验证和调整自动测试策略。

自动化策略

部署的自动化可确保部署更快、更一致。 《自动化战略》概述了任何此类自动化机制的配置;包括:

  • 频率
  • 工具
  • 要部署到的环境

了解通信计划

整个项目团队和所有利益相关方必须确认他们了解:

  • 报告结构
  • 报告频率
  • 通信渠道

了解成功定义和标准

整个项目团队和所有利益相关方必须确认他们了解:

  • 成功定义
  • 成功标准

备份和恢复概念

备份和恢复概念概述了将在解决方案中实施的技术功能。 本公司的备份和恢复政策要求提供此服务。

已测试备份和恢复

基于备份和恢复概念的全端到端测试。

商业案例

业务案例文档介绍与采取操作、采取替代操作(如果可用)或不采取任何操作相关的参数。 这些论点应当以具体事实(尽可能/相关)为基础加以平衡,并强调所有案件的好处和风险。

商业案例文档应是所有选择的明确定义,最后是为实施建议的解决方案提出令人信服的理由。

业务分析师了解项目范围和期望

业务分析师应确认他们完全了解:

  • 项目范围
  • 所有客户期望
  • 这是每个人在项目各个阶段作出的所有决定的基础

业务KPI

组织使用关键绩效指标(KPI)来评估其在达到目标方面的成功。

业务KPI定义了可衡量的价值,以证明公司如何有效地实现关键业务目标。 选择适合您的业务/情景的KPI,并明确定义KPI是什么、如何衡量、如何使用和由谁使用,这一点很重要。

业务需求文档

业务要求文档(BRD)详细描述了项目的业务解决方案,为客户的业务需求和期望提供了明确的规格说明。 BRD还区分了业务解决方案和技术解决方案。

在审查业务解决方案时,BRD应该回答以下问题:
“企业想做什么?”

对已识别并符合ROI和KPI预期的解决方案或架构进行任何必要调整后,业务部门予以签收

风险评估和渗透测试过程可能会产生需要在解决方案架构或开发中解决的问题和结果。

因这些流程而做出的任何调整都需要由企业审核和批准,并根据总体目标进行衡量。

缓存策略

缓存策略概述了将为最终用户缓存的内容。 它必须符合性能KPI。

例如,可以缓存图像、javascript和其他服务器文件等元素,以提高解决方案的性能。

编码准则

编码准则定义了开发人员在开发解决方案时应遵循的基本原则。 这些功能包括:

  • 命名约定
  • 服务使用
  • 库使用情况

通信操作手册

确保所有适当的角色/角色都已收到《操作手册》。

传递性能测试报告

确保所有适当的角色/角色都收到性能测试报告。

交流发行说明

确保所有适当的角色/角色都收到了发行说明。

将范围和期望告知团队

确保项目团队充分了解项目范围和交付期望,并与之保持一致。

交流培训材料和用户指南

确保所有适当的角色/角色都收到培训材料和用户指南。

遵守客户安全要求

确保客户的所有安全要求都到位。

遵守安全概念

确保已实施安全概念。

组件和模板关系概念

将在新应用程序中使用的模板和组件的大纲。 包括继承规则、权限和关系等详细信息。

组件和模板关系规范

组件和模板关系概念的详细信息。

组件规范

每个要实施的组件的规范详细信息。

外部接口模型的概念

如何针对开发和测试任何外部接口的概念,这些外部接口可能未对开发或测试环境打开/可用。

规划/实施这些界面的模型,以确保测试尽可能接近类似于生产的行为。

内容架构文档

内容建议架构的文档。 详情应包括(其中包括):

  • 内容树
  • 标记概念
  • 重用内容的策略

经过迁移验证的内容

将审核旧版系统内容,并验证所选内容以迁移到新解决方案。

合同草稿

法律合同的初稿。

当前内容结构和格式

有关当前内容架构和格式的文档。 这将用于生成未来的内容架构。 它还将用于迁移概念。

客户备份和恢复策略

客户有关以下方面的政策:

  • 数据和解决方案的备份流程
  • 备份存储
  • 确认备份按预期运行
  • 恢复,如果失败

客户编码准则

客户关于如何开发的任何准则/要求。

客户部署/发布策略

客户的策略,用于定义部署/发布的方式和时间。

这些要求通常包括时间表、计划和签订要求。

客户监控策略或要求

客户应监控的策略和要求。 这些建议是监视概念中指定的任何建议的补充。

客户生产发行计划

客户为生产环境的发行定义的计划。

客户报告策略和要求

客户在报告方面的任何政策和/或要求。 这些功能包括:

  • 具体报告的提交频率
  • 特定报表的格式
  • 特殊要求

客户路线图

制定要实施的主要里程碑的路线图,包括技术和业务。 然后,将该路线图告知客户。

客户安全策略

客户(业务和IT)将制定策略来定义解决方案所需的安全级别。 这些功能包括:

  • 通过风险评估的要求。
  • 通过渗透测试的要求。
  • 任何具体的安全要求;例如转义所有输入字段、加密使用(SSL)、证书以及身份验证和会话。

客户规范准则

客户有关规范的格式、交付和签订的任何准则。

客户测试报表

在“用户接受测试”(UAT)期间,从客户向“质量潜在客户”报告。

记录了影响升级的自定义和修补程序

所应用的任何自定义和/或已应用的修补程序都必须记录在案,因为它们可能会影响将来的升级:

  • AEM可根据业务需求进行大量定制。 任何可能影响升级的自定义都必须完全记录。 例如,对AEM的用户界面(UI)进行的任何主要更改。

  • 当前解决方案所需的任何更新都必须完整记录;这包括:

    • 累积修补程序包(CFP)
    • 服务包(SP)
    • 修补程序
    • 升级

每日用户接受测试报表

由用户接受测试(UAT)生成的报告或会议。 他们应该详细说明:

  • 报告的问题
  • 确定这些问题的优先顺序

已启用默认安全性

确保已启用/实施AEM的默认安全设置。

部署/发布策略和流程

正式化的策略,涵盖项目的部署和发布。 这些功能包括:

  • 发行时间
  • 假日规划
  • 频率
  • 并且取决于相关环境

部署终止时间已建立

定义跨环境部署的所需频率。

开发方法

软件开发方法将软件开发工作的整个过程分解为不同的阶段(或阶段),每个阶段都有不同的活动。 目标是改进规划和管理。

在定义方法时,您应预定义项目团队创建并完成的特定交付件和工件,以开发或维护您的应用程序。

开发角色定义

定义在解决方案中执行IT(性能或其他)和/或单元测试的开发人员和/或角色。

开发环境已准备就绪

确保为开发环境配置了自动化部署所需的集成工具。

开发团队了解项目范围和期望

开发团队应确认他们完全了解:

  • 项目范围
  • 所有客户期望
  • 这是每个人在项目各个阶段作出的所有决定的基础

对话框规范

有关解决方案所需对话框的详细信息。

文档开发环境设置

开发环境文档。

文档生产环境设置

生产环境的文档。

文档测试环境设置

测试环境的文档。

耐久性测试

耐久性测试显示解决方案在特定负载下的性能。 测试可衡量解决方案在提交到阈值负载时的存活时间以及性能级别。

已执行耐久性测试

执行耐久性测试。

错误处理概念

错误处理是指对编程、应用和通信错误的预期、检测和解决。

错误处理文档

基于错误处理概念,详细记录了建议的错误处理。

呈报流程

所有呈报流程的定义。 每个项目级别将有不同的流程:

  • 项目团队
  • 客户
  • Adobe

定期举办质量审查会议

与适当的团队成员定期举行质量审查会议。

现有权限结构

为旧版解决方案或组织内定义的一组现有权限和组的文档。

现有系统图

现有系统和依赖关系的图表(或一组图表)。

预期成功定义和标准

项目赞助商收集与项目成功相关的业务期望。 在项目开始时,必须提供全套期望,因为这些期望应影响整个实施过程中作出的所有决定。

预期可能包括:

  • 特定KPI,例如提供的页面数量增长百分比
  • 缩短发布内容的时间
  • 更高级别的目标,如易于使用的界面

体验设计要求

解决方案整个体验的要求。 这包括个性化、跨设备持久性和用户体验等因素。

体验规范

体验设计要求的详细信息。

外部系统和用户依赖/系统上下文

概述解决方案整个生态系统的图表(或一组图表)。 这应包括外部集成、接口、依赖关系和网络等元素。

回退系统和过程

回退系统的定义:

  • 在发生严重故障时必须继续运行的业务关键功能
  • 回退时需要的流程

已测试回退系统和过程

回退系统的端到端测试。

从业务利益相关方注销回退系统

业务利益相关方签署,回退系统和相关程序将确保关键业务功能。

关于KPI的可行性确认

对AEM和高级解决方案设计的可行性研究结果。 应根据KPI衡量这些指标,以确保能够满足这些指标。

最终合同

在继续开展项目之前,需要签订最后确定的合同。 这基于合同草稿

利益相关方接受的解决方案的功能

确认利益相关方完全接受:

  • 解决方案功能
  • 解决方案中的任何已知问题

上线时间表

所需活动的时间轴和计划:

  • 为上线做准备
  • 实际上要上线

定义的快乐路径

快乐路径是默认情景,没有异常或错误情况。 它由一系列在一切按预期进行时执行的活动组成。

硬件估计

初步估计:

  • 基本AEM安装所需的硬件
  • 任何其他要求(基于高级解决方案设计)

硬件将可满足要求

确认所有环境都将拥有所需的最低硬件。

高级别要求

对高级别要求的定义提供了对系统要求的全面划分,包括以下方面:

  • 业务流程
  • 主要系统功能

有关这些函数的基本详细信息通常是已知的,因此本文档不应是预估文档。

高级解决方案设计

高级解决方案设计解释了将用于开发解决方案的架构。 架构图提供了整个系统的概述,确定了将为产品及其界面开发的主要组件。

高级系统图

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

历史内容结构

旧版系统的内容结构的定义。 此参数在准备迁移策略时也可供参考。

历史绩效和历史绩效KPI

您需要从旧版系统中收集并记录性能统计信息和性能KPI。 然后,将这些参数用作参考点并作为新解决方案的基准。

确定关键关键解决方案/功能

关键业务功能的列表。

实施 — 根据渗透测试结果进行更改

根据渗透测试的结果,对解决方案实施所有必需的更改(已签署)。

实施 — 自动测试策略

设置支持自动测试所需的工具和流程。

实施 — 自动化策略

设置支持自动化所需的工具集和流程。

实施 — 内容架构

内容架构的实施、标记概念和内容的重用。

实施 — 体验设计

实施支持体验设计的要求。

实施 — 回退系统和过程

回退系统和相关过程的实施。

实施 — 集成

实施与所有必需外部系统的集成。

实施 — 迁移策略

迁移以及验证新解决方案的内容和其他工件。

实施 — 角色和权限

角色和权限、用户和组的实施。

实施 — 安全概念

实施所有安全措施,包括AEM默认值。

实施 — 安全软件

软件应用程序安全性的实现。

实施 — 系统架构安全概念

系统安全性的实现。

实施 — URL处理

实施URL处理概念。

实施 — 工作流

实施设计的工作流。

实施概念

实施理念为整个实施提供了指导原则。 它应当考虑到:

  • 运营
  • 维护
  • 兼容性
  • 可重用性
  • 安全
  • 可扩展性

此概念还可以超出解决方案中使用的框架、库和其他工件。

通知Adobe支持上线计划

联系Adobe支持,以确保在上线过程中启用所需的任何支持。

初始体验设计

体验设计的初步概念。

集成测试

对内部和外部所有集成进行测试,并获得相应的确认。

这应该是自动的,并且应经常运行,以确保系统的稳定性。

问题跟踪过程

清晰的流程记录了遇到的所有问题并跟踪正在进行的活动,以确保所有问题都得到解决。

问题跟踪系统和流程

一个跟踪系统,连同所需的进程,记录所遇到的所有问题并跟踪正在进行的活动,以确保解决所有问题。

所有项目利益攸关方都应有权访问,以便促进项目状况的透明度。

示例包括Atlassian JIRA和HP Quality Center。

问题跟踪系统过程的建立与集成

所选工具已完全集成并授予所有所需角色的访问权限。

旧版系统

对于您的项目,旧版系统是现有的技术、计算机系统或应用程序,将被新解决方案取代。

应收集旧版系统的详细信息,以便您了解可以停用的内容、停用时间以及对任何其他系统的影响。

要使用的开发工具列表

将在实施中使用的工具概要;工具应包括:

  • 文档工具
  • 问题跟踪工具
  • 部署工具
  • 构建工具

需要访问Adobe支持门户的用户列表

需要访问Adobe支持门户的所有用户和角色的列表。

该列表通常由解决方案架构师和/或客户IT员工组成。

日志文件分析

分析以及生成的建议,用于定义需要记录哪些内容才能监控解决方案:

  • 要记录的活动
  • 粒度级别
  • 每个活动的记录信息

已测试并启用维护任务(AEM特定)

测试并启用AEM维护任务,例如:

  • 压缩
  • 系统清洁
  • 工作流清除

迁移计划

记录迁移;包括

  • 迁移时间表
  • 内容维护计划,根据迁移策略

迁移策略

对映射到新解决方案的现有内容、内容架构和格式的完整描述。 它应包括:

  • 如果可能,自动迁移的技术详细信息
  • 迁移后要执行的烟雾测试,以验证迁移的内容

它还应建议如何在从迁移到新系统实际上线的期间,使内容保持最新(或尽可能保持最新)。 这可能意味着内容冻结、双重发布或Alpha系统的维护。

监控 — CPU

监控解决方案对系统CPU的使用:

  • 平均

监控 — 磁盘I/O

监控解决方案的磁盘输入和输出速率:

  • 平均

监控 — 磁盘空间

监控解决方案对磁盘空间的使用:

  • 平均
  • 随时间增长

您应通过以下方式监控使用情况:

  • 存储库
  • 日志文件

监控 — 外部系统

监控解决方案与外部系统之间的任何连接:

  • 流量率
  • 稳定性

监控 — 网络带宽

监控解决方案对网络带宽的使用情况:

  • 平均流量率
  • 稳定性

监控 — 请求

监控对解决方案发出的请求。

监控 — 安全点

在定义的安全点进行监控。

监控 — 系统

监控整个系统;例如:

  • 可用性
  • 平均性能
  • 性能峰值
  • 警报

监控 — 阈值和干预

监控解决方案定义的阈值,并实施干预步骤以减少负载。

监控概念

要应用于您的解决方案的监控概念;并入:

  • AEM standard监控
  • 系统监控
  • 客户特定监控要求

监控潜在弱点

应确定和定义可能容易失败的具体点。 还应定义与这些任务相关的任何监视任务。

示例包括(其中包括):

  • 关键工作流
  • 交易处理
  • 集成点

向系统工程师传递监控策略

确保系统工程师和操作人员了解和了解任何监控策略。

监控报告 — 现有结构

定义:

  • 何时生成监控报告
  • 他们应该送给

操作任务文档

记录了所有操作任务,并定义了其频度。

操作手册

手动提供成功运行和维护解决方案所需的所有信息:

  • 所有操作任务
  • 关键联系人
  • 部署计划
  • 部署前/部署后的检查列表
  • 其他关键任务

还应详细说明以下实施概念:

  • 满足性能KPI
  • 扩展解决方案以继续满足这些KPI

准备包

已构建并交付的软件包,可供部署。

渗透测试

渗透测试(非正式地称为笔测试)是对计算机系统的攻击,它寻找安全漏洞,可能获得计算机的功能和数据。

渗透测试 — 已通过

已传递所有必需的标准。

渗透测试 — 结果

为业务创建的报表,用于解释渗透测试结果。

性能和可扩展性概念

有关如何确保您的实施符合性能KPI,以及如何扩展解决方案以使其继续满足这些KPI的概念文档。

性能基准

性能基准用于定义性能测试、耐久性测试和监控。 它通过评估解决方案和系统硬件的性能特性来实现这一点。

性能KPI

这些指标定义了衡量系统性能所需的关键绩效指标(KPI)。 一些示例包括页面加载时间、服务器响应时间和数据库查询性能。

性能测试 — 报表

为企业创建的报告,详细说明性能测试的结果。

性能测试 — 结果匹配性能KPI

结果必须与定义的KPI和绩效预期相匹配。

基于角色的测试概念

基于角色的测试是一种基于体验设计中概述的不同角色的方法。 它还会测试帐户及其相关权限级别。

这通常用于用户接受测试(UAT)。

POC已根据要求文档进行测试和验证

概念验证(POC)将根据要求进行测量,以确保二者保持一致。

部署后核对清单

用于定义要在每次部署后执行的一系列检查和任务的检查列表。

部署前核对清单

用于定义在每次部署之前要执行的一系列检查和任务的检查列表。

生产环境基线性能测试

通常在标准安装的AEM上运行基线测试。 然后,将此值用作测试相应实施和硬件的基准。

生产环境已准备就绪

确认生产环境已准备就绪,且已实施自动部署。

业务利益相关方的生产签约

在上线到生产环境之前,必须先授予生产注销(PSO)。 这是对将投入生产的版本以及任何已知问题进行审核的结果。 注销作为“上线”计划的一部分提供。

生产签收流程和策略

在将包移动到生产环境之前获取生产签名所需的策略和过程。

项目通信计划

为业务利益相关者和项目团队定义沟通计划。

项目工作 — 最终估计

初始估计数为高水平,根据执行工作的高水平要求作出。

现对这些内容进行审查、改进和扩大,以提供最终估计。 估计应由每个适当的项目负责人提供,包括项目管理、咨询、架构、测试和开发。

这些估计用于资源筹措和预算编制。

项目工作 — 初始估计

初步估计数是高额的,是根据执行工作的高额要求作出的。 这项工作将在以后的阶段进行审查和改进。

项目组织

概述项目和团队的组织和报告结构所需的文档。

通常采用图表的形式或包含图表,以直观地概述时间轴和责任。 有许多工具可用于帮助解决此问题。

项目范围文档

项目范围文档要求您标识并记录以下列表:

  • 特定项目目标
  • 交付项
  • 功能
  • 函数
  • 任务
  • 截止时间
  • 计划的工作

它涵盖交付项目必须实现的目标以及必须完成的工作

定义的频率内的项目状态报表

按照商定的计划和所需格式提交项目状态报告。

概念验证(POC)

概念验证(POC)为解决方案实现了有限范围的功能。

该方案应旨在论证该方案的可行性,验证其能够达到所需目的,并证明其有潜力可用。

清除规则

AEM维护多个版本的资产和内容。 清除规则的设计和配置是定期删除旧版本,以维护存储库的运行状况和大小。

质量报表格式和频度

定义质量报表的所需内容和格式,以及必须交付的频率。

协调发布

项目经理负责协调发布到生产环境所需的所有角色。

发行说明

发行说明是此版本文档的一部分。 发行说明应涵盖:

  • 先决条件
  • 包括的要求
  • 已解决的问题
  • 版本中的已知问题

它与Runbook一起用于执行安装前和安装后步骤和检查。

注意

有关示例,请参阅AEM发行说明

在生产环境中运行的版本

最终版本正在运行并在生产中处于活动状态。

相关合同条款

您应强调与项目实施相关的具体合同条款;例如合同里程碑、发票期或工作人员要求。

报表频率

与客户一起定义向他们提交报表的频率。

存储库优化

在tar文件中,数据从未被覆盖,即使仅更新现有数据,磁盘使用率也会增加。

为了抵消存储库不断增大的大小,已制定了一种优化策略来删除过时的数据。

请求在Adobe支持门户中设置项目部分

在Adobe支持门户中设置项目的正式请求。

要求文档

这套文件涵盖功能和非功能需求以及估计的工作。

可用于支持的资源上线

确保上线所需的所有角色都配备人员并可用。

风险评估

风险评估由客户的IT和/或安全部门执行。

它评估项目的技术和业务风险。 解决方案需要进行评估,以确保符合安全策略。

风险减轻计划

风险缓解计划包括风险评估。 它们共同涵盖:

  • 已识别风险
  • 如在实施中出现这些风险,可能采取解决办法

ROI预期

定义附加到解决方案的投资回报(ROI)预期。

它们旨在通过界定与估计投资有关的预期收益/利润,从经济角度说明解决方案的效率。

角色和权限概念

详细说明与新应用程序所需的角色和访问权限相关的概念,包括以下内容的高级概述:

  • 角色
  • 用户
  • 权限
  • 以及用户管理和预配

角色和权限概念符合安全准则

审查角色和权限概念,确保其符合安全策略。

角色和权限规范

基于角色和权限概念的详细规范。

安全架构Recommendations

Recommendations与软件和硬件架构的安全性相关。

基于安全性的编码准则

这些准则根据安全要求定义了如何进行开发编码,例如:

  • 命名约定
  • 框架准则
  • API使用情况

安全检查列表

项目特定的项目核对清单,基于安全概念以及确保解决方案符合性所需的任何其他策略。

通常,这也会作为Runbook中部署后步骤的一部分包含在内。

安全概念

定义并记录应用程序、架构和基础架构所需安全配置的详细信息。

安全概念草案

高级概要,涵盖以下项的安全设置:

  • 应用程序
  • 架构
  • 基础架构

列出和评估的安全问题

列出并评估解决方案的所有安全问题;包括工作量估计。

业务利益相关方的安全签署

请利益相关方签署,以确保安全实施符合策略和期望。

设置支持流程

设置所需的支持流程。

第三方系统的SLA

确保服务级别协议(SLA)可用并传达给开发团队和运营团队,以便在实施和支持期间使用。

烟度测试概念

烟雾测试由一组定义的步骤组成,这些步骤可测试解决方案的关键功能以确保解决方案的基本操作和功能。

它们在安装或部署后在任何环境中执行。

为系统验证而执行的烟度测试

应在所有系统上运行烟雾测试,以确保解决方案在安装或部署到任何环境时的基本功能能够正确运行。

软件架构策略

软件架构的高级策略;包括服务、servlet、框架和其他实施决策。

已成立解决方案审查委员会并且会议频率集

解决方案审查委员会通常由客户利益相关方组成。

董事会定期举行会议,以持续检讨目前范围之规定及相关规范。 目的是确保符合成功定义和标准,并为制定要求提供投入。

解决方案Runbook

解决方案的安装说明,以及安装时要执行的基本操作任务。

解决方案签收和验收流程

签署和接受流程概述了在将解决方案发布到生产环境之前必须满足的标准。

它还可用作合同里程碑。

特殊功能概念

在AEM平台上被视为超出正常开发范围的任何特殊功能的初始概念。

特殊功能规范

在AEM平台上被视为超出正常开发范围的任何特殊功能的详细信息。

规范准则

客户关于如何进行规范的任何准则。

规范审核和审批流程定义和传达

客户签署规范的明确过程应当到位。 此过程可确保要求的范围清晰而稳固。

为AEM管理员培训选定的员工

需要培训以管理解决方案的内部员工。

为作者和最终用户培训选择的员工

需要培训才能编写解决方案的内部员工。

利益相关方

利益相关方是对项目有重大兴趣的关键人员和/或角色。 有些将为项目预算捐款。

利益相关方可以是内部和/或外部。

利益相关方了解成功定义和标准

确认实际实施团队以外的所有利益相关方都了解:

  • 成功定义
  • 成功标准

利益相关方了解项目和期望

确认实际实施团队以外的所有利益相关方都与整个项目和预期保持一致,包括项目团队内部和客户内部。

状态报表格式定义

状态报告是沟通的关键工具。 格式应与客户的任何报告要求保持一致。

成功标准和定义

客户、项目赞助人、项目经理或顾问应当具体说明:

  • 为项目定义成功结果的内容。
  • 达到该成功定义所需的特定标准。

这些标准用于确保符合成功标准:

  • 作为KPI的基础。
  • 在整个实施过程中做出决策时。

支持验证报告的问题

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

支持流程和访问Adobe支持门户

访问Adobe支持门户对于提交有关实施过程中可能出现的任何基于产品的问题的票证至关重要。

访问权限应分配给团队的关键成员。

系统架构定义

针对解决方案所有环境的架构的初始建议和定义。

系统架构文档

详细说明系统架构的文件;包括所有环境的界面、网络位置和集成,以及其他信息。

系统架构安全概念

概述如何使系统体系结构符合任何安全策略。 这可以涵盖:

  • 防火墙和防火墙规则
  • 安全区
  • 本地和一般流量管理器
  • Web服务器
  • 代理和反向代理

已识别和验证的系统风险因素

在风险评估(或其他审阅)中发现的任何风险因素均予识别及评估:

  • 每个风险中隐含的风险水平
  • 以及针对实施所需的任何更改的估计工作量。

团队了解成功定义和标准

确认整个团队都了解成功定义和标准。

团队了解通信计划

确认团队的所有成员都知道应与客户通信的人员,以及有关方式和时间的详细信息。

团队了解项目和期望

与整个项目和期望保持一致,无论是在项目团队内部还是在客户内部。

技术要求

这些要求特定于支持解决方案的服务的技术实施。

技术风险因素已验证

识别和验证潜在的技术风险。 技术风险可包括:

  • 跨站点脚本
  • 面向最终用户的输入字段
  • 基础架构
  • 技术时代
  • 集成数量
  • 和依赖关系

技术规范

技术规范涵盖(其中包括):

  • 接口
  • 配置
  • API
  • 支持解决方案要求的服务

模板规范

所需模板的规范。 这些内容应涵盖详细信息,包括parsys、blueprint和继承映射等。

这些规范基于业务要求和体验要求。

测试用例

测试用例特定于执行解决方案功能测试所需的详细步骤。

测试内容

测试内容应尽可能靠近生产内容。 它必须具有足够大的选择范围,以便能够测试所有方案。

测试环境已准备就绪

确保测试环境已准备就绪,并实施了自动部署,以确保所有发行候选代码都是最新的测试代码。

测试报表

详细说明测试结果的报告;包括:

  • 缺陷产生
  • 已执行的测试用例状态
  • 其他与质量相关的主题

应当指出:

  • 应允许任何测试团队保持中立并提供测试结果。
  • 项目经理有责任评估结果的任何影响并决定采取适当行动。

测试套件

选择自动化套件和工具。 这些功能将用于自动化测试,包括用例测试。

已选择测试工具包

为用例自动化和其他测试执行任务选择了自动化套件和工具。

测试概念

测试概念是项目测试的非常高级的概要;包括QA、UAT、性能、安全性和集成测试。

测试计划

这些计划更详细地概述了针对每个开发阶段执行测试的情况,并以测试策略为基础。

测试范围

这些要求特定于支持解决方案的服务的技术实施。

测试策略

测试策略概述了质量保证和用户接受测试的高级策略。 这包括时间轴、报告频率和执行。

第三方集成概念

与第三方系统集成的体系结构和系统级概念。

第三方集成规范

第三方系统支持的功能和集成要求(功能和非功能)的详细信息。

第三方安全概念

用于确保任何第三方集成安全性的概念。 必须符合相应的安全策略。

第三方集成系统

确保所有第三方系统均可用,并提供了相应的文档以用于集成实施。

已启用第三方系统访问

需要授予与第三方系统一起使用的各个角色的访问权限。

第三方测试概念

定义:

  • 集成测试用例
  • 与任何第三方应用程序相关的功能

阈值定义

定义系统中监控点的键值。

例如:

  • 有多少千字节(KB)的未发送日志在主服务器实例上生成警告
  • 在主服务器上生成警告之前,每个事务平均延迟所容忍的毫秒数

时间轴和里程碑

这应该定义项目时间表和合同里程碑,用于:

  • 开具发票。
  • 与成功定义、成功标准和KPI保持一致。

项目总工作量

应综合项目每个线索的所有努力估计;包括开销、开发、系统工程、建筑和测试工作。

如果协议中包含支持级别,则还应包括支持和行动努力。

培训材料

培训课程中要使用的材料。 应专门为解决方案创建材料,并设计为与用户指南结合使用。

了解项目范围和期望

相应角色应确认他们完全了解:

  • 项目范围
  • 所有客户期望
  • 这是每个人在项目各个阶段作出的所有决定的基础

URL处理概念

您的URL处理概念应涵盖AEM特定的URL功能,包括:

  • 虚URL
  • 链接外部化
  • 错误页
  • 映射

该概念还应包括:

  • 任何重写规则
  • web服务器上的虚拟主机
  • SEO注意事项,如robots.txt
  • 网站地图

用例

用例是实现目标所需的操作或事件步骤列表。 通常,它们定义角色与解决方案之间的交互。 角色可以是用户或外部系统。

转换为测试方案的用例

测试方案基于技术和业务用例。 它们用于测试解决方案行为是否符合预期。

用户指南

用户指南为解决方案的用户提供信息和帮助:

  • 作者
  • 高级用户
  • 管理员

已验证的预算计划

预算计划必须由所有利益攸关方审查和验证。 他们需要检查详细信息,如开具发票、金额和预算报告的方法/时间。

白盒测试结果

白盒测试是一种测试应用程序内部结构或工作方式(而非其功能)的方法。 白盒测试可以应用于软件测试过程的单元、集成和系统级。

工作流规范

根据工作流概念,这些规范应详细定义将创建完整工作流的步骤。

每个工作流的规范应包括(至少):

  • 用例
  • 角色
  • 步骤
  • 成果
  • 错误处理

工作流概念

工作流允许您自动执行AEM活动。 工作流概念概述:

  • 需要自动化的流程
  • AEM中将受影响的服务和角色

在此页面上