中国人民解放军63921部队 赵爽 刘文红 翟文丽
航天地面系统软件服务于航天和经济建设，随着各类先进技术在天基领域的不断应用，航天地面系统软件越来越多地呈现出信息化、体系化、自动化的特点，软件在航天地面系统软件中所占的比例大幅上升，对软件研制的时效性和质量要求越来越高，当前航天地面系统软件研制面临着下列问题和挑战：
（一）航天地面系统软件研制方式的转变
航天地面系统软件研制发生了巨大的变化，软件规模由单体软件转变为大型复杂系统，研制模式由用户单位自研转变成招标研制或联合研制，从单一团队到多团队协同开发，特别是对于大型系统，涉及到十几家企业联合研制。软件开发模型从瀑布模型转变为敏捷开发，以管理为中心的离散式模型转变为以生产为中心的连续式模型；
软件研制过程中涉及的角色、人员变多，需要大量协同调度等。面对竞标研制、竞争性采购的新常态，在“多任务并举、高密度发射、大批量交付”的科研形势下，航天地面系统软件研制问题日益突出。
（二）需求不确定
时间紧、论证不充分导致任务需求获取不足，软件需求分析不全面，用户试用时需求发生比较大的变化，满足不了任务需要，改动软件工作量大，影响软件进度和质量。需求没有进行有效的管理，需求变更难以控制，系统问题难以追溯，需求维护困难，更无法实现积累与复用。
大型航天软件系统软件开发成本高、风险大、周期长，参与单位及人员众多，如何能够保证研制进度、确保大型航天地面系统软件的质量，增强航天软件系统性能成为亟待解决的问题。本文以某大型航天地面系统为例，研究了敏捷开发在大型航天地面系统的应用。
（一）大型航天地面系统简介
大型航天地面系统存在着系统复杂、业务广、技术含量高等特点，涉及多个学科领域业务知识，交叉性强，规模大，研制周期长，集成难度高，管理复杂。这类系统包含多个分系统、子系统及软件配置项，涉及多个用户单位，用户数量多岗位角色多，需求复杂且不明确。以某系统为例，包含6个分系统、35个子系统，188个软件配置项，由9家企业共同研制完成，用户单位12家，但整个系统研制周期不到2年，同时还要满足急需任务需要。系统基于微服务架构[1]，采用容器化部署方案[2]。
（二）敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，在1991年由Roger提出[3]，它的核心思想在于快速、增量式地交付可工作的软件，个人与沟通胜过过程与工具；
可工作的软件胜过面面俱到的文档；
客户协作胜过合同谈判；
响应变化胜过遵循计划[4-8]。21世纪初，敏捷宣言的发布标志着敏捷软件开发方法正式诞生。敏捷开发主要包括动态系统开发方法、Scrum、极限编程（XP）、透明水晶开发方法（Crystal Methods）和特性驱动开发（FDD）等[4]，在敏捷开发中，软件项目被划分为多个子项目，各个项目的成果都经过测试，具备集成和可运行的特征。敏捷开发一般采用2—4周的迭代周期便能快速响应用户的需求，有效的节省资源，一经提出便受到行业的推崇，越来越多的软件公司始采用敏捷开发模式[9-17]。
（三）敏捷开发的应用
基于大型航天地面系统的复杂性及需求不明确特点以及敏捷开发的适应性，确定采用敏捷开发研制模式，进行敏捷迭代开发、持续集成和测试。项目建立了适应敏捷开发的组织结构，明确了职责，并强调进行基于敏捷的需求工程，加强需求开发和管理。敏捷开发软件研制流程如图1所示，覆盖从立项论证到运行维护乃至报废全过程。
图1 敏捷开发软件研制流程
在基于敏捷迭代开发中，整个软件研发周期划分为原型版、任务版和正式版三个阶段。原型版软件为了满足急需任务需要，基于用户原始需求，完成系统基本和急需任务功能，界面也较为简单。用户代表高度参与此阶段工作，讨论任务需求，参与项目每日站会，对照需求表查看项目功能完成情况。任务版软件是在原型版软件基础上部署到典型用户单位真实环境进行试用，用户根据任务需求和岗位职责对照软件进行试用，反馈新的使用需求和软件存在的问题，研制单位根据反馈问题细化需求，修复缺陷，增加功能，对软件进行升级，并开始多轮的构建和测试，进行迭代完善，持续交付。正式版软件是在任务版软件基础上完成软件系统所有功能，实施第三方评测，开展试验鉴定和验收测试工作，形成最终的正式交付版本。
每个软件版本的研制又划分为一系列短小的、固定长度的小迭代项目。每一次迭代都包括需求分析、设计、实现和集成与测试。由于项目复杂，人员众多，项目采用集中式开发和异地分散式开发相结合的模式[18]，在原型版阶段各研制单位主要在各自的分散开发环境中进行Scrum迭代开发，制定sprint，召开每日站会等，形成数据库段和软件段。软件段包括插件应用程序段、WEB应用程序段、二次开发接口段等等。在集中开发环境中，将段按照约定的标准规范基于统一的集成框架进行迭代的集成和测试，形成系统和系统文档，如图所示。系统采用开放式面向服务架构，支持界面集成、服务集成及数据集成：
1）界面集成。遵循统一的界面集成规范开发集成前台终端软件，通过统一的界面集成框架和通用控件库，确保各系统的用户界面风格和操作方式的一致性。
2）服务集成。新研和已有应用服务资源通过统一的服务目录，完成跨平台服务调用和数据访问，实现服务集成。
3）数据集成。通过统一的数据主题服务目录提供跨平台的数据资源访问服务集成。
图2 开发方式
（一）需求工程
需求工程主要包括需求开发（分析）和需求管理，如图3所示，需求开发包括需求获取、需求分析和需求确认，包括引出用户需求并将其转化为产品需求，对产品需求进行分解，描述产品的功能、性能、设计特征、验证要求等。需求管理包括需求变更管理和需求追踪。鉴于敏捷开发针对的是需求变化多、响应速度快、能频繁交付的开发场景，因此敏捷开发需求工程更加占用重要的地位[19][20]，贯穿于基于敏捷开发的软件研制的全生命周期，重要程度甚至高于基于瀑布模型的软件研制。航天地面系统软件从立项论证开始直至验收交付甚至到维护保障都在进行需求工程。项目需求来源包括系统立项论证报告（可行性分析报告）、研制技术要求（任务书)、需求汇编报告、需求申请表及纪要等等。在立项论证阶段对系统定位、使命任务、关键指标、质量要求、进度以及经费等进行系统论证，立项论证的结果是系统需求的源头，主要是系统业务需求分析及主要功能分析，在后续的技术（建设）方案、任务书、需求规格说明等都在深化需求。运行维护需求开发对交付后产品的运行提供技术支持与服务，监控软件的运行状态，获取维护需求，并制定相应的解决方案，必要时对产品进行改造升级维护。
图3 需求工程
由于本项目系统复杂，规模比较大，用户比较多，需求来源多，因此着重进行了需求开发和需求的有效管理。为了规范系统需求的提出、分发、变更及维护管理，控制需求变化引起的开发、测试与需求不一致的情况，确保用户提出的需求理解准确，在系统中得到充分实现，成立了需求管理组织机构，建立需求管理规定，指定专人，常态化开展需求对接及管理工作，收集用户需求，每半个月开展一轮“需求理解—对接—分析—确认”工作，保障系统开发、测试、上线及运行管理等工作的顺利进行。
（二）角色与职责
1.用户单位为系统主要使用单位，履行下列职责：
(1)负责提出系统用户需求，提出对系统的功能、性能、设计约束和其他方面的期望和要求等；
(2)负责解释项目开发过程中遇到的本单位的系统需求问题；
(3)负责对本单位最终用户需求实现情况进行结果验证；
(4)负责确认需求结果，参与项目验收等。
2.总体单位为系统论证、建设及使用单位，履行下列职责：
(1)负责需求管理的整体协调工作，包括需求管理流程的审批等；
(2)负责提出系统需求，提出对系统的功能、性能、设计约束和其他方面的期望和要求等；
(3)负责系统需求变更分析、需求优先级评估等工作；
(4)负责需求申请和变更审批，对需求进行管理和追踪；
(5)负责对需求实现进行结果验证，确认需求结果并进行项目验收；
(6)负责维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导报告需求进展。
3.研制单位负责实现系统各种需求，履行下列职责：
(1)负责需求开发过程相关工作，处理需求开发、实现、测试和系统上线运行工作；
(2)负责对用户提出的需求进行系统的功能、性能、设计约束和其他方面的需求分析；
(3)负责编写软件需求文档及需求列表等，实现需求人员与开发人员的有效交互；
(4)负责根据需求评审和评估意见，及时修改和调整需求内容；
(5)负责本单位从研制合同开始到项目验收的需求管理与追踪；
(6)负责提出系统开发、性能优化、软件升级等需求。
（三）需求开发
需求开发（获取）主要是获得系统目标需求和引出用户使用需求，由于本项目用户较多且分散，因此将其分为主动获取和主动提交。主动获取指总体单位和研制方通过需求调研表、需求文档、研讨会等形式主动获取用户需求。主动提交指用户或用户代表在原型系统使用过程中记录使用需求，形成用户需求文档（需求汇编），通过需求申请表和需求汇编报告等形式主动向总体单位和研制方提交用户需求。需求申请表如表1所示：
表1 需求申请表
本项目当系统初步完成原型版开发提交用户使用后，用户根据使用过程中的问题和使用需求，形成用户需求汇编。例如某典型单位多个岗位的用户提出上下册200多页的需求汇编，其中涵盖系统所有子系统。
（四）需求理解与分析
在获得用户需求后，需将其转化为产品需求，并对产品需求进行分解，描述产品的功能、性能、设计特征、验证要求等。研发项目组在拿到来源于用户单位的需求汇编（上/下册）和需求申请表，梳理待明确或待细化问题，初步形成需求分析报告，进一步与用户对接沟通，理解需求。
在需求沟通理解的基础上，研制方进一步对需求进行分析，梳理出680项原始需求，建立了项目需求列表。研发人员依据项目需求列表，进行了需求分析，将需求分解映射到软件配置项，确定需求优先级、研制单位及在哪个版本中实现该需求，有些不在项目建设范围内的需求纳入到项目二期是实现，如表2所示。上述680项在原型版实现190项，任务版64，正式版266项，其余161项需求纳入项目二期建设。
表2 需求分析表
（五）需求确认
需求确认按照需求分析评审和软件成果确认两种方式组织实施。
1.需求评审
总体单位组织需求分析预审，参加需求预审的单位包括用户单位及各承研单位，完成对需求的预审查，确保处理措施明确可行，初步设计合理，完成时间满足要求。各承研单位根据预审查的问题进行修改完善。
2.软件确认
软件完成小版本迭代后，由总体单位组织各承研单位提交软件阶段成果，对软件功能完成情况进行确认，对软件版本进行管理，及时更新至部署环境，进一步由用户进行功能确认后，部署更新至各用户单位。
（六）需求管理
为了保证需求的完整性、一致性，需要在整个软件生命周期对需求进行管理，追踪从用户到产品，以及产品部件的需求，并控制其变更，需求追踪表如表3所示。
表3 需求追踪表
GJB5000标准是军用软件研制能力成熟度模型，GJB5000A是以CMMI1.2版本为基础制定的适用于软件开发全过程的通用标准，关注标准化的研制过程和规范化的文档，对软件工程过程进行管理，保证按时交付高质量的软件产品。在实施过程中，特别是在5000A评价的早期，多采用严流程、重文档的瀑布生存周期模型，但这与轻量级、轻文档的敏捷开发并不矛盾，在本质上都是为了提高产品质量、保证研制进度[21-23]。GJB5000A规定了管理、工程和支持实践域，未规定如何实施，鼓励依据标准因地制宜，建立本地化软件过程管理体系，可以根据项目特点进行适当的剪裁。GJB5000A在向5000B改版时，特别强调了对于敏捷方法的适用，并在某研制企业进行了试点，分析了其覆盖的实践域。
在基于敏捷研制过程中，需求开发和管理、配置管理都占有很高的地位，计划会议、每日站会、评审会议和回顾会议等都是在进行项目策划和管理，从传统的WBS转为基于需求特性进行项目管理。产品任务列表、需求汇编报告、纪要、每个迭代版本的设计、测试大纲、报告等都是文档类产品，特别是在本项目研制过程中，在任务版和正式版交付时，都要求整理过程记录和文档，形式规范化的项目文档。而敏捷工具的使用，自动化的记录和分析了项目研制过程中的数据，供质量保证和测量与分析使用。敏捷开发的特点就是需求不明确，因此会引入变化和风险，在每个迭代周期，都在不断的识别风险并跟踪，有效进行风险的缓解。
敏捷开发方法的应用解决了传统瀑布模型对于需求不确定反复迭代的大型软件项目不适用的问题，极大的降低了项目的风险，保证了项目的进度，在早期就能得到用户对系统的反馈，并在初始迭代中实现，项目质量也得到了保证。但敏捷开发对用户的参与度要求比较高，可以说用户已经成为了研发团队的一员，人与人之间的沟通十分重要，因此构建合理流畅的工作流程、分散与集中的工作环境、团队的有效合作特别重要。
猜你喜欢 文档研制航天 高弹倍固沥青防水涂料的研制建材发展导向(2022年12期)2022-08-19血管吻合试验台的研制及试用现代仪器与医疗(2022年3期)2022-08-12浅谈Matlab与Word文档的应用接口客联(2022年3期)2022-05-31我的航天梦儿童时代(2022年4期)2022-04-19有人一声不吭向你扔了个文档中国新闻周刊(2021年26期)2021-07-27轻松编辑PDF文档电脑爱好者(2021年9期)2021-05-12逐梦航天日学苑创造·A版(2019年8期)2019-08-15Word文档 高效分合有高招电脑爱好者(2017年7期)2017-05-06“我心中的航天梦”画作展军事文摘·科学少年(2017年1期)2017-04-26“我心中的航天梦”画作展军事文摘·科学少年(2017年2期)2017-04-26