一种基于GJB5000A二级软件生命周期模型的本地化实施

孙秀芳 姜 凯

1(武汉软件工程职业学院计算机学院 湖北 武汉 430205) 2(武汉中原电子集团有限公司研发中心 湖北 武汉 430205)

0 引 言

经过长时间的发展,我国武器装备从单纯依靠硬件发挥战斗力逐渐演变为软硬件结合共同决定着武器装备的综合性能,特别是随着嵌入式软件在武器装备中广泛而深入的应用,软件也越来越起着神经中枢的作用。在这种环境下,软件运行一旦失效,就可能导致整个武器装备失灵,造成严重后果。

我国为规范从事军用软件研制开发单位的软件研制开发流程,原总装备部电子信息基础部于2008年3月推出了GJB5000A-2008《军用软件研制能力成熟度模型》,在该标准中给出了军用软件研制能力成熟度五级模型和相应软件过程要求[1]。2013年,原总装备部又发布了GJB8000-2013《军用软件研制能力等级要求》,其中规定承担军用软件研制任务的单位应达到相应军用软件研制能力的等级要求[2]。截至2018年9月通过GJB5000A二级认证的军用软件研制单位135家,通过GJB5000A三级认证的军用软件研制单位67家[3],目前越来越多的单位在软件开发管理活动中更加重视贯彻实施GJB5000A标准工作。

其中,GJB5000A二级为已管理级,其本地化实施后能确保其过程按照既定程序文件进行策划并得到执行,其开发过程遵循选定的软件生命周期模型,从而最大限度保证软件开发过程和软件开发质量。

随着军改的深入开展,市场化的竞标项目越来越多,这些竞标项目多为软硬件相结合、需求稳定、软件研制周期短、功能实现程度高的新研产品。在此背景下,按照本单位软件工程化体系中关于生命周期模型选型规定,由于增量模型和原型模型不满足选型要求(它们适合需求不太明确的项目),一般会选择典型的瀑布模型进行软件工程化管理和实施。但是这些新研竞标项目的研制周期比较短、研制任务重,软件开发过程中质量的控制就会面临着时间和人力成本的双重压力,这样依照典型的瀑布模型控制新研竞标项目就会显得力不从心。本文就针对选择什么样的生命周期模型才能更加适合新研竞标型项目的软件工程化实施这个问题进行探讨,并将工作开展中的工程实践和体会总结出来,提出一种新的较适合新研竞标项目的软件生命周期模型并进行了本地化实施,以满足新研竞标项目开发过程的这种实践,希望能够引起更多软件工程化管理人员,就新研竞标型项目如何更好地进行过程控制展开广泛深入的讨论。

1 GJB5000A二级软件生命周期模型的适应性

GJB5000A标准对软件研制能力成熟度等级进行合理划分[4],总共包含成熟度等级5个,过程域22个,专用目标48个、专用实践165个,共用目标2个、共用实践12个。当前,从事相关软件开发的单位大多按照原总装备部规定的承担相关软件研制任务的单位,应达到GJB5000A标准中软件研制能力相应等级的要求进行本地化实施,取得了很好的效果[5-6]。

按照GJB5000A对承担军用软件研制能力成熟度等级要求,从事军用软件开发的单位在从事相关软件项目开发必须达到二级(已管理级)以上的软件研制能力成熟度要求。GJB5000A二级(已管理级)中共包含7个过程域19个目标。其中,项目策划过程域是对软件研制整个过程进行详细策划,从而保证项目有计划的稳步推进,是GJB5000A对软件开发的一个重要要求,也是项目按期开展的重要保障。

选择软件生命周期模型是GJB5000A二级项目策划过程域中第一个专用目标(建立估计值)中第三个专用实践(定义项目生存周期)输出的典型工作产品,是实施GJB5000A二级的必经步骤,其决定着整个软件开发的过程、活动、时间顺序、软件输入输出工作产品以及软件验收交付的标准。可以这么说,软件生命周期模型的定义决定了项目策划的质量,项目策划的好坏直接决定了项目是否能够正常开展及按时交付。

