介绍
这是博客的第三部分，重点介绍一些流行的软件规模测量方法及其对软件项目估算的有用性. 在第三部分中，介绍了非功能性尺寸测量方法. 在关于这个主题的下一篇也是最后一篇博客中，我将介绍混合方法.
非常建议对这个话题感兴趣的读者先阅读 第一部分 和 第二部分 在阅读本博客系列的第三部分之前.
对于可用于软件项目估算的特定软件规模测量方法, 以下特征应适用:
- 尺寸测量方法可在物镜中进行 (独立于做这件事的人), 可重复的, 可验证，因此 站得住脚的 大大地;
- 大小本身仅在以下情况下有用 历史数据 可用该尺寸测量方法测量的项目;
- 尺寸测量方法应支持 参数化模型和/或工具 为了准确地考虑影响估计的项目特定特征, 比如 QSM SLIM, 软件 SEER, 真实计划 要么 可可二号.
当然, 任何不符合这些标准中的一个或多个的软件规模测量方法可能对组织仍然非常有用, 只要他们制定程序以确保可重复的尺寸测量, 收集和分析历史数据和/或根据收集的数据建立自己的估计模型. 然而对于这个博客, 重点是在尚未实施参数化估算过程的组织的背景下，特定测量方法对于软件项目估算的理论实用性. 对于这些组织, 愿意实施规模测量方法以估计软件项目, 这个博客可以作为选择特定方法的指南.
尽管本博客中所写的所有内容均基于个人经验和公开文档 (参考), 我想强调的是 此博客仅反映我个人的观点和信念 因此我并不是说这个博客中写的一切都是绝对的事实. 我的个人信仰不一定也是我所属组织的信仰: 仪表, Nesma 和 ISBSG.
我鼓励大家在这个博客上提交评论和/或反馈.
非功能性尺寸测量方法
而功能尺寸测量方法只测量用户需求的功能尺寸 (软件应该为用户提供什么), 非功能性尺寸测量方法测量 (经常是) 非功能性用户需求, 可以是技术用户要求和/或质量用户要求 (软件应该如何工作). 交付的代码的度量也被认为是非功能性的大小度量.
最广泛使用的非功能性大小度量是源代码行 (地块).
源代码行 (地块)
源代码行对许多人和组织有吸引力，因为一旦软件系统准备就绪, 它可以由源代码计数器自动计数. 经常, 开发工具已经在项目期间测量了代码行数.
许多组织使用 slocs 度量作为其软件项目估算过程的输入. 这很了不起, 因为slocs的数量只能在完成后测量. 这意味着在软件估计中使用 slocs, 必须估计 slocs, 未测量. 通常，一个专家团队一起估计新项目的源代码行数和/或使用与以前完成的项目类比的方法来估计要交付的软件大小.
虽然这看起来是个好主意, 这种方法给工作量估算带来了很大的风险. 没有ISO标准 (或任何其他标准) 可用于源代码行. 不同的代码计数工具返回一个 (有时完全) 计算相同代码后的不同结果. 有时测量物理线, 但也经常计算源语句. 因为一个语句可以很容易地写在多行上, 这已经凸显了一个大问题.
此外, 所需的源代码行数取决于技术环境等因素, 复杂性和程序员能力. 源代码行也没有真正代表用户的价值. 获得更多代码行还是更少代码行更好? 更多的行可能意味着更多的功能, 但是如果一个人会根据每人的价格向供应商付款 1000 源代码行 一件事是肯定的……客户会得到很多代码! 代码计数器不应衡量开发工具生成的代码, 但实际上这些工具不可能从测量中排除生成的代码.
因此，通常很难将已完成的软件项目的 slocs 用作下一个软件项目的输入. 使用专家来估算一个新项目的总代码行数，然后根据源代码行数使用历史数据是非常危险的. 通过这种方式估计, 估计的主要输入参数已经存在很大的不确定性百分比.
所以, 为什么许多组织以这种方式估算他们的项目? 部分刊物, 例如 ‘软件缺陷的来源和去除方法‘ 通过卡珀斯琼斯, 声明以这种方式估算项目是一种专业的渎职行为. 有时可能会奏效, 但所涉及的风险是巨大的，可能无法避免因超支而失败的项目. 事实上, 这正是经常被忽视的事情. 大型项目中通常会出现很多问题, 最后，几乎总有可能“归咎于”软件项目中经常出现的一些操作问题……一些技术问题, 或者没有足够参与的产品负责人, 或者 OTAP 环境的实现速度不够快, 或者客户在项目期间改变了很多需求……等等. 然而，在大多数软件故障的情况下, 在分析真正的原因时, 证明这个项目开始时的期望太乐观了……团队太小了, 持续时间太短, 成本太低. 专家估计, 以及不基于行业标准和经验数据的估算 通常从乐观的期望开始. 了解实际估算与项目结果之间关系的组织, 将专注于实施工具，使他们能够尽可能准确地估计项目, 例如，也不奖励供应商提供的过于乐观的估计. 然而, 组织必须达到一定的成熟度才能理解这一点，而这个成熟度对于行业中的许多组织来说仍然很遥远……即使对于那些认为自己非常成熟的组织!
理论上, 源代码行对软件估计根本没有用. 有些人报告这样估计成功的项目, 但从理论的角度来看，这可能是偶然或运气的结果.
下表列出了评估此方法对软件项目估算的有用性的特征:
| 特征 | 是/否 | 评论 |
| 目的, 可重复的, 可验证和可辩护的 | 没有 | 只有在项目完成后才能测量 Slocs. 对于项目估算，只能使用“猜测的 slocs”. |
| 历史数据可用 | 是 | ISBSG R13: 180 专案. 然而, 无法验证测量的 SLOC 类型. |
| 模型/工具支持 | 是 | QSM SLIM, 软件 SEER, 真实计划, 可可二号. ISBSG |
SNAP 积分
SNAP 是“软件非功能性评估过程”的首字母缩写词,” 一种非功能性软件规模的衡量方法. SNAP 点调整是对功能点调整的补充, 衡量功能软件大小. SNAP 是 国际功能点用户组 (联合会), 并使用 软件非功能性评估实践手册, 现在在版本中 2.2.
SNAP 与 ISO 松散连接 9126 和ISO 25010 软件质量标准. 它试图调整软件项目中实现的非功能性需求的规模. 虽然这看起来是个好主意, SNAP 方法似乎没有达到目标. 它没有为所有非功能性需求提供一个完整的测量工具，而且一些高度相关的非功能性需求根本没有被测量. 一些额外的观察:
- 行业中使用的大多数文档都没有明确说明有关 SNAP 试图衡量的非功能性需求的必要信息. 此外, 不清楚缺少此信息时该怎么办. 无论如何都要数数……或者什么都不数?
- 并非所有 ISO 9126 或 ISO 25010 测量非功能性需求的类别. 即使可以使用已发布的方法测量 SNAP 点, 人们认为是重要的成本驱动因素的非功能性需求 (例如. 性能或安全性, 等等), 被忽略;
- 尚不清楚不同 SNAP 类别之间的关系是如何确定的，以及为什么这是有效的. 为什么 UI 复杂 (SNAP 点数 = 添加或配置的属性数 …2, 3 要么 4 乘以唯一 UI 元素的数量) 与批处理过程中测量的非功能性大小相等……或更多……或更少的非功能性大小 (4 次, 6 次或 10 乘以数据属性数). 类别之间似乎没有相关联系，测量 SNAP 点的方式似乎是任意的;
- Abran 教授指出， 统计证明 SNAP 方法未通过通常的有条理的有效性测试, 因为看起来用于证明 SNAP 点和努力之间相关性的数据集中的异常值似乎没有被删除;
- 一些被测量的非功能性需求实际上是功能性的，并且也在 NESMA 和/或 IFPUG 方法中被测量. 这对于声称只测量非功能性需求的方法来说很奇怪.
总而言之, 尽管 IFPUG 和许多从业者都提倡将 SNAP 方法作为一种用于估算的好的有效方法, 从实践和理论的角度来看，在这种方法在项目估算方面变得有用之前，仍有许多问题需要解决. 目前，可用 SNAP 衡量的项目历史数据非常有限. 在 2013, 国际软件基准测试标准组发布了一个 SNAP 数据收集表, 但直到现在还没有收到带有 SNAP 积分的项目提交.
目前, 最多可用于尝试了解已完成项目之间的性能或生产力差异, 但目前还不适合做项目估算.
下表列出了评估此方法对软件项目估算的有用性的特征:
| 特征 | 是/否 | 评论 |
| 目的, 可重复的, 可验证和可辩护的 | 没有 | SNAP 手册应确保客观测量, 但是因为在缺少必要信息时不确定该怎么做, 测量者可能会做出不同的假设，导致不同的规模. |
| 历史数据可用 | 没有 | ISBSG 确实在 SNAP 点捕获项目, 但还没有提交数据. IFPUG SNAP 组中可能有可用数据. |
| 模型/工具支持 | 没有 |
下一篇博客
在下一篇关于这个主题的博客中, 我将就软件项目估算的主要混合大小测量方法的有用性发表我的看法.
关于作者
Harold van Heeringen 是 Metri 的高级基准测试顾问. 除了他为 Metri 所做的工作, 他参与了 Nesma (董事会成员), 国际软件基准标准小组 (ISBSG, 现任总统) 和通用软件度量国际联盟 (COSMIC, 国际咨询委员会, 代表荷兰).