软件项目估计方法及应用.doc
软件项目估计方法及应用 凡事预则立,不预则废。一个好的开始项目等于成功的一半,软件项目的成功关键在于一个切实可行、安排合理的项目计划。某种程度上来说,项目计划的好坏已经决定了项目的成败。而要做好项目计划,则必须从优秀的项目估计开始。 《孙子兵法》云:“夫未战而庙算胜者,得算多也,未战而庙算不胜者,得算少也。多算胜,少算不胜,而况于无算乎 !”意思是说,在拉开战幕之前,就详细分析敌我实力,商讨周密的作战计划,充分评估有利条件和不利条件,开战之后就往往会取得胜利 ;反之,没能进行周密“庙算”,开战之后就往往会失败,更何况不进行“庙算”呢 ?由此可见,预先估计对于一件事情的成败的重要性是至关重要的,甚至是决定性的。 项目估计如此重要,那么我们如何才能做好估计呢 ? 很多项目经理会说,我们也做了估计,可是最终还是失败了,这又是为什么呢 ?对这 些失败的项目进行“尸体解剖”,我们发现这些项目经理往往是对项目估计认识不充分,缺少正确的项目估计的技能和知识,从而导致项目估计工作不完整、不全面、不准确,因而无法有效的支撑项目计划的制定。 估计的方法及流程 以项目的初始估计为例,完整的项目估计活动应该遵循如图所示的步骤: (1) 作为项目估计的输入,需求要尽可能的明确。需求描述的越清晰、越完整,估计的结果偏差就越小。 (2) 在估计的操作中,被估计的需求应进行一定程度的分解。理论上,分解的颗粒度越精细,估计的结果的精度也越高。但在实际操作中 ,需要考虑两个方面的因素。一方面,项目从启动到结束,需求的可分解性是逐渐增加的,因此在最初的阶段,需求分解不太可能达到非常精细的程度,即使强制进行了细致的分解,对估计结果的影响也不明显 ;另外一个方面,需求分解的越细致,操作的工作量也越大,估计的成本也越高。因此,需要把握需求分解的颗粒度,要找到其中的平衡点。 (3) 规模估计的目的是衡量最终交付产品的规模量级。对于软件项目的规模一般是代码行 (LOC,或 KLOC)。常用估计方法通常有 Delphi 方法、类比法、功能点估计法和 PERT估计法 a) Delphi 法 i、 组织者向专家发放项目需求,估计专家熟悉项目需求。一般由 3~ 4 名专家参与估计为佳。 ii、 组织者向各专家提供项目规格和估计表格 ; iii、组织者召集小组会各专家讨论与规模相关的因素,并设定估计结论的接受标准。一般以估计差异 的方差值在某一设定的范围内为可接受 ; iv、 各专家匿名填写估计表格 ; v、 组织者整理估计结果,计算差异,并将估计结果告知各专家 (注意匿名 ) vi、 组织者组织讨论估计差异较大的估计项 ; vii、 专家针对差异不可接受的项目进行再次估 计,并再次填写估计表格。 viii、 重复 4-6, 直到达到估计的偏差达到可接受的范围为止。 b) 类比法 i、 整理出项目功能列表和实现每个功能的代码行 ; ii、 标识出每个功能列表与历史项目的相同点和不同点,特别要注意历史项目做得不够的地方 ; iii、 通过步骤 1 和 2 得出各个功能的估计值 ; iv、 输出规模估计。 c) 功能点估计法 功能点估计是基于系统功能的一种规模估计方法。通过研究需求或设计来确定各种功能和特性的数量,从而计算出规模。通常的步骤是: i、 确定计算 功能点的基准。例如将一个输入操作作为一个功能点,将其他功能按照其复杂度这算成以此功能点为基准的数值,并将此数值作为企业规模估计的基准 (此基准的颗粒度大小可以根据企业自身的情况来选择确定 )。例如 读键盘输入 = 1 FP 屏幕打印输出 = 1 FP 数据库查询 = 2 FP 数据库更新 = 4 FP TCP/IP 连接 = 3 FP API 接口调用 = 2 FP …… ii、 计算需求或设计中包含各种功能单元的数量。 iii、 将这些数据进行加权求和,即可得到该软件的功能点规模。 iv、 如果企业已经习惯于用代码行来进行后续的估计处理,则可根据历史数据,将功能点换算成代码行,以便于后续的处理。也可以将功能点估计的结果直接用于后续的工作量、成本、进度估计。这取决于企业的工作规范和数据积累。 d) PERT 估计法 PERT 估计法是对项目规模按三种不同情况估计:期望规模 E、最低可能规模L,最高可能规模 H。然后通过计算得出估计结果 R=(L+4E+H)/6。 在项目不同阶段,通常需要同时结合 2 种以上的方法。例如 ,在项目前期,需求尚未完全明确的阶段,一般采用类比法、 PERT 估计法进行初步的估计。在需求较为明确后,使用 PERT 估计法结合 Delphi 法或功能点估计法,则可得到更加精确的估计结果。 规模估计的结果将会得到项目最终将输出的代码行。 (4) 在得到软件规模的结果后 Size,可根据企业度量的生产率数据 P,可计算得到工作量 W=Size/生产率 (人天 ) (5) 最后根据工作量、以及能够获取的资源数量、人力成本情况,则可计算得到项目的工期和进度,以及项目人力成本的估算结果。 软件项目估计的误区及注意事 项 实际工作中,很多企业在实践中已经在使用上面提到的各种方式来进行软件估计,但他们却难以得到理想的效果。这又是为什么呢 ? 很多项目经理在实际操作中,只注意到估计的方法和流程,但软件估计作为一项工程方法,仅仅遵循一些这些方法是不够的,必须之一它的一些注意事项。 (1)首先,估计的准确与否,与参与估计的“专家”能力是息息相关的,及时方法再正确,如果由一些经验不足的人员来从事该项工作,也无法得到理想的结果。因此,必须保证参与估计的人员是公司里面较为资深的人员,对产品和技术都有充分的了解。 (2)其 次,软件项目管理是一个系统工程,必须注意其他方面对估计工作的影响。例如,一些公司过度重视项目的工期,对于延期的项目会有较为严重的处罚 ;还有的公司将项目的工作量与奖金多少相联系。这些措施直接导致项目成员为了能够减少被处罚的几率,或者多得到奖金而人为的夸大规模估计的结果。 而在正常情况下,由于技术人员的个性和思维特征,项目估计的结果都会偏于乐观。因此企业可以根据各个项目估计与实际的偏差规律来进行必要的修正。 (3)一些项目在进行估计之前,就已经确定了项目的工期等目标,这使得估计人员会产生一种与期望的结果 一直的倾向性,导致估计不够客观。还有一些企业,在项目人员提交估计结论后,高层管理者会与项目组“讨价还价”,毫无根据的消减规模估计的结果,这样多次之后,项目经理会在估计结果的基础上可以的添加一定的幅度来应对领导的“砍价”,形成恶性循环,从而使估计工作的成果落空。 (4)估计不是统计,因此存在误差是非常正常的。一些项目经理认为每次项目的初始估计都有明显的偏差,因此逐渐放弃了此项工作。这是一个误区。我们应该记录每次项目估计的偏差程度,在进行了多个项目后,将积累的数据进行分析,找到一个平均的偏差值,并将此数值作 为后续估计的修正参考。这样长期积累,将会逐步提高软件估计的准确性。 (5)软件估计在一个项目的生命周期过程中,需要多次进行。分别在立项、需求、设计、编码、测试等阶段来进行。随着项目的逐步推进,每次估计的结果将更加接近真实的情况。在每次估计后,应及时更新项目计划,如果出现原来计划没有考虑到的问题,应及时做出调整。 很多项目经理只在项目初始阶段做一次估计,后面就不再做了。实际上,这是估计的认知不足。估计工作是一个循序渐进,逐渐趋于真实的过程,不是一次性的,因此必须多次反复才能取得良好的效果。 (6)还有一种情况导致估计的结果偏差严重,那就是没有考虑重用等因素。很多软件项目都可以重复使用以前的技术文档、设计或者代码、测试用例等,但一些项目估计工作过程中没有充分评估这部分所带来工作量变化,或者评估的不够充分。在度量的基础上,可以发现各种重用给工作量带来的影响,例如设计的重用能够节省多少工作量,代码的重用会有多大影响 ?此外,不同的重用比例也会有不同的影响。这些都可以通过历史数据的积累来得到参考依据。 (7)在将规模转换为工作量的过程中,对于生产率的理解存在一些错误。很多研发人员会将编码阶段的编码效率作为 生产率来计算工作量,这直接导致了工作量计算的偏差。 这里所说的生产率,是指软件项目整个生命周期过程中的生产率,包括技术文档的写作、编码以及测试、项目管理、质量管理等所有的活动。如果单纯理解为编码的效率,那么可想而知,工作量的计算结果自然无法准确。 (8)在从工作量转换为工期的工程中,很多项目经理都直接用工作力量来除以项目组的人数。这里存在着一个巨大的误区,我们一起来分析一下。 在项目进展的各个阶段,项目投入的资源数量是不一样的,大致的趋势如下: 在项目的开始和结束阶段,投入的资源并不多,而高峰期往往出现在设计、编码、测试阶段。如果简单的将工作量除以项目组的人数,就没有考虑到项目的这种资源投入的特点。 此外,项目具有自身的规律,超出限度的增加资源来缩短工期,或者延长工期来减少资源,都是无法达成的。因此项目管理者必须充分了解项目的客观规律并遵循这一规律,不要将估计工作变成了数字游戏。 小结 一个优秀的软件项目,从优秀的项目计划开始 ;一个优秀的项目计划,从优秀的估计工作开始。然而很多企业只关注到了项目的计划、监控工作,却忽视了软件估计这个 重要环节。导致项目从一开始就沿着一套错误的路线在行进,越是紧跟计划,越是严密监控,距离项目目标就越远。这其中良好的估计就是关键。我们常说画龙在点睛,项目这条大龙,计划是龙头,而软件估计就是龙头上的点睛之笔 !