软件是一种固化的思维→不可直接估算，只能间接估算→间接估算可以分为两个层次：一是估算固化前的思维表现形式；二是考虑团队情况估算固化后的思维表现形式→间接估算使多维视角成为可能，很多时候需要从不同视角，兼顾两个层次进行估算，并用不同视角下的结果彼此验证。
间接估算是指无法估算思维本身，而只能估算思维的表现形式。这点还是有些抽象，我们来补充一点说明。
假设一个人种了10亩地玉米，他想估计产量，因此假设每亩产1000斤，可以得到估算的结果为10000斤。一旦秋收后，就可以实际称量一下产量，看是不是10000斤。
在这里，他估的是产量，得到的也是产量，而产量对应于确定量的玉米实物，两者是同一个东西，看得见摸得着，因此可以讲是直接估算。
接下来轮到思维了。
我们碰到的第一个问题就是，思维在哪里呢？每个人身边多彩的生活足以佐证思维的存在，但思维本身确实看不见摸不着。因此对思维的估算就只能估算思维的表现形式，如书籍的页数等，但书籍并不是思维本身，而只是思维的载体，这就是间接估算。
间接估算自身又包含了两个层次：一是对需求的估算。如果使用功能点这类单位对需求进行度量和估算，那么得到的是需求的规模，这时候并不会考虑人员等因素的影响；二是基于需求的规模，估计实现等最终需要耗费的人月。
在采用Story等作为单位时，上述两个层次往往会被合并在一起。而合并在一起则不利于考查软件开发自身的投入产出，这时即使是想做比较粗略的投入产出统计也几乎没有可能。
与此同时，间接估算拉开了估算和软件的距离，这就导致站在不同位置上，最终看到的东西不同。但又由于不管怎么看，都是软件的一体多面，所以不同估算方法所得结果应该大致相同。
比如说，可以根据外在的输入、输出，估算最终软件的功能点（未调整功能点），并折算成代码行，再通过公式就可以计算出最终所需的人月。这是一个视角。
下面是一个折算成代码行后，再用COCOMOII进行计算的实例：
对于一般项目：A为2.94，E将设为1.15，所有的工作量乘数（EM）都被设为1，这样对于估计为100KSLOC的项目，其需要的人月数为
PM=2.94（100）1.15=586.61MM。
（上面这个例子取自《软件成本估算：COCOMOII模型方法》一书，这个值对国内很多做项目的人可能很难接受）
而通过制作比较详细的WBS（Work Breakdown Structure），考虑规格说明的创建时间、评审时间，设计文档的创建时间、评审时间，各个需求场景的实现时间等，也可以得到一个项目所需的人月。这是第二个视角。(www.xing528.com)
图5-2所示是一个WBS的例子，取自PMBOK。
图5-2 WBS的简单实例
先估算规模，再利用公式进行计算与使用WBS这两类视角差异较大，但其结果却不应该出现太大的偏差，因此说用两类或更多几乎完全不相关的视角彼此验证，通常可以使估算的结果更为精准。
关于COCOMOII
COCOMO的目标是帮助软件开发者预先对成本和进度进行估算，进而进行决策。这个模型最早发布于1981年，而后在2000年左右升级到COCOMOII。模型的主要开发人是Barry W.Boem。对COCOMOII最权威的介绍就是这位老人家写的《软件成本估算：COCOMOII模型方法》。老实讲这书看着比较晦涩，但还是值得一读。
这个模型的根本目的是用来帮助估算，但我个人的经验是模型本身有点水土不服，很难用起来。估算的成本值过于偏高，也许是因为模型本身参照的项目规模，复杂度等都比较大的缘故。
即使如此，还是推荐了解这个模型的原因在于：通过这个模型可以理解到软件开发的全貌，分解出来的14个调整因子非常经典，彼此正交。用这14个因子来分析项目，即使只是定性的，也帮助不小。
COCOMOII的调整因子列表（COCOMOII认为下面所有这些因子都将影响项目的人月）见表5-2。
表5-2 COCOMOII的因子
其中，有一点需要做点额外的说明。
在这一模型中涉及人员的因子有：需求分析师的能力、程序员的能力（总体）、人员持续性、应用（业务领域）经验、使用编程语言和开发工具的经验、对平台的经验和团队凝聚力。所有这些加起来可以让项目的估算结果出现22倍的变化。
这一方面提醒我们人在软件开发中的重要影响，另一方面也提醒我们在精细粒度上软件估算一定是不准的。
程序员或者需求分析师不太可能是“标准件”，甚至同一个人在时间轴的不同点上也是不同的。而在估算人月的时候一定需要对人员的状况做出假设，而这一假设和现实的吻合程度大多时候不可能是100%，这种偏差的影响都会在估算结果和现实的差距上体现出来。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
