基于GJB5000A 的软件估算技术在EICAS 系统中的应用

赵丹，周鹏甲，王建超

（1.陕西千山航空电子有限责任公司，西安710065；2.飞马智科信息技术股份有限公司，马鞍山243000）

0 引言

软件估算技术是构成策划软件项目和控制软件项目进度成本等方面的基石。无论哪类项目在开展项目以前以及进展过程中都要预先估计其软件项目中所产生的各个软件产品的规模、工作量、进度和成本等。但在软件进行开发的过程中，软件项目的开发过程是复杂多变的，正是由于软件开发过程的复杂性，软件估算过程也常常被认为是“黑匣子”过程，拥有非常高的不确定性和繁杂性[1]。军用软件成熟度模型即GJB5000A的宗旨是评价软件项目管理过程并对软件项目管理过程进行指导，实践方法并没有具体的明确指出，仅仅给出了相关的考核标准。因此，简单高效具体的软件估算是软件项目开发和管理过程中非常重要的任务，也极具挑战性，结合本单位的实际情况，发挥本地化特色，找到适合本单位的方法思路，将软件项目估算方法应用到本单位实际项目，能够使本单位软件项目管理水平走向正规化、流程化和高效化，是具有重要及深远指导意义的。

依据算法模型（algorithmic model）使用与否，软件估算方法可以划分为三类：未基于算法模型的软件估算方法、基于算法模型的软件估算方法和组合估算方法[2]。20 世纪60 年代，最先开始研究和探索软件项目估计方法，形成了SDC 线性模型，线性模型发展经历了40 多年[3]。依据艾尔布策功能点方法，全面功能点法相继产生，它是由艾伦·艾布恩等人所给出，其优点是更为细化和可操作性强更强[4]，此后纳入国际标准。经过几十年的时间沉淀，计算机技术发展迅速并得到广泛普及，人们更加关注和重视软件估算方法的研究和应用，软件估算日益重要。

近几年来，虽然专家系统、神经网络、人工智能等新技术在软件项目中得到广泛应用，提高和改善了很多问题的估计精度，但尚存的问题依然很多[5]。针对目前存在的各类问题，本文使用已有的软件估算技术，运用到实际开发的软件项目当中，在实践中证明了通过此具体的本地化软件估算技术使软件项目管理水平得到了提升。

1 GJB5000A基础及软件估算技术理论知识

1.1 GJB5000A 基础

采用能力成熟度模型集成（Capability Maturity Model Integration，CMMI）的思想观念，GJB5000A 军用软件成熟度模型选用了分级表示法，按照提前明确的过程域集对组织的过程改进路径进行定义。其宗旨是指导软件开发组织实施有限的关键过程活动，来对软件过程稳步地改进，持续提升组织的软件过程能力。

在GJB5000A 中，软件研制能力成熟度等级由低到高分别是初始级（ML1）、已管理级（ML2）、已定义级（ML3）、已定量管理级（ML4）和优化级（ML5）。除ML1之外，其它成熟度等级均含有多个过程域（Process Area）。虽然GJB5000A 中，初始级的组织的软件研制过程没有任何要求，但是组织要达到更高的成熟度等级，不仅仅要将本成熟度等级包含的过程域全部实施完成，同时需要实施低于此成熟度等级的所有等级包含的全部过程域。各等级对应过程域及过程域类型见表1。

表1 GJB5000A 等级对应过程域

从表1 可以看出，GJB5000A 已管理级可分为7 个过程域。其中项目策划过程域和测量与分析过程域均有对估算相关的活动。项目策划过程域要求对软件规模、工作量等做估算；测量与分析过程域要求对项目策划过程中所做的估算做监控和测量分析。根据GJB5000A 的要求，对软件估计的要求如下：

（1）软件项目经理组织对WBS 中的主要工作产品和活动进行规模估计。按照《软件项目估计规程》执行，对规模、工作量/成本、进度和关键计算机资源进行估计，形成《软件估计报告》，记录估计的结果及其假设，并对其进行配置管理；

（2）当项目的规模、工作量/成本、资源等发生变更时，应重新估计；

（3）软件项目经理组织《软件估计报告》评审。

1.2 软件估算技术理论知识

在GJB5000A 军用软件成熟度模型的体系架构下，不仅对软件本身的质量非常重视，同时也极其关注软件项目的过程管理质量，而软件项目过程管理非常重要的一个环节就是软件项目估算，它是软件项目管理的前提基础。软件项目各类资源被有效利用的程度取决于软件估算的准确程度。在软件项目刚开始启动前，就必须开展软件估算任务，从而对软件项目的进度、各类资源和成本等方面进行控制，为软件项目在后续各阶段中实施各个过程域提供必要的数据支撑。

