NESMA功能点估算(二)

NESMA功能点计数规则

前文介绍了NESMA分析法的3类估算方法,本文主要介绍NESMA标准估算方法的计数,以及逻辑文件、功能操作以及复杂度的计数规则。详细功能点估算法计数规则要复杂的多,阅读时间会比较长。

  • 一、NESMA功能点分析法对比

NESMA功能点估算中已说明,NESMA包括预功能点分析、估算功能点分析和详细功能点分析,三种计数方法对比如下:

类型计数项类型对需求要求精确度/偏差
预功能点分析逻辑文件低/50%
估算功能点分析逻辑文件、交易中/15%
详细功能点分析逻辑文件、交易、复杂度

预功能点分析关注点在于数据,估算功能点分析关注点在于数据和交易,详细功能点分析除了关注数据和交易外,还要对每个功能点的复杂度进行判断。

  • 二、逻辑文件计数规则

预功能点分析关注数据功能,数据功能的关注点都在逻辑文件。逻辑文件分为内部逻辑文件和外部接口文件,两类文件都是与业务逻辑相关的数据。

在应用系统的模型中,数据一般可分为业务数据、业务规则、编码数据。业务数据和业务规则都是业务逻辑范畴,需要逐一计数规模;而编码数据是业务逻辑无关的,都是开发时把一些可能硬编码的数据当作数据字典统一维护起来。对系统边界内的编码数据,统一计数为一个内部逻辑文件;系统边界外的编码数据,统一计数为一个外部接口文件。

  • 1.内部逻辑文件

  • 内部逻辑文件必须是用户所认可的对象。如果不是从用户视角,而是从技术角度产生的数据:中间文件、临时文件等不应该被视为内部逻辑文件。
  • 内部逻辑文件必须经过持久化的,意味着数据在被使用过后依然存在,可以再次使用。
  • 数据必须在应用系统中有用到,并且系统会对数据做增、删、改操作。比如,项目中可能会出现这种情况:需要同步其他系统的数据到本系统,如果该数据仅仅被使用,那数据被视为外部逻辑文件;如果该数据会被修改,则该数据应被视为内部逻辑文件。

        以上3条是内部逻辑文件计数的基本准则。

  • 务必不要遗漏历史数据,当历史数据服务于其他的业务数据时,历史数据就要被识别为内部逻辑文件。
  • 应用程序中包含的常量、文本、解码等实体类型作为一个内部逻辑文件统一进行计数。
  • 2.外部接口文件

  • 外部接口文件同样必须从用户视角看到的,被计数的应用系统所使用。
  • 由另外的应用系统来维护,也就是说外部接口文件不能在本应用中增、删、改,否则就是内部逻辑文件了。
  • 同样,外部逻辑文件也必须经过持久化。

       以上同样是外部接口文件的基本准则,各种计数规则也都围绕这些准则描述的

  • 每个外部接口文件,至少存在一个外部输出(和\或)一个外部输入。外部接口文件必须被系统所使用,如果没有被使用到,要么就是需求没有澄清清楚,要么该文件就确实没什么用。
  • 被计数的系统所引用,但由另一个应用维护的,包括常量、文本和解码等实体类型,应该统一计作一个外部接口文件。
  • 3.FPA数据表

应用程序中,哪些有常量、文本、编码等信息的实体类型,被称为FPA数据表。这些信息能够给用户维护,并被统一计数为一个内部逻辑文件。如果引用的其他应用系统的FPA数据表,则统一被计数为一个外部接口文件。

以下的实体类型都是FPA数据表:

  • 实体类型必须包含一个,且只能包含一个数据项,不管数据类型的数量是多少。
  • 实体类型中包含的数据都是常量
  • 实体类型由一个键值对和一个或多个描述字段等
  • 数据类型中包括不同类型的数据,这种不是FPA表。比如,产品数据包括产品编号、产品名称、地区名称,很明显这不是FPA数据表。
  • 4.预估算分析法计数

