即SDM224系统工程基础第10周Study Note

• 即SDM224系统工程基础第10周Study Note
  • 1.1 什么是系统？
  • 1.2 系统生命周期
  • 1.3 获取与使用阶段
  • 1.4 开发方法
  • 1.5 什么是系统工程？
  • 1.6 系统工程的相关性
  • 1.7 系统工程的优点
  • 课程反馈：如何真正理解系统工程

当我问自己，我真的知道了解什么是系统工程吗？答案是我不知道；
然后我又问自己，这个东西很重要吗？我说有可能。
所以我决定写下这篇博客。

周一晚上的思政课的时间，读了一下课程推荐教材《INTRODUCTION TO SYSTEMS ENGINEERING》。

读完，我发现，系统工程其实蛮好的。

这篇博客主要是第一章的读后感。

1.1 什么是系统？

书中的系统定义参考了ISO/IEC 15288，

a combination of interacting elements organized to achieve one or more stated purposes

一组相互作用的元素，组织在一起以实现一个或多个明确的目的

不像信号与系统里的系统定义，这里的系统少了一些数学的性质，变得普适和易于理解。

第一章还有一个有趣的概念叫“Capability System”，作者将系统和其支持其运行的能力联系在一起，将概念扩大到了更大的范围，称之为“Capability System”，这个概念引导人在看待一个系统的时候，不把目光局限在系统本身，而是能够看到更广的范围。

比如以一个上帝视角来观察Freedorm的运作，从研发到开售到售后，一系列小的事情在脑中闪过，给人一种掌控全局的安全感。

• 注：Freedorm是南科大宿舍门改装套件，能够提供蓝牙感应开门，远程开门等功能，详情请见我们的开源页面

1.1.7.2 Physical Hierarchy提出了一种四层的系统结构，分别是：System, Subsystem, Assemblies, Component。这种结构在工程中是非常常见的，应用在Freedorm上也非常合适。

对于更大更复杂的项目，还会多一个System of Systems，每一个小的System都有自己的System Engineering，包括生命周期，需求分析，设计，验证优化等等。

1.2 系统生命周期

这一页引入了课上经常听到的四个生命周期，这几个阶段可以总结为：

1. 预获取阶段（Pre-acquisition Phase）：

   • 在这一阶段，系统生命周期开始于业务规划过程中产生的系统构想。对可行选项的早期考虑会确认系统的初步业务需求，并通过一个业务案例来详细说明支出组织资源以获取该系统的合理性。
   • 在某些情况下，预获取阶段可能确定继续获取系统不可行或不具成本效益（如技术限制或资金不足）。
   • 因此，预获取阶段主要通过研发资金确保只有可行且具有成本效益的项目会继续进入获取阶段。

2. 获取阶段（Acquisition Phase）：

   • 获取阶段基于系统的业务需求，旨在将系统引入组织并投入使用。
   • 通常包括根据业务需求、利益相关者需求和系统需求来定义系统，随后与承包商合作开发或交付该系统。

3. 使用阶段（Utilization Phase）：

   • 系统在使用阶段持续在组织中服役，直到不再满足业务需求，或无法再履行组织要求的功能，或不具备继续服务的成本效益。
   • 在此期间，系统可能经历多次修改和升级，以解决性能不足、满足不断变化的操作要求、适应外部环境，或提高当前性能和可靠性。

4. 退役阶段（Retirement Phase）：

   • 经过操作使用和系统支持后，系统最终逐步退役，生命周期以退役阶段结束。
   • 如果组织中对该系统能力的需求仍然存在，那么一个系统生命周期的结束往往意味着另一个系统生命周期的开始，整个过程重新启动。

由于作者R. Ian Faulconbridge从事澳大利亚的军工开发，这些术语特别适用于与政府合作的项目。

尽管这四个阶段在消费产品开发中也适用，但不完全贴切。因此，在Freedorm的开发中，我们采用了以下的生命周期模型：

链接一下其他知识，设计思维里Double Diamond就是用在预获取和获取阶段来获取用户需求和和确定产品解决方案的一种工具。

1.3 获取与使用阶段

If you can’t explain it simply, you don’t understand it well enough. —— Albert Einstein

