APP下载

用例功能点软件成本自动计算实践及创新

2023-08-02徐建军陈卫华

自动化仪表 2023年7期
关键词:用例点数度量

徐建军,陈卫华,王 浩,候 斌

(中广核工程有限公司核电安全监控技术与装备国家重点实验室,广东 深圳 518172)

0 引言

“十四五”以来,我国企业数字化转型被提升到重要的战略位置,数字经济和数字产业发展速度正在加快。新形势下,我国软件业界不断通过提升管理水平主动转型,围绕着软件度量构建的进度、成本、质量、效率等指标,持续改进软件开发过程、提升软件产品的交付效率和交付质量。在软件业务规模快速发展的同时,我国软件行业的管理水平依然相对落后,综合竞争能力与软件产业强国相比仍相对较低。据近年发布的中国软件行业研究报告,我国软件行业还存在项目成本高、产品交付周期难以控制等问题。尤其是作为项目成本评估的软件工程规模度量、费用估算标准化问题,一直没有得到科学有效的解决。其主要原因是缺乏标准化、智能化的软件管理手段以及过度依赖人工经验。

软件项目的规模度量和过程控制一直都比较困难。软件具有不可见性、抽象性和知识密集型的特点。与硬件相比,软件没有明显的生产制造阶段,属于非实物性的脑力劳动。随着企业对软件需求的不断发展,业界曾运用预算倒推法、工作分解法、源代码行法以及文档页码数等评价方法,开展软件规模度量和成本估算[1]。但以上方法大都严重依赖评估人员的工作经验和能力,且存在软件开发语言、开发工具、应用环境等方面的差异。客观来看,过度依靠人工方式度量软件规模,不可避免地会给成本估算带来不确定性和效率低下的问题。鉴于此,基于专业和普适的模型和规范,找到1种科学、合理的软件规模度量和成本自动估算方法尤显必要和紧迫。

国内外对软件项目的开发质量和进度控制已有较深入的研究。美国卡内基梅隆大学软件工程研究所在20世纪80年代就提出了能力成熟度模型集成(capability maturity model integration,CMMI),通过软件度量帮助软件企业和软件项目提高项目管理水平和改进软件质量[2]。2018年,CMMI研究院正式发布CMMI 2.0中文版,为软件项目敏捷过程提供直接方法指导。周伯生等对CMMI进行了初次研究,并提出了软件度量模型构建方法和质量模型构建方法[3]。杨勋姮等尝试利用软件自动化技术开展软件过程和质量控制的研究[4],设计了辅助实施质量保证的自动化软件管理工具。冀建伟对相关法规标准,以及软件全过程质量控制的方法开展研究[5]。

本文在长期实践的基础上,提出了基于软件系统用例与功能点相结合的软件成本自动计算方法。该方法通过功能点数的自动计算,利用人工智能、机器学习、自然语言处理等方法,自动从需求文档、技术规范等文本抽取、识别功能点数以提高功能点计数的准确性、提升软件规模和费用估算的智能化水平和效率。该方法具有一定的创新性和较高的应用价值。

1 软件规模常用估算方法

业界传统的软件规模度量方法有专家决策法、类比估算法、源代码行法、功能点估算法等[6]。这些估算法都有各自的适用范围和优缺点。专家决策法是在专家个人和集体判断的基础上形成的1种相对主观的估算方法。该方法的特点是简单、直观,可直接依靠专家团队的集体经验,得出软件开发成本价格。类比估算法是从软件项目或产品历史库中找到与当前待评估软件项目的应用领域、运行环境、复杂度、规模尽可能一致的同类项目,通过1套行之有效的评价与分析机制,得出估算成本。类比估算法虽然简单、直观,但其前提是必须要建有相对完整、可靠的软件项目数据库;其不足是对缺乏历史参考数据的崭新项目的估算有难度。源代码行法是对软件项目各功能模块的源代码长度进行累计。源代码行法虽然简单、直观,但代码行必须从技术开发的角度估算,因此非专业技术人员很难理解和估算[7]。

功能点估算法是近年来业界比较流行的1种软件规模度量方法。该方法通过识别软件需求的内外部逻辑文件及其功能来评估软件的规模。相比专家决策法和类比估算法,功能点估算法在估算方法上更具客观的标准依据,可有效避免对评估人员技术背景的影响[8]。然而,该方法还需通过人工方式计算实现。随着软件规模的增大和项目数量的增多,传统人工估算法的统计效率亟待提高,不能与软件工程智能化发展趋势相适应。用例与功能点相结合的软件规模度量法,正是在借鉴如上常用估算法优劣势的基础上,基于实践提出的1种自动估算方法。

2 用例功能点结合估算模型

2.1 用例的数学定义

