军用型号项目软件复用成本度量模型

张圆圆，刘 琪，王 颖

1.中国电子科技集团公司 电子科学研究院，北京 100041

2.北京海淀区复兴路14号 80分队，北京 100897

1 引言

近年来，我军武器装备更新步伐不断加快，对军工装备研制需求不断增长。军工科研项目是普遍按照产品型号及系列进行研发的大型复杂系统工程[1]，具有安全可靠性高、投资规模巨大、建设周期长等特点[2]。软件研发是军工项目研制的一部分，随着计算机技术越来越广泛地应用于武器装备，军用软件在规模和功能重要性上均呈急剧上升趋势，软件研发已成为军工型号项目研制的关键[3]。“软件活动是可控、可度量和可改进的过程”（Watts Humphrey），为了提高软件质量、控制进度，军用软件开发组织必须在项目过程中持续度量，持续跟踪，持续改进，不断提高软件项目管理水平。

目前，各武器装备型号都积累了一大批成熟的软件产品，型号项目的系列化研制方式，使得软件产品的重用也越来越普遍[4]，对存在复用的型号项目软件进行有效、准确的软件规模/成本估计（Software Measurement），是软件研制过程中进行任务、资源分配，以及进度安排等项目策划（Project Plan）活动的重要前提和基础。软件复用开发与传统的软件开发方式不同，导致了新的软件复用度量方法及度量模型的需求[5]，本文根据军用型号项目软件研制特点，分析了软件开发过程中的复用行为对成本度量结果的影响，并结合项目实施的实际过程及经验数据，对 COCOMO2.0（Constructive Cost Model，建设成本分析模型）进行了改进，形成了适用于军用型号项目的改进型软件复用进度/成本估计模型。

2 军用型号项目软件复用成本度量

2.1 软件可复用性及复用成本度量

随着现代软件工程技术越来越向集成化、构件化方向发展，相应地，能够在不同层次、不同程度上，以不同方式重复使用软件各个要素及成分的软件复用技术也得到了越来越普遍的运用。可复用软（构）件具有测试充分、接口清晰、可移植性好、质量稳定等特点，合理的复用能够有效缩短软件开发周期、减少软件代码错误率，从而有效地减少项目开发的成本[6]。

根据复用粒度大小和抽象层次的不同[7]，可将软件复用分为小粒度复用、中粒度复用及大粒度复用三类；软件复用活动可分为生产活动和消费活动[8-9]，生产活动是可复用（软）构件的研发过程（Development for Reuse），如 COTS（Commercial Off-The-Shelf components，成品软件）的研发；消费活动是基于可复用软件（构件）来构造、集成和组装应用系统的过程（Development with Reuse），即对可复用对象进行选择、裁剪及使用的消费过程。显然，软件复用生产活动趋向于增加项目成本，消费行为趋向于减少项目成本。

将对构件的可复用性进行的度量称为软件可复用性度量（reusability metrics），描述了软（构）件被专门设计、开发和支持，以便在其他应用程序中加以利用的程度；将开发过程对软构件消费的成本度量称为复用度量（reuse metrics）。

军用型号项目研制周期较长，多按产品型号进行系列化研制[4]，各型产品多积累了丰富的领域知识、架构设计、测试用例、需求设计文档、软件源代码等各粒度、各层次的可复用成分，在军用型号软件项目研制过程中，应在继承、复用型号积累的各类可复用因素的同时，在软件架构、接口设计等各个环节注重产品的可复用性，使软件产品易于被同型号产品所沿用，即型号项目软件研发过程同时包含了复用软件的生产和消费。因此，不同于一般软件项目，军用型号项目软件复用成本度量模型应同时包含对软件可复用性及软件复用的成本度量。

COCOMO模型对软件可复用性的度量通过系统通用特性统计项中的“可重用性”及成本影响力因子“可复用性开发”得到了体现，本文主要对模型中软件复用度量（reuse metrics）方法进行了改进。

2.2 军用型号项目软件复用成本度量模型

