系统架构：复杂系统的产品设计与开发

什么是系统思维？

系统思维是一种把疑问、状况或难题明确视为系统的思维方式。而系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。所以，系统思维就是将疑问、状况或难题视为一组相互关联的实体的思维方式。

系统思维方法

如何把目标当作系统来思考？

系统思维的目标是令我们能够对系统进行思考。使得我们可以更轻松的理解复杂系统。

系统的关键特征	系统思维的任务
系统具备形式及功能，形式是功能的载体	确定系统及其形式与功能
系统由实体组成，每个实体均具备其形式及功能。一般来说，这些实体本身也是系统，而系统自身也有可能是更大系统中的一个实体	确定系统中的实体及其形式与功能，以及系统的边界和系统的外部环境
系统的实体之间通过关系相连，而关系具备形式特征和功能特征。某些实体会和系统之外的实体发生关系，那些实体处在系统的外部环境中	确定系统中的各实体之间所具有的关系，以及系统内的实体与系统边界处的实体之间所具有的关系，并确定这些关系的形式及功能 - 确定如何将系统初步分解为恰当的实体 - 用整体思维找出潜在的实体 - 通过对重点的分析，把注意力集中到重要的实体上 - 为实体创建抽象 - 定义系统的边界，并将其与外界环境隔开
系统的功能和其他特征，是随着其实体之间发生功能交互而涌现出来的，而功能的交互，又是由实体之间的形式关系而引领的。涌现物使得系统具备强大的能力，使得其功能大于所有部件各自的功能之和	根据实体的功能及实体间的功能交互，来确定系统的涌现属性

如何思考复杂系统？

理解并管理复杂度的工具

• 系统分解：横向切分（分层）、纵向切分（分模块）
• 梳理关系：类/实例的关系（特化/泛化关系）、递归关系
• 思考方式；自顶向下、自底向上、交替思考

复杂系统的定义

• 简单系统：分解一次就可以将其完整描述出来的系统
• 复杂度适中的系统：分解两次，每个上级部件的下级数量不超过7个左右，即最多81个组件可描述清楚的系统
• 复杂系统：分解两次后还有抽象元素的系统

思考复杂系统的方式

复杂系统的特点	思考复杂系统所用的方式
系统可以反复分解，每次分解出的实体都越来越小，也越来越专业	- 把系统分解为实体 - 判断这些实体之间是否呈现出体系 - 把实体排布到体系中的适当位置上 - 继缕进行分解，直到形成了两个抽象层，或是遇到了原子部件为止
系统中的实体之间有着某种特定的逻辑关系	- 从实体中确定类及类的实例 - 确定实体之间的特化和泛化关系 - 确定实体是否以递归的方式使用或出现
复杂的系统中蕴含着几种关系模式，我们可以利用这些模式来思考系统	- 自顶向下、自底向上、由内而外地思考系统 - 在形式领域和功能领域之间交替地恩考 - 确定当前系统、伴生系统以及使用情境 - 在某个级别中，确定价值通路层及支援实体层 - 功能 - 目标式的思考：某一级别的功能是其下一级别的目标 - 先向下考虑两个级别，然后再回溯一个级别，以确定适当的整理方式与分组方式
可以为架构创建视图或对架构进行投射，以增强对系统的理解	- 使用 SysML 等工具为系统构建协调一致的视图 - 使用 OPM 等工具从维度更高的模型中进行投射，以创建协调一致的视图

如何分析系统架构？

分析形式

• 找到一个合适的抽象层级，定义为系统
• 向下分解，确定形式实体，并对实体进行适当的分层
• 确定形式实体之间的关系
  • 找出所有可能关系（空间/拓扑关系、连接关系、地址关系、顺序关系、成员关系、所有权关系、人际关系等）
  • 评估可能功能
  • 确定合适的关系
• 确定形式环境
  • 确定整个产品系统：本系统 + 伴生系统
  • 确定系统边界：本系统的边界在哪里
  • 确定使用情景（Use Context）：整个产品系统在什么情况下被使用

分析功能

• 识别外部主要功能（体现业务价值的功能）
• 确定内部功能实体（含操作数和过程）
• 确定功能交互
  • 首先绘制一张内部功能图，图中必须包含与价值相关的操作数
  • 检查图中是否漏掉了显然应该有的过程，例如输入过程与输出过程
  • 检查内部过程图中是否漏掉了明显应该有的操作数，例如输入值等
  • 检查每一项过程，看看该过程是否还必须使用其他一些操作数，才能把功能完整地呈现出来
  • 检查每一个操作数，看看该操作数是否还与其他过程相交互
  • 从与价值有关的输出值开始i，回溯整个路径，并考虑我们想要的涌现物是否能够从这些过程及操作数中涌现出来
