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

《载人航天器软件需求变更控制探究》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、载人航天器软件需求变更控制探究　　摘要：载人航天器工程中，软件实现系统功能的比重越来越大。如何及时、有效地解决软件需求变更问题，已成为软件工程化管理不可回避的课题。论述了载人航天器需求变更产生的原因，在分析当前需求变更控制流程存在问题的基础上，提出了需求变更控制管理的改进流程和方法。该方法已在某型号某大型软件的工程化管理中实践，取得了良好效果。关键词：载人航天器；软件需求；变更控制；改进流程中图分类号：TP301文献标识码：A文章编号：1672-7800（2013）006-0023-03作者简介：李

2、皖玲（1980-），女，硕士，中国空间技术研究院载人航天总体部工程师，研究方向为载人航天器信息系统。0引言软件需求在软件产品的整个生存期中占有重要位置，是软件工程项目的依据和出发点，无论是软件开发还是软件维护，都是以满足软件需求为最终目的[1，2]。在实际工程研制中，用户需求变更的现象不可避免。美国StandishGroup公司对89400个软件项目的调查和研究指出3种最经常使项目遇到困难的因素，其中，不断改变的需求和规格说明占所有项目的12%[3]。同时，ESPITI机构根据3800个调查人的回答

3、，管理（更改）需求是被调查者回答的软件研制过程中最难解决的两个最大问题之一[4，5]。以航天某型号的某个子系统为例，共有软件配置项14个，全生命周期共发生需求变更34次，涉及软件11个，占到软件总数的78.6%，发生过4次及4次以上需求变更的软件有4个，占到软件总数的28.5%。如何及时、有效地控制软件需求变更问题，已成为软件工程化管理不可回避的课题。如果不能对需求变更进行及时有效的控制管理，很可能对整个软件项目造成“牵一发而动全身”的影响[6]。1需求变更原因及管理现状1.1需求变更原因载人航天器

4、软件工程化的一项重要工作是对变更进行控制，以将变更对工作量、工期和质量的影响降低到最小。根据型号研制工作经验，造成需求变更的原因可总结为以下方面：9（1）系统复杂导致需求理解不完整、不明确。载人航天器研制是个庞大的系统工程，由13个分系统构成，一个系统级功能及任务需层层分解至某个软件或某几个软件来实现，带来软件内部、软件与软件之间信息流设计复杂、信息交互频繁。系统需求的复杂性，带来了对软件需求理解的不确定性及不完整风险。载人航天器软件需求分析需经过系统级、分系统级、配置项级三级开展，在需求分析阶段，

5、若系统级或分系统级未对软件需求进行深入论证、分析，软件研制人员也未重视分系统级及系统级人员的参与，导致需求分析工作各自独立，没有设计出良好的软件结构适应变化，造成后期频繁的需求变更。（2）工程周期长导致需求不断加以完善。载人航天器的软件研制需经历初样、正样阶段，一般研制周期为2～3年。在初样阶段，建立初步的软件功能基线后，开发工作即开始启动。随着软件研制工作的深入，分系统会提出新的需求。同时，载人航天器系统与子系统按照同一节点进行开发，即使建立的功能基线是无遗漏的、明确的，但随着工程深入，其中的某个

6、子系统发生任务变更，由此带来该子系统软件或其相关软件需求发生变化。（3）软件需求本身特点。软件需求作为整个软件项目的最关键的一个输入，同硬件产品不同，具有模糊性、不确定性、变化性和主观性等特点，它的自身特点就决定了变化的可能[5]。1.2需求变更管理存在的问题9载人航天器软件工程化的需求管理方法经过近10年的运行和实践，确保了多艘航天器软件安全、稳定运行，详细流程见图1所示。但目前需求变更控制流程仍然存在待改进地方，主要体现在以下方面：（1）需求变更控制方式单一。载人航天器软件工程化对需求变更的控制

7、方式单一的主要表现，其一是未区分软件研制不同阶段需求变更的处理流程，对需求变更控制和管理均是按照图1所示的流程进行，实际上，初样和正样阶段的需求变更，对计划和质量的影响是完全不同的；其二是对所有的需求变更一视同仁，未区分关键性需求和改进性需求，致使需求变更频繁发生，导致工作量和资源投入的不理性增加。（2）变更影响域分析滞后。对于分系统提出的变更，多是从技术的角度出发，经过系统级、分系统两级论证通过后，以技术要求方式下达。一旦软件研制单位接收到技术要求，按照软件工程化要求进行软件变更及影响域分析时，发

8、现由于此次需求变更对软件架构和研制进度带来较大影响，并引入了质量风险，也只能按照影响域分析结果进行变更。2需求变更管理流程改进设计一个清晰的、明确的、可控的、有效管理的需求变更工作流程，有利于促进软件开发过程中的人员分工和合作；有利于对需求变更的处理阶段进行实时监控和跟踪[7]。需求变更控制改进后流程见图2所示。2.1变更申请9软件需求变更申请可由需求方（分系统级）提出，也可由开发方（软件研制方）提出。提出的软件需求变更由开发方归入“需求变更池”进行管理，“需求变更池