根据是否采用算法模型（Algorithmic Model），可以将软件成本度量方法分为基于算法模型的方法、非基于算法模型的方法以及组合方法[10]。其中，基于算法模型的成本估算方法通过线性模型、乘法模型、分析模型等规则、公式的建立，将软件成本估算为一系列主要成本驱动因子变量的函数[11]。COCOMO模型是基于算法模型的成本度量方法的典型代表，该方法选取项目中具有代表性的特征，从产品（Product）、平台（Platform）、人员（Personnel）和项目（Project）等 4个方面使用17个成本影响力乘数EM（Effort-Multiplier）来综合衡量环境、人员等因素对项目开发成本/进度的影响。

每类 EM 乘数都分为“Very Low，Low，Nominal，High，Very High，Extra High”等级别，每个级别对应通常在0.5到1.5之间的具体参数值，而每类乘数的Nominal级别取值一定为1，代表该类乘数对项目成本没有影响，取值小于1，表示项目中该类因素能减少项目成本，反之则会增加项目成本。EM乘数直接与软件规模估计结果相乘，每一项影响力乘数/因子都会对软件规模估计结果的整体进行调整。

成本度量模型需要软件规模度量结果作为输入[11]，根据军用型号项目软件的特点，本文使用IFPUG功能点法进行规模估计、COCOMO 2.0成本度量模型进行成本/进度度量，在此基础上，从以下几个方面对上述模型进行了改进，形成了军用型号项目软件复用成本度量模型：

（1）基于复用度量的功能点规模估计方法

在根据需求进行功能点分析及识别的同时，根据复用粒度不同，对复用单元逐一进行复用度分析，分析精度可精确到类一级，具体阐述及数学模型见3.3节。

（2）复用软件（构件）DI表

在 GSC（General System Characteristic，系统通用特性）列表中增加了复用软（构）件DI项，并定义了量化评价表，以量化评估软件复用对系统整体规模的影响。

（3）复用乘数

在软件成本估计阶段，增加了反映系统复用消费情况的乘数“REME”（Reuse Metric，复用度量）。REME量化评估表见4.2节表4。

3 功能点法软件规模估计

功能点规模估计法（Function Point Analysis，FPA）是基于软件的功能性需求，通过统计各类需求功能点的数量及复杂度，以得到软件规模估计值的方法[12-13]。功能点估计法是目前普遍使用的主流软件规模估计方法，能够在项目早期根据用户需求对软件功能数量进行测量，而无需借助于软件设计细节及具体编码。现以功能点估计法中的IFPUG法为例，介绍功能点估计的基本工作过程。

3.1 未调整功能点数计算

IFPUG法将应用系统功能性需求分为两类：数据功能性需求和事务功能性需求。数据功能性需求满足用户的内、外部数据需求，分为内部逻辑文件（Internal Logical Files，ILF）及外部接口文件（External Interface Files，EIF），其中，ILF是指一组存在内在逻辑关联、由本应用内部产生及维护的数据/控制信息，EIF是在本应用中被引用的在应用边界之外产生及维护的数据/控制信息；事物（交易）功能性需求是用户提出的用来对数据进行处理的需求，包括外部输入（External Inputs，EI）、外部输出（External Outputs，EO）以及外部查询（External Inquiries，EQ），其中，EI接收来自应用边界之外的数据/控制信息，用以维护内部逻辑文件或改变系统行为，EO向应用系统之外发送经处理的数据/控制信息，而EQ则向用户展示经提取处理的数据/控制信息，不会引起对ILF的维护或系统行为的改变。

通过识别及归类，得到用户需求中以上五类功能点的数量及类别。对于每个功能点，需要根据其处理的事务或数据的复杂程度来确定该功能点的复杂度权值，复杂度越高，赋予功能点的权值也就越高，意味着实现该功能点所需要的工作量也越大。功能点复杂度权值计算方法如表1所示。

表1 各类功能点不同复杂度的权值

表1中，功能点复杂度分为简单，一般，复杂等类别，主要根据功能点的复杂度加权因子来计算并确定，如：表2为使用RET及DET来确定EIF类功能点的复杂度分类阈值的示例。

表2 外部接口文件类功能点复杂度

表2中，记录元素类型（RET）代表用户可以识别的数据元素子集，相当于数据库中的表；数据元素类型（DET）代表用户可以识别的，唯一、不重复的字段，即数据表中字段。

