架构合规性评审检查清单
硬件和操作系统检查单
- 项目的生命周期是怎么样的?
- 项目处于生命周期的什么阶段？
- 已经识别或分析出什么主要问题，其项目观点将驱动网络、服务器及终端用户设备的硬件和操作系统评估?
- 什么系统能力将涉及大量和或高频的数据传送？
- 系统设计如何影响或涉及终端用户设备？
- 什么是使用、数据存储和处理的数量和分布（区域的和全球的）？
- 哪些应用在数据、应用服务等的相似性方面与用户项目相关联?数据与项目相关联的程度如何？
- 在系统关键元件的功能设计之前已经选择什么硬件和操作系统?
- 如果在项目控制之外做出硬件和操作系统决策：
- •项目对那些决策的理由依据有什么认识?
- •形成系统设计时，项目如何才能影响这些决策?
- 如果已经选择一些非标准件：
- •对不使用公司标准的根本业务需求和技术需求是什么?
- •是否被业务案例支持?
- •已经仔细检查了业务案例中的假设吗?
- 评价硬件和操作系统的全部生命周期成本的流程是什么?
- 公司财务管理层如何进行生命周期成本评价?
- 是否已完成对供应商的财务分析?
- 是否己向供应商做出承诺?
- 是否相信只有一家供应商可以满足自身需求?
软件服务和中间件检查单
- 1.描述错误条件是如何被定义、提出并在应用组件之间扩散的。
- 2.描述如何在不同应用模块中定义方法并分类的一般性特征模式
- 3.描述如何在不同应用模块中定义并创建方法参数的一般性特征模式。参数[in]、 [in/out]、[out]是否始终按相同的顺序规定?各模块返回的布尔值是否具有一致的结果?
- 4.描述用来对客户端与服务器之间调用的往返次数进行最小化的实施途径，特别是对进程外调用且涉及复杂数据结构时
- 5.描述在主系统组件之间通过的主要数据结构
- 6.描述在主系统组件之间使用的主要通信协议
- 7.描述在不同系统组件之间所用的封送处理技术。描述所用的任何专门封送处理
- 8.描述有状态组件和无状态组件的系统被设计到何种程度。
- 9.描述如何以及何时为有状态组件和无状态组件保存状态
- 10.描述通过对象集中来创建、使用和破坏或复用对象的程度
- 11.描述系统对线程或临界区编码的依赖程度
- 12.描述在系统内部对方法、方法论据和方法功能性进行文件化的实施途径以及内部文件。
- 13.描述用于构建系统的代码评审流程。
- 14.描述已经用于对系统组件进行测试的单元测试。
- 15.描述不同系统模块包括的前置条件和后置条件测试
- 16.描述系统包括的断言测试。
- 17.组件是否支持其需要支持的所有界面类型?或者是否依照语言绑定或其他形式的封送处理，做出了关于哪些类型的组件将调用其他组件的假设?
- 18.描述需要跨越不同平台处理大端法或小端法数据格式问题的程度。
- 19.描述是否需要对数字或字符串进行跨越不同平台的不同处理。
- 20.描述软件是否需要检查浮点取整误差。
- 21.描述时间与日期功能，如何管理日期才能避免对时间与日期的计算或显示的不恰当处理。
- 22.描述已经使用什么工具或流程来测试系统的内存泄漏、可达性或一般稳健性
- 23.描述系统服务软件的分层。描述主要系统组件之间的总体链接数量。系统是否由许多点对点界面组成?还是使用主要消息传递中枢代替
- 24.描述系统组件松耦合或紧耦合的程度
- 25.系统需要从基础设施中获取共享存储库、通信协议支持、负载平衡、事务处理、系统监控、命名服务或其他基础设施服务等方面的哪些需求?
- 26.描述系统和系统组件如何设计以便重构。
- 27.描述系统或系统组件如何依赖公共消息传递基础设施和独特的点到点通信结构
应用检查单（基础设施应用）
- 1.是否需要不通过企业标准基础设施应用产品而提供的能力?例如：
- 协作
- 应用共享
- 视频会议
- 安排日程
- 电子邮件
- 工作流管理
- 发布/文字处理应用
- HTML
- SGML和XML
- 便携式文件格式
- 文件处理(专用格式)
- 桌面发布
- 电子表格应用
- 演示应用
- 业务演示
- 图像
- 动画
- 视频
- 声音
- 数据管理应用
- 数据库界面
- 文件管理
- 产品数据管理
- 数据仓库藻集市
- 项目群管理应用
- 项目管理
- 项目群可见性
- 协作
- 2.对标准产品没有满足企业基础设施应用能力的业务需求进行描述。
应用检查单（业务应用）
- 1.所需任何能力是否都由支持一个或多个业务线应用的标准产品来提供？例如
- 1.业务采办应用
- 1.销售和营销
- 2.工程应用
- 1.计算机辅助设计
- 2.计算机辅助工程
- 3.数学统计分析
- 3.供应商管理应用
- 1.供应链管理
- 2.客户关系管理
- 4.制造应用
- 企业资源规划(ERP)应用
- 制造执行系统
- 制造质量
- 制造流程工程
- 机器和自适应控制
- 客户支持应用
- 航空公司后勤支持
- 维修工程
- 财务应用
- 人员应用
- 设施应用
- 信息系统应用
- 系统工程
- 软件工程
- Web开发者工具
- 集成开发环境
- 生命周期类别
- 功能性类别
- 特性类别
- 计算机辅助制造
- 电子商务实现
- 业务流程工程
- 统计质量控制
- 1.业务采办应用
- 2.对标准产品不满足的业务应用能力的流程需求进行描述。
应用集成方法
- 1.本架构以哪些集成点(业务流程活动、应用、数据、计算环境)为目标?
- 2.将采用什么应用集成技术(公共业务对象[ORB]、标准数据定义[STEP、XML等]、公共用户界面演示/桌面)?
信息管理检查单
- 1. 数据值
- 对数据管理和使用进行标准化的流程是什么?
- 什么业务流程支持数据的输入和确认?什么业务流程支持数据的使用?
- 什么业务活动对应于数据的创建和修改?
- 什么业务活动对应于数据的删除?是否将其视为业务记录的一部分?
- 业务用户所需的数据质量需求是什么?
- 正在运行什么流程以支持数据引用完整性和或规范化?
- 2. 数据定义
- 所购应用(COTS)的数据模型、数据定义、结构和托管选项是什么?
- 为信息系统所有组件定义并维护数据需求和设计的规则是什么?
- 采用什么可分享存储库来获取模型内容和支持性数据信息?
- 用于设计数据库的物理数据模型定义(源自逻辑数据模型)是什么?
- 已经选择什么软件开发和数据管理工具?
- 已经识别哪些数据所有者来负责公共数据定义，消除无计划的冗余码，提供一贯可靠、及时和精确的信息以及保护数据避免其遭到滥用和破坏?
- 3. 安全/保护
- 保护数据以免其受到无意和未经授权的改变、泄露和分配的数据实体及属性的访问规则是什么?
- 保护数据使其免受未经授权的外部访问的数据保护机制是什么?
- 对来自外部数据源且暂时存储在企业内部的数据进行访问控制的数据保护机制是什么?
- 4. 托管、数据类型和共享
- 利用所定义的对存储在不同平台上的物理数据进行更新的规则，将独立授权数据作为一个逻辑源进行管理的规程是什么?
- 对来自独立授权操作数据的复制数据进行管理的规程是什么?
- 已识别什么层级数据服务器来存储高临界或中间临界操作数据?
- 已识别什么层级数据服务器来存储C型操作数据?
- 已识别什么层级数据服务器来存储数据仓库中所包含的决策支持数据?
- 已经实施了什么数据库管理系统(DBMS)?
- 5. 公用服务
- 什么是标准化的分布式数据管理服务(如确认、一致性检查、数据编辑、加密和事务管理)及其在何处存储?
- 6. 访问方法
- 对标准文件、消息和数据管理的数据访问需求是什么?
- 对决策支持数据的访问需求是什么?
- 数据存储位置和应用逻辑位置是什么?
- 正在使用的查询语言是什么?
安全检查单
- 安全意识：是否确保正在设计的公司安全策略和指南为最新版本?是否读过这些安全策略和指南?是否知道所有相关计算安全合规性和风接受流程?(面谈者应列出所有相关方针和指南。)
- 识别/认证：将如何向应用识别用户以及应用如何证实该用户正是其所申明用户的处理流程进行图形化。为流程图提供支持性文件，以解释从用户界面到应用数据库服务器并返回用户的流程。在账户、密码等方面是否与公司策略合规?
- 授权：提供一个自始至终的处理流程，展示用户如何要求对应用进行访问，表明关联的安全控制和职责分离。这应包括该要求如何被适当的数据所有者批准，如何将用户置入适当访问层级的分类概要，如何创建用户ID、密码和访问以及如何提供给用户。还包括如何向用户告知与使用该应用相关的职责，如何提供一份访问协议，如何更改密码、谁来求助等
- 访问控制：将如何添加、更改、删除和记录用户D、密码和访问概要进行文件化。文档应包括谁对这些流程负责。
- 敏感信息保护:提供对需要附加保护的敏感数据进行识别的文档。识别负责该数据的数据所有者，以及用于保护该数据的存储、传输、打印和分配的流程。包括如何保护密码文件字段。如何防止用户看到其他人的敏感信息?是否与外部相关方(合作伙伴、供应商、承包商等)具有关于信息保护的协议?如果有，其义务是什么?
- 审核跟踪和审计日志:识别并记录用户或应用支持所需的群组账户包括操作系统群组账户。识别并记录具有超级用户类型特权的个人账户和或角色，这些特权是什么，谁访问这些账户，如何控制、跟踪并记录对这些账户的访问，以及如何处理密码更改和分配，包括操作系统账号。还识别审计日志，谁可以阅读审计日志，谁可以修改审计日志，谁可以删除审计日志，以及如何保护和存储审计日志。用户DD是否在审计跟踪中被隐藏
- 外部访问考量因素：该应用是否将仅在内部使用?若不是，是否与公司外部访问需求合规?
系统管理检查单
- 1.必须发布的软件更改频率是什么?
- 2.什么工具用于软件分发?
- 3.允许生产多个软件和或数据版本吗
- 4.用户数据备份频率和期望的恢复时间是什么?
- 5.如何创建和管理用户账户?
- 6.系统许可证管理策略是什么?
- 7.需要什么一般系统管理工具?
- 8.需要什么特定应用管理工具?
- 9.需要什么特定服务管理工具?
- 10.如何接收并发送服务调用?
- 11.描述如何卸载系统
- 12.描述用于检查系统是否恰当安装的流程或工具。
- 13.描述用于监控系统健康及性能的工具或仪器。
- 14.描述可用于确定已在何处安装系统的恰当工具或流程
- 15.描述什么形式的审计日志可适当地获取系统历史记录，特别是在发生事故之后。
- 16.描述将系统错误信息迅速发送到服务人员的系统能力。
系统工程/整体架构检查单
- 1. 概述
- 1.哪些其他应用和或系统需要与你的应用和或系统集成?
- 2.描述与每个应用和或系统的集成水平和集成策略
- 3.用户库在地理上如何分布?
- 4.该系统对企业内部或外部的其他用户团体有什么战略重要性?
- 5.需要什么计算资源来向企业内部用户提供系统服务?是在企业外部且使用企业计算资产?还是在企业外部使用其自身资产?
- 6.本地交付环境外的用户如何才能访问你的应用和数据?
- 7.该应用的预期寿命是什么?
- 8.描述适应用户库、存储数据和交付系统技术方面变更的设计
- 9.用户库规模及其期望性能水平是什么?
- 10.使用什么性能和压力测试技术?
- 11.软件和数据组件的总体组织是什么
- 12.整体服务和系统配置是什么?
- 13.如何配置软件和数据并将其映射到服务和系统构型?
- 14.该系统需要什么专利技术(硬件和软件)?
- 15.描述如何才能在一段时间之后复制并重新部署该软件的每一个版本
- 16.描述现有用户库以及期待该用户库在未来三到五年内如何更改
- 17.描述用户库的当前地理分布以及期待该用户库在未来三到五年内如何更改
- 18.描述有多少当前或未来用户需要使用移动应用，或谁需要离线工作。
- 19.描述应用一般做什么、应用的主要组件以及主要数据流。
- 20.描述应用中所包括并使得能监控应用健康及性能的仪器。
- 21.描述系统的业务理由
- 22.根据初始开发成本和长期维修成本，描述在其他选项中选择系统开发语言的理由依据。
- 23.描述用于提出系统架构及系统架构产品选择阶段的系统分析流程
- 24.除了最初的客户，谁还可以使用该系统或者从中受益?
- 25.以浏览模式和更新模式使用该系统的用户比例是多大?
- 26.事务性要求的典型长度是多少?
- 27.是否需要保证数据发送或更新?或者系统能否承受故障
- 28.系统的正常运行时间需求是什么?
- 29.描述系统架构在哪些方面符合或不符合标准
- 30.描述该项目使用的项目规划和分析途径
- 2. 处理器/服务器/客户端
- 1.描述客户端服务器应用架构
- 2.在图上添加注释，以说明在何处执行应用功能性
- 3. 客户端
- 1.用户设备是否执行了除演示外的功能?
- 2.描述正在提供的数据和流程帮助设施
- 3.描述屏幕对屏幕的导航技术。
- 4.描述用户如何在该应用与其他应用之间进行导航
- 5.如何从用户设备启动该应用和其他应用?
- 6.是否具有应用间数据和流程共享能力?如果有，描述正在共享什么以及借助了什么技巧技术。
- 7.描述传送到客户端的数据量。
- 8.支持该应用的本地数据存储的附加需求有哪些?
- 9.支持该应用的本地软件存储内存的附加需求有哪些?
- 10.是否具有由影响应用用户的其他应用需求或情况引起的已知硬件软件冲突或能力限制?运
- 11.描述如何对展现层的界面外观与其他现有应用的界面外观进行对比
- 12.描述客户端需要支持异步和或同步通信的程度。
- 13.描述如何将系统展现层与该系统其他计算层或数据传送层分开。
- 4. 应用服务器
- 1.展现层和应用层能否/是否在单独处理器上运行?
- 2.应用层和数据访问层能否/是否在单独的处理器上运行?
- 3.能否将该应用独立于所有其他应用放置在应用服务器上?如果不能，请解释依赖性。
- 4.能否很容易地增加更多并行应用服务器吗?如果可以，负载平衡机制是什么?
- 5.是否已测量该应用产生的资源需求?测量值?如果已测量，是否已在应用层级和总体层级确认了计划服务器能力?
- 5. 数据服务器
- 1.是否具有必须共享数据服务器的其他应用?如果有，识别这些应用并描述数据和数据访问需求，
- 2.是否已测量该应用产生的资源需求?测量值?如果已测量，是否已在应用层级和总体层级确认了计划服务器能力?
- 6. COTS (若适用)
- 1.厂商是否有实力且稳定?
- 2.当厂商移交时企业能否收到源代码?
- 3.本软件是否为企业使用而配置?
- 4是否具有会妨碍使用本软件的任何异常A&D数据或流程?
- 本软件目前是否可用?
- 5.是否已使用/证实了与企业类似的容量可用性服务层级需求?
- 描述厂商的以往财务情况和市场份额历史情况
系统工程方法和工具检查单
- 1.当前开展业务的方式是否存在衡量标准?
- 2.系统所有者是否已创建用于指导该项目的评价准则?描述将如何使用这些评价准则。
- 3.为了更好地利用现有工作，是否己对现有架构进行研究?描述用于研究和理解的方法。架构是否集成?如果集成，请解释将使用的方法
- 4.描述用于该项目的方法
- 用于定义业务战略
- 用于定义需要改进的领域
- 用于定义基线和目标业务流程
- 用于定义过渡流程
- 用于管理项目
- 用于团队沟通
- 用于知识管理、变更管理和构型管理
- 用于软件开发
- 用于引用标准和指导说明
- 用于交付物的质量保证
- 用于设计评审和交付十物验收
- 用于获取衡量标准
- 5.该方法是否文件化并向每个团队成员发布这些方法?
- 6.团队成员对这些方法的熟悉程度如何?
- 7.什么流程适当地确保与这些方法合规?
- 8.描述到项目和预期发布结束为止适当支持这些方法使用的基础设施
- 如何提供咨询和故障分析?
- 如何协调培训?
- 如何对变更及增强内容进行合并和级联?
- 如何获取和交流经验教训?
- 9.该项目正在使用什么工具?(规定版本和平台。)团队成员对这些工具的熟悉程度如何?
- 10.描述到项目和预期发布结束为止适当支持这些工具使用的基础设施
- 如何提供咨询和故障分析?
- 如何协调培训?
- 如何对变更及增强内容进行合并和级联?
- 如何获取和交流经验教训?
- 11.描述该项目如何促进其交付物和可交付内容的复用
- 12.该项目实施后，架构设计还“有效”吗?描述将变更重新并入架构设计所用的方法
- 13.当前流程是否被定义?
- 14.是否将这些问题进行文件化、评估并关联到当前流程?如果没有，如何知道你正在修理已被破坏的事物?
- 15，是否识别现有的/计划的流程改进活动并将其关联到当前流程?如果没有，如何知道该活动不与其他工作说明书相互矛盾或者冗余?
- 16.是否具有现行衡量标准?是否具有预测衡量标准?如果没有，你如何知道正在改善事物?
- 17.用于适当收集、评价和报告衡量标准的流程是什么?
- 18.新设计会对现有业务流程、组织和信息系统产生什么影响?是否已将这些影响文件化并与所有者分享