载人航天器软件需求变更控制研究

开篇：润墨网以专业的文秘视角，为您筛选了一篇载人航天器软件需求变更控制研究范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：载人航天器工程中，软件实现系统功能的比重越来越大。如何及时、有效地解决软件需求变更问题，已成为软件工程化管理不可回避的课题。论述了载人航天器需求变更产生的原因，在分析当前需求变更控制流程存在问题的基础上，提出了需求变更控制管理的改进流程和方法。该方法已在某型号某大型软件的工程化管理中实践，取得了良好效果。

关键词：载人航天器；软件需求；变更控制；改进流程

中图分类号：TP301文献标识码：A文章编号：1672-7800（2013）006-0023-03

作者简介：李皖玲（1980-），女，硕士，中国空间技术研究院载人航天总体部工程师，研究方向为载人航天器信息系统。

0引言

软件需求在软件产品的整个生存期中占有重要位置，是软件工程项目的依据和出发点，无论是软件开发还是软件维护，都是以满足软件需求为最终目的[1，2]。

在实际工程研制中，用户需求变更的现象不可避免。美国Standish Group 公司对8 400个软件项目的调查和研究指出3种最经常使项目遇到困难的因素，其中，不断改变的需求和规格说明占所有项目的12%[3]。同时，ESPITI机构根据3 800个调查人的回答，管理（更改）需求是被调查者回答的软件研制过程中最难解决的两个最大问题之一[4，5]。以航天某型号的某个子系统为例，共有软件配置项14个，全生命周期共发生需求变更34次，涉及软件11个，占到软件总数的78.6%，发生过4次及4次以上需求变更的软件有4个，占到软件总数的28.5%。

如何及时、有效地控制软件需求变更问题，已成为软件工程化管理不可回避的课题。如果不能对需求变更进行及时有效的控制管理，很可能对整个软件项目造成“牵一发而动全身”的影响[6]。

1需求变更原因及管理现状

1.1需求变更原因

载人航天器软件工程化的一项重要工作是对变更进行控制，以将变更对工作量、工期和质量的影响降低到最小。根据型号研制工作经验，造成需求变更的原因可总结为以下方面：

（1）系统复杂导致需求理解不完整、不明确。载人航天器研制是个庞大的系统工程，由13个分系统构成，一个系统级功能及任务需层层分解至某个软件或某几个软件来实现，带来软件内部、软件与软件之间信息流设计复杂、信息交互频繁。系统需求的复杂性，带来了对软件需求理解的不确定性及不完整风险。

载人航天器软件需求分析需经过系统级、分系统级、配置项级三级开展，在需求分析阶段，若系统级或分系统级未对软件需求进行深入论证、分析，软件研制人员也未重视分系统级及系统级人员的参与，导致需求分析工作各自独立，没有设计出良好的软件结构适应变化，造成后期频繁的需求变更。

（2）工程周期长导致需求不断加以完善。载人航天器的软件研制需经历初样、正样阶段，一般研制周期为2～3

年。在初样阶段，建立初步的软件功能基线后，开发工作即开始启动。随着软件研制工作的深入，分系统会提出新的需求。同时，载人航天器系统与子系统按照同一节点进行开发，即使建立的功能基线是无遗漏的、明确的，但随着工程深入，其中的某个子系统发生任务变更，由此带来该子系统软件或其相关软件需求发生变化。

（3）软件需求本身特点。软件需求作为整个软件项目的最关键的一个输入，同硬件产品不同，具有模糊性、不确定性、变化性和主观性等特点，它的自身特点就决定了变化的可能[5]。

1.2需求变更管理存在的问题

载人航天器软件工程化的需求管理方法经过近10年的运行和实践，确保了多艘航天器软件安全、稳定运行，详细流程见图1所示。但目前需求变更控制流程仍然存在待改进地方，主要体现在以下方面：

（1）需求变更控制方式单一。载人航天器软件工程化对需求变更的控制方式单一的主要表现，其一是未区分软件研制不同阶段需求变更的处理流程，对需求变更控制和管理均是按照图1所示的流程进行，实际上，初样和正样阶段的需求变更，对计划和质量的影响是完全不同的；其二是对所有的需求变更一视同仁，未区分关键性需求和改进性需求，致使需求变更频繁发生，导致工作量和资源投入的不理性增加。

（2）变更影响域分析滞后。对于分系统提出的变更，多是从技术的角度出发，经过系统级、分系统两级论证通过后，以技术要求方式下达。一旦软件研制单位接收到技术要求，按照软件工程化要求进行软件变更及影响域分析时，发现由于此次需求变更对软件架构和研制进度带来较大影响，并引入了质量风险，也只能按照影响域分析结果进行变更。

2需求变更管理流程改进

设计一个清晰的、明确的、可控的、有效管理的需求变更工作流程，有利于促进软件开发过程中的人员分工和合作；有利于对需求变更的处理阶段进行实时监控和跟踪[7]。

需求变更控制改进后流程见图2所示。

2.1变更申请

软件需求变更申请可由需求方（分系统级）提出，也可由开发方（软件研制方）提出。

提出的软件需求变更由开发方归入“需求变更池”进行管理，“需求变更池”由需求变更时间、需求变更定义、变更原因、提出变更人等信息组成。

根据软件研制特点和软件进展阶段，需求方定义需求变更周期，每一个需求变更周期对“需求变更池”的需求进行统一处理。如在初样尚未进入编码阶段，需求变更周期定义为两周，若在初样已完成编码阶段，需求变更周期定义为一个月，在正样阶段，将“需求变更池”的处理周期定义为事件驱动。在每一个需求变更周期内，需求方将与开发方一同，对“需求变更池”内的需求处理一次。