了解了逻辑文件的计数规则,在项目早期或者需求不是特别明晰的情况下,已经可以采用预估算分析法计数。只是该方法会存在较大的误差,可能会达到\pm50%左右。

计数公式:UFP=ILF \times 35 + EIF \times 15

三、事务功能计数规则

估算功能点分析法是NESMA三种估算类型中最常用的,它估算的误差比预估算功能法更小,但它除了要求识别逻辑文件之外,还是要识别事务功能。估算功能点分析法对每个功能的复杂度采用缺省值。比如,所有的数据功能采用了低复杂度,所有的事务功能采用了中级复杂度。该方法在估算效率和精确度上获得了较好的平衡。

事务功能包含3个类型:外部输入(EI)、外部输出(EO),外部查询(EQ)。每个事务功能必须保证是用户能够认知的最小的业务操作,如果一个功能还可以继续细分,显然它不是事务功能。

  • 1.外部输入

外部输入简单来说就是从应用程序外部向应用输入数据的过程,它通常导致针对一个或多个内部逻辑文件的增、删、改操作。

  • 如果内部逻辑文件可以被单独维护,那么每个内部逻辑文件ILF至少需要统计一个外部输入。
  • 对用户直接输入数据和源自其他应用程序的数据输入(通过输入文件或消息的形式)都需要被统计。比如,定时启动的批处理任务等都应该被视为外部输入,在估算规模时,时有遗漏诸如定时任务等功能的情况发生。
  • 如果一个输入画面上可以执行增、删、改多个操作,则应该被视为多个外部输入,而不是看作一个大的外部输入。
  • 一个外部输入如果是因为技术原因被引入的,不是用户要求的,则不能视为一个外部输入。
  • 每个内部逻辑文件要至少有一个外部输入,如果发现没有,就要检查统计时是否遗漏,或则需求有缺失。
  • 如果一个删除或者修改功能,先要加载某个业务对象信息,此处,加载对象信息不是一个外部查询。应该把加载对象作为删除或修改过程的一部分。
  • 有些外部输入从外部看好似完全相同,但是维护的是不同的内部逻辑文件,那么应该被视为不同的外部输入。
  • 2.外部查询

  • 外部查询功能项必须是用户认可的。同时,必须是通过输入的数据即时产生输出的数据。这样一个输入-输出的过程被视为外部查询。
  • 外部查询的发起可以通过用户,也可以通过外部的其他应用程序来发起。
  • 外部查询的规模是完全确定的;外部查询的输出不得包含任何需要进一步数据处理的结果;执行外部查询时,不得改变内部逻辑文件。
  • 外部查询和外部输入的区别就是:外部查询的输入数据,只是为了配合执行查询动作,不会影响数据本身;而外部输入会直接影响数据,修改内部逻辑文件。
  • 切勿把外部查询的输入当做外部输入、外部查询的输出当做外部输出。
  • 一个外部查询必须是独立的功能。比如,在修改或删除某个业务对象时需要先加载对象的信息,这个加载对象功能就不能作为一个外部查询,而是作为外部输入的一部分。
  • 3.外部输出

  • 不同于外部查询,外部输出可以不需要数据的输入。如果有数据的输入,也是一些选择性或控制性的信息。比如,生成某年的统计报表,需要先选择年份,这也是外部输出的数据输入,一般比较简单。
  • 不同于外部查询,EO的输出规模是不确定的,而且数据可能包括运算等,会进一步处理。
  • 通常以统计报表或文件的方式提供给用户,或者以消息的方式提供给其他应用程序。
  • 有些输出由于技术原因而引入,不是用户视角的功能,这不能作为外部输出来计数的。
  • 如果一个选择画面、选取列表、弹窗功能,数据源来自逻辑文件,这些都要被统计为外部输出。因为列表长度不确定,因此不是外部查询。
  • 如果一个功能的输出内容完全一样,只是用不同的语言展现,那么应视为一个外部输出。因为虽然语言不通,但展现的数据元素类型相同,数据处理逻辑也想通,应作为一个外部输出。
  • 4.估算功能点分析法计数