这一章详细介绍了获取阶段的一些概念，包括以下四个主要活动，每个活动包括关键的设计步骤和评审节点如下：

1. 概念设计（Conceptual Design）：

   • 概念设计旨在系统层面生成一套明确的需求，以逻辑方式表述。尽管清晰定义系统需求是合理且必要的起点，但通常执行得不充分，常导致后续开发过程中的问题。概念设计过程通过正式流程来明确业务需求与需求（BNR：Business Needs and Requirements），由业务管理层确认，再由业务操作层的利益相关者细化为利益相关者需求和需求（SNR：Stakeholder Needs and Requirements），最终由需求工程师转化为系统需求规范（SyRS：System Requirements Specification）。
   • 在大型系统中，可能会为每个关键组成元素（如主要物资系统、人员、支持、培训和设施等）分别制定SyRS。

2. 初步设计（Preliminary Design）：

   • 初步设计的目的是将功能基线（FBL：Functional Baseline）转化为系统配置或架构的上层物理定义。这个阶段将逻辑设计转化为物理设计，使焦点从问题领域转移到解决方案领域。初步设计的结果是生成一个子系统级的分配基线（ABL：Allocated Baseline），将FBL中的逻辑分组重新细化并分配到子系统级的物理分组（称为配置项，CI：Configuration Item）。
   • 初步设计评审（PDR：Preliminary Design Review）用于评估ABL的技术适用性，确保该设计满足技术要求并识别并确认各个CI的接口和兼容性。

3. 详细设计与开发（Detailed Design and Development）：

   • 初步设计中的ABL用作详细设计和开发的基础，以完成各子系统、组件的开发。在此过程中可能会进行原型设计，并通过测试和评估确认系统设计。详细设计与开发的最终产物是产品基线（PBL：Product Baseline），此时系统被定义为由多个子系统、组件及其制造和建造的所需材料和工艺组成。
   • 产品基线在关键设计评审（CDR：Critical Design Review）中建立，CDR是最终设计评审节点，决定设计是否正式被接受，标志着生产/建造活动的开始。CDR评估详细设计，判断生产/建造的准备情况，并确保所有内部和外部接口的兼容性。

4. 建造/生产（Construction and/or Production）：

   • 获取阶段的最终活动是建造或生产，系统组件按照PBL中的详细设计规范被生产，系统最终以其完整形式建成。会进行正式测试与评估活动（验收测试，AT&E：Acceptance Test and Evaluation），以确保最终系统配置符合SyRS中的需求。
   • 建造/生产活动以及获取阶段以正式鉴定评审（FQR：Formal Qualification Review）结束，FQR是客户根据AT&E结果正式接受系统的基础。

引入一堆名词和概念来解释一堆东西是对读者对不尊重，因此为了表明我对读者对尊重和对这部分内容的理解，我将上面的一坨提出我的解释：

1. 概念设计：

   • 这一阶段的目标是以清晰的方式定义系统需求。虽然明确系统需求是开发的关键第一步，但许多项目在这一点上会遇到问题，因为需求的描述可能不够准确。概念设计的过程通过正式步骤来明确业务需求，得到管理层的确认，并在此基础上细化为详细的系统需求。

2. 初步设计：

   • 初步设计阶段把概念设计中的系统结构转化为更具体的设计框架，重点从“需要什么”转移到“如何实现”。初步设计会更详细地定义子系统，确保不同部分能兼容和协同工作。这个阶段还会对设计进行评估，以确保技术上可行，并且符合需求。

3. 详细设计与开发：

   • 这一阶段在初步设计的基础上，进一步细化各个部分的具体设计和开发。可能会制作原型来验证设计是否满足需求，并进行测试。最终成果是详细的系统设计，这时候的设计细节已经可以支持实际的生产或建造工作。

4. 建造和生产：

   • 在详细设计完成后，系统进入实际的建造或生产阶段。各部分根据设计规格被制造出来，系统逐步被组装成完整的形式。最后，通过正式测试确保系统符合设计需求，经过确认后，客户正式验收系统。

1.4 开发方法

书中还介绍了几种常见的开发方法，以下是ChatGPT-4o的解释：

