软件质量的数学化——度量

马克思说过：一种科学，只有成功地运用数学时，才算达到真正完善的地步。

今天写这篇文章时，脑子里陆续跳出几个概念，数字、量化、定量、数学......又联想找到马克思这句话，讲得很精彩，也很令人兴奋，讲得没有任何问题。

但同时也迸发出很多疑问，从实际工作体验来看，数学在有些领域有些时候不可或缺，也很精准，而另一些领域另一些时候却又显得流于形式，脱离实际。那么，这是数学的问题，还是领域的问题，抑或是发展阶段的问题，定量与定性相比注定更优更接近真相吗......

当年做产品开发时，一位老领导常说，Speak with Data，就是谈论问题时要带着数据才更有价值；找工作写简历时，老鸟也总会在简历里用数字表现业绩，避免所谓的泛泛而谈；产品设计中，尺寸、公差、参数、指标无不是通过数字来定义、控制及落地成功的......不一而足。

但同时也会看到数字失去其准确性的时候，比如在公司里，员工需要登记工时，领导需要查看各类报表，项目开发需要做各种成本评估......做过的人常常会觉得这些数字、百分比、曲线都太脱离实际了，很多时候和做算术题无异。然而，即使是大咖公司的精英领导依然在不遗余力地推行它，并且用其做决策，结果当然不会是尽如人意的，那么问题出在了哪里？

以我粗浅的理解，答案是聊胜于无，对于以上提到的问题，即使数字不够准确，但依然比定性描述好得多，很多时候定性与拍脑袋几乎无异，问题其实就在于难以拿到准确的数字。实际上，相信管理层非常清楚数据不准确的问题，但依然可以通过这些不准确的数据去管理和逐层推进优化（这个有意思的话题，有机会再来分享下）。

不过，我也认同量化的意义其实并没有看上去那么大，特别是涉及到社科领域。

现在回到主题，软件度量也并不能绝对保证信息准确和高质量软件，但这是一个当前最优的管理手段或方法。

从另一个角度看，软件质量度量的根本目的就是为了管理的需要，为了提供管理所必需的可见度。

写到这里，也解决了我的另一个疑惑，我以前就职的一家头部公司为什么没有那么多的软件度量工作，数字化做得也一般，归根结底是它有极端完善的组织流程，主动管理的必要性相对弱一点，一套流程被某个事件Trigger之后，流程像一台在轨列车一样会运行起来，这种形势下的管理多在于保持在轨和衔接站点的交接，而不那么需要根据度量结果进行非标化的调整，不需要换，更不需要建轨道。

度量是客观对象到数字对象的同态映射，软件品质量与软件度量成直接对应关系。软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。

没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。

度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量等等。

度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。

当然，正是因为量化的难度高和价值有限，也会有观点认为软件不可度量，但主流观点还是认可度量的意义。

卡内基梅隆大学软件工程研究所认为通过软件度量能实现三个作用：1. 增加理解；2. 管理软件项目，主要是计划和估算、跟踪和确认；3. 指导软件过程改善，主要是理解、评估和包装。

模型是一种认知工具，软件质量模型也是软件质量评价的基础，软件质量模型代表了人们对软件质量特性的认识程度和理解程度，常见的模型有McCall模型、Boehm模型、FURPS模型和ISO9126。

那么，落地一点看，软件度量如何具体进行？

首先，凡事都要先定目标，有目标，才有方向，企业终极目标是商业目标，所以商业目标会作为度量目标的第一输入。此外，由于过程改善是一个闭环，已经识别出的过程改进建议也同样可以作为输入。

但是，目标并不具备操作性，落地要细化，要有据可依，所以还需要依据度量目标，设计Indicator、所用公式、收集方法、存储方法、分析方法等，形成一套度量标准。

项目管理里有个裁剪概念，就是说不同一切照搬书本，要因地制宜，要因时制宜，要根据项目情况定义项目度量计划。接下来就是具体的按计划执行了，QA开始收集并分析度量数据，识别出异常后，并按照一定的流程推动解决。

在阶段性度量过程结束后，还需要落实成报告向管理层汇报，以便管理层及时获得软件质量状态，相应地做出决策。此外，度量数据还要存在组织资产库，以用于后续分析及改进。

文章暂时整理到这里。

最后再分享一点小感触，基础理论学科重要性自不必说，但它与实际应用的鸿沟也是显而易见的，我们多数人不做科学研究。那么，如何将理论、科学、数学的营养不着痕迹地引入日常工作里，不落入纸上谈兵的境地，非常难得，但同样也非常。

深入浅出可绝非易事。