开发人员质量考核办法
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
EQ: External Inquiry外部查询 需求分析人员 功能需求人员依据用例，聚焦人机交互类型（外部输入、外部输 出、外部查询）功能点，进行功能点分析。 商城功能点举例： 前台
添加购物车 提交订单 后台 查询订单 导出订单 开发经理 开发经理专注外部接口，内部逻辑，进行功能点补充。
商城功能点举例： 接口类
6. 在线数据输 在线数据输入率是多少？
3
入
7. 终端用户效 应用程序设计考虑到终端用户的效率 3
率
吗？
8. 在线更新 多少ILF被在线事务所更新？
3
9
处理复杂度 应用有很多的逻辑或者数据处理吗 3
10. 重用性
被开发的应用要满足一个或者多个应 3 用需要吗？
11. 易安装性 升级或者安装的难度如何？
代码质量考核办法
1. 开发人员代码考核办法
1.1. 目的
开发人员代码考核主要是针对在内部开发阶段代码质量进行考 核，目的是提升开发人员的质量意识，提高公司代码开发质量。
1.2. 考核内容
考核阶段主要是在公司内部的开发阶段（即在提交用户前），主 要考核的内容为：提交测试被打回、缺陷密度，BUG收敛率等方 面。在项目执行的每轮测试给出每个开发人员的缺陷密度、BUG收 敛率。在内部封版结束后质量保证部出每个开发人员BUG密度总 和，平均BUG收敛率。
积分扣减接口 积分查询接口 内部逻辑
日统计存储过程
2.2. 加权功能点计算
针对每个项目难易程度，需进行加权计算，应用难易一般分为数 据和事务处理的难易程度。
加权后的功能点数 ＝ 未调整的功能点数 × （0.65 + 0.01×TDI） TDI参考4附录
3. 考核延伸
质量保证人员测试质量考核：提交客户后BUG密度作为测试质量的 标准（CMM 3级标准：每功能点0.07个缺陷）
通用特性得分表
通用特性
描述
得分
1. 数据通信 多少个通信设施在应用或系统之间辅 3 助传输和交换信息。
2. 分布数据处 分布的数据和过程函数如何处理？ 3 理
3. 性能
用户要求相应时间或者吞吐量吗？ 3
4. 硬件负源自文库 应用运行在的硬件平台工作强度如 3 何？
5. 事务频度 事务执行的频率(天、周、月)如何？ 3
2. 功能点分析方法
本功能点分析方法参考 国际IFPUG方法，简化了部分步骤，可能存在 不足，需在具体执行过程中在补充。
2.1. 功能点分析
功能点由需求分析人员提供功能点列表，并由开发经理补充完 成，开发计划依据此制定
分析规则 ILF: Internal Logical File内部逻辑文件 EIF: External Interface File外部接口文件 EI: External Input外部输入 EO: External Output外部输出
0 毫无影响 1 偶然影响 2 偏下影响 3 一般影响 4 重大
影响 5 强烈影响
页面策划及制作人员质量考核：页面原型出的测试BUG密度，后期 测试出现的原型BUG密度
需求人员质量考核：测试中提出的功能建议性BUG数量 工作效率：统计功能点工作效率（人日/功能点），得到各层次人员 的工作效率，并可以作为工作效率参考依据。 工作量评估：根据统计的工作效率，作为工作量评估的依据。
4. 附录
1.2.3. BUG收敛率
BUG收敛率=（前一轮bug数量—本轮bug数量）/前一轮bug数量 测试人员区分是开发修改引起的bug，还是测试未测试出来的bug。 前一轮未测出的bug不在统计范围。 考核标准
BUG收敛率<=X%(需试运行阶段采集) X%～XX% 奖励月绩效0.05，项目奖金绩效0.1(需讨论) X%～XX% 合格（平均水平） X%～XX% 扣除月绩效0.05，项目奖金绩效0.1(需讨论) X%～XX% 扣除月绩效0.1，项目奖金绩效0.2 (需讨论)
1.3. 考核方式
1.3.1. 部门工作绩效考核
按照考核内容的项目绩效考核方法扣除相应绩效。
1.3.2. 项目绩效考核
项目结项时按照考核内容的项目绩效考核方法扣减相应比例
1.3.3. 年度考核
代码考核可以作为年度考核的依据。
每个开发人员在年度出现三次因代码质量问题（即三次因代码质量引 起扣除绩效）可以考虑降低人员的年底奖金，严重时解除合同。
3
12. 易操作性 启动、备份、恢复过程的效率和自动 3 化程度如何？
13. 跨平台性 应用被设计、开发和支持被安装在多 3 个组织的多个安装点（不同的安装点 的软硬件平台环境不同）吗？
14. 可扩展性 应用被设计、开发以适应变化吗？ 3
TDI 总计
42
每个通用特性默认为3，根据应用具体的情况进行相应调整：
1.2.2. 缺陷密度
缺陷密度=缺陷总数/功能点总数 缺陷总数，需剔除原型类BUG、建议性BUG。
功能点数为加权平均后的功能点数，计算规则详见后面2计算规 则说明 考核标准
缺陷密度量化标准 (需试运行阶段采集，CMM 3级标准：每功能 点5个)
X～XX个 奖励月绩效0.05，项目奖金绩效0.1(需讨论) X～XX个 合格（平均水平） X～XX个 扣除月绩效0.05，项目奖金绩效0.1(需讨论) X～XX个 扣除月绩效0.1，项目奖金绩效0.2 (需讨论)
数据分析在每轮测试完成和每项目封版结束及时给出，开发人员 3天内可以申述，针对有争议的地方进行讨论。
1.2.1. 提交测试被打回
提交测试因提交的版本有严重质量问题被打回，出现这种情况会 影响整体工作进度，并浪费开发和测试人员的时间。部署环境问题 导致问题不在此范围内。 考核标准
每次扣除月绩效0.1，项目奖金绩效0.1
添加购物车 提交订单 后台 查询订单 导出订单 开发经理 开发经理专注外部接口，内部逻辑，进行功能点补充。
商城功能点举例： 接口类
6. 在线数据输 在线数据输入率是多少？
3
入
7. 终端用户效 应用程序设计考虑到终端用户的效率 3
率
吗？
8. 在线更新 多少ILF被在线事务所更新？
3
9
处理复杂度 应用有很多的逻辑或者数据处理吗 3
10. 重用性
被开发的应用要满足一个或者多个应 3 用需要吗？
11. 易安装性 升级或者安装的难度如何？
代码质量考核办法
1. 开发人员代码考核办法
1.1. 目的
开发人员代码考核主要是针对在内部开发阶段代码质量进行考 核，目的是提升开发人员的质量意识，提高公司代码开发质量。
1.2. 考核内容
考核阶段主要是在公司内部的开发阶段（即在提交用户前），主 要考核的内容为：提交测试被打回、缺陷密度，BUG收敛率等方 面。在项目执行的每轮测试给出每个开发人员的缺陷密度、BUG收 敛率。在内部封版结束后质量保证部出每个开发人员BUG密度总 和，平均BUG收敛率。
积分扣减接口 积分查询接口 内部逻辑
日统计存储过程
2.2. 加权功能点计算
针对每个项目难易程度，需进行加权计算，应用难易一般分为数 据和事务处理的难易程度。
加权后的功能点数 ＝ 未调整的功能点数 × （0.65 + 0.01×TDI） TDI参考4附录
3. 考核延伸
质量保证人员测试质量考核：提交客户后BUG密度作为测试质量的 标准（CMM 3级标准：每功能点0.07个缺陷）
通用特性得分表
通用特性
描述
得分
1. 数据通信 多少个通信设施在应用或系统之间辅 3 助传输和交换信息。
2. 分布数据处 分布的数据和过程函数如何处理？ 3 理
3. 性能
用户要求相应时间或者吞吐量吗？ 3
4. 硬件负源自文库 应用运行在的硬件平台工作强度如 3 何？
5. 事务频度 事务执行的频率(天、周、月)如何？ 3
2. 功能点分析方法
本功能点分析方法参考 国际IFPUG方法，简化了部分步骤，可能存在 不足，需在具体执行过程中在补充。
2.1. 功能点分析
功能点由需求分析人员提供功能点列表，并由开发经理补充完 成，开发计划依据此制定
分析规则 ILF: Internal Logical File内部逻辑文件 EIF: External Interface File外部接口文件 EI: External Input外部输入 EO: External Output外部输出
0 毫无影响 1 偶然影响 2 偏下影响 3 一般影响 4 重大
影响 5 强烈影响
页面策划及制作人员质量考核：页面原型出的测试BUG密度，后期 测试出现的原型BUG密度
需求人员质量考核：测试中提出的功能建议性BUG数量 工作效率：统计功能点工作效率（人日/功能点），得到各层次人员 的工作效率，并可以作为工作效率参考依据。 工作量评估：根据统计的工作效率，作为工作量评估的依据。
4. 附录
1.2.3. BUG收敛率
BUG收敛率=（前一轮bug数量—本轮bug数量）/前一轮bug数量 测试人员区分是开发修改引起的bug，还是测试未测试出来的bug。 前一轮未测出的bug不在统计范围。 考核标准
BUG收敛率<=X%(需试运行阶段采集) X%～XX% 奖励月绩效0.05，项目奖金绩效0.1(需讨论) X%～XX% 合格（平均水平） X%～XX% 扣除月绩效0.05，项目奖金绩效0.1(需讨论) X%～XX% 扣除月绩效0.1，项目奖金绩效0.2 (需讨论)
1.3. 考核方式
1.3.1. 部门工作绩效考核
按照考核内容的项目绩效考核方法扣除相应绩效。
1.3.2. 项目绩效考核
项目结项时按照考核内容的项目绩效考核方法扣减相应比例
1.3.3. 年度考核
代码考核可以作为年度考核的依据。
每个开发人员在年度出现三次因代码质量问题（即三次因代码质量引 起扣除绩效）可以考虑降低人员的年底奖金，严重时解除合同。
3
12. 易操作性 启动、备份、恢复过程的效率和自动 3 化程度如何？
13. 跨平台性 应用被设计、开发和支持被安装在多 3 个组织的多个安装点（不同的安装点 的软硬件平台环境不同）吗？
14. 可扩展性 应用被设计、开发以适应变化吗？ 3
TDI 总计
42
每个通用特性默认为3，根据应用具体的情况进行相应调整：
1.2.2. 缺陷密度
缺陷密度=缺陷总数/功能点总数 缺陷总数，需剔除原型类BUG、建议性BUG。
功能点数为加权平均后的功能点数，计算规则详见后面2计算规 则说明 考核标准
缺陷密度量化标准 (需试运行阶段采集，CMM 3级标准：每功能 点5个)
X～XX个 奖励月绩效0.05，项目奖金绩效0.1(需讨论) X～XX个 合格（平均水平） X～XX个 扣除月绩效0.05，项目奖金绩效0.1(需讨论) X～XX个 扣除月绩效0.1，项目奖金绩效0.2 (需讨论)
数据分析在每轮测试完成和每项目封版结束及时给出，开发人员 3天内可以申述，针对有争议的地方进行讨论。
1.2.1. 提交测试被打回
提交测试因提交的版本有严重质量问题被打回，出现这种情况会 影响整体工作进度，并浪费开发和测试人员的时间。部署环境问题 导致问题不在此范围内。 考核标准
每次扣除月绩效0.1，项目奖金绩效0.1