1. 瀑布式开发方法 (Waterfall Approach)：

   • 瀑布模型是一种线性、顺序式的开发方式，各个阶段如需求分析、设计、实现、测试等按顺序依次完成。每一阶段必须完全完成，才能进入下一个阶段。瀑布模型逻辑清晰、便于管理，但缺乏灵活性。如果在后期发现需求变更，回溯和调整的代价较高。

2. 增量式开发方法 (Incremental Approach)：

   • 增量开发将系统分为多个小部分，逐步完成。每个部分的开发和测试都作为一个小“增量”完成，然后将增量整合形成完整的系统。这种方法可以逐步向用户交付功能，便于反馈和改进，也能更快适应需求变化。

3. 螺旋式开发方法 (Spiral Approach)：

   • 螺旋模型结合了瀑布和增量开发的优点，并强调风险管理。每次迭代都包含规划、风险评估、开发、验证等活动，形成一个螺旋式上升的开发过程。这种方法特别适用于风险较高或需求不明确的项目，能在每个迭代中不断优化和改进。

4. 演进式开发方法 (Evolutionary Approach)：

   • 演进式开发关注系统的不断改进和迭代。初始版本并不追求完美，而是快速推出一个基本版本，然后逐步完善。这种方法适合那些需求随时间推移不断变化的项目，能够更好地响应新需求和环境的变化。

不同方法各有优劣，选择合适的方法取决于项目的需求、时间、预算、风险等因素。

1.5 什么是系统工程？

原文第5章写得很好，我就不班门弄斧了，这里放上原文 (不放中文，因为ai翻译感觉不太对)：

展开查看原文

1.5 WHAT IS SYSTEMS ENGINEERING?

There is a wide range of definitions of systems engineering, each of which is subtly different because it tends to reflect the particular focus of its source. Although each of these definitions has a slightly different focus, a number of common themes are evident and are described in the following sections.

1.5.1 Top-down Approach

Traditional engineering design methods are based on a bottom-up approach in which known components are combined into assemblies and then into the subsystems from which the system is then constructed. The system is then tested for the desired properties and the design is modified in an iterative manner until the system meets the desired criteria. This approach is valid and extremely useful for relatively straightforward problems that are well defined. Unfortunately, complicated problems cannot be solved using the bottom-up approach.

Systems engineering begins by addressing the system as a whole, which facilitates an understanding of the system, its environment, and its interfaces. Once system-level requirements are understood, the system is then broken down into subsystems and the subsystems further broken down into assemblies, and then into components until a complete understanding is achieved of the system from top to bottom. This top-down approach is a very important element of managing the development of complicated systems. By viewing the system as a whole initially and then progressively breaking the system into smaller elements, the interaction between the components can be understood more thoroughly, which assists in identifying and designing the necessary interfaces between components (internal interfaces) and between this and other systems (external interfaces).

It must be recognized, however, that while design is conducted top-down, the system is implemented using a bottom-up approach for a simple four-tier system. That is, one of the aims of systems engineering is to provide a rigorous, reproducible process by which the complex system can be broken down into a series of simple components that can then be designed and built using the traditional bottom-up engineering approach. Importantly, therefore, the second principal facet of systems engineering is to provide a process by which the components, assemblies, and subsystems can be integrated to achieve the desired system purpose.

1.5.2 Requirements Engineering

The development of a complete and accurate definition of system requirements is fundamental to project success and is a primary focus of the early systems engineering effort (recognising, of course, that a complete description is not always possible). The life cycle of a system begins with business needs, which are translated into a large number of statements of requirement that form the basis for the logical design and subsequently elaborated further to form the physical architecture.

These transitions must be managed by a rigorous process, called requirements engineering, which is aimed at ensuring that all relevant requirements are included (and all irrelevant requirements excluded). The establishment of correct requirements is fundamental to the success of the subsequent design activities. Poor requirements cannot be rectified by good design, so it invariably follows that rigorous development of requirements is essential for the acquisition to be successful.

Chapter 2 provides more detail on the body of knowledge of requirements engineering.

1.5.3 Focus on Life Cycle

