系统工程,第1部分:什么是系统工程?
从系列中:系统工程:管理系统复杂性
布莱恩•道格拉斯
本视频介绍了什么是系统工程以及为什么它是有用的。我们将介绍系统工程如何帮助您以有效的方式开发复杂的项目以满足规划目标的广泛概述。本介绍将为本系列的其余部分打下基础,我们将介绍如何开发和描述系统体系结构,如何在整个项目中沟通需求、要求和约束,如何通过贸易研究优化设计,以及如何知道系统最终应该做什么。
这是系统工程系列的第一个视频。现在,我们不打算在4到5个视频中涵盖所有的系统工程,但我希望能对它如何帮助我们以有效的方式开发复杂的项目来满足规划目标给出一个广泛的概述。这里的高效意味着我们试图减少不必要的工作和返工,我们试图在设计的早期发现错误和缺陷,我们试图在项目的所有关键参与者之间有效地沟通,以便每个人都朝着相同的共同目标工作。
为了理解系统工程如何帮助我们实现这一点,我们将介绍系统架构是如何开发和描述的,我们如何在整个项目中沟通需求、要求和约束,我们如何通过贸易研究优化设计,以及我们如何知道系统最终会做它应该做的事情。这就是这个系列的概述,但是在这个视频中,我们将停留在一个非常高的水平上讨论什么是系统工程以及它为什么有用。我希望你能坚持下去。我是Brian,欢迎来到MATLAB技术讲座。
系统工程是一个过程,我们可以用来开发一些太复杂的东西,只是设计和建造作为一个单一的整体。它是从一个想法开始,通常是模糊不清和不明确的,并将其付诸实践。它将系统视为一个整体,理解系统与外部世界之间的相互作用以及内部组件之间的相互作用。它指导工程过程,以便系统可以以一种可以实现的方式进行描述,并在此过程中确保它满足项目的需求。
当然,不只是一组需求,不同群体的需求相互竞争。一种是涉众,他们启动了整个项目并推动了高水平的目标。这些都是客户,最终决定你所创造的东西是否对他们有价值的人。
然而,也有项目管理人员需要平衡风险、进度、预算和其他规划限制。
还有工程专家。他们是软件、机械和电气工程师,或者具有特定领域知识并负责设计和实现所描述的系统的人员。他们需要一个实际可实现的描述,并且足够清楚地理解关键需求和约束,但又不能太详细以至于在实现中没有灵活性。毕竟他们是专家,所以他们知道如何最好地设计一些东西。
那么,剩下的,在这些圈之外是系统工程的角色。系统工程师帮助了解这些组的需求,并努力描述与所有这些组兼容的系统。
在项目开始时,我们以一组模糊的目标开始,我们试图完成什么。然后,我们形成一些不同的概念,可以满足这些目标,并通过分析和模拟将其缩小为我们想要前进的初步系统。通常这个系统非常复杂,需要分解成更小的组件。然后这些组件可以被进一步分解,直到你剩下一组足够简单的东西,让你明白如何设计它们。一旦这些组件被设计和构建,系统工程也是确保每个组件做它应该做的事情的过程,然后这些组件的集成做它们应该做的事情,以此类推,直到你有一个功能良好的顶层系统,满足最初的目标。
这些复杂的问题可能以机器的形式出现,也可能是一个软件项目,或者您可能正在为整个城市设计一个交通基础设施。这里的关键不是你要解决的具体问题,而是这个问题非常复杂,如果不先把它分解成更小的组件,你就无法完全掌握如何设计它。
当然,整个过程不是一个线性的过程,即涉众告诉项目管理人员他们想要什么,系统工程师将其分解为需求和架构,然后工程专家开始构建它。这个过程是迭代的,所有团队之间都有紧密的沟通,这样他们就可以随着项目在定义和设计过程中的进展而深入了解更详细的细节。这是至关重要的,因为你经常会发现不同群体的需求是相互冲突的,只有通过贸易研究、体系结构描述和需求,你才能弄清楚并能够解决它。
然而,这种方法并非没有自己的挑战。当您将系统分解为组件时,会出现新的问题。现在,您需要考虑什么是简化这种复杂性的最佳方法——什么是在功能上、逻辑上和物理上拆分系统的最佳方法。那么这些组件应该怎么做才能满足更高层次系统的需求呢?我们如何确保所有的组件是相互兼容的,这样当它们被构建时,通常是在不同的地区,不同的时间,由不同的人,它们最终都结合在一起,满足项目的需求?
这些都是系统工程的挑战,对于那些喜欢解决棘手的跨职能问题的人来说,这是一个有趣的领域。现在,为了帮助我们做到这一点,我们有一些工具,这些工具提供了开发系统架构、定义接口、编写需求并将它们追溯到设计的简化方法。我们有基于模型的方法,可以让我们快速分析和模拟早期架构,这样我们就可以进行贸易研究,更快地发现设计问题。我们有一套标准的里程碑和审查周期,以确保我们不会在无法实现或不能满足特定需求的设计中继续前进。
这是我想强调的一点。架构描述、评审、贸易研究以及所有这些都是额外的工作。这绝对超出了你开发和构建一个系统所需要做的事情。
假设你正在开发一款网络应用,那么最终产品就是软件。编写代码对程序有直接的价值,因为为了产品的存在,代码必须存在。另一方面,谈论编写软件并没有直接的价值。例如,一个产品可以在没有系统需求评审或功能架构图的情况下仍然存在。这两件事都不是绝对必需的,因为它们不是最终交付产品的一部分。
那么,如果是这样的话,为什么要采用系统工程方法呢?
好吧,正如您可能猜到的那样,如果您正在构建的系统足够复杂,需求评审和架构图以及其他一切都是必要的。系统工程额外的时间和精力将少于返工和修复一个在一开始就没有正确架构和描述的系统所需要的时间和精力。
对于一个简单的例子,这可能更有意义。
假设你在设计一扇车门。很明显,你需要一些结构上的东西,可以铰接在车架上,还有某种可以从车里里外外打开的门闩。所以,这些都是要求,你有一个机械工程师在设计。
在集成过程中,你看着它,想,等等,我也想能透过门看到外面。所以,你让工程师重新设计结构来容纳一扇玻璃窗。
但是现在你想要能够打开窗户。因此,他们重新设计了门,包括一个移动窗户的机构和一个机械曲柄。
但这并不是你想要的,你希望它是电动的。现在你需要一个电气工程师设计一个马达,一个拨动开关,以某种方式将电力从汽车电气系统输送到车门。
啊,但你也不想窗户关上时压到手指吧。现在你需要传感器和软件来管理安全元件。等等。
这种边做边探索的方法可以让我们快速地投入到一个项目中,并在早期取得我们可以从中学习的进展,然而,它也会创造一个昂贵且耗时的工作和返工周期。
当然,这个问题是人为设计的,有点傻。你可能会想,如果我在那个项目中,一开始我们只是头脑风暴我们想做的所有事情,粗略地找出所有的部分,然后分别设计和建造我们的组件。如果我们有一个问题,我们的组件是否能很好地与另一个组件交互,我们只要走到彼此面前,把它解决掉。这就是系统工程。只是规模要小得多。
每个人都是小型项目的系统工程师,因为问题足够简单,工程师团队能够将所有重要信息保存在他们的集体记忆中,或者使用特别的笔记,每个人都可以与项目的总体目标保持同步,彼此之间也可以保持同步。但在更复杂的项目中,高层目标、不同功能和组件之间的相互依赖关系不是那么直接,或者它们太多了,合理地期望一种特别的方法就足够了。
所以,这就是为什么我们有我们的过程,我们的工具,帮助我们把一个系统分解成合理的组件,架构这些组件应该如何相互接口,它们应该做什么,以及我们将如何测试它们。使用基于模型的方法,我们可以快速评估系统,并允许我们快速地研究工作设计,并且希望没有长时间的故障和返工周期。
为了说明这一点,让我们看看对于一个涉众想要个人空中出租车服务的项目,系统工程方法可能是什么样的。
我们从涉众需求分析开始:这是要弄清楚客户最终希望实现什么。比如,需要运送多少人?持续多长时间?他们需要走多远?它需要在哪里降落和起飞?每乘客英里的目标成本是多少?等等。我们正在了解最终系统应该完成什么。
从那里,我们可以开始概念探索的过程——也就是说,找出项目可能采取的所有不同形式:我们应该建造固定翼还是旋翼?它应该跑多快?它能载多少乘客?等。模型和模拟放在一起来评估每个概念的可行性,这样我们就可以权衡每个概念的优缺点,并将其缩小到初步解决方案。
有了一个初步的概念,我们可以开始用系统需求来定义它:比如兼容性需求——比如它需要与现有的机场基础设施进行接口?存在可靠性、可维护性和可用性需求,例如根据后果的严重程度可接受的故障率是多少?系统需要多长时间才能停机维护?还有一些环境要求,比如它必须应对什么样的天气?它能在高海拔地区起飞吗?尘土飞扬的环境呢?
性能要求基本确定后,我们可以开始将系统概念划分为功能:像机身这样的东西——它必须能够飞行并保持在一起,电力需要存储和分配,系统必须能够与地面基础设施通信,等等。然后我们可以看看函数之间是如何交互的。这是它们之间交换的信号、数据、物质和能量。我们可以讨论它们在物理上是如何配置的,功能是由硬件还是软件执行的?不同软件元素之间的逻辑是如何划分的?
我们现在继续通过分析和模拟来验证这个概念将满足涉众的需求。我们进行了更多的贸易研究,在这些研究中,我们观察了不同具体实现和概念的功能组织的成本和性能。如果它看起来很有前途,我们就开始把这个概念发展成更具体的东西。我们得到较低层次的需求,我们定义子系统,并开始初步配置,我们细化体系结构描述。我们继续通过这些任务,平衡来自管理层的项目需求,工程专家的实施需求,以及利益相关者的总体目标,提供越来越细的细节,直到我们有足够的信心开始详细设计和制造。
在这一点上,我们开始集成和测试过程。如果我们正确地完成了前端工作,我们将会把问题和返工的数量降到最低。当然,这并不能保证不会出现问题,但是系统工程过程应该使您远离不断返工的情况,就像我们在车门示例中遇到的情况一样。我的意思是,你能想象如果你在系统集成和测试阶段然后意识到你应该建造一架固定翼飞机而不是旋翼飞机吗?那将是一场噩梦!
好了,这段视频就讲到这里:简单的项目不一定需要正式的系统工程过程。另一方面,像制造飞机这样复杂的事情绝对需要。在这两者之间,你做系统工程的具体方法是不同的。也许项目可以从思考和讨论需求中受益,但不一定从正式的架构设计和评审中受益。每个系统和行业可能需要略有不同的方法。这就是为什么,在接下来的几个视频中,我不会试图解释一个适用于所有系统工程的方法,只是没有一个。相反,我们将介绍一些在系统工程中使用的更重要的工具和过程,解释它们如何帮助简化问题,并提供一些您可以考虑使用它们的场景。
在下一集视频中,我们将把系统工程视为一个优化问题,并展示工程经验和贸易研究如何通过良好的决策来帮助优化设计。此外,我们将展示模型和系统的其他近似如何成为决策过程的关键部分。
如果你不想错过这个或任何其他Tech Talk视频,不要忘记订阅这个频道。如果你感兴趣,你可以看看我的频道,我也会介绍控制理论的话题。感谢收看,我们下期见。
您也可以从以下列表中选择一个网站:
如何获得最佳的网站性能
选择中国站点(中文或英文)以获得最佳站点性能。其他MathWorks国家站点没有针对您所在位置的访问进行优化。