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

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

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

　　WBS分解和估算的关系

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

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

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

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

　　估算方法

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

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

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

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

　　估算的科学和艺术

　　估算模型是科学，专家经验是艺术

　　估算过程是科学，灵活调整是艺术

　　参数模型是科学，个体影响是艺术

　　过程定义是科学，过程裁剪是艺术