软件度量的规则体系

来自：清华大学出版社《深度精耕——日本软件企业精义解读》 作者：唐德权 [2004/11/08]
索林根的软件度量指南：十大方针
软件度量专家索林根(Van Solingen)在《聚焦产品的软件过程改善》(Product Focused Software Process Improvement)中详细阐述了软件度量项目工程(Measurement program engineering)，提出软件度量的十大方针，如下所示。
1. 准备让软件开发者参与软件度量项目；
2. 开始软件度量工程前了解软件产品的质量目标、过程模型和学习目的；
3. 软件度量项目工程为目标导向，确保具备有限但相关的度量设定；
4. 指定期望值(假设)；
5. 由具有实际度量经验的人员按照规则对度量数据作出分析和解释；
6．将度量数据的分析和解释聚焦于：详细而精确的过程行为、全局过程、或者产品质量目标，但是决非聚焦于个人绩效；
7. 执行专门资源(人员)来支持度量项目工程的开发团队；
8. 评价实际产品质量和目标产品质量的差距；
9. 评价过程行为的影响(产品质量方面)；
10. 将特定情景中过程行为的知识存储到经验数据库中。
高尔发的关键成功因素：九大要素
品质与生产力管理集团(Q/P Management Group)总裁斯科特·高尔发(Scott Goldfarb)在《建立有效的度量体系》(Establishing a Measurement Program)中认为，建立并实施有效软件度量体系的关键成功因素包括如下：
1. 确定度量目标和计划；
2. 获得高层管理者的支持；
3. 拥有专属资源；
4. 面向员工的培训、教育和营销推广；
5. 日常工作中的度量一体化；
6. 聚焦于项目团队的结果；
7. 度量不要针对个人；
8. 有效定义数据以及实情报告制度；
9. 推动度量自动化。
软件工程研究所的软件度量规则：二十八条规则
美国卡内基·梅隆大学软件工程研究所在《软件度量指南》中列出了如下软件度量的规则：
1. 理解软件度量方法只是达到目的的手段，而其本身并不是目的；
2. 以应用度量结果而不是收集数据为中心；
3. 理解度量的目标；
4. 理解如何应用度量方法；
5. 设定期望值；
6. 制定计划以实现早期成功；
7. 以局部为重点；
8. 从小处着手；
9. 将开发人员与分析人员分开；
10. 确信度量方法适合要实现的目标；
11. 将度量次数保持在最低水平；
12. 避免浮夸度量数据；
13. 编制度量工作成本；
14. 制定计划使数据收集速度至少是数据分析和应用的3倍；
15. 至少每月收集一次关于工作投入水平的数据；
16. 明晰关于工作投入水平数据收集的范围；
17. 仅收集受控软件的错误数据；
18. 不要指望准确地度量纠错工作；
19. 不要指望找到界定完善的放之四海而皆准的过程度量方法；
20. 不要指望找到过程度量的数据库；
21. 理解高级过程的特征；
22. 应用关于生命周期阶段的简单定义；
23. 用代码行表示规模；
24. 明确将哪些软件纳入度量范围；
25. 不要指望使数据收集工作自动化；
26. 使提供数据的工作更容易；
27. 使用商业上可用的工具；
28. 认为度量数据存在瑕疵、不精确也不稳定。
帕克的目标驱动软件度量原则：四大原则体系
帕克(Robert E. Park)、哥特(Wolfhart B. Goethert)和弗罗哈克(William A. Florac)在1996年的《目标驱动软件度量指导手册》(Goal-Driven Software Measurement—— A Guidebook)中提出软件度量的原则如表5-10所示：
表5-10 帕克的目标驱动软件度量原则
1. 部门管理者的度量原则

—— 设立清晰的目标；
—— 让员工协助定义度量手段；
—— 提供积极的管理监督：寻求和使用数据；
—— 理解员工报告的数据；
—— 不要使用度量数据来奖赏或者惩罚实施度量的员工，并确信他们知道你和其他任何人都遵守这一规则；
—— 建立保护匿名的惯例，对匿名提供保护将建立起信任并培育起可靠数据的收集机制；
—— 如果员工的报告基于对组织有用的数据，支持他们；
—— 不要强调那些排斥其他度量方式的某种度量方式或者指标。

2. 项目管理者的度量原则

—— 知晓组织的战略性焦点并强调支持该战略的度量手段；
—— 在追踪的度量手段上与项目组获得一致，并在项目计划中定义这些度量手段；
—— 向项目组提供规则有序的关于其所收集数据的反馈；
—— 不要私人单独地进行度量。
3. 项目组的度量原则

—— 尽最大努力报告准确而及时的数据；
—— 协助在管理中将项目数据聚焦于改善软件过程；
—— 不要使用软件度量夸耀自身的优秀，否则这将鼓励其他人使用其他数据展示其反面。

4. 通用原则

—— 软件度量本身不要成为一个战略；
—— 在软件过程改善的全局战略中整合软件度量，为此应该拥有或者开发一种这样的战略来联合软件度量计划；
—— 带着共同目标与课题从点滴做起；
—— 设计一种持续的软件度量过程，以使其：
? 与组织目标与宗旨相联系
? 包括严格的定义
? 持续实施；
—— 在广泛实施所设计的度量手段和过程之前进行测试；
—— 对软件度量手段和度量活动的效果进行度量和监控。
弗罗哈克的实用软件度量原则：十大原则
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的过程度量原则如下。
1. 过程度量受商业目标驱动；
2. 过程度量手段源自软件过程；
3. 有效度量需要明确阐述的可操作性的定义；
4. 不同的人拥有不同的度量观点和需求；
5. 度量结果必须在产生结果的过程和环境中检验；
6. 过程度量应当跨越整个生命周期；
7. 保持的数据应当提供分析未来的实际基线；
8. 度量是进行客观沟通交流的基础；
9. 在项目内部和项目之间对数据进行总计和比较需要细心和规划；
10. 结构性的度量过程将强化数据的可靠性。

