赫歇尔空间天文台科学地面段软件开发管理方法的研究*

张 洁，黄茂海

(中国科学院国家天文台，北京 100012)

CN 53-1189/P ISSN 1672-7673

赫歇尔空间天文台科学地面段软件开发管理方法的研究*

张 洁，黄茂海

(中国科学院国家天文台，北京 100012)

国内空间项目软件管理方法已经不能满足当前日益复杂的地面应用系统的要求。深入研究了具有国际领先水平的赫歇尔(Herschel)空间天文台科学地面段的软件开发管理方法。赫歇尔科学地面段基于迭代模型的分支开发的特点,切实可行的软件管理计划以及基于用例需求的开放管理方式改变了地面段总是处于整个工程建设的末端的现状，而是从载荷研制阶段就开始工作，而且面对频繁的需求变更，始终保持高效的工作状态，这些在国内空间项目中是前所未有的。本研究给国内空间项目的软件开发提供了新的思路和方法。

空间天文学其他学科；软件开发管理；过程模型；迭代开发；需求管理；用例

随着国内航天科技工业体系的发展，作为五大系统之一的地面应用系统在各项目型号中占得比重也越来越重要。尤其在空间科学项目中，地面应用系统具有有效载荷种类和数量多、面对的用户最多、用户需求变化最大、运行管理复杂等特点[1-2]。然而，国内空间项目地面系统软件开发的管理方式还停留在空间项目的发展初期，大多采用瀑布式、长期固化需求的管理方式，面对地面应用系统的这些新特点，传统的管理方式显得难以应付[3-4]，甚至可能会在研制过程的后期带来很大的风险。

作为欧洲迄今最复杂的空间科学设备——赫歇尔红外空间天文台项目之所以能成功运作，其颠覆以往常用的瀑布模型，采用积极拥抱变化的策略的项目管理方式功不可没。2005年到2013年，中国科学院国家天文台加入赫歇尔地面段研制和运行[5]，作为成员正式投入工程力量，成为地面段软件系统开发的重要方面，获得科学权益，所做出的贡献获得国际同行的高度评价。通过合作，在国内成功安装运行了欧洲空间局基石级别项目的科学地面段软件系统，消化了具有世界领先水平的地面应用系统技术和运行流程，还将立足国内的技术团队“嵌入”到欧洲空间局成熟高效的工程系统中，学习、建立了长期稳定的高效管理和沟通机制。本文根据合作中获得的知识、技术、经验，深入剖析赫歇尔地面应用系统的软件工程管理，为国内空间项目的软件开发管理提供新的思路和借鉴。

1 赫歇尔红外空间天文台科学地面段简介

赫歇尔(Herschel)是欧洲空间局建造的大型红外空间望远镜，作为空间科学“基石”项目，是欧洲空间局研制的最为复杂的航天器。它具有直径3.5 m的主镜和3台非常灵敏的探测仪器：成像光谱与测光仪(Spectral and Photometric Imaging Receiver, SPIRE)、光电阵列和射谱仪(Photodetector Array Camera and Spectrometer Instrument, PACS)、远红外外差接收机(Heterodyne Instrument for the Far Infrared, HIFI)。

与国内空间地面应用系统的概念有所不同，地面段还包括相应的组织单位和相关人员。在欧洲空间标准ECSS-E-70Part1A中明确定义了地面段的概念，即包括为工程任务执行和准备的所有地面设施及相关人员。赫歇尔科学地面段由科学中心(HSC)、3个专用仪器控制中心(ICCs)、任务操作中心(MOC)组成。图1显示了赫歇尔科学地面段的主要结构及其与系统其他部分的关系。

由于赫歇尔空间天文台的3个仪器和科学中心分别位于不同的国家，为了使地面段能够整体有效地工作，赫歇尔公共科学系统(Herschel Common Science System, HCSS)被研制出来，用于实现各个载荷需要的功能等，它是赫歇尔地面系统的重要组成部分。赫歇尔公共科学系统是作为所有与赫歇尔操作相关的信息、数据、软件的公共库。同时它是所有赫歇尔用户获取数据和进行通信的基础结构[6]。公共科学系统与赫歇尔各系统的数据流交互图见图2。

图1 赫歇尔科学地面段的主要结构

Fig.1 Illustration of the structure of the Herschel Science Ground Segment (HSGS)

图2 公共科学系统与赫歇尔各系统的数据流