逐一确定每个功能点的复杂度，统计每类功能点中各复杂度功能点数量Nij，并与表1中相对应的复杂度权值Vij相乘，得到系统未调整功能点数UFP，如式（1）所示：

3.2 评估通用系统特性（GSC）

UFP能够从数据/事务复杂度的角度出发来衡量系统规模，但一些诸如复杂安全控制，大量逻辑处理、复杂数学计算、复杂输入/输出、软件复用度等系统级影响因素，都会在整体上客观影响项目开发周期及项目成本估计结果。为此，需要统计各GSC项对系统规模的影响，并使用一个从1（不重要）到5（绝对重要）的评分标准来量化评估通用系统特性对系统规模的影响程度。将各个GSC项取值相加，得到系统TDI（Total Degree of Influence），如式（2）所示。其中，i代表第i项GSC对系统的影响程度。

GSC项的选择、取值、对项目的影响程度及所占比重均可以根据当前软件行业的技术发展情况及所处行业的特点进行裁剪及定制[13]，使其成为软件开发组织的过程资产。对于军用型号项目软件，由于相同型号所使用的硬件平台及软件开发环境相对固定，且基于保密等原因一般不以网上下载升级包的形式进行软件在线升级，因此删除了“在线升级”GSC评估项，并根据型号项目开发过程中普遍存在的对同系列以往型号项目多个层次、各种粒度的复用、继承的特点，对复用粒度大小，复用度百分比等复用因素进行量化、分级，开发了复用软（构）件DI表，如表3所示。

表3 复用软（构）件DI表

将式（2）中得到的通用评估特性TDI带入公式（3）进行计算，得到系统调整（修正）因子VAF：

式（3）决定了系统影响度系数TDI在修正因子VAF中所占比重，即决定了项目的系统特性对软件成本及进度的影响程度。由公式可推导出，由于TDI的取值范围是[0，70]，乘以权值后的取值范围是 [0，0.7]，因此VAF的取值范围为[0.65，1.35]。也就是说，GSC项对项目的整体调整范围是±35%。

最后，将通过式（3）得到的VAF与通过式（1）得到的UFP相乘，即得到了最终的软件功能点度量值FPC，如式（4）所示：

3.3 基于复用度量的多粒度功能点估计模型

在COCOMO成本度量模型中，使用功能点法进行规模度量时，如果分析人员通过分析，估计有百分之r的构件可重用，则可以使用下式对软件复用规模进行估计[11]：

上式对软件的整体重用比例进行了估计，具有一定的主观性，缺乏估计的客观依据，往往不够精确，从而影响了估计的准确性。军用软件开发过程中可能出现各种粒度的复用，以面向对象软件为例，存在对象/类、模块/操作集合、系统等不同粒度软件单元的复用[14]。在使用功能点法进行规模估算的过程中，用户需求被细分并识别为各类功能点，而功能点由具体的函数/类等小粒度软件单元来实现，这样，通过对功能点的识别及复用度估计，可实现对函数等小粒度软件单元的复用度量[15]。进一步，可以按照粒度从小到大的顺序，自底层到顶层逐步计算系统功能点数，并估计各粒度复用对象的复用度，直至整个系统。根据复用对象的不同，可使用以下三个准则进行分析及估算：

（1）对函数/方法（Function）、类（Class）等小粒度复用，在进行类的规模度量的同时，估计其在新系统中的复用度RPC；

其中，UFPi表示对某个复用类i的功能点度量，RPCi表示该类的复用度估计值。

（2）对模块（Module）为粒度的复用，估计模块整体复用度RPM，同时估计该复用模块的TDI；

其中，UFPj表示对某个复用模块j的功能点数度量结果，RPMj表示对该模块的整体复用度估计值，TDIj表示对该模块的GSC统计结果。

（3）对分系统（System）级大粒度复用，则需在估计分系统复用度RPS、计算分系统TDI的同时，以该复用分系统为单位统计其成本规模因子EM。

分系统级复用度量=EMk×TDIk×(1-RPSk)×UFPk其中，UFPk表示对某个分系统级复用模块k的功能点数度量结果，RPSk表示对分系统的整体复用度估计值，TDIk表示对该分系统的GSC统计结果，EMk表示对分系统的成本估计乘数。