1.2.1 规模估算方法

（1）Delphi 法

Delphi 法又称专家调查法。顾名思义，专家调查法是依赖于专家的技术经验和知识储备，把专家看作信息获取的主要对象，在缺乏估算的数据和信息资料的情况下，通过专家进行技术预测，对问题进行判断、评价估计并进行预测，是一种比较直观的预测方法。Delphi 法的主要工作程序如图1 所示。

图1 Delphi法主要工作程序

依据上图Delphi 法工作程序，应注意以下事项：

①轮番征询意见：提出的问题数量要求可控，不宜过多，问题要具体明确；

②选择调查对象：调查对象人数一般控制在10～50 人以内，要求是具有广泛代表性的专家，对相应业务精通熟悉，同时具有较强的判断和洞察能力；

③轮番征询意见后，一般需要使用中位数法统计处理意见，调查结论通常为处于中位数的专家意见。

知悉了Delphi 法的工作流程，可以总结出Delphi法的特点见图2。

图2 Delphi法的主要特点

从图2 中Delphi 法的特点，可以看出Delphi 法的科学性和用途的广泛性，但是在函询过程中，需要通过书信来实现调查对象的联系，无法实现面对面研讨，非常浪费时间，各个专家极难不用过多的解释就提出的明确具体的问题，通过中位数法获得的最终意见在一定程度上会具有人为强制性，配合使用其他的方法，可以取得较好的估算效果。

（2）类比法

类比法适用于历史软件项目的数据具有较强的可信性、准确性和完整性，组织已建立起完善的软件项目评价和分析机制，同时正在实施的软件项目与历史软件项目复杂程度、应用环境领域等方面相类似的情况，利用历史软件项目的数据对比估算正在实施的软件项目信息。

其基本估算步骤如下：

①将新项目的各个功能模块以及其代码行数整理列出；

②对新项目的各个功能模块与历史项目的功能模块进行对比，列出相同点和不同点，同时重点标识出历史项目的不足之处；

③通过对比新项目和历史项目，完成步骤①和②后，可以得出新项目的每个功能模块的估计值，需要注意的是，在使用类比法估算软件项目时，通常还需考虑对可重用代码的估算问题进行解决。

（3）PERT 法

PERT（计划评估的评审技术），也被称为PERT 方法，用来协调多个承包商和科研院所。在软件项目整个生命周期实施完成的时间随机以及假设软件项目持续时间随机的情况下，并且理论上服从某种概率分布，使用PERT 法可以将某时间范围内的软件项目完成概率估算出来。

定义1：在软件项目实施过程极其顺利，所有任务工作都能顺利完成的情况下，所使用的时间称作乐观时间；在软件项目正常实施情况下，某一项工作任务完成所需要的时间称作最可能时间；在软件项目实施的最不利的情况下，需要一个特定的任务完成时间被称为悲观的时候。

假设以上定义的三个时间估计均服从β分布，可以计算出各个阶段的期望时间Ti：

其中，xi表示第i项工作的乐观时间，mi表示第i项工作的最可能时间，yi表示第i项工作的悲观时间。

第i项工作的持续时间方差为：

例如，某项目研制划分需求分析阶段、设计与实现阶段、测试阶段、验收与交付阶段四个阶段，各阶段按瀑布模型依次开展，没有时间上的重叠，各阶段完成时间估计：需求分析阶段为6-12-15；设计与实现阶段为14-21-36；测试阶段为5-8-10；验收与交付阶段为6-14-13。

则各阶段的期望工期和方差为：

从PERT 法可以看出，任何一个软件项目都具有不可压缩的最小周期，在项目开展实施过程中，我们要遵循客观规律不能盲目向用户承诺。

1.2.2 平均生产率估算方法

通常，估计技术可以划分为两种类型：代码行（LOC）估算法和功能点（FP）估算法，二种估计方法具有相似性和差异。首先，软件项目策划人员需要根据用户需求叙述软件项目，得到一个有界的软件范围，并由此试图将软件项目划分为可以独立估算的子功能模块；其次，分别对各个子功能模块进行代码行估算或者功能点估算；然后，测量生产力成本，规模或工作的量通过基线变量的具体估计来导出子功能模块；最后，将子功能模块的估算进行整理综合取得整个软件项目的总估算。

