对于软件项目，估算有很重要的地位，估算步骤最好是能够先估算规模，再根据生产率得到总体工作量，再根据总体工作量预计项目各阶段周期。类别估算，参数估算，专家法或三点法估算，功能点估算等都常在软件项目中使用。
在没有充分的历史数据积累的情况下建议参与专家法通过类别方式进行估算，有了足够的历史数据来检验和校正估算参数和可以过渡到功能点估算和专家估算。项目在进行过程中需要不断的积累和收集历史项目的实际执行数据，形成工作量比例分布，生产率等实际的估算参数基准。
1.主体任务工作量估算
在软件生命周期中的需求，设计，编码，测试等活动是项目的主体工作任务，也是估算的重点。对于软件项目在计划阶段很难直接估算到功能点的代码行，因此一般采 用对功能点或用例点进行估算，这样就可以得到需求的规模。需求规模/需求生产率可以得到需求阶段的工作量，再根据工作量比例分布即可以得到设计，编码等阶 段的工作量估算数据。
对于软件项目历史数据足够和积累了更多的经验后，可以根据各阶段产出物的规模/生产率分别来得到各阶段的工作量.
设计工作量 = 设计规模(设计类，接口等数量)/设计生产率
编码工作量 = 代码行/代码生产率
测试工作量 = 测试用例数/测试生产率
通过以上方法基本就可以得到主体任务的规模和工作量估算数据。
2.评审任务工作量估算
项目究竟应该安排哪些评审，在哪个阶段安排，评审的覆盖率要达到多少等都应该根据项目质量计划和质量策略来确定。评审是预防和保证质量，投入适量的评审可以大大的减少缺陷的泄漏和返工。
评审工作量的安排并不是越多越好，项目总周期和工作量是一定的，评审安排太多则后期主体任务和返工工作量则会被压缩。评审的关键是发现可能导致项目重大工作量偏差的缺陷泄漏，而不是要100%防止任何缺陷的泄漏。
对于评审的工作量 = 评审人数*产出物的规模/评审速率
对于不同类型的工件都应该有一个最合适的评审速率，因此评审的工作量应该是根据待评审工件的实际规模确定的，而不是先确定了工作量而在评审过程中随意的去改变评审的速度，这样的话评审很难真正发现关键缺陷。
3.返工的工作量
对于返工主要是因为缺陷引起的，缺陷可能是评审缺陷也可能是后期系统测试的Bug。在软件项目中对于文档缺陷的修改和Bug的修复应该有不同的返工速率，这是需要历史版本收集和校验的重要参数数据。
根据项目历史版本一般可以得到项目的缺陷密度预测数据，因此在估算出当前项目的规模后就很容易得到项目的总缺陷数预计，自然就可以计算返工工作量了。
各阶段的返工工作量 = (项目规模*缺陷密度)/各阶段的返工速率
4.总结
对于软件项目估算，历史项目积累的经验数据越多，越稳定则估算越趋于准确。估算是项目计划的一个重点，估算不准确会造成后期项目计划频繁修改，也就谈不上相应的基线和跟踪控制。
估算出项目总体规模后并不代表项目估算完成，估算数据最终要应用的各个工作包和相关的任务上。因此必须根据各阶段的规模，各阶段的生产率，评审和返工等生产率估算项目中存在的各种类型任务的规模和工作量。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
