一种弹上软件开发生命周期模型

赵淑君

(北京遥感设备研究所，北京 100854)

0 引言

通常策划软件项目开发工作时需要根据项目的特点选择一种适合的软件开发生命周期模型(以下简称软件开发模型)，按照软件开发模型的要求开展软件开发活动。弹上软件的开发过程亦如此。弹上软件作为导弹的大脑和核心，其研发过程的控制对软件质量乃至整个武器系统的质量起到至关重要的作用，因此选择一种合适的软件开发模型十分必要。

1 传统软件开发模型简介

传统的软件开发模型有原型、瀑布型、迭代型/增量型[1]等。

原型一般用于软件项目早期，此时需求不明确，需要快速形成软件产品，但对软件产品可靠性要求不高，通常用于功能演示验证；瀑布模型一般用于需求明确的项目，是一种理想的文档驱动型的开发方式；迭代型/增量型介于二者之间，但是软件需求的变更需要受到严格的控制，每一次迭代都类似一个瀑布过程，整个开发周期比较长，管理活动消耗时间较多。

近年来提出的敏捷开发方法，在许多行业和领域得到了广泛的关注和应用[2-4]，它的本质是一种“关注产品本身胜于过程和文档”的观点，它的4句宣言“个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划”[5]强调开发者之间以及开发者与客户之间面对面地交流，强调以人为核心，强调快速响应，它的开发特点类似于迭代型或者增量型，但是敏捷开发方法更侧重于给出了很多操作层面的方法和步骤，如用户故事、每日站会、冲刺、回顾、燃尽图、结对编程等[6]，但它对文档的要求相对较弱，通常在高层级描述系统结构和行为以及关键的设计原理[7]，编制“刚刚够(just enough)”的文档[8]，该方法在安全关键软件和军用软件开发实践中也获得了一些有益探索[9-10]。

2 弹上软件的特点

弹上软件有其专门的应用场景，既遵循软件的一般研制规律，必须经过系统分析与设计(用户需求开发)、软件需求分析、软件设计和实现、单元测试/单元集成测试、配置项测试、软硬件集成测试、验收交付和运行维护等多个阶段[11]，同时又具有自己的特点，主要表现在3个方面。

(1) 需求不稳定

武器装备有其自身的研制规律，需要创新和突破，研制过程是一个不断探索发现、不断深化认识的过程，因此软件需求必然也是一个循序渐进、不断迭代和完善的过程，很难一次明确到位。在这个过程中由于需求不断变化，软件技术状态始终在一个动态的变化当中，需求变更呈现常态化，特别是整个研制阶段的初期和中期，为了系统功能的改进和性能的优化，软件经常需要不断地修改和完善。频繁的更改不仅影响软件的质量也影响开发的进度。

(2) 对缺陷“零容忍”

弹上设备任务具有一次性的特点，软件质量好坏直接关系到任务的成败，因此对于软件缺陷“零容忍”。因为一个小小的软件疏忽就会导致任务的失败，造成非常严重的损失和后果，这不是通常软件“bug”修复就可以的。通常弹上软件具有很高的安全关键等级，“一次做对”、“零缺陷”是弹上软件质量的最高目标，也是弹上软件过程控制的最高目标。

(3) 研制节点紧迫

弹上软件作为武器系统的一部分，它的研制进程与武器系统的研制进度紧密相关，经常要求研制节点“后墙不倒”。时间紧，任务重，对软件质量是一个极大的挑战。因此，在需求不稳定不明确的情况下如何有效开展软件研制工作，从而既保证软件质量又要满足武器系统的进度要求，就成为一个引人思考的问题。

弹上软件的上述特点表明，其面临一个矛盾，需求很难一次明确，但是又要求产品可靠性高，原型和瀑布型无法满足要求，采用迭代型/增量型又因为频繁的需求变更使得软件过程控制复杂繁琐，无法满足进度要求，敏捷开发中对于文档需求的弱化同样也不能满足弹上软件开发的文档标准[12]要求。

