软件项目的复杂性在于，这些因素之间基本上没有简单的线性关系。当项目过程不成熟或积累的历史数据不足时，应谨慎使用直接估计规模的方法。因此，及时估计规模不清楚团队的实际生产率，不能根据规模推出具体的工作量。在这种情况下，可以直接估计工作量，然后在项目进度跟踪过程中收集输出的规模数据，积累历史数据，便于以后建立相关的预测模型。

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

　　当新项目的规模比历史项目大几倍时，工作量往往会成为指数级增长。在这种情况下，我们应该谨慎采用原来的线性比率关系。可供参考Cocomo该模型用于估计项目的工作量和工期。当项目工作量预计为月时，最好根据历史经验和模型预测项目可以完成的最短周期，而不考虑人力资源的限制。虽然此时没有考虑活动任务排名和资源约束，但基本上可以获得经验数据。

　　WBS分解与估算的关系

　　在详细估算项目时，往往会确定项目周期，所以为了满足进度WBS分解粒度和进度的安排非常重要。例如，在开发阶段，有四个人可以并行开发。WBS最好细化四个平行任务。当发现预排进度不能满足要求时，需要再投资四个人，此时需要WBS进一步分解，满足8个人同时进入并行发展的需要。WBS当后期集成工作量超过并行节省的时间时，分解基本达到进度压缩的极限。WBS和估算没有完全的先后关系，分解后进行估算，在估算过程中又在调整和分解WBS。

　　当项目人力资源非常固定时，WBS分解需要根据现有的人力资源进行考虑和分解。此时，分解粒度最好与项目可用的人力资源相匹配。总体原则仍然是前紧后松，使项目的人力资源能够在项目开始时完全移动，而不是等待前续的工件和任务。

　　当考虑到人力资源仍然不能满足进度要求时，我们需要考虑我们采用的方法论，如增量迭代是否可以替换瀑布模型，如果可以，我们需要根据增量迭代的想法重新分解WBS，采用不同的生命周期模型WBS差异往往很大。

　　当以上仍不能满足进度要求时，我们可以考虑切割过程，重点关注核心过程元素，以确保对产品质量有重大影响。当过程切割仍然不能满足时，你需要考虑的是人类因素，寻找开发生产率是普通人的5倍以上，而不是知道WBS如果不能细分，继续投资项目。

　　估算方法

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

　　功能点法是一种经过实践验证的方法，但应用成本高，估计工作量投资大。功能点法的最终结果是规模，实际工作量仍需了解项目的生产率数据。此外，功能点法的估计结果不能直接和WBS分解体任务相对应的分解工作包是一个难题。

　　Cocomo估计是一种估计软件成本的方法，但只给出一个可行的模型，项目没有足够的历史数据来确定调整因素和系数。但一旦项目建立了这个模型，它就会通过Cocomo项目工作量项目工作量和

　　项目周期精度较高。

　　通过回归拟合，观察历史项目中的工作量和规模数据，可以得到生产率、工作量和生产率之间的参数模型。该参数模型可用于通过软件项目的规模预测实际工作量。

　　科学与艺术的估算

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

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

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

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