(用例设计在软件开发项目绩效考核中的应用.docVIP

(用例设计在软件开发项目绩效考核中的应用.doc

  1. 1、本文档共5页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
(用例设计在软件开发项目绩效考核中的应用

用例设计在软件开发项目绩效考核中的应用 作者/转载者: 黄翼飞  发表时间:2006-3-22 14:17:20 用例设计在软件开发项目绩效考核中的应用 前言 没有比较就没有考核。绩效考核的根本目的就是通过考核等管理手段促进绩效的提高,要怎样才能知道绩效提高了呢?一定要有比较!因此,我们要使用一个指标体系来算出这个绩效的数据。本文介绍的绩效考核方法可以使: 1. 各个项目之间有着客观一致的绩效考核标准 2. 项目组内各成员的之间有着客观一致的绩效考核标准 3. 员工可以计算自己的绩效考核结果 实例 一般软件公司是这样进行绩效考核的: 1. 按项目开发的阶段划分项目,并制定相关的计划 2. 在月初,双方确认这个月要完成的计划内容 3. 在月末,对这些计划内容的完成情况进行评分 4. 依据评分的结果考虑是否加或扣当月工资 如: 被考核人:XXX  考核人:XXX   考核月份:2006-3  制表时间:2006-3-6 ------------------------------------------------------------------- 计划内容          权重  预计完成  实际完成  评估分数 ------------------------------------------------------------------- 完成A网站的需求、开发、测试 20   25     30     80 完成B应用系统的需求     30   15     20     80 完成C 应用系统的上线    50   20     10     100 ------------------------------------------------------------------- 合计            100               90 问题 我们看看上面这张考核表,不难发现: 1. 多个项目之间的评分标准不一致,不同项目的团队成员易产生对考核结果不满的情绪,有以下几个原因: a) 计划内容本身的界限是不清晰的 b) 不同项目的阶段所需求工作量不相同,或者很难找到它们之间的可计算 2. 单个项目中的各成员之间的评分标准不一致,团队成员易产生对考核结果不满的情绪 3. 评分没有客观依据,过于主观,不能令人信服 4. 员工在不能预见自己的绩效考核结果,找不到提高评分的办法 5. 看不到不同时间考核结果的差异,对员工的绩效提高没有实质性的帮助 实际过程 了解RUP(cess) 的朋友,知道软件开发过程并不是我们想象的如此简单。它告诉我们在同一个时间内所有的开发阶段是有可能共存的。也是说整个开发过程可以是多个迭代同时进行。 让我们回顾一下日常的开发过程: 1. 得知有一个项目需要开发。有可能是老板告诉你的,也可能是业务部门告诉你的,总之我们要为它而工作了,同时确信老板同意开始这个项目 2. 对这个项目涉及的人员及其需求进行调查。这里的需求包括了所有项目的需求,比如老板对这个项目的要求及期望,用户对这个项目的期望,开发人员对这个项目的期望。这时,我们很快会发现,调查所有人是不可能的,调查所有需求也是不可能的。因此, 1) 我们会先找几个关键人物,了解他们的期望,确定系统的边界(或叫轮廓,XP(Extreme Programming)中把它叫系统隐喻); 2) 再把系统划分为几个部分,确定先做哪个部分后做哪个部分; 3) 再一个一个部分对需求进行调查 当我们在调查的时候,常常会发现新的部分之间的关联,这使我们不得不对这两个部分的内容进行检查,加的加,改的改,删的删。 3. 基于调查的结果进行设计。这个时间,我们经过对这些需求的分析、归类,设计一个开发的模型以支持这些需求。设计时也免不了会发现需求不对的地方,对需求进行加的加,改的改,删的删。 4. 基于设计的结果进行编码、集成。也免不了会发现设计、需求不对的地方,对需求进行加的加,改的改,删的删。 5. 基于编码的结果进行测试,以验证软件是否达到了需求。我们常常发现这时的需求与设计之前的需求已有了很大的变化。 6. 发布(部署)产品,进行项目收尾。 如果某一时间,客户要知道项目进行到哪了,我们告诉他设计已完成,正进行编码工作。当有需求变更时,相关的需求、设计又要来过。客户能不怀疑我们的回答么? 做过软件开发的人就会知道,上面的过程描述中有很大的问题。我们的做过程并没有错,一个一个需求,一个一个功能的实现,有变更时就一个一个变更的实现,大家都这样做,也只有这样做。对于一个应用软件项目来讲,而不太可能真正的按软件书上写的过程一个一个过程的做下去,集中10天做完所有的需求,集中20天内做完所有设计。 做的过程没有错,把过程描述出来,为什么就错了?

文档评论(0)

1789811832 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档