软件度量的要点：来自实战的教训
软件度量这一作业本身比较难以在实际的软件开发中顺利操作，也难以在软件开发改善中产生立竿见影的效果，甚至会让人觉得这是枯燥无味的无用功。这往往会形成妨碍实施软件度量的阻力，挫伤软件度量人员的积极性和热情。那么，如何有效地推动软件度量，就成为软件度量作业的重点课题。下面是软件度量作业的要点，可以作为推动软件度量作业的参考。
1. 从点滴开始。与其采用声势浩大的软件度量运动，还不如从点滴开始：让员工逐渐进入度量状态，避免因为大规模运动带来的不适和阻力。从点滴开始，从小规模的简单的度量项目开始，从能够吸引员工并能让其接纳的度量项目开始，保证软件度量能在避免受挫的情况下得以逐渐推进，同时尽可能提高软件度量的自动化程度。
2. 解释为什么。这是消除抵制情绪和消解阻力的重要环节，因为人们不会切实地践行那些他们没有真正理解和接纳的理念和措施。需让员工明白，使用度量将比没有任何度量要好；度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善；软件度量仅仅针对软件产品、项目和过程，而不针对个人；等等。
3. 根据项目实情加以具体实施。不同的项目拥有不同的产品、流程、环境、目标和顾客，顾客、软件开发人员、项目组甚至经营者对项目的需求也不同，必须聚焦于解决该项目在产品、流程等方面的问题，而不是直接套用以前曾经实施或者已经模式化的度量标准。
4. 共享数据。度量数据的共享这一行为本身具有四大好处：一则可以让员工感受到度量的切实性，即行动正在按照计划进展；二则可以为员工提供度量的反馈信息，以改进现状；三则可以通过比较，寻找最佳实践，实施标杆学习；四则可以通过数据共享增进信任，消除软件度量可能带来的误解。
5. 保持简单易懂。简单易懂这一点对于降低度量过程中的理解成本、沟通成本和实施成本都不可或缺。因为软件开发人员没有必要成为软件度量理论、统计方法以及度量技术的专家，他们仅仅需要知道软件度量与解决问题之间的关系，知道如何简单高效地实施度量。
6. 塑造度量文化。在软件开发中有意识地塑造一种重视记录、亲近数据、偏好图表、基于度量进行作业的习惯或者说文化，将判断、分析和决策立基于可预测性、可控制性、可改善性之上。
软件度量的陷阱：直面铜板的反面
就像铜板的正反两面，软件度量也具有正反两个方面的影响：正面效用在于通过度量获得定量化的可控过程，负面影响在于其过度滥用带来的危害，比如：
1. 软件开发的量化指标替代了开发目标。软件开发管理中定量化极为重要，这当然是指有目的的、毫无浪费的、明确的定量化。如果视软件度量为目的，那么软件度量就会陷入可悲的误区：纯粹的量化指标替代了目标，数据淹没了宗旨，任务迷糊了方向，软件度量成为软件开发过程的目标而不是手段，成为应付考核和评价的功利性工具。指标仅仅是个反光镜，而不是行进的指向标。如果不能理解软件度量在商务上的目标，那么就会出现这样的情况：收集了错误的数据，以及数据没有被正确使用。要想接近目标，双眼必须注视前方。
2. 软件开发的度量方法取代了度量理念。软件度量不仅仅包含着丰富多样的度量方法，更包含着博大精深的度量理念；不仅仅需要理解软件度量的方式方法，更要践行软件度量的理念。如果仅仅拘泥于软件度量的方式方法而忽略更为本质、更为精髓、更为深刻的理念，那么软件度量对于软件开发的意义就不再重要，因为这种情况下的软件度量虽然获得了看似完美的躯壳，却丢失了灵魂。
3. 软件开发的度量结果成为奖惩的根本依据。软件度量的结果如果成为考核和奖惩的根本依据，那么就偏离了软件度量的用途：软件度量只针对项目、产品和过程，用于对软件项目、产品和过程进行理解、分析、预测、评估和改善；软件度量从不针对个人，既不用于评估个人的能力，也不用于评估个人的绩效，更不用于作为个人奖惩的根据，这样才能保持数据的可靠性、客观性和准确性。如果软件度量针对个人，这将从根本上影响个人的态度和行为，并危害团队的绩效。永远不要让软件度量成为软件开发人员心理上的负担。
过程影响公司的首席咨询顾问卡尔·威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：
1. 缺乏管理承诺；
2. 度量得太多太早；
3. 度量得太少太晚；
4. 度量了错误的事项；
5. 度量定义不严密；
6. 度量用于评估个人；
7. 度量用于激励而非理解；
8. 仅仅收集但不使用数据；
9. 缺乏沟通和培训；
10. 曲解度量数据。
软件度量并非神话，从其诞生之日起就没有预言过任何神话。软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发的所谓“银弹”，就需要重温那句富有讽刺意味的名言：谎言有三种，即谎言、该死的谎言、统计数据。