中国铁路济南局集团有限公司 山东 250000
摘 要 软件造价估算是信息化项目管理中重要的环节。现行铁路行业对软件造价的估算方法通常采用类比法、类推法或者人月工时法,这些方法过于依赖估算人员经验,不同人的估算差异较大,没有科学的依据。不利于项目管理、预算投资、审计等工作开展。本文立足铁路行业信息化项目管理现状,探讨以"NESMA预估功能点法"建立一套合理的造价估算方法,优化铁路行业信息化项目管理水平。
关键词 NESMA功能点法 软件造价 铁路工程
近年来,随着铁路客货运、供电等专业信息化工作快速推进,许多工程都包含信息系统的建设、升级、扩容等工作,比如近些年电力SCADA业务改造,牵引变电所无人化改造辅助监控系统扩容等项目。在单纯的信息化建设项目中,对于委外研发的功能性系统、业务处理软件、OA系统、管理信息系统、各类功能模块等建设都涉及到了大量的软件开发、数据迁移、系统升级等工作。
软件系统的造价估算一直是薄弱环节,大多数情况是采用类比法、类推法、厂家询价或者人月工时的方式。目前软件价格估算工作过于依赖估算人员的经验和既有项目,不同人的估算差距非常大。往往出现很多项目只是简单的数据迁移,但是按照软件开发来报价或者估算。有些信息系统实际工作量很少但是报价虚高,有些系统看似简单实际工作量大,导致造价过低,工期过短的现象出现。国铁集团也没有相应的软件造价估算规范。在没有指导性规范参考的背景下,项目执行单位、设计单位、审批单位在编制及审核项目方案时,都无法提供充分的测算依据,靠着经验主义、拍脑袋的方法确定软件开发的工作量。
2.1常用功能点法介绍
本文采取一种新的估算软件的方法,即功能点法。在功能点法的发展及推进过程中,ISO国际标准组织先后采纳了IFPUG、COSMIC、MARKⅡ、NESMA和FiSMA等五种方法作为ISO国际功能点标准[1]:
a) ISO/IEC 19761(COSMIC-FFP方法);
b) ISO/IEC 20926(IFPUG方法);
c) ISO/IEC 20968(MkⅡ方法);
d) ISO/IEC 24570(NESMA方法);
e) ISO/IEC 29881(FiSMA方法)。
根据相关国际标准中的方法适用范围声明,COSMIC方法适用于商业应用软件和实时系统;IFPUG方法适用于所有类型软件的功能规模度量;MkⅡ方法适用于逻辑事务能被确定的任何软件类型;NESMA方法与IFPUG方法非常类似,但对功能点计数进行了分级,以便在估算的不同时期选择不同精度的方法进行估算;FiSMA方法适用于所有类型软件的功能规模度量。
NESMA是一种与IFPUG极为类似的快速功能规模度量方法,可以在项目不同阶段选择不同的精度,从而对软件规模进行估算。相对于MarkⅡ、COSMIC及FISMA,NESMA的标准与IFPUG的标准保持了最好的一致性。
2.2 NESMA优势。
目前在全球范围内,超过90%的企业选择使用IFPUG及NESMA方法,尤其广泛使用于美国、意大利、德国、韩国、日本等国家,而NESMA方法中的详细功能点法与IFPUG方法基本等效。
以上五种功能点法都是《软件工程软件开发成本度量规范》GB/T 36964-2018中明确要求采用的方法,但是涉及到目前铁路行业使用现状,从普遍性、易用性来说NESMA功能点法更简单、高效、易于推广。
2.3 NESMA功能点法估算软件造价流程。
软件估算,其实是采用一定的方法,对软件系统的规划、工作量、工期、成本等指标的预估,是软件度量过程的一个环节,估算的主要流程包括软件规模估算、软件规模调整,工作量估算、成本估算四个步骤[2]。在最重要的软件规模估算阶段引入NESMA功能点法。
2.3.1软件规模估算阶段。
(1)识别系统功能类型组件。
审核待建信息系统资料,对系统进行详尽的数据功能类组件(ILF/EIF)和事务功能类组件(EI/EO/EQ)识别[3]。功能类型见图2-1。
图 2-1
其中数据功能是指从用户角度按到的逻辑数据组。事务功能是指功能对用户有独立完整的意义,并且执行了一个完整的信息处理过程,并且功能执行后,应用程序处于一个稳定的状态。
ILF(内部逻辑文件):在本系统维护的业务数据。
EIF(外部接口文件):本系统引用,在其他系统维护的业务数据。
EI(外部输入):对数据进行维护或改变系统行为的事务。
EO(外部输出):对数据加工后呈现或输出的事务。
EQ(外部查询):对已有数据直接呈现或输出的事务。
(2)确定每个功能项的重用程度(高/中/低)。
功能的复杂度取决于数据类型的数量和该功能使用到的引用逻辑文件的数量,分三个层次见表2-1:
低:该功能涉及少量数据元素类型和/或引用的逻辑文件。
中:该功能在复杂性方面既不低也不高。
高:该功能涉及许多数据元素类型和/或引用的逻辑文件。
复杂度 | 功能类型 | ||||
ILF | ELF | EI | EO | EQ | |
低 | 7 | 5 | 3 | 4 | 3 |
中 | 10 | 7 | 4 | 5 | 4 |
高 | 15 | 10 | 6 | 7 | 6 |
表 2-1
功能复杂度的具体评估方法在NESMA功能点法有详尽的说明,在这里不再赘述,各集团公司应根据既有信息系统情况建立一套明确包含各系统的软件功能复杂度清单。
(3)计算软件规模估算US。
在概算阶段我们采用指示功能点法计算:
US=ILF*35+EIF*15 (2-1)
在预算阶段我们采用估算功能点法计算,取系统复杂程度为中,按估算功能点法计算:
US=ILF*10+EIF*7+EI*4+EO*5+EQ*4 (2-2)
2.3.2软件规模调整阶段。
根据项目阶段,明确规模变更调整因子CF。根据2023年国家或地方软件行业基准数据[4]公布的CF取值如表2-2:
项目阶段 | 取值 |
可行性研究报告 | 1.85 |
预算(用户需求说明书) | 1.50 |
招/投标(用户需求说明书) | 1.25 |
软件需求说明书 | 1.10 |
软件设计方案 | 1.00 |
表 2-2
规模调整因子指的是在项目的不同阶段可能产生的对最初需求的变化程度,如在可行性研究报告阶段,取数值1.85即为有85%的内容可能会与最初的设计不同,需要对85%的内容进行调整。集团公司既有系统各部分功能基本确定,需求很明确,在预算阶段可以选取1.00-1.25之间,新建系统应遵照表2-2调整。由规模调整因子性质可知选取的数值越小,意味着系统变动越小。
调整后软件估算规模,单位为功能点数FP,计算公式为:
S=US*CF (2-3)
2.3.3工作量估算。
软件开发工作量AE的计算公式为:
AE=(PDR*S)*SWF*RDF (2-4)
(1)PDR为参考最新的国家或地方软件行业基准数据,确定相关业务领域软件开发生产率基准数据,铁路行业的PDR参考表2-3,单位为人时/功能点,可参考交通行业生产率P50中位数。
行业 | P10 | P25 | P50 | P75 | P90 |
交通 | 2.02 | 3.92 | 7.87 | 20.14 | 25.13 |
表 2-3
在既有软件系统或者平台上进行的少量需求优化或者功能性改善需使用维护型开发生产率取值如表2-4。
维护型开发生产率(单位 人时/功能点) | ||||
P10 | P25 | P50 | P75 | P90 |
1.23 | 2.04 | 3.81 | 5.75 | 6.96 |
表 2-4
(2)参照行业经验,确定软件因素调整因子SWF。SWF包含业务领域、应用类型及质量特性调整因子。交通行业业务领域调整因子为1.10。涉及铁路业务的应用类型调整因子如下表2-5。
应用类型 | 范围 | 取值 |
业务处理 | 办公室自动化系统、人事、会计、工资、销售等经营管理及业务处理软件 | 1.0 |
科学计算 | 算法、模拟、统计、大数据分析等 | 1.25 |
多媒体 | 图像、影像、声音等多媒体应用领域;地理信息系统;教育和娱乐应用等 | 1.3 |
流程控制 | 生产控制、仪器控制、实时控制等 | 2.0 |
表 2-5
质量特性调整因子如表2-6。
质量要求 | 说明 | 取值 |
分布式 | 此应用能够在各组成要素之间传输数据 | 各因子分别取-1、0、1; 最终 取值=1+0.025*各因子之和。 |
性能 | 对用户对应答时间或处理率的需求水平 | |
可靠性 | 发生障碍时引起的影响程度 | |
跨平台 | 开发能够支持不同硬件和软件环境的软件 | |
安全性 | 应用系统所采取的保障系统安全的相关要求 | |
应用云化 | 应用云化部署主要是体现系统部署方式和提供应用服务的状态 |
表 2-6
(3)开发因素调整因子RDF,包括开发语言、团队经验等。在概预算及招投标阶段可不考虑RDF的影响,对于既有软件的扩容改造,可按照表2-7,2-8分别确定开发语言影响因子,团队经验影响因子。
开发语言 | 取值 |
C及其他同级别语言/平台 | 1.5 |
JAVA、C++、C#及其他同级别语言/平台 | 1.0 |
Python及其他同级别语言/平台 | 0.8 |
PowerBuilder、ASP及其他同级别语言/平台 | 0.6 |
表 2-7
团队经验 | 取值 |
为本行业开发过类似项目 | 0.8-0.9 |
为其他行业开发过类似项目或为本行业开发过不同但相关的项目 | 1.0 |
没有同类项目背景 | 1.1-1.2 |
表 2-8
2.3.4成本估算
基于行业基准数据或企业基准数据,确定人力成本费率F,单位为万元/人月,入表2-9。
序号 | 城市名称 | 基准人月费率(万元) |
1 | 北京 | 3.20 |
2 | 上海 | 3.18 |
3 | 深圳 | 3.11 |
4 | 广州 | 2.69 |
5 | 成都 | 2.35 |
6 | 济南 | 2.18 |
表 2-9
人月费率包含软件的直接人力成本、间接成本及合理利润,但不包括直接非人力成本。根据企业及项目数据,估算直接非人力成本DNC,单位为万元,包括差旅费、会议费、培训费、招待费、餐费等。此项费用不一定会产生,视项目实际情况而论,根据项目不同,合理确定是否包含在间接费中,在预算招标阶段可暂不考虑。
基于上述数据,计算软件开发成本SDC,公式为:
SDC=AE/174*F+DNC (2-5)
3.1 GM6000-DAS系统介绍。
以“XX高铁供电SCADA系统主站设备更新项目
”为例,GM6000-DAS系统是在Wonderware ArchestrA平台软件基础上二次集成开发而成的调度管理自动化系统,以各主、被控站数据为依托,功能涵盖SCADA监控、系统维护、网络管理、数据存储备份、系统安全等,适用于铁路牵引供电系统、铁路10KV电力配电系统的监控,同时还适用于城市轨道交通监控系统等相关自动化监控领域[5]。
GM6000-DAS系统集成了“系统常用功能”“条件程控操作”“站复归”“开关对象人工操作”“遥测对象操作”“实时报警操作”“拓扑分析设置”“故障报告”“倒闸操作”“遥视操作”“国际化报表功能”等多种模块,是功能强大的SCADA调度数据一体化平台。
3.1 SCADA系统主站设备更新项目造价评估。
“XX高铁供电SCADA系统主站设备更新项目”软件改造分成两部分,一是基础平台升级,二是软件功能升级。本论文只分析软件功能升级部分,本次升级有“条件程控”“实时报警优化展示”“全景化信息展示”“自动巡检”“综合告警”“源端维护”“设备及应用状态监测”“报文自动筛选”8部分。在设计及预算审查时期,采用预估功能点法。
(1)核对项目各功能模块建设内容,确定ILF为423个,EIF为187个,EI为196个,EO为78个,EQ=182个,采用式2-2,计算可得US=ILF*10+EIF*7+EI*4+EO*5+EQ*4=7441 FP。
(2)系统已经开发非常成熟,CF取1.1。计算调整后软件估算规模S=US*CF=8185FP。
(3)GM6000-DAS系统属于在既有平台上进行的需求优化,按表2-4取PDR,范围在(1.23-6.96)中位数P50为3.81。系统属于交通领域流程控制系统,软件因素调整因子SWF=1.10*2.0*1.10=2.42。系统开发语言为JAVA,团队经验为为本行业开发过类似项目,所以开发因素调整因子RDF=1.0*0.8=0.8。综上,计算软件开发工作量AE=(PDR*S)*SWF*RD的取值范围在(19491-110289)人时/功能点,取中位数P50计算为60374人时/功能点
(4)GM6000-DAS系统取“成都市人力成本率”,从而得出该项目直接成本预算合理范围在(263-1490)万元,取中位数P50,最合理的预算为815万元。
实际上GM6000-DAS并不是为一个路局单独开发,现在有多个局用的此系列系统,每个局两套系统。假设按40%-60%的更新率去估算,平摊到每个系统的软件升级部分直接成本是42.89-62.69万元。考虑到服务器租用费、测试费、等保测评费、差旅费、会议费、培训费等非人力成本,核对项目投资预算得知软件开发服务费用合计82万元,项目方案整体取费略高。
通过测算可以发现在没有用NESMA功能点法的情况下,是很难对该系统预算升级部分进行合理评估。此外GM6000-DAS系统造价的难点在于合理评估该项目的ILF、EIF、EI、EO、EQ等具体的数量。识别各类功能属于数据功能类组件还是事务功能类组件是合理计算系统直接成本的最重要因素。因此该工作需要对相关系统有深入的了解及调查。
首先,在信息化项目立项审查中引入功能点法,可以更加客观、有说服力地节省预算,提高项目执行单位、设计单位、概预算审查部门的水平。其次,信息化项目的费用细化且透明。采用功能点方法,配套调整因子和相关费用计划详细计列出来,各部门有了共同讨论的基础。最后,产出的费用评估报告为评审审查工作提供了科学依据。在有限的评估时间内,通过费用评估报告,可以辅助进行判断和决策。通过交叉验证,项目方案概算更为合理、有依有据,避免出现大幅费用削减导致项目建设处于两难局面。
在下一步工作中,应组织人力对集团公司委外的信息系统进行全方位的分析及评估,建立铁路软件造价规范,制作涵盖各系统的造价评估参数目录。重点包括各系统软件规模功能类型组件详表,软件复杂度定级;软件因数调整因子参数,包括业务领域、应用类型、质量特性参数;开发因素调整因子参数,包括开发语言因子,团队经验因子参数等。为集团公司软件造价评估工作提供更简便合理的依据。
参考文献:
[1]王钧.SJ/T 11463—2013中华人民共和国电子行业标准[S].中华人民共和国工业和信息化部,2013.
[2]郑人杰.Nesuma功能点分析及应用指南[M].v2.3.中国标准出版社,2018(5):9-11.
[3]2023年中国软件行业基准数据报告SSM-BK202309[EB]中国软件行业协会软件造价分会,2023.
[4]任女尔,郭芳郁,赵锋云,等.功能点法在软件造价评估中的应用[J].电脑与电信,2020(7):59-61.
[5]GM-6000 DAS分布式调度管理自动化系统调度员工作站使用手册[Z].成都交大光芒科技股份有限公司,2020.