软件度量集成化分析模型

软件度量是软件过程改进的一个重要方面,度量的目的是过程改进,但最终目的仍然是软件企业的成本收益上.如果最终的度量和改进没有体现到企业的赢利上,那就不能将度量和改进发挥了作用.

将度量用于绩效考核是不推荐的做法,但当度量不和绩效考核挂钩的时候更需要从人性化的角度去推动度量和改进.和绩效考核挂钩造成的后果就是为了指标而指标,为了度量而度量,具体指标和度量数据能够发挥哪些作用,如何指导改进和企业赢利并不会有太多人关心.软件工程和CMMI推荐了一套集成化的度量分析模型,我们讲给模型仍然不能充分体现客户驱动和价值驱动的概念.如果真正体现绩效,似乎从平衡计分卡角度来规划软件度量的指标更有实际的指导意义(待后续思考).

对于度量,首先要解决为什么需要度量的问题,做任何事情都是需求驱动的,没有源动力驱动做一件事情就体现不出价值.而驱动度量的源动力归根到底仍然是以最小的成本生产高质量的软件,为企业创造价值.这个驱动力是一个长期的驱动力而不时局限在现在,对于软件过程改进更是体现在对企业中期和长期价值的贡献.

不可否则人的经验或专家的判断比一些数据更有用.但这些经验必须要能够固化下来形成过程或方法论,才能形成企业的过程资产,长久的为企业服务.如何来证明某种方法或经验是否有效?我们可以设定指标,开始收集和分析数据,根据数据做出决策和判断.所以大家都清楚可以通过度量来知道某种方法是否有效,但如何保证你设置的度量指标本身,你收集的数据是否真正有效才是度量的关键问题.

要使度量真正有效必须要解决两方面的问题,一个是度量指标的设计是否合理?一个是如何保证你收集的数据是真实可靠?这两者缺一不可,如果这两点都做好了,你的度量过程就做好了.度量过程做好了才谈得上我们利用这些数据去做分析和决策,以持续改进工作软件开发过程.《实用软件度量》一书在如何进行有效度量中还谈到必须将度量过程做为软件工程的支持过程来实现，但对于其强调的信息驱动度量还不如讲为价值驱动度量。如果从单个项目管理角度来看则是为实现项目目标而度量。

1)功能规模表示项目预计提供的功能数量,通常有需求，变更需求和功能点决定。功能规模决定物理规模，或者说功能规模和物理规模间存在某种函数关系。

2)对于新技术的发现和创新可能回缩小产品的规模。新技术包括外购的软件，可重用的组件或架构。在新产品开发中其一是采用的技术架构对产品物理规模有影响，其二是业务规则本身的复杂性影响产品物理规模。由于采用的技术不确定，常导致产品的规模不确定。

3)产品规模的增长和不稳定性导致需要额外的人力资源。

4)过程性能或说软件开发过程成熟度会增加对人力资源和资金成本的需求并增加开发进度和产品质量。成本,进度和质量其本身就是项目的三重重要约束，成熟的过程也需要在三者之间达到一种平衡，最终体现到对软件企业长远期收益和价值的贡献。

5)如果在项目早期增加人员，并使人员得到良好的培训和交流，有可能提前项目进度。但对于进行中的项目，增加人员往往只能使进度更加落后。在熟练的人员进入一个新项目都存在对项目开发环境和过程的熟悉。

6)进度太紧张可能导致产品质量问题。包括产品缺陷，维护问题和性能问题。这通常发生在为了满足很紧的进度而减少测试工作的情况下。对评审和测试中发现的问题不予解决或解决不好同样会引发质量问题。

7)潜在的产品质量问题可能导致项目的返工，从而需要更多的人力资源和资金的投入。COPQ坏质量成本在软件开发项目中必须得到控制,因为任何返工往往会使需求,设计和开发等多个环节受到影响。

8)质量问题会导致产品稳定性下降并影响成本。管理人员可能会被迫修改或取消一些任务需求来满足成本和进度的约束。

9)对于软件项目而言，人员工作量包括返工是项目成本的关键因素。成本控制可以仅仅通过控制其它上游因素来确定。

10)资源和费用超支同产品质量问题一样都影响客户满意度。