用例是软件系统参与者与系统之间一系列交互行为序列的集合。以用例为核心的需求模型如图1所示。

图1 以用例为核心的需求模型

所有用例的集合就组成软件系统需求全集。用例代表了用户的需求,其数学定义为UC=(ACTOR,CON,AHE,{PRO},EXT,RES,REG,REQ)。其中:UC代表图例;ACTOR代表软件系统中完成一系列任务的各类角色;CON代表基本事件过程的触发条件;AHE代表基本事件过程的前提条件;{PRO}代表基本事件集合;EXT代表异常;RES代表后果;REG代表业务规则;REQ代表技术需求。

基于用例来定义系统软件需求,实际上就是以用例需求为核心,通过描述实现该用例的业务边界、业务规则、功能要求、性能要求、界面规范及接口交换等诸多功能,完成各类角色的具体任务和目标[9]。

2.2 功能点的五个功能单元

对用例进行功能点计算,需依据事先确定好的标准,计算出系统用例中每类功能单元所包含的功能点数量。依照国际功能点用户组织(International Function Points User’s Group,IFPUG)标准,目前功能点计算涉及5个功能单元。其中:2个为数据功能单元,分别为内部逻辑文件(internal logical file,ILF)和外部接口文件(external interface file,EIF);3个为事务功能单元,分别为外部输入(external input,EI)、外部输出(external output,EO)和外部查询(external query,EQ)[9]。

2.3 功能点估算步骤

传统的用例功能点估算由人工完成。为提高计算效率,本文估算方法可由计算机对每个用例模板文档进行遍历自动计算。功能点计算步骤如下。①确定用例功能点估算范围与边界。②计算功能单元ILF、EIF、EI、EO和EQ出现的次数。③逐一计算出每个功能单元每次出现的复杂度值。④由复杂度值确定每个功能单元出现的权重。⑤计算得到未校正的功能点数Ufp。根据以上步骤,可得未校正的功能点数Ufp计算式为:

Ufp=NEIWEI+NEOWEO+NEQWEQ+NILFWILF+

NEIFWEIF

(1)

式中:Ufp为未校正的功能点数;NEI、NEO、NEQ、NILF、NEIF分别为EI、EO、EQ、ILF和EIF出现的次数;WEI、WEO、WEQ、WILF、WEIF分别为EI、EO、EQ、ILF和EIF的复杂度加权因子。

经整理,式(1)可简化为:

(2)

式中:Ni,j为第i个功能单元在复杂度j时的出现次数;Wi,j为第i个功能单元在复杂度j时的加权因子。

2.4 确定相关调整系数

根据IFPUG公布的相关标准,软件系统的复杂程度可根据系统特征的性能复杂度、界面复杂度、代码复用要求、系统应用类型、开发语言类型等14项影响因子逐个分析赋值,再按IFPUG公布的调整系数求和式(3),计算得出调整系数Vaf。

(3)

式中:Vaf为求和后的调整系数;N为确定的实际系统性能特征个数,取值为1~14;Ni为第i个影响因子的复杂程度。

软件系统的影响因子影响程度,可按每个影响因子的复杂程度赋值0~5。其中:0为无影响或未出现;1为偶发影响;2为轻度影响;3为一般影响;4为重影响;5为极重影响。需要强调的是,在利用14项影响因子加权调整功能点计算时,可根据具体软件系统的特殊情况,适应性地增加新的影响因子。权值的赋值范围调整可以根据不同的软件系统用线性插值法获取[10]。下面以其中软件应用类型、开发语言类型2个影响因子为例进行说明。本文通过参考中国软件行业基准数据分析报告(CSBMK-202010),综合应用类型、开发语言类型特点和实践经验,获得相应类型的参考调整系数权值。表1为应用类型及应用范围调整系数参考表。

表1 应用类型及应用范围调整系数参考表

表2为开发语言类型及其调整因子参数表。

表2 开发语言类型及其调整因子参数表

2.5 计算软件规模和费用

本文在计算出Ufp的基础上,再与求得的Vaf相乘,计算得到调整后功能点数FP,也就是软件的规模。

FP=Ufp×Vaf

(4)

在计算出功能点数的基础上,根据功能点耗时率计算出工作量。

Ae=Fp×PDR

(5)

式中:Ae为工作量;PDR为功能点耗时率,人时/功能点。

本文在计算出工作量的基础上,根据人月成本,计算出软件开发费用P。

(6)

式中:F为人月成本,元;176为按每月22 d、每天8 h计算得出的工作小时数,h。

3 功能点自动计算实例

3.1 用例文档举例

设计文档起草发文模块用例如表3所示。

