请选择 进入手机版 | 继续访问电脑版
设为首页收藏本站

CCOSE论坛

 找回密码
 立即注册
查看: 59|回复: 1

赵献民:系统工程的玻璃笼子

[复制链接]

316

主题

435

帖子

1609

积分

论坛元老

Rank: 7Rank: 7Rank: 7

积分
1609
发表于 2018-2-4 08:46:57 | 显示全部楼层 |阅读模式
系统工程的玻璃笼子

2017-12-26 赵献民

原载于:系统工程 (微信公共号)


赵献民,某研究所航空电子系统设计师,研究员级高级工程师。长期从事人机工程与人机接口设计,航空电子系统设计,以及系统顶层需求研究、系统工程方法论和架构应用研究。

本文所说的“系统工程的玻璃笼子”,是看不见的,却实实在在禁锢着系统工程。让人们只能在笼子外面围观系统工程,或者赞叹、或者批评、或者质疑,而不是把系统工程从笼子里面解放出来,让它发挥影响,释放其潜在的、巨大的能量。



1. 对系统工程的认识

1.1热力学第二定律

热力学第二定律即熵增大原理,揭示了自然界的一个普遍规律,可以用来帮助理解系统工程。熵即系统的混乱程度。非孤立系统的熵减小需要外部能量投入。举个例子。假如家里的房间不打扫,会越来越乱。要想让房间重新变得整洁,就需要花精力打扫。打扫房间所花费的人的精力,对于需要打扫的房间来说就是外部能量投入。
如果任由一个系统自由发展,系统的熵必然持续增大。如果要控制系统的熵,必须以能量投入为代价。系统工程就是这样的一套方法:它力争以最小的能量代价控制人造系统的熵,并使其发展聚焦于既定的目标。系统工程的生命周期管理本质目的之一也是为了控制熵,使项目不至于陷入难以控制的混乱状态。

1.2康威定律的魔咒

系统工程中所说的“系统”可以说是“客体系统”,它是以提供产品或服务为目的而人为构造的相互关联的元素的集合。与“客体系统”相对应的是“主体系统”,它是构造客体系统的主体,是人或者组织(企业)。
对著名的康威定律可以理解为,作为客体系统的产品或服务,其架构是主体系统架构的反映。
康威定律提醒我们,要研究如何更有效地构造一个客体系统,必须同时研究需要什么样的主体系统。因为“能量代价”是要由主体系统承担的,而且主体系统的缺陷必然反映在客体系统上。

1.3系统工程推进工作现状

要评估系统工程推进工作的现状,首先要选择评价现状的尺子,也就是要考察系统工程工作的目的和评价标准。
INCOSE系统工程手册4.0版(机械工业出版社)提出“系统工程以提供满足用户需求的高质量产品为目的”,这显然是站在用户视角的观点。如果站在主体系统(企业)视角,应该是“通过提升研发质量和效率、有效控制风险,以提升企业的核心竞争力为目的”。
不考虑代价谈高质量产品是不现实的。企业生存发展是提供高质量产品的一个前提。系统工程有助于使企业(主体系统)的利益与用户的利益达成统一。

基于以上观点提出系统工程工作效果的评价标准:

  • 是否有效提升了研发质量。广义的质量包括产品的竞争力;
  • 是否有效提升了研发效率;
  • 是否有效控制了研发风险。

采用以上标准,可以评估或者自我审视一下本单位或所熟悉的单位系统工程工作效果。目前国内的现状也许不尽如人意。

我们有必要考虑一下这其中的原因,也许包括以下方面:

  • 科研团队对系统工程掌握的不够,需要更多的培训;
  • 工具链不完整,如需求管理工具、系统建模工具、仿真工具等;
  • 用户不按照系统工程的正确方法管理项目;
  • 首个应用系统工程的项目承受双重压力,难以应付。企业发展总是从简单系统研发到复杂系统研发,从单一项目到多项目并行。发展到一定阶段,终于意识到原来的方法再也应付不下去了,希望依靠系统工程解决发展中的矛盾。可是推进系统工程是有代价的,包括经济代价和员工的精力代价。在研发方面的压力没有减小的情况下,推进系统工程的代价就是“额外”代价,从哪个项目开始试行系统工程,这经常是让企业难以决策的一个问题。企业要迈过这个门槛非常不容易,这就是所谓的“双重压力”;
  • 组织架构和工作流程不匹配;
  • ……