本文针对弹上软件的上述特点，提出了一种基于原型+快速瀑布模型的弹上软件开发模型，解决在需求不稳定的情况下，通常的软件开发模型无法同时满足质量和进度要求的问题，并对该模型的各个阶段主要工作内容和要求进行了阐述。该模型同样适用于具有类似特点的其他软件。

3 弹上软件开发模型组成

3.1 模型组成框图

弹上软件开发模型的组成如图1所示。

说明：一次软件开发过程以完成软件验收交付活动作为结束标志，后续运行维护(包含武器系统联试)过程中，如果需要进行软件修改，执行软件更改升级过程。

基于原型+快速瀑布模型的弹上软件开发模型，包括：原型功能验证、快速需求固化、快速设计优化、快速代码优化、软件内部测试、软硬件集成测试/三方评测和验收交付等阶段。

(1) 原型功能验证：是通过需求分析、设计、实现和测试验证的快速迭代过程形成初步的软件产品，并放到所属系统中完成初步验证，以便引出正式的软件需求，也即开发软件需求的过程。

(2) 快速需求固化：是根据原型功能验证结果，将软件需求进行固化，形成正式软件需求文档的过程。

(3) 快速设计优化：是根据正式的软件需求文档，对软件初步设计方案进行优化，形成正式软件设计方案的过程。

(4) 快速代码优化：是根据正式的设计方案对代码的实现进行优化的过程。

(5) 软件内部测试：是对优化后的代码进行详细的单元测试、单元集成测试和配置项测试的过程。

(6) 软硬件集成测试/三方评测：软硬件集成测试是将软件置于所属系统与硬件及外部设备或其他软件进行集成测试以确定软硬件及本软件与其他软件之间的工作是否相协调一致的过程，同时在此阶段还要视需要开展软件第三方评测工作并最终通过软件第三方评测。

(7) 验收交付：是将通过软硬件集成测试和三方评测的软件完成正式验收交付的过程。

3.2 原型功能验证

原型功能验证阶段通过快速形成软件产品对软件功能进行验证来开发软件需求。

弹上软件作为导弹武器系统的一部分，其功能和性能与硬件及系统耦合非常紧密，软件需求很难在项目初期独立明确出来，即使描述很明确，软件严格按照需求实现了，由于武器系统本身的复杂性，未知不确定因素很多，也容易出现“正确地做了(you built it right)”[13-14]但做的产品不满足武器系统使用要求的情况。

原型功能验证的指导思想就是通过原型开发方法，快速形成一个原型产品，在接近真实的系统中进行验证，通过验证的结果来修正软件需求、设计和实现，直到该原型产品初步满足系统使用要求。这是一个引出需求、开发需求的过程，往往需要任务提出方和任务承制方紧密合作，需要需求分析、设计、实现和功能验证的快速反复迭代。在功能验证过程中原始需求不断被修改和完善，经过多次验证后逐渐趋于收敛，直至软件产品初步满足系统要求。

与通常的增量或迭代模型不同，在该过程中对文档的要求是比较弱的，对中间形成的工作产品的配置管理要求也是比较弱的，对测试验证的全面性和系统性的要求也是比较弱的。在首次迭代时，形成需求、设计和测试验证的初始文档，之后每一次快速迭代过程中，需记录本次迭代过程中需求的变化、软件设计更改情况以及验证用例设计和执行情况。这些文件侧重于对需求、设计和测试验证内容的记述，对标准化和规范化要求较弱，通常和源代码一起在开发库中进行管理，进行非正式的控制。

在此过程中整个项目团队需要经常讨论或进行非正式的评审，讨论的内容包括技术需求、实现方案、如何验证以及验证数据和结果的分析等，一次讨论往往涵盖需求、设计、实现和测试验证整个过程的内容。

