3.指标和软件指标

一、指标和软件指标

• 措施（Measure）
  产品或过程某些属性的程度、数量、尺寸、容量或大小的定量表示
• 测量（Measurement）
  确定度量的行为
• 公制（Metric）
  系统、组件或过程拥有给定属性的程度的定量度量（IEEE 标准术语表 SE 术语）
• 指标（Indicator）
  指标是一个指标或指标组合，可提供对软件过程、软件项目或产品本身的洞察
• 指标特征
  • 易于理解和精确定义
  • 使用便宜
  • 强壮的
  • 随着时间的推移保持一致和使用

为什么要measure

• 表示产品的质量
• 评估生产产品的人员的生产力
• 评估从新的软件工程方法和工具中获得的好处
• 形成估计的基线
• 帮助证明对新工具或额外培训的要求
• 当你可以衡量你所谈论的内容并用数字表达时，你就对它有所了解
• 但是当你不能衡量它，当你不能用数字来表达它时，你的知识是贫乏的，不能令人满意的– Lord Kelvin
• 你无法控制你无法衡量的东西。– DeMarco

为什么要使用指标

• 更准确
• 可比
• 测量
• 测量不是目标，目标是通过测量、分析和反馈提高软件开发质量

指标指南

• 在解释指标数据时使用常识和组织敏感性
• 定期向收集措施和指标的个人和团队提供反馈
• 不要使用指标来评估个人
• 与从业者和团队合作，设定用于实现目标的目标和指标
• 永远不要使用指标来威胁个人或团队
• 指示问题区域的指标数据不应被视为“负面”。 这些数据只是流程改进的指标
• 不要执着于单一指标而排除其他重要指标

示例指标

• 缺陷率
• 错误率
• 测量者
  • 个人
  • 模块
  • 开发中
• 错误应按来源、类型、成本分类

软件指标

• 软件指标被定义为使人们能够定量确定软件过程、产品或项目具有特定属性的程度的单位
• 与软件系统、流程或相关工件相关的任何类型的度量

指标类型

• 流程指标
• 产品指标
• 项目指标

软件指标基线过程

过程度量（process metrics）

• 过程度量是软件开发过程的度量，例如
  • 总体开发时间
  • 使用的方法类型
• 跨所有项目和长时间收集过程指标
• 他们的目的是提供导致长期软件过程改进的指标

要改进任何过程，合理的方法是：

1. 测量过程的特定属性
2. 从这些属性中得出有意义的指标
3. 使用这些指标来提供指标
4. 指标导致改进策略

量化管理

• 软件过程和产品都被定量地理解和控制
• 量化管理不等于指标。 指标是表示项目或组织状态的指标。 另一方面，定量管理涉及基于指标和历史数据做出决策
• 量化管理的重点是使过程稳定和可预测

过程度量

• 关注作为可重复或管理过程的结果而实现的质量。战略性和长期性
• 统计软件过程改进 (SSPI)。 错误分类与分析：
  • 所有错误和缺陷均按来源分类
  • 记录纠正每个错误和缺陷的成本
  • 计算每个类别中的错误和缺陷数量
  • 分析数据以查找导致组织成本最高的类别
• Defect Removal Efficiency (DRE-缺陷排除效率). Relationship between errors (E) and defects (D). The ideal is a DRE of 1
  • DRE= E / (E + D)

如何衡量软件过程的有效性

• 我们间接测量软件过程的有效性
• 我们根据可以从过程中得出的结果得出一组指标
• 结果包括
  • 软件发布前发现的错误
  • 交付给最终用户并由最终用户报告的缺陷
  • 交付的工作产品（生产力）
  • 耗费人力
  • 日历时间消耗等
  • 符合日程安排

项目指标

• 项目度量是软件项目的度量，用于监视和控制项目
• 它们使软件项目经理能够：
  • 通过进行必要的调整以避免延迟和潜在的问题和风险最大限度地缩短开发时间
  • 持续评估产品质量并修改技术方法以提高质量