除了上面提到的,也许还有很多原因。但是笔者认为,关键原因也许是另外两个:方法论体系不完整;主体系统有缺陷。

2. 什么是研发活动

系统工程是方法论的局部而非必要的整体。不能对方法论“断章取义”地“拿来主义”,应该全面了解先进的方法论体系,按需剪裁和扩展,聚焦于解决我们的问题。另外,需要解决“主体系统”的缺陷。

为了说清楚这两个问题,需要从最基本的概念谈起。INCOSE系统工程手册中说系统工程是“……结构化的研发流程”,那么“流程”是什么呢?也许可以说“流程”是对活动的有序组织。那么,“活动”又是什么呢?也就是说,对于系统研发来说,研发活动是什么?

研发活动的本质如图1所示,是在问题空间中“认识问题”、“描述问题”和“确认问题” ;在方案空间中“分析问题”、“传递问题”和“解决问题”。

1

1

图1 问题空间和解决方案空间

事实上对“什么是研发活动”却有不同的观点,或者可以说存在另外的现实。现实之一是把“部门的业务包”(如图2)作为研发活动。所说的“部门”在某些科研机构中也称为“专业”,两者在本质上是一样的。在项目执行过程中,工作计划总是按照部门逐层分解下达。事实上所谓的“计划”通常是模糊的,不能清晰完整地描述问题空间。


2

2

图2 将部门的业务包作为研发活动
用户的真正需要是服务,而服务主要由客体系统的功能承载和体现。将部门的业务包作为研发活动的问题在于,客体系统的功能会被部门之间的界面割裂。部门之间往往既争名夺利又相互推诿。部门之间的业务关系复杂,业务低效,难以界定对问题空间中的“问题”的责任主体。
现实之二是将系统元素(SE)的“描述包”作为研发活动(如图3)。图3解决方案空间椭圆中的方框表示逐级细分的系统元素。提供给用户的客体系统是一个整体,这个整体承载着用户所需要的功能。功能往往是有多个系统元素共同支撑的。将系统元素的描述包作为研发活动,功能(问题)会被系统元素之间的界面割裂。研发过程中在系统元素之间传递数据的工作量巨大,衰减和畸变严重。此处所说的“传递数据”的一种形式是传递需求使用的规范。
b3.jpg

图3 将系统元素的描述包作为研发活动

分析了上面两种定义研发活动的情况后,是否可以考虑一个问题:有没有一种理想的情况,将问题空间和解决方案空间中的问题划分为可管理的小块(如图4),将每个“小块”作为一项科研活动,为每个“小块”配置人力资源。这也许是最简单高效的方式。因为每个“小块”都直接“面向服务”或者说对应具体的功能,且块之间的关系是可以依靠一套方法给出明确定义。

b4.jpg

图4 将空间划分为“可管理的小块”
可是,如何将问题空间和解决方案空间划分为可管理的小块呢?在讨论这个问题之前,先扒一扒两个概念:面向过程和面向对象。
将“科研流程”视为科研活动以及科研活动的顺序,本质上是面向过程的方法。当科研活动非常复杂时,面向过程的方法是不适用的,而应该增加面向对象的方法。对于这个认识,《大象》一书中有几段非常精彩的陈述:
  • 面向过程的分析方法是找到过程的起点,然后顺藤摸瓜,分析每一个部分,直至达到过程的终点。
  • 将世界视为过程的这个方法本身蕴含着一个前提假设,即这个过程是稳定的……只可惜我们这个世界从来都不是一成不变的。
  • 并非面向过程的方法不正确,只是它应对复杂事物时面临了太多的困难。
  • 面向对象的方法与面向过程的方法根本的不同,就是不再把世界看作是一个紧密关联的系统,而是看成一些相互独立的对象。每个对象都只与有限的其他对象有关系,在分析对象时需要考虑的信息量就大大减少。

