软件部绩效考核规范Word文档下载推荐.docx

软件部绩效考核规范Word文档下载推荐.docx

《软件部绩效考核规范Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《软件部绩效考核规范Word文档下载推荐.docx（15页珍藏版）》请在冰豆网上搜索。

1

90～100

优

0%--5%

2

70～80

良

5%--10%

3

50～60

合格

10%--15%

4

低于50

不合格

15%--100%

（2）缺陷率来源

主要是软件经过测试组测试后，所产生的测试报告；

◆软件交付使用后一年内产生的软件维护记录表;

◆开发人员的缺陷率考核，主要依据测试报告和软件维护记录；

◆测试人员的缺陷率考核，依据软件维护记录。

（3）缺陷率单位

以程序单元为单位，相比较而得出缺陷率的值（原理：

缺陷数/单元总数）。

这里所指的程序单元，是WBS分解后的内容。

（4）开发人员缺陷率计算方法

●根据测试报告和软件维护记录中的缺陷类别，分别统计各类别的缺陷率，然后依据度量指标的计分标准表来打分。

●缺陷数计算公式为：

Total=∑（Ci*Fi*Ki）；

●缺陷率计算公式为：

V=Total/U；

其中

i=1,2,...n代表每个缺陷；

U代表开发人员负责的、已完成且已被测试的程序单元总数；

C代表缺陷所对应的缺陷级别的权重系数；

通常权重系数以"

一般"

缺陷级别作为基数（权数设为1），"

轻微"

缺陷级别可不用计算缺陷率（权数设为0）。

缺陷级别

权数

致命

死机，数据丢失，主要功能组完全丧失，系统悬挂

严重

主要功能丧失，导致严重的问题

一般

次要功能丧失，不太严重，如提示信息不太准确

轻微

微小的问题，对功能几乎没有影响，产品及属性仍可使用.如有错别字

K代表缺陷所在单元对应的权重系数，开发难度增加时程序单元相应递减为0.75,0.5…（也可用分数表示更直观），具体根据具体开发项目难易程度制定。

一般开发难度的单元，确定为：

1。

模块

模块1

R1

模块2

R2

N

模块n

Rn

F代表缺陷所对应的测试难易的权重系数，这里是指开发人员出现bug后，判定其发现的难易程度。

根据缺陷的发现难易度，将起划分为三个级别,具体可根据开发项目难易程度另行制定。

级别

难

0.5

容易

1.5

（5）测试人员缺陷率计算方法

●首先根据软件维护记录表中的缺陷统计的缺陷率，然后依据度量指标计分标准表来打分。

Total=∑（Ci*Fi）;

V=Total/U;

●所有参数含义参见开发人员缺陷率计算方法。

二、进程考核

对软件开发的进展情况进行度量，主要考察时间进度。

1.考核指标

●Budget

按照对于每个单元工作量评估的结果，规定完成的时间。

●PTC报告

通过比较实际完成时间和计划完成时间的时间差，与任务完成周期的比率来评价各任务的及时度。

以下为PTC报告：

姓名：

XXX月份：

组别：

开始时间：

版本记录：

（VX.x；

X.x）

任务

描述

第1周

…

第5周

TOT

PTC

ACT

Percent

Budget

REM

T1

T2

5

Tn

合计

平均：

TOT:

已经花费的总天数；

PTC:

除了本月花费的天数，还要多少天可以完成；

ACT:

本月实际需要的天数；

Budget:

最初预计的本月需要花费的天数；

REM:

整个任务完成的期限；

Percent:

本月完成的百分比。

●对于每周工作过程中，所花费的天数，通过书写的“工作日志”，可以进一步核实。

工作日志每天要书写，精确到小时，每周向直接上级汇报，并存档。

便于抽查、核对。

●对开发人员、测试人员的过程考核数据是：

项目所负责的程序单元的计划完成时间和实际需要时间。

●对技术执行总监的过程考核数据是：

整个项目的计划完成时间和实际完成时间。

●时间差率=（本月实际需要时间-本月预计完成时间）/本月预计完成时间；

即：

Percent。

（以天为单位）；

最终的结果为N个任务的平均值。

2.评分标准

时间差率范围可根据具体项目而定。

时间差率范围

90-100

15％以下

70-80

15％-35％

低于70

35％以上

三、综合考核

根据综合因素考核表对相应人员的考核。

详见附录一程序员、中级程序员、高级程序员、系统分析员综合因素考核表，附录2技术执行总监综合因素考核表

第四部分、绩效考核

一、开发人员（程序员、高级程序考核）考核

1.质量考核

在软件测试过程中和软件后期维护发现的缺陷，需定位缺陷级别,计算缺陷率，以此对开发人员以后的工作岗位、薪水等，进行调整。

