软件工程讲义_第十六章估算.ppt.ppt

基于问题的估算 然后，将基线生产率度量应用于适当的估算变量中，导出每个功能的成本或工作量。将所有功能的估算合并起来，即可产生整个项目的总体估算。 对于一个组织而言，其生产率度量常常是变化的，使用单一的基线生产率度量是不可信的。一般情况下，平均的LOC/pm或FP/pm应该根据项目领域来计算。当估算一个新项目时，首先应将该项目对应到某个领域中，然后，再使用恰当的领域生产率平均值对其进行估算。 基于问题的估算 不管使用哪一种估算变量，项目计划人员都要首先为每个功能或每个信息域值确定一个估算值的范围。利用历史数据或凭直觉，计划人员为每个功能或每个信息域的计数值都分别估算出一个乐观的、可能的和悲观的规模值。当确定了值的范围后，就得到了一个不确定程度的隐含指标。 基于问题的估算 接着，计算三点(估算值)或期望值。可能通过乐观值(Sopt)、可能值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量(规模)的期望值S: S=(Sopt+4Sm+Spess)/6 一旦确定了估算变量的期望值，就可以应用历史的LOC或FP生产率数据。任何估算技术，不管它有多先进，都必须与其他方法进行交叉检查。 基于LOC估算的实例 考察一个为机械零件计算机辅助设计应用而开发的软件包。P342-343 图16-2 LOC方法的估算表 基于FP估算的实例 基于FP估算时，问题分解关注的不是软件功能，而是信息域的值。项目计划人员分别对软件的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件进行估算。 图16-3 估算信息域的值 基于FP估算的实例 估算出复杂度加权因子，并计算出复杂度校正因子。最后得出FP的值：FPestimated=总计×[0.65+0.01×∑(Fi)] 基于过程的估算 最通用的项目估算技术是根据将要采用的过程进行估算。即，将过程分解为一组较小的任务，并估算完成每个任务所需的工作量。 同基于问题的估算技术一样，基于过程的估算首先从项目范围中抽取出软件功能。接着给出为实现每个功能所必须执行的一系列的框架活动。这些功能和相关的框架活动可用表格形式给出，如图16-4所示。 基于过程的估算 图16-4 基于过程的估算表 基于过程的估算 一旦将问题功能与过程活动结合起来，计划人员就可以针对每个软件功能，估算完成各个软件过程活动所需的工作量，这些数据写在图的中心部分。然后，将平均劳动力价格应用于每个软件过程活动的估算工作量，就可以估算出成本。但各项任务的劳动力价格可能是不同的。 基于过程的估算 最后一个步骤就是计算每一个功能及框架活动的成本和工作量。如果基于过程的估算是不依赖LOC或FP估算而实现的，现在就已经有了两组或三组成本与工作量的估算，可以进行比较、调和。如果两组估算非常一致，则有理由相信估算是可靠的。反过来，如果这些分解技术得到的结果不一致，则必须做进一步的调查和分析。 基于过程估算的实例 参看图16-4所示的在于过程的估算表，表中对CAD软件的每个功能，都给出了其各个软件工程活动的工作量估算(人月)。其中，工程和构造发布活动又被细分成表中所示的主要软件工程任务。对客户沟通、策划和风险分析活动，还给出了总工作量的估算。 如果需要的话，每一个框架活动或软件工程任务都可以采用不同的劳动力价格，分别进行计算。 基于用例的估算 由于以下原因，建立基于用例的估算方法还有困难： 描述用例时，可以采用多种格式和风格——没有标准形式。 用例表现的是软件的外部视图，常常在不同的抽象级别上建立。 用例没有标识出它所描述的功能和特性的复杂性。 用例没有描述出涉及很多功能和特性的复杂行为。 与LOC或FP不同，一个角色的“用例”可能需要数月的工作量，而另一个角色的“用例”可能在一到两天内就能完成。 调和不同的估算方法 必须对多种估算方法进行调和，以得到对工作量、项目持续时间或成本的一致估算。 如果不同估算之间的差别很大，一般能够追溯到以下两个原因之一： 计划人员没有充分了解或误解了项目范围。 在基于问题的估算技术中所使用的生产率数据不适合本应用系统，过时了，或者是误用了。 计划人员必须确定产生差别的原因，再来调和估算结果。 经验估算模型 计算机软件估算模型使用由经验导出的公式来预测工作量，工作量是LOC或FP的函数，将LOC或FP的结果值代入到估算模型中。 用以支持大多数估算模型的经验数据都是从有限的项目样本中得出的。因此，还没有一种估算模型能够适用于所有的软件类型和开发环境。从这些模型中得到的结果必须慎重使用。 应该对估算模型进行调整，以反映当前项目的情况。应该使用从已完成项目中收集的数据对该模型进行检验——方法是将数据代入到模型中，然后将实际结果与预测结果进行比较。如果两者一致性很差，则在使用该模型前，必须对其进行调整和再次检验。 估