接下来看看认知域的四个象限(图5)。已知的是有限的,仅仅是一个小角落 ;未知的是无限的,是事物的绝大部分,事实上第三象限是无边界的。面向过程的方法基于这样一个“世界观”假设的前提,即认为事物之间有确定的因果关系,其关系和行为是稳定的、已知的或可知的(即可预测的)。但事实并非如此。当所面对的系统越来越复杂、越来越接近真实的世界时,就会发现面向过程的方法已经无法应付了。面向过程的方法试图将过程和关系定义清楚,并期望系统按照确定的过程和关系运行。但现实世界并非如此,过程和关系往往是不稳定和不确定的。“面向对象的流程”比“面向过程的流程”更适应不确定和不稳定的关系。

b5.png

图5 认知域

对于软件领域所说的“过程”和“对象”大家都是熟知的了,可是对于科研活动来说的“对象”是什么呢?结合对问题空间和解决方案空间的认识,可以说科研活动的“对象”有三种形态:问题、活动和文件(图6)。
b6.png

图6 研发活动的对象

系统工程定义了研发流程(图7),但没有定义研发活动及其关系,没解决研发活动的结构化定义问题,这也许是它落地困难的重要原因。

b7.jpg

图7 结构化的流程

我们就是要尝试通过面向对象的方法将研发活动作结构化定义,为系统工程提供必要的支持。结构化的研发活动对应结构化的设计文件体系,结构化的设计文件体系支持系统工程落地。


3. 研发活动的结构化

说到这里,不得不再讨论另一个重要的概念——结构化。

结构化概念:在对事物按正交维度分类和描述基础上,用一般性方法解决问题的方法。其优势在于:

  • 按正交维度分类(图8)的优点是分类完整且无冗余;
  • 一般性方法是适用于特定类别问题的通用解决方法,而不是对特定问题的方法。

与结构化方法相对应的“非结构化”则是针对特定事物用特殊方法解决问题的方法。
结构化的优点:
  • 因为问题类别可穷举解决方法也可穷举且易于复用;
  • 描述事物的数据(广义)易维护;
  • 描述事物的数据(广义)可追溯。


b8.png

图8 对事物分类的维度


结构化的基础是对事物的分类方法。对事物的分类方法是结构化最重要的基础。

(美国)国防部体系结构框架(DoDAF)可以支持对研发活动的结构化定义。DoDAF中有几句非常重要的描述引用如下:
  • DoDAF “为文档设计和开发决策提供一种结构化的方法,来为系统工程提供支持”;
  • “DoDAF2.0为系统工程过程提供广泛的体系结构支持”;
  • “DoDAF模型从利益攸关者视角将问题空间分解为可管理的小块,并进一步定义为DoDAF模型”。


b9.jpg

图9 (美国)国防部体系结构框架


“概念、结构、行为、关系”是对事物分类的四个基本维度(图10)。DoDAF定义的八个视角52个模型是一种细分维度(图11),可以对问题空间作进一步细分,细分为“可管理的小块”。让人们可以在52维空间里上看、下看、左看、右看……,原来每个视图都很简单。

以DoDAF支持系统工程,两者共同构成了更完整的方法论体系。


b10.jpg

图10 对事物分类的维度


b11.jpg

图11 四维与52维

再回到前面的问题,DoDAF能把问题分解为“可管理的小块”吗?是怎么做到的?图12就是对DoDAF模型对应的“问题的小块”尝试的理解。而图13是与图12对应的DoDAF模型较正式的描述。需要说明的是,图12和图13是笔者基于自己的业务特点所作的理解和剪裁,不必深究其正确性。尤其是各模型中的关联线,笔者本人也认为不是绝对的。实际上笔者认为DoDAF模型之间的关系恰恰体现了并行流程而不是完全串行流程的特点。大型项目往往需要几百几千人多年协作才能完成,如此复杂系统研发工作,怎么可能是完全串行的呢?!

b12.jpg
图12  “问题的小块”

b13.jpg
图13 DoDAF模型(剪裁)




4. 元文件和集成文件

为了进一步说清楚工程实践中如何操作,笔者妄自“编造”了两个术语:“元文件”和“集成文件”。

对于问题空间中的问题和解决方案空间中的问题,按照结构化方法将这些问题划分为“可管理的小块”,对每一小块的描述就是一份“元文件”。

在系统研制过程中,为了特定利益攸关者使用方便,将元文件打包并作整体描述的文件称为“集成文件”。例如为了开展方案评审,提供给评审专家的方案报告是集成文件;为了向下层分包商传递系统元素的需求,提供给相应分包商的规范也是集成文件。用集合的思想理解元文件和集成文件之间的关系可以表示成图14。


