软件工程——共同演进的方法与实践 田文洪 第五章 软件生产率和工作量度量新.pptVIP

第五章 软件生产率和工作量度量 生产率和工作量简介 1 小结 4 项目工作量度量 3 软件生产率估计 2 本章学习目标 1 2 3 理解算法代价估计的原则 掌握生产率度量和项目工作量度量的方法 了解软件生产率和项目工作量度量的含义 软件生产率和项目工作量估算简介 应用场景 项目经理评估各软件工程师的生产率 根据客户需求和公司现有资源来估计项目的工作量和成本 目标问题 如何为某个项目分配合理的人力、时间和相关资源 要完成该项目需要多少工作量（人力）？ 要完成一个项目或任务需要多长有效时间？ 项目或任务的总成本是多少？ 软件产品度量的定义 含义 一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量) 目的 描述（项目和过程） 评估（状态和质量） 预测（为计划） 改进（产品质量和过程性能） 软件质量和组织绩效的决定因素 产品 技术 人力 过程 客户特征 业务条件 开发环境 关键因素 ：程、人、产品、技术 过程处于三角的中心，连接其它三个因素 四个软件项目中缺陷产生的原因 软件生产率估计 软件生产率测量 直接测量：如在一个特定时间内产生的代码行数 一定时间产生的代码行数（LOC） 执行速度 文件页数 错误和缺陷数 间接测量 ：如一个给定时间内生产出的功能点和目标点 功能性 可靠性 可维护性 复杂性 效率 其它质量指标 基于规模的度量—直接测量 一个基于规模的度量的例子 面向规模的度量标准 每KLOC（千行代码）的错误数，即总错误数除以总KLOC 每KLOC（千行代码）的缺陷数，即总缺陷数除以总KLOC 每KLOC（千行代码）的文档页数，即总文档页数除以总KLOC 基于代码行数的度量方法的优缺点 优点 LOC、KLOC和相关度量容易计算 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入 有大量的关于LOC的文献和数据 缺点 LOC依赖于使用的语言，这对短小精悍的程序不利 不太适用于非过程化语言 LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得，例如，项目计划人员难于在分析和设计完成之前估算LOC 功能点度量—间接测量 功能点数从直接度量软件信息域和评估软件复杂性的经验量化关系中获得 一个功能点度量的例子 功能点度量—间接测量 五个信息域值（功能点） 用户输入的数量 用户输出的数量 用户查询的数目 文件数量 外部接口的数量 计算功能点（FP ） 复杂性调整值 系统需要可靠的备份和恢复么？ 需要进行数据通信么？ 有分布式处理功能么？ 性能重要么？ 将该系统运行在一个现有的操纵系统中么？ 系统要求在线输入数据么？ 在线输入数据要求在多个屏幕和操作之间建立输入事务么？ 主文件是否在线更新？ 输入、输出、文件或查询是否复杂？ 内部处理是否复杂？ 代码是可重用的么？ 设计中包括数据（流程）转换或安装么？ 系统要为不同的机构设计不同的安装方法么？ 应用程序便于变更么？易于用户使用么？ 功能点度量—间接测量 功能点计算 每FP的错误数，即总的错误数除以总的FP数。 每FP的缺陷数，即总的缺陷数除以总的FP数。 每FP的文档页数，即总的文档页数除以总的FP数。 每人月的FP数，即总的FP数除以总的人月数 基于LOC度量和基于FP度量的关系 代码行数和功能点之间的关系依赖于编程语言 如何利用度量方法进行生产率估计 问题 某个小组的LOC/人月（或FP/人月）的数据应该和另一个组的相比么？ 项目经理应该使用这些度量方法来评价个人表现么？ 对策 谨慎使用生产率度量，因为有很多因素可能影响生产率 项目工作量度量 算法成本模型—基于经验的度量 软件成本的算法成本模型 其中A是一个常量，由组织的实践和软件的类型决定。Size可以是软件代码规模的估算，也可以是功能点或目标点。B的取值范围为[1,15]。M是反应产品、过程和人力属性的乘数。 算法成本估算的例子 不同软件开发阶段的估算的不确定性 可行性 需求 设计 编码 交付 4x x 2x 0.5x 0.25x COCOMO 模型 COCOMO(构造性成本模型)是一个经验模型, 通过收集大量的软件项目的数据而获得 好处 它已得到广泛的证明。可用于公共领域并且很多公共和商业工具都支持它。 它应用广泛，并得到了不同组织的评价。 它有较长的历史，于1981年第一次实例化[Boehm, 1981]，为了适用于Ada进行了一次改进[Boehm and Royce, 1989]，最新版本COCOMO II发布于2000年[Boehm et al., 2000]。 项目工作量度量 项目计划中的工作量度量 使用C