02工作产品评审指南

目录1.概述42.需求评审42.1完整性42.2正确性42.3质量指标42.4可跟踪性42.5其他43.特性需求评审54.工作细目结构评审55.系统结构设计评审55.1系统结构55.2正确性55.3设计标准和可跟踪性55.4逻辑性55.5界面65.6清晰度66.概要设计评审66.1结构66.2数据66.3正确性和完整性66.4标准和可跟踪性76.5界面76.6健壮性77.详细设计评审77.1结构77.2数据77.3正确性和完整性77.4标准和可跟踪性87.5健壮性88.编码评审88.1规范性88.2完整性88.3合理性88.4可靠性88.5可维护性99.测试计划评审99.1测试计划99.2正确性和完整性99.3标准和可跟踪性99.4Regression 测试99.5资源和进度910.项目计划评审1010.1清晰度1010.2完整性1010.3一致性101. 概述工作产品是在项目开发和管理过程中产生的各种产物, 其中包括提交给最终客户或用户的文档、报告、编码等, 也包括项目组内部使用的各种文档、报告、工具程序、测试用例等。 本文提供了针对性的工作产品评审指南作为非正式、正式评审的参照。2. 需求评审2.1 完整性 所有的内部文档引用是正确的和最新的； 所有的需求描述是恰到好处的并提供适度的细节； 需求描述为设计提供了足够的内容和信息； 实现需求的优先级已被定义； 系统对外界面已被确定, 如软件, 硬件和通讯截面等； 系统商业流程已被清晰表达； 需求说明书定义了所有的、已知的客户和系统需要； 可预知的错误出现时, 系统的应有反应已全部定义. 如用户错误输入信用卡号码, 系统应友善的提醒用户信用卡号码出错。2.2 正确性 各个需求之间不矛盾； 各需求描述是清晰的、连贯的和没有歧义的； 各需求可被测试、演示、评审、分析； 各需求是在项目的范围内； 必要的信息不缺项, 没有待定的需求； 所有需求可在现有约束和假定下实现； 所有的错误信息说明是直接的、恰当的和可被理解的。2.3 质量指标 所有的性能指标已被明确和恰当的定义； 系统安全和保密的要求已被明确规定； 其他的隐含的质量指标已被定义并说明可接受的标准；2.4 可跟踪性 每个需求已被单独和正确确认； 每个需求能被跟踪至概要设计相关文档, 如功能设计、数据库设计等。2.5 其他 所有的需求都是需求而非解决方案或设计； 和响应时间相关的需求已被定义和量化； 和国际相关的为题已被确认, 如不同的语言界面等。 所有定义的软件需求用软件来实现是可行和恰当的。3. 特性需求评审l 特征需求说明书符合规范要求；l 特征需求说明书正确地反映了用户的需求，没有错误；l 特征需求说明书完备地反映了用户的需求，没有遗漏；l 特征需求说明书前后一致并与相关文档是一致的；l 特征需求说明书描述清晰，没有歧义。4. 系统结构设计评审4.1 系统结构 系统结构设计是完整的, 如允许实现全部的需求； 系统已被足够的分解； 系统结构设计为概要设计提供足够的基础； 系统结构具有足够的伸缩性； 系统维护的问题已被确认； 各子程序能被分阶段测试。4.2 正确性 结构设计不含多余结构； 所有的稳定性和性能要求已被考虑； 所有的安全要求已被考虑； 结构设计包含了所有的约束； 结构设计是全面的、正确的和不模糊的； 所有的数据结构已被定义, 没有不必要的数据结构定义。4.3 设计标准和可跟踪性 所有的结构设计标准已被合理采纳； 结构设计可反向追踪至需求说明书。4.4 逻辑性 没有丢失或不正确的逻辑； 所有可能的状态和情况已被考虑。4.5 界面 所有的界面是清楚的和已被定义的； 最小量的数据在界面上交换； 使用最少的系统变量。4.6 清晰度 系统结构, 包括数据交换、控制和界面以被清晰定义； 设计被多角度、多方面但相一致的表达； 系统设计约束和假定、依赖性、权衡利弊均已被记录和归档。5. 概要设计评审5.1 结构 数据结构已被清晰的分解和定义； 结构已被恰当分解并可作为详细设计的依据； 每一个模块已被清楚描述并可测试； 模块分解符合相应标准和规范。5.2 数据 系统常量和参量已被参数化； 所有的数据已被适当的定义； 数据结构和参数的命名是有意义的并符合命名标准。5.3 正确性和完整性 概要设计是完整的, 如将实现所有的需求； 所有的基础要求已被确认, 如备份, 检查点等； 所有的错误信息是唯一的和有意义的； 所有的稳定性和性能要求已被设计； 国际化要求已被适当的考虑和设计； 文件维护的程序已被确定； 过程处理的优先级已被确定； 分析表明系统会达到要求的处理能力、反应时间和准确性； 所有的保密要求已被设计； 概要设计考虑了所有的约束； 概要设计的模块不含多余的已在其他子系统或模块中设计的部分； 概要设计为详细设计提供了足够的基础； 维护的问题已被考虑； 概要设计是全面的、正确的和不模糊的； 概要设计是可伸缩的； 概要设计是可检验的。5.4 标准和可跟踪性 所有的设计标准已被合理采纳； 用户界面符合项目标准； 所有的概要设计部分可反向追踪至需求说明书。5.5 界面 所有的界面已被清楚定义； 最少的数据量在界面被交换； 最少的系统变量被使用。5.6 健壮性 自我测试、失败-安全、降级模式的要求在设计中已被考虑； 出错处理机制已被使用； 非正常现象能被合理的处理并不会导致破坏性后果。6. 详细设计评审6.1 结构 伪代码在此级设计中是适当的和相一致的。6.2 数据 系统数据不包括的部分已被加入； 所有的数据已被适当的定义和初始化； 所有定义的数据全被使用； 数据及参量的命名在模块内部和界面相一致； 缺省值的使用是必要的和正确的。6.3 正确性和完整性 详细设计完整的和正确的实现概要设计的要求； 每个模块的对外功能要求都已完成并可测试； 所有的数理运算都已做精确性分析； 关键的时间要求都已做分析； 概要设计中的内存使用已被实现； 所有的函数都已定义； 各函数间是逻辑上独立的； 维护的问题已被处理； 各模块具有内聚性； 各模块具有外耦合性； 详细设计可被测试； 逻辑是正确的、清晰的和完整的； 循环语句退出点是正确的和必执行的； 单元测试已被定义； 所有的逻辑是可测试的。6.4 标准和可跟踪性 所有的详细设计标准已被适当采纳； 所有的协议符合项目标准； 所有的详细设计能被反向追踪至概要设计和需求说明书。6.5 健壮性 错误处理被有效和正确处理并不会导致破坏性后果； 模块能捕获错误信息和修正； 非正常现象能被合理的处理并不会导致破坏性后果。7. 编码评审7.1 规范性 程序满足代码书写规范。7.2 完整性 程序已处理了在需求说明中的所有条件、功能，包括后来的变更； 已书写了必要的注释； 注释与程序逻辑相符合； 已完成了所有设计时的功能； 已实现了所有客户操作界面。7.3 合理性 已校验了输入参数； 子程序中对错误的检测结果已报告给调用它的程序段； 没有未初始化的变量； 不存在死循环； 每一个程序段都有一个入口和一个结束点； 不存在没有使用过的变量声明； 程序已模块化； 代码有重用性。7.4 可靠性 代码与不同平台上字符和字的长度无关或已妥善处理； 已对错误进行了处理；7.5 可维护性 程序已正确缩进； 在每个程序段的开头，有该段程序功能的描述，包括作者、调用的程序、被调用的程序，等等； 变量的名称具有描述性（即可以从变量的名称看出该变量的含义）。8. 测试计划评审8.1 测试计划 测试的方式是可行的； 测试的目标已确定； 测试的依靠性已确定； 测试环境已被定义； 测试暂停和重新启动已确定；8.2 正确性和完整性 足够的测试已能包含各个反面并能确认功能已能在其相应的环境中正常实现； 集成的测试程序已保证各界面测试符合相应的设计； 功能的描述可被测试并已书写在测试计划中, 具有正确性和完整性； 所有的测试进出条件是足够的和可实现的； 所有的非测试项目都已书写文档； 测试计划是完整的, 正确的和不模糊的； 有效的和无效的输入都已测试； 所有的测试通过和不通过条件已定义。8.3 标准和可跟踪性 测试标准已被使用； 测试计划列出所引用的标准、文档资料； 所有的需求已在验收测试计划中确定； 各测试用例可反向追踪到需求说明书。8.4 Regression 测试 足够的和适当的测试用例被用于测试和确认已被测试的功能； 所有的代码改变都已被测试, 特别是界面部分。8.5 资源和进度 所有的资源都已考虑, 包括人力资源和软件、硬件、网络等； 测试工具的开发都已计划并有适当的开发周期； 开发或采购测试工具都已计划并可执行； 测试角色和分工都已确认。9. 项目计划评审9.1 清晰度 项目计划已被适当分解, 详细和复杂程度适中； 各分计划的内容足够清晰和