本文11000余字，预计需要20分钟。
首先说明一下，本文中所有蓝色字体的内容都是参考性的，不读或不细读几乎不影响对本文的理解，您完全可以跳过去不看。
| 写在前面的话 中国系统工程爱好者协会（CCOSE）的系统工程爱好者沙龙是个非常好的平台。虽然CCOSE是个松散的“民间组织”（依托中国系统工程学会科普工作站），但是其跨行业的特点、开放包容的特点和参与者们的积极进取、热心交流的氛围都给人非常好的体验。我早就有个想法，想在系统工程爱好者沙龙作一次线下交流。一是创造更多交流的机会，二是我作为这个组织的受益者，也真心想要回馈这个组织。哪怕不能提出有价值的理论和方法，仅就我本人从事科研实践的经历和思考，如果能提出一些有价值的问题供大家一起思考，也应该是不无益处的。这件事正式策划是2019年8月19日，约好后我抓紧时间编写交流文档，作交流准备，刚好赶上月末事情也多，竟然能在8月31日完成交流，应该可以说是快节奏的！ 参加线下交流的人不是很多。可能是因为交流的题目取的不好（原来在通知中称为“技术识别、描述与系统工程”），没有准确、完整地反映交流的主题。也许让人觉得有些偏离系统工程这个大方向，侧重于技术管理。技术管理往往被认为是单位领导层的职责，不太容易被一线的系统工程师关注。这是我的一些猜测。看来前期策划和介绍还是很重要的。因为各种原因难以参加线下交流的同仁，我们说好了再找机会，只要有意愿，总是可以创造机会见面交流的。 交流前，我也有些顾虑，担心自己讲不好，也担心大家不感兴趣。但是这种顾虑在交流开始后很快就烟消云散了。原计划一个半小时讲解，一小时讨论。结果是边讲解边讨论，三个半小时才好不容易刹住车。刚刚开始交流不久，随着首次互动讨论的开始，会场热度迅速上升。大家几乎是争先恐后地抓紧时间参与讨论。会后还“捉对”讨论了一会儿。交流达到了预期目的，了解到OPM软件可能适用于解决功能逻辑关系描述问题。 会后东道主索为公司何强请大家共进晚餐。很多人因为有事情要处理没参加。大家往往是上有老下有小的，周末甚至比工作日还累。次日有的人自家娃儿们新学年开学，当爹的还要做好后勤工作。都不容易！晚餐只有几个人参加。相见恨晚的、一见如故的“老”朋友，找个清净的店儿。当然是杂谈式的聊天、讨论，算是线下交流的加餐吧。聊到很晚，非常开心！聊到了……（此处删去两千字）。 晚上回到宾馆，发现线上还热闹着。微信又多了几位好友，各有关心的问题，讨论一直到11点半左右。早晨6点多起床，发现我们亲爱的沙龙召集人温跃杰已经把这次活动的宣传稿初稿发给我了，真是精力充沛、干劲儿十足的家伙！好吧，我也趁着热乎劲，对稿子提出了一些修改建议反馈回去。接着整理昨天讨论的一些重要问题，分享到“系统工程沙龙”群里面，弥补一下无法参加线下讨论的热心同仁的遗憾。这再次引起大家讨论的热情。 好些朋友索取交流的PPT，还有几位同仁建议我把交流的内容写成文章，进一步扩大交流的范围，提高交流效果。我推脱“精力有限，写文章太累了” 。不过想起来建议是对的。刚好返程火车上近4个小时没事做，把这时间利用一下吧。否则即使看了我的PPT，估计也只能猜测到三两分交流的内容，因为现场交流的信息量很大，PPT只有十几页，里面的文字也很少。以前提到写文章往往是把技术问题写成正式的论文，这次尝试一下写成叙议结合的“杂谈”。实际上我也不知道这算是什么文体，或许叫“胡说体”更合适。信马由缰地写吧，也许这样写的东西读起来会轻松些，反而不容易犯困。 |
这次交流，开篇先热热场，我提出一个观点：技术体系是燃料，系统工程是引擎，能量在两者结合中爆发。以活塞式发动机和燃气轮机对比为例，两者的能量转换效率是不同的，极限功率差别也很大。重型装备就需要重量级的发动机，反之轻型装备可能完全不必使用重量级的发动机。当然这是另外一个话题，超出了本次交流的范围，不作展开说明了。这里重点想要说的是，不管是活塞式发动机，还是燃气轮机，没有燃料都是不行的。就是说，要构建人造系统，就必须要掌握相应的专业技术。构造复杂的人造系统往往需要用到复杂的专业技术体系。
图1 不同类型引擎的差别
接下来步入主题，说明本次交流的概述。系统工程对提升企业竞争力具有战略性意义。但是系统工程难以直接提升企业的专业技术能力。即使是非常出色的系统工程咨询公司也无力直接承担系统研发，道理就在于此。提升企业竞争力是个“系统性问题”，不能指望通过单一的手段解决。那么我们就来一起思考一下，是否有更完整的解决方案？——当然这个方案里面一定是包括系统工程的。
下面将要介绍的就是如何将技术体系与系统工程结合起来，共同促进系统研发，并提升企业竞争力。
罗列一些关于知识的观点。算是对当天所讨论的主题的必要性做个交代：
*知识资产是技术型企业竞争力的基础；
*企业的知识资产不是个人私产，需要被显性化描述和管理；
*复杂系统研发所需要的知识体系往往是庞大的。越是庞大，越要避免庞杂。只有对知识体系作结构化描述才能作到完整描述，才能对其有效管理；
*组织的知识资产在系统工程生存周期过程、活动中发挥作用；
*对技术体系的结构化描述是界定部门及人员技术责任的基础，是技术责任履职评价的基础，是制定企业技术发展战略的基础。
对这些观点没有做过多的解读，看起来PPT内容投影出来，老司机们基本都是心领神会。仅仅对人员的技术责任问题作了一点儿补充。在企业中，常见的一种现象是特定的项目有明确的责任人，项目中的具体工作一般也有明确的责任人。但是，对于企业有竞争力具有重要意义的技术体系，其中的各项技术往往没有明确的责任人。即使部门和人员的责任规定了技术责任范围，这些范围也往往是模糊的。真要是较真，说说某个具体的技术该谁负责，估计多半难以达成一致的意见。没有明确的责任人，就意味着可以没人为技术负责。如果一个企业的部门和人员都是只为项目负责，而不为技术负责，这对技术型企业意味着什么？不言而喻！
接下来引用《产品研发管理》一书作者周辉的一句话“建议这些公司马上进行技术分类、技术梳理、核心技术与关键技术的识别”。在这本书里面，周辉将技术分为四类：核心技术、关键技术、通用技术和一般技术。说明了界定技术类别所依据的原则。周辉说得很清楚，核心技术决定了企业是否拥有竞争优势，关键技术不可替代。当然，不等于通用技术和一般技术不重要。或许可以将其理解为，通用技术和一般技术是企业的及格线，如果没有达到及格线，何谈卓越？何谈竞争优势？
图2 技术类别及发展战略
引述周辉的话，目的不在于对他的话作详细解读，而是引出本次交流的主题：既然要“马上进行技术分类、技术梳理、核心技术与关键技术的识别”，那么，到底该如何识别？如何梳理？周辉在《产品研发管理》一书中并没有说明。
我高度认同周辉的观点，认同他关于技术识别与技术梳理重要性的阐述。我也觉得，技术识别与技术梳理是一个企业做知识资产积累和发展规划的基础。所以，如何识别技术、如何梳理技术体系，这个问题必须回答清楚，并且给出可以直接指导企业实践的方法。
要把技术识别和技术体系梳理的事情彻底扒清楚，就不得不扣一扣到底什么是“技术”。下面上菜，看看大师们的观点。
*法国哲学家狄罗德：技术是为了完成某种特定的目标而协同动作的方法、手段和规则的完整体系
*世界知识产权组织（1977）：技术是制造一种产品的系统知识，所采用的一种工艺或提供的一项服务，不论这种知识是否反映在一项发明、一项外形设计、一项实用新型或者一种植物新品种，或者反映在技术情报或技能中，或者反映在专家为设计、安装、开办或维修一个工厂或为管理一个工商企业或其活动而提供的服务或协助等方面
*宋健（曾任中国工程院院长）：技术是为某个目的共同协作组成的各种工具和规则体系。技术是有目的的；技术是通过广泛的协作完成的；技术的首先表现形式为生产工具、设备；技术的另一种表现形式为规则，即生产使用的工艺、方法、制度等知识；技术是成套的知识体系
哲学家的定义很有哲学家的范儿，简明、严谨、抽象。宋健给出的定义也很严谨，逻辑清晰。相比之下，世界知识产权组织的定义算个“对照组”吧，似乎很全面，但是显得冗长。
不过，要直接指导我们做技术识别和技术体系梳理，看上面的定义似乎还是摸不着头脑。所以，我就斗胆按照自己的理解也给出了一个定义：
技术是指导实践活动的知识；
技术是关于某种形式或方法对解决实践问题（包括实现特定功能）是否有效或有益的认识。
这两句话用逻辑关系图描述是这个样子的（图3）：
图3 技术的定义
解释一下，首先，技术属于知识。图中的“技术”与“知识”之间实线和空心三角箭头组合的符号是表示“泛化”逻辑符号，这与统一建模语言（UML）使用的符号是一致的。另外，技术是关于某种形式或方法对解决实践问题是否有效或有意的认识。展开来讲，技术可能表现为某种形式，例如用玻璃制作凸透镜用来当做放大镜，这是以形式表现出来的技术；技术也可能表现为某种方法，比如钻木取火是以方法表现出来的技术。第三，如果对解决某种实践问题是有效的，那么这种形式或方法可以称为技术；其反逻辑是，如果对解决某种实践问题是无效的，对这种形式或方法的认识也是技术。第四，如果对解决某种实践问题是有益的，那么这种形式或方法可以称为技术；其反逻辑是，如果对解决某种实践问题是无益的，那么对这种形式或方法的认识也是技术。所谓的“有益”也包含两层含义，一是使解决问题的效果更好，二是使解决问题的代价更少。例如能让汽车跑得更快的技术是有益的，再如能让汽车更节能的技术也是有益的。
关于图3，在线下交流后国防科大的徐建国博士指出，技术与功能之间不应该是多对一的关系，应该是多对多的关系。我想了一下，觉得非常有道理。某项特定的技术完全可以支持多种功能。非常感谢徐博士指出这个错误。但是在当前这份文件中我并没有改正这个错误，我有意这样做，就是想说交流对于个人成长多么重要！“独学而无友，则孤陋而寡闻”。真诚的交流会让双方受益。在这份文件的图中还有一些已经发现的错误或有失严谨之处，大家找找看吧，找到了告诉我哦。
就图3还提出了一个问题：中医针灸是不是技术？按照我给出的定义，针灸应该算是技术。工程上的技术往往有明确的科学依据，但是并不意味着所有技术都必须有已知的科学依据。这个例子可以帮助理解图3中“有效”和“有益”的内涵。
上面这些阐述赢得了大家的认可，但是也牵出了一个更基础的问题：既然说技术属于知识，那么什么是知识？这个问题引发了一轮讨论的高潮。对这个问题的认识可以参考一些网上很容易查到的资料。
一直以来，西方哲学界对知识的定义包含了三个要素，即所谓的得到辩护的真信念，英文中常被简称为JTB理论。具体来说，某个人A'知道'某个事件B，或说A掌握了关于B的知识，是指:
1) B本身是真的;
2) A相信B是真的;
3) A相信B为真是得到辩护的(或者说有理据、合理的或确证的)。
这样的情况下，获得的知识是真实可靠的。
JTB理论中的每一点都是必要的。首先，如果事件B本身是假的，就不能说是知识。其次，如果A不相信或不接受'B是真的'这一点的话，也不能说他知道B。最后，即使前两点满足，如果A的相信不是得到辩护，或者说有理据的话，仍然不能说A有关于B的知识。举例来说，某人买了彩票后弄丢了，然后他认为自己也没有中彩票。虽然事实上他也没中，但由于他的相信是无合适理由的(未经辩护)，所以不能称作是知识:他并不知道自己的确没中彩票。
葛梯尔问题是现代知识论中的一个关于知识的定义的问题。1963年，美国哲学家爱德蒙德·葛梯尔(EdmundGettier)在一篇只有三页纸的论文中质疑当时哲学界公认的知识的定义:知识是得到辩护的真信念(也称为知识三要素，或'JTB理论')。他的论文标题是:'得到辩护的真信念就是知识吗?'。在论文中，葛梯尔提出了两个反例，说明即使是得到辩护的真信念，也未必是知识。这篇论文引发了哲学界对于知识定义的一系列争论，并导致了葛梯尔问题的出现:'应当怎样补充或修改知识三要素，才能完整地定义知识的概念?'
一个工作职位有史密斯和琼斯两个人竞争。双方都想得到这个职位。史密斯在某天晚上听到别人说上司会把这个职位给琼斯。事实上琼斯比他学历高，经验也更优胜。他很有理由相信琼斯会得到这个职位。同时琼斯中了彩票，将和某人分享十万美元。于是史密斯认识到:'得到这个职位的人中了彩票'。然而，事实上是上司让史密斯得到了这个职位。史密斯不知道的还有:他买的彩票也中奖了，他就是那个和琼斯分享十万美元的人。现在的问题是:史密斯认识到的'得到这个职位的人中了彩票'是一个得到辩护的真信念，但他真的知道这一点吗?这就是知识三要素理论的反例。
我觉得，可以把知识理解为是“人的意识对事物的正确映像”。用一个形象的图形可以把这个定义描绘成图4的样子。所说的“事物”包括物质和能量（质能世界），可以再对其分解为人造事物和自然事物。而人的肉体也属于自然事物。我自认为图4的描述比较形象，但是这个描述也有个局限性。因为对人的意识本身的正确认识也应该是知识，这恰恰是哲学所考虑的重点。但是在图中没有得到表达。
图4 知识的定义
把“解决实践问题”这个范围缩小一下，仅就“功能”讨论。因为我们所关心的人造系统，总是有一个或一系列功能的，系统依靠其拥有的功能为用户提供服务。所以就重点聚焦讨论“功能”。按照同样的逻辑，也来花点儿笔墨扒一扒什么是“功能”。
对“功能”的严谨定义：功能是为达到某种目的，对特定对象施加某种作用的能力。在描述一个功能时，在语言形式上采用动宾结构。其中的动词表示上述对功能的定义中的“作用”，宾语表示表示作用的对象或作用对象的属性。“作用的对象”也可以理解为是作用所涉及到的客体。例如“轰炸军舰”描述了一个功能，其中“轰炸”是动词，表示作用；“军舰”是宾语，表示作用的对象。再如“测量目标的位置”也描述了一个功能，与“轰炸军舰”不同的是，其宾语表示客体对象的属性。
这里需要强调的是，对功能的描述不需要强调作用的主体。或者说，对作用主体的描述不是描述功能的必要要素。关于这一点有其现实的意义。因为作用的主体往往体现了解决方案，但是在最初提出功能性需求时，并不需要确定解决方案。过早地固定解决方案是无益的。关于这一点，在系统工程的需求写作规范中有明确的阐述。例如针对一条功能性需求“测量目标最大位置”，它描述了一条功能，但不不限制实现这一功能的主体。在工程实践中，可以使用雷达测量目标的位置，也可以使用光电探测设备测量目标的位置。
关于这一点，再次引发了讨论。一种观点是，在系统需求写作时，要求明确承载功能的主体（某个特定的系统或系统元素）。我想，在业务和任务分析阶段，基本不需要提及和限定主体，事实上这个阶段考虑问题涉及的主体往往是用户。在系统定义阶段，承载功能的主体就是所关注系统（SOI）。在对系统逐层向下分解为各层系统元素的过程中，功能的主体也会随着视角而变。上面所说的“不限定实现功能的主体”，解释为不要过早地限定实现功能的下一层系统元素，这样逻辑大概就清晰了。
在交流中还讨论了如何看待和处理“用户提出涉及具体解决方案的需求”问题。我觉得对这种情况最好积极面对，相互谅解。毕竟用户（或客户，用户代表）要对某些事情负责，也有压力。只要用户提出的需求没有严重限制设计人员的想象，就是可以接受的，通常也是应该接受的。不过早限定解决方案、不限制工程人员的想象的需求描述就是恰当的，这是底层逻辑。需要强调的是，对于用户提出的不同层级的需求，在项目管理中应该把它们放在合适的层级和过程中管理。比如用户提出的业务和任务类需求，应该在需求阶段管理和处理；用户提出实物产品的需求，可能只在系统定义及以后阶段管理和处理。这样就不会乱了。简单说，就是要把用户提出的需求按照生存周期分门别类地管理起来，不要混在一起。
说完对功能的理解，再回到讨论的主线，关于技术的识别和技术体系的描述方法。这里需要强调一下，此处所说的“技术体系”特指特定企业为实现其使命所涉及的技术。要描述技术体系，首先应该建立统一的框架。对于形成一定规模的技术型企业，梳理技术体系以及描述技术通常需要很多人写作完成。如果缺乏整体框架，多专业众多人员各自描述的技术体系必然是杂乱无章的。只有建立了统一的整体框架，并对框架达成共识后，各专业的众多人员才能在此基础上添加细节，让梳理和描述越来越完整、越来越饱满。
这里所用的术语“框架”（Framework）不是“架构”（ Architecture）。框架是反映底层逻辑和基本原则的形式特征吧？对这样的认识我信心不足，欢迎读者指正！而架构是特定系统区别于其他系统的主要特征，是系统的主要形式特征与主要功能之间的映射关系。这也是我个人的理解，欢迎讨论，欢迎指正！
要制定描述技术体系的基础框架，就需要必要的理论指导。我想，对“功能”、“技术”、“技术概念”、“可操作性技术”、“功能性特征”、“非功能性特征”、“形式”（实体）等术语的理解是重要的理论基础。
谈到理论，就聊起了理论与实践之间的关系问题。理论研究是很难的，对理论的论述往往也很抽象，不容易懂。所以，理论往往让人望而生畏。尤其是对从事工程实践的工程师来说，有时甚至会排斥抽象的理论描述及讨论。常常会听到这样的话“你别跟我说那些高深的理论，我听不懂。我希望你直接告诉我，这个活儿该怎么干”。甚至喜欢强调理论的人在工程师的圈子里显得近乎异类，给人以故弄玄虚的感觉。
我想说，理论不是“玄学”。实践缺乏理论是盲目的，理论脱离实践是空洞的。不应该排斥理论去蛮干，也不能无病呻吟作理论。作为工程师，做理论研究应该立足实践。理论研究非常不容易，但是理论研究的成果应该很容易使用。好的理论会把解题变得很容易，所以没有道理排斥理论。比如用微积分很容易解决的问题，假如换做用小学生的算术去解，那可能是极其困难的。所以说，理论能是实践变得简单，而不是让实践更复杂。
要制定描述技术体系的基础框架，需要首先思考一个问题：理想的框架应该符合什么原则，或者说它能是技术体系的描述具备什么特征？我想，对技术体系的描述，其最重要的特征是“完整且无冗余”。
图5 描述技术体系的基本要求
完整，意味着对企业来说必要的技术，在识别时不会缺失。完整地识别技术体系是完整描述技术的基础。对技术体系描述的完整性能让企业发现自身的不足，针对未描述的技术要做描述计划并实施，对未掌握的技术要制定技术发展规划以补足能力缺失。对技术的完整描述还意味着，在项目实践中，该做的技术工作不会疏漏。
无冗余，意味着技术之间的关系被明确地识别并描述，不会对某项技术做重复描述。只有对技术体系做结构化的分解，才能做到无冗余。无冗余还是明确组织及人员技术责任的基础。如果对技术的分解和描述是混乱的，往往会成为组织及人员技术责任混乱的重要原因。
要做到完整且无冗余，总是要遵循某种原则。上面的讨论已经说明了技术与功能之间的关系，很自然地，可以发现这样一种划分技术的方法：分为与系统的功能性特性相关的技术，以及与系统的非功能性特性相关的技术，两者分别对应系统的功能性需求和非功能性需求。前者是“实现功能”的技术，后者是“使实现功能的效果更好或代价更小”的技术。
接下来我们可以通过一个例子继续思考。比如汽车传动系统需要“改变传动比”（也可以说是“改变扭矩”）这样一个功能，针对这个功能性需求，有“无级变速”和“双离合变速”等技术。那么，在技术分解时，仅仅列举出“无级变速技术”和“双离合变速技术”就够了呢？显然不够。只有对“无级变速技术”做进一步分解并描述，才能直接指导工程实践。在这里我将“无极变速技术”称为“技术概念”，它仅仅非常简要地描述了技术的基本特征。
这里涉及到“概念”一词。我对它的理解是对某种原理、规律、方案的概要描述，往往使用一个短语命名。“概念”一词容易与“术语”混淆。术语是理解特定领域专用语言中的专用词汇，是该领域共同认可的某种定义，领域内从业人员依靠这种定义表达和交流。术语不同于大众语言。比如“牛肉”“白云”就不是术语。概念的名称属于术语，但是术语并不都是概念。描述事物“是什么”的术语就不是概念，如DNA（脱氧核糖核酸）是术语，但不是概念。
我的这些认识在群里被指正，一个非常有力的资料是中华人民共和国国家标准GBT15237.1-2000《术语工作词汇 第1部分：理论与应用》。标准文本中明确说“术语是特定专业领域中一般概念的词语指称”“概念是通过对特征的独特组合而形成的知识单元”。我目前感觉对标准还不太理解。感兴趣的可以查阅。
要对技术概念做进一步分解和描述，我想到了沿着系统生存周期做展开分解和描述。在概念阶段，提出“无极变速”技术概念，分析这项技术所能满足的需求，分析其科学依据、技术可实现性、代价等；在系统定义阶段，详细设计无极变速箱的结构、工艺、材料等等。然后是实现，集成、验证等等阶段。在每个阶段，还会衍生出一系列技术，例如无级变速金属带润滑技术、无级变速金属带热处理技术等等。分解以后识别出来的这些技术，我将其称为“沿着生命周期展开的可操作性技术”，或者简单的称其为“可操作性技术”。技术概念与可操作性技术之间的关系见图6。
图6 技术概念与可操作性技术
可操作性技术与技术概念之间存在对应关系，从另一方面看，针对系统生存周期特定活动的可操作性技术之间往往存在共同特性，这些共性技术抽象命名为“一般性可操作性技术”。与此对照，与特定技术概念相关的可操作性技术称为“特殊性可操作性技术”。这样的划分方式见图7。
图7 技术体系的基础框架
例如，某个人掌握了“系统误差分析技术”，或者“汽车控制算法设计技术”，意味着掌握了一类可操作性技术，而不限于适用于实现特定的技术概念。这种划分方式的现实意义在于能清晰的界定组织和人员的技术责任。在实际工程项目中，如果提出了一个新的技术概念，并分解出某个特殊性可操作性技术，那么对于这个特殊性可操作性技术，其实也会走过从概念到实现的过程，首次突破这项特殊性可操作性性技术的任务，通常就应该由掌握了该类一般性可操作性技术的部门或人员承担。
除了技术概念和可操作性技术，还有一类技术是与工程方法和工具相关的。例如使用三维设计软件设计某种机械结构，这种技能也是技术。使用系统建模语言作系统设计建模，甚至系统工程方法论，也应该属于技术。对于工程方法和工具类的技术，在此就不作展开详细描述了。至于这类技术如何细分，通常对工程项目没有直接影响。
至此，技术体系最底层的框架就确定了。接下来要继续思考，对“功能性特性相关的技术概念”、“非功能性特性相关的技术概念”和“沿着生存周期展开的可操作性技术”如何继续分解。
显然，对于“功能性特性相关的技术概念”要以功能分解为基础。这是一项极富挑战性的课题！对功能的分解大致有这样几种思路：按照系统的运行过程划分，按照功能涉及的客体对象划分，按照系统元素的界面划分，按照基础技术分类划分，等等。每一种划分方式都有其合理性，在工程实践中常常都会被用到。但是，究竟怎么划分是合理的？或者说是最优的？
在讨论中大家谈到了“任务剖面”，或者说定义运行概念（OpsCon），就是对任务运行过程的想定。对“任务剖面”的想象和定义是必要的，它是对运行概念OpsCon的描述。但是，对于复杂系统来说，定义的任务剖面通常是一些典型任务剖面，而无法定义系统实际运行过程的所有剖面。或者说，系统通常不会按照事先定义的“剖面”运行。定义任务剖面的价值在于识别任务运行过程中涉及的对象、对象之间的关系和运行规则/机制。在系统设计中，要确保能有效地管理或控制对象之间的关系，让系统按照有利的规则/机制运行，以获取期望的利益。这样就把系统设计和设计描述问题简化了。体现“面向对象”思想。
复杂系统不是钟表。复杂系统在运行过程中，因为系统元素之间的关联关系动态变化，应用事先设计好的一套机制运行，适应外部事物（包括环境）情况及其变化。系统在运行过程中表现出的实际作用或许可以理解为是“涌现”出来的。
我提出的建议是首先按照系统功能所涉及的对象划分，这符合面向对象的思想。按照对象划分，能最大限度地避免重叠。但是仅仅按照对象划分是不行的，接下来应该按照过程划分。将功能划分到足够细致后，就可以针对每项功能提出技术概念。功能与技术概念之间是一对多的关系。对于一项功能，至少提出一项技术概念。
例如对于战斗机，按照功能涉及的对象划分系统功能，一种典型的划分实例可能是这样的：对战斗机的拦截功能，对地面交通设施的轰炸功能，对电子侦察飞机的驱逐功能等等。
接下来按照过程划分，可以参考OODA环，划分为目标探测功能、目标识别功能、战术规划功能、火力打击功能等等。
OODA 是观察（Oberve）、调整（Orient）、决策（Decide）以及行动（Act）的英文缩写，常称为“OODA循环”。它是美国空军上校、飞行员、战略家约翰·博伊德关于空战战术和飞机设计的重要理论。
OODA本质上描述了一个闭环控制过程。这种过程体现的思想不仅适用于指导空战，而是具有更普遍的应用价值，它适用于描述和改进一般性的闭环控制过程。
为了使OODA循环所体现的思想更具普适性(一般性)，有必要对其作进一步抽象描述。
将“观察”抽象为“测量”Measure，本质上是“获取对对象的描述信息的过程”。
将Orient译为“判断”比译为“调整”更合适。将“判断”抽象为“估计”Evaluate，本质上是“依据测量获取的信息(往往是有限的、不确定的、带噪声的信息)估计关于对象的现实”，体现了对不确定性认识。
将“决策”抽象为“规划”Planning。因为对于即将采取的复杂行为，不是“或A或B的选择”这样的“决策”，而是提出备选解决方案、方案权衡对比、选定方案的过程，称为“规划”比“决策”更具一般性。
综上所述，我认为可以将OODA抽象为MEPA(测量measure，估计Evaluate，规划Planning，行动Act)。感兴趣的专家可以就此问题找我专门交流指正，先谢啦！
最后，针对特定功能提出技术概念。例如针对“测量空中目标距离”这项功能，可以提出“雷达测距”、“激光测距”、“光学测距”等技术概念。
毫无疑问，按照对象、过程、技术这样的顺序分解不是唯一合理的，我觉得不存在最佳的分解方案。作为工程师，我认为只要某种分解方案是对工作有益的就可以了，并不需要苛求完美。“完整且无冗余”是追求的理想，但是追求理想与面对现实并不矛盾。
对于“与非功能性特性相关的技术概念”的分解不需要太多纠结，按照可靠性、维修性、安全性、电磁兼容性、经济性、重量特性……去分解就是了。
对于“按照生存周期展开的可操作性技术”，思路也很容易理清，可以直接参照INCOSE定义的生存周期过程分解就可以了，如系统需求定义技术、系统分析技术、系统验证技术等。特殊性可操作性技术如模拟信号接口设计技术、总线接口接地技术、系统时间误差测量及分析技术等等。
按照这个技术体系框架分解完技术体系后，建议按照周辉提出的类别对技术作标记，并制定合适的技术发展战略。这一点在交流时忘记说了，在此补充一下。
对于技术体系分解描述的结构，我认为应该采用逻辑关系图（就像本文图3那样的形式），这是种网状的结构，表达能力非常强，远远超过思维导图。讨论到这一问题时，有专家告诉我有个软件叫OMP，适合描述这种网状的逻辑关系。这是我的一大收获！
写到这里，我长长地舒了口气。技术体系框架问题算是写完了。
最后，我跟大家分享了一些自己想到的问题，也建议大家把这个问题清单再继续拉长。因为提出问题有时甚至比解决问题更重要，也更难。这个清单暂时包括这些问题：
*描述系统的模型（视图）可以被复用吗？
*真正复用的是技术还是模型？
*用模型描述系统，那么用什么描述技术？
*MBSE为系统赋能，拿什么为组织赋能？
*有基于模型的系统工程，需要基于模型的技术工程吗？两者能结合吗？
*系统研制与知识积累可以结合吗？
*项目管理与技术管理能统一吗？如果要统一，需要做哪些工作？需要什么样的软件平台？
*咱们能一起做点什么吗？
图8 技术与模型
在交流时，我讲述了一个案例。一个设计师团队把某飞机的一个软件模块直接复用到另一型飞机上。因为两型飞机动力等方面的特性不同，在飞行时因此引发事故，为此付出了生命的代价。这个沉重的案例引发我们思考，模型真的很方便复用吗？真正可以被复用的到底是模型还是知识？
如果技术体系能按照上述框架建立起来了，系统生存周期过程也能与技术体系对应起来了。那么，把技术体系与系统研制结合起来，系统研制的生存周期V模型应该是什么样子呢？既然系统是要为用户提供服务的，系统功能是系统为用户提供服务的基础，那么，在系统研制过程中，就应该始终围绕着系统功能开展工作，我将其称为“基于技术面向功能的系统研发”，与此对应，将系统生存周期V模型的左半边划分为任务层、概念层和物理层三层，这与目前常见的按照系统元素层级划分的方式不同，对比见图9。
图9 两种V模型对比
针对“基于技术面向功能的系统研发”没有展开作详细说明和讨论。这个问题很大，如有必要，就留到以后再找机会讨论吧。估计在交流的时候大家也没明白我想说什么，因为我也确实没说太多。
还讨论了更多的问题，再写就太乱了，显得内容喧宾夺主。回过头看一下，这种“胡说体”挺好哒，很容易码出很多字，自己感觉很有成就感，哈哈！
再次感谢大家！
系统工程公众号是由一群系统工程爱好者所发起，目的是推进系统工程在中国应用，纯粹公益性质。 |
联系客服
