运载火箭软件外协开发的思考---软件开发的几个关系探讨

查看原文

其他

运载火箭软件外协开发的思考---软件开发的几个关系探讨

原创洞穴之外理念世界的影子 2021-06-23

公众号：理念世界的影子

文不可无观点，观点不可无论据。

转载请注明出处

运载火箭软件怎么外协开发？一家之言，贻笑大方。

准备持续推送MATLAB程序设计的体会，写了一篇软件的软文起个头，不一定合适，但总比火箭总体设计更接近一点。

无论是从100多年前巴贝奇的差分机和第一位程序员艾达算起（https://blog.csdn.net/u012396362/article/details/80121363），或是从72年前的通用计算机ENIAC算起，还是从61年前高级语言Fortran首次成功运行算起。计算机软件在极短时间内取得的巨大成就足以使所有其它工程黯然失色，软件是系统工程的集中体现，是人类智慧的结晶。

运载火箭同样是人类智慧的结晶，它是对科学原理要求准确，对数据要求精确的一个行业，涉及较大的算法复杂度和大量的数据处理。它的发展依赖于配套软件的发展。目前相关软件开发采用半自编、半外协的方式。做好外协软件开发，首先是要想好如下几个关系。

1、软件开发与工程关系---IO和插值，还是理论和流程？是个重要问题

2、软件开发与需求关系---从自发的“需求捕捉”上升到自觉的“需求分析”

3、软件开发与架构关系---超越“楼上楼下电灯电话”的思维

4、软件开发与通用性关系---失去易用失去很多，失去通用失去所有

5、软件开发与界面关系---文本在前界面在后

6、软件开发与平台关系---平台是软件水平发展到一定程度的产物

7、软件开发与持续改进关系---建立软件分级体系

8、软件开发与维护使用关系---易用性和组织保障双管齐下

1、软件开发与工程关系---IO和插值，还是理论和流程？是个重要问题

专业建设是各工程组组级建设的核心，其内涵包括理论拓展、流程固化、标准规范、软件建设等。目前，外协最多的是软件建设，而其它被认为是专业自身工作。

那么，工程上软件建设的核心在哪儿呢？笔者认为，是IO与插值，IO是数据接口和流向，插值是数据处理方法。软件建设要能适应多类型IO，要能用、易用、好用，而且要预留接口，可以配置复杂的IO，要可扩展；软件也能应用多类插值，插值要流程简单、数据驱动，而不是通过软件内部写死大量逻辑来驱动。

在工程组建设中，建议对如下两个事物严格区分。

一是严格区分软件建设与理论拓展，对于部分需要外协的理论拓展问题，对工具的要求不宜太高，不要陷入IO和插值，被繁琐的IO和插值环节掩盖了主要矛盾，验收时有个门面即可。能不能两个都想要？笔者认为一般情况下可行性不高。看看国内，目前有特别突出的商用大型计算软件吗？也许，唯一有点知名度的只有MWorks吧，而笔者认为其成功的一大原因，也是因为有现成的modelica规范。

二是严格区分软件建设与流程固化。在软件建设前，对于IO、插值等应该有清晰的认识和表述，而不应在软件建设时才来梳理，甚至由软件开发者来梳理。能不能同时开展？笔者认为这样效果不会太好，因为软件需求梳理和方案设计是个需要综合全部信息的过程，如果总是在随时提出新的接口，新的方法，在原有基础上修修补补，将会影响软件通用性，同时也会让开发人员疲于奔命，而无法全情投入。

2、软件开发与需求关系---从自发的“需求捕捉”上升到自觉的“需求分析”

软件开发是根据用户需求建造出软件系统的过程，是一项包括需求捕捉，需求分析、设计、实现和测试的系统工程。

工程类软件任务书提出要超越朦胧的需求捕捉阶段，这个阶段关注“我需要什么功能”？但功能的细节缺乏，无法写出需求的详细形式，无法描述清楚IO具体是什么样子的，流程是什么样子的？更不用说据此归纳出模式和种类。

软件需求分析是对软件的一个系统的分析与设想，是对用户需求进行理解、归纳，然后用软件工程开发语言（即需求规格说明书）表达出来的流程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。

