分类： 架构设计与优化
2014-11-16 22:56:03
拿我刚开发完成的一个项目（以下简称为A项目）为例，原设计团队估计的LOC（Line of Code）是31k，实际开发NBNC行（Non-Blank Non-Comment 非空非注释行、物理代码行）12k，有效代码行VLOC 5.5K（不含头文件）。可见，实际代码量与估计代码量差别相当大，准确估计有多难。
按照专业（理论）的估计方法，应该是找几个专家分别估计，然后大家一起讨论修正，最后计算综合估计值。但实际上这很难操作，一是找不到所需要的专家；二是即使有这样的专家，对所估计对象可能又不熟悉；三是可能缺乏专业的操作方法；四是没有那个时间来搞；......总之，拍脑袋的事情很难办。
我们实际的操作方法，大概是这样的：找出要开发的需求（可能xR，比如OR，DR，AR，SR等），然后由设计人员（通常只有一个人）逐条拍脑袋给出一个值来。所有的值加起来，就是最终的估计值了。
为什么软件规模估计会存在偏差，而且往往估计偏高呢？我查看了一下A项目估计数据，发现几个现象：
1、对于大颗粒的估计对象，往往估计得很大，非常不准确；
2、对于可以重用的部分，没有考虑；
3、存在重复估计；
4、每个xR估计值至少是500行，与实际相差太远；
5、xR之外的估计要不要考虑？除了xR之外，可能存在一些公共的机制、库、隐含的DFx等代码需要估计，这部分也最好单独拿出来；
6、按xR估计还是按所有功能打包估计？这要视我们对软件对象的掌控能力，不同的人可以采用不同的方法。我建议两个方法都估计，然后再根据两个方法的估计结果进行讨论修正；
7、什么时候做软件规模估计？软件规模估计的时机点比较多，甚至每个TR点都有必要做一次估计。TR3点基本上是最后一次软件估计了，这个时间点的估计非常重要，要力求准确。我推荐在估计之前，要形成初步的代码架构设计。有了代码架构，对需要做什么，要写哪些.cpp，哪些.h，有哪些公共代码，已经有一个初步的掌握了。此时再来估计，相对就会准确一些；
8、使用NBNC和有效代码行来描述软件规模，哪个更合适？拿A项目来讲，NBNC 12k，有效代码VLOC 5.5K，投入两个人分别工作1.5人月，一共3人月，NBNC生产率为4k，VLOC生产率为1.8k。我司生产率标准为大约600行/人月，我记得600行/人月应该指的是NBNC？这样一比，我也不太确定究竟哪个更合适用来描述软件规模了，似乎业界通行使用NBNC吧？
究竟如何才能比较准确的进行软件规模估计呢？说实话，我也没有什么好方法，我谈一下我的理解。A项目实际开发结果与最初的估计偏离还是比较大的，我想主要有如下原因：1、估计规模偏离大，虚高；2、精英开发模式，采用最少代码实现既定功能；3、合理的代码架构；4、采用C++开发（原设计是按C方式开发的）；5、开发进度相比预期提前，除了规模偏差之外，还有一个不能忽视的因素，就是为了项目成功主动自愿加班。
软件规模准确估计很难，但估计不准确对项目开发影响又很大。做软件的人，面对要开发的软件，只要熟悉它，通常可以给出比较准确的估计。要投入多少人，做多久，基本上有一个比较恰当的判断。但是，这种判断一定要杜绝私欲，就是给自己留有非常大的旋转空间，这不仅会害了自己也会害了项目。A项目就是一个例子，一看31k的规模，要在2个月内开发出来，这得需要多少人啊！？因此，项目Leader到处找人，协调人，找不到那么多人啊。幸运的是，有捍码队出马，一个顶x个，不到两个月就搞出来了。
虽然准确估计软件规模很难，但我们还是可以从以下因素来考虑。2、哪些人参与软件规模估计？我觉得包含这几类人即可：开发人员、设计人员、估计专家，通常也就是2~3个人。一般来讲，开发人员与设计人员一起估计就差不多了。
3、估计代码行还是估计工作量？我觉得估计工作量（人天或者人月）可能更好一些，因为不同的人、不同功能的生产率不一样。
4、估计对象大些好还是小些好？我觉得估计对象要尽量细化，越粗越不好估计，越不准确。比如A项目有好几个功能，每个功能估计都是4000行，这个粒度就太大了，肯定不准确。而且估计的最小粒度是500行，这个基本单位也太大了。
5、可重用部分要不要考虑？有些功能可以重用基础功能，这部分在估计时要考虑进去，可以重用的部分单独估计。同时要杜绝重复估计，A项目的估计就存在重复估计的问题。