• 从过去的项目中收集到的指标被用作对当前软件项目进行工作量和时间估计的基础
• 随着项目的进行，将人力和日历时间花费的实际值与原始估计值进行比较
• 项目经理使用这些数据来监视和控制项目
• 由项目经理和软件团队用于调整项目工作流程和技术活动
• 指标：
  • 每个 SE 任务的工作量或时间
  • 每个审核小时发现的错误数
  • 计划与实际里程碑日期
  • 变化次数及其特点
  • SE任务的努力分布
• 产品指标是软件产品在其开发的任何阶段（从需求到已安装的系统）的度量
• 产品指标可以衡量：
  • 软件设计的复杂性
  • 最终程序的大小
  • 生成的文档页数

软件测量的类型

• 直接措施
  • 易于收集
  • 例如。 成本、工作量、代码行 (LOC)、执行速度、内存大小、缺陷等
• 间接措施
  • 更难以评估且只能间接测量
  • 质量、功能、复杂性、可靠性、效率、可维护性等

指标标准化

• 为了回答这个问题，我们需要知道项目的规模和复杂性

• 但是如果我们对这些措施进行标准化，就可以比较两者
  对于规范化，我们有两种方法：

  • 面向规模的指标

    基于所生产软件的“大小”

    • 面向规模的指标的优势

      可以轻松计算 LOC
      许多软件估计模型使用 LOC 或 KLOC 作为输入

    • 面向规模的指标的缺点
      LOC 度量依赖于语言和程序员
      它们在估计中的使用需要很多难以实现的细节

  • 面向功能的指标

    • 基于软件提供的“功能”

    • 使用称为功能点的度量间接测量功能

    • 功能点 (FP) 是使用基于可数软件度量和软件复杂性评估的经验关系得出的

    • 计算FP的步骤

      1. 计数测量参数
      2. 评估值的复杂性
      3. 计算原始 FP（见下表）
      4. 对复杂性因素进行评级以产生复杂性调整值 (CAV)
      5. 计算调整后的 FP 如下：FP=原始 FP ×(0.65 + 0.01 ×CAV)
      • 软件信息域值
        用户输入数
        用户输出数
        用户查询次数
        文件数
        对外接口数量
      • 速率复杂性因素
        对于每个复杂性调整因素，在 0 到 5 的范围内给出评级
        0-无影响
        1- 附带
        2- 中等
        3- 平均
        4- 显着
        5-必不可少的
      • 复杂性调整因素
        1. 系统是否需要可靠的备份和恢复？
        2. 是否需要数据通信？
        3. 是否有分布式处理功能？
        4. 性能很关键吗？
        5. 系统会在现有的、利用率很高的操作环境中运行吗？
        6. 系统是否需要在线数据输入？
        7. 在线数据输入是否需要在多个屏幕或操作上构建输入事务？
        8. 主文件是否在线更新？
        9. 输入、输出、文件或查询是否复杂？
        10. 内部处理复杂吗？
        11. 代码是否设计为可重用？
        12. 设计中是否包括改装和安装？
        13. 系统是否设计用于不同组织的多个安装？
        14. 应用程序的设计是否便于用户更改和使用？
      • 复杂度调整值
        • 所有因素 F1 到 F14 的评级相加，以产生复杂性调整值 (CAV)
        • 然后将 CAV 用于计算软件的功能点 (FP)
      • FP特性
        • 好处
          独立于语言，基于项目早期已知的数据，有利于估算
        • 缺点
          计算复杂度，主观评价，FP没有物理意义（只是一个数字）

二、软件质量指标

• 软件质量指标是软件指标的一个子集

• 它侧重于产品、过程和项目的质量方面

• 正确性

  • 这是每个 KLOC 的缺陷数，其中缺陷是经验证不符合要求

  • 缺陷是程序用户在程序发布供一般使用后报告的问题

• 可维护性

  • 这描述了在发现错误时可以更正程序、在环境发生变化时进行调整或在客户更改要求时增强程序的容易程度
  • 平均变更时间 (MTTC)：分析、设计、实施、测试并将变更分发给所有用户的时间
    • 可维护的程序平均具有较低的 MTTC