在GJB5000/CMMI系统中有一个过程域/实践域称为原因分析(CAR)，即分析选定结果的原因，找出结果的根本原因，采取有效措施避免坏结果或促进好结果的产生。

为什么软件开发过程需要实施原因分析？因为很多事情没有表面上看起来那么简单，找不到根本原因，可能只会头痛，不能解决根本问题。

医学上有一个术语叫做涉及性疼痛。它意味着疼痛不是表现在人们一眼就能看到的病源，而是表现在身体的其他部位。

比如有的患者感觉腿痛，但实际问题不是腿部病变，而是椎间盘脱垂压迫脊柱神经。对于这样的患者，如果找不到真正的原因，再怎么治疗也没用——因为原因不再在那里。同样，心脏病患者通常会感到左臂疼痛，但治疗左臂对他没有帮助。

作者的一个朋友经常感到腰痛，服用许多治疗腰痛的药物都没有效果。后来，当他病情严重时，他发现自己得了肺癌，癌细胞已经转移了很久。……

很多软件Bug并不像表面上看起来那么简单。表面上看起来某个功能有故障，但实际上可能是软件架构有问题。

如果原因分析不好，找不到Bug根本原因只会给软件表现出故障的功能补丁，这样即使软件暂时可以运行，很快也会在这里或者其他地方再次出现问题。

如果总是一个个打补丁，就像在伤口上贴创可贴一样。虽然看起来比手术便宜，性价比高，但是留下了很大的隐患。一旦这个隐患爆发，那个成本可能是无法承受的。

因此，原因分析对软件开发非常重要。如果这个实践领域能够很好地实施，软件开发将少走弯路。

这大概也是GJB5000B原因分析GJB5000A五级过程域降低到三级实践域的原因！

这正是：

治疗指标不治本，病因无法分析清楚

软件开发也是如此。找出原因并采取行动。

参考书目:项目百态:深入了解软件项目行为模式，作者:(美)TomDeMarco等等，译者:金明，出版社:人民邮电出版社

作者简介:王小双，长期从事GJB5000推广、实施、评价、改进工作，创建软件工程之思微信公众号，共享软件工程之思GJB5000、CMMI软件工程的知识与感悟。现在致力于GJB5000咨询和软件流程改进和软件工程能力提高的研究工作。