软件度量是软件 过程改进的一个重要方面,度量的目的是过程改进,但最终目的仍然是软件企业的成本收益上.如果最终的度量和改进没有体现到企业的赢利上,那就不能将度量和改进发挥了作用.
将度量用于绩效考核是不推荐的做法,但当度量不和绩效考核挂钩的时候更需要从人性化的角度去推动度量和改进.和绩效考核挂钩造成的后果就是为了指标而指标,为了度量而度量,具体指标和度量数据能够发挥哪些作用,如何指导改进和企业赢利并不会有太多人关心. 软件工程和 CMMI推荐了一套集成化的度量分析模型,我们讲给模型仍然不能充分体现客户驱动和价值驱动的概念.如果真正体现绩效,似乎从平衡计分卡角度来规划软件度量的指标更有实际的指导意义(待后续思考).
对于度量,首先要解决为什么需要度量的问题,做任何事情都是需求驱动的,没有源动力驱动做一件事情就体现不出价值.而驱动度量的源动力归根到底仍然是以最小的成本生产高质量的软件,为企业创造价值.这个驱动力是一个长期的驱动力而不时局限在现在,对于软件过程改进更是体现在对企业中期和长期价值的贡献.
不可否则人的经验或专家的判断比一些数据更有用.但这些经验必须要能够固化下来形成过程或方法论,才能形成企业的过程资产,长久的为企业服务.如何来证明某种方法或经验是否有效?我们可以设定指标,开始收集和分析数据,根据数据做出决策和判断.所以大家都清楚可以通过度量来知道某种方法是否有效,但如何保证你设置的度量指标本身,你收集的数据是否真正有效才是度量的关键问题.
要使度量真正有效必须要解决两方面的问题,一个是度量指标的设计是否合理?一个是如何保证你收集的数据是真实可靠?这两者缺一不可,如果这两点都做好了,你的度量过程就做好了.度量过程做好了才谈得上我们利用这些数据去做分析和决策,以持续改进工作软件开发过程.《实用软件度量》一书在如何进行有效度量中还谈到必须将度量过程做为软件工程的支持过程来实现，但对于其强调的信息驱动度量还不如讲为价值驱动度量。如果从单个项目管理角度来看则是为实现项目目标而度量。
1)功能规模表示项目预计提供的功能数量,通常有需求，变更需求和功能点决定。功能规模决定物理规模，或者说功能规模和物理规模间存在某种函数关系。
2)对于 新技术的发现和创新可能回缩小产品的规模。新技术包括外购的软件，可重用的组件或架构。在新产品开发中其一是采用的技术架构对产品物理规模有影响，其二是业务规则本身的复杂性影响产品物理规模。由于采用的技术不确定，常导致产品的规模不确定。
文章来源于领测软件测试网 https://www.ltesting.net/
