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

表一：项目评价维度表 工作计划及总结 提交情况 （5%） 项目工作计划执行 及完成情况 （50%） 项目完成质量情况 （30%） 项目会议执行情况 （5%） 项目时效情况 （5%） 其它项目工作需求 响应情况 （5%） 最终得分 评分部门 计划、需求、评审、总结遗漏次数　 文档、代码、注释、资源　 详见表2 　详见表3 　 与承诺里程碑时间点一致：是、否。 严重bug平均关闭时间：这个维度代表项目组解决bug的效率，如果时间太长，说明项目组对bug重视不够　 　 评分标准 0分：不提交； 3分：提交，但会延迟； 5分：按时提交； 10分：按时提交并加以提醒； 0分：50%及以下完成； 1-5分：以0分为基础每多完成10%加1分； 10分：100%完成； 10-15分：以10分为基础每多完成10%加1分； 0分：正常交付时点50%及以下完成； 1-5分：以0分为基础每多完成10%加1分； 10分：交付时点100%完成； 10-15分：以10分为基础每多完成10%加1分； 0分：从不执行； 3分：偶尔执行（每周、月1次）； 5分：每天执行，但部门员工少于50%时，会议自动取消； 10分：每天执行，当部门员工少于50%时，逐个了解情况并加以指导； 0分：平均出勤率少于80%，总体漏打卡少于10次，迟到少于10次； 1-10分：以0分为基础，每多2%且漏打卡、迟到每少1次，加1分； 0分：找多种理由不响应； 1-5分：经其它部门多次催促，延迟、被动响应； 6-9分：在协商交付时点延迟完成； 10分：接到需求能够进行有效沟通，能够在协商交付时点，100%完成； 10-15分：接到需求能够进行有效沟通，同时，提出合理化建议，超前完成； 电子警察组 CAD绘图组 虚拟漫游组 3D动画组 表二：完成情况维度表 功能实现数量 （30%） 界面友好度 （10%） 文档完整性 （20%） 代码可读性 （10%） 注释行数/代码量 （5%） 资源、版本备份 （5%） 最终得分 说明 与式样书比较20%　 有创造性的功能10% 与前续项目比较5%； 与行业同类产品比较5% 数量与项目裁剪表、RTM比较10%。 文档质量10% 与编码规范比较　 UML语言描述 　千行注释率不得低于10 资源备份：有、无 版本备份：有、无 　 评分标准 电子警察组 CAD绘图组 虚拟漫游组 3D动画组 表三：完成质量维度表 严重bug数 / 测试用例数 （20%） 系统出现的严重bug数 / 严重bug总数 （20%） 被reopen的bug / bug总数 （20%） 测试工作量（人日） / 测试用例数 （10%） 测试用例总数/ 代码总行数 （5%） 评审情况 （5%） 最终得分 说明 这个维度代表了一个项目的严重bug数量是否正常，让测试用例参与计算，是为了平衡规模不同的项目的数据。　 我部门采取“三轮测试”，三轮的目标分别是：单体测试发现bug、确认测试验证bug、系统测试稳定回归。如果在第三轮回归的时候，还出现大量严重bug，那肯定是不正常的，也会对质量构成巨大风险。这个数字应该要控制在一个很低的水平。 　reopen指开发fix后，测试验证不通过，或者是已经close的bug又复发。这个维度也应该被控制在一个很低的水平，如果偏高，说明开发修复bug的效率偏低，代码不稳定，发布后出现bug的几率增加 这个维度代表投入的测试资源是否充足，这里的工作量，指的是从测试设计到测试执行的所有人月数。如果数字过低，说明测试资源紧张，无法保证测试质量；如果过高，说明有可能测试效率低，测试经理需要进行解释。　 　这个维度为避免测试用例数量不足现象 　我部门评审分三个级别：走查，用于代码级别评审，组长必须参加。同行评审，用于设计级别评审，PM必须参加。管理评审，用于计划类、成果物提交类评审，经理必须参加 　 评分标准 电子警察组 CAD绘图组 虚拟漫游组 3D动画组 1．BUG等级划分建议： 　　目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标