代码行（LOC）估算法和功能点（FP）估算法针对分解软件项目子功能模块所需的颗粒度有所不同。当采用代码行（LOC）估算法时，必须对各个功能进行很详细的分解，达到一定的细致程度，而采用功能点（FP）估算法时，各个功能分解程度可以不必很详细，因为估算功能点所需要的数据估算变量是较为宏观的。代码行（LOC）估算法是对每行代码进行直接估算，与其不同的是，功能点（FP）估算法需要估计输入、输出、数据文件、外部接口数量以及复杂程度校正值间接确定。项目策划人员还必须对被分解的各个功能给出有代表性的估算值范围。软件项目策划人员依据历史数据或者凭借项目实施过程中的实践经验，按照定义1 规定的乐三种情况分别对各个功能模块给出代码行或功能点估计值。

1.2.3 工作量估算方法

软件项目中工作量的估算，是指开发软件需要的人力资源的估计。工作量估算和软件项目进度估算共同影响决定软件项目开发团队的构建及规模。工作量的单位一般为人日、人月、人年，不同单位间通过转换系数进行转换。

通常，主要的软件工作量估算方法包括：

（1）COCOMO 模型估算方法

COCOMO 模型估计法又称构造性成本模型，实质是基于模型的一种参数化的项目估算方法，其特点是估算的软件工作量可以通过定义乘法因子准确合理地估算出来，估算精确、易于使用。

根据复杂程度和应用领域的差异性，COCOMO 可划分为三个类型和三种软件应用开发模式，具体见表2。

表2 COCOMO 模型估算方法种类及应用开发模式

COCOMO 工作量估计方法的乘法因子被称为调整因子（Effort Adjustment Factor，EAF），体现出来多个参数的组合效果，这些参数可以分为五个等级：很低、低、正常、高和很高，数值在0.5 到1.5 之间，其乘积构成COCOMO 模型成本方程的系数，这些参数使得项目特征化和规格化。

基本模型是将已经估算出来的代码行数（LOC）作为自变量，构建一个静态单变量模型的函数，最后计算出软件项目软件产品开发的工作量。中间模型是基于基本模型的基础上，需要与硬件、进度、人员各方面的参与，以进一步调整估计的工作负荷影响因素。详细模型在中间模型的基础上，同时还需考虑对软件项目开发过程中策划、分析、设计、测试等各步骤的影响。

组织模式相对来说项目规模较小，无需过多创新之处，开发环境比较熟悉并且具有一定的稳定性。嵌入式应用开发模式中软件项目创新性很强，对整个应用层开发要求很高，接口要求受到一定限制，例如新游戏软件的开发。中间应用开发模式是在上述两种模式之间的模式。

（2）Putnam 模型估算方法

Putnam 模型估算方法是由Putnam 提出的一种动态多变量模型。此模型估算工作量时，整个生命周期的工作量假定符合特定的分布。通常在大型项目(总工作量≥30 人年)应用。Putnam 模型估算方法公式如下：

其中，L 表示源代码行数（LOC）；K 表示全生命周期开发过程所需工作量（以人年计）；td 代表开发所持续的时间（单位：年）；Ck 是一个常数，代表一种技术状态，反映出了“妨碍开发进展的制约”，取值因软件开发过程的情况不同而有所差异，Ck 具有代表性的参数值如表3 所示。

表3 Ck 的典型值

2 EICAS系统介绍

2.1 系统功能及用途

EICAS 系统（全称：发动机指示和空勤告警系统）的机载部分包括显示处理机、液晶显示器、发动机指示控制器、激励源转换盒。

显示处理机采集来自飞机四台发动机、环控系统、操纵系统、燃油系统、液压系统和电气系统的参数及其告警信号，通过对采集的参数进行综合处理后传至系统的显示器进行显示并输出参数，参数以刻度盘、柱状条、数字或文字的形式显示出来，并通过不同的色彩编码对各参数不同的状态进行区分，为飞行员提供EICAS 系统交联系统的工作状态及告警指示，以便采取措施。

在EICAS 系统工作过程中飞行员可以通过操作发动机指示控制器进行画面切换、显示亮度调节、两台显示器和两台显示处理机切换等操作。

2.2 软件用途

EICAS 系统软件由三个软件配置项构成。XC-18N显示处理机软件驻留在XC-18N 显示处理机中，D/XYJ-73N 液晶显示器软件驻留在D/XYJ-73N 液晶显示器中，SK-18J 发动机指示控制器软件驻留在SK-18J发动机指示控制器中。软件用途如下：

（1）XC-18N 显示处理机软件能够实现各交联系统的信号采集，并将数据进行组织，再通过HDLC 总线送给液晶显示器进行显示；完成系统的自检、通信和对前端采集模块进行重配置等任务；