总之，本阶段的重点在于快速引出需求，快速进行功能验证，确保提出的软件需求是符合实际的，满足大系统功能要求的，并且与整个系统的功能是协调一致的，是确保软件人员不但“正确地做了(you built it right)”并且还“做了正确的东西(you built the right thing)”[13-14]的重要一环，因为在确保需求正确的基础上谈软件的质量才有意义。

3.3 快速需求固化

当原型软件产品开发完毕，功能得到初步验证后，需求逐步明晰并趋于稳定，自本阶段开始，将进入严格的软件工程化控制流程，包括文档的质量控制、配置管理(包括基线控制、更改控制等)、评审管理等。

快速需求固化阶段将软件需求进行固化，形成正式的软件需求。这一环节非常重要，明确了需求即明确了软件项目的范围和边界，作为后续工作的基础以及验证软件是否满足要求的依据。具体工作分为用户需求固化和软件需求固化2部分。

(1) 用户需求固化

任务提出方根据前期功能验证的结果，以文档的形式快速固化用户需求，编制软件任务书，任务书从用户的角度描述对软件的要求，包括软件的运行场景，详细的功能、性能和外部接口要求，特别是在原型功能验证阶段不作为考虑重点的安全性和可靠性要求要明确提出来，另外管理要求以及一些设计约束包括开发环境要求、交付的形式、里程碑评审节点、进度控制要求等应一并明确出来。任务提出方将自己最关注的内容明确地提出来，有助于任务承制方准确理解用户要求，进而正确实现它。

(2) 软件需求固化

任务承制方根据软件任务书，进行需求分析，结合初级软件产品功能验证结果，从承制方的角度理解每一条用户需求，并向下分解，逐级细化为可实现的软件需求，编制软件需求规格说明文档。

在本阶段，任务提出方和承制方应充分沟通，以便清晰、准确、无二义性地描述出真实的需求，这2份文档分别由任务提出方及承制方编写，同时进行评审，便于评审专家对这2份文档的一致性和协调性进行审查，从而确保任务提出方和承制方对于需求的理解是协调一致的，承制方准备实现的功能正是提出方所需要的，并且以文档的形式固化了下来。通过评审的文档纳入受控库进行管理，如果后续有需求变更需要严格按照更改控制流程进行。

3.4 快速设计优化

快速设计优化阶段依据固化的软件需求对软件设计方案进行优化，形成最优的正式软件设计方案。

在功能验证阶段，需求是比较模糊的，最初的设计方案与当时的认识有关，功能验证过程中渐进地修改代码，使之越来越接近使用要求，但是最初的产品架构和模块划分与固化后的软件需求相比，不一定是最优的了。因此需要对前期的软件架构进行重新审视，视需要进行优化和调整，并对模块划分合理性进行检查，按照内聚性强且耦合性弱的原则，对不符合要求的模块重新进行设计优化，确保软件架构和模块划分对于固化后的需求来讲已经是最优的，形成软件设计说明文档。

软件设计说明文档需进行正式评审，确保设计方案相对于需求的合理性，相对于实现的最优性，即确保设计方案是能实现软件需求的最优方案。该文档通过评审后纳入受控库进行管理，如果后续有设计变更需要严格按照更改控制流程进行。

3.5 快速代码优化

快速代码优化阶段依据评审后的软件设计说明文档对已形成的软件代码进行优化，使之与设计相一致，并使之符合编程规范。

代码优化包括2部分：一是依据设计优化进行架构和模块实现方面的优化，对代码进行修改完善，使之与优化后的设计保持一致；二是编程语言规范上的优化。在功能验证阶段，侧重于快速编写出代码进行功能验证，对代码规范性要求不是关注的重点，本阶段需求和设计已经相对固化，对软件编程的规范性要求就提到了议事日程。代码完成后应采用静态分析工具进行代码规则检查，对发现的编程规则问题及时进行修正。

经过优化的代码还缺乏系统而全面的内部测试，可在开发库进行管理。

3.6 软件内部测试