软件生命周期模型都有其适应范围,选择合适的软件生命周期模型是整个项目按期有条理往前推进的保证,是项目策划的关键。典型的软件生命周期模型如瀑布模型、增量模型和原型模型虽然能解决部分软件项目策划中的软件生命周期选型问题[7],也能指导实际项目的开发过程活动,但这些模型大都只能适应部分状态背景下的软件开发管理活动,在当前新研竞标型项目开发管理过程中,时间要求往往比较紧[8],任务量又繁重,人力资源又紧张,在这种情况下按照典型的软件生命周期模型进行项目策划,由于新研竞标项目的需求明确且稳定,根据软件工程化体系文件要求会选择典型的瀑布模型进行软件开发过程和质量的控制,但是典型的瀑布模型阶段划分多、要求顺序执行,不能跳过阶段,每个阶段输出的产品必须完成评审后才能进入下一个阶段,这种瀑布模型的时间跨度大,灵活性不足,就很难保证项目如期保质保量地交付实施,所以找出一种更加适合的软件生命周期模型用于指导新研竞标型项目中软件开发活动就显得十分必要了。

2 典型软件生命周期模型比较分析

软件生命周期模型是描述软件开发过程中各种活动如何执行的模型[9]。它规定了软件开发的全部活动划分成哪些阶段及其主要活动和执行顺序,因此要根据软件项目实际特点选择合适的软件生命周期模型。

本单位在软件工程化管理实施过程中引入了瀑布模型、增量模型和原型模型并进行了本地化实施,形成了软件过程管理体系文件《QLD1224-2020-软件生存周期选型指南-v1.9》。

2.1 瀑布模型使用分析

瀑布模型也称为设计驱动模型,是最古老也是最被广泛熟知的模型,起源于1960年,依照连续的阶段进行软件开发[10]。瀑布模型是全生命周期模型,也是软件工程化项目开展过程中,选用最多的模型。在本单位实施过程中,包括系统需求分析阶段、软件需求分析阶段、软件设计阶段、软件实现和调试阶段、确认测试阶段、验收交付阶段、运行和维护阶段等,各阶段按顺序进行,涵盖了GJB5000A二级中所有过程域。瀑布模型优缺点及适用范围如下。

(1) 瀑布模型优点:① 提供程序化规范化的管理流程指导软件开发;② 使用简单,顺序执行,一个结束再开始一个;③ 过程中发现问题及时,利于项目阶段成本控制;④ 过程控制可见性较强;⑤ 记录软件开发过程较全,便于管理维护。

(2) 瀑布模型缺点:① 直到项目结束,用户才能获得可用的软件产品,过程周期长;② 无法预知变化情况,若发生需求遗漏,返工风险较大;③ 模型灵活性不高,不能跨阶段操作;④ 会议多,文档多;⑤ 不易变更。

(3) 瀑布模型适用范围:① 需求清晰稳定,开发方和用户方易达成共同理解,需求变更较少;② 对质量的要求高于对成本和进度的要求;③ 首次实施软件工程化管理的团队。

2.2 增量模型使用分析

增量模型从需求分析到验收交付整个过程中采用增量开发的形式,第一个增量版本大多完成软件的核心功能,满足最终交付软件产品的基本需求,一般不包含不确定的需求以及非核心的其他需求。在接下来的增量版本中逐渐实现非核心需求和逐步确定的原不确定需求,增量开发过程中识别的新的需求或积累的变更,可以需求变更的形式在第二次增量开发中完成。

(1) 增量模型优点:① 人力资源分配更加合理灵活;② 在需求不稳定的情况下将风险降到最低;③ 能够较好地解决人力、资金和成本等无法一次到位的问题;④ 软件可按版本逐次交付,首先交付核心功能版本满足客户主要功能的先使用。

(2) 增量模型缺点:① 对软件开发管理团队要求较高,风险管理和过程管理方面,最好有软件工程化管理经验的人参与;② 软件架构设计要求较高;③ 集成和测试难度大,概要设计阶段要设计好;④ 需求变更概率大,需求变更控制较难,对配置管理人员要求较高。

(3) 增量模型适用范围。依据本单位试点项目经验,增量模型适用于中大型项目以及一部分预研项目。增量模型适用的软件项目有如下要求:① 用户核心需求清楚,但具体需求不清晰不稳定;② 项目开发人员不足;③ 产品可以分割成不同增量(构件)分别完成;④ 软件开发团队具有相关领域开发经验;⑤ 项目的风险较高;⑥ 用户要积极表达需求,参与项目开发过程;⑦ 团队具备软件工程化管理经验。

