Show Menu
主题×

术语表

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

业务利益相关方的接受

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

接受测试

当应用程序可以生产时,将执行验收测试。 这些测试由代表各种类型最终用户的组使用真实场景来执行。
接受测试用于确认:
  • 项目符合客户的要求。
  • 解决方案适合用途。
  • 用户接受该解决方案,并可以设想使用它。
  • 客户接受项目。
计划和设计验收测试越早,最终部署就越轻松。 应与客户和您的质量保证团队一起定义它们。
尽管您可能无法在项目开始时定义所有详细信息,但应讨论并商定初始定义。 验收测试可能基于基本要求(功能和性能)。

协调访问测试系统

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

Adobe安全核对清单

Adobe安 全核对清单 (Adobe Security Checklist)是为确保AEM在安装时是安全的而提供的正式清单。 它包含您需要执行的安全措施和验证步骤,以确保实例的完整性。 Security Checklist

Adobe支持门户项目设置

Adobe支持门户使实施合作伙伴和客户能够将AEM实施设置为支持门户中的一个项目。
可以注册详细信息;例如,关于实现的技术和版本。 这为客户与Adobe之间提供了透明度。

AEM Administrator Training

为解决方案的行政人员提供培训。 有关详细 信息,请参阅Adobe Training Services

AEM作者培训

为将要为解决方案制作(创作)内容的员工提供培训。 有关详细 信息,请参阅Adobe Training Services

AEM认证考试

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

AEM Certified

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

AEM Technical Training

提供适当角色的技术培训;例如,开发人员、建筑师、工程师和业务从业者。

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和其他服务器文件等元素,以改进解决方案的性能。

编码准则

编码准则定义了开发人员在开发解决方案时应遵循的基本原则。 其中包括:
  • 命名约定
  • 服务使用
  • 库使用情况

通信操作手册

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

通信性能测试报告

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

交流发行说明

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

向团队传达范围和期望

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

交流培训材料和用户指南

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

遵守客户安全要求

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

遵守安全概念

确保安全概念到位。

组件和模板关系概念

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

组件和模板关系规范

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

组件规范

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

外部接口模型的概念

如何针对开发或测试环境中可能不打开/不可用的任何外部界面进行开发和测试的概念。
规划/实施这些界面的模型,以确保测试尽可能接近类似于生产的行为。

内容架构文档

内容建议架构的文档。 详情应包括(其中包括):
  • 内容树
  • 标记概念
  • 内容重用策略

已验证迁移内容

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

合同草稿

法律合同的初稿。

当前内容结构和格式

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

客户备份和恢复策略

客户有关以下方面的政策:
  • 数据和解决方案的备份流程
  • 备份存储
  • 确认备份正按预期运行
  • 恢复,如果失败

客户编码准则

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

客户部署/发布策略

客户制定的策略,用于定义部署/发布的方式和时间。
这些要求通常包括时间轴、计划和签署要求。

客户监控政策或要求

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

客户生产发布计划

客户为发布到生产环境而定义的计划。

客户报告政策和要求

客户在报告方面的任何政策和/或要求。 这些功能包括:
  • 具体报告的提交频率
  • 特定报告的格式
  • 特殊要求

客户路线图

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

客户安全策略

客户(业务和IT)将制定策略来定义解决方案所需的安全级别。 这些功能包括:
  • 通过风险评估的要求。
  • 通过渗透测试的要求。
  • 任何特定安全要求;如转义所有输入字段、加密使用(SSL)、证书以及身份验证和会话。

客户规范指南

客户拥有的与规范的格式、交付和签字相关的任何准则。

客户测试报告

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

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

所应用的任何自定义和/或已应用的修补程序必须记录在案,因为它们可能影响将来的升级:
  • AEM可以严格自定义以满足业务需求。 任何可能影响升级的自定义必须完整记录。 例如,对AEM的用户界面(UI)所做的任何主要更改。
  • 当前解决方案所需的任何更新都必须完整记录;这些包括:
    • 累积修复包(CFP)
    • 服务包(SP)
    • 修补程序
    • 升级

每日用户接受测试报告

由用户接受测试(UAT)生成的报告或会议。 他们应详细说明:
  • 报告的问题
  • 优先处理这些问题

已启用默认安全性

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

部署/发布策略和流程

涵盖项目部署和发布的正式策略。 这些功能包括:
  • 发行时间
  • 节假日规划
  • 频率
  • 并且可以依赖于相关环境

已建立部署节奏

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

开发方法

软件开发方法将软件开发工作的整个过程分为不同的阶段(或阶段),每个阶段都有不同的活动。 目标是改进规划和管理。
在定义方法时,您应预定义项目团队为开发或维护应用程序而创建和完成的特定交付件和对象。

开发角色定义

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

开发环境就绪

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

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

开发团队应确认他们完全了解:
  • 项目范围
  • 所有客户期望
  • 这是项目中每个阶段按个人作出的所有决定的基础

对话框规范

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

文档开发环境设置

开发环境的文档。

文档生产环境设置

生产环境的文档。