Systems engineering is focused on the entire system life cycle and takes this life cycle into consideration during decision-making processes. In the past, it has been too common to consider design options only in light of issues associated with the Acquisition Phase and to pay little attention to through-life support aspects.

It is proper for project managers and their teams to focus on the Acquisition Phase of the project and on the development of a system that meets stakeholder requirements while minimizing cost and schedule. However, a lack of consideration of whole-of-life aspects can often lead to larger-than-expected costs in the Utilization Phase, which must then be met from budgets that are insufficient to keep systems in service.

A life-cycle focus requires a focus on the capability system, not on the product.

1.5.4 System Optimization and Balance

A system architecture must represent a balance between a large number of requirements and constraints that, in addition to technical considerations, cover a wide range of factors such as environmental, economic, human factors, moral, ethical, social, cultural, psychological, and more. A simple but essential example is the balance between cost and performance—if either is allowed to dominate, it will generally be at the expense of the other.

Balance in system design must also be achieved across the life cycle. Metrics like cost-effectiveness should be measured across all phases, not just in acquisition. Often, cost savings made in acquiring the system are later offset by significant maintenance and repair costs during its service life.

Systems engineering plays a crucial role in ensuring balance among the various system components. It is essential that optimization and balance are managed at the system level. It does not necessarily follow that optimizing each subsystem will lead to an optimized overall system. Consequently, some subsystems may need to be intentionally limited to allow their combination to yield an optimal system.

A further advantage of the top-down approach in systems engineering is that system optimization and balance can be achieved as a natural outcome of the design process—something not guaranteed in a bottom-up design approach.

1.5.5 Integration of Disciplines and Specializations

Systems engineering aims to manage and integrate the efforts of a multitude of technical disciplines and specialties to ensure that all stakeholder requirements are adequately addressed. Rarely is it possible for a complicated system to be designed by a single discipline.

Consider, for example, the development of an aircraft. While aeronautical engineers may play a major role, the design, development, and production of a modern aircraft system require a wide variety of other engineering disciplines, including electrical/electronics, safety, EMI/EMC, production, metallurgical, and corrosion engineering. Additionally, other engineering fields are necessary for testing, logistics, and maintenance support, as well as for designing and building facilities such as runways, hangars, refueling stations, and embarkation/disembarkation areas.

Beyond engineering, non-engineering disciplines contribute to areas like marketing, finance, accounting, legal compliance, and environmental concerns. In short, the development of a single aircraft system may involve hundreds or even thousands of professionals from various disciplines.

The aim of systems engineering is to define tasks for these diverse disciplines and specialties and to manage their integration to produce a system that meets user requirements. This integration role is increasingly important in modern system developments due to the complexity of large projects, diverse contracting mechanisms, and the geographic dispersion of contractor and subcontractor teams across the country and around the world.

1.6 系统工程的相关性

同上，这里原文写得很好，我不再赘述，这里放上原文：

系统工程的原则和流程适用于各种项目，尽管应用程度有所不同。系统工程原则和方法最明显的应用是在大型复杂项目中。然而，较小且不那么复杂的项目也可以通过定制的系统工程方法受益。由于其广泛的适用性，理解系统工程的优点并根据项目的相对规模、复杂性和风险进行适当调整显得尤为重要 (apply them in a tailored manner, cognizant of the relative size, complexity, and risks associated with each undertaking.)。

在应用范围的一端是使用前沿开发技术的大型复杂项目，这些项目通常涉及巨额资金、较长的时间周期和显著的风险。而在范围的另一端是使用现有技术的小型项目，这些项目通常周期较短、成本较低，风险也较小。显然，这两种类型的项目所需的系统工程深度不同，我们在此讨论的各个方面都需要针对每个项目进行相应的调整。

1.7 系统工程的优点

ChatGPT-4o将系统工程的主要优势总结为：

1. 成本节约：系统工程通过全生命周期成本管理，可以在系统的设计、建造、使用、支持及报废等阶段节省大量费用。尽管早期的系统工程工作可能带来一定的成本增加，但经验表明，这种投资通常能在后期阶段带来更大的节约。