本文以核电设计文档管理系统的1个用例规模度量为例,利用语义分析和文本挖掘技术,自动识别并抽取系统需求文档用例表中功能点数,计算出软件规模和价格。1个完整的软件系统需求可以由诸多用例集合组成。而每个用例都可以用1个用例模板表来完整描述。只要通过软件系统逐个对用例表中的功能点数进行标注和统计,就可以通过遍历把整个软件系统功能点数计算出来,再通过转化实现软件系统规模和价格测算的自动化和智能化。

3.2 功能点自动计算算法结果比较

软件功能点计算智能化主要是利用语义分析及文本挖掘技术抽取用户需求文本中的用例表,构建文本与功能点映射关系并自动计算功能点数,度量出软件规模,从而计算费用[11]。功能点标注和计算应有文本自动识别读取功能,且在用例表相应位置予以标注,并根据计算式自动计算功能点数。功能点自动估算算法如下。

伪代码算法:[利用用例模板表计算功能点]

处理步骤A0:导入一张结构化用例表;

do{将用例添加到系统用例集;

do{标注用例表中每个类;

If(若该类为ILF)

{则添加到ILF集,并标注;}

else{则添加到EIF集,并标注;}

do{对事件的行为进行识别:

(1)若为EI,则添加到EI集,并标注;

(2)若为EO,则添加到EO集,并标注;

(3)若为EQ,则添加到EQ集,并标注;

} while (最后一个行为);

do{确定ILF集中的每个类:

(1)计算为该类的一个DET;

(2)计算为该类的一个RET;

(3)确定复杂度值和影响因子;

} while (最后一个ILF类);

do{确定EIF集中的每个类:

(1)计算为该类的一个DET;

(2)计算为该类的一个RET;

(3)确定复杂度值和影响因子;

} while (最后一个EIF类);

do{计算事务的复杂度:

累计EI、EO、EQ和RET、DET总复杂度值和影响因子;

} while (最后一个行为);

} while (最后一个类);

} while (遍历最后一张用例表);

处理步骤A1:求和功能点数,计算出工作量和费用。

根据以上算法,可自动计算出设计文档起草发文模块用例校正后的功能点数,遍历全部设计文档管理系统用例集,累加计算出整个用例集的功能点数。

根据式(4),通过功能点数求出软件系统的工作量Ae,再根据式(5)计算出软件成本。功能点耗时率(PDR)和人月成本(F)2个常量值,可参考软件行业普遍采用的平均水平,按功能点耗时率7.12人时/功能点、人月成本2.85万元/人月进行计算。以上算法全部过程均可通过软件代码算法实现。计算结果如下。

Ae=Fp×PDR=512×7.12=3 645人时

为检验用例功能点自动计算方法的准确性,本文将计算结果与软件系统实际工时进行比较。系统记录实际工时数如表4所示。

项目软件系统按用例功能点法自动计算所得工时合计为3 645人时,折算成软件成本为59.02万元,准确率为80.02%。项目事后实际记录工时4 544人时、实际综合成本75万元,准确率为78.69%。

通过对比可知:从软件规模看,通过功能点自动计算得到的工作量,与实际记录的工作量数据相比准确度较高,准确率达80%左右,偏差为20%左右,远小于接受范围偏差(30%);从软件成本造价看,通过功能点自动计算的工时成本为59.02万元,占项目实际造价成本75万元的78.69%,均在可接受范围内。根据实际经验,功能点估算的准确性主要依靠系统需求的准确性及完整性,因此本文估算方法的计算结果准确性依赖于用例表描述的准确性和完整性。所以在实际软件度量计算中,可根据偏差不断调试影响因子权值,通过迭代持续缩小估算偏差,并为以后的项目估算提供历史经验数据。

4 结论

用例功能点软件成本自动计算方法具有较高的应用价值。该方法以国家标准为依据,从用户需求出发,对用例的功能点进行识别和计算。该方法明确且可量化,结果确定性强。从普适性方面来看,该方法适用于各种不同应用类型的软件项目,可选择与之相对应的调整系数和加权因子,具有应用范围的普遍性。从可迭代方面来看,该方法可根据软件实际评估中遇到的问题,不断调整和优化方法和指标系数。随着技术和业务的高速发展,用例功能点估算法应用场景会越来越多,包括大数据技术结合的功能点度量、云平台上的软件功能点度量等。这将进一步提升软件过程控制的效率和智能化水平。

猜你喜欢

用例点数度量
鲍文慧《度量空间之一》
模糊度量空间的强嵌入
UML用例间包含关系与泛化关系的比较与分析
UML用例模型中依赖关系的比较与分析
迷向表示分为6个不可约直和的旗流形上不变爱因斯坦度量
联锁软件详细设计的测试需求分析和用例编写
從出土文獻用例看王氏父子校讀古書的得失
看不到的总点数
画点数
破解“心灵感应”