文档测试环境设置

测试环境的文档。

耐久性测试

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

执行耐久性测试

执行耐久性测试。

错误处理概念

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

错误处理文档

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

上报流程

所有升级流程的定义。 每个项目级别都将有单独的进程:
  • 项目团队
  • 客户
  • Adobe

建立定期质量审查会议

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

现有权限结构

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

现有系统映射

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

预期成功定义和标准

项目发起人收集与项目成功相关的业务期望。 在项目开始时,必须有一整套期望,因为这些期望应影响整个实施过程中作出的所有决定。
预期包括:
  • 特定KPI,如所服务页面的百分比增长
  • 发布内容的时间更短
  • 更高级别的目标,如易于使用的界面

体验设计要求

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

体验规范

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

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

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

备用系统和过程

备用系统的定义:
  • 在发生严重故障时必须继续运行的业务关键功能
  • 回退时所需的进程

已测试回退系统和过程

备用系统的端到端测试。

从业务利益干系人处注销回退系统

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

关于KPI的可行性确认

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

最终合同

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

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

确认利益相关方完全接受:
  • 解决方案功能
  • 解决方案中的任何已知问题

上线计划

以下项目所需的活动的时间轴和计划:
  • 准备上市
  • 真正的上线

已定义快乐路径

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

硬件估计

以下各项的初步估计:
  • 基本AEM安装所需的硬件
  • 任何附加要求,基于高级解决方案设计

硬件将可满足要求

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

高级要求

对高级别要求的定义对系统的要求进行了广义细分,包括:
  • 业务流程
  • 主要系统功能
有关这些功能的基本详细信息通常是已知的,因此本文档不应是估算。

高级解决方案设计

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

高级系统地图

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

历史内容结构

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

历史绩效和历史绩效关键绩效指标

您需要从旧系统中收集和记录性能统计数据和性能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维护多个版本的资产和内容。 清除规则经过设计和配置,可定期删除旧版本以保持存储库的运行状况和大小。

质量报告格式和节奏

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

协调发布

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

发行说明

发行说明是发行文档的一部分。 发行说明应包括:
  • 先决条件
  • 包含要求
  • 已解决的问题
  • 版本中的已知问题
它与操作手册一起使用,以执行安装前后的步骤和检查。
有关示例,请参阅 AEM发行说明

在生产环境中运行的版本

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

相关合同条款

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

报告节奏

与客户一起定义向其提供报告的频率。

存储库优化

tar文件中的数据不会被覆盖,即使仅更新现有数据,磁盘使用率也会增加。
为了抵消存储库不断增大的大小,实施了一种优化策略以删除过时的数据。

在Adobe Support Portal中设置项目部分的请求

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

要求文档

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

可用于支持的资源投入使用

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

风险评估

风险评估由客户的IT和/或安全部门执行。
它评估项目的技术和业务风险。 该解决方案需要评估,以确保符合安全政策。

风险缓解计划

风险缓解计划包括风险评估。 它们共同涵盖:
  • 已识别风险
  • 如在实施过程中出现这些风险,可能采取的解决办法

ROI预期

定义附加到解决方案的投资回报(ROI)预期。
它们旨在通过界定与估计投资有关的预期收益/利润来说明以经济方式解决方案的效率。

角色和权限概念

详细规范了与新应用程序所需的角色和访问权限相关的概念,包括以下高级概述:
  • 角色
  • 用户
  • 权限
  • 以及用户管理和供应

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

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

角色和权限规范

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

安全架构建议

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

基于安全性的编码准则

这些准则定义了如何根据安全要求进行开发编码,例如:
  • 命名约定
  • 框架准则
  • API使用

Security Checklist

项目特定项目清单,基于安全概念以及确保符合解决方案所需的任何附加政策。
通常,这也包含在操作手册的部署后步骤中。

安全概念

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

安全概念草案

涵盖以下各项安全设置的高级大纲:
  • 应用程序
  • 架构
  • 基础设施

列出和评估的安全问题

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

从业务利益相关方处签字

从利益相关方处签字,以确保安全实施符合政策和预期。

设置支持流程

设置所需的支持流程。

第三方系统的SLA

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

烟度测试概念

烟雾测试由一组定义的步骤组成,这些步骤可测试解决方案的主要功能以确保解决方案的基本操作和功能。
它们在安装或部署后在任何环境中执行。

为系统验证执行的烟雾测试

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

软件架构战略

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

已建立解决方案审查委员会并召开会议

解决方案审查委员会通常由客户利益相关方组成。
董事会定期举行会议,以持续检讨目前范围内之要求及相关规范。 目的是确保符合成功定义和标准,并为制定要求提供投入。

解决方案手册

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

解决方案签字和验收流程

签署和接受流程概述了在将解决方案发布到生产环境中之前必须满足的标准。
它还可以作为合同上的里程碑。

特殊功能概念

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

特殊功能规范

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

规范准则

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

已定义和通知规范审核和批准流程

应该为客户签署规范制定一个明确的流程。 这一过程确保了要求的明确性和牢固性。

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

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

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