使用准则（1），（2），（3），在软件功能点度量过程中对各个粒度的软件复用对象进行复用规模估算，即得到了最终的软件复用后规模度量结果。

4 COCOMO2.0软件成本估计

通过第3章得到以功能点为单位的软件复用规模度量值FPC，进一步，需要对系统的成本因子进行度量，以得到最终的工作量/成本及进度估计。

4.1 软件规模效应

其中，A为常量，当软件规模以功能点为单位时，A的取值为0.033，指数E由下式得出：

式（6）中，B为线性缩放比例常量，取值为0.91；W代表开发团队的5项规模效应比例因子（Scaling Factor），用以衡量软件开发组织对大规模软件的研发能力，分别为：PREC（先例性，有开发类似产品的经验），FLEX（开发灵活性），RESL（能够处理和化解项目风险的能力），TEAM（团队凝聚力），PMAT（组织过程成熟度）。

通过式（5）、（6）可知，当指数E＞1时，软件组织的收益率会随着开发规模的增大而下降，即具有规模不经济性，反之则具有规模经济性。

经过计算，即得到估计了规模不经济性后的标称（nominal）工作量PMNM。

4.2 系统复用度量乘数REME

实际估计过程中，根据经验，去掉了与软件复用情况密切相关的RELY及DOCU乘数，增加了反映系统复用情况的乘数“REME”（Reuse Metric，复用度量），并定义了其量化评估取值表，如表4所示。

表4 REME量化评估表

将上一节得到的标称工作量PMNS与各项成本驱动因子量化评估结果相乘，得到校正后（adjust）的最终工作量估计PMAD（人×月）：

进一步，使用下式得到软件开发周期的估计值TDEV（月）：

5 软件系统开发成本估计实例

本章使用改进的系统复用成本度量模型对某军用大型软件地面规划分系统进行基于各粒度复用的成本度量。该分系统具有A、B、C、D、E五个模块，分系统继承、复用了该型号软件产品的领域知识、算法，软件架构等。其中，模块B是对以往型号的整体改造和移植，重用度达到90%；模块C、D集成了一个COTS软件系统，并使用COTS提供的二次开发接口进行了显示功能及连接代码的开发，新开发部分的重用度为60%；模块A、E为新研，但重用了部分以往型号的软件源代码、库函数。

5.1 功能点法软件规模估计

功能点估计及计算结果如下：

为解决上述技术难点，分别建立永磁直驱柔性构架有限元瞬态响应分析模型及整车动力学模型，并提出架悬直驱结构与驱动轴间动态间隙的干涉评判指标，以此作为间隙大小设定的依据。

（1）对模块A、B、C、D、E分别根据各模块的整体特性进行TDI统计，将结果带入式（3），得到模块调整（修正）因子VAF，具体统计结果如表5所示。

（2）对5个模块（A，B，C，D，E）进行功能点规模估计，得到各模块的功能点估计结果（269，930，233，90，299）。

（3）对5个模块分别按各复用对象的复用粒度进行复用规模分析。

模块A中，部分重用了（30%）该型产品上一版软件的一个功能需求，共计由2个ILF（简单，复杂度权值7），1个EI（简单，复杂度权值3），2个EQ（简单，复杂度权值3）实现该功能需求[15]，代入式（1）进行计算可得该重用需求功能点的UFP计算结果为23，运用3.3节准则（1）进行计算后可得该需求功能的复用规模度量结果为17；模块B为配置项级重用，重用后工作量为原来的10%；模块C、D在COTS提供的接口基础上进行功能开发，重用后工作量为原来的40%；模块E中，部分重用了（80%）一个需求功能点，共计由2个ILF（简单，复杂度权值7），2个EI（简单，复杂度权值3），3个EO（简单，复杂度权值4），3个EQ（简单，复杂度权值3）实现该功能，代入式（1）进行计算可得该重用需求功能点的UFP计算结果为41，同样，运用3.3节准则（1）进行计算后可得该需求功能的复用规模度量结果为8；重用部分的UFP为原来的20%。复用度量后各模块规模估计结果为（263，93，93，36，266）。

表5 改进GSC项列表及各模块TDI

（4）将得到的模块VAF向量与各模块复用UFP向量进行点乘，得到整个分系统功能点估计结果，如表6所示。

