《软件产品项目考核维度.docVIP

表一：项目评价维度表 工作计划及总结 提交情况 （5%） 项目工作计划执行 及完成情况 （50%） 项目完成质量情况 （30%） 项目会议执行情况 （5%） 项目时效情况 （5%） 其它项目工作需求 响应情况 （5%） 最终得分 评分部门 计划、需求、评审、总结遗漏次数　 文档、代码、注释、资源　 详见表2 　详见表3 　 与承诺里程碑时间点一致：是、否。 严重bug平均关闭时间这个维度代表项目组解决bug的效率，如果时间太长，说明项目组对bug重视不够 说明 与式样书比较20%　 有创造性的功能10% 与前续项目比较5%； 与行业同类产品比较5% 数量与项目裁剪表、RTM比较10%。 文档质量10% 与编码规范比较　 UML语言描述 　千行注释率不得低于10 资源备份：有、无 版本备份：有、无 　 评分标准 电子警察组 CAD绘图组 虚拟漫游组 3D动画组 表三：完成质量维度表 严重bug数 / 测试用例数出现的严重bug数 / 严重bug总数被reopen的bug / bug总数 测试工作量（人） / 测试用例数 说明 这个维度代表了一个项目的严重bug数量是否正常，让测试用例参与计算，是为了平衡规模不同的项目的数据。“三轮测试”，三轮的目标分别是：发现bug、验证bug、稳定回归。如果在第三轮回归的时候，还出现大量严重bug，那肯定是不正常的，也会对质量构成巨大风险。这个数字应该要控制在一个很低的水平。reopen指开发fix后，测试验证不通过，或者是已经close的bug又复发。这个维度也应该被控制在一个很低的水平，如果偏高，说明开发修复bug的效率偏低，代码不稳定，发布后出现bug的几率增加这个维度代表投入的测试资源是否充足，这里的工作量，指的是从测试设计到测试执行的所有人月数。如果数字过低，说明测试资源紧张，无法保证测试质量；如果过高，说明有可能测试效率低，测试经理需要进行解释。这个维度 评分标准 电子警察组 CAD绘图组 虚拟漫游组 3D动画组 1．BUG等级划分建议： 　　目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 　　● 致命(可对应目前BUG体系中的“非常严重”)： 　　致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 　　具体基本上可分为： 　　○ 严重花屏 　　○ 内存泄漏 　　○ 用户数据丢失或破坏 　　○ 系统崩溃/死机/冻结 　　○ 模块无法启动或异常退出 　　○ 严重的数值计算错误 　　○ 功能设计与需求严重不符 　　○ 其它导致无法测试的错误 　　● 严重（可对应目前BUG体系中的“严重”） 　　严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 　　具体基本上可分为： 　　○ 功能未实现 　　○ 功能错误 　　○ 系统刷新错误 　　○ 语音或数据通讯错误 　　○ 轻微的数值计算错误 　　○ 系统所提供的功能或服务受明显的影响 　　● 一般（可对应于目前BUG体系中的“普通”） 　　一般性问题主要为：界面、性能缺陷 　　具体基本上可分为： 　　○ 操作界面错误（包括数据窗口内列名定义、含义是否一致） 　　○ 边界条件下错误 　　○ 提示信息错误（包括未给出信息、信息提示错误等） 　　○ 长时间操作无进度提示 　　○ 系统未优化（性能问题） 　　○ 光标跳转设置不好，鼠标（光标）定位错误 　　● 提示（可对应于目前BUG体系中的“轻微及建议”） 　　提示性问题主要为：易用性及建议性问题 　　具体基本上可分为： 　　○ 界面格式等不规范 　　○ 辅助说明描述不清楚 　　○ 操作时未给用户提示 　　○ 可输入区域和只读区域没有明显的区分标志 　　○ 个别不影响产品理解的错别字 　　○ 文字排列不整齐等一些小问题 　　○ 建议 　　注意：对于结构及硬件问题，由于产品测试部仅是进行辅助测试，碰到此类问题时，均将于定位于等级“致命”，具体情况由结构及硬件部门相关人员确认。 分 部 门