软件内部测试阶段的任务是对优化后的代码进行系统全面的内部测试，以验证“你正确地做了(you built it right)”。

软件内部测试包括单元测试、单元集成测试和配置项测试3个活动[15]。

在功能验证阶段，为了快速收敛需求，经历的是需求-实现-功能验证的不断迭代过程，主要就是压缩了系统全面的内部测试时间，这是考虑到内部测试是测试软件实现的正确性，在需求还不十分确定的情况下，先把明确的需求固化下来才是最紧迫的事情，过于强调软件实现正确性是意义不大的。

在本阶段，需求已经明确，设计和实现也得到优化，到了验证软件产品本身正确性的时机。系统全面的内部测试是保证软件质量的重要环节，首先应进行全面的测试用例设计，亦可继承之前在功能验证阶段的部分测试用例，对优化后的软件代码在单元级、单元和单元之间以及配置项级进行测试，针对发现的问题修改软件代码并完成回归测试，分别形成单元测试报告、单元集成测试报告和配置项测试报告，通过相应的同行或正式评审后与源代码一起纳入受控库管理，如后续有代码更改需要严格按照更改控制流程进行并完成回归测试。

3.7 软硬件集成测试及第三方评测

软硬件集成测试的任务是将软件置于所属系统环境进行集成测试，以验证“你做了正确的东西(you built the right thing)”。

本阶段由任务提出方主导，任务承制方参与，将通过内部测试的源代码作为系统的一部分，与硬件及系统中其他设备或软件进行集成测试，验证软件是否满足软件任务书的要求，以及是否与整个系统相适应。形成系统整机测试报告或软硬件集成测试报告。

在此过程中，通常根据软件的安全关键等级要求，任务承制方将软件提交第三方评测，并配合评测单位进行第三方评测，对软硬件集成测试和三方评测中发现的问题一并修改，完成相应的回归测试，直至所有问题均得到解决，并严格按照更改控制流程完成受控库中相应文档和代码的更改升级。通过内部测试、软硬件集成测试和三方评测的源代码和全部文档入产品库。

3.8 验收交付

验收交付阶段的主要任务是进行软件验收准备并完成软件验收交付[16]。

在此阶段，任务承制方需要编制软件研制总结报告等管理性文档，提交验收申请，从产品库中提取正式软件产品完成装机，并由任务提出方组织完成软件的验收测试，通过验收测试的软件通常随硬件交付。

至此一个弹上软件的开发周期完成。交付后如果需要对软件进行修改，则执行严格的软件更改控制过程。

4 文档和配置管理要求

弹上软件开发需要遵循的顶层标准GJB2786A[11],GJB438B[12],GJB5235[17]等对军用软件文档和软件配置管理都做了严格的要求，特别是GJB438B详细规定了软件文档编制的要求，因此无论采用什么开发模型，都不能随意减少文档的输出数量或降低对文档质量的要求，本模型也不例外。本模型强调软件文档质量的重要性，区别在于根据弹上软件特点对文档的产生和控制时机进行适应性调整，避免了产生大量频繁变动的正式文档以及不必要的配置管理、正式评审等成本的增加，这样既提高了开发效率，又能通过高的软件文档质量和必要的配置管理活动来保证武器系统研制周期较长情况下的软件可继承性，减少对人的过度依赖。

5 结束语

在软件开发过程中，既尊重软件的特殊性，又遵循和顺应软件研制的一般规律，才能交出高质量的软件，最大程度地减少质量问题的发生。本文提出的软件开发模型，针对大部分弹上软件的特点，强调了研制前期快速功能验证的必要性，中期需求固化和设计实现优化的必要性，以及后期全面系统的测试验证的必要性。本模型适用于大部分弹上软件的开发过程，如果软件有特殊要求或者需求很明确或对质量要求不高的应用场合，则应按照软件的实际情况选择其他更为合适的开发模型。同样，本模型亦同样适用于需求不稳定但对软件质量要求高的其他类软件的开发活动。