下面是小编为大家整理的软件度量都该度个啥？,供大家参考。
软件度量都该度个啥？
摘要：
这年头 T IT 界流行 “ 用数据管理过程 ” 、 “ 用数字说话 ” ，软件度量成为热点话题! ! 一方面一堆专家在 “ 哗众取宠 ” ，而另外一方面企业在推行软件度量的实践中遇到了各式各样的问题，软件度量在软件企业中的实施效果不甚理想。一个软件企业应该从何做起度量工作呢? ? 希望本文能给大家带来有益的启发! !
形形式式的度量陷阱
N N 年前，老板对我们过程改进工作曾指示：能量化的工作尽量量化，不能量化的就不要勉强。当时觉得这个指示非常好，我也相信这个观点很多人都会认同。实际上应该是这样吗? ? 软件度量就必 须用数字来说明问题吗? ? 量化的结果一定比非量化的结果更准确客观吗? ?
没有一套好的度量工具，很难做好度量工作! ! 这是很多人的认识。而一些度量工具的生产厂商，更加是大力渲染，目的还不是为了更容易从软件企业的口袋里面掏钱呗! ! 要做好度量工作，真的需要一套强大的度量工具吗? ?
处于手工作坊的软件公司，难以进行软件度量，软件度量只能在有一定过程基础的公司进行。另外，对于小公司、小项目没有度量的必要，度量更适用于大公司、大项目。是这样吗? ? 难道小公司、不规范的公司、小项目就不能利用软件度量来改善生产力吗? ?
软件生产活 动是智力活动，要客观度量是很难的，要做好将会是很花成本的事情，而且开始阶段要忍受比较高的成本，软件度量所带来的效果，需要长时间才能体现。软件度
量难道就没有立竿见影的效果吗? ? 难道软件度量是大公司、有钱公司才能玩得起吗? ?
形形式式的度量陷阱，还远不止以上这些呢! !
什么是度量? ?
我一直想搞清楚度量的定义，在网上查了一大轮，只能找到一些让人看了还不如不看的 “ 学院派 ” 的定义。搞清楚什么是软件度量，非常重要，将会让我们少走弯路，直接发挥度量的价值。看看下面我对度量的定义：
测量就是这样一种活动: : 基于一定 的目的，采用一定的方法或标准，对目标事物进行观察，获得客观的评价结果，并根据评价结果采取适当的行动。
这个定义，反应了度量活动的四个要素：
1. 基于一定的目的。
2. 采用某种方法或标准。
3. 得到客观的评价结果。
4. 采取适当的行动。
让我们以测量水的温度为例来理解测量的定义。
如果有人给你一个度量任务，要求你度量水的温度，你会怎样做? ?
你会不会马上想到用温度计? ?
不好意思，如果是这样，你就落入了度量的其中一个陷阱了。你应该先问，为什么要度量水的温度? ? 不同的目的，做法 是不一样的。
如果度量的目的是为了判断煲水的时候水是不是开了。你还会用温度计吗? ? 当然你可以用能测量一百摄氏度的温度计来度量水的温度，但我们更多的会用肉眼观察水的形态，来判断是否水开了，如果想更简单一点的，买一个水开的时候会响的水壶或者是搞个饮水机就可以搞定了。
如果度量水的温度，目的是希望水温合适，好帮 B BB 洗澡呢? ? 有些妈妈会用温度计，有些妈妈会用自己的手直接去感觉水温，两种办法都可以。
一个测量水温的小问题很有学问。每个人发现，不同的目的，做法是不一样的。有些做法非常简单实用，不需要任何特殊工 具。用手感受温度或者用肉眼观察就可以了。相反，如果我们不知道目的，很可能会一刀杀鸡，甚至受伤。一不小心就可能直接用手感受到开水的温度。
另外我们也发现，度量的结果不一定都是数字来的，只要满足目的，越简单越好。水是否开的问题，我们只需要知道水是否开了就可以了，度量结果只有两个：是或者否，我们不需要知道这水是摄氏多少度。度量并不需要很精确，满足目的就好! !
度量的目的不是光为了得到一个结果，而是要根据度量的结果采取行动。如果妈妈发现水温不够，她会加入一些热水，如果觉得太热，就会加入冷水。这些行动的目的就是 为了让 B BB 有适合的水温洗澡。
首先应该度量的指标 —— 公司的效益指标
如果要做度量工作，最开始应该度量什么呢? ? 我建议应该首先度量公司的效益，度量效益的目的是对公司生产力状况有一个准确的认识，更准确地分析出问题所在，为决策提供更准确的依据。
那么公司的效益该如何度量呢? ?
公司有两大生产力指标，成本与收入。公司近一年的总体成本，包括人工、采购、水电费、房租费等全部费用加起来，财务肯定会有这样的一个数字。公司近一年所有人员的工作时间，所有人员包括开发、测试、行政、财务等，凡在公司的工作的所有人，这 些人上了多少天的班，一定也会知道，每个公司都有考勤请假的记录吗，就算没有也可以大概估算。这样我们可以得到公司全部人员一年的总体工作时间，单位是小时。这样我们有这样的一个指标：
成本指数
= 公司总费用/ / 总工作时间，单位：元/ / 小时
这个数字表明，在这个公司工作的每一位员工，每工作一个小时，其实是需要这样的一个成本的。没有算的公司尽快算算，你可能会发现，原来这个数字还相当大呢，远远超过这个人的时薪。
关于收入，我们有这样的一个指标：
收入指数
= 公司总收入/ / 总工作时间，单位 : 元/ / 小时
这个数字说明了在这个公司工作的每个员工，每工作一个小时，给公司带来了多少价值。
如果收入指数大于成本指数，说明公司是在赚钱的。公司的生产力就可以看这两个数字了，我们希望尽量降低成本指数，尽量提高收入指数，于是我们会得到下面这个指标：
效益指数 = 收入指数: : 成本指数
企业的最终目的是提高效率指数。成本高没关系，效率指数高就没问题。这些指标还可以进一步细化，比如: : 可以对成本进行分类，将成本分为人工成本和非人工成本。人工费可分为工程人员人工费和辅助人员人工费等。细分后可以找到
自己不合理的成本结构，并 做出相应的改进。比如细分收入，看看收入的构成，哪些部门和哪些人产生了收入，可以帮助企业增加收入。
公司的效益指标的度量是任何公司都可以做的，而且应该是第一时间就要做的度量，并且要持续地做的。公司所做的任何工作，市场活动、过程改进工作、度量工作等等，最终目的还是为了提高效益指数! !
每个软件公司都可以并且应该做好的度量 —— 缺陷度量
就算一个开发极不规范公司，我想总会对缺陷有一定的管理办法吧? ? 至少缺陷会被记录下来( ( 哪怕是各种方式) ) ，而不会只是口头说而毫无记录吧? ?
大多数软件公司都会有一套管理缺陷的 系统，我们应该如何把缺陷度量做得更好呢? ?
我们需要目标驱动地把度量工作做好，首先有两个最基本的要求：
1. 缺陷被准确地记录和跟踪。
2. 客观地依据缺陷状况对软件发布进行决策。
根据这两个要求，我们需要详细定义缺陷的属性，这些缺陷的属性就是我们要度量的内容。很多公司都会定义缺陷的描述、严重程度等属性，另外也会规定发布的时候，什么严重级别的缺陷不能超过多少个等要求。
以上两个目标只是缺陷度量的两个基本目标，如果更深入一点，我们希望能预防缺陷的再次发生，最简单有效的办法就是：直接让项目组成员 一起来分析缺陷的原因，让大家避免重犯。
如果想做更系统更深入的分析，就需要考虑在组织层面来做这个分析工作。这时有必要增加缺陷一个属性，叫做“ 缺陷来源 ” ，就是说产生这个缺陷的源头是在哪里，是需求没有分析到位，还是设计没有做好，还是编码出问题? ? 按“ 缺陷来源 ” 来分析公司不同类型的项目的缺陷情况，您就会发现公司的软件开发过程最有问题的是哪个过程? ? 哪些过程做得比较好? ? 这些分析结果会很好的指引过程改进的方向。
有很多地方可以发现缺陷。这是每个公司都应该做好的一种衡量，也是最有资格做好的。
成功的基础 —— 软 件规模度量
最近有这样的一个辩论，功能点 S VS 代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里不详细谈论这两种办法，这两种办法实施难度颇高，我们看看有什么更简单适用的办法。
我们为什么要进行软件规模度量呢? ? 目的无非是：
1. 作为报价或决策的依据。
2. 安排具体的项目进度。
3. 可以作为组织的生产力数据，用途很多，比如: : 项目之间的横向比较，供以后的项目 参考等。
如果是为了投标报价，建议用 i Delphi 法，功能点法、代码行法太慢了，不能适应商战社会，投标经常是没有这么多时间让你去折腾的。i Delphi 法的大致方法如下：
1. 找几名资深专家，一起对项目进行 WBS ，把项目的工作分解为十几条最多二三十条的工作项。
2. 所有专家都会估算每个工作项的工作量，并向其他专家解释其原因。
3. 第一次，专家估计的结果可能会大相径庭。每个专家听完别人的意见后，都会重新估价。
4. 按照上述办法，各专家反复估算几次，一般次数就是2 2- -4 4 次，各专家估计 的工作量会越来越趋近，这个时候取全部专家的平均值。
如果是为了目标 2 2 ，安排具体的项目进度，我建议用 “ 傻瓜估算法 ” ，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种 “ 罪状 ” ，但不好意思，用功能点法或者代码行法就很准吗? ? 我们亲爱的软件工程师们认可功能点法或者代码行法吗? ? 搞功能点法代码行法等这些 “ 虚 ” 办法，还不如老老实实地 WBS ，直接估算每个工作的工作量。
第一步: : 集合公司最有项目经验和 估算经验的工程师，制定出一个组织层面的估算表框架。
软件开发活动，可以分类以下几类：
直接生产软件的活动，如需求开发、设计、编码、测试和其他工程活动。
项目管理活动，如: : 撰写项目计划、跟踪计划、发布和评审等。
项目支持类活动，如：配置管理、A QA 检查等。
维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。
根据公司的实际情况，列出各种项目活动。可以根据不同的项目类别列出不同的活动，这些活动要尽可能细化。比如在考虑设计的时候，也要考虑设计审核的时间，在做规划的时候，要考虑 总体规划和分规划的编制。
把这些框架定好，并设计出估算表模板，供项目组使用。
根据我的经验，很多估算没有做好，往往是因为忘记或没有估算管理、支持和维护的活动。当一个公司的估算精英们聚集在一起的时候，大家要把公司估算中经常遇到的问题都列出来，这些问题都要在估算表模板中考虑进去，并且要写的足够清楚说明。当项目团队使用这些模板时，就相当于用估算精英们的脑袋来思考这个项目的估算。
第二步：项目组选用合适的估算表模板，进行由底而上的估算。
项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成 员一起在这个模板的基础上，继续细化，进行详细的 WBS ，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软F MSF 中的估算办法，这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责这个任务的人在做预估的时候，肯定要认真考虑这个任务的风险，需要做哪些具体的工作，这样在开始工作之前更容易发现更多潜 在的问题。相反，如果项目经理分配了时间，这个人可能不会考虑这个任务。
3. 完成这项任务的人会感到被重视和尊重。他会非常重视自己承诺的完成时间，努力按时完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动跟踪自己的工作。
第三步: : 不断改进模板，完善。
每个项目使用模板进行估算后，可以对模板提出改进建议，将这个项目的成功经验融入到模板中，让后面的项目受益。
“ 傻瓜估算法 ” 非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想 说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好? ? 当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。I CMMI 也没有规定非要用什么功能点法代码行法来度量软件规模。
软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用 “ 土方法 ” 也可以把工作量估好估准! !
如果要满足目标 3 3 ，即作为组织的生产力数据，应该如何度量呢? ?
满足目标 3 3 之前，我们应该保证我们能满足目标 1 1 和目标 标 2 2 ，如果目标 1 1 和 目标 2 2 都没满足的情况下，我们就去追求目标 3 3 ，是有点 “ 超前 ” ，这种 “ 超前 ” 对公司来说可能是“ 拔苗助长 ” 。当然我们希望有一种方法能同时满足这三个目标的，但到目前为止，我还没有见到过这样的成功案例。软件规模度量还是要一步一步来，不要一开始就期望吃成个“ 胖子 ” 了。
如果在 “ 傻瓜估算法 ” 的基础上...