估算功能点分析法确定了逻辑文件的数量和功能操作过程的数量,复杂度采用默认值,即数据功能的复杂度采用“低”,ILF、EIF分别为7、5,事务功能的复杂度采用“中”,即EI、EO、EQ分别为4、5、4。

功能点计数公式:

UFP = 7\times ILF + 5\times EIF + 4\times EI + 5\times EO +4\times EQ

正常情况下,如果需求已经明晰,有文档产出,此时就可以进行估算功能点计数。

  • 四、复杂度及参数类型计数

  • 1.确定参数

  • 1.1 记录元素类型(RET)

指一个ILF或EIF中用户可以识别的数据的子集。可以将RET理解为逻辑文件中包含的子表,每个子集都计算为一个RET。如果没有子集,就认为RET为1。

一个逻辑文件的复杂度的记录类型的数量是逻辑文件中的实体类型的数量。比如,添加订单时会保存“订单编号、物品数、订单金额及其他信息、客户ID、客户名称、部门ID”,订单编号、物品数等都是订单信息类型,客户ID、客户名称是客户信息类型,部门ID是部门信息类型,则订单ILF的RET为3(订单信息、客户信息、部门信息)。

  • 1.2 数据元素类型(DET)

数据元素类型指用户能够识别的不重复的元素,并且只有在应用程序中被使用和维护的属性才会被统计为数据元素类型。

数据元素类型的计数规则涉及到数据功能和事务功能2种情形,

数据功能DET的计数规则

a. 根本原则就是必须确保计数的属性是用户认可、被应用程序使用和维护的;

b. 由于技术原因引入的字段,比如时间/时间戳、操作人等字段,如果不是用户特别要求,都不能计入数据元素类型的范围;

c. 把涉及到FPA数据表的所有数据元素统一计数;

d. 如果实体A和实体B之间是多对多的关系,我们一般在2个实体之外会建立一个A和B的关联关系表,此时,这个关联表是不能被视为逻辑文件的。但是,在计算逻辑文件复杂度DET时,要把关联表中的字段作为外键跟实体A、实体B一起来计数。比如,课程表和学生表,一门课会有多个学生参加,一个学生也可以参加多门课程,他们之间是多对多的关系。模型设计时会单独建立一个学生和课程的关联表,这个表是不能作为一个逻辑文件的。但是,在统计课程这个逻辑文件的DET时,除了课程本身的属性,还要把学生ID把统计在内;同样,在统计学生这个逻辑文件的DET时,除了学生属性,还要把课程ID作为外键属性统计在内。

e. 如果2个实体各自具有逻辑独立性,则应该视为2个逻辑文件来统计。

f. 如果一个实体依赖于另一个实体,则应该把2者视为一个实体,DET取所有数据元素的总和;RET按2计算。

事务功能DET的计数规则

a.触发事务功能的事件要引入统计范围。可能是点击按钮、选中菜单事件,也可能是多级菜单选择、然后再点击按钮的一系列事件,这些都都只统计为一个数据元素类型。

b.报错提示信息也要引入统计范围。执行事务功能时给用户的错误提示信息,都要作为一个数据元素类型进行计数。

c.输出的所有处理数据,比如平均值、总计、总数、最大最小值等都要被作为数据元素类型进行计数。

d.事务功能DET统计的基本原则就是所有数据及控制信息必须跨越应用程序边界。比如,字段总金额是通过总量和单价自动计算而来,那么总金额字段是不能被计为一个DET的;流程状态更新、sysdate等同样也不能作为一个DET,因为状态、系统时间等字段不是跨越系统边界输入的。

e.增删改功能,新增或修改功能依据画面的输入字段,删除功能大部分情况下只需要记录主键一个字段。