• 确定功能架构
  • 对操作数所进行的交换，形成了过程之间的交互，而操作数与内部过程相结合，则构成了功能架构
• 确定与价值相关的次要外部功能及内部功能

建立功能与形式的映射

确定形式与过程之间的映射

• 找出所有重要的形式元素
• 找出与价值有关的内部过程和操作数
• 考虑执行每个过程时所需要的形式实体
• 将形式元素映射到内部过程
• 针对每个还没有能够与内部过程建立映射的形式元素，试着思考它可能会与哪个过程相映射，并考虑目前有没有必要把该过程表示出来

确定形式结构是如何承载功能和性能的

• 在形式元素之间的各种关系中，把有可能起到重要作用的结构关系找出来
• 把相关的内部过程之间进行的功能交互找出来
• 针对每一个功能交互，找出对该交互起着必要做中的形式结构
• 把对性能方面的涌现属性与以「某某性」为名的那些性质起着展示作用的形式结构找出来
• 根据对重要的功能交互起到必要支撑作用的结构关系，来对已经找到的形式结构进行增删或修改

如何构建系统架构？

确定系统需求

• 确定受益者和利益相关者
• 确定受益者和利益相关者的需求
• 对需求进行优先级排序
• 基于SPS将需求转化为目标

SPS（系统问题陈述）

系统问题陈述（System Problem Statement，SPS）：是一项论述，它指出了系统为体现其价值而打算完成的事情，若能完成这件事，则表明系统取得了真正的成功。和Scrum中的DoD（Definition of Done）本质上是一致的。

与DoD的主要区别是，DoD是为了明确完成的标准。而SPS是为了让干系人迅速的理解目标，毕竟大几十页的需求文档很难让人快速明确系统目标。

SPS的结构：

• 为了…【对与特定解决方案无关的意图所作的陈述】
• 通过做某事【对与特定解决方案相关的功能所做的陈述】
• 使用【对形式所做的陈述】

确定系统概念

提出概念

• 对目标进行分析，以确定出涉及系统价值且与特定解决方案无关的操作数及过程
• 运用创造力进行特化，以确定出一套由具体的操作数（operand）/过程（process）/工具（instrument）所组成的概念
• 对我们提出的每一个概念进行检查，看看它是否与目标相符，如果有必要，可以对与特定解决方案无关的陈述进行调整

扩充概念并提出概念片段

• 针对蕴含着多个功能的丰富概念进行扩充或分解，以揭示其中的主要内部功能，或揭示出扩展之后的操作数/过程/工具
• 针对刚才发现的每一套操作数/过程/工具，再次运用「提出概念」这个大步骤下面的各条小步骤，以确定出操作数/过程/工具格式的概念片段

演化并完善整体概念

• 在概念和概念片段的空间中系统地进行搜寻，以确保没有遗漏
• 在满足约束条件的前提下，将概念片段以各种组合方式进行组合，以确定整体概念

选出几个整体概念，进行进一步的发展

• 运用逆向思维来思考：哪个概念最有可能满足系统目标？
• 运用整箱思维来思考：哪个概念最有可能做出好的架构？
• 对选出的这些概念进行检查，看看它们是否能够满足目标，同时也可以对其进行必要的调整

研发系统架构

把概念扩展为功能架构

• 从整体概念中确定关键的内部函数（问题5b），并将这些函数从输入端或起点一直链接到输出端或终点
• 基于上述结果，确定系统在体现其主要价值时所依循的价值通路

定义形式

从功能领域切换到形式领域：基于问题4a～4f，定义系统形式。具体流程参考分析形式

把功能映射为形式

具体流程参考建立功能与形式的映射

研发系统之下第2级的架构

• 流程与研发系统架构流程一致
• 把上一级中的解决方案当作下一级中的问题描述（功能-目标思考法）

功能-目标思考法

系统架构过程中涉及的问题