2.3 原型模型使用分析

原型模型是一种支持用户想法的开放模型,用户在软件生命周期的设计阶段能起到积极的作用,以最大减少软件开发过程中的风险。原型模型的优缺点及适用范围如下。

(1) 原型模型优点:① 快速挖掘用户需求;② 开发方和用户方更易达成需求的共同理解;③ 降低了开发风险和开发错误发生率;④ 开发周期变短,工程进度更快;⑤ 降低了项目的人力物力成本。

(2) 原型模型缺点:① 软件产品需要二次开发,当输出的原型产品被告知用户不是最终运行的软件产品时,用户不太容易接受,给二次开发带来了风险;② 增加了用户对产品的期待性,用户快速看到原型后,若接下来的开发无法完成,则会给用户造成不好的印象;③ 最终产品不是开发的原型,原型仅是对用户需求的充分挖掘的定义,最终的产品仍要考虑质量和可维护性;④ 增加了最终产品的开发难度,用户看到快速原型产品后,很可能会提出更高一级的需求,这无形增大了最终产品的开发难度。

(3) 原型模型适用范围。本单位实际项目开发中,一些自研项目或用于验证某些技术原理的项目会选用原型模型。原型模型适用的软件项目应满足以下条件:① 用户需求不明确;② 用户对交付的文档质量要求不高;③ 用户要求能快速看到产品的概貌;④ 项目的主要目的用于展示或者验证原理;⑤ 适合中小型项目开发,不太适合大型项目开发。

通过对以上三种典型软件生命周期模型特点、优缺点和使用场景进行分析,基于对需求不同程度的理解,软件项目负责人在选用软件生命周期模型时可从以下几点进行考虑:(1) 软件需求明确且稳定可靠时尽量选用瀑布模型;(2) 软件核心需求比较明确且其他需求可逐步确定时尽量选用增量模型;(3) 软件需求不明确且用户不知道怎么表达需求时可选用原型模型。

3 新研竞标项目软件开发过程特点

近年来,随着军改的推进实施,公司参与相关部门市场化招标竞标的项目越来越多,经各项目组汇总分析,概括本公司参与竞标项目的软件开发大多具有以下特点:

(1) 多为嵌入式软件,参与研发的项目多为陆面通信装备项目,开发的软件也多为运行在装备中的嵌入式软件,软件的研制受到特定的硬件和软件环境约束。

(2) 研发周期短,软件的开发一般会纳入装备研制过程,随装备一起开发测试,与装备一起交付,与硬件开发周期相比,软件开发研制周期更短。

(3) 需求明确且稳定,竞标项目从竞标任务书下达的那一刻起,就确定了该项目的所有功能、性能、对外接口要求等研制内容,且在竞标研制过程中,很少做出大的改变。

(4) 重视功能的实现,较少对文档有较高要求,竞标型项目一般会要求参与竞标的单位完成规定的功能,在功能都能够达标的基础上,会对性能进行测试,而对文档则不会提出过多要求。

针对上述新研竞标项目的四个特点,若选择现有典型的瀑布模型,则必须按照其规定的七个阶段完成相应活动、输入的工作产品、输出的工作产品等要求,严格按顺序进行评审,走完整个全生命周期,这样一来,虽然开发过程得到了保障,但实践表明其研制周期就无法满足要求,往往不能按期提交程序代码,从而造成项目不能按期交标。

若选择现有典型的增量模型,把软件划分为多个构件进行开发,并依次集成和测试发布,至最终形成一个可发布的软件版本,这就要求每次生成的软件必须是一个可以发布并稳定运行的软件版本,对于依赖硬件支撑的嵌入式软件产品很难做到按构件开发集成。实践也表明这种逐步开发的软件研制周期也很长、大部分工作耗费在了重复测试过程中,给竞标型产品的按期交付带来压力。

由于本单位参与新研竞标型的项目大都需求明确且稳定一致,按照软件工程化体系实施要求,则不适合选择原型模型作为控制软件开发过程的生命周期模型,原型模型对于需求不明确的项目具有较好的适应性。

由此可见,针对上述新研竞标项目的特点及现有生命周期模型对其适应性分析后,可知现有模型已不能较好满足其开发过程的管理要求。