作为需求，在航天系统内存在这样一个事实上的困难，就是专业性太强，以及使用模式复杂(甚至混乱)，这也注定了外协单位难以独立做出需求分析，更多的是由火箭工程师直接指定，即使是通过多次会议逐步讨论，最终还是由火箭工程师确认的。因此，有必要在火箭工程师和软件工程师之间假设一道桥梁，而这道桥梁，既需要懂软件，更需要懂火箭，由他来实现“需求捕捉”到“需求分析”的提升。如这道桥梁暂时不存在，笔者认为，将需求分析主体放在火箭工程师身上，而不是软件工程师身上也许更为合适。一是因为火箭设计中概念多、细节多、取舍多，当火箭工程师不懂软件时，他甚至都捕捉不到确切需求；二是因为火箭工程师在同一专业浸淫时间长，可以持续发力，而不像软件工程师总是随时换个项目做；三是因为火箭工程师都学过软件，并有少数学得特别出色的，反之则不然。

3、软件开发与架构关系---超越“楼上楼下电灯电话”的思维

在上世纪50年代，对社会主义的梦想就是楼上楼下电灯电话，现在我们已经知道这种对电气化时代的抽象是远远不够的。但在软件上，很多人仍存在这种思维。譬如提软件要求时，总是提出在这个地方一点鼠标，就出现什么什么结果。认为这就是先进，这就是自动化。

就像很多时候，我们编写的软件，通常就是一个对话框，填几组数，然后一点按钮，执行结果。但真实的商用软件，几乎不存在这样的使用模式，因为这种模式太过简单，无法承载庞大的IO或复杂的功能。譬如两点之间联系，定义100种方法，也不过100种模式，但如果将之架构为两层，每层定义10种，就已经有了100种模式。

软件编制是一个系统工程，对于单一有利的用法，可能与其他操作模式不相容，更可能与整个实现逻辑不相容。甲方需要做的事情，是通过提出明确的需求，由乙方统一综合制定架构，包容这些功能，并实现操作的统一化和简单化。

架构是一系列相关的抽象模式，是一个系统的草图，用于指导大型软件系统各个方面的设计。通过架构的设计，达到可靠性、安全性、可伸缩性、可定制化、可扩展性、可维护性、客户体验等目标。

由于航天系统软件功能复杂，做大型航天软件架构需要彻底了解火箭各专业内涵，但由于航天院所大多数涉密的特点，在向外部单位开放专业时又存在一定的困难。这时候，尤其需要航天工程师具备一定的架构能力，提炼出模式特点，或者最起码有初步的对架构的识别和判断能力，以更好地参与甚至指导软件开发。

4、软件开发与通用性关系---失去易用失去很多，失去通用失去所有

很多人认为软件首要在易用性，满足当前需求才是最重要的，短期来看是正确的。但长期来看，片面追求易用，而忽略通用，是造成软件版本分化的最大原因，是导致专业工具水平难以持续提升的最大瓶颈，也是关键时候无法快速完成工作造成专业能力被质疑的幕后元凶。

通用性首先和架构有关，就像针对火箭，我们常想到的软件用法是先选火箭为几级，然后每级怎么配置。但实际上，很少有商用软件是这么用的。即使开始可以这么配置，它们的底层绝对不会这么写。软件编写的模式越来越趋向于代码与数据分离、逻辑与代码分离。逻辑不要写死在代码内部，否则，只要碰到一种新火箭构型，就等着外协人员来改代码，或者软件的死亡。很多软件不就是因为移植代价太大最终没人用了吗？很多专业就是因为原有软件无法用于新型号，只能在新型号再开发一次，来回低水平重复。

值得一提的是，通用只和开发难度矛盾，和易用并不矛盾。强大如STK，大家并不认为它难用，但没有人否认它难开发。通用的软件可以满足各类场景，既可以采用复杂但强大的专家模式，也可以采用简单易用的新手模式，甚至这种模式本身都是可以定制的。

软件是没有逻辑的，除非人为指定；软件是没有生命力的，如果用代码指定，一定要以数据为核心，在数据分类上创新，通过数据表达各类系统；在开发方法上创新，通过数据实现逻辑；在数据的可视化表达上创新，通过数据自定义界面。

5、软件开发与界面关系---文本在前界面在后

很多人认为软件就是界面，就是GUI。笔者极度反对这种观点，而支持文本在前界面在后。