每个季度上报公司一次，作为下一步调薪的依据。

技术部门每个月由技术执行总监统计，并存档。

每个月所有人员的统计情况，上报部门。

2.当月绩效考核

考评分=进程评分*进程权数+综合因素评分*综合因素权数。

综合指标权重系数表：

指标

进程考评

0.6

综合因素

0.4

二、项目经理考核

1.考核得分计算方法是：

AV=（（∑Pi）/i）*0.5+M*0.3+C*0.2；

2.Pi代表项目组成员的过程考核得分；

3.M代表技术执行总监的过程考核得分；

4.代表技术执行总监的综合因素得分；

5.i=1,2,...n代表项目组成员数量。

6.绩效考核标准：

一般地，根据项目组的平均得分值，有以下评分标准：

考核评价

80～89

60～79

低于60

差

7.技术部每个月确定了项目组成员绩效考核评价后，计算项目组的平均得分值，比较项目组的平均得分值与绩效考核标准范围，确定技术执行总监的绩效考核评价。

三、测试人员考核

1.在软件检查、评审、测试通过后，对软件维护记录中的缺陷，需定位缺陷级别,计算缺陷率，以此对测试人员考核；

缺陷率越高其评价分就越低。

2.测试组根据任务综合评价表每个月统计各测试人员所负责的任务的综合评价结果，比较测试人员任务的得分值与绩效考核标准范围，确定测试人员绩效考核评价。

四、美工人员考核

1.根据当月完成工作量，以通过评审的原图及牵引图数量为衡量标准，数量越多，评价分越高。

2.对客户评价及满意度进行调查，并作为硬性标准。

第五部分、其他说明

1.开发的前期，指定每个模块的难易程度。

2.bug发现的难易程度，在提交测试报告，并评审后决定。

3.需要相关部门需提供软件维护记录表（缺陷数量、程度）。

附录1：

程序员、中级程序员、高级程序员

综合因素考核表

岗位名称：

总得分:

项目及考核内容

配分

自评

上级审核

编码的水平（15%）

A、编码非常简洁、规范，注解完整、清楚，容易被人理解；

15

B、编码非常简洁、规范，注解较完整、易懂，较容易被人理解；

13

C、编码较简洁、规范，注解较完整、易懂，基本能被人理解；

10

D、编码较简洁、规范，有个别注解，勉强能被人理解；

8

E、编码不简洁、规范，没有注解或仅有个别注解，无法被人理解。

相关技术文档的编写水平（15%）

A、编写非常规范，非常及时，随时都可以查阅正在开发任务的设计文档、已完成任务的说明文档；

B、编写非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内；

C、编写较规范，较及时，一般可以查阅近期文档；

文档编写滞后3至6天；

D、编写较规范，但不及时，常常难以查阅，文档编写滞后6天以上；

E、编写不规范，不及时，常常难以查阅，甚至没有编写相关文档。

合理化建议（10%）

A、常常有很好的建议，并很大的提高了工作效率，而且能认真听取和执行经理的建议；

B、有时有好的建议，对工作效率有些提高，并且能认真听取和执行经理的建议；

C、有时提一些建议，但没什么效果，往往能听取和执行经理的建议；

6

D、很少提建议，能听取经理的建议，但很少能执行，有时有些固执己见；

E、喜欢固执己见，不太能听取经理的建议，经常固执己见。

工作总结、计划（10%）

A、每次都能按时提交总结和计划，并且内容完整、详实、清楚，使人能清楚地把握当前工作动态；

B、每次都能按时提交总结和计划，内容较完整、详实，使人能了解当前工作动态；

C、基本能按时提交总结和计划，内容较完整、详实，使人能了解当前工作动态；

D、基本能按时提交总结和计划，内容不太完整，使人能基本了解当前工作动态；

E、很少能按时提交总结和计划，内容不太完整，使人能基本了解当前工作动态。

备份源程序（10%）

A、每天工作结束时，都能及时备份源程序，每次抽查都能通过；

所有版本的源程序（以及开发环境）均能及时备份；

B、基本每天都能备份源程序，抽查偶尔没有通过；

C、往往2至3天备份一次源程序，抽查一般没有通过；

D、往往一星期备份一次源程序，抽查一般没有通过；

有最终版本的源程序（以及开发环境）的备份；

E、不备份源程序，抽查从来没有通过。

对外技术保密（源程序、技术文档、核心技术等）（10%）

A、从不向无关人员透露技术秘密，从不携带技术秘密（非工作需要，下同）离开公司。

对技术保密问题提出了自己的建议，并被采纳，并经常提醒他人注意技术保密；

B、从不向无关人员透露技术秘密，从不携带技术秘密离开公司。

经常提醒