今天谈下软件开发中的软件规模估算话题。

软件项目估算杂谈

软件估算是软件项目计划制定中的一个关键内容，在软件项目管理里面，特别是在进行进度计划安排的时候，一定不是先确定工作量并安排进度，而是先基于SOW和项目范围进行规模估算，基于规模再来评估工作量，最后才是基于资源约束思路(关键路径或关键链）来安排具体的进度计划。

规模，工作量，资源和工期

软件项目的复杂性就在于这几个因素间基本都没有简单的线性关系可寻。在项目过程不成熟或积累的历史数据不够的时候，慎用直接估算规模的方法，因此及时估算了规模也不清楚团队的实际生产率情况，无法根据规模推出具体的工作量。在这种情况下一般可以直接估算工作量，在项目进度跟踪过程中再收集产出物的规模数据以积累历史数据，方便后期建立相关的预测模型。

功能点和代码行是可采用的规模数据，但采用代码行时候往往无法区分不同的代码类型本身往往具有不同的复杂度，对于逻辑层实现算法的代码和UI层实现简单完整性代码，虽然可能相同的代码行，但其复杂度不同将直接导致工作量的不同。对于任意一个功能点的开发基本都会涉及到DB,逻辑层和UI代码，因此可以给出一个综合的代码生产率数据，然后根据该数据到计算工作量。

当新项目的规模比历史项目规模大几倍的时候，往往工作量会成指数级增长，在这种情况下要谨慎采用原来的线性比率关系。可以借鉴Cocomo模型来估算项目的工作量和项目工期。当预计出项目工作量人月后，最好能够根据历史经验和模型来预测在不考虑人力资源限制情况下项目可以完成的最短周期。虽然这个时候还没有考虑活动任务排序和资源约束，但基本可以得出一个经验数据。

WBS分解和估算的关系

项目在做详细估算的时候往往项目周期已经确定，因此为了可以满足进度WBS的分解颗粒度和进度的安排就至关重要了。比如在开发阶段现在有四个人可以进行并行开发，这个时候WBS最好能细化出四个可以并行的任务,当发现预排的进度无法满足要求的时候，需要再投入4个人，这个时候就需要WBS进一步分解以满足8个人能够同时进入并行开发。当WBS分解导致后期集成工作量超过并行节约的时间时候，基本就到了进度能够压缩的极限。所以WBS和估算没有完全的先后关系，分解后进行估算，在估算过程中又在调整和分解WBS。

当项目人力资源很固定的时候，WBS分解更需要按现有人力资源情况进行考虑和分解，这个时候分解的粒度最好和项目可用人力资源匹配。总体原则仍然是前紧后松，让项目人力资源在项目一开始就能够完全动起来，而不是要漫长地等待前续工件和任务。

当考虑了人力资源仍然无法满足进度要求的时候，需要考虑我们采用的方法论，如是否可用增量迭代的方法替换瀑布模型，如果可以则需要完全根据增量迭代思路重新分解WBS，对于采用不同生命周期模型情况下WBS往往存在较大的差异。

当以上仍然无法满足进度要求的时候，我们可以考虑对过程进行裁剪，重点保证对产品质量有重大影响的核心过程元素。当进行过程裁剪仍然无法满足的时候，你需要考虑的是人的因素，去寻找开发生产率比一般人高5倍以上的开发高手，而不是在明知WBS无法细分的情况下继续往项目里面投人。

估算方法

在项目没有太多积累的情况下，依赖专家去估算往往是最有效的方法。专家估算是一种没有纸面化的Bottom-Up估算方法，因此专家估算的准确度往往是比简单的类别估算准确度高的。采用三点法估算的计划评审技术仍然是专家法的一种，这种方式的估算可以让我们更加清楚项目进度的一个范围值。

功能点法是一种经过实践验证的方法，但应用成本很高，估算的工作量投入也较大。功能点法最终结果是规模，仍然需要知道项目的生产率数据才能得出实际的工作量。另外功能点法估算的结果无法直接和WBS分解的工作包和具体的任务对应起来，这是一个较难解决的问题。

Cocomo估算是一种关于软件成本估算的方法，但仅给出一个可行的模型，项目没有足够多的历史数据根本无法确定出各调整因子和系数。但一旦项目建立起这种模型，则通过Cocomo模型得出的项目工作量和项目周期具有更高的准确度。

观察历史项目中工作量和项目规模的数据，通过回归拟合可以得出生产率，工作量，生产率三者间的参数模型，这个参数模型可以用来我们通过软件项目的规模来预测实际的工作量。

功能点估算原理和方法

功能点估算原理说明

Function Point Estimation 功能点估算是一种用来估算项目大小的技术。

功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。

功能点法和专家法估算最大的不同点在于对估算规模的细化的定量分析上面．我们在用专家法估算的时候往往会直接去估算工作量，或在规模的估算中掺杂了生产率的数据，导致估算数据出现问题．专家法估算虽然有时候也很准确，但不能提升为组织级可以参考和借鉴的同样规则．其实专家法的估算要做准确也是遵循了功能点法估算的思路，在考虑一个软件功能究竟涉及到哪些操作，涉及到多少数据文件的存在，每个操作需要访问哪些数据文件等相关问题．只是这些想法停留在专家头脑里面而没有量化出来．

我们的预测，分析和决策能力要提升，就必须对我们的经验进行模型化和定量分析．功能点法正好就起到了这个作用．其实功能点发也有不完善的地方，这可以根据我们项目实际的使用情况去不断的改进。

功能点发进行估算的时候具体过程是：

1.对估算功能单元的类型进行识别
2.计算每种类型的复杂度．
3.计算总体的调整前的功能点数
4.根据调整因子对功能点数进行调整

功能点估算中有5种信息域需要进行描述：其中事务类的有EI,EO和EQ，数据存储类有ILF和EIF，具体如下：

 外部输入(EI):通过界面等的输入，插入更新等操作都是典型外部输入
 外部输出(EO):仅仅输出，入导出，报表，打印等输出
 外部查询(EQ):先要输入数据，在根据输入数据计算输出，如查询
 内部逻辑文件(ILF):可以理解为业务对象，可能对应多个数据表
 外部接口文件(EIF):其它应用提供的接口数据

A.对事务类功能点的估算

对事务类的功能点估算需要确定DET和FTR两个指标。

对于DET可以理解为界面的录入具体数据项，按钮也要作为数据项。而对于FTR则是事务功能需要操作的数据文件的数目。

对EI的复杂度的计算参考下表：

对EO和EQ复杂度的计算参考下表：

B.对数据存储类功能点的估算

对数据存储类功能点的估算需要确定DET和RET两个指标。

DET代表的是具体数据存储文件的数据项的数目。而RET代表的是数据文件是复合文件时候关联或引用的个数．如订单数据文件由于存在订单头和明细关联引用,RET应该算2。也就是说当数据文件注册的单表越多，那么RET值越高。

对ILF和EIF复杂度的计算参考下表。

信息域数据估算完成后可以开始考虑调整因子。

调整因子是一种补偿机制，即通过五个信息域和复杂度都还没有办法考虑到的因素就应该做为调整因子．如同样一个软件系统一种是系统要支持分布式和自动更新，而另一种是不考虑这种需求，如果不考虑调整因子这两者的规模是一样的，但很明细第一种情况复杂度和规模都会更大些。具体参考下表。

有了调整因子后最终可以得到调整后的功能点数:

AFP(调整后功能点)= UFP (未调整功能点数目)* AF (影响因子)

功能点估算案例说明

项目我们举一个简单的软件功能模块实现的例子来进行说明。

需求：实现一个订单的录入，更新，删除和查询功能．订单信息是指一个用户订购的公司产品的情况．其中订单头包含了具体的类型，订购时间，发运地址，客户名称等信息．订单明细包含了订购的具体产品的数量的情况．

假设用户表和产品数据表已经建立，本次订单功能开发仅仅是引用获取这些数据。同时暂时不考虑在单据保存时候的其它其它特殊业务逻辑和权限。

功能界面情况如下：

STEP1:计算出EI,EO和EQ事务功能

对于订单保存功能，项目自我约定对于组合框DET算2,对于GRID的DET算3.其余界面控件DET都算1,所以可以数出DET数目为15.再来考虑FTR数目，这里需要操作订单数据文件，客户数据文件和产品数据文件FTR数应该算3.

STEP2:计算出ILF和EIF事务功能

这里订单文件只算一个DET，但后台数据表会涉及到两个数据表．由于订单头和订单明细有关联关系，所以这里RET取2。

客户文件和产品文件虽然不是外部系统文件，但本次开发的功能并不需要再去设计该数据文件和数据表，所以这里把其作为EIF来处理．

STEP3:根据对应表计算各个信息域复杂度的情况．

最终的估算情况如下：

最终的未调整的功能点数目为:61

调整因子在这里不再举例说明了,如项目调整因子为1.08，则最终功能点数为：

AFP = 61*1.08 = 66.

还有些没有细化考虑的，如具体的DET数量的计算规则等。

注意软件功能点估算得出的是最终软件的规模而不是工作量，规模必须和人的生产率结合才能够最终转换为工作量数据。

比如张三生产率为22功能点/天，那么该功能点工作量就是3人天。而李四开发效率低，仅仅是11个功能点/天，那么工作量就是6人天。

CocomoII成本估算模型

COCOMO的发展历程和很多IT管理相关模型的产生一样有着十分传奇的色彩，和其国的Levi’s品牌牛仔裤一样有着悠久的历史。1981年的一天，师出TRW汤普森·拉莫·伍尔德里奇公司[美]计算机科学部从事软件开发成本估算研究工作的Barry Boehm博士——一个为成全天下软件开发事业而投身到历史的洪流中去,决意用智慧为世界迎来崭新的明天的人。

功夫不负有心人，在历经日以继夜的无数次失败后，终于在这一天提出的结构性成本估算模型——“构建式成本模型”(COCOMO)，它是一种精确、易于使用的成本估算方法，而且是一个和Putnam一样已经得到业界数据的验证的模型。

时过境迁，在随后的10年岁月里，在美国空军任职的Ray Kile先生,对其进行了修订改良，形成了中级COCOMO增强版，同时也是美军使用的标准版本。Boehm从来没有放弃成为一个伟大软件成本估算模型专家的理想，而一直从事如何有效地将COCOMO有效地运用到软件项目成本估算工具当中，他意识到IT界的发展极为迅速，如果没有发展和创新COCOMO终究有一天将会被社会所淘汰，被世人所遗忘，所以到了1996年，Boehm博士根据软件发展情况，终于发布了改进版，将COCOMO升级为COCOMOII，而COCOMO II是对经典COCOMO模型的彻底更新，反映了现代软件过程与构造方法。

首先我们应该了解一下COCOMO模型中用到的一些变量，当然还有COCOMOII模型的类型和分类，这是估算软件成本的重要环节：

COCOMO模型中的变量

DSI——-源指令条数。不包括注释。1KDSI = 1000DSI。

MM——-开发工作量（以人月计） 1MM = 19 人日 = 152 人事 =1/12 人年

TDEV—–开发进度。(以月计)

COCOMO模型的类型

COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）

嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。

半独立型（semidetached）：介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。

COCOMO模型的分类

COCOMO模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详细COCOMO模型。

其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。

COCOMOII不仅可以评估开发工作量，而且可以对项目的进度进行具体估计。 COCOMOII拥有规模计算，工作量估算，进度估算等重要能力能很好地帮助我们软件维护和进行软件决策。对我们在对项目的范围，时间，成本等管理是十分有利的条件，使我们拥有更多时间去关心项目的质量和使得人力资源更有效分配和利用起到极其重要的作用。可以从产品大小估计的结果中计算出项目的总体人员工作量和时间表。除了大小输入，另一项关键输入是对团队生产率的评测。该输入值可确定项目的总工作量。总的项目时间表与总工作量之间存在非线性的关系。遗憾的是，这些模型从数学的角度来看非常复杂，但是COCOMOII模型正好给我们的工作简化其中复杂的过程，为我们赢得更多的有效时间。

PM nominal = Person months effort of the project (人月工作量)
A  = Constant representing the nominal productivity (工作量调整因子)
B  = accounts for the relative economies/ diseconomies of scale (规模调整因子)
Size = Size of the project (规模,千代码行或功能点数目)

首先这里我们可以看到COCOMO是一个典型的参数估算模型。其中重要的就是两个调整因子和规模的确定上面。

对于软件项目的规模，最适合的还是采用功能点法进行估算，在估算出功能点后可以根据功能点和代码行的折算关系得到代码行的估算数据。因此我们看到COCOMO本身并不能够解决规模估算的问题，更重要的是根据系统已经有的规模来确定项目的工作量和项目周期。

B是规模调整因子，也叫做过程调整参数，当B=1时候说明了工作量和规模之间是线性的关系，这个时候就等同到了我们平时通过规模/生产率来确定项目的工作量的情况上面。但根据实践经验，项目工作量并不是完全由简单的个体生产率来确定的，还涉及到开发灵活性，架构风险，团队，过程成熟度等很多的影响因素。因此需要对B进行适当调整,具体的调整规则参考下表：

B = 1.01 + 0.01 ( PREC + FLEX + RESL + TEAM + PMAT)

这里一般B一般都是大于1.01的。当B<1的时候，说明项目架构，开发环境，团队都足够健壮和稳定。这个时候项目表现出来了对规模的经济性，当规模成倍增加的时候，工作量反而不要翻倍。当B>1的时候，说明了项目工作量对规模的非经济性。当规模增加的时候可能会导致工作量的成倍增加。

简单来讲就是规模和工作量直接本身也不是简单的线性关系，当软件项目规模增大的时候一般都带来复杂度的增加，而复杂度往往导致工作量非线性成倍增加。

对于调整因子A一般都是常量，这个需要总结历史项目的度量数据进行反推来计算。因此说要使用COCOMO成本估算模型，必须积累足够多的历史经验数据。

在工作量估算出来后，就可以根据工作量来估算项目的进度。个人认为COCOMO最大的贡献在于对项目进度的估算，如果说对工作量估算还存在当B=1的时候工作量和规模会成为线性关系的话，那对于进度估算则基本上不会出现简单的线性关系。基本上都说明了项目的进度不是简单的根据工作量除以资源的投入而得到的。

TDEV代表项目的进度，其中单位仍然按月计算。

通过Excel绘制出工作量与进度的关系曲线如下：

从上图可以看到工作量和进度之间呈现出类似学习曲线的关系，即当工作量成倍增加的时候，进度并没有得到有效提升，当工作量增加的时候进度本身的提升能力相对缓慢。类似在《人月神话》这本书里经常谈到的一句话，即向落后的项目中不断的投入人手，往往导致的是项目进度进一步落后。