表6 功能点计算结果

5.2 软件成本估计

软件成本/进度估计计算结果如下：

（1）规模经济效益指数E

对5项规模效应比例因子所涉及的5个方面进行衡量，以量化评估开发组织的研发能力随着软件规模的增大而变化的趋势，经过对组织的五项比例因子进行考察，最终规模经济性比例因子取值见表7中黑体所示，将规模因子带入公式（6）进行计算，得到规模指数E。

表7 规模经济比例因子取值表

（2）经过对分系统的整体复用程度进行衡量及评估，该系统的复用度量乘数REME取值定为0.95（high）。

（3）逐一确定各成本影响力乘数的取值，具体取值结果见表8所示。

5.3 估计结果比对

为了检验改进的软件复用度量模型的有效性，将改进的度量模型与标准的COCOMO2.0软件估计方法的各步骤中间计算结果进行了比较，并将使用两种方法得到的工作量、工期、成本以及平均生产率等最终规模度量结果与该项目实际数据进行了对比。计算过程中，取待估计分系统的整体TDI为31，分系统整体复用度估计值r为0.6。两种方法计算结果对比值如表9所示。

5.4 结果验证

本单位通过积累前期历次执行型号项目软件研发工作的经验数据，得到本组织的型号产品软件开发项目平均生产率P为8 h/功能点，以每周5个工作日，每天工作8 h来计算，则P为20功能点/人月；在工期估计方面，该分系统开发项目于2013年3月11日开始进入需求分析阶段，至2013年12月22日完成验收交付，历时41周。可见，使用改进的成本估计方法的确提高了软件估计的精度。

表8 成本影响力乘数EM取值对比表

表9 成本估计计算结果对比表

6 结束语

准确的软件成本度量是项目顺利进行的基础。军用型号项目软件复用度量模型使用功能点法详细评估每个复用单元的复用后实际工作量，并对COCOMO2.0软件成本分析模型进行了改进，增加了软件复用量化评估成本驱动因子及系统通用特性统计项，从系统级对度量结果进行了修正。与传统度量模型相比，复用度量模型具有更高的准确性，适应了军用型号软件项目的开发特点，为项目的进度安排及成本控制等方面提供了很好的参考。

[1]张杰，闫振国，李原.航空型号生产项目集成进度控制方法[J].计算机工程与应用，2008，44（26）：230-232.

[2]郭薇，李想，曾斌.面向军用软件的COCOMOII改进模型研究[J].船舶电子工程，2014，34（1）.

[3]Lee T，Gu T，Baik J.MND-SCEMP：an empirical study of a software cost estimation modeling process in the defense domain[J].Empirical Software Engineering，2014，19（1）：213-240.

[4]吴清才，郑琪，王首一.军用软件的工程研制与[M].北京：国防工业出版社，2013.

[5]李英梅.基于构件的软件复用度量的研究[D].哈尔滨：哈尔滨工程大学，2007.

[6]Graham I.Object-orientedmethods[M].Wokingham，UK：Addison-Wesley，1991.

[7]Agresti W W.Software reuse：developers’experiences and perceptions[J].Journal of Software Engineering and Applications，2011，4（1）：48-58.

[8]Karlsson E A.Software reuse：a holistic approach[M].Chichester：John Wiley and Sons Ltd.，1995.

[9]Vasantha R，Sudhakaran J K.A mixed method approach for efficient component retrieval from a component repository[J].Journalof Software Engineering and Applications，2011，4（7）.

[10]李明树，何梅，杨达，等.软件成本估算方法及应用[J].软件学报，2007，18（4）：775-795.

[11]Boehm B W，Abts C，Brown A W，et al.Software cost estimationwithCOCOMO II[M].New York：Prentice Hall，2000.

[12]IFPUG（International Function Point Users Group）.Function point counting practices manual-release4.2[R].2004.

[13]Chrobot B C.The economic importance of business softwaresystemsfunctionalsizemeasurement[J].Software Engineering，2011，1（1）.

[14]毛明志，陈立.多粒度的面向对象软件估算模型的研究及应用[J].计算机科学，2009（2）.

[15]文静，顾勋梅.一种度量软件需求的功能点方法[J].微电子学与计算机，2011（10）.