Fig.2 Illustration of data flows between the HCSS and other systems

3个仪器控制中心分别监视各自仪器行为，分析与发布定标数据产品，赫歇尔科学中心规划和维护系统的科学观测日程，任务中心则维护与卫星的通讯。仪器控制中心、科学中心、任务中心和天文学家通过赫歇尔公共科学系统进行数据的交互，实现各自的任务要求。

2 赫歇尔公共科学系统软件开发线路图(Road Map)

2.1 赫歇尔公共科学系统软件过程模型

赫歇尔公共科学系统全程支持星上载荷仪器的设计制造、测试、集成联试、在轨测试以及日常运行各个阶段，从根本上决定了不可能采用瀑布模型，而是采用了在中小项目中常用的迭代模型。赫歇尔公共科学系统开发过程要经历一个从先启阶段->精化阶段->构建阶段->移交阶段的过程(开发周期)[7]，见图3。在先启阶段主要关注建立系统的范围和整体需求；精化阶段进一步定义需求、分析问题域、建

立架构基线并且识别主要风险；构建阶段把可运行的架构基线，经过一系列的迭代循环，开发出完整的系统；移交阶段则是为项目最终交付做准备。在迭代过程中的每一个生命周期阶段都经过需求、分析、设计、实现、测试以及发布的过程。

图3 迭代模型开发阶段

Fig.3 A list of stages in developing an iterative model

赫歇尔公共科学系统开发方式最大的创新之一就是支持赫歇尔整个生命周期的所有活动。赫歇尔公共科学系统的开发与载荷仪器的研发测试是并行同步开展的。系统在有效载荷研制阶段、整星集成和联调阶段、在轨测试阶段、日常运行阶段以及项目结束后的长期成果保存阶段，都为各种用户提供一致的交互支持，实现赫歇尔公共科学系统在项目研制周期的各个阶段实现平滑过渡。这样做的好处一方面提高了软件的兼容性，提高软件的利用率；另一方面仪器研发人员和科学家从一开始就可以得到全面的操作训练，降低了在轨运行时人为的操作失误，同时地面软件也能在开发过程中通过真实的数据不断测试和改进，能最大程度地保证飞行器任务的顺利执行。

2.2 赫歇尔公共科学系统软件开发策略

赫歇尔公共科学系统在开发过程中采用分支开发的策略，在每个迭代周期内同时维护几个版本的并行发开，测试与代码开发并行。其中进化开发代码线总是不断地继续向前，分支开发代码线则在每个迭代周期的代码冻结后顺序进入稳定化，测试以及维护阶段。采用这个策略，版本i在稳定化、测试及维护阶段后，后续版本的i+1的开发计划和实施可以不受终端的影响，继续执行。

图4 分支开发策略

Fig.4 Illustration of the method of branched development

为了尽量减少维护多版本造成的版本混乱，赫歇尔公共科学系统在一个迭代周期里只维护两个版本，一个开发版本和一个分支版本。

2.2.1 开发版本要求

当迭代计划确定后，开发代码不需要等待配置管理委员会(Configuration Control Board, CCB)的任何批准，只需按照迭代计划持续演进。当新的需求被受理接收后，根据其优先级别被分配到要进行的一个迭代中，等到相应的迭代计划开始时，才在开发版本中进行变更，值得注意的是开发版本是更新所有的新需求的唯一入口。

2.2.2 分支版本要求

当开发版本的要求可以满足测试计划的要求时，配置管理员建立分支基线将分支从开发主线上脱离，形成分支版本。分支版本的活动主要包括测试、维护以及有限的修改变更。

测试活动包括：系统端到端测试、数据处理流水线功能测试以及最终用户接受测试。测试过程中发生的问题修改必须由相应的配置管理委员会批准后执行，且必须通过补丁流程提交修改申请。只有是软件错误的修复问题才能在分支版本中执行。

当测试和修复完成后，经配置管理委员会批准此版本的发布和安装，分支版本始终是发布新版本的唯一渠道。

这种设计开发与测试既独立又重叠的开发方式，优化了项目计划，使得资源合理应用，并且大大缩短了赫歇尔项目的研制周期。

3 软件开发过程管理的实施

赫歇尔空间天文台项目的参与者来自十几个不同的国家，其项目管理的难度可想而知。赫歇尔科学地面段在项目管理组织的领导下，通过十多年的开发过程，在把握管理用户需求、确定项目范围、控制项目规模、进行质量和进度的管理、配置管理、系统确认和验证以及风险管理等方面积累了丰富的经验和实践总结，其中极具特色的当属项目计划的制定与管理和需求管理。