首先，如果文本的工作量为1，那么界面的工作量就是10。对于商用软件，由于包装极好，界面可以包打一切，让人感受不到文本的存在。但对于我们使用的软件，一般很难达到这种水平，使劲够、跳起来够也未必能够到1，离界面的10还差了十万八千里，这时候追求10其实根本做不到，还不如老老实实把1做好。

其次，很多专业磨合一段时间后，对某一个问题的使用套路已经十分程序化。每次使用时打开一个界面，进入多层对话框修改某一处，运行得到结果，再退出软件显得过于麻烦，尤其是对于多次操作时。此时如果具备文本功能，采用脚本驱动很快得到结果，可能是一种更易用的模式。

第三，在工程单位，经常需要对数据进行各种各样的处理、组合和变换。譬如10万条打靶之类的需求，软件提前考虑的话容易实现，但如软件不够通用，且没有提前考虑，就无法完成这些需求。而如果软件具备文本功能，则编写一个简单脚本，就可以自然完成这些临时要求的功能。

从以上三个角度，笔者支持文本在前界面在后的用法。尤其是很多软件开发，输入输出接口还没有最终敲定，就开展编界面，最后的结果，只能是来回反复，消耗大家的情绪和耐心，是非常不可取的。

6、软件开发与平台关系---平台是软件水平发展到一定程度的产物

大家都爱大平台，但在软件建设水平不高时，应更注重基础建设积累工作，处理好大与小的关系。一口吃不成个胖子。

从小到大：从小型软件入手，形成、建立和完善软件过程化开发机制，最终将成果用于指导大型平台软件建设。

变大为小：将软件进行模块化划分，形成不断完善的通用模块库，持续积累能力，实现从代码级到模块级的提升。

聚小成大：详细梳理软件间接口，通过约定接口标准，形成软件互通和数据流动机制，实现软件的聚合。

另外，二次开发软件在当前软件建设中分量越来越重。商用软件为达到通用，使用了复杂的抽象机制和大量组件库，学习成本较高。而商业软件在火箭工程中应用有独特特点：首先是用到的组件库并不多，其次是对于很多问题会使用较为独特的组件库，通用书籍不涵盖此部分内容，目前多依赖老员工的口头传授或新员工的自我体会。因此建设目标为“文档化、案例化、可测化”。文档化指建立商用软件使用规范，案例化是指形成针对本专业独特问题建立标准案例，此案例具备明确的输入输出，从而实现开发和使用正确性的可测化。

7、软件开发与持续改进关系---建立软件分级体系

限于经费、进度等，开发总是会碰到各种各样的瓶颈，理想软件开发时间太长，另一方面，简单实现既定功能是简单的，但长此以往，水平难以提高。在这两个的中间需要建立一套连续的分级体系，每次开发均应致力于软件本身或多个模块在分级体系中的提升。

可将软件开发定义为多个级别。软件开发的目标是最高级别（商业化级），在开发水平、经费和进度限制下，一般无法直接达到此层次，但应谋求分级体系中的提升。

此外，在软件开发时，应谨守“模块化、标准化、体系化”思想，模块化指软件内部模块和外部接口的划分；标准化指各型号、各单位间数理后模块、接口的归类和统一；体系化为对软件需求体系的梳理，形成完备的、层次化的软件树。

8、软件开发与维护使用关系---易用性和组织保障双管齐下

软件是用出来的，一方面要持续提升易用性，另外还需通过组织保障，双管齐下。

如某些软件是通过外协高校开发，开发后甲方修改能力一般，是软件维护中的最大瓶颈。如果在开发过程中，发现存在技术水平高，软件能力出色的同学，通过强有力措施引进人才，则对于软件发展具有较大的功效。

另外，在软件开发时，组织要做好型号之间统筹，尤其是在软件架构存在缺陷，易用性尚未达到理想境地时。确保各型号广泛使用软件，共同维护软件，而不是向多个分支发展，无法形成合力。

第三，技术上，可以布置某些场景，或在某些型号上提出某些问题，创造需求，有意地引导软件发展；组织上，对部分发展较好的软件编写或维护者进行奖励。鼓励软件持续建设，起到带头示范作用。

往期文章：

软文

《设计和仿真有什么区别？》