（2）D/XYJ-73N 液晶显示器软件主要完成通过HDLC 总线从显示处理机获取图形指令，并将图形指令生成显示画面，还具有自检、维护等功能；

（3）SK-18J 发动机指示控制器软件主要完成对操作面板按键的扫描，并通过HB6096 总线将结果发送给显示处理机。

系统软件结构图如图3 所示。

3 软件估算方法在EICAS系统中的实践

3.1 EICAS 系统软件的规模估算

本章仅针对显示处理机中显示控制模块进行估算技术方法实践讨论。显示处理机中显示控制模块主要的软件模块包括初始化模块、数据接收模块、响应主控信息模块、显示画面数据处理模块以及发送和接收EPD 数据模块。

软件规模估算分代码估算和文档估算。由于在项目实践中EICAS 系统沿用以往项目软件，所以在这里采用专家调查法结合类比法进行规模估算。具体步骤如下：

（1）确定工作产品。软件项目经理按照各阶段、里程碑所需形成的主要工作产品，明确应实施规模估算的工作产品；

（2）成立软件估计组。邀请3 名及以上经验丰富的专家组成软件估计组；

（3）用宽带Delphi 估计方法对工作产品规模估算。

图3 EICAS系统软件结构图

①代码估算

在以前相类似项目基础上进行估算，历史项目代码规模具体情况如表4 所示。

表4 显示控制模块代码历史数据

估算专家根据上述项目的历史数据和自身的经验，对本项目各软件类比系数进行估算如表5 所示。

如表5 所示，3 位专家根据沿用项目和本项目的特点，独自估算出模块的相似系数。然后根据每个模块所有专家估算的结果做比较，如果估算的最大值和最小值之差与均值的比值（差异率）不超过20%，则认为专家对该模块的估值是可接受的，估算的终值为各估算专家对该模块估算的均值。从表5 可以看出，每个模块的估算偏差值均在20%以内，所以，估值结果是有效的。

表5 显示控制模块类比系数估计结果

根据专家的估算情况，整理出的结果如表6 所示。

表6 EICAS 系统显示控制模块软件规模估计表

②文档估算

估算专家根据沿用项目历史数据和自身的经验，对本项目文档页数的估算如表7 所示。

如表7 所示，3 位专家根据以往类似项目和本项目的特点，独自估算出每个文档的页数。同理可看出，对每个文档的估值差异率均不超过20%，估值都是可以接受的。根据专家的估算情况，整理出的估算结果如表8 所示。

表7 显示控制模块规模历史数据

表8 显示控制模块规模历史数据

3.2 EICAS 系统软件的平均生产率估算

平均生产率是指组织平均每人天的工作效率，可以以每人每天生产的代码行和每人每天生产的文档页数表示。

在本项目实践中，依据前文叙述的平均生产率估算方法进行本项目的估算，利用已经积累的历史经验数据、公开的数据及经验最终得到平均生产率如表9所示。

表9 EICAS 系统平均生产率估算值

3.3 EICAS 系统软件的工作量估算

软件项目经理估计工作时按照估计工作量和成本表中所列出的要求，得出各阶段技术工作量、各类型管理工作量、技术总工作量、管理总工作量、软件项目总工作量的估计值（人日），具体方法如下：

（1）技术总工作量=源代码估计总行数×难度系数/人均生产率；

（2）按照各阶段技术工作量占比，得出各阶段技术工作量=技术总工作量×各阶段技术工作量占比；

（3）按照各阶段管理工作量占比，得出各阶段管理工作量=技术总工作量×各阶段管理工作量占比；

（4）全生命周期的管理总工作量是各个阶段的管理工作量的总和；

（5）软件项目总工作量=技术总工作量+管理总工作量。

技术工作量和管理工作量估计表如表10-11所示。

通过上表技术工作量和管理工作量可以得到项目总工作量如表12 所示。

4 结语

在软件项目实施管理整个过程中，获得有用的软件估算极其具有挑战性，也是极为紧要的任务之一。本文针对试点项目EICAS 系统探讨使用了软件估算技术，提高了策划准确度，提供了较高的估算值，能更好地安排项目任务，降低了成本，对任务按时完成和里程碑的维护提供了可信的数据依据，对历史项目数据的挖掘和应用，使得以后项目的开发不会仅仅只凭经验，本次估算方法的应用将是其他项目在软件策划方面的参考，对于所在单位推广软件工程化管理定量分析方面起到了促进作用。

表10 EICAS 系统技术工作量估计表

表11 EICAS 系统管理 工作量估计表

表12 EICAS 系统项目工作量估计表