术语表

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

业务利益相关方的接受

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

接受测试

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

验收测试用于确认:

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

计划和设计验收测试越早,最终部署就越简单。 应与客户及您的质量保证团队一起定义这些组件。

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

访问协调的测试系统

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

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认证的领先开发人员

  • 至少一个AEM认证架构师

  • 至少75%的开发人员通过AEM认证;

    这使得经过认证的开发人员能够指导初级开发人员并确保知识共享和透明度

架构图

架构图是架构的图形表示。 它包括下列内容的表示:

  • 概念
  • 他们的原则
  • 作为体系结构一部分的元素和组件

架构草稿

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

架构审阅板注销

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

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

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

与KPI相比,自动测试套件可满足真实内容和结果的要求

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

  • 适用于生产内容
  • 根据KPI检查

自动化测试战略

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

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

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

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

自动化战略

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

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

了解通信计划

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

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

了解成功定义和标准

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

  • 成功定义
  • 成功标准

备份和恢复概念

备份和还原概念概述了将在解决方案中实施的技术功能。 公司备份和恢复策略要求执行此操作。

已测试备份和恢复

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

业务案例

业务案例文档提供与采取操作、采取替代操作(如果可用)或不采取任何操作相关的论据。 这些论点应根据具体事实(在可能/相关的情况下)进行平衡,并强调所有案件的好处和风险。

业务案例文档应是所有选项的明确定义,并以实施建议的解决方案的令人信服的论据结尾。

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

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

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

业务KPI

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

业务关键绩效指标定义了可衡量的价值,以证明公司如何有效地实现关键业务目标。 选择适合您的业务/方案的KPI非常重要,它们的定义明确,如何衡量、如何使用以及由谁使用。

业务需求文档

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

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

对已识别并符合ROI和KPI预期的解决方案或体系结构进行任何必要调整后,企业签字同意

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

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

缓存策略

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

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

编码准则

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

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

通信操作手册

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

通信性能测试报告

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

Communicate发行说明

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

向团队传达范围和期望

确保项目团队完全了解项目范围和投放期望,并与之保持一致。

交流培训材料和用户指南

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

遵守客户安全要求

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

符合安全概念

确保安全概念已经到位。

组件和模板关系概念

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

组件和模板关系规范

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

组件规范

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

外部接口模型的概念

如何针对开发或测试环境可能无法打开/可用的任何外部界面进行开发和测试的概念。

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

内容架构文档

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

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

已验证迁移内容

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

合同草稿

法律合同的初稿。

当前内容结构和格式

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

客户备份和还原策略

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

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

客户编码准则

客户关于如何开发的任何指导/要求。

客户部署/发布策略

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

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

客户监控策略或要求

客户对应监控的政策和要求。 这些是在监测概念中指定的任何建议之外的。

客户生产发布计划

由客户定义的向生产计划发放的环境。

客户报告政策和要求

客户对报告的任何政策和/或要求。 这些包括:

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

客户路线图

制定技术和业务方面要实施的重大里程碑的路线图。 然后,将向客户传达此路线图。

客户安全策略

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

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

客户规范指南

客户所遵循的与规范的格式、投放和签署相关的任何准则。

客户测试报告

在用户验收测试(UAT)期间从客户报告给质量潜在客户。

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

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

  • AEM可以严格定制以满足业务需求。 任何可能影响升级的自定义必须完整记录。 例如,对AEM的用户界面(UI)所做的任何重大更改。

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

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

每日用户接受测试报告

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

  • 报告的问题
  • 优先处理这些问题

默认安全已启用

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

部署/发布策略和进程

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

  • 发行时间
  • 假日规划
  • 频率
  • 并且可以依赖相关环境

部署节奏已建立

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

开发方法

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

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

开发角色定义

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

开发环境就绪

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

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

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

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

对话框规范

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

文档开发环境设置

开发环境的文档。

文档生产环境设置

生产环境的文档。

文档测试环境设置

测试环境的文档。

耐久性测试

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

执行的耐久性测试

执行耐久性测试。

错误处理概念

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

错误处理文档

根据错误处理概念,详细记录建议的错误处理。

升级进程

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

  • 项目团队
  • 客户
  • Adobe

建立定期质量审查会议

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

现有权限结构

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

现有系统映射

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

预期成功定义和标准

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

预期包括:

  • 特定KPI,如服务页面的百分比增加
  • 发布内容的时间更短
  • 更高级别的目标,如易于使用的界面

体验设计要求

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

体验规范

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

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

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

回退系统和过程

回退系统的定义:

  • 业务关键功能,在出现严重故障时必须继续运行
  • 回退时所需的进程

已测试回退系统和过程

备用系统的端到端测试。

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

从业务利益相关方处签字,确认备用系统和相关程序将确保关键业务功能。

KPI的可行性确认

对AEM和高级解决方案设计的可行性研究结果。 应根据关键绩效指标衡量这些指标,以确保这些指标得到满足。

最终合同

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

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

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

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

转到实时计划

以下项目所需活动的时间轴和计划:

  • 准备上市
  • 实际的上线

已定义的快乐路径

