一、概要设计的评审
软件概要设计监理的目的是对软件概要设计有关内容（重点是软件的结构、软件的功能、软件的结构、接口设计、接口关系等）、概要设计过程、概要设计活动、文档格式进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。
|
＃
|
检查项
|
Y/TBD/N/NA
|
|
|
清晰性
|
|
|
|
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
|
|
|
|
是否所有的假设、约束、策略及依赖都被记录在本文档了？
|
|
|
|
是否定义了总体设计目标？
|
|
|
|
完整性
|
|
|
|
是否所有的以前的TBD（待确定条目）都已经被解决了？
|
|
|
|
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
|
|
|
|
是否所有的TBD的影响都已经被评估了？
|
|
|
|
是否仍存在可能不可行的设计部分？
|
|
|
|
是否已记录设计时的权衡考虑？ 该文件是否包括了权衡选择的标准和不选择其它方案的原因？
|
|
|
|
依从性
|
|
|
|
是否遵守了项目的文档编写标准？
|
|
|
|
一致性
|
|
|
|
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
|
|
|
|
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
|
|
|
|
可行性
|
|
|
|
从进度、预算和技术角度上看该设计是否可行？
|
|
|
|
是否存在错误的、缺少的或不完整的逻辑？
|
|
|
|
数据使用
|
|
|
|
所有复合数据元素、参数以及对象的概念是否都已文档化？
|
|
|
|
是否还有任何需要的但还没有定义的数据结构，反之亦然？
|
|
|
|
是否已描述最低级别数据元素？是否已详细说明取值范围？
|
|
|
|
功能性
|
|
|
|
是否对每一下级模块进行了概要算法说明？
|
|
|
|
所选择的设计和算法能否满足所有的需求？
|
|
|
|
接口
|
|
|
|
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）？
|
|
|
|
是否已描述界面的功能特性？
|
|
|
|
界面将有利于问题解决吗？
|
|
|
|
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致？
|
|
|
|
是否所有的界面都提供了所要求的信息？
|
|
|
|
是否已说明内部各界面之间的关系？
|
|
|
|
界面的数量和复杂程度是否已减少到最小？
|
|
|
|
可维护性
|
|
|
|
该设计是否是模块化的？
|
|
|
|
这些模块具有高内聚度和低耦合度？
|
|
|
|
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
|
|
|
|
性能
|
|
|
|
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）？
|
|
|
|
可靠性
|
|
|
|
该设计能够提供错误检测和恢复（例如：输入输出检查）？
|
|
|
|
是否已考虑非正常情况？
|
|
|
|
是否所有的错误情况都被完整和准确地说明？
|
|
|
|
该设计是否满足该系统进行集成时所遵守的约定？
|
|
|
|
易测性
|
|
|
|
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？
|
|
|
|
该套系统是否能用增量型的方法来集成和测试？
|
|
|
|
可追溯性
|
|
|
|
是否各部分的设计都能追溯到需求说明书的需求？
|
|
|
|
是否所有的设计决策都能追溯到原来确定的权衡因素?
|
|
|
|
所继承设计的已知风险是否已确定和分析？
|
|
