完美软件开发：方法与逻辑-定性分析及工作估算

先回到我们一直在用的公式。

假设一个人的工程素养为E，一个人的工作意愿为W，组织所能提供的力量为O，内耗系数为M，那么对于一个拥有n个人的团队，其在单位时间内最终可能贡献值可以表示为：

[（E₁×W₁+O）+（E₂×W₂+O）+…+（E_nW_n+O）]×M

对设计和编码进行定性分析，所需要考察的维度和估算非常相似，都是内耗系数M和工作意愿W。

一是代码自身的结构越差，写同样代码行所需考虑的事情也就越多，这事实上会增加内耗系数。最终导致的结果是从用户的角度来看，软件没有什么改观，但从开发的角度看，无数的人月却已经花进去了。简单来讲就是有投入没有产出，内耗极大。根据5.1.2中的介绍，在COCOMOII中认为这种内耗可以使效能降低一半。

二是糟糕的代码为无所作为提供了冠冕堂皇的接口，团队的最终状态大多时候会变成和代码所处的状态一样。僵化、逻辑混乱的代码基本上会对应到僵化、迟缓、毫无斗志的团队。

我们前文曾经做过这样的假设：(www.xing528.com)

如果我们认为积极向上的团队工作意愿为1，能对工作基本负责的团队工作意愿为0.5，负不起责任的团队工作意愿为0.5以下，极值为0。那么糟糕的代码很可能使工作效能降低一半。

所以说从长期来看，设计和编码的好坏至少可以导致4倍左右的效能差异。

这里需要特别提到的是对现有软件产品的选用，尤其是平台的选用。当我们选择Windows或Linux，选择Java或.NET，选择SQL或NoSQL等时，事实上也就选择了其背后所隐含的力量，这种力量最终将作用于组织力量O，决定基线的高度。假使说A技术代表的基线高度为20，B技术代表的基线高度为40，那么选择A的人或公司天生就处于劣势。

本书并不以评价平台优劣为目标，因此并不会在各种现有技术的优劣上展开笔墨，但从架构设计的角度看，这些因素是不能忽略的。

COTS是什么

在谈估算或开发模型类的书中，经常会提到COTS这个缩写。COTS是Commercial off-the-shelf。中文大多时候会被翻译成“商用现成产品”。按理说，软件开发的历史已经超过30年，商用现成产品应该很多，软件开发似乎应该沦为一种组装工作。但事实却远非如此，除了一些基础库外，在应用领域中大家还是在各干各的。这有法律、机制上的原因（使用非开源的产品，一旦出现问题可能完全解决不了），但更主要的原因则可能是需求变化太快，使更多的软件不像是螺丝，而像是其他领域中完整的方案。