3.1 赫歇尔公共科学系统软件项目管理计划(Software Project Management Plan, SPMP)

赫歇尔科学地面段从系统的角度对地面系统和星上载荷仪器进行统一的规划和系统的管理，合理制定计划，地面系统和卫星系统的工作相互交叉和影响，调动起双方研制人员的主观能动性，充分参与到对方的开发工作中，实现地面系统支持各个阶段的测试工作。

在项目初期，赫歇尔科学地面段就确定软件计划，包括通过工作分解结构(Work Breakdown Structure, WBS)识别任务阶段，定义科学地面段组织结构及团队职责，制定项目计划的可行性检查方案。需要说明的是软件项目管理计划并不是一成不变的，而是允许在开发过程不断地演进和细化，比如进度的调整和迭代计划等。

(1)任务阶段的识别和统一

从项目一开始，项目管理组就从系统的层面将地面系统的研制流程纳入开发计划中，将地面系统的任务与工程大系统的研制任务同步，将其分为9个任务阶段，分别是：

•载荷仪器测试阶段(ILT)：主要测试仪器的功能、环境和科学表现；

•系统测试阶段(IST)：验证仪器的功能以及仪器之间的兼容性；

•地面段测试阶段：地面中心为独立的飞行操作做准备；

•发射和早期轨道阶段：科学负载关闭；

•试运行阶段：包括航天器和仪器试运行；

•定标和性能验证阶段：可以获得所有仪器的飞行性能数据；

•科学演示阶段：总结在性能验证阶段获得的结果和知识；

•常规运行阶段：用于获得赫歇尔的运行活动的数据；

•后任务阶段：包括纲要监控阶段、任务巩固阶段、主要存档阶段和存档巩固阶段。

通过9个阶段的划分，地面系统在各个阶段的任务一目了然，根据每个阶段的任务安排制定迭代计划，支持各个阶段的测试工作，不仅使得地面系统的研制与星上设备同步运行，同时通过不断地提交迭代版本进行载荷和集成的测试，逐步完善地面系统。

(2)各团队职责的明确

赫歇尔公共科学系统由科学中心(HSC)和3个仪器控制中心(ICC)共同开发。不同于国内空间项目，赫歇尔公共科学系统在不同任务阶段，其用户角色是不同的。这些用户角色分为两类。一类是使用赫歇尔公共科学系统，并把它作为一个科学系统，例如：帮助开发和测试仪器，要求和执行赫歇尔观测、生成、存储和分析数据等，包括仪器控制中心、科学中心、任务控制中心以及天文学家等。另一类是软件工程用户角色，负责系统设计、开发、维护、测试和集成等[8]。

图5 地面系统在各个阶段的平滑过渡

Fig.5 Illustration of realization of smooth transitions between different development stages in the ground segment

图6 各任务阶段用户角色交互

Fig.6 Illustration of interactions between the roles of users that are in different mission stages

赫歇尔公共科学系统根据不同任务阶段的需要，与不同系统的用户进行交互。在仪器测试阶段和集成测试阶段，与仪器控制中心的仪器工程师进行交互，分别用于3台仪器的测试和验证3台仪器的集成是否被成功执行。在常规运行阶段，与仪器控制中心、任务控制中心、科学中心和天文学家进行交互，用于常规运行活动。在这些任务中，科学地面段根据交互测试和运行的结果，决定是否需要更改新的需求或者是进行修复。通过这样的方式，不断输送迭代出的满足计划要求的软件版本，有效地将赫歇尔公共科学系统参与到系统各个任务阶段的测试当中。

3.2 需求管理

赫歇尔公共科学系统另一特色是永无停止的需求开发过程。从研制开始到现在已经成功解决了一万多个问题，发射4年来包含几百万源代码的处理软件已经演进了10个版本。虽然飞行器已经停止运行，但是需求还是不断地被提出、被分析、被处理。科学地面段之所以能够第一时间高效地进入工作状态，与其科学的需求管理是分不开的。

3.3 基于用例的需求开发方式

