软件是一种固化的思维→无法形成真正的、统一的软件度量单位→在精度上，估算可以保留一定的模糊，结果通常需要体现为一定的范围→但估算结果本身要可以验证。
前文一再提到软件的估算精度有限，这事实上要求软件估算的结果需要体现为一个范围值，而非一个单值。但即使承认了软件估算的模糊性，也使用了范围值，也不意味着软件估算自身不需要同实际值进行比较。
有些偏差可能是由于单位导致的，有些偏差可能是由于需求自身的不确定性所导致的，但确实也有一些偏差是因为方法错误或失误所导致的。这就要求估算的结果要能够同实际结果进行比对。有些估算方法会对这种比对造成障碍，应该尽量避免。比如说，基于Story对工作量进行估算。这类方法也许可以校验每个Story的期间和工作量，但关键是一旦对估算值和实际值间的偏差进行分析，所得到一切经验只是对某几个人能力有所帮助，而很难累积历史数据。
COCOMOII使用的估算方式比较值得参照，这里再来看一下这种方法。COCOMOII使用的基本方法是：先估算规模，再考虑人员组织等影响因素来计算工作量和工期。
规模可以是代码行或未调整的功能点。而影响因素如下。
●应用（业务）经验。
●数据库规模。
●是否用于重用。
●要求提供文档的程度。
●使用编程语言和开发工具的经验。
●是否多场所开发。
●人员稳定性。
●相关平台的经验。
●平台自身的稳定程度。(www.xing528.com)
●有先例可循的程度。
●开发过程成熟度。
●产品复杂度。
●程序员能力。
这样一旦出现偏差，我们就可以找出是哪个维度上出了问题，而且有利于之后的改进。
这类反省工作大多时候会面临某些挑战。一种典型挑战是小需求数目的极度膨胀。
随着需求的持续变化和深入，需求碎片的量会非常的大（不用太多，需求变更的条目超过500就很麻烦）。这导致很难区分估算和实际值的偏差是因为估的不准还是因为需求变更扩散了需求的边界。
好比说，我估计自己的1亩地可以产多少玉米，最终也是同自己的1亩地的产量进行比较，那这个比较是有意义的。而估的是自己的，最终却同隔壁王二家的产量进行比较，那就不是很有意义了。
上面这个问题，在其他行业中也许很好解决，但在软件行业中却是很困难的一个问题。软件行业中的问题更类似于：我原本想种一亩地玉米，估的也是玉米的产量，但中间商量来商量去，却种成了一半玉米，一半高粱。解决这类问题的关键点是为需求确立基线，预先设计数据采集方法，并集成进项目管理工具，标识清楚变更点。
CMMI中对Baseline的定义是：A set of specifications or work products that has been formally reviewed and agreed on，which thereafter serves as the basis for further development，and which can be changed only through change control procedures.
（基线是一系列已经被正式评审并且同意的规格说明书或工作产品，是进一步开发的基础并仅能通过变更控制流程进行改变）
事实上，这个定义可以简化一点：基线即是基准，在软件开发中是达成某种条件后的一系列资料。比如说，如果某份需求文档在所有利害相关人间达成了一致，那么这份文档就可以成为基线的一部分。而基线这个概念之所以有用，是因为没有它既无法区分什么是变更，也无法判断估算是准还是不准。
需求变更天然就会不停向纵深发展。比如说，当开发一个Bug管理系统时，添加一个字段，数据需要导成Excel，需要和外部XX系统进行连接，这样的需求会不断发生。如果没办法给它一个边界，那么就哪里都不是变更，估算也就无所谓准或不准。而需求变更本身是连续的，你没办法从需求自身来定义这种边界。当我们说这是一个手机的时候，手机的外形尺寸就是手机的边界，可需求的边界却只能从时间点上来约定，尽管这一时间点前后的发生的需求本质上并无差别。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
