赵献民：系统工程的玻璃笼子
| 赵献民，某研究所航空电子系统设计师，研究员级高级工程师。长期从事人机工程与人机接口设计，航空电子系统设计，以及系统顶层需求研究、系统工程方法论和架构应用研究。 |
本文所说的“系统工程的玻璃笼子”，是看不见的，却实实在在禁锢着系统工程。让人们只能在笼子外面围观系统工程，或者赞叹、或者批评、或者质疑，而不是把系统工程从笼子里面解放出来，让它发挥影响，释放其潜在的、巨大的能量。
|
1. 对系统工程的认识
|
1.1热力学第二定律
1.2康威定律的魔咒
1.3系统工程推进工作现状
基于以上观点提出系统工程工作效果的评价标准：
- 是否有效提升了研发质量。广义的质量包括产品的竞争力；
- 是否有效提升了研发效率；
- 是否有效控制了研发风险。
采用以上标准，可以评估或者自我审视一下本单位或所熟悉的单位系统工程工作效果。目前国内的现状也许不尽如人意。
我们有必要考虑一下这其中的原因，也许包括以下方面：
- 科研团队对系统工程掌握的不够，需要更多的培训；
- 工具链不完整，如需求管理工具、系统建模工具、仿真工具等；
- 用户不按照系统工程的正确方法管理项目；
- 首个应用系统工程的项目承受双重压力，难以应付。企业发展总是从简单系统研发到复杂系统研发，从单一项目到多项目并行。发展到一定阶段，终于意识到原来的方法再也应付不下去了，希望依靠系统工程解决发展中的矛盾。可是推进系统工程是有代价的，包括经济代价和员工的精力代价。在研发方面的压力没有减小的情况下，推进系统工程的代价就是“额外”代价，从哪个项目开始试行系统工程，这经常是让企业难以决策的一个问题。企业要迈过这个门槛非常不容易，这就是所谓的“双重压力”；
- 组织架构和工作流程不匹配；
- ……
|
2. 什么是研发活动
|
系统工程是方法论的局部而非必要的整体。不能对方法论“断章取义”地“拿来主义”，应该全面了解先进的方法论体系，按需剪裁和扩展，聚焦于解决我们的问题。另外，需要解决“主体系统”的缺陷。
为了说清楚这两个问题，需要从最基本的概念谈起。INCOSE系统工程手册中说系统工程是“……结构化的研发流程”，那么“流程”是什么呢？也许可以说“流程”是对活动的有序组织。那么，“活动”又是什么呢？也就是说，对于系统研发来说，研发活动是什么？
研发活动的本质如图1所示，是在问题空间中“认识问题”、“描述问题”和“确认问题” ；在方案空间中“分析问题”、“传递问题”和“解决问题”。
事实上对“什么是研发活动”却有不同的观点，或者可以说存在另外的现实。现实之一是把“部门的业务包”（如图2）作为研发活动。所说的“部门”在某些科研机构中也称为“专业”，两者在本质上是一样的。在项目执行过程中，工作计划总是按照部门逐层分解下达。事实上所谓的“计划”通常是模糊的，不能清晰完整地描述问题空间。
分析了上面两种定义研发活动的情况后，是否可以考虑一个问题：有没有一种理想的情况，将问题空间和解决方案空间中的问题划分为可管理的小块（如图4），将每个“小块”作为一项科研活动，为每个“小块”配置人力资源。这也许是最简单高效的方式。因为每个“小块”都直接“面向服务”或者说对应具体的功能，且块之间的关系是可以依靠一套方法给出明确定义。
- 面向过程的分析方法是找到过程的起点，然后顺藤摸瓜，分析每一个部分，直至达到过程的终点。
- 将世界视为过程的这个方法本身蕴含着一个前提假设，即这个过程是稳定的……只可惜我们这个世界从来都不是一成不变的。
- 并非面向过程的方法不正确，只是它应对复杂事物时面临了太多的困难。
- 面向对象的方法与面向过程的方法根本的不同，就是不再把世界看作是一个紧密关联的系统，而是看成一些相互独立的对象。每个对象都只与有限的其他对象有关系，在分析对象时需要考虑的信息量就大大减少。
接下来看看认知域的四个象限（图5）。已知的是有限的，仅仅是一个小角落 ；未知的是无限的，是事物的绝大部分，事实上第三象限是无边界的。面向过程的方法基于这样一个“世界观”假设的前提，即认为事物之间有确定的因果关系，其关系和行为是稳定的、已知的或可知的（即可预测的）。但事实并非如此。当所面对的系统越来越复杂、越来越接近真实的世界时，就会发现面向过程的方法已经无法应付了。面向过程的方法试图将过程和关系定义清楚，并期望系统按照确定的过程和关系运行。但现实世界并非如此，过程和关系往往是不稳定和不确定的。“面向对象的流程”比“面向过程的流程”更适应不确定和不稳定的关系。
图6 研发活动的对象
系统工程定义了研发流程（图7），但没有定义研发活动及其关系，没解决研发活动的结构化定义问题，这也许是它落地困难的重要原因。
图7 结构化的流程
|
3. 研发活动的结构化
|
说到这里，不得不再讨论另一个重要的概念——结构化。
结构化概念：在对事物按正交维度分类和描述基础上，用一般性方法解决问题的方法。其优势在于：
- 按正交维度分类（图8）的优点是分类完整且无冗余；
- 一般性方法是适用于特定类别问题的通用解决方法，而不是对特定问题的方法。
- 因为问题类别可穷举解决方法也可穷举且易于复用；
- 描述事物的数据（广义）易维护；
- 描述事物的数据（广义）可追溯。
图8 对事物分类的维度
- DoDAF “为文档设计和开发决策提供一种结构化的方法，来为系统工程提供支持”；
- “DoDAF2.0为系统工程过程提供广泛的体系结构支持”；
- “DoDAF模型从利益攸关者视角将问题空间分解为可管理的小块，并进一步定义为DoDAF模型”。
图9 （美国）国防部体系结构框架
“概念、结构、行为、关系”是对事物分类的四个基本维度（图10）。DoDAF定义的八个视角52个模型是一种细分维度（图11），可以对问题空间作进一步细分，细分为“可管理的小块”。让人们可以在52维空间里上看、下看、左看、右看……，原来每个视图都很简单。
以DoDAF支持系统工程，两者共同构成了更完整的方法论体系。
图10 对事物分类的维度
图11 四维与52维
再回到前面的问题，DoDAF能把问题分解为“可管理的小块”吗？是怎么做到的？图12就是对DoDAF模型对应的“问题的小块”尝试的理解。而图13是与图12对应的DoDAF模型较正式的描述。需要说明的是，图12和图13是笔者基于自己的业务特点所作的理解和剪裁，不必深究其正确性。尤其是各模型中的关联线，笔者本人也认为不是绝对的。实际上笔者认为DoDAF模型之间的关系恰恰体现了并行流程而不是完全串行流程的特点。大型项目往往需要几百几千人多年协作才能完成，如此复杂系统研发工作，怎么可能是完全串行的呢？！
|
4. 元文件和集成文件
|
为了进一步说清楚工程实践中如何操作，笔者妄自“编造”了两个术语：“元文件”和“集成文件”。
对于问题空间中的问题和解决方案空间中的问题，按照结构化方法将这些问题划分为“可管理的小块”，对每一小块的描述就是一份“元文件”。
在系统研制过程中，为了特定利益攸关者使用方便，将元文件打包并作整体描述的文件称为“集成文件”。例如为了开展方案评审，提供给评审专家的方案报告是集成文件；为了向下层分包商传递系统元素的需求，提供给相应分包商的规范也是集成文件。用集合的思想理解元文件和集成文件之间的关系可以表示成图14。
每个DoDAF模型可以对应一类元文件，对应问题的“小块”。元文件全集是对项目定义的完整数据集。集成文件通过引用元文件的形式建立元文件与集成文件之间的追溯关系。一份元文件可以被多份集成文件引用。也就是元文件“一处定义，多次使用”。
设计活动和元文件都依靠DoDAF的各模型组织和描述。结构化的设计活动划分是结构化的元文件体系的基础。每份元文件在“范围”一章均说明对应哪个DoDAF模型，甚至文件的编号中都可以带有DoDAF模型名称，这样就确定了该元文件在整个文件体系中的地位和作用。
可以以“三棵树” （图15）作为“导航地图”组织大部分元文件：
- 作战活动分解树OV-5a；
- 系统功能分解树SV-4；
- 系统元素分解树SV-1。
图15 组织元文件的“三棵树”及映射矩阵
设计文件是设计活动的交付物。结构化的设计文件体系等同于结构化的设计活动。构建结构化的设计文件体系，实际上也是构建结构化的设计流程。
这样作的好处是每个设计员：
- 专注于特定的设计活动；
- 专注于特定的问题；
- 专注于特定类型的设计文件；
- 专注于特定的表达方式；
- 专注于特定的技术。
设计员容易上手。工作成果可非常方便地复用。既利于技术进步，又利于人才成长。对于多项目并行情况下提升工作效率更是意义重大。
元文件“一次定义，多次使用”。结构化的设计文件是可维护且方便维护的；可以方便地组合成集成文件（如组合形成方案报告、分发给成品厂所的规范、用户资料等）；文件更改的影响范围非常清晰，易于传递变更，易于控制状态。
对应“基于模型的系统工程”，“元文件”其实就是模型。
将项目分解为面向对象的研发活动，其积极意义在于，将人或团队的职责部署到问题上，而不是将界面不清的任务部署到“部门和人”上；不是将产品开发责任部署到“部门和人”上。
|
5. 总结
|
最后回到讨论的题目，主体系统的研发活动架构，就是那个“系统工程的玻璃笼子”吧？对对象（问题、活动和文件）作结构化分类，是改造主体系统研发活动架构的基础。面向对象配置人力资源（本质上是配置人员的职责而不是配置人员），以此改造研发活动架构。既利于项目推进，又利于技术积累。可应对多项目并行。