4 简明应用开发模型内涵

新研竞标型项目的软件开发活动管理,按照公司软件过程管理体系文件中的《QLD1224-2020-软件生存周期选型指南-v1.9》进行件生命周期模型选型,应选用瀑布模型,然而考虑到瀑布模型中各阶段产品和文档须满足出口准则后才能进行下一阶段的软件开发活动,对竞标型项目软件开发管理来说,这显然不能满足软件研制周期的要求。在此情况下,结合本公司多年的软件工程化实践和工程开发经验,提出了一种以瀑布模型为参考基础的“简明应用开发模型”,以实现软件生命周期模型与实际项目研制流程相符合。简明应用开发模型如图1所示。

图1 简明应用开发模型流程示意图

该模型共包括需求分析阶段、设计与开发阶段以及验收与交付阶段等三个阶段,比瀑布模型的七个阶段减少了四个阶段,研制过程周期大大压缩。同时,该模型中设计与开发阶段(含设计、编码以及测试等)的开始时间、结束时间虽然具有先后顺序,但活动时间可以重叠,可在所有活动完成后再进行阶段评审,大大增加了软件开发活动的灵活性。需求分析阶段也一样,当需求内部评审通过后,就可以开始设计分析活动了,而不用像瀑布模型那样,必须等到需求正式评审通过后,才能进行下一步的设计活动,这样灵活安排活动,减少了时间资源和人力资源的消耗,使整个项目团队的整体工程工作量得以减少,提高了工作效率。该模型输出的工作产品包括程序、文档和数据等都和瀑布模型一样有较高质量要求,一样需要参照《GJB438B-2009军用软件开发文档通用要求》进行编写[11],丝毫没有对文档的质量有降低标准,只是可以不用像瀑布模型那样每个阶段都要输出特定的文档并通过评审后才能进入到下一个阶段。该模型通过本单位多个项目试点运行后表明,能够较好地支持陆面设备竞标项目中软件开发活动的管理。为了更好地将该模型推广至更多项目,特对该模型的优缺点及适用范围进行总结如下。

(1) 简明应用开发模型的优点:① 减少了设计与开发阶段过程中产生的文档,降低了管理人员通过文档完成情况评估项目完成进度的错误看法;② 聚焦软件开发活动于软件代码质量的提升,使更多的工作量集中于软件编码实现与测试;③ 加快了软件的实现,压缩了软件研制过程周期,提高了项目组人员的生产效率;④ 提高了文档的一致性和准确性,验收阶段一起提交按照GJB438B要求拟制的软件文档,同时保证了软件文档的质量;⑤ 减少了项目的阶段评审,与瀑布模型相比去掉或合并了非必要的管理评审和技术评审,节省了软件开发管理时间,降低了软件开发的管理费用。

(2) 简明应用开发模型缺点:① 降低了需求管理的有效性,项目的阶段评审控制和软件文档产品对整个开发过程指导的减少,不易保证阶段之间的正确衔接以及及时发现并纠正开发过程中存在的缺陷,使需求追踪变得不好控制;② 软件开发过程的透明性和可管理性变弱,使得模型的风险控制能力也减弱;③ 模型无法解决需求不明确或不准确的问题。

(3) 简明应用开发模型适用范围:① 软件项目需求明确稳定;② 软件项目研制周期较短(项目周期建议小于12个月);③ 源代码规模不大(源代码行数建议不大于5万行)。

每个软件生命周期模型都有本身的优点,也都存在自身的不足,也都有其适用的范围。虽然不能建立一个完美的软件生命周期模型适合所有的项目,但是建立一些合理可行且适合本地化实践操作的软件生命周期模型还是有必要的。

5 结 语

本文通过对典型软件生命周期模型如瀑布模型、增量模型和原型模型分析讨论,并结合多年来的工程经验和软件工程化实践,提出了一种以瀑布模型为参考基础的简明应用开发模型用于指导本单位某些实际工程项目的实施,本地化实践表明该模型在保证软件开发质量的同时,又提高了软件开发效率(也称工程平均生产率=软件的实际有效代码规模/项目的实际工程工作量,量纲为LOC/人天),希望对已经通过GJB5000A二级已管理级评价的单位或项目团队有所帮助。