采取“需求变更池”管理的好处是将需求变更流程变为周期性，既能确保所有需求申请都能够得到及时处理并经历正规的需求管理流程，又能尽可能地减少对软件研制过程的干扰。

2.2影响域分析论证

当需求变更周期到达时，需求方和开发方将一同进行变更的影响域分析。

若需求方提出需求更改申请，需与软件经理共同编制需求更动论证及影响分析报告。需求方从更动的必要性、可行性及变更带来的影响方面进行论证，即是否必须进行设计变更才能满足预期的性能指标要求和使用要求，或是对此有明显改善、提出的变更技术上是否合理，工程上是否可行，变更对产品的可靠性、安全性及接口的影响。开发方根据需求跟踪矩阵，标识并实施因分配需求的更改而引起的项目计划、软件工作产品（包含文档和代码）和活动的更改。开发方的影响分析包含软件功能、性能等技术类分析，还应包含管理类的非技术影响分析。

若开发方提出需求更改申请，开发方单独编写需求更动论证及影响分析报告，需重点从软件配置项角度论述更改带来的影响。

在该流程中，影响域分析论证由需求方和开发方在申请得到响应的第一时间内共同完成，需求变更影响域分析将更全面、更系统也更具体。同时，通过影响域分析，将需求方变更也纳入到了工程化管理，既对需求方更改进行了控制，以减少不必要的软件变更，又使得开发方能够及早地参与影响域分析论证，及时应对需求变更。

2.3需求变更评审

软件配置控制委员会（SCCB）（组成人员中包含需求方、软件专家）评估需求变更论证及影响分析报告。

2.4需求变更分级管理实施

在进行需求变更评审时，需对需求变更进行定级，针对定级情况实行分级管理，以达到对需求变更的控制和管理。

根据变更影响域分析，可将需求变更定义为4个级别。一级为变更关键性需求，如若不变更，意味着整个项目不能正常交付使用，前期工作也会被全部否定；二级变更影响后续关键性需求，不影响前面工作内容的交付，但不变更，新的项目内容无法提交或继续；三级变更为后续重要需求，如果不被满足会令整体项目工作的价值和开发人员技术价值下降；四级需求是改良性或可选性需求，没有实施变更并不影响已有功能的使用，代表个人喜好[8，9]。

一二三等级变更，需实施更改；对于四级需求，如果时间和资源条件允许，可实施更改或是后续版本更改。

需求方提出的变更申请，需求方对分配需求进行更改，将变更后的《软件任务书》批准、受控，下发至软件研制单位。开发方接收到正式变更要求，类同开发方提出的变更申请，按照软件工程化管理规定，办理更改的三单审批流程，实施更改。

2.5通报和跟踪

SCCB确认需求已进行实际的变更。软件配置管理工程师通知所有受影响的小组和个人。开发方将因更改而引起的情况通报给受影响的组和个人，对已标识的相关更改进行跟踪，直到更改结束。

3需求变更管理实践

上述需求变更管理流程，已被成功应用到某型号某软件研制过程，该软件为嵌入式C程序，代码规模约为12 000～15 000行。在实践过程中，初样阶段 “需求变更池”处理周期为1个月，正样阶段处理周期定义为“新的需求提出”。至软件交付时，该软件共发生软件需求变更15项，需求方提出需求变更6项，开发方提出需求变更9项，通过需求变更评审，需求变更一级为3项、二级为4项、三级为2项、四级为6项。

通过需求变更管理，该软件共发生的15项需求变更中，实施了13项，有效地控制了软件需求变更比率。在未增加开发人员和资源情况下，同软件开发计划相比，软件过程文档编写数量减少了16份以上，初步预算节省软件工程组人员工时80人时以上；同时软件研制过程可见、受控，软件研制进展顺利，交付进度较计划时间提前了约60天；软件在交付使用后，其功能性能满足用户需求。

4结语

通过分析软件项目开发过程中需求变更产生的原因，提出了软件工程化管理过程中存在的问题，并在此基础上提出了需求变更管理主流程， 该流程保证变更实施在可控范围内进行，将影响域分析提至系统级层面，并将需求变更实施分级管理，从而将变更带来的影响尽可能地降到最小。需求变更管理流程真正将需求方、开发方与需求变化、变更请求和项目管理紧密结合在一起。通过某型号某软件3年的软件工程化管理实践，证实该管理流程使需求变更在项目开发中得到了有序有效管理， 保证了项目的顺利完成， 提高了项目的质量。

参考文献：

[1]韩万江，姜立新.软件项目管理案例教程[M].北京：机械工业出版社，2005.

[2]张海藩.软件工程[M].第1版. 北京：清华大学出版社，2006.

[3]ERACAR Y A， MIECZYSLAW. An architecture for software that adapts to changes in requirement [J] . Journal of System and Software，2000（50）.

[4]STANDISH GROOP. User survey report[R]. European Software Process Improvement Training Initiative， 1995.

[5]秦众森，李娟.需求变更管理过程机器工具分析与展望[J].计算机工程与设计，2009（11）.

[6]SUZANNE ROBERTSON， JAMES ROBERTSON.掌握需求过程[M].王海鹏，译.北京：人民邮电出版社，2003.

[7]傅娟，钱亮亮.浅谈软件需求变更策略[J].科技广场，2008（12）.

[8]雷雷，崔立元.企事业信息系统软件需求变更度量方法[J].计算机工程与应用，2001（37）.