02工作产品评审指南(doc)
综合能力考核表详细内容
02工作产品评审指南(doc)
目录 1. 概述 4 2. 需求评审 4 2.1 完整性 4 2.2 正确性 4 2.3 质量指标 4 2.4 可跟踪性 4 2.5 其他 4 3. 特性需求评审 5 4. 工作细目结构评审 5 5. 系统结构设计评审 5 5.1 系统结构 5 5.2 正确性 5 5.3 设计标准和可跟踪性 5 5.4 逻辑性 5 5.5 界面 6 5.6 清晰度 6 6. 概要设计评审 6 6.1 结构 6 6.2 数据 6 6.3 正确性和完整性 6 6.4 标准和可跟踪性 7 6.5 界面 7 6.6 健壮性 7 7. 详细设计评审 7 7.1 结构 7 7.2 数据 7 7.3 正确性和完整性 7 7.4 标准和可跟踪性 8 7.5 健壮性 8 8. 编码评审 8 8.1 规范性 8 8.2 完整性 8 8.3 合理性 8 8.4 可靠性 8 8.5 可维护性 9 9. 测试计划评审 9 9.1 测试计划 9 9.2 正确性和完整性 9 9.3 标准和可跟踪性 9 9.4 Regression 测试 9 9.5 资源和进度 9 10. 项目计划评审 10 10.1 清晰度 10 10.2 完整性 10 10.3 一致性 10 概述 工作产品是在项目开发和管理过程中产生的各种产物, 其中包括提交给最终客户或用户的文档、报告、编码等, 也包括项目组内部使用的各种文档、报告、工具程序、测试用例等。 本文提供了针对性的工作产品评审指南作为非正式、正式评审的参照。 需求评审 1 完整性 o 所有的内部文档引用是正确的和最新的; o 所有的需求描述是恰到好处的并提供适度的细节; o 需求描述为设计提供了足够的内容和信息; o 实现需求的优先级已被定义; o 系统对外界面已被确定, 如软件, 硬件和通讯截面等; o 系统商业流程已被清晰表达; o 需求说明书定义了所有的、已知的客户和系统需要; o 可预知的错误出现时, 系统的应有反应已全部定义. 如用户错误输入信用卡号码, 系统应友善的提醒用户信用卡号码出错。 2 正确性 o 各个需求之间不矛盾; o 各需求描述是清晰的、连贯的和没有歧义的; o 各需求可被测试、演示、评审、分析; o 各需求是在项目的范围内; o 必要的信息不缺项, 没有待定的需求; o 所有需求可在现有约束和假定下实现; o 所有的错误信息说明是直接的、恰当的和可被理解的。 3 质量指标 o 所有的性能指标已被明确和恰当的定义; o 系统安全和保密的要求已被明确规定; o 其他的隐含的质量指标已被定义并说明可接受的标准; 4 可跟踪性 o 每个需求已被单独和正确确认; o 每个需求能被跟踪至概要设计相关文档, 如功能设计、数据库设计等。 5 其他 o 所有的需求都是需求而非解决方案或设计; o 和响应时间相关的需求已被定义和量化; o 和国际相关的为题已被确认, 如不同的语言界面等。 o 所有定义的软件需求用软件来实现是可行和恰当的。 特性需求评审 o 《特征需求说明书》符合规范要求; o 《特征需求说明书》正确地反映了用户的需求,没有错误; o 《特征需求说明书》完备地反映了用户的需求,没有遗漏; o 《特征需求说明书》前后一致并与相关文档是一致的; o 《特征需求说明书》描述清晰,没有歧义。 系统结构设计评审 1 系统结构 o 系统结构设计是完整的, 如允许实现全部的需求; o 系统已被足够的分解; o 系统结构设计为概要设计提供足够的基础; o 系统结构具有足够的伸缩性; o 系统维护的问题已被确认; o 各子程序能被分阶段测试。 2 正确性 o 结构设计不含多余结构; o 所有的稳定性和性能要求已被考虑; o 所有的安全要求已被考虑; o 结构设计包含了所有的约束; o 结构设计是全面的、正确的和不模糊的; o 所有的数据结构已被定义, 没有不必要的数据结构定义。 3 设计标准和可跟踪性 o 所有的结构设计标准已被合理采纳; o 结构设计可反向追踪至需求说明书。 4 逻辑性 o 没有丢失或不正确的逻辑; o 所有可能的状态和情况已被考虑。 5 界面 o 所有的界面是清楚的和已被定义的; o 最小量的数据在界面上交换; o 使用最少的系统变量。 6 清晰度 o 系统结构, 包括数据交换、控制和界面以被清晰定义; o 设计被多角度、多方面但相一致的表达; o 系统设计约束和假定、依赖性、权衡利弊均已被记录和归档。 概要设计评审 1 结构 o 数据结构已被清晰的分解和定义; o 结构已被恰当分解并可作为详细设计的依据; o 每一个模块已被清楚描述并可测试; o 模块分解符合相应标准和规范。 2 数据 o 系统常量和参量已被参数化; o 所有的数据已被适当的定义; o 数据结构和参数的命名是有意义的并符合命名标准。 3 正确性和完整性 o 概要设计是完整的, 如将实现所有的需求; o 所有的基础要求已被确认, 如备份, 检查点等; o 所有的错误信息是唯一的和有意义的; o 所有的稳定性和性能要求已被设计; o 国际化要求已被适当的考虑和设计; o 文件维护的程序已被确定; o 过程处理的优先级已被确定; o 分析表明系统会达到要求的处理能力、反应时间和准确性; o 所有的保密要求已被设计; o 概要设计考虑了所有的约束; o 概要设计的模块不含多余的已在其他子系统或模块中设计的部分; o 概要设计为详细设计提供了足够的基础; o 维护的问题已被考虑; o 概要设计是全面的、正确的和不模糊的; o 概要设计是可伸缩的; o 概要设计是可检验的。 4 标准和可跟踪性 o 所有的设计标准已被合理采纳; o 用户界面符合项目标准; o 所有的概要设计部分可反向追踪至需求说明书。 5 界面 o 所有的界面已被清楚定义; o 最少的数据量在界面被交换; o 最少的系统变量被使用。 6 健壮性 o 自我测试、失败-安全、降级模式的要求在设计中已被考虑; o 出错处理机制已被使用; o 非正常现象能被合理的处理并不会导致破坏性后果。 详细设计评审 1 结构 o 伪代码在此级设计中是适当的和相一致的。 2 数据 o 系统数据不包括的部分已被加入; o 所有的数据已被适当的定义和初始化; o 所有定义的数据全被使用; o 数据及参量的命名在模块内部和界面相一致; o 缺省值的使用是必要的和正确的。 3 正确性和完整性 o 详细设计完整的和正确的实现概要设计的要求; o 每个模块的对外功能要求都已完成并可测试; o 所有的数理运算都已做精确性分析; o 关键的时间要求都已做分析; o 概要设计中的内存使用已被实现; o 所有的函数都已定义; o 各函数间是逻辑上独立的; o 维护的问题已被处理; o 各模块具有内聚性; o 各模块具有外耦合性; o 详细设计可被测试; o 逻辑是正确的、清晰的和完整的; o 循环语句退出点是正确的和必执行的; o 单元测试已被定义; o 所有的逻辑是可测试的。 4 标准和可跟踪性 o 所有的详细设计标准已被适当采纳; o 所有的协议符合项目标准; o 所有的详细设计能被反向追踪至概要设计和需求说明书。 5 健壮性 o 错误处理被有效和正确处理并不会导致破坏性后果; o 模块能捕获错误信息和修正; o 非正常现象能被合理的处理并不会导致破坏性后果。 编码评审 1 规范性 o 程序满足代码书写规范。 2 完整性 o 程序已处理了在需求说明中的所有条件、功能,包括后来的变更; o 已书写了必要的注释; o 注释与程序逻辑相符合; o 已完成了所有设计时的功能; o 已实现了所有客户操作界面。 3 合理性 o 已校验了输入参数; o 子程序中对错误的检测结果已报告给调用它的程序段; o 没有未初始化的变量; o 不存在死循环; o 每一个程序段都有一个入口和一个结束点; o 不存在没有使用过的变量声明; o 程序已模块化; o 代码有重用性。 4 可靠性 o 代码与不同平台上字符和字的长度无关或已妥善处理; o 已对错误进行了处理; 5 可维护性 o 程序已正确缩进; o 在每个程序段的开头,有该段程序功能的描述,包括作者、调用的程序、被调 用的程序,等等; o 变量的名称具有描述性(即可以从变量的名称看出该变量的含义)。 测试计划评审 1 测试计划 o 测试的方式是可行的; o 测试的目标已确定; o 测试的依靠性已确定; o 测试环境已被定义; o 测试暂停和重新启动已确定; 2 正确性和完整性 o 足够的测试已能包含各个反面并能确认功能已能在其相应的环境中正常实现; o 集成的测试程序已保证各界面测试符合相应的设计; o 功能的描述可被测试并已书写在测试计划中, 具有正确性和完整性; o 所有的测试进出条件是足够的和可实现的; o 所有的非测试项目都已书写文档; o 测试计划是完整的, 正确的和不模糊的; o 有效的和无效的输入都已测试; o 所有的测试通过和不通过条件已定义。 3 标准和可跟踪性 o 测试标准已被使用; o 测试计划列出所引用的标准、文档资料; o 所有的需求已在验收测试计划中确定; o 各测试用例可反向追踪到需求说明书。 4 Regression 测试 o 足够的和适当的测试用例被用于测试和确认已被测试的功能; o 所有的代码改变都已被测试, 特别是界面部分。 5 资源和进度 o 所有的资源都已考虑, 包括人力资源和软件、硬件、网络等; o 测试工具的开发都已计划并有适当的开发周期; o 开发或采购测试工具都已计划并可执行; o 测试角色和分工都已确认。 项目计划评审 1 清晰度 o 项目计划已被适当分解, 详细和复杂程度适中; o 各分计划的内容足够清晰和不模糊; o 各分计划之间的关系很清楚; o 各分计划被合理排序并相一致。 2 完整性 o 所有的假设已被定义; o 所有的估算已被文档化, 包括数据和估算方法。 o 项目计划符合各标准、过程、程序的要求; o 计划中没有不相关内容。 3 一致性 o 各计划中相关的部分是一致的; o 计划的内容和相关文档中的内容相一致; o 计划的内容和计划的范围和目标相一致; o 计划的书写符合相应的书写规范并符合读者的习惯。
02工作产品评审指南(doc)
目录 1. 概述 4 2. 需求评审 4 2.1 完整性 4 2.2 正确性 4 2.3 质量指标 4 2.4 可跟踪性 4 2.5 其他 4 3. 特性需求评审 5 4. 工作细目结构评审 5 5. 系统结构设计评审 5 5.1 系统结构 5 5.2 正确性 5 5.3 设计标准和可跟踪性 5 5.4 逻辑性 5 5.5 界面 6 5.6 清晰度 6 6. 概要设计评审 6 6.1 结构 6 6.2 数据 6 6.3 正确性和完整性 6 6.4 标准和可跟踪性 7 6.5 界面 7 6.6 健壮性 7 7. 详细设计评审 7 7.1 结构 7 7.2 数据 7 7.3 正确性和完整性 7 7.4 标准和可跟踪性 8 7.5 健壮性 8 8. 编码评审 8 8.1 规范性 8 8.2 完整性 8 8.3 合理性 8 8.4 可靠性 8 8.5 可维护性 9 9. 测试计划评审 9 9.1 测试计划 9 9.2 正确性和完整性 9 9.3 标准和可跟踪性 9 9.4 Regression 测试 9 9.5 资源和进度 9 10. 项目计划评审 10 10.1 清晰度 10 10.2 完整性 10 10.3 一致性 10 概述 工作产品是在项目开发和管理过程中产生的各种产物, 其中包括提交给最终客户或用户的文档、报告、编码等, 也包括项目组内部使用的各种文档、报告、工具程序、测试用例等。 本文提供了针对性的工作产品评审指南作为非正式、正式评审的参照。 需求评审 1 完整性 o 所有的内部文档引用是正确的和最新的; o 所有的需求描述是恰到好处的并提供适度的细节; o 需求描述为设计提供了足够的内容和信息; o 实现需求的优先级已被定义; o 系统对外界面已被确定, 如软件, 硬件和通讯截面等; o 系统商业流程已被清晰表达; o 需求说明书定义了所有的、已知的客户和系统需要; o 可预知的错误出现时, 系统的应有反应已全部定义. 如用户错误输入信用卡号码, 系统应友善的提醒用户信用卡号码出错。 2 正确性 o 各个需求之间不矛盾; o 各需求描述是清晰的、连贯的和没有歧义的; o 各需求可被测试、演示、评审、分析; o 各需求是在项目的范围内; o 必要的信息不缺项, 没有待定的需求; o 所有需求可在现有约束和假定下实现; o 所有的错误信息说明是直接的、恰当的和可被理解的。 3 质量指标 o 所有的性能指标已被明确和恰当的定义; o 系统安全和保密的要求已被明确规定; o 其他的隐含的质量指标已被定义并说明可接受的标准; 4 可跟踪性 o 每个需求已被单独和正确确认; o 每个需求能被跟踪至概要设计相关文档, 如功能设计、数据库设计等。 5 其他 o 所有的需求都是需求而非解决方案或设计; o 和响应时间相关的需求已被定义和量化; o 和国际相关的为题已被确认, 如不同的语言界面等。 o 所有定义的软件需求用软件来实现是可行和恰当的。 特性需求评审 o 《特征需求说明书》符合规范要求; o 《特征需求说明书》正确地反映了用户的需求,没有错误; o 《特征需求说明书》完备地反映了用户的需求,没有遗漏; o 《特征需求说明书》前后一致并与相关文档是一致的; o 《特征需求说明书》描述清晰,没有歧义。 系统结构设计评审 1 系统结构 o 系统结构设计是完整的, 如允许实现全部的需求; o 系统已被足够的分解; o 系统结构设计为概要设计提供足够的基础; o 系统结构具有足够的伸缩性; o 系统维护的问题已被确认; o 各子程序能被分阶段测试。 2 正确性 o 结构设计不含多余结构; o 所有的稳定性和性能要求已被考虑; o 所有的安全要求已被考虑; o 结构设计包含了所有的约束; o 结构设计是全面的、正确的和不模糊的; o 所有的数据结构已被定义, 没有不必要的数据结构定义。 3 设计标准和可跟踪性 o 所有的结构设计标准已被合理采纳; o 结构设计可反向追踪至需求说明书。 4 逻辑性 o 没有丢失或不正确的逻辑; o 所有可能的状态和情况已被考虑。 5 界面 o 所有的界面是清楚的和已被定义的; o 最小量的数据在界面上交换; o 使用最少的系统变量。 6 清晰度 o 系统结构, 包括数据交换、控制和界面以被清晰定义; o 设计被多角度、多方面但相一致的表达; o 系统设计约束和假定、依赖性、权衡利弊均已被记录和归档。 概要设计评审 1 结构 o 数据结构已被清晰的分解和定义; o 结构已被恰当分解并可作为详细设计的依据; o 每一个模块已被清楚描述并可测试; o 模块分解符合相应标准和规范。 2 数据 o 系统常量和参量已被参数化; o 所有的数据已被适当的定义; o 数据结构和参数的命名是有意义的并符合命名标准。 3 正确性和完整性 o 概要设计是完整的, 如将实现所有的需求; o 所有的基础要求已被确认, 如备份, 检查点等; o 所有的错误信息是唯一的和有意义的; o 所有的稳定性和性能要求已被设计; o 国际化要求已被适当的考虑和设计; o 文件维护的程序已被确定; o 过程处理的优先级已被确定; o 分析表明系统会达到要求的处理能力、反应时间和准确性; o 所有的保密要求已被设计; o 概要设计考虑了所有的约束; o 概要设计的模块不含多余的已在其他子系统或模块中设计的部分; o 概要设计为详细设计提供了足够的基础; o 维护的问题已被考虑; o 概要设计是全面的、正确的和不模糊的; o 概要设计是可伸缩的; o 概要设计是可检验的。 4 标准和可跟踪性 o 所有的设计标准已被合理采纳; o 用户界面符合项目标准; o 所有的概要设计部分可反向追踪至需求说明书。 5 界面 o 所有的界面已被清楚定义; o 最少的数据量在界面被交换; o 最少的系统变量被使用。 6 健壮性 o 自我测试、失败-安全、降级模式的要求在设计中已被考虑; o 出错处理机制已被使用; o 非正常现象能被合理的处理并不会导致破坏性后果。 详细设计评审 1 结构 o 伪代码在此级设计中是适当的和相一致的。 2 数据 o 系统数据不包括的部分已被加入; o 所有的数据已被适当的定义和初始化; o 所有定义的数据全被使用; o 数据及参量的命名在模块内部和界面相一致; o 缺省值的使用是必要的和正确的。 3 正确性和完整性 o 详细设计完整的和正确的实现概要设计的要求; o 每个模块的对外功能要求都已完成并可测试; o 所有的数理运算都已做精确性分析; o 关键的时间要求都已做分析; o 概要设计中的内存使用已被实现; o 所有的函数都已定义; o 各函数间是逻辑上独立的; o 维护的问题已被处理; o 各模块具有内聚性; o 各模块具有外耦合性; o 详细设计可被测试; o 逻辑是正确的、清晰的和完整的; o 循环语句退出点是正确的和必执行的; o 单元测试已被定义; o 所有的逻辑是可测试的。 4 标准和可跟踪性 o 所有的详细设计标准已被适当采纳; o 所有的协议符合项目标准; o 所有的详细设计能被反向追踪至概要设计和需求说明书。 5 健壮性 o 错误处理被有效和正确处理并不会导致破坏性后果; o 模块能捕获错误信息和修正; o 非正常现象能被合理的处理并不会导致破坏性后果。 编码评审 1 规范性 o 程序满足代码书写规范。 2 完整性 o 程序已处理了在需求说明中的所有条件、功能,包括后来的变更; o 已书写了必要的注释; o 注释与程序逻辑相符合; o 已完成了所有设计时的功能; o 已实现了所有客户操作界面。 3 合理性 o 已校验了输入参数; o 子程序中对错误的检测结果已报告给调用它的程序段; o 没有未初始化的变量; o 不存在死循环; o 每一个程序段都有一个入口和一个结束点; o 不存在没有使用过的变量声明; o 程序已模块化; o 代码有重用性。 4 可靠性 o 代码与不同平台上字符和字的长度无关或已妥善处理; o 已对错误进行了处理; 5 可维护性 o 程序已正确缩进; o 在每个程序段的开头,有该段程序功能的描述,包括作者、调用的程序、被调 用的程序,等等; o 变量的名称具有描述性(即可以从变量的名称看出该变量的含义)。 测试计划评审 1 测试计划 o 测试的方式是可行的; o 测试的目标已确定; o 测试的依靠性已确定; o 测试环境已被定义; o 测试暂停和重新启动已确定; 2 正确性和完整性 o 足够的测试已能包含各个反面并能确认功能已能在其相应的环境中正常实现; o 集成的测试程序已保证各界面测试符合相应的设计; o 功能的描述可被测试并已书写在测试计划中, 具有正确性和完整性; o 所有的测试进出条件是足够的和可实现的; o 所有的非测试项目都已书写文档; o 测试计划是完整的, 正确的和不模糊的; o 有效的和无效的输入都已测试; o 所有的测试通过和不通过条件已定义。 3 标准和可跟踪性 o 测试标准已被使用; o 测试计划列出所引用的标准、文档资料; o 所有的需求已在验收测试计划中确定; o 各测试用例可反向追踪到需求说明书。 4 Regression 测试 o 足够的和适当的测试用例被用于测试和确认已被测试的功能; o 所有的代码改变都已被测试, 特别是界面部分。 5 资源和进度 o 所有的资源都已考虑, 包括人力资源和软件、硬件、网络等; o 测试工具的开发都已计划并有适当的开发周期; o 开发或采购测试工具都已计划并可执行; o 测试角色和分工都已确认。 项目计划评审 1 清晰度 o 项目计划已被适当分解, 详细和复杂程度适中; o 各分计划的内容足够清晰和不模糊; o 各分计划之间的关系很清楚; o 各分计划被合理排序并相一致。 2 完整性 o 所有的假设已被定义; o 所有的估算已被文档化, 包括数据和估算方法。 o 项目计划符合各标准、过程、程序的要求; o 计划中没有不相关内容。 3 一致性 o 各计划中相关的部分是一致的; o 计划的内容和相关文档中的内容相一致; o 计划的内容和计划的范围和目标相一致; o 计划的书写符合相应的书写规范并符合读者的习惯。
02工作产品评审指南(doc)
[下载声明]
1.本站的所有资料均为资料作者提供和网友推荐收集整理而来,仅供学习和研究交流使用。如有侵犯到您版权的,请来电指出,本站将立即改正。电话:010-82593357。
2、访问管理资源网的用户必须明白,本站对提供下载的学习资料等不拥有任何权利,版权归该下载资源的合法拥有者所有。
3、本站保证站内提供的所有可下载资源都是按“原样”提供,本站未做过任何改动;但本网站不保证本站提供的下载资源的准确性、安全性和完整性;同时本网站也不承担用户因使用这些下载资源对自己和他人造成任何形式的损失或伤害。
4、未经本网站的明确许可,任何人不得大量链接本站下载资源;不得复制或仿造本网站。本网站对其自行开发的或和他人共同开发的所有内容、技术手段和服务拥有全部知识产权,任何人不得侵害或破坏,也不得擅自使用。
我要上传资料,请点我!
管理工具分类
ISO认证课程讲义管理表格合同大全法规条例营销资料方案报告说明标准管理战略商业计划书市场分析战略经营策划方案培训讲义企业上市采购物流电子商务质量管理企业名录生产管理金融知识电子书客户管理企业文化报告论文项目管理财务资料固定资产人力资源管理制度工作分析绩效考核资料面试招聘人才测评岗位管理职业规划KPI绩效指标劳资关系薪酬激励人力资源案例人事表格考勤管理人事制度薪资表格薪资制度招聘面试表格岗位分析员工管理薪酬管理绩效管理入职指引薪酬设计绩效管理绩效管理培训绩效管理方案平衡计分卡绩效评估绩效考核表格人力资源规划安全管理制度经营管理制度组织机构管理办公总务管理财务管理制度质量管理制度会计管理制度代理连锁制度销售管理制度仓库管理制度CI管理制度广告策划制度工程管理制度采购管理制度生产管理制度进出口制度考勤管理制度人事管理制度员工福利制度咨询诊断制度信息管理制度员工培训制度办公室制度人力资源管理企业培训绩效考核其它
精品推荐
下载排行
- 1社会保障基础知识(ppt) 16695
- 2安全生产事故案例分析(ppt 16695
- 3行政专员岗位职责 16695
- 4品管部岗位职责与任职要求 16695
- 5员工守则 16695
- 6软件验收报告 16695
- 7问卷调查表(范例) 16695
- 8工资发放明细表 16695
- 9文件签收单 16695
- 10跟我学礼仪 16695