《用例设计在软件开发项目绩效考核中的应用.doc》由会员分享，可在线阅读，更多相关《用例设计在软件开发项目绩效考核中的应用.doc（5页珍藏版）》请在三一文库上搜索。
1、用例设计在软件开发项目绩效考核中的应用作者/转载者: 黄翼飞 发表时间:2006-3-22 14:17:20 用例设计在软件开发项目绩效考核中的应用前言没有比较就没有考核。绩效考核的根本目的就是通过考核等管理手段促进绩效的提高，要怎样才能知道绩效提高了呢？一定要有比较！因此，我们要使用一个指标体系来算出这个绩效的数据。本文介绍的绩效考核方法可以使：1.各个项目之间有着客观一致的绩效考核标准2.项目组内各成员的之间有着客观一致的绩效考核标准3.员工可以计算自己的绩效考核结果实例一般软件公司是这样进行绩效考核的：1.按项目开发的阶段划分项目，并制定相关的计划2.在月初，双方确认这个月要完成的计划内
2、容3.在月末，对这些计划内容的完成情况进行评分4.依据评分的结果考虑是否加或扣当月工资如：被考核人：XXX考核人：XXX考核月份：2006-3制表时间：2006-3-6-计划内容权重预计完成实际完成评估分数-完成A网站的需求、开发、测试 20253080完成B应用系统的需求 30152080完成C应用系统的上线 502010100-合计100 90问题我们看看上面这张考核表，不难发现：1.多个项目之间的评分标准不一致，不同项目的团队成员易产生对考核结果不满的情绪，有以下几个原因：a)计划内容本身的界限是不清晰的b)不同项目的阶段所需求工作量不相同，或者很难找到它们之间的可计算2.单个项目中的各
3、成员之间的评分标准不一致，团队成员易产生对考核结果不满的情绪3.评分没有客观依据，过于主观，不能令人信服4.员工在不能预见自己的绩效考核结果，找不到提高评分的办法5.看不到不同时间考核结果的差异，对员工的绩效提高没有实质性的帮助实际过程了解RUP(rationalunifiedprocess)的朋友，知道软件开发过程并不是我们想象的如此简单。它告诉我们在同一个时间内所有的开发阶段是有可能共存的。也是说整个开发过程可以是多个迭代同时进行。让我们回顾一下日常的开发过程：1.得知有一个项目需要开发。有可能是老板告诉你的，也可能是业务部门告诉你的，总之我们要为它而工作了，同时确信老板同意开始这个项目2
4、.对这个项目涉及的人员及其需求进行调查。这里的需求包括了所有项目的需求，比如老板对这个项目的要求及期望，用户对这个项目的期望，开发人员对这个项目的期望。这时，我们很快会发现，调查所有人是不可能的，调查所有需求也是不可能的。因此，1)我们会先找几个关键人物，了解他们的期望，确定系统的边界（或叫轮廓，XP(ExtremeProgramming)中把它叫系统隐喻）；2)再把系统划分为几个部分，确定先做哪个部分后做哪个部分；3)再一个一个部分对需求进行调查当我们在调查的时候，常常会发现新的部分之间的关联，这使我们不得不对这两个部分的内容进行检查，加的加，改的改，删的删。3.基于调查的结果进行设计。这个
5、时间，我们经过对这些需求的分析、归类，设计一个开发的模型以支持这些需求。设计时也免不了会发现需求不对的地方，对需求进行加的加，改的改，删的删。4.基于设计的结果进行编码、集成。也免不了会发现设计、需求不对的地方，对需求进行加的加，改的改，删的删。5.基于编码的结果进行测试，以验证软件是否达到了需求。我们常常发现这时的需求与设计之前的需求已有了很大的变化。6.发布（部署）产品，进行项目收尾。如果某一时间，客户要知道项目进行到哪了，我们告诉他设计已完成，正进行编码工作。当有需求变更时，相关的需求、设计又要来过。客户能不怀疑我们的回答么？做过软件开发的人就会知道，上面的过程描述中有很大的问题。我们的
6、做过程并没有错，一个一个需求，一个一个功能的实现，有变更时就一个一个变更的实现，大家都这样做，也只有这样做。对于一个应用软件项目来讲，而不太可能真正的按软件书上写的过程一个一个过程的做下去，集中10天做完所有的需求，集中20天内做完所有设计。做的过程没有错，把过程描述出来，为什么就错了？原因很简单：我们在描述时，总喜欢套用一些模式，一些书写的方法，而不是按实际的过程描述。如果我们不套用任何模式，将会如何呢？我们再来描述一遍上面的过程：1.了解软件项目的故事（story）。开始一个软件应用项目，了解关键人物都有哪些？他们要求是一个什么样的系统？把这些要求描述成一个一个的故事，如果稍稍规范一点。就
7、会象这样：1)这个系统的目标是为了谁解决什么问题2)第一步做什么，系统反馈什么3)第二步做什么，系统反馈什么4)5)问题解决了，结束本故事我们会仔细的看这些故事，发现有些地方看不懂，于是我们就去问清楚，有些事情是那个描述故事的A也不清楚的，但A告诉我们B会懂，于是我就问B；有些事情A也不知道有谁会知道，我们就把它放在一边，等知道的时候再问，继续看其他的故事。2.了解系统隐喻，构造软件框架。永远也问不清楚所有的事情，所以当我们知道整个系统的是为了解决什么问题，将用什么办法来解决它（暂时叫做系统隐喻），关键人物也认可时，我们就不再问下去了。我们依据这个系统隐喻去构造一个最上面的故事。然后，只关心与
8、这个故事有关的故事。同时构造一个程序框架以支持项目的开发3.实现故事。在软件框架上，实现一个故事，再实现一个故事，4.实现变更。有时发现事情并没有想象的简单，于是就变更它，这就要求我们实现这些次变更。它象实现故事一样：实现一次变更，再实现一次变更，5.部署软件。感觉软件已达到了可被接受的预想或合适的要求了，就发布这个软件。上面所说的故事就是我们常说的用例（usecase）。我们可以使用用例的形式来描述整个系统的计划内容，并计算它的工作量，为工作之间、项目之间的绩效提供一个统一的衡量标准。这时，我们发现：1.由故事（有些项目可以用故事所包含的步骤）的数量可计算出开发的工作量2.我们实际开发工作过
9、程的时间、成本、进度是可以被不了解项目实现技术的人所感知的如果我们仔细查看项目的所有工作，会发现有些工作不是基于某个用例的，也与某些用例没有直接关系，如何拿用例来计算它的工作量呢？在项目的开发中确定存在这些工作，如项目开始时的了解软件项目的故事。但通过分析知道，在一个软件项目中顶层用例的数量是不难预测的，也是说在这个时期要向关键人了解的用例数是可以预测的。我们不难发现，要了解的用例数越多，需求了解的工作量就越大。在相同类型的应用软件开发中，需求了解的工作量与用例数量的比例是基本一致的。同理，了解系统隐喻，构造软件框架、部署软件的工作量与用例的量也是成比例的。在没有不熟习技术的前提下，根据本人的经验，同类软件项目的工期与底层用例数（更多信息请参考http:/ 301010100完成B应用系统的用户模块 202020100完成C应用系统的转帐模块 503025200-合计100 150由于这种方法使用了与具体项目的特性、过程无关的评分标准，所以可以保证本绩效考核方法可以达到以下几个目标：1.使各个项目之间有着客观一致的绩效考核标准2.使项目组内各成员的之间有着客观一致的绩效考核标准3.使员工可以计算自己的绩效考核结果