f.一个外部输入如果由多个页面依次操作,则几个页面被视为一个外部输入。统计数据时应该把这些页面的所有数据整合起来一起计数。

g. 分页组件的功能比如上页、下页等不能作为数据元素类型进行统计;系统日期、页面这样的标准数据不能作为DET。

  • 1.3 引用文件类型(FTR)

引用文件类型是一个事务功能维护或读取的逻辑文件。确定一个事务功能的复杂度的引用文件类型的数量,要把一个事务功能中牵扯到的合法性校验、验证和功能执行中涉及的逻辑文件的数量都包括在内。

统计引用文件类型的数量只能是内部逻辑文件或外部接口文件,其他临时文件、技术原因引入的文件等都不能纳入统计范围。

  • 2.逻辑文件复杂度

计算了逻辑文件的RET和DET后,通过下表可获取逻辑文件的复杂度。

记录元素类型(RET)

数据元素类型(DET)

1~19

20~50

≥51

1

2~5

≥6

  • 3.外部输入复杂度

计算得到外部输入的FTR和DET后,通过下表就可获取外部输入的复杂度。

引用的文件类型个数(FTR)

数据元素类型(DET)

1~4

5~15

≥16

0~1

2

≥3

  • 4.外部输出复杂度

计算得到外部输出的FTR和DET后,通过下表就可获取外部输出的复杂度。

引用的文件类型个数(FTR)

数据元素类型(DET)

1~5

6~19

≥20

0~1

2~3

≥4

  • 5.外部查询复杂度

使用确定外部输入复杂度的计数规则来对外部查询的输入部分进行归类。只需要考虑和输入部分相关的数据元素类型DET和文件类型引用FTR。
使用确定外部输出复杂度的计数规则来对外部查询的输出部分进行归类。只需要考虑和输出部分相关的数据元素类型DET和文件类型引用FTR。
除了使用上述两个分类的复杂度之外,外部查询的复杂度也可以仅考虑与数据输出部分相关的数据元素类型DET和应用文件类型FTR。

  • 6.功能复杂度对照表

复杂度级别

功能类别

ILF

EIF

EI

EO

EQ

\times7

\times5

\times3

\times4

\times3

\times10

\times7

\times4

\times5

\times4

\times15

\times10

\times6

\times7

\times6

  • 7.详细功能点分析法计数

详细功能点分析法是精确度更高的估算方法,对事务功能必须详细到统计涉及到的逻辑文件数量及其数据元素类型,逻辑文件必须详细到数据元素类型和记录类型。获取到这些信息后,就可以计算功能的复杂度。

正常来说,要进行详细功能点分析必须至少设计阶段进行中,已经具备了可行的数据模型,就可以进行计数。

UFP =\sum ILF + \sum EIF + \sum EI +\sum EO +\sum EQ

五、常见计数场景

  • 分页功能不计入功能点

大多的数据查询都会以分页形式展现,分页组件提供了上、下页的翻页功能,这些都是技术、易用性引发的功能,不能计入功能点。

  • 下拉列表等功能要作为外部输出

用户界面中提供的数据列表选择功能,如果数据来源于内部逻辑文件,则应该当作一个EO计入功能点,谨记不能重复计数。如果是FPA数据表,则不计数。当然这里并不是说只有下拉列表才计数,类似的源于内部逻辑文件的数据展现都要纳入计数范围。

如下图中,印章刻制功能中的印章规格、印章类型都来源于印章信息表,这里印章规格和印章类型都要作为一个EO计数;但是印章销毁功能中的印章规格、印章类型就不能再次计数了。

  • 应用的报错信息作为一个DET进行统计

这个在数据元素类型一节有说明。通常在用户交互过程中会有数据校验,每个数据校验都作为一个DET进行统计。

  • 每一类帮助文档都识别为一个EQ

