功能尺寸测量方法

这是博客的第二部分，重点介绍一些流行的软件规模测量方法及其对软件项目估算的有用性. 在第二部分中，功能大小测量方法IFPUG, 涵盖 NESMA 和 COSMIC. 在以后的博客中，我将介绍非功能性尺寸测量方法和混合方法.

非常建议对这个话题感兴趣的读者先阅读 本博客的第一部分, 在阅读第二部分之前.

对于可用于软件项目估算的特定软件规模测量方法, 以下特征应适用:

• 尺寸测量方法可在物镜中进行 (独立于做这件事的人), 可重复的, 可验证，因此 站得住脚的 大大地;
• 大小本身仅在以下情况下有用 历史数据 可用该尺寸测量方法测量的项目;
• 尺寸测量方法应支持 参数化模型和/或工具 为了准确地考虑影响估计的项目特定特征, 比如 可可二号, 苗条的, 软件 SEER 要么 真正的计划.

当然, 任何不符合这些标准中的一个或多个的软件规模测量方法可能对组织仍然非常有用, 只要他们制定程序以确保可重复的尺寸测量, 收集和分析历史数据和/或根据收集的数据建立自己的估计模型. 然而对于这个博客, 重点是在尚未实施参数化估算过程的组织的背景下，特定测量方法对于软件项目估算的理论实用性. 对于这些组织, 愿意实施规模测量方法以估计软件项目, 这个博客可以作为选择特定方法的指南.

我鼓励大家在这个博客上提交评论和/或反馈.

内斯马FPA

Nesma FPA 与 IFPUG 非常相似，因为它测量相同的基本功能组件 (BFC的 [24]) (ILF, EIF, 没有, 是的, 情商) 现在两种方法的计数准则几乎没有区别. 许多专家使用 IFPUG 功能点中测量的大小等于 Nesma FP 中的大小. Nesma 在估算方面优于 IFPUG 的主要优点是可以使用许多衍生方法，这些方法被认为是 ISO/IEC 标准的一部分:

• 指示性 FPA – 当仅指定数据模型时，可以在项目生命周期的早期使用此方法. 准确率不是很高 (-30% / +50%), 但通常足以在项目生命周期的早期阶段仅需要 ROM 估计时有用.
• 高水平FPA (又名. 预估FPA) – 这种方法被认为是当今的主要方法, 因为大多数功能文档缺乏能够使用标准 Nesma 的细节 (或 IFPUG) FPA. 高级 FPA 对每个基本功能组件使用固定的复杂性评估: 逻辑文件的低复杂度和函数的平均复杂度. 这种方法可以在数据模型和函数已知的情况下使用, 但是在哪些功能中使用哪些属性的细节缺乏或不完整 (经常是这样). 这种方法的准确度约为 -8% 至 +15% (看到 这张纸).

此外, Nesma 区分 项目规模 (添加到现有系统的功能点数, 加上系统中改变的功能点数, 加上删除的功能点数, 加上完成项目需要实现的软件功能点, 例如转换软件) 和 产品尺寸 (交付给用户的应用程序的功能大小).

Nesma 是一个非常活跃的志愿者社区，他们不断致力于在新类型或特殊类型的软件项目中使用该方法的新方法. 尽管这些不是 ISO/IEC 标准的正式组成部分, 这些方法对于软件估计非常有用. 例如，广泛使用的指南是:

• FPA用于软件增强
  使用这种方法在一些国家实际上是强制性的，以便承包商能够投标政府项目.
• SOA 环境中的 FPA (只有荷兰语)
• 数据仓库项目中的 FPA
• 项目生命周期早期阶段的 FPA
• FPA 应用于用例 / UML 文档

该 估算的依据 (英国央行) 对于由 Nesma 和 AACE国际, 总成本管理权, 是一种非常有用的方法来基线任何软件项目估计, 同时也证明了估算者已经考虑了他估算中重要的所有方面. 内斯玛 (联合会) 大多数商业和非商业参数化软件估计模型和工具都支持该方法.

下表列出了评估此方法对软件项目估算的有用性的特征:

特征	是/否	评论
目的, 可重复的, 可验证和可辩护的	是	ISO / IEC 24570:2004
历史数据可用	是	ISBSG R13: 187 专案 (5433 与 IFPUG 结合使用时)
模型/工具支持	是	质量管理, 扫描电镜, 真正的计划, 可可二号, ISBSG

 

联合会

IFPUG方法是功能尺寸测量中使用最广泛的方法. 在所有要求中, 它仅测量功能性用户需求，并以内部逻辑文件的方式进行测量 (ILF), 外部接口文件 (EIF), 外部输入功能 (没有), 外部输出功能 (是的) 和外部查询 (情商) 功能被识别和分类的复杂性. 软件的复杂度按以下方式分类: 低, 中或高, 取决于所涉及的数据属性数量等项目, 引用的文件数或作为逻辑文件一部分的记录类型数. 对于内部逻辑文件 (ILF) 例如, 连接到低复杂度 ILF 的功能点的数量是 7 功能点 (FP), 中等复杂度的 ILF 得到 10 FP 和一个高复杂度的 ILF 得到 15 FP. 每个函数有最小点数，每个函数有最大点数. 虽然这在一定程度上简化了分析过程, 不同的逻辑文件和函数的大小之间可能没有足够的细微差别，这被认为是一个缺点. 例如, 复杂的外部输入函数的大小是 6 FP, 但是一个非常复杂的 EI 的大小是 6 点以及极其复杂的 EI 的大小也是 6 FP.