需要培训的内部员工就解决方案进行创作。

利益相关者

利益相关方是与项目有重大利害关系的关键人员和/或角色。 一些人将为项目预算捐款。
利益相关者可以是内部和/或外部。

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

确认实际实施小组以外的所有利益相关方都了解:
  • 成功定义
  • 成功标准

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

确认实际实施团队以外的所有利益相关方都符合整个项目和预期,无论是项目团队内部还是客户内部。

状态报告格式定义

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

成功标准和定义

客户、项目赞助人和项目经理或顾问应指定:
  • 什么定义了项目的成功结果。
  • 满足该成功定义所需的特定标准。
这些标准用于确保满足成功标准:
  • 作为KPI的基础。
  • 在整个实施过程中做出决策时。

支持验证报告的问题

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

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

访问Adobe支持门户对于提交有关实施过程中可能出现的任何基于产品的问题的票证至关重要。
访问权限应分配给团队的关键成员。

系统架构定义

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

系统架构文档

详细描述系统架构的文档;包括所有环境的接口、网络位置和集成,以及其他信息。

系统架构安全概念

关于如何使系统架构符合任何安全策略的高级概述。 这可以涵盖:
  • 防火墙和防火墙规则
  • 安全区
  • 本地和一般交通管理者
  • Web服务器
  • 代理和反向代理

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

在风险评估(或其他审阅)中发现的任何风险因素已识别及评估:
  • 每一个风险中隐含的风险级别
  • 以及解决这些问题所需对实施进行的任何更改的估计努力。

团队了解成功定义和标准

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

团队了解通信计划

确认团队所有成员都知道哪些人应与客户进行沟通,并了解具体方式和时间。

团队了解项目和期望

与整个项目和预期保持一致,既与项目团队内部一致,又与客户一致。

技术要求

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

已验证技术风险因素

识别和验证潜在的技术风险。 技术风险包括:
  • 跨站点脚本
  • 最终用户面向输入字段
  • 基础设施
  • 技术时代
  • 集成数量
  • 和依赖关系

技术规范

技术规范涵盖(其中包括其他信息):
  • 接口
  • 配置
  • API
  • 支持解决方案要求的服务

模板规范

所需模板的规范。 这些应包括parsys、blueprint和继承映射等详细信息。
这些规范基于业务要求和体验要求。

Test Cases

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

测试内容

测试内容应尽可能接近生产内容。 它必须具有足够大的选择范围,以允许测试所有场景。

测试环境就绪

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

测试报告

详细介绍测试结果的报告;包括:
  • 缺陷
  • 已执行测试用例的状态
  • 其他与质量相关的主题
应当指出:
  • 应允许任何测试团队保持中立并提供测试结果。
  • 项目经理有责任评估结果的任何影响并决定采取适当行动。

Test Suite

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

已选择测试工具套件

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

测试概念

测试概念是项目测试的极高层次概述;包括QA、UAT、性能、安全性和集成测试。

测试计划

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

测试范围

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

测试策略

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

第三方集成概念

用于与第三方系统集成的架构和系统级概念。

第三方集成规范

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

第三方安全概念

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

第三方集成系统

确保所有第三方系统都可用,并提供相应的文档,以便进行集成实施。

已启用第三方系统访问

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

第三方测试概念

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

阈值定义

为系统中的监视点定义键值。
例如:
  • 有多少KB的未发送日志在主服务器实例上生成警告
  • 在主服务器上生成警告之前允许的每个事务的平均延迟毫秒数

时间轴和里程碑

这应定义用于以下目的的项目时间线和合同里程碑:
  • 开具发票。
  • 根据成功定义、成功标准和KPI进行对齐。

项目总工作量

所有努力的估计,应该合并到项目每个线索中;包括开销、开发、系统工程、建筑和测试工作。
如果协议中包括支助级别,则还应包括支助和行动工作。

培训材料

用于培训会话的材料。 材料应专门为解决方案创建并设计为与用户指南结合使用。

了解项目范围和期望

相应的角色应确认他们完全了解:
  • 项目范围
  • 所有客户期望
  • 这是项目中每个阶段按个人作出的所有决定的基础

URL处理概念

您的URL处理概念应涵盖AEM特定URL功能,包括:
  • 虚URL
  • 链接外部化
  • 错误页面
  • 映射
该概念还应包括:
  • 任何重写规则
  • Web服务器上的虚拟主机
  • SEO注意事项,如robots.txt
  • 站点地图

Use Cases

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

转换为测试场景的用例

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

用户指南

用户指南为解决方案的用户提供信息和帮助:
  • 作者
  • 高级用户
  • 管理员

已验证的预算计划

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

白框测试结果

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

工作流规范

根据工作流概念,这些规范应详细定义创建完整工作流的步骤。
每个工作流的规范应包括(至少):
  • 用例
  • 角色
  • 步骤
  • 结果
  • 错误处理

工作流概念

工作流允许您自动执行AEM活动。 工作流概念概述:
  • 需要自动化的流程
  • AEM中将受影响的服务和角色