• 7a. 谁是受益者？他们的需求是什么？为了满足需求，需要改变哪一个与特定解决方案无关的操作数的状态？与价值有关的属性是什么，改变状态所用的与特定解决方案无关的过程是什么？这些操作数和过程，还具备其他哪些属性？
• 5a. 系统对外体现的、与价值相关的主要功能是什么？与价值相关的「特定」操作数是什么，该操作数具备哪些与价值相关的状态，这些状态如何为「特定的」过程所改变？对工具形式所做的抽象是什么？[概念是什么？还有其他哪些概念也能够满足于特定解决方案无关的功能？]
• 5b. 主要的内部功能是什么？内部操作数与过程是什么？[对这些过程所做的特化是什么？概念片段是什么？整体概念是什么？操作概念是什么？]
• 5c. 功能架构是什么？这些内部功能是怎样连接成价值通路的？主要的外部功能是怎样涌现出来的？
• 5d. 其他较为重要且与价值有关的次要外部功能是什么？它们是如何从内部功能及价值通路中涌现出来的？
• 4a. 系统是什么？
• 4b. 主要的形式元素是什么？
• 4c. 形式结构是什么？
• 4d. 伴生系统是什么？整个产品系统是什么？
• 4e. 系统边界是什么？接口是什么？
• 4f. 使用情境是什么？
• 6a. 工具对象怎样与内部过程相映射？形式结构怎样支持功能交互？怎样影响系统的涌现物？
• 6b. 在实际的内部价值创建路径中，非理想的因素使得我们必须安排哪些操作数、过程及工具性的形式对象？
• 6c. 有哪些起到支持作用的功能及工具能够为价值创建路径中的工具对象提供支持？
• 6d. 有哪些接口位于系统边界上？有哪些需要传递或共享的操作数？接口所在的地方有哪些过程？构成接口的工具对象是什么？这些对象之间有何关联（是相同的对象，还是相兼容的对象）？
• 6e. 与体现主要功能和次要功能有关的那些过程是按照什么顺序来执行的？
• 6f. 还有没有其他功能也在同时按顺序执行着？
• 6g. 实际的时钟时间对理解系统的操作来说是否起着重要的作用？还有没有时间方面的问题或限制需要处理？
• 8a. 怎样把系统之下第1级的架构扩展到系统之下第2级？
• 8b. 用什么样的方案可以对系统之下第2级的对象进行模块化？

关键概念

• 涌现：指系统在运作时所表现、呈现或浮现出的东西。涌现仅发生在功能领域，不会发生在形式领域。预测涌现物的方法：⓵ 根据以前做过的情况来预测，也就是根据先例来预测。⓶ 做试验。 ⓷ 建模。
• 形式（form）：指这个系统是什么样子，它是一种已然存在或有可能存在的物质载体或信息载体。形式是功能的载体。
• 功能（function）：系统能够做什么。它是能够引发并创造某种性能，或是对性能有所贡献的活动、操作及转换行为。它由过程和操作数组成。
  • 过程：功能中表示动作或转换的那部分，也就是改变操作数状态的那一部分
  • 操作数：是其状态会在过程中发生改变的事物
• 行为：行为是由功能以及与功能相关的状态变化情况所构成的序列，系统中的形式对象，应该按照这个顺序来执行各项功能，以便使系统的价值得以体现。
• 系统架构：系统架构是概念的体现，是对物理的/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所作的定义
• 概念：
  • 用来在形式与功能之间创建映射。虽然概念与架构都包含着从功能到形式的映射，但概念是以一种通用的方式，来解释功能是如何映射到形式的。
  • 是对系统架构的一种简化，有助于我们对架构进行宏观的探索。
  • 是一个过渡点，使我们的思维从与特定解决方案无关的方面，转换到与特定解决方案相关的方面。
• 形式关系：是某段时间内稳定存在或有可能稳定存在的实体之间所具备的关系。也称为结构关系。形式关系是功能关系的载体。
• 功能关系：是指用来完成某件事情的实体之间所具备的关系，此关系可能涉及实体之间对某物的操作、传输或交换。也称为交互关系。
• 元素（element）：强调系统形式中的某个方面。同义词是「部分(part）」、或「部件(piece）」
• 实体（entity）：泛指形式及功能。同义词是「单元(unit）」或「事物(thing）」
• 原子部件：凡是一经拆解就失去意义的东西，就可以称为原子部件
• 需求：受益者的意愿或所需要的东西。通常是以一种模糊或宽泛的方式来表达的。
• 目标：规定了所构建的系统应该怎样去满足受益者所提出的需求。