IFPUG 方法作为估算符合以下特征的项目最有用的方法 (不限):

• 该软件是面向数据的, 许多 CRUD (创建, 读, 更新, 删除) 指定功能
• 该软件是面向管理的
• 提供详细的功能设计，其中数据模型完整清晰，所有功能都清楚使用哪些数据属性

当测量功能需求的大小时, 有多种方法可以将其转换为估计值. 使用将要实现软件的组织的历史数据通常是最好的方法, 最好有专业的估算工具支持. 如果历史数据不可用, 国际软件基准标准组的开放数据库可以证明非常有帮助. 它包含超过 6700 专案 (释放 13) 其中许多是在 IFPUG 中测量的. 大多数商业和非商业参数化软件估计模型和工具都支持 IFPUG 方法.

下表列出了评估此方法对软件项目估算的有用性的特征:

特征	是/否	评论
目的, 可重复的, 可验证和可辩护的	是	ISO / IEC 20926:2009
历史数据可用	是	ISBSG R13: 5244 专案
模型/工具支持	是	质量管理, 扫描电镜, 真正的计划, 可可二号, ISBSG

 

COSMIC

通用软件测量国际联盟 (COSMIC) 是自愿的, 全球软件度量专家组. 开始于 1998, COSMIC 开发了一种测量软件功能大小的方法，旨在克服 Nesma 和 IFPUG FPA 的一些感知缺陷. 而 Nesma 和 IFPUG 主要用于衡量管理软件的大小, COSMIC 也适用于测量实时和基础设施软件的大小. 该方法是完全“开放的”; 所有方法文档都可以在公共领域免费下载.

COSMIC 方法的主要优点之一是它允许测量专家将软件划分为软件层和对等组件, 这使得可以测量驻留在单独的体系结构层或相互通信的不同组件中的软件的功能大小. 这克服了 Nesma 和 IFPUG 方法的一个明显缺陷, 不允许以这种方式划分软件.

另一个重要的优点是该方法遵循比例尺. 因此，每个功能流程的功能大小可以是介于 2 COSMIC功能点 (每个功能过程的最小值) 和 (理论上) 无穷.

通常 COSMIC 方法非常适用于使用敏捷方法开发的项目. 这些类型的项目通常提供的文档类型 (例如. 用户故事, 用例, 活动图, 序列图, 类图) 通常很容易用 COSMIC 以非常准确的方式测量.

虽然 COSMIC 的使用越来越多，认证从业者的数量也在增加, 仍然没有很多开放的基准数据可用. ISBSG 新开发和增强存储库版本 13 (二月发布 2014) 包含关于 500 在 COSMIC 中衡量的项目, 而在 IFPUG 功能点中衡量的项目数量远高于 5000 专案.

COSMIC 方法通常特别适用于使用功能规模估计以下类型的项目时:

• 实时软件项目;
• 移动应用软件项目;
• 基础设施软件项目;
• 在分层架构中交付软件的软件项目;
• 行政软件项目.

功能文档至少应显示软件实现的功能过程以及用户与软件之间的数据移动.

下表列出了评估此方法对软件项目估算的有用性的特征:

特征	是/否	评论
目的, 可重复的, 可验证和可辩护的	是	ISO / IEC 19761:2003
历史数据可用	是	ISBSG R13: 488
模型/工具支持	是	质量管理, 扫描电镜, 真正的计划, ISBSG

还有两个 ISO/IEC 功能尺寸测量标准, 光纤SMA 和 马克二世, 但由于这些方法仅用于特定的当地社区, 本文不讨论它们.

所有功能尺寸测量方法都非常适合软件项目估算. 然而，软件大小只是估计的一部分. 应使用相关的历史生产力数据将大小转换为估计值. 当已知功能点的功能大小时, 它应该乘以项目中可能需要的每个功能点的最可能小时数. 虽然有几种专业的参数化工具可用, 并且可以轻松获取包含历史数据的数据库, 许多组织认为使用功能规模测量既复杂又耗时，并且他们发现很难为他们需要估算的项目确定准确的生产率. 他们更喜欢耗时较少的方法或更易于应用的方法. 不幸, 这也意味着这些方法可能不那么准确.

下一篇博客

在下一篇关于这个主题的博客中, 我将就主要的非功能性规模测量方法对软件项目估算的有用性发表我的看法.

 

关于作者

Harold van Heeringen 是 Metri 的高级基准测试顾问. 除了他为 Metri 所做的工作, 他参与了 Nesma (董事会成员), 国际软件基准标准小组 (ISBSG, 现任总统) 和通用软件度量国际联盟 (COSMIC, 国际咨询委员会, 代表荷兰).

博文代表作者个人观点
而并不一定与官方NESMA政策一致.