考虑到以传统的软件需求规格说明来描述系统的需求，非常容易混淆需求和设计的界限，而且这种方法分割了各项系统功能的应用环境，从各项功能入手，很难了解这些功能项是依靠怎样的相互关联完成系统目标的问题[9]，赫歇尔科学地面段软件需求管理不同于国内空间项目的管理方式，采用基于用例描述需求的开发方式。这种基于用例需求的方法完全是站在用户的角度上(从系统的外部)描述系统的功能，大大帮助开发人员和用户之间针对系统需求的沟通。

首先根据先启阶段定义项目前景文档，识别可能用例的用户和系统，定义系统的技术需求，然后收集确定客户和其他相关人员的需要和特性，形成用例模型。赫歇尔公共科学系统的用例模型都是在精化阶段产生，包括：用户角色描述文档，用例文档和补充需求文档，识别各个任务阶段的所有角色，并且描述了各用户与赫歇尔公共科学系统以及数据处理模块之间的交互关系[10-11]。赫歇尔公共科学系统根据这些顶层文档，进一步明确系统规模，细化用户需要特性、用例需求和工作流程。基于用例的需求开发，有助于识别和追踪用户需要和相关用例需求的属性，各需求的依赖关系和需求的可追踪性。

3.4 赫歇尔科学地面段需求管理

赫歇尔科学地面的需求管理是完全开放的，并且采用积极拥抱变化的策略。任何人在任何时候都可以提出新的需求，无论需求合不合理，只要需求被提出，相关责任人都会在最短的时间对新需求的提出做出回应。赫歇尔成功发射距今已经有5年之久，至今还是有需求不断被提出、分析、修改和维护。到目前为止，仍然没有一份完整齐全的最终固化的需求用例被确定，需求始终处于一个变化的状态。

这样看似杂乱无章的管理方式在国内空间项目中几乎不可能出现。国内空间项目往往是在项目初期就确立了所有的需求，发生变更是非常少见的，尤其是到研制阶段的后期，一旦发生变更，费时费力，而且风险巨大。而赫歇尔科学地面段却以开放的管理模式处理了超过17 000条的变更请求，其

主要原因就是它采用了合理的变更管理流程(图7)和基于缺陷跟踪管理系统的管理。

(1)变更管理流程

系统的变更(包括新需求)可以由科学地面段开发团队、载荷仪器控制中心和项目科学团队成员提出，同时分配给相关开发团队成员，进行初步调查研究，目标是分析实施变更对技术、开支、进度的影响。技术影响的分析包括哪些工作产品会受影响、实施变更以及验证所有被影响的交付物所需要的努力的估算。一旦调查研究完成，由配置管理委员会评估做出安排，接受或者拒绝。

一旦变更请求被接受，变更请求的实施和验证会以和其他工作项一样的方式，根据其优先级别被分配到要进行的一个迭代中，相应的迭代计划和测试计划也做出更新。在进行项目迭代计划时，回顾积压的变更请求列表，设定工作的优先级，决定下一步实施哪些变更。这样的流程使得发生的变更可以井然有序的按照迭代计划进行，而不会出现版本的混乱。

图7 变更管理流程

Fig.7 Illustration of change of the management process

(2)基于缺陷跟踪管理系统的管理

赫歇尔科学地面段需求的变更是基于缺陷跟踪管理系统进行管理，所有的变更记录都在缺陷跟踪管理系统中，包括请求、分析、接受或拒绝、实施、验证和关闭。在缺陷跟踪管理系统中，要求记录每一个需求的变更请求的状态，包括：ID(缺陷跟踪管理系统自动分配)、简要描述、详细描述、影响、严重性以及优先级(图8)。

图8 缺陷跟踪管理系统的issue状态

Fig.8 A display of the Issue state of the JIRA

赫歇尔科学地面段所有的系统变更过程使用工作项列表的方式记录在缺陷跟踪管理系统平台中，便于系统变更的捕获、设定优先级和跟踪变更请求。缺陷跟踪管理系统的使用极大地减少与变更管理和可跟踪性相关的资源消耗。

4 结束语

赫歇尔科学地面段软件开发管理方法是在赫歇尔项目长达十几年的开发过程中，同时在欧洲空间合作标准化(European Cooperation For Space Standardization, ECSS)的框架下，不断总结改进的软件工程方法。如何借鉴赫歇尔科学地面段先进的软件开发管理方法，结合国内空间项目的特点，能够合理地应用到软件项目中，还需要继续深入研究，在实践中不断提高。

