公司名字测试打分 wyxiang自己用

公司名字测试打分 wyxiang自己用 公司名字测试打分,wyxiang自己用 您现在的位置:希赛首页软件工程质量保证正文 软件开发度量及考核方法 作者:论坛精华来源:发表评论进入社区 0引言 本人觉得如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是大多数没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。以下文档是本人根据以前经验和相关的资料所编写的度量方法和考核方法，希望能对公司改善考核制度有用。由于时间有限，有不足之处，请各位仁兄多提意见，谢谢～ 1目的 对软件开发的过程所产生的软件项的质量和过程进行定量的，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2软件项包括 1)技术文档:参照公司"软件工程产品集"，所确定的配置项;主要包括:可行性报告、需求、软件功能规格说明、开发、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等; 2)计算机程序。 3度量数据的来源 1)项目计划; 2)评审报告; 3)测试报告; 问题报告; 4) 5)软件维护记录; 4质量度量 4.1度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表(见附录1)，有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 4.2质量等级 1)软件项的质量等级的确定根据度量综合指标进行。 2)度量综合指标计算公式为:Total=?QiMi。 3)其中i=1,2,.n代表指标数量; 4)Q代表度量的指标; 5)M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表: 序号指标权重 1指标1权数1 2指标2权数2 3指标3权数3 4指标4权数4 5指标5权数5 加权平均分1.0 6)质量评价:一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 9.0~10.0优质 2 8.0~8.9良好 3 6.0~7.9合格 4低于6.0劣质 4.3度量指标计算方法 1)度量指标评分标准:根据软件项的各检查指标的缺陷率来确定，既为每项度量指标制定计分标准，缺陷率越高得分越低。 度量指标计分标准表 序号得分缺陷率范围 1 9~10范围1 37~8范围3 45~6范围4 5低于5范围5 2)缺陷率来源:主要是各软件项检查、评审、测试的过程所产生的缺陷跟踪表(见附录2)，缺陷跟踪表中的缺陷类别对应检查表中的检查指标。 3)缺陷率单位 1结构化方法 需求文档:以功能点或文档页数为单位(缺陷数/功能点、缺陷数/页)。 设计文档:以模块或文档页数为单位(缺陷数/模块、缺陷数/页)。 软件代码:以模块或代码行数为单位(缺陷数/模块、缺陷数/LOC)。 2面向对象方法 需求文档:以业务用例或文档页数为单位(缺陷数/BUC、缺陷数/页)。 设计文档:以用例或文档页数为单位(缺陷数/UC、缺陷数/页)。 缺陷数/UC、缺陷数/LOC)。 软件代码:以用例或代码行数为单位( 4)缺陷率计算方法: 1首先根据缺陷跟踪表中的缺陷类别分别统计各类别的缺陷率，然后依据度量指标计分标准表来给每个度量指标打分。 2缺陷率计算公式为:Total=?(Bi/U)Mi。 3其中i=1,2,.n代表缺陷级别，缺陷级别可分为:致命、严重、一般、轻微; 4 B代表每种缺陷级别的缺陷数; 5 U代表缺陷率单位数; 6 M代表每种缺陷级别的权重系数，通常权重系数以"一般"缺陷级别作为基数(权数设为1)，"轻微"缺陷级别可不用计算缺陷率(权数设为0)。 缺陷级别权重系数表: 序号级别权数 1致命3 2严重2 3一般1 4轻微0 5过程度量 5.1及时度 1)以软件项目计划规定的的完成时间为基准，通过比较实际完成时间和计划完成时间的时间差，与软件项完成周期的比率来评价各软件项的及时度。 2)时间差率=(实际完成时间-计划完成时间)/(计划开始时间-计划完成时间) 3)评分标准如下:时间差率范围可根据具体项目而定。 及时度评分标准表 序号得分时间差率范围 以内) 1 9~10范围1(15% 3 7~8范围3(15%~35%) 4低于7范围4(35%以上) 5.2成熟度 以软件项检查、评审、测试的结果为评价基准，评分标准如下: 1 9~10分:一次检查、评审、测试通过，无须调整; 2 7~8分:一次检查、评审、测试通过，略有调整，或第二次检查、评审、测试通过无须调整; 3 6分以下:二次以上检查、评审、测试未通过。 5.3改善效率 在检查、评审、测试的结果的基础上改善软件项结果，以改善的时间是否影响后续阶段的完成和计划的总体完成时间为评分依据，评分标准如下: 1 9~10分:改善效率良好，软件项的修改无须增加工作量，不影响阶段的继续进行和项目计划的总体完成，或无须修改; 2 7~8分:改善效率一般，软件项的修改或完善影响阶段的继续进行，增加工作量在原计划的20%(此阀值可根据具体项目而定)以内; 3 6分以下:改善效率较差，软件项的修改或完善过程使项目延期，或增加的工作量超过20%(此阀值可根据具体项目而定)。 5.4综合评价 1)过程度量的综合评分方法是:S=P*A1+M*A2+E*A3。 2)S代表综合评分; 3)P代表及时度; 4)M代表成熟度; 5)E代表改善效率; 6)A代表过程指标(P、M、E)在整个指标体系中所占的权重系数(可根据具 体项目而定)。 过程指标权重系数表: 序号指标权重 1及时度权数1(0.3) 2成熟度权数2(0.3) 3改善效率权数3(0.4) 加权平均分1.0 7)过程评价:一般地，根据过程综合评分，有以下评分标 准。 过程评价计分标准表: 序号得分过程评价 1 9.0~10.0优质 2 8.0~8.9良好 3 6.0~7.9合格 4低于6.0劣质 6软件项综合评价 1)软件项综合评分=质量评分*质量权数+过程评分*过程权数。 综合指标权重系数表: 序号指标权重 1质量权数1(0.5) 2过程权数2(0.5) 加权平均分1.0 2)软件项综合评价:一般地，根据软件项综合评分，有以下评分标准。 软件项综合评价计分标准表: 序号得分过程评价 1 9.0~10.0优质 2 8.0~8.9良好 3 6.0~7.9合格 4低于6.0劣质 7度量记录 项目经理或开发经理在软件项提交检查、评审、测试通过后，需要填写软件项度量表(见附录3)，并提交给SQA部审核和软件事业部经理批准。如果一个软件项由多人完成，需要将软件项按(功能、模块)拆分，分别记录 各人的度量，SQA部在审计软件项时，根据软件项度量表填写软件项综合评价表(见附录4)。 8绩效考核 8.1开发人员考核 1)软件项的平均得分值计算方法是:AV=(?COi)/i*10。 2)AV代表软件项的平均得分值; 3)CO代表软件项综合得分; 4)i=1,2,.n代表软件项数量。 5)绩效考核标准:一般地，根据软件项的平均得分值，有以下评分标准。 绩效考核计分标准表 序号得分考核评价 1 90~100优秀 2 80~89良好 3 60~79及格 4低于60很差 6)软件部门根据软件项综合评价表每个月或季度统计各开发人员所负责的软件项的平均得分值，比较开发人员软件项的平均得分值与绩效考核标准范围，确定开发人员绩效考核评价。绩效考核为"良好"以上人员奖励相应金额，绩效考核为"很差"人员处罚相应金额。对于很差的开发人员需要通报批评，并要求在项目经理、开发经理帮助下写个人软件开发过程改进书。如果是连续三个月都是很差，则可能降级、降工资、甚至解雇;对于优秀的开发 人员通报表扬，并组织经验交流会介绍其优秀的软件开发过程控制方法，如果是连续三个月都是优秀，则可能升级、升工资。 8.2项目经理、开发经理考核 1)项目组的平均得分值计算方法是:AV=(?COi)/i*10。 2)AV代表项目组的平均得分值; 3)CO代表项目组成员绩效考核得分; 4)i=1,2,.n代表项目组成员数量。 5)绩效考核标准:一般地，根据项目组的平均得分值，有以下评分标准。 绩效考核计分标准表 序号得分考核评价 1 90~100优秀 2 80~89良好 3 60~79及格 4低于60很差 6)软件部门每个月或季度确定了项目组成员绩效考核评价后，计算项目组的平均得分值，比较项目组的平均得分值与绩效考核标准范围，确定项目经理、开发经理绩效考核评价。绩效考核为"良好"以上项目经理、开发经理奖励相应金额，绩效考核为"很差"项目经理、开发经理处罚相应金额。对于很差的项目经理、开发经理需要通报批评，并要求在部门经理帮助下作项目组软件开发过程改进书，如果是连续三个月都是很差，则可能降级、降工 资、甚至解雇;对于优秀的项目经理、开发经理通报表扬，并组织经验交流会介绍其优秀的项目组开发过程管理方法，如果是连续三个月都是优秀，则可能升级、升工资。 8.3检查、测试人员考核 1)在软件项检查、评审、测试过程中，项目经理或开发经理需要填写检查、测试人员的缺陷查找质量度量表(见附录5)作为月度考核或季度考核依据。 2)缺陷查找率计算方法 1缺陷查找率计算公式为:Total=?(Bi/U)Mi。 2其中i=1,2,.n代表缺陷级别，缺陷级别可分为:致命、严重、一般、轻 微; 3 B代表每种缺陷级别的缺陷数; 4 U代表缺陷率单位数; 5 M代表每种缺陷级别的权重系数，通常权重系数以"一般"缺陷级别作为权数设为1)，"轻微"缺陷级别可不用计算缺陷查找率(权数设为0)。 基数( 缺陷级别权重系数表: 序号级别权数 1致命3 2严重2 3一般1 4轻微0 3)缺陷查找质量评价:为每个软件项 制定相应的缺陷查找质量计分标准。 缺陷查找质量计分标准表: 序号得分缺陷查找率范围 1 9~10范围1 37~8范围3 45~6范围4 5低于5范围5 4)缺陷查找的平均 得分值计算方法是:AV=(?COi)/i*10。 1 AV代表缺陷查找的平均得分值; 2 CO代表缺陷查找质量得分; 3 i=1,2,.n代表软件项数量。 5)绩效考核标准 绩效考核计分标准表: 序号得分考核评价 1 90~100优秀 2 76~89良好 3 60~75及格 4低于60很差 6)软件部门根据软件项综合评价表每个月或季度统计各检查人员或测试人员缺陷查找的平均得分值，比较检查人员或测试人员缺陷查找的平均得分值与 良好绩效考核标准范围，确定检查人员或测试人员绩效考核评价，绩效考核为""以上人员奖励相应金额。对于优秀的人员通报表扬，并组织经验交流会介绍其优秀的检视和测试方法。 8.4缺陷考核 1)某阶段的软件项检查、评审、测试通过后，如果在后面阶段工作中发现此软件项的缺陷时，需定位缺陷级别，定位是"重大"以上级别缺陷时，每个缺陷罚款×元，作为项目组活动经费。 2)在软件项检查、评审、测试过程前，需要制定软件项的最低缺陷查找率，通过缺陷查找质量度量表(见附录5)，比较检查或测试人员的缺陷查找率少于最低缺陷查找率时，当软件项在以后阶段发现缺陷而被罚款时，款项由软件项负责人和检查、测试人2比1分摊。 9附录 附录1:软件项检查表;(略) 附录2:缺陷跟踪表;(略) 附录3:软件项度量表;(略) 附录4:软件项综合评价表;(略) 附录5:缺陷查找质量度量表。(略) 也谈软件测试缺陷跟踪管理 发布时间:作者:未知来源:51Testing软件测试网整理编辑 上一篇下一篇|打印|我要投稿|每周一问，答贴有奖 字体:小中大| 缺陷跟踪管理是软件测试工作的一个重要部分，软件测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。 1、缺陷跟踪管理的目标 软件缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标: 确保每个被发现的缺陷都能够被解决;这里解决的意思不一定是被修正，也可能是其他处理方式(例如，在下一个版本中修正或是不修正)，总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致; 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定软件测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。 2、缺陷的描述 对缺陷的描述应该包含以下的内容:可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷缺陷基本信息缺陷状态缺陷的状态，分为"待分配"、"待修正"、"待验证"、"待评审"、"关闭"缺陷标题描述缺陷的标题缺陷的严重程度描述缺陷的严重程度，一般分为"致命"、"严重"、"一般"、"建议"四种缺陷的紧急程度描述缺陷的紧急程度，从1-4，1是优先级最高的等级，4是优先级最低的等级缺陷提交人缺陷提交人的名字(邮件地址)缺陷提交时间缺陷提交的时间缺陷所属项目/模块缺陷所属的项目和模块，最好能较精确的定位至模块缺陷指定解决人缺陷指定的解决人，在缺陷"提交"状态为空，在缺陷"分发"状态下由项目经理指定相关开发人员修改缺陷指定解决时间项目经理指定的开发人员修改此缺陷的deadline缺陷处理人最终处理缺陷的处理人缺陷处理结果描述对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改缺陷处理时间缺陷处理的时间缺陷验证人对被处理缺陷验证的验证人缺陷验证结果描述对验证结果的描述(通过、不通过)缺陷验证时间对缺陷验证的时间缺陷的详细描述对缺陷的详细描述;之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细测试环境说明对测试环境的描述必要的附件对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的TAG:缺陷管理:32版权声明:原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。软件人员管理，一向被认为是一件难题。尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。 在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。项目主管把任务进行分解，和每个软件开发人员对各自所需完成的工作内容、期限和考核标准达成一致，特别是各个模块之间的接口，并形成一份完整的"任务说明书"。在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。 开发人员应具有较强的事业心、责任感和较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品和新技术提供条件。通常研发一个软件项目所需的时间较长，我认为按项目的里程碑或项目来安排对软件人员的考核， 若项目周期超长也可在年中和年末进行考核，以目标管理(Management By Objectives，简称为MBO)为原则设定KPI(Key Performance Index)，考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。 根据客户关注点确定考核指标，同时将客户的满意度与做为考核的衡量标准，一个项目完成后，公司不要把该项目的奖金一下子全发给软件人员，可以留下30%~40%待一年后发放，给客户一年的时间发现问题，软件公司可根据问题的大小从余下奖金中相应扣除。 用下面的七项指标对开发人员进行绩效考核评定: 1.工作态度 2.软件质量(bug的等级和个数，回归次数，重要模块系数) 3.工作难易度(功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度) 4.工作效率/能力(完成百分比，工作经验) 5.主动性 6.沟通能力 7.程序程度 1)非常及时，随时都可以查阅任意相关文档; 2)非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内; 3)较规范，较及时，一般可以查阅近期文档，文档编写滞后3~6天; 4)较规范，但不及时，常常难以查阅，文档编写滞后6天以上; 5)不规范，不及时，常常难以查阅，甚至没有编写相关文档。 代码应该有统一的代码库管理，而不是只保存在程序员个人手里;Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。 微软公司对软件人员的绩效考核每半年进行一次，先由员工自己为这半年来的业绩做一个评估，打一个分数，然后放到网上，等待部门经理签字、打分。没有经过部门经理打分、签字的信息呈红色;经理打完分后，如果员工认为经理的评价比较符合事实，再进行最后的确认，确认后信息变为绿色，业绩考核的过程就完了。此外，部门经理打分的同时还要为每位员工制定下个半年的目标。如果员工对经理的评价存有异议，便可以拒绝确认，更高层经理及人力资源部的人员看到后，会与员工沟通，直至查到员工拒签的原因。 也有些知名的IT公司已将软件开发人员的绩效评估建立形成了一个体系，每年有年度的绩效考核，开发部门有开发成本考核。从每年12月开始到第二年1月份的两个月期间，公司上上下下都认真地做绩效考核，因为晋升调薪需要这个依据。考核完后，经理要跟员工面谈，将考核结果告诉他。考核的关键是评估后的沟通，这比评估更重要。让员工知道他的不足在哪里，优势在哪里，员工自己要提出想法。考核后排在后5%的员工要内部下岗，实际上是降工资， 博客，请务必保留此出处 留岗观察。本文出自"Michael:变革管理应对挑战" 文章转自:阅读本文的人还阅读 名字测试打分起名测名打分 定时关机命令软件取消自动关机的命令定 萨摩犬多少钱萨摩犬图片萨摩犬视频萨 北海市,北海市环北文化产业开发有限公司合 爱在日月潭结局大连日月潭大酒店爱在日 荣威350汽车报价荣威350汽车之家 特别声明: 1:资料来源于互联网，版权归属原作者 2 :资料内容属于网络意见，与本账号立场无关 3:如有侵权，请告知，立即删除。