10 种软件规模估算简介
规模估算是项目成本估算的先驱条件．也是最关键的软件项目管理任务之一。
下面介绍10种软件应用规模估算的方法：
-
传统的类比规模估算法
类比规模估算法是将新项目与已完成的旧项目进行类比，基于旧项目数据进行估算。
如果有基准数据或者来自类似项目的历史数据．这种规模估算方法可以较早完成，甚至在完全知道新应用软件的需求之前就可以开始类比规模估算。
但是，如果既没有类似项目的历史数据又没有精确的基准数据，类比规模估算法根本就无法工作。
-
基于代码行指标的传统规模估算法
虽然基于Loc指标的规模估算方法应用非常普遍，但它却是有害的。它的害处表现在：
-
当计算方法在物理行数和逻辑语句数之间进行转换时，从相同代码段所计算出来的规模可能会出现超过500％的差异。
-
该指标对高级编程语言的损害与该语言的能力成正比。换句话说，使用Loc指标表示生产力和质量数据，汇编语言看起来比Java或c++更好。
-
Loc指标无法用于估算或度量软件项目的非编码活动，比如需求、架构、审计和用户文档。
-
软件行业存在有超过700种编程语言．其中超过50种编程语言根本就没有已知的源代码计数规则。
-
大多数现代应用软件都用多种编程语言编写，有些应用软件使用了多达15种编程语言．而这些语言每个部有自己独特的代码计数规则。所以即使是Java和HTML的简单混合也使代码计数变得十分困难。
另外，这种规模估算方法对需求、功能说明书和其他书面文档的规模估算无能为力。
-
基于故事点数指标的规模估算法
用户故事包含了特定软件需求非常简洁的描述．只有一两句话组成。它是一种收集需求的方法。
使用故事点估算的一个问题是．没办法将使用故事点度量指标的应用软件与使用功能点、用例点或任何其他软件度量指标进行规模估算的应用软件进行比较。
-
基于用例指标的规模估算法
用例是一种既有文字描述也有图形的需求表示方法。用例中除了角色外还包括许多其他元素．比如前置条件、后置条件等。用例图及其支持文本可以用于功能点及用例点度量指标的计算。
由于用例点的计算比功能点更为简单，用例点规模估算方法比功能点分析稍快一些。
用例点估算的问题也是没办法将使用用例点度量指标的应用软件与使用功能点、故事点、代码行或任何其他软件度量指标进行规模估算的应用软件进行比较。
-
基于IFPUG功能点分析的规模估算法
功能点规模估算方法比基于代码行的规模估算方法更为可靠，因为功能点指标支持所有的软件项目可交付物：书面文档、源代码、测试用例以及错误和缺陷。
功能点分析的实质是由包含如下5个元素的加权公式推导出来的： 1．输入 2．输出 3．逻辑文件 4．查询 5．接口
功能点分析的问题是相当缓慢而且非常昂贵。
另外，精确的功能点分析需要由经过认证/培训的功能点计数方法的人员来执行。
-
使用功能点变体的规模估算法
功能点变体包括但不限于：
1．COSMIC功能点 2．工程功能点 3．3—D功能点 4．全功能点 5．特性点 6．芬兰功能点 7．MarL H功能点 8．荷兰功能点 9．面向对象功能点 10．web对象功能点
其中的COSMIC功能点、荷兰功能点和芬兰功能点等类型已经获得了ISO组织的认证。
虽然功能点变体为了嵌入式软件做了一些改变，但它们依然具备IFPUG功能点的所有优点和缺点：功能点分析相当精确、非常有用，但其速度缓慢而且成本昂贵。
-
使用功能点粗略估计的高速规模估算方法
“粗略估计”是指当使用正规功能点分析的时候，不需要使用或者理解决定功能点规模大小的每一个因子就可以确定功能点的数量。
之所以如此，是因为大多数软件项目在软件需求完成之前就需要有初始软件成本的估算结果，而此时还不可能进行正规功能点分析。
使用最频繁的功能点粗略估计方法包括以下几种：
粗略估算方法可以实现比IFPuG功能点、cosMIc功能点或者任何其他标准功能点分析方法更加快速的功能点计数速度和更为低廉的计数成本。它们的操作速度是标准功能点分析的2倍到20倍不等。
-
基于逆火分析或L0C到功能点转换的规模估算方法
“逆火”就是逆推了从功能点数量预测源代码数量的数学公式。现在也已经形成了转换的基准数据供估算时使用。
尽管通常逆火分析没有真正的功能点计数准确．但对于小于1个功能点的代码变更，逆火分析是当前仅有的能够导出其功能点数量的两个方法之一。
如果源代码规模已知．用逆火分析进行规模估算既快速又便宜。
-
基于模式匹配的规模估算方法
模式匹配方法建立在大量遗留应用软件的规模数据是已知的基础之上。这样就可以通过使用基于软件的性质、范围、类别和类型等信息的分类方法，对软件规模进行估算。
模式匹配规模估算方法内置于一个原型规模估算工具中，可以以超过每分钟300000个功能点的速率预测应用软件的规模。所以它是有史以来软件行业开发的最快和最便宜的规模估算方法。
-
估算软件需求变更的规模
前面的这些规模估算方法所产生的规模估算结果都只是在某单一时间点有效。但是，实际上通过对大量软件项目的观察表明，软件需求在后续的设计和编码阶段以每月1％到超过2％不等的速率增长或者变化。这么多的规模增长必然会对项目进度和成本均产生显著影响。
因此，规模估算方法需要能够处理软件需求的变更和增长．这些需求变化也会导致程序源代码数量的增长。
这正是：
估算方法何其多，快捷有效最难得
收集数据和经验，终有一天会实现
参考书目：《软件工程最佳实践》
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
