一、形式审核
1、逻辑性
编写日期是否在《需求规格说明书》签字确认之后?与项目计划中的时间节点是否对应?
2、格式规范性
文档编号、版本号、页眉页脚、目录结构是否符合项目文档标准?图表编号是否连续?
3、完整性
是否包含引言、总体设计、接口设计、运行设计、数据结构设计、出错处理设计等必备章节?
4、引用文件
是否明确列出引用的标准、合同、需求规格说明书等依据文件?
5、术语一致性
术语、缩写词的定义是否与需求阶段文档保持一致?
二、内容审核
1、需求可追溯性
(1)需求覆盖度
概要设计是否覆盖了SRS中定义的全部功能需求与非功能需求?是否存在遗漏?
(2)双向追踪
是否建立了"需求→设计元素"的追踪矩阵?每个功能模块能否追溯到SRS中的具体需求项?
(3)一致性
一级/二级/三级功能划分是否与需求规格说明书一致?性能指标、安全指标是否不低于合同及SRS要求?
2、系统架构合理性
(1)架构模式
是否采用面向对象设计或结构化设计等先进方法?架构是否清晰表达了层次关系?
(2)模块划分
模块划分是否合理?高内聚、低耦合原则是否得到体现?
(3)扇入扇出
各模块的扇入、扇出数是否控制在合理范围(正常≤7)?
(4)可扩展性
是否考虑了系统演化性?对新需求和技术变更的适应性如何?
3、功能设计
(1)功能分配
每个功能需求是否都分配到了具体的软件部件(模块/组件)?
(2)功能描述
各模块的输入、输出、处理逻辑、异常处理是否描述清晰?
(3)处理流程
核心业务流程是否配有处理流程图或活动图?逻辑是否自洽?
4、接口设计
(1)用户接口
用户命令、语法结构、系统反馈信息是否定义清晰?
(2)外部接口
与外部系统、硬件设备的接口协议、数据格式、通信方式是否明确?
(3)内部接口
模块间接口的参数定义、数据类型、调用方式、时序关系、异常处理是否契约化?
(4)接口一致性
接口定义是否与《接口需求规格说明》(IRS)一致?
5、数据结构设计
(1)逻辑结构
数据实体、属性、关系的定义是否完整?E-R图或类图是否准确?
(2)物理结构
存储要求、访问方法、索引设计、数据冗余控制是否合理?
(3)数据一致性
与《数据库(顶层)设计说明》(DBDD)是否协调一致?
6、质量属性设计
(1)性能设计
响应时间、吞吐量、并发性能、资源占用是否满足SRS要求?是否有性能瓶颈分析?
(2)可靠性设计
是否说明了容错、冗余、故障恢复等可靠性措施?
(3)安全性设计
访问控制、数据加密、审计日志、防火墙等安全措施是否充分?
(4)可维护性
模块独立性、代码可读性、配置化管理是否考虑?是否设计了专门的检测点和维护模块?
(5)安全关键功能
对于安全关键功能,是否采用了必要的设计策略(如N版本程序、恢复块等)?
7、运行与出错处理设计
(1)运行设计
运行模块组合、运行控制方式、资源占用时间是否明确?
(2)出错处理
各类出错信息的含义、输出形式、处理措施是否定义?
(3)补救措施
是否有数据备份、降级运行、系统恢复与再启动方案?
8、设计决策与约束
(1)设计决策
关键技术选型(架构模式、数据库、中间件)是否有明确依据和权衡分析?
(2)假设与约束
设计所依赖的假设条件、技术约束是否已记录?
(3)TBD项
概要设计阶段尚未解决的问题是否已标识,并制定了后续解决计划?
三、监理审查方法
1、文档审查
对照检查表逐项审核,形成《概要(结构)设计检查表》。
2、联合评审
组织业主单位、承建单位、专家组召开评审会议,形成《概要(结构)设计评审意见》。
3、问题跟踪
对发现的问题建立问题跟踪记录,督促承建单位限期整改并复查。
4、监理意见
出具书面监理意见,明确"通过/修改后通过/不通过"结论。
四、监理输出文档
审查完成后,监理单位应根据实际情况形成以下文档:
概要(结构)设计检查表 — 记录逐项审查结果
概要(结构)设计评审意见 — 汇总评审结论与问题清单
概要设计确认表 — 各方签字确认
监理意见/监理通知单 — 对不合格项提出整改要求
会议纪要 — 记录评审过程
夜雨聆风