下载掌阅APP，畅读海量书库
立即打开
当我们面对现实工作与生活中的各种挑战时，除了需要有应对挑战的勇气和坚忍不拔的毅力，还需要学会运用知识、工具与各种先进的方法来赢得挑战。
在产品设计与开发领域，开发人员需要不断地学习先进的科学技术知识，采用人们在社会工作、生活中积累的宝贵经验和科学方法，以应对设计与开发过程中已知或未知的各种挑战。
采用系统方法解决问题是人们在工程实践中总结出来的一种先进方法，也是产品设计与开发团队成员需掌握的一项重要能力。
3.1.1 系统的概念、属性及类型
1.系统的概念
系统指的是多个相互联系的要素组合起来的一个整体。整体表现出其组成部分所不具备的功能或性质，从而能够实现特定的目标，这种现象也被称为“涌现性”。例如，实现火星登陆的航天器就可以被看成一个系统，它具备把人类或各种火星登陆器从地球表面发送到火星表面这样一种功能，但其构成要素或组成部分本身则没有能力实现火星登陆这个功能。
日常生活中常见的系统有计算机操作系统、人体免疫系统、工厂自动控制系统、大自然生态系统、飞行自动控制系统、电力系统及通信系统等，这些系统在人们的认识里都是相对复杂的整体概念或产品名称，都包括多个构成要素。
2.系统的属性
系统的一般属性如下。 [2]
1）整体性。整体性是系统最基本、最核心的属性，是系统性最集中的体现。
2）关联性。构成系统的要素是相互联系、相互作用的；同时，所有要素隶属系统整体，并具有互动关系。
3）环境适应性。任何系统都存在于一定的环境之中，并与环境产生物质、能量和信息的交流。
除了以上三个一般属性，很多系统还具有目的性、层次性等属性。
1）目的性。系统是为了满足人们的特定需求而人为设计或开发的。
2）层次性。复杂系统具有层次性，构成系统的多个要素因为相互联系而产生层次结构。
3.系统的类型
1）自然系统与人造系统。如自然的水循环系统与人类建造的水力发电系统。
2）实体系统与概念系统。由自然存在的物质组成的系统称为实体系统，而由非物质构成的各种概念、程序等称为概念系统。
3）动态系统和静态系统。随时间而变化的系统称为动态系统，反之称为静态系统。
4）封闭系统与开放系统。是否与外界进行物质、能量及信息交换是区分封闭系统与开放系统的关键。
通过对系统概念、性质及类型的了解，可以联想到，为满足客户复杂的产品需求所设计与开发的产品都可以归类为人造系统。那么为满足这些需求而进行的产品设计也可以理解为进行系统设计，当然也属于工程设计领域。
从图3-1可以看出，人造系统通过与外部环境进行信息、物质或能量的转换，实现特定的功能与目的，从而满足客户的需求。如果在此基础上进一步细分系统，那么系统中每个功能模块本身仍然是由更基本的要素构成的。例如，各种实现逻辑的执行单元、能量传输单元、支撑整体结构的物理单元等。
图3-1 人造系统与外部环境
示例
这里以日常使用的便携式计算器为例。打开开关时，电源接通，系统开始有能量输入，输出驱动屏幕默认显示“0”，这时我们可以通过按下相应的数字按键及加、减、乘、除等按键构成算法组合，最后按下等号键完成信息输入，计算器就会在屏幕上自动输出计算结果，完成信息输出。通过这个过程可以看出，计算器就是一个人造系统，通过电池能量及自身构造，对信息输入进行处理并得到相应的输出结果，以实现数字计算的功能。
我们可以把示例中计算器的设计看成一个人造系统的设计，因为计算器的构成符合人们对系统概念的定义。要站在产品整体的角度来处理计算器的设计与开发过程中遇到的各种问题，找到各对象组合之间相互关联的部分，并解决各种问题，从而达成要实现的目标。
近年来，随着技术的不断发展，人们关注的系统组成要素本身也变成了非常复杂的系统。例如，我们可以把复兴号电力动车组涉及的整个交通体系看成一个庞大的系统，而在这个庞大的系统中，仅复兴号电力动车组这个组成要素就是一个复杂的系统。根据对以上概念的理解，人们提出了体系（System of Systems，SOS）这个概念，当前这个概念还在不断发展。有学者将其定义为：体系是经过整合的若干大规模系统，这些系统多种多样，可以独立运行，但能为实现某个共同目标而协同工作。构建体系的出发点可能是费用、性能和健壮性等。 [3] 可见，随着人们认识的不断提高，系统这个概念本身也在不断地扩展与深入。
3.1.2 系统方法论
在近代工程实践的基础上，系统方法论一直随着人们认识的逐步深入和实际工程经验的积累而不断演进。人们试图找到一个最好的方法以尽量涵盖更多的领域，从而有效地解决系统中可能出现的各种问题。事实上，如同牛顿的力学理论与爱因斯坦的相对论，不同方法论都有各自适用的空间和简化的模型来更方便地处理科学实践中遇到的各种问题。对使用者来说，在特定场景下最方便、最适合的方法就是最好的。但这并不意味着方法论的探索可以止步不前。恰恰相反，人们始终试图找到更好的方法来处理与解决现实的各种问题，从而解放生产力去探索未知的世界，这也是探索研究的意义所在。
下面介绍几种典型的系统方法论。它们能够比较全面地概括系统方法论的特点，方便读者理解并掌握系统方法论思想的精髓，从而更好地交付各种产品或解决实际生活中的问题。
1.霍尔三维结构
霍尔三维结构 [4] 是来自贝尔电话实验室的亚瑟·D.霍尔（Arthur D.Hall）通过在贝尔电话实验室的实践经验总结出来的经典方法论，这种方法论能够比较全面地概括系统工程的各项特点，如图3-2所示。
霍尔通过工程实践及研究发现，可以从三个维度来划分系统工程。
1）时间维度。系统开发的时间维度由每个重要决策的里程碑划分，每个被划分出来的单元称为阶段，这些阶段定义了一个项目从开始到结束的整个生命周期。从图3-2中可以看到，项目从时间维度可划分为七个阶段。
（1）项目集计划阶段。根据顶层的战略制定产品项目集与产品开发的顶层路线图。
（2）项目计划阶段。选定要设计的项目，制订项目开发计划。
（3）系统开发阶段。根据计划阶段的设计要求，开发满足项目需要的设计。
（4）产品制造阶段。生产产品的各组成部分，最终组合成相应的产品。
（5）产品部署阶段。完成产品的运输、安装与部署。
（6）产品运行阶段。按照系统的设计功能开展各项服务。
（7）产品退役阶段。产品完成使用使命而退役，开始计划新的产品。
图3-2 霍尔三维结构
2）逻辑维度。这是一个问题解决的逻辑流程，在实际项目中可以在任何阶段顺序执行相关步骤，但是每个阶段问题的解决必须按照逻辑维度问题解决的步骤顺序执行。这个问题解决流程包括如图3-2所示的步骤。
（1）问题定义。通过系统调查，尽可能全面地收集各种资料和数据，清楚定义问题。
（2）价值系统设计。系统设计要达到的指标，设计衡量与评价系统相关功能或性能的各种指标。
（3）系统综合。主要是按照问题的性质和总的功能要求，组成一种可供选择的系统方案，方案中要明确系统的结构和相应的参数。
（4）系统分析。对系统方案的性能、特点及满足设计指标的程度进行相应的优先次序排列。
（5）最优化。根据系统分析的结果，对方案中的各项参数进行调整，从而达到系统最优的效果。
（6）制定决策。在对系统进行分析、优化的基础上进行决策，选择最终行动方案。
（7）实施计划。根据决策阶段选择的行动方案，将系统付诸实施。
3）知识维度。为满足系统工程所需的各种学科知识，包括工程技术、医学、架构、商业、法律、管理、社会科学与艺术等。
由时间维度与逻辑维度构成的二维结构，早在霍尔三维结构之前就有比较多的讨论。实际上，每个时间阶段的问题都可采用逻辑维度问题处理的方法和步骤，并且在遇到特定问题的时候，可以采用迭代的方式进行处理，直到问题解决，从而得出进入下一个阶段决策所需的结论或结果。这样的步骤经常在最优化的逻辑开发过程中有所体现。
图3-3为二维结构的一个简化模型。从这个模型中可以看到，在以时间维度为主的每个阶段活动执行过程中，运用逻辑维度的问题处理方法，通过问题的不断挖掘、优化、迭代，最后得到一个满足系统工程设计的结果。
图3-3 系统工程二维结构
2.切克兰德的软系统方法论
英国学者彼得·切克兰德（Peter Checkland）通过工程实践及调查研究发现，随着系统工程应用领域的不断发展及扩展，系统设计也越来越复杂，涉及与人及社会等非工程领域的互动，这时单纯地采用之前的系统方法论（如霍尔三维结构，切克兰德称其为硬系统方法论）会遇到很多困难，甚至导致项目失败。因为在工程实践的早期，系统问题较为明确，需要解决的是如何解决已知问题本身。而后来随着技术的不断发展，逐渐遇到更大范围的情境，这时需要解决什么问题的“问题”就成了一个议题，所以切克兰德引入了“比较”环节，提出了软系统方法论，以便将系统方法论扩展到更大的应用领域。 [5]
图3-4为切克兰德软系统方法论概要，这个方法论分为七个不同的阶段。
1）阶段1和阶段2：问题表达。在问题还不是特别明确的情况下，尽可能地发现问题情境并尽量避免过早地陷入某种特定的结构，尽可能多地搜集问题情境中人们对问题的不同认识，同时不强求人们用系统论的术语做出分析，从而揭示那些可能的、相关的选择。
图3-4 切克兰德软系统方法论概要
建立起一种内容最丰富的可能图像。根据这种图像，选择关于问题情境的一个观点（或一些观点），从这些观点出发，再进一步研究问题情境。从表达的情境中发现“结构”“过程”“结构与过程之间的关系”，从而了解问题的真实情境。
2）阶段3：相关系统的根定义。根定义是一种从某个特定角度对一个人类活动系统的简要描述，这里称为相关系统的根定义。这样做的目的在于如果在后面阶段的研究显示出这种选择缺乏洞察力、不相关或不可能有结果，那么这种观点可能被其他观点取代。
一个形式完整的根定义需要包括如下六个要素，其首字母缩写为“C AT-WOE”。
● C（Customers）。系统活动的受害者或受益者。
● A（Actors）。系统活动的主要执行者或促使者。
● T（Transformation Process）。把定义的系统输入转变为定义的输出过程。
● W（Weltanschauung）。Weltanschauung是德语中“世界观”的意思，在这里表示一种观点、框架或图景，使某个特定的根定义变得有意义。
● O（Ownership）。系统的所有者。
● E（Environment constraints）。作用于系统的环境约束条件。
3）阶段4：构造和检验概念模型。在根定义的基础上，构造一个模型，使之能够实现根定义中的活动内容，形成概念模型。根定义说明了系统是什么，而概念模型则描述了系统必须做些什么才能符合所定义的系统。构造的模型不是已知的、存在于现实世界中的现实活动系统的描述，只是概念上的说明。
基于根定义的概念模型不存在正确与不正确之分，只存在能自圆其说和较难自圆其说之分，但是我们至少可以用图3-4中4a阶段的那种适合所有人类活动系统的正规的系统概念来检验所建立的概念模型的完整性，至少能让模型的建立过程较为正式，而不是草率完成的。
4）阶段5：概念模型与现实的比较。概念模型建立后就可以与现实世界的活动进行比较，通过比较发现概念模型不完善的部分，而重新返回建模阶段加以精练。
可以针对不同的研究采取不同的比较方式。实际上，概念模型可能不止一个，在反复的比较中可能发现各种优缺点，从而更好地对概念模型进行修正，进而得到最适合的概念模型。
5）阶段6：实施可行的和合乎需要的变革。阶段6的目的是通过将概念模型与现实情境中“是什么”进行比较来产生下面任何一种类型变更的讨论。
（1）结构方面的变革。主要针对组织运行中保持不变的部门结构。
（2）过程方面的变革。主要关于组织中动态要素的改变，如口头的或书面的汇报和信息传输过程的改变。
（3）态度方面的变革主要关于个人或集体意识，包括认识或态度等方面的改变。
6）阶段7：采取改善问题情境的行动。由于变革方案的实施改变了问题情境中原有的问题，而产生了另一个新问题，或者实施变革的活动本身可能有问题，这些新问题同样可以用方法论提供的方法来解决。
这种方法论并不是严格按照顺序进行的，可能从任何一个阶段开始，也可能从中间的阶段再次返回阶段1开始。这种方法论强调的是不断地反馈与学习。
除了上面介绍的两种被广泛接受的方法论，还有诸如“物理—事理—人理”（Wuli-Shili-Renli，WSR）系统方法论、“全面系统干预”（Total System Intervention，TSI）系统方法论等，感兴趣的读者可以去查阅与了解相关的内容。事实上，随着学科的深入发展，细分领域越来越多，其创造出来的场景也越来越复杂，目前系统方法论也依然在不断发展。
对于工程师或项目管理人员，知道典型系统方法论的发展与演进，从理论上了解问题解决的思想，再结合工程实践反馈，能够进一步加强对理论的认识。相信这样的过程有助于读者处理与解决现实世界中各种复杂多变的问题。
3.1.3 系统思考方法
系统思考方法就是站在系统的角度来处理各种问题。针对系统思考方法，本书总结了可以应用于日常工作与生活的“系统思考三三法则”。
1.等三分钟
“欲速，则不达；见小利，则大事不成。”遇到问题不要立即给出答案，经过三分钟思考后再回答。很多问题的复杂度或背后的“套路”超出了仅凭直觉就能马上做出有效决策的限度，在时间允许的情况下，需要运用直觉与理性分析相结合的方法进行综合判断，再给出答案。
2.问三个人
“三人行，必有我师焉。”我们面对的是越来越复杂的世界，也越来越依靠彼此互不交叠的专业知识来共同发展。我们比以往更需要团队合作或运用他人的知识与智慧来弥补个人知识领域的盲区，这样才能够从系统角度围绕目标进行有效、全面的分析与思考，从而使计划或处理方法更加完备，使风险应对更加充分、有效。
3.画三张图
在明确或清楚定义需要处理的问题后，就可以画出三张系统决策图（见图3-5）以分析及处理各种问题，保证在分析处理问题时能够关注系统思考的整体性、有序性、层次性、开放性、目的性、环境适应性及过程连续性等。
（1）静态分析图。可以运用“相互独立，完全穷尽”（Mutually Exclusive，Collectively Exhaustive，MECE）分析法 [6] 对问题进行静态分析，画出静态分析图。MECE分析法比较适合静态分析，因为实际动态发展的事物之间很难完全彼此独立且毫无关联。
图3-5 三张系统决策图
（2）动态监控图。事物随时间流逝而不断发展变化，我们要找到问题中关键的参数或动态变化的指标，并对其发展趋势进行预测、跟踪、分析及调整，使其变化满足系统设计的范围。例如，项目进度管理虽然有明确计划，但在实际执行过程中总会遇到各种意外事件使项目进度偏离原始目标。通过对关键项目活动进行动态监控，可以清楚地了解偏离目标的动态变化指标，从而采取有效的应对措施。
（3）动静结合图。系统是由若干部分相互联系、相互作用形成的具有某些功能的整体。系统不是孤立存在的，而是整体的、动态的，随着时间推移而不断发展。所以需要对静态与动态分析后的关键因素进行共同分析与监控，从整体上看待问题，并找到解决问题的平衡点，进而找到系统的最优解，而非单项最优解。
综上所述，运用系统的思考方法处理各种复杂问题，将充分保证产品设计与开发过程及结果的完整性，降低项目技术风险，提高项目执行效率，进而减少各种资源投入，并缩短问题处理或项目交付的时间，以及保证高质量。
3.2.1 系统工程的概念、特点及核心目标
1.系统工程的概念
系统工程，也就是处理系统的工程技术。 [7] 国际系统工程协会（InternationalCouncil on Systems Engineering，INCOSE）将系统工程定义为：系统工程是一种跨学科和综合的方法，使用系统原理和概念，以及科学、技术和管理方法，使工程系统的成功实现、使用和退役成为可能。 [8]
2.系统工程的特点
1）在开发的早期能够建立、平衡并综合各干系人的目标，计划及定义成功的标准，定义实际或预测的客户需求、可执行的概念及需求的功能。
2）选择合适的产品生命周期模型、过程方法及架构的管理方式，能够对项目的复杂度、不确定性和变化有一个合理的等级评判。
3）针对需求建立执行的基准、合适的模型，并为每个开发阶段所需的工作量选择合适的架构设计方案。
4）站在整体的角度执行设计的整合、系统验证及确认。
5）在兼顾问题与解决方案的同时，要考虑系统及服务，识别出每个部分在系统组装单元中扮演的角色，在保证系统性能的同时，给出能够满足系统要求的平衡后的方案。
3.系统工程的核心目标
系统工程是从总体出发，合理开发、运行和革新一个大规模复杂系统所需的思想、技术、方法论、方法与技术的总称，属于一门综合性的工程技术。系统工程是一门交叉学科。系统工程提供引导、指导及领导力来整合交叉领域学科及不同团体，使其更加紧密地合作；创造出一个合适的开发流程架构，从概念设计到交付产品、运行、更新升级，直至产品退役。
系统工程兼顾技术与商业目的，既能满足客户需要，又能满足产品质量要求，并顾及干系人的关注点，避免在实际使用过程或执行过程中产生不必要的负面影响或不足。
系统工程最终要为交付系统的结果负责，因此要管理好整个系统工程执行期间的所有风险点，包括但不限于技术风险、进度风险、交付风险、整合风险、测试风险等。系统工程最重要的目标是控制风险、交付产品并创造价值。
用定量与定性相结合的思想和方法处理大型复杂系统的问题，无论是系统的设计或组织建立，还是系统的经营管理，都可以统一地看成一类工程实践，统称为系统工程。系统设计思想更强调从系统的角度来思考创新产品的设计。系统设计要求在更高的层级关注终点的方向性部分，而不是关注那些实现的细节部分。
一般来说，系统工程把研制大规模系统的开发项目作为主要对象，可是其观点与方法也适用于小规模的开发项目和对现存系统的改善与发展。 [9]
综上所述，系统工程的核心目标主要包括如下几点。
● 站在整体的高度保证系统成功。
● 追求系统整体性能最优。
● 从技术角度看待问题，充分发挥团队力量。
● 在追求技术的同时满足商业上的要求。
系统工程方法论就是分析和解决系统开发、运作及管理实践中的问题所应遵循的工作顺序、逻辑步骤和方法。它是系统工程思考问题和处理问题的一般方法与总体框架。 [2]
3.2.2 系统生命周期及模型
人们在系统工程的实践中不断发现与总结出各种有效的方法，并根据系统设计的实际需要，结合自身的应用情境，总结提炼出一些系统开发的关键要素，并针对这些要素之间的相互关系进行分析与总结，提出了各种生命周期框架。这些框架既包括完成系统设计与开发的关键支持要素，也说明这些要素之间的相互关系，从而共同形成一个具有指导功能的载体。
1.系统生命周期的概念
每个系统都有生命周期（Life Cycle）（也称生存周期），生命周期可以采用抽象的功能模型来表述系统需求的概念，包括实现、使用、更新及退役。一般来说，人造系统都会经历如图3-6所示的系统生命周期。
图3-6 系统生命周期模型
那么，阶段之间怎么交接？如何保证整个系统生命周期过程的完整性？我们首先对如下几个与系统生命周期相关的关键概念进行介绍与说明。
1）阶段。从系统生命周期的概念中可以看出，人造系统的生命周期在顺序上存在人为的阶段划分，这也符合人们认识自然与改造自然的规律。根据事物发展顺序及工作关注重点不同而进行划分，其主要目的还是便于不同干系人进行有效的沟通与理解。
2）评审点（也称决策门、控制门、里程碑、关口等）。评审点就是在不同的阶段之间进行交接的决策点，既代表着项目执行到了一个特定的里程碑，也代表了评审上一个阶段项目活动的目标是否达成和下一个阶段的进入标准是否满足，其目的是管理阶段进度及评估相关交付物是否满足计划的需求目标，降低各种与产品开发相关的风险。其整体思想类似于采用阶段—关口 [10] 的方法处理开发过程中的问题。
3）基准。基准是指在产品生命周期特定时间制定，并且评审后获得批准的配置项版本。它可以是多种形式的文件，作为交接或评审条件是否满足的判断基准。对于比较复杂的大型工程项目，伴随生命周期过程，往往需要对系统进行技术状态管理（也称配置管理）。技术状态管理是指应用技术和行政管理手段对产品技术状态进行标识、控制、审核和记录的活动。技术状态是指在技术文件中规定的，并且产品需要达到的物理和功能特性。
示例
可以把求学过程简单地看成一个在校学习的生命周期，把整个求学过程中的每个年级看成一个个学习阶段，那么决定是否能够升级的标准在于每学期期末的考试成绩，考试是否能够通过则需要参照之前定义的基准，这样就构成了逐级升级的过程。
再比如，了解到客户想要一台能够炒菜的机器，需求方的关注点不是这台机器长什么样子、怎么设计、如何生产，而是如何满足需求，如何使用。对于产品设计开发人员，又可以分为不同的专业，如概念设计工程师、产品开发工程师、生产制造工程师、复杂支持的售后工程师等，他们分别在整个生命周期的不同阶段执行特定的项目活动。确定阶段分工后，就要定义阶段与阶段之间的交接方式，也就是评审点，在这个时间点判断是否能够进入下一个阶段，如定义在什么时间产品开发工程师需要把设计好的图纸等交接给生产制造工程师。确定交接的节点或时间后，就要确定交付的文档、设计、材料等是否能够满足下一个阶段开始的条件，这时就要将基准作为判断条件，或者进行比较与参考。这个基准通常是在项目之初，在计划阶段就定义好的。
2.ISO/IEC/IEEE 15288框架
不同的组织因产品类型不同，而可能对系统生命周期有不同的理解，各大型组织或行业机构也有自己的定义。本书统一采用国际标准化组织发布的ISO/IEC/IEEE 15288框架中的定义。原因在于，以一个国际化的视角与全球的可能相关方进行沟通，并根据自身的特点进行相关剪裁，这样既有助于在彼此沟通的过程中更好地理解双方需求，也可以在今后与国际组织合作时将其作为一个可以共同参考的基准，从而更好地进行沟通、交流或合作。
ISO/IEC/IEEE 15288框架是国际标准化组织发布的系统和软件工程—系统生命周期过程标准（也称系统生命周期流程；本书参考标准为2015年版）。 [11] 这个标准建立的目的在于构建一个描述系统生命周期的通用框架，并且定义一整套可以用于任何系统层次的相关流程和术语。
从图3-7中可以看出，系统生命周期既可以采用阶段的方式描述，也可以采用过程组的方式描述，但是其基本的组成部分都是过程，目的在于促进采购方与供应方及其他利益相关方在系统生命周期过程中的沟通。
图3-7 ISO/IEC/IEEE 15288框架
过程就是通过一系列相互联系或相互影响的活动把输入转变成输出。 [12] 生命周期过程的目的与意义包括如下三点。
● 每个生命周期过程的结果、活动和任务之间都有很强的相关性。
● 将过程之间的依赖关系减少到最大的可行范围。
● 过程能够在生命周期中由单个组织执行。
下面说明过程描述所需的要素，这些要素分为必需项与可选项，如图3-8所示。
图3-8 基本过程和构成要素
● 名称（Name）。用来概括描述过程范围并能够与其他过程进行区分的简短名词。
● 目的（Purpose）。一句话描述的该过程要达到的目标。
● 产出（Outcomes）。执行过程要得到的可量化或可关注的技术或商业结果。
● 活动（Activities）。用来描述一组为达成或执行过程所需要完成的被需要、建议、允许或执行的具体活动。
● 任务（Tasks）。为支持得到期望的过程产出而进行的需求、推荐或通常采取的活动。
● 输入（Inputs）。需要通过过程进行转换的条目。
● 输出（Outputs）。一些过程输出对于构建最终产品或服务是必不可少的。其他过程输出是中间产品，仅供顾客确认或审核员检查使用。过程输出主要有两种类型：工件和信息项。
● 控制及限制（Controls and Constrains）。指导或限制过程的性能。控制与法规等相关，限制则与外界环境或商业因素相关。
从图3-8中可以看出，过程输出的结果既可以是原型机、模型、信息等过程中给组织使用的中间结果，也可以是满足系统设计需求的产品或服务。其本质目的是解耦系统的复杂度，找到最小可以执行的一系列活动，从而获得期望的结果。
ISO/IEC/IEEE 15288框架将系统生命周期内需要执行的过程进行了分组，每个分组过程都有相对应的描述，包括目的及期望的输出和相应的活动和任务，以便通过过程实现期望的输出。
ISO/IEC/IEEE 15288框架包括4个过程组、30个过程，如图3-9所示。
图3-9 系统生命周期过程组
4个过程组简要介绍如下。
● 协议过程组。两个组织建立与产品或服务有关的协议所需的活动。
● 组织项目启动过程组。涉及提供使项目满足组织相关方的需求和期望所需的资源。
● 技术管理过程组。管理及应用分配的资源和资产，从而满足组织达成的或应该履行的协议的要求。
● 技术过程组。包括整个生命周期的各项技术活动，将利益相关方的需求转换成产品和服务。
如前所述，ISO/IEC/IEEE 15288框架也可以采用阶段描述，其中列出了6个阶段：概念、开发、生产、使用、运维、退役，并且每个阶段都设置了一个决策门，用来提供决策选择。在这个框架中，所有阶段都是可以重叠的，使用阶段和运维阶段是并行的。
在ISO/IEC/IEEE 15288框架中，无论是划分为阶段，还是划分为过程组，底层都是由过程组成的。 [13]
3.生命周期模型
如果仅仅按照系统生命周期阶段划分的方式来介绍生命周期概念，很容易让人认为所有的阶段过程都是单一顺序执行的，这显然不能满足现实工程实践中各种产品设计与开发的需要。实际上，针对不同的开发场景或不同行业，还有更多类型的生命周期模型被提出并广泛使用。
有些模型从表面上看是线性的、顺序执行的，但是在实际使用过程中，需要针对具体情况选择特定的模型，并采用增量或迭代的方式进行开发，而非限定在某个线性、特定的开发过程中。下面对几种典型的模型及其特点做简要说明，目的是让读者在实际项目开发过程中能够更灵活地应对各种不同开发场景。
1）瀑布模型。瀑布模型最早是由罗伊斯（Royce）在20世纪70年代提出的。瀑布模型比较适合这样的项目：开始时就可以对项目的范围、需求、进度、成本及各种资源有比较明确的定义，可以提前完成大部分项目规划工作。一般来说，采用瀑布模型开发的项目可以借鉴过往类似的项目经验或模板等。
如图3-10所示，瀑布模型的系统生命周期就是按照线性的顺序逐级而下，直到最后的交付。这是一种理想的示意模型，目的是让人更容易理解不同阶段发生的顺序。在实践中，存在不同阶段反复迭代的可能性，而非直接逐级向下。
图3-10 瀑布模型
实战分享
以下情况可以优先选择瀑布模型：充分了解拟交付的产品；有坚实的行业实践基础；整批一次性交付有利于干系人。在实际产品开发过程中，如软硬件结合的产品设计与开发领域，如果项目需求在前期比较明确且后期变化相对较小，就可以采用瀑布模型对产品进行开发。
使用瀑布模型的开发方法也称预测型方法，这种开发方法能够使项目团队在早期降低项目不确定性水平，并完成大部分项目规划工作。
2）V形模型。V形模型是20世纪80年代末期提出的，简单来说，就是将系统生命周期的各阶段组织成一个与字母V类似的结构，已被广泛应用于多个行业及领域。V形模型如图3-11所示。
从图3-11可以看出，V形模型分为左右两部分。左边部分顺序说明了市场需求、需求分析/可行性研究、概念设计、系统分析与设计、子系统设计、详细设计的阶段构成；软硬件开发阶段则衔接左右两端；右边部分的阶段包括单元测试、子系统验证、系统验证与部署、系统确认、运行与维护、变更与升级、退役或替代。
从另一个角度来看，针对V形模型的核心部分，左边侧重于产品的定义与分解过程，从系统到功能再到部件，逐层分解，体现了V形模型左边自上而下的设计与开发方式；而右边则侧重于集成与整合过程，从部件、子系统到最后完整系统逐级验证与整合，体现了V形模型右边自下而上的验证与审核的流程思想。从图3-11中可以看到V形模型核心部分所对应的每个层级的定义、设计及系统实现的逐级验证与确认的过程，其核心思想是一种左右对称的层级设计与验证的关系。
实战分享
V形模型依然是线性顺序类型的开发模型，其应用的前提是项目前期能做好需求分析，项目范围相对明确。V形模型的特点是将设计实现和开发验证的过程有机地结合起来，它包括单元测试和系统测试，可以在保证设计质量的前提下缩短开发周期。
在实际产品开发过程中，V形模型适用于需求明确、技术风险不高、容易实现代码或硬件模块化的产品开发场景。
图3-11 V形模型
3）螺旋模型。螺旋模型是最早由巴利·玻姆（Barry Boehm）提出的一种软件开发概念模型，由风险分析驱动并采用周期性方法进行系统开发。该模型通过在每个迭代阶段开发出相应原型的方式降低风险，在每个阶段过程或循环之前进行风险评估，针对对应循环的特点采用特定的过程模型，所以能够兼顾及融合诸如瀑布模型等其他模型的方法及特点。螺旋模型的最大特点是在融合其他模型的基础上引入风险分析过程。如图3-12所示，螺旋模型的每个循环都由以下四个活动构成。
图3-12 螺旋模型
（1）确定目标、方案和限制条件，考虑所有对成功至关重要的利益相关方的获胜条件。
（2）评估方案，识别并消除风险，识别并评估源自所选方法的风险。
（3）开发、测试、验证下一级产品，识别与评估满足获胜条件的不同方法。
（4）制订下一次迭代计划，获得所有对成功至关重要的利益相关方的批准，并承诺继续进行下一个周期。
实战分享
由于引入了风险识别、分析和控制，并采用周期性的方法进行开发，所以螺旋模型适用于新技术开发，能够确保在需求不明确的情况下对项目风险和需求变更进行良好的控制。
但是，由于引入了严格的风险管理环节，螺旋模型对人员、费用和时间的投入提出了更高的要求。
4）敏捷开发模型。敏捷开发模型是通过将任务分解成小的增量步骤（可以基于客户定义的优先级）来实现一组目标，只需要最小的计划，每步都会产生交付给客户的工作系统或子系统。敏捷开发模型的特点还在于能够实现跨专业职能团队在短时间内共同工作，因此，它有能力对动态环境中的变化做出快速反应，并使正在开发的系统适应已经产生的结果。
实践中有很多不同的敏捷开发模型，如极限编程（Extreme Programming，XP）、Scrum、动态系统开发方法（Dynamic Systems Development Method，DSDM）等。
在敏捷开发环境中与活动相关联的生命周期是由短期冲刺的迭代及评审主导的，图3-13是这种模型的一种示意图。 [14]
实战分享
以下情况可以优先选择敏捷开发模型：需要应对快速变化的环境；需求和范围难以事先确定；能够以有利于干系人的方式定义较小的增量改进。
敏捷开发模型强调整个项目团队（包括客户）的合作，并且快速输出可用成果；进行阶段性的评审，并且在下一阶段快速改进修正，变更灵活，能够降低项目开发风险并有效控制成本。其实际的产品开发过程应用，包括一些软件产品（计算机应用程序、操作系统等）、带嵌入式软件的产品、互联网应用产品等。
图3-13 敏捷开发模型
在实际的产品设计与开发过程中，可以根据实际场景，采用基于系统生命周期的顺序、迭代、增量和迭代加增量等开发方法，再引入风险分析要素，构建出很多种不同的项目开发模型，但其具体应用的核心思想仍然是针对特定场景，采取更好的方式或方法来获得最优的问题解决方案。充分吸收和运用这些模型的核心思想，针对具体场景和实际需要进行合理剪裁，这才是本书介绍这些模型的核心目的所在。
3.2.3 系统工程的未来
国际系统工程协会在2007年就给出了基于模型的系统工程（Model Based Systems Engineering，MBSE）的定义：“基于模型的系统工程是对系统工程活动中建模方法的正式认同，从概念定义阶段到开发阶段和后续的生命周期各阶段，都正式使用模型以支持需求、设计、分析、验证、确认等各项活动。”并且在2021年发布的《系统工程愿景2035》中提到，系统工程的未来主要是基于模型的。 [15]
基于模型的系统工程的目的是，从传统的基于文档和以代码为中心的设计方法逐渐走向基于模型的设计方法。数字化的文档和代码虽然都已经通过现代IT技术实现了有效的管理与储存，但是文档之间依然存在一定的割裂，需要人为管理，而文档关联的逻辑性及文档本身的可重用性等都存在一定的局限。采用基于模型的系统工程，以模型为中心，比传统的系统设计方法更先进，主要表现在整个工程从一开始就以模型的形式，对各种复杂的系统需求、结构设计、行为、仿真、性能、测试等进行无二义性的说明、分析、设计及追溯等，从而在产品的相关人员间建立一个统一的垂直交流平台，进而提高团队在应对复杂系统开发时的沟通效率，加强设计或问题的可追溯性，提升设计的可重用性，增强知识的获取和再利用。
基于模型的系统工程可以让项目干系人通过模型来多角度分析系统，评估变更的影响，管理系统的复杂度并提升设计质量，也支持通过模型在设计早期进行相应的检验和确认，以发现潜在的设计缺陷，从而降低设计风险，加快设计进度，减少开发费用。
但是，如果想要全面实现基于模型的系统工程，需要有相应的方法论、系统建模语言，以及支持系统建模管理的各种工具，并且系统设计本身也因不同行业及产品的特点而具有相应独特的产品属性，所以当前基于模型的系统设计还在发展完善的过程中。
无论未来如何发展，基于模型的系统工程方法的最终目的还是降低复杂团队沟通的成本，提高流程执行的效率，避免系统性风险。
本书的内容仍然基于传统系统工程方法，但是基于模型的系统工程方法的思想是可以借鉴及剪切使用的。实际上，传统方法论的产品领域本身也在不断迭代发展，不断吸收新的工程方法并运用到开发中，如现代设计过程更多地采用建模与仿真的方式来论证产品开发，这就是一个向基于模型的开发方法逐渐过渡的过程。相信，随着各项技术及工具的不断发展，未来会有越来越多的企业，开始由文档设计走向采用模型化、数字化、结构化设计的基于模型的系统工程方法。
3.2.4 系统工程与项目管理的关系
系统工程也是方法论，它站在系统整体角度，运用多个学科的知识支持系统的设计、开发、技术管理、运行、部署及最后的退役。实际上，从项目开发角度来看，系统工程是站在项目管理角度，从技术维度支持产品开发的一种方法。
项目管理的范围包括与项目开发相关的方方面面，如对开发团队、采购、技术、进度、预算、风险及干系人的管理等。这些不同方向的管理，本身并不是孤立存在的，而是彼此之间有所关联的。系统工程作为支持项目开发的一种方法或管理手段，则更关注技术及系统开发的角度。应该说，项目管理涵盖更大的范围，而系统工程本质上是项目管理范围内的一个部分，是为项目服务的，也是为达成项目目标而采取的一种有效的方法或手段。项目管理背景下的系统工程如图3-14所示。
在IT类复杂软硬件相结合的产品开发领域，项目团队中一般有两个主要的角色作为整个项目开发的牵头人：一个是项目经理，另一个是系统工程师。前者负责整个项目资源、进度、沟通及费用等方面的管理，而后者则主要从项目整体出发，从技术的角度对项目开发中的各部分进行组织、协调及问题处理等。在实际工作中，二者相互配合，带领整个项目团队完成项目的开发。这是否意味着二者有明确的界限或完全没有交叠呢？答案显然不是这样的，两个角色都要为项目的进度负责，都要识别项目风险等。在《NASA系统工程手册》中也有说明，管理一个项目主要包含三大目标：从技术角度管理项目、管理项目团队及管理项目进度与成本。 [16] 从图3-14中可以看出，项目计划与控制的功能更关注识别和控制项目成本与进度。项目经理需要站在整个项目的角度对项目团队进行管理，保证交付物在可控的开发进度与成本范围内，并保证交付技术满足需求的结果。
图3-14 项目管理背景下的系统工程
系统工程方法论在20世纪40年代提出，接着在军事研发、太空探索及软件开发领域得到了更多实践与验证，显示出巨大威力，在日益复杂的产品设计与开发过程中发挥着越来越重要的作用，也越来越受众多中小企业的重视。好的、合适的系统开发流程不但能够极大提升产品设计与开发的效率，也能降低企业运行成本及执行过程的风险。由于每家企业的发展阶段及侧重点有所不同，因此需要根据企业或组织的实际情况进行合理取舍。
理论上的各种工程方法论或生命周期模型往往因为过于抽象，一般并不能直接应用；并且针对某些特定的应用场景，如果单独使用某种方法可能无法满足实际需要，因此应在实际应用中对符合相应应用场景的各种方法或模型进行剪裁，使之更适合各家企业的具体情况。但是能够对方法或模型进行合理剪裁的前提是，既要对整个设计与开发流程有深刻的理解，也要对各种方法论或模型的真正含义有深刻的理解，这些因素都为实际的剪裁、使用带来了一定的困难。本书通过介绍一套完整的产品设计与开发的框架与流程，以及实际案例的说明，使读者能够更加清楚地理解具体执行过程建立的目的和意义，以及如何在实际项目中进行剪裁、使用。
3.3.1 产品设计与开发框架
从广义上来说，产品是指能够满足人们各种使用和消费需要的任何东西，包括有形与无形的产品或服务等。在本书中，产品是指具备系统特点的复杂产品，构成要素并不单一，涉及的技术领域多样，其过程需要由多个专业人才构成的团队通过协作才能完成，具备复杂系统工程的特点。因此，需要大批量生产的复杂产品的设计与开发过程就是本书主要介绍的内容。
本书中的产品设计与开发是指为满足人们对复杂产品需求的设计与开发过程，是从产品设计与开发角度来阐述产品从需求提出到最终交付给客户的整个复杂问题解决过程。为了更好地理解产品设计与开发过程，下面给出产品设计与开发框架，以此说明产品从需求提出到最终交付需要完成的主要任务。
如图3-15所示，产品设计与开发框架在组成上可以分为三部分，即产品创新设计、产品开发实践及产品问题解决。在顺序上可分为两个阶段，即产品创新设计与产品开发实践。
图3-15 产品设计与开发框架
1）产品创新设计。在正式投入大量开发资源之前所进行的各种创新设计与评估阶段的工作，所有工作都为下个阶段的开发执行做好决策和计划上的准备。
2）产品开发实践。经过创新设计阶段的评估、设计及评审决策，正式批准所有的资源投入，进入产品开发的执行阶段。包括从产品具体开发到交付的整个工程实践过程。
3）产品问题解决。产品问题解决在整个产品设计与开发过程中发挥着重要作用。无论是哪个阶段、哪个环节都需要解决各种类型的复杂问题，既要兼顾产品开发的流程、步骤、计划与执行，又要采用科学合理的方法与手段，解决可能遇到的各种复杂而棘手的问题，交付产品，创造价值。
3.3.2 产品设计与开发流程
产品设计与开发流程的制定，既需要站在技术及工程的角度，结合系统工程的方法论，兼顾整体，又需要站在项目管理的角度，管理项目范围、进度周期、项目成本等方面。所以，在流程制定上，需要在项目管理的框架内，采用系统工程的思想及方法进行设计与开发。
另外，对于产品设计与开发流程，站在不同的角度可以有不同的理解。
● 从项目管理角度，可以分为三个阶段，包括立项阶段、工程设计与验证阶段及生产交付与运维阶段。
● 从设计与开发角度，可以分为两个阶段，包括产品创新设计阶段和产品开发实践阶段。
这里提到的两个角度，将在更下层的子阶段实现项目分解执行层面的统一。这体现出，每个项目干系人站在不同立场与视角看待问题的过程可能是不一样的。站在设计与开发角度看待问题，设计意味着对客户的要求进行规划，而开发则意味着对规划的结果逐步进行工程实现，直到产品完成生产交付客户甚至产品生命周期结束。从子阶段细分及项目执行角度，项目管理、设计与开发就又统一为一体了，其差异则体现在项目经理与系统工程师的职责与内容上的差异。
如图3-16所示，本书介绍的产品设计与开发流程的阶段划分方式，是笔者通过自身实践，结合主流项目管理理论总结出来的，也就是从项目管理角度将项目分为三个主阶段及八个子阶段，从系统工程角度把整个项目设计与开发看成两个主阶段及八个子阶段，其中八个子阶段的内容与《产品化项目管理之路》 [17] 中的子阶段划分实现了统一，其划分理念也是一致的，这也体现了产品设计与开发流程本身是包括在项目管理范围内的一个更下一层项目活动的分解结果。下面从设计与开发的技术角度对两个主阶段及八个子阶段做说明与介绍。
图3-16 产品设计与开发流程
1.产品创新设计
主要介绍从产品需求、产品概念定义、可行性分析到项目计划的整个产品创新的设计过程，重点在于创新设计的过程，包括确认需求和设计目标、概念设计、顶层系统设计、可行性分析及产品设计与开发方案的最终选择与确认等环节。
产品创新设计阶段的核心在于从技术角度对需求进行各种评估及具体开发执行前的决策。主要包括以下四个子阶段。
1）产品需求。站在技术的角度分析从需求识别到需求创新，考虑如何更好地理解客户和市场的需求；同时要考虑产品创新的竞争力需要，在满足不同层次创新的同时真正实现交付有竞争力、有价值的产品或服务。
2）产品概念定义。从概念到系统框架设计，再分解到功能或子模块设计，从而站在产品的整体设计角度实现产品设计与开发的协调与优化，关注并协调满足多个利益相关方在整个系统开发过程中不同的关注点。
3）可行性分析。通过多种方式、方法及手段识别出产品创新设计与开发过程中可能遇到的各种不确定性的问题，并给出各种相应的解决方法，从而提出多个可行的设计方案，如采用建模和仿真技术等方法评估满足各种需求的方案，最终交付多个可供选择的设计方案。
4）项目计划。完成可行性分析后，再结合产品需求、概念定义等先前的工作输出，将产品设计与开发工作分解为可执行的最小活动单位，用以评估执行项目活动所需的工作量、费用、进度等的详细方案，从而制订具体的项目执行计划。
产品创新设计阶段评审点的几个关键条件如下。
● 设计计划是否满足客户的真实需求？
● 技术上是否可以实现？
● 进度上是否可以满足？
● 资源上是否可以满足？
● 是否具有竞争力？
● 是否具有创新点？
● 方案上是否最优？
● 各项风险是否都可控？
● 各种前期所需的设计文档是否齐全？
● 采用何种流程和方法满足当前设计的要求？
2.产品开发实践
主要介绍产品开发执行的整个过程，包括详细的产品开发、制订测试计划、执行单元测试验证、系统设计验证、系统整合确认、工厂生产、批量生产测试、交付产品到运维管理等整个过程。
产品开发实践阶段主要包括以下四个子阶段。
1）设计开发。进入设计开发阶段意味着逐步把设计的框架结合理论，变换成图纸、代码，然后进行样机生产或系统整合，交付能够满足期望功能的物理样机或原型机。
2）测试验证。测试与验证决定着产品是否能够满足设计要求、功能要求、质量要求及批量生产要求等。这个阶段既包括基本的功能确认，也包括实际产品系统测试所需的各项验证与确认过程。
3）生产交付。能够实现产品的批量生产，才能从供应链的角度及工业化生产的角度交付价值，而只有交付到客户手中真正使用才能够体现出产品的价值。技术上如何实现批量生产、如何高效交付、如何方便客户使用也是开发的关键。
4）升级维护。产品在使用过程中遇到的各种问题或新的需求，在产品设计与开发阶段就要考虑，但是总有无法覆盖的场景和最初不能满足的需求，在产品交付后才能够识别并通过升级满足，这就要求在已有产品的基础上再次进行更新与开发，以满足客户需求。
产品开发实践阶段需要实现最终产品或服务的交付，其评审点的几个关键条件如下。
● 采用的开发方法是否合适？
● 执行的步骤是否完备？
● 技术培训是否按照计划完成？
● 设计计划中的风险是否已经消除？
● 测试验证的结果是否满足设计需要？
● 所有问题是否都已经解决？
● 产品是否达到设计上的系统最优？
● 批量生产等目标是否达成？
3.产品问题解决
这种活动贯穿整个产品设计与开发流程，既要解决设计阶段的问题，又要解决开发过程中可能遇到的问题。产品问题解决可以参考如下原则。
● 如同医学上没有一种药能够包治百病，具体问题只有放置在特定场景下进行分析与处理才有意义。
● 能解决问题的不一定都是专家，人人都可以提出非常优秀的点子，从而解决问题。
● 解决问题的方法可以是突破性、启发性的，关键是能解决问题，而尽量不要引入新的问题。
● 发挥集体的智慧，协调集体完成解决方案的导入与执行。
1.系统方法的掌握及运用可以启发或帮助读者解决各种工程问题的挑战。
2.学会系统思考是解决工作和生活问题的第一步，也是最重要的一步。
3.没有一种方法或模型可以解决所有问题，最适合的才是最好的。
4.产品设计与开发流程展示了从技术开发角度来看，产品是如何从需求到交付的，给出了一个经实践验证有效的参考模型。
5.产品设计与开发的关键点是，在实现项目目标交付产品的同时，思考如何降低成本、提高质量、加快进度、提高竞争力、可批量生产、有高价值、满足真实需求、体验良好、具备新功能、采用新技术、提升性能。