2. 缩短开发周期：系统工程帮助确保用户需求在设计中得到准确反映，从而减少后续更改需求所需的时间和成本。通过在设计初期评估可行的替代方案，系统工程能够更快地推进设计成熟度，缩短项目周期。

3. 减少系统故障和进度超支：系统工程通过严格的需求工程确保需求明确且可验证，避免因需求不当而导致的系统失败、超支和延期。需求管理过程注重保持对最初用户需求的可追溯性和一致性，而不会施加不必要的技术限制。

4. 降低技术风险：系统工程的严格方法在项目早期识别并管理技术风险，通过性能测量、设计评审和审计来追踪设计决策，显著减少项目后期可能出现的失败风险。

5. 提高系统质量：系统工程的纪律性确保项目最终的产品更加符合预期用途，满足用户的实际需求，从而提升系统的整体质量，确保系统按预期的高质量水平运行。

课程反馈：如何真正理解系统工程

1. 课程中的“本本主义”倾向

本本主义又称教条主义，是毛泽东1930年5月在《反对本本主义》中提出的一个概念。 毛泽东认为，在中国开展无产阶级革命，不讲究中国实际情况，生搬硬套马克思主义，就是本本主义。 – 本本主义- 维基百科

当前课程对SyRS，RBS等系统工程概念反复强调，每位同学都被要求严格按照完整流程进行概念设计。这种方式让我感觉，我们可能是在一味执行流程，而没有真正理解这些流程存在的意义和背后的灵活性。

在上周项目例会中，我询问大家对SyRS的实际体会时，几乎没有人给出积极的回答，多少反映了这套流程和我们实际的理解之间的落差。

2. 《Introduction to Systems Engineering》带来的思考

用了一个晚课的时间，我读了《INTRODUCTION TO SYSTEMS ENGINEERING》的第一章，因为课上已经多次提到前面的概念，我直接从1.6和1.7节开始。下课后我发现，系统工程原来还挺不错的。作者在1.6节中提到：“关键在于理解系统工程的优势，并根据项目的规模和复杂性灵活应用。” (it is critical to understand the merits of systems engineering apply them in a tailored manner, cognizant of the relative size, complexity, and risks associated with each undertaking.) 这种方法一下子点醒了我，也让我意识到，系统工程不仅仅是晦涩的流程和抽象概念，核心是让我们去解决“cost overruns, and schedule problems”这些项目中的实际问题——这些也恰恰是我在过去项目中遇到的难题。

基于我的阅读体验，我相信其他同学也会从这本书中获得类似的收获，尤其是当他们能够体会到系统工程不仅是概念，而是有实际的应用价值。

3. 一些可能的改进

一个好的Code Review不仅仅是指出代码中的问题，更应该提供具体的改进建议或示例代码，让开发者明确知道如何提升代码质量

• “先理解，再操作”：我们可以试试换一种顺序，先让大家读一读书中的关键章节，特别是那些能直接应用在项目上的内容。比如让大家自己翻译一部分书里的内容，带着问题来课堂讨论。这样，学到的东西会更具体，理解也会更深，比一上来就记一堆术语要有效得多。

• 回顾过去的“翻车”项目，增加代入感：可以设计一次作业，让我们回顾一下之前做的失败项目（比如一些思政课小组作业、编程课的组队作业……大家应该都有不少“翻车”经验吧）。通过这种方式，让同学们自己分析那些项目到底哪儿出了问题，然后再思考如果用系统工程的方法能不能解决点什么问题。这样一来，不但能让我们更有兴趣，也能让大家感觉到学的东西不是“纸上谈兵”。

• 因地制宜的项目流程设计：可以借用书中的思路，让同学们按照自己项目的实际情况，去裁剪系统工程流程。比如，我们可以定位自己项目在复杂度光谱上的位置，然后一起来讨论哪些流程步骤真正有必要，哪些可以简化。这个评估和裁剪的过程本身就是学习如何实际应用系统工程的关键，让我们明白系统工程不是单一的“标准答案”，而是能够灵活适应不同项目需求的工具。

这样一来，我们的学习不只是“跟着流程走”，而是学会分析和应用，最终理解系统工程的真正优势和适用边界。希望这些反馈对课程设计有所帮助。