b14.jpg
图 14元文件与集成文件的集合

每个DoDAF模型可以对应一类元文件,对应问题的“小块”。元文件全集是对项目定义的完整数据集。集成文件通过引用元文件的形式建立元文件与集成文件之间的追溯关系。一份元文件可以被多份集成文件引用。也就是元文件“一处定义,多次使用”。

设计活动和元文件都依靠DoDAF的各模型组织和描述。结构化的设计活动划分是结构化的元文件体系的基础。每份元文件在“范围”一章均说明对应哪个DoDAF模型,甚至文件的编号中都可以带有DoDAF模型名称,这样就确定了该元文件在整个文件体系中的地位和作用。

可以以“三棵树” (图15)作为“导航地图”组织大部分元文件:

  • 作战活动分解树OV-5a;
  • 系统功能分解树SV-4;
  • 系统元素分解树SV-1。


b15.jpg

图15 组织元文件的“三棵树”及映射矩阵

设计文件是设计活动的交付物。结构化的设计文件体系等同于结构化的设计活动。构建结构化的设计文件体系,实际上也是构建结构化的设计流程。

这样作的好处是每个设计员:

  • 专注于特定的设计活动;
  • 专注于特定的问题;
  • 专注于特定类型的设计文件;
  • 专注于特定的表达方式;
  • 专注于特定的技术。

设计员容易上手。工作成果可非常方便地复用。既利于技术进步,又利于人才成长。对于多项目并行情况下提升工作效率更是意义重大。

元文件“一次定义,多次使用”。结构化的设计文件是可维护且方便维护的;可以方便地组合成集成文件(如组合形成方案报告、分发给成品厂所的规范、用户资料等);文件更改的影响范围非常清晰,易于传递变更,易于控制状态。

对应“基于模型的系统工程”,“元文件”其实就是模型。

将项目分解为面向对象的研发活动,其积极意义在于,将人或团队的职责部署到问题上,而不是将界面不清的任务部署到“部门和人”上;不是将产品开发责任部署到“部门和人”上。


b16.jpg

         5. 总结         

最后回到讨论的题目,主体系统的研发活动架构,就是那个“系统工程的玻璃笼子”吧?对对象(问题、活动和文件)作结构化分类,是改造主体系统研发活动架构的基础。面向对象配置人力资源(本质上是配置人员的职责而不是配置人员),以此改造研发活动架构。既利于项目推进,又利于技术积累。可应对多项目并行。

最后,有必要强调一下,分类法是组织数据的核心,是重中之重!


系统工程公众号是由一群系统工程爱好者所发起,目的是推进系统工程在中国应用,纯粹公益性质。
系统工程爱好者协会(CCOSE)是系统工程的大本营,成立于2014年,协会定期举办系统工程沙龙,并及时发布系统工程工作成果,欢迎更多系统工程爱好者参与到系统工程推进工作中,并踊跃投稿。
长按二维码关注微信号,进入子菜单查看分类文档,或回复“目录”获取文档总目录。
有问题或投稿请加管理员微信:SEC_heq,投稿请注明“投稿”。
获取CCOSE信息请进入www.ccose.org
b17.jpg

回复

使用道具 举报

316

主题

435

帖子

1609

积分

论坛元老

Rank: 7Rank: 7Rank: 7

积分
1609
 楼主| 发表于 2018-2-4 09:21:18 | 显示全部楼层
阳洋:
首先文章的名字我就想了半天,为什么叫“系统工程的玻璃笼子”?
我理解该文的主旨是要说明“创新活动组织过程”如何应用系统化工程的方法论进行思考和设计。这样理解不知对否?
看到了,“玻璃笼子”在文前开篇处。谢谢!
从笼子里解放出来,发挥巨大的作用。。。我非常感兴趣。
比如应用于企业或区域商业经济的咨询的方案设计社会化系统规划与运营?

赵献民:结尾处也有呼应
    系统工程不是用来看的,是要拿来干的。
    干!

   
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

 

QQ|京ICP备17005959号|IAC-16|Archiver|手机版|小黑屋|CCOSE论坛    

GMT+8, 2018-2-23 00:21 , Processed in 0.082750 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表