应用系统中会提供不同类型的帮助信息。比如,系统帮助文档,界面的字段提示说明信息等。这些帮助信息,都需要进行一定程度的程序修改或开发。因此,帮助文档也要纳入统计范围,每一类帮助可视为一个EQ外部查询,复杂度默认为“低”。

  • 报表等生成式工具

报表工具通常会提供报表定义、报表设计、文件导入导出等工具,这些功能都是工具本身提供的,不能计入统计范围。只统计客户需求提出的报表、统计等功能,并且每个都被统计为外部输出。

  • 图表、报表等都是外部输出

报表、图表等都统一识别为EO。如需要识别复杂度,则依据需求中使用到的文件引用类型FTR和数据元素类型DET来确定复杂度。

  • 安全与授权

所有系统中都有用户未授权就会自动跳转到登录页功能,认证授权也要纳入考虑范畴。如果安全认证服务是公共平台提供的统一服务,则不计入统计范围。如果是应用系统独立开发,则应该计入功能点数。

  • 不可重复计数

一个功能在系统中只能被统计一次,不可重复使用。比如,某个功能被不同模块多次使用,同一个下拉列表选择框在不同的页面多次出现等,这些都只能统计一次。

  • 生产可复用代码不能增加功能点规模

项目实际开发过程中,项目组可能为了增加代码的扩展性和可维护性,经常要求代码的复用。这会在用户原始需求的基础上增加开发量,增加开发成本。客户并不会为该需求承办风险和成本,不引入计数范围,不会对功能点规模产生影响。

  • 代码复用不能影响功能点规模

软件项目经常会复用已有的代码实现用户需求,从而提供开发效率,但这不会对软件的功能点规模产生影响。

  • 多条件的组合查询

在有多个查询条件的综合查询功能中,我们不能把每个条件都当做一个功能点来进行计数,也不可把综合查询简单的视为一个功能点进行统计。在对相关功能进行估算时切记仔细。

比如一个查询功能包括3个查询条件:姓名、籍贯和部门。如果条件之间具有排他性,这时就不要只把这个查询统计为一个功能点了。假如本实例中录入姓名或籍贯后,不允许录入部门;或者,录入部门后不允许录入姓名和籍贯。这说明存在2个互相排斥的条件录入,所以此时应该计数为2个查询。

在定制类信息化项目中,软件开发费用的测算是一项系统性的工作,需要综合考虑直接成本和间接成本,并运用标准的度量方法。《信息化项目软件开发费用测算规范》为这一过程提供了科学的指导。 参考资源链接:[信息化项目软件开发费用测算规范](https://wenku.csdn.net/doc/5b9x3rc89p?spm=1055.2569.3001.10343) 首先,明确项目需求是测算的第一步。功能需求分析应详细记录所有定制功能,以及实现这些功能所需的时间和资源。随后,依据IFPUG或NESMA等国际功能点度量方法对软件规模进行评估。软件规模的评估结果是连接功能需求与工作量的关键桥梁。 工作量评估后,接下来进行直接成本的计算。直接成本包括所有可以直接归因于项目的成本,如开发人员的工资、软件工具的购买、服务器费用等。对于间接成本的计算,则需要根据开发方的运营情况,估算如研发管理费用、设备折旧等成本。 在计算过程中,还需考虑项目的不确定因素和潜在风险,这些可能会对项目进度和成本产生影响。此外,还应预留一部分变更管理和质量保证的成本,以应对项目过程中可能出现的需求变更和质量控制问题。 最后,将所有工作量、直接成本和间接成本汇总,再根据开发团队的生产力和历史数据进行工期估算,从而得出总的软件开发费用。 在整个测算过程中,遵循《信息化项目软件开发费用测算规范》中的方法和步骤,可以帮助项目管理团队更加科学地进行费用预算和控制,确保项目在预定成本内顺利完成。 参考资源链接:[信息化项目软件开发费用测算规范](https://wenku.csdn.net/doc/5b9x3rc89p?spm=1055.2569.3001.10343)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值