[1] 黄慧明. 我国第一代中继卫星地面应用系统发展建设的思考[J].飞行器测控学报, 2012, 31(5): 1-5. Huang Huiming. Reflections on development of the ground system of the first generation CTDRSS[J]. Journal of Spacecraft TT & C Technology, 2012, 31(5): 1-5.

[2] 陈宁. 地面应用系统: “嫦娥”的数据处理中心[J]. 国防科技工业, 2010(10): 40-41.

[3] 许文. “双轨制”时期对科技文件管理工作的思考[J]. 航天制造技术, 2012(3): 67-69. Xu Wen. On the managing work of scientific and technical files during the “double-track pricing system”[J]. Aerospace Manufacturing Technology, 2012(3): 67-69.

[4] 施宁. 中国航天型号工程项目管理若干问题研究[D]. 北京: 对外经贸大学, 2003.

[5] Ott S. Developing a data processing system for a world-class observatory: sharing the Herschel experience[EB/OL]. [2015-01-23]. http://colloquium.bao.ac.cn/sites/default/files/PPT_NAOC%20colloquium_No.68.2012_Dr.Stephan%20Ott.pdf.

[6] Roelfsema P. Designing for software reuse-the Herschel common science system[EB/OL].[2015-01-23]. http://www.ercim.eu/publication/Ercim_News/enw65/roelfsema.html.

[7] 毕特纳, 思朋斯. 迭代软件开发项目管理[M]. 罗景文, 罗灿锋, 张弘毅, 译. 北京: 清华大学出版社. 2010.

[8] Brumfitt J, Zäschke T. Herschel common science system overall architecture and design[EB/OL]. 2007[2015-01-23]. http://herschel.esac.esa.int/hcss-doc-13.0/load/hcss_drm/design/architecture.html.

[9] 肖瑾. 基于用例的软件需求管理研究[J]. 核动力工程, 2009, 30(S2): 79-83+99. Xiao Jin. Software requirements management based on use cases[J]. Nuclear Power Engineering, 2009, 30(S2): 79-83+99.

[10]HCSS Development Team. Herschel common science system: use case definitions[EB/OL]. 2006[2015-01-23]. https://home.sron.nl/j/Hifi/User/ccadm/0068.pdf.

[11]HCSS Development Team. Herschel common science system: actor descriptions[EB/OL]. 2006[2015-01-23]. https://home.sron.nl/j/Hifi/User/ccadm/0058.pdf.

A Study of the Method for Software-Development Managementof the Herschel Science Ground Segment

Zhang Jie, Huang Maohai

(National Astronomical Observatories, Chinese Academy of Sciences, Beijing 100012, China, Email: mhuang@nao.cas.cn)

Currently project software managements for space observatories in China adopt methods based on the waterfall model and the requirement management for long-term fixed requirements. These methods cannot meet the demand to develop complex systems for ground-based applications of spaced-based observation. In this paper we present a study of the method of software-development management for the Herschel Science Ground Segment (HSGS), which is a first-class successful model of software-development management of the world. The HSGS uses the method of branched development. Based on an iterative model the method of branched development adopts the Software Project Management Plan (SPMP), which is practically reasonable and applicable. The implementation of the method in the HSGS synthetically meets the requirements of the HSGS and the payloads of the entire project. The method is an open-management approach capable of incorporating application requirements in practically emerging use cases. With the method the HSGS changes the conventional situation that a system for ground-based applications is developed at the final stage of a project of a spaced-based observatory. Instead, the HSGS works right from the payload-development stage, and it is frequently adjusted to meet changing requirements. The HSGS can thus always support data-analysis systems highly efficiently. The instrument engineers and scientists can accept training of operation of the scientific instruments from the start of the project to reduce chances for operational mistakes. Meanwhile, the software in the HSGS can be improved in the course of operations to ensure mission success. The merits of the HSGS are absent in managements of Chinese space projects. Our study of the HSGS shows a new method and a new line of thoughts for software-engineering managements of space-observatory projects in China.

Space astronomy; Software-development management; Process model; Iterative model; Requirement management; Use cases

中国科学院战略性先导科技专项 (XDA04080300) 资助.

2014-08-09；修定日期：2014-09-14 作者简介：张 洁，女，助理研究员. 研究方向：空间天文技术方法. Email: zhangjie@nao.cas.cn 通讯作者：黄茂海，男，研究员. 研究方向：天文技术与方法. Email: mhuang@nao.cas.cn

V556; TP311

A

1672-7673(2015)02-0212-07