王斌 韩雷
摘要:估算软件规模是软件研制计价中非常重要的一环。传统的源代码行法在估算软件规模方面有诸多的不便之处,因此今年新下发的《军用软件研制概算计价规范(试行)》采用了改进的“快速功能点法”进行软件功能规模估算。本文对此方法的基本概念进行了介绍,给出了实施方法和具体步骤,并给出了一个应用举例,可为软件研发部门估算软件功能规模提供参考。
Abstract: Estimation of software scale is a very important part in software development and valuation. The traditional source line method has many disadvantages in estimating software scale. Therefore, the newly issued "Military Software Development Budget Valuation Specification (trial)" uses the improved "Fast Function Point Method(FFPM)" to estimate the software function scale. This paper introduces the method and the concrete steps, and gives an example of application, which can provide a reference for the software research and development department to estimate the software function scale.
關键词:功能点分析;软件规模估算;软件计价
Key words: function point analysis;software size estimation;in terms of software
中图分类号:TP311.5 文献标识码:A 文章编号:1006-4311(2020)14-0220-02
0 引言
中央军委装备发展部在2019年初下发了《军用软件研制概算计价规范(试行)》(以下简称“规范”)。“规范”中明确规定了军用软件研制计价由综合费用、直接非人力成本、收益三部分组成。其中综合费用中软件研发工作量部分采用改进的基于功能点的软件功能规模估算方法进行计算。因此,正确熟练地应用该方法,是正确估算军用软件研制费用的基础。
1 软件功能规模估算方法介绍
1.1 源代码行法估算软件功能规模的不足
目前,业界主流度量软件规模最常用的方法是“源代码行法”。该方法虽然简单直观,但存在着明显不足。
1.1.1 没有代码行规模度量标准 即使相同功能、相同技术实现的软件,由于开发人员不同,其代码行数量也会存在较大差异;
1.1.2 人为增加代码行,性能质量下降 通常情况下相同功能的软件,代码行越少,性能越好、质量越高,以代码行为基础计算软件开发成本,不能正向牵引软件编码质量的提高;
1.1.3 开发完成前难以度量 对于软件计价,开发前必须进行度量。源代码行法完成软件编程后才能得到代码行,无法及时开展软件规模度量;
1.1.4 不利于项目管理 代码行法是从技术实现的角度度量软件规模,不便于客户和管理人员理解。
1.2 “快速功能点法”概述
功能点分析法(FPA),是一种以功能点(Function Point)为单位测量软件功能规模的度量方法,最早由Daich[1]和Kitchenharm[2]提出。该方法是一种分解类的规模度量方法[3],即把复杂系统分解成子系统进行评估的方法。它主要是基于软件文档对功能性需求进行分析和度量,使用内部逻辑文件(Internal Logical Files,ILF)、外部接口文件(External Interface Files,EIF)、外部输入(External Inputs, EI)、外部输出(External Outputs,EO)、外部查询(External Query,EQ)等5种组件分解系统功能,以功能点数的形式表示软件规模[4]。它从用户视角出发,定义明确,便于计算,不同计算着计算结果误差在10%以内。“规范”中采用“快速功能点法 (Fast Function Point Method,FFPM)”进行软件功能规模估算。此方法是参考NESMA等国际标准进行软件功能规模估算的方法,删除了国际标准中不适用军用软件的内容,统一了复杂度权值,对规模调整因子进行了优化,可操作性更强,易于理解和掌握。
2 实施方法
“快速功能点法”对应NESMA标准中的估算功能点计数,主要分为五个步骤:确定估算范围、分解软件功能需求、估算功能点数、用户验证、专家审核。
2.1 确定估算范围
①收集支撑用户功能需求的文档。包括立项综合论证报告、软件研制总要求、软件需求规格说明、软件概要/详细设计等文档,上述文档应按照有关规定通过评审或者有效性审查。
②确定计数类型。按照新研、改进项目或升级项目区分对待划定功能规模估算范围。
③划分度量边界。从用户视角将被度量软件划分成若干个估算对象,厘清每个估算对象的逻辑用户及相互间接口关系,确定度量边界。
2.2 分解软件功能需求
①需求功能分解。在確定的软件功能规模估算范围内,将用户功能需求分解到可以被估算的最小功能单元。
②识别数据功能。根据数据功能的定义及特征,逐一识别每个估算对象包含的数据功能并分类,主要包括ILF和EIF。
③识别事务功能。根据事务功能的定义及特征,逐一识别每个估算对象包含的事务功能并分类主要包括EI、EO、EQ。
2.3 估算功能点数
①估算原始功能点数(UFP)。根据公式
UFP=7×ILF+5×EIF+4×EI+5×EO+4×EQ (1)
估算出原始功能点数量。
②确定规模调整因子(VAF)。
VAF=1.3+0.1×(F1+F2+F3+F4+F5+F6+F7) (2)
其中F1~F7为从关键性、分布式处理、性能、计算机资源限制、复杂处理、可重用性、多环境等7个方面描述软件特性的调整因子,其描述和评分标准详见“规范”,VAF取值范围一般为1.3~2.7。
③估算调整后功能点数(FP)。
FP=269.6446+0.7094×UFP×VAF (3)
最终得到调整后的功能点数即为软件功能规模。
2.4 用户验证
估算完成后,将估算结果和最终用户和相关干系人(使用者、所有者、其他系统)对项目的功能规模进行确认和核实。验证包括:结果正确性、对于需求规格说明的解释和假设,必要时应对估算结果做出修正。
2.5 专家审核
软件功能规模估算一般由软件研发单位实施,得到软件功能规模后,应编制相应文档,将和用户确认过的估算结果交由功能规模度量专家进行审核和验证。
3 应用举例
以某信息管理系统为例,介绍本方法的应用过程。首先根据软件需求规格说明,确定估算范围;然后基于本系统尚处在需求分析阶段的实际情况,决定“快速功能点法”进行功能点数估算;再根据《软件需求规格说明》分解功能单元,并计算数据功能和事务功能。计数结果见表1。
计数结束后,根据公式(1)估算出原始功能点数UFP。
UFP=7×ILF+5×EIF+4×EI+5×EO+4×EQ=70+35+80+25+64=274FP
随后,需确定软件规模调整因子。根据软件安全关键等级以及需求和用户的描述,确定软件规模调整因子分值,见表2。
根据公式(2),本例中规模调整因子VAF的计算结果为:
VAF=1.3+0.1×(F1+F2+F3+F4+F5+F6+F7)=1.3+0.1×2=1.5
根据公式(3),计算调整后功能点数(FP)
FP=269.6446+0.7094×UFP×VAF=269.6446+0.7094×274×1.5=561.208FP
最后,需将估算结果(含数据功能和事务功能的原始值)一并上报给专家进行审核验证。需要注意的是,军方审核结果只核减不核增,这就研发单位的估算人员细致工作,务必将数据功能和事务功能统计清楚。
4 结束语
“快速功能点法”在以原始功能点数作为衡量软件规模的主要依据的同时,还考虑了软件基本特征对研发工作量的影响,这些影响通过规模调整因子体现。相对于基于代码行的方法,基于功能点的软件规模估算方法易于用户理解,可以在项目早期使用,有相关标准支持,运用一致性较好。
但是本方法仍存在一定的不足之处。比如,当软件中存在大量复杂算法、数学模型、概念创新等复杂智力劳动时,其价值不能通过功能规模估算方法体现。此时可考虑补充采用类比法、类推法等其他方法估算软件功能规模;公式(3)中的系数269.6446和0.7094是通过大量实际项目数据分析得到的经验参数,不一定适用于所有的软件,可以进一步扩大统计范围,根据不同软件类型确定不同的参数值。
参考文献:
[1]Daich T G, Price G, Dawood W. Metric Tools; Size, In: CROSSTALK, Aril 1995:21-25.
[2]Kitchenham B. Marking Process Predictions. In: Fenton N E, ed. Software Metrics: A Rigorous Approach. UK, Chapman & Hall, 1991,337.
[3]GB/T 36964-2018,软件工程 软件开发成本度量规范[S]. 国家市场监督管理总局,中国国家标准化管理委员会,2018.
[4]ABRAN A ROBILLARD P N. Function points: A Study of Their Measurement Processes and Scale Transformations[J]. Systems Software, 1994, 25: 171-184.