快乐路径是默认情景,没有特殊或错误条件。 它由当一切按预期进行时执行的活动序列组成。

硬件估计

以下各项的初步估计:

  • 基本AEM安装所需的硬件
  • 任何附加要求,基于高级解决方案设计

硬件将可满足要求

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

高级要求

对高级要求的定义对系统的要求进行了概括性的细分,包括:

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

这些函数的基本细节通常是已知的,因此此文档不应是估计。

高级解决方案设计

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

高级系统映射

本系统地图应提供一个非常高级别的系统图。 它不同于Solution Context,即它是涉及的所有系统的广义映射,此图上没有接口。

历史内容结构

旧系统的内容结构的定义。 这供参考,也用于准备迁移策略。

历史绩效和历史绩效KPI

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

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

关键业务功能的列表。

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

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

实施——自动化测试战略

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

实施——自动化战略

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

实施——内容架构

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

实施- Experience Design

实现支持Experience Design的要求。

实施——回退系统和过程

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

实施——集成

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

实施——迁移战略

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

实施——角色和权限

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

实施——安全概念

执行所有安全措施,包括AEM默认设置。

实施——安全软件

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

实施——系统架构安全概念

系统安全的实现。

实施- URL处理

URL处理概念的实现。

实施-工作流

实施设计工作流。

实施概念

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

  • 运营
  • 维护
  • 兼容性
  • 可重用性
  • 安全
  • 可伸缩性

此概念还可以概括解决方案中使用的框架、库和其他伪像。

通知Adobe支持“开始使用”计划

联系Adobe支持以确保在移动中启用所需的任何支持。

初始体验设计

体验设计的初步概念。

集成测试

测试所有集成(内部和外部)的结果确认。

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

问题跟踪进程

清晰的流程记录所遇到的所有问题并跟踪当前活动,以确保解决所有问题。

问题跟踪系统和进程

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

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

示例包括Atlassian JIRA和HP Quality Center。

问题跟踪系统进程已设置并已集成

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

旧系统

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

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

要使用的开发工具列表

将用于实施的工具的概要;工具应包括:

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

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

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

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

日志文件分析

分析,连同生成的建议,定义监控解决方案所需记录的内容:

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

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

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

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

迁移计划

文档迁移;包括

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

迁移策略

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

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

它还应建议在迁移和新系统实际开始运行之间的期间如何使内容保持最新(或尽可能保持最新)。 这意味着内容冻结、多次发布或维护alpha系统。

监视- CPU

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

  • 平均

监视——磁盘I/O

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

  • 平均

监视——磁盘空间

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

  • 平均
  • 随时间增长

您应通过以下方式监视使用:

  • 存储库
  • 日志文件

监视——外部系统

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

  • 流量
  • 稳定性

监视——网络带宽

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

  • 平均流量
  • 稳定性

监视——请求

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

监视——安全点

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

监视——系统

监控整个系统;例如:

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

监视——阈值和干预

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

监视概念

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

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

监测潜在弱点

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

示例包括(等):

  • 关键工作流
  • 事务处理
  • 集成点

向系统工程师传达监视策略

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

监视报告——就地结构

定义:

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

运营任务文档

所有运营任务都记录在案,并定义其频率。

操作手册

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

  • 所有运营任务
  • 关键联系人
  • 部署计划
  • 部署前/部署后核对清单
  • 任何其他关键任务

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

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

已准备包

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

渗透测试

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

渗透测试——通过

所有必要条件均已通过。

渗透测试——结果

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

性能和可伸缩性概念

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

性能基准

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

性能KPI

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

性能测试——报告

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

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

结果必须与定义的KPI和性能预期相符。

基于角色的测试概念

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

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

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

概念验证(POC)根据要求进行评估,以确保两者保持一致。

部署后核对清单

定义每次部署后要执行的一系列检查和任务的核对清单。

部署前核对清单

定义在每次部署之前要执行的一系列检查和任务的核对清单。

生产环境基准性能测试

通常对AEM的标准安装运行基准测试。 然后,将其用作测试实现和硬件的基准。

生产环境就绪

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

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

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

生产签名流程和策略

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

项目通信计划

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

项目工作——最终估计数

初步估计数为高水平,根据执行的高水平要求进行。

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

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

项目工作——初始估计数

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

项目组织

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

通常以图表的形式或包括,以直观地概述时间轴和责任。 有许多工具可帮助您完成此操作。

项目范围文档

项目范围文档要求您识别和文档以下列表:

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

它涵盖交付项目必须取得的成果以及必须完成的工作

已定义节奏中的项目状态报告

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

概念验证(POC)

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

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

清除规则

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

质量报告格式和节奏

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

发布协调

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

发行说明

发行说明是发行文档的一部分。 发行说明应包括:

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

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

注意

例如,请参见AEM发行说明

在生产环境上运行的发行版

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

相关合同条款

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

报告节奏

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

存储库优化

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

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

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

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

要求文档

这套文件包括职能和非职能需求以及估计的工作。

可用于支持的资源开始使用

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

风险评估

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

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

风险减轻计划

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

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

投资回报预期

定义附加到解决方案的投资回报(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中的服务和角色将受到影响

On this page

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now