敏捷系统工程

　　敏捷系统工程AgileSystemsEngineering

　　《敏捷系统工程》表达了系统工程的一种愿景，即在敏捷的工程背景环境中，精确的需求规范、结构和行为可以满足系统安全性、安保性、可靠性以及性能等更大的关注。

　　世界著名的作家及演说家BrucePowelDouglass博士将敏捷方法和基于模型的系统工程(MBSE)有机结合在一起，定义了系统整体的特性，从而避免传统的基于文档规范的方式所带来的错误。

　　《敏捷系统工程》阐述了系统开发的整个生命周期，包括需求、分析、设计以及向特定工程学科的转交。Douglass博士自始至终都将敏捷方法与SysML和MBSE相结合，进而为系统工程师提供概念和方法层面应用的流程指南，使他们可以避免规范中的缺陷并改进系统的质量。与此同时，敏捷方法可以降低系统工程的工作和成本。主要特色

　　◆识别出在系统工程的环境中如何更有效地应用敏捷方法的概念和技术

　　◆展示了如何进行基于模型的功能分析并将分析的结果往回与系统需求和利益攸关者需要相关联，并往前与系统架构和接口定义相关联

　　◆提供了一种用于保证系统工程数据质量和正确性的方式(并且是在系统建造之前)

　　◆解释了敏捷系统架构的规范以及系统功能到系统组件的分配

　　◆阐释了如何将工程规范数据传递到下游工程而不发生保真度的丢失

　　◆包括了跨行业系统全生命周期中不同阶段的详细案例，其中以工业外骨骼“Waldo”为例介绍了复杂系统的系统工程过程

　　BrucePowelDouglass3岁时开始自学读书，不到12岁就开始学习微积分。他14岁辍学游历美国，几年后进入俄勒冈大学学习数学专业。他*终获得俄勒冈大学运动生理学科学硕士学位以及USD医学院神经生理学博士学位。他在USD医学院期间提出了一个名为自相关因子分析的数学分支，用于研究多细胞生物神经系统中的信息处理。

　　Bruce作为软件开发人员和系统工程师在实时嵌入式系统领域已经工作超过30年，是实时嵌入式系统领域著名的演说家、作者与顾问。他是嵌入式系统大会和UML世界大会的顾问委员会的成员之一，并在会议上讲授过关于系统工程、项目估算和调度、项目管理、面向对象的分析与设计、通信协议、有限状态机、设计模式以及安全性关键系统设计方面的课程。Bruce在实时系统、软件设计以及项目管理方面有多年的开发、授课与咨询经验。他还为很多(特别是实时领域内的)杂志和期刊撰文。

　　Bruce是IBM物联网(IoT)业务部的首席布道师。作为首席布道师，除了披荆斩棘开拓道路，他更像是一位首席科学家。Bruce与UML合作伙伴在UML与SysML标准的规定方面密切合作。他开发了用于Rhapsody建模工具的第*个DoDAF的UML概要以及其他概要，例如故障树分析概要以及安保性分析概要。他是对象管理组组织的实时分析和设计工作组的副主席。他还撰写了其他几本关于系统与软件开发方面的书籍，包括DoingHardTime:DevelopingReal-TimeSystemswithUML,Objects,FrameworksandPatterns(Addison-Wesley,1999)、Real-TimeDesignPatterns:RobustScalableArchitectureforReal-TimeSystems(Addison-Wesley,2002)、Real-TimeUML3rdEdition:AdvancesintheUMLforReal-TimeSystems(Addison-Wesley,2004)、Real-TimeAgility(Addison-Wesley,2009)、DesignPatternsforEmbeddedSystemsinC(Elsevier,2011)、Real-TimeUMLWorkshopforEmbeddedSystems(Elsevier,2014)等，以及一本关于乒乓球方面的短篇教材。

　　Bruce喜欢古典音乐，古典吉他弹奏水平达到专业水准。他参加过多场体育比赛，包括乒乓球、自行车极限马拉松赛、赛跑以及全接触跆拳道，尽管目前还只是与打不还手的静物交手。他*近重新回到三项全能运动比赛以及自行车极限马拉松赛，并在2014年首次参加了铁人三项比赛。

　　Bruce在全世界进行广泛咨询与培训活动。如果你对此感兴趣，可以通过[email protected]与他联系。

《敏捷系统工程》中的方法基于作者的Harmony敏捷系统工程流程。该流程有关软件开发方面的部分在其他文献中有详细描述.。《敏捷系统工程》仅涉及系统工程的关注点。Harmony敏捷系统工程流程是一种敏捷的、以模型为中心的实施途径，用于开发系统工程所需的工程数据；需求、架构、接口以及可依赖性分析是其中*重要的内容。Harmony流程是依据作者在全球范围内所指导完成、取得飞速进展并在其他方面发挥作用的实际项目上累积的数十年系统经验提出和完善的。

前 言
产品的功能和复杂性正在成倍地增加，而且对这些系统的安全性、可靠性以及安保性的关注使得这样的系统对工程师而言更加困难。同时，产品开发周期正在萎缩。很显然，变革是需要的。我们需要能够以更少的时间制造出更有能力且缺陷更少的系统。
针对此问题，一个受到高度评价的解决方案是避免以文本作为捕获工程数据的主要手段。虽然文本具有极好的表现力，但是它是有歧义的，而且是极其不严谨的。使用更加正规的定义语言(这里，显然是指UML和SysML)进行建模是要力求改善特定的工程数据。只要我们能够想出改进的方式即可。
另一个所提供的解决方案是敏捷方法。尽管敏捷方法已经开始应用于嵌入式和实时系统，但这些方法却是由软件IT行业开发的。然而，敏捷文献(几乎)完全关注在台式机或IT软件开发上。他们考虑的开发环境(几乎)全部都是同地域小型团队的合作，并不关注安全性、可靠性或安保性问题；而且没有与电子或机械部件的联合开发。因此，系统工程师想要知道的是“这种方法如何适用于‘我’和我的工作”。敏捷文献没有给出答案。
有一些关于系统工程的很好的书籍，也有一些关于SysML与基于模型的系统工程(MBSE)的很好的书籍。有许多关于软件的敏捷方法的书籍(其中一些书籍也是很好的)。然而，目前还没有书籍来尝试将这些概念综合为一种一致且可用的系统工程方法。《敏捷系统工程》的目的就在于满足这种需要。
我们首先简单地介绍了系统工程学科，之后又简短讨论了敏捷方法，因为它们在大多数系统文献中都有论述，包括其益处。除前言部分外，还有一章内容关于基本的SysML。接着，我们就开始理解如何在现实生活中应用MBSE。
《敏捷系统工程》中的方法基于作者的Harmony敏捷系统工程流程。该流程有关软件开发方面的部分在其他文献中有详细描述a；《敏捷系统工程》仅涉及系统工程的关注点。Harmony敏捷系统工程流程是一种敏捷的、以模型为中心的实施途径，用于开发系统工程所需的工程数据；需求、架构、接口以及可依赖性分析是其中最重要的内容。Harmony流程是依据作者在全球范围内所指导完成、取得飞速进展并在其他方面发挥作用的实际项目上累积的数十年系统经验提出和完善的。
在教育工作者中有这样一种说法——“我示你看。我讲你听。你做你懂”。为此，《敏捷系统工程》中有大量示例用于阐明执行所涉及的工程步骤的细节。这些示例涉及工程学科的多个方面，包括软件、电子和机械工程。这些示例中的第一个示例是高端跑步机。第二个更复杂的示例是能够承载1500千克的可穿戴工业用机器人外骨骼(被称为waldo)。Harmony敏捷系统工程流程的每个主要活动都是以这些和其他示例展开讨论和演示的。我们鼓励读者针对提出的问题构建自己的解决方案并建立这些章节中所描述的模型。
a　例如，参见Real-Time Agility(Addison-Wesley, 2009)或Real-Time UML Workshop for Embedded Systems(Elsevier， 2014)。
X 敏捷系统工程
读者
《敏捷系统工程》的主要读者不言而喻是系统工程师。系统工程师的主要关注点集中在(通常)由多个工程学科所实施的系统规范与设计上。系统工程师规定了产品的系统特性而将学科特有的细节留给适当的下游工程团队。一些下游工程师也可能在《敏捷系统工程》中找到感兴趣的信息，特别是系统工程数据如何被格式化并采纳以满足转交活动中他们需要的细节。
目标
在游历世界期间，我感受到系统工程师在应用MBSE方法时所遇到的困难。主要的语言——SysML——令人望而生畏。SysML包括800页左右的UML规范并且增加了数百页。它是一种功能极为强大但是十分复杂的语言。
除了语言本身，随着产品复杂性成倍增加以及产品交付周期的不断缩减，亟须同时提高系统工程工作的效率并改进质量。我们看到系统在安全关键的、高可靠性和安保性环境中正日益取代人类，并且我们必须能够始终依靠这些系统的功能正常运转。
《敏捷系统工程》有一个简单目标——为系统工程师提供足够的指导，以便他们能方便有效地将敏捷方法和MBSE应用到复杂系统的开发中，因为现实世界越来越依赖于这些系统的运行。
工具
《敏捷系统工程》中的所有建模示例都使用IBM? Rhapsody?工具进行建模。然而，关于标准的一个好处是对不同工具的多种选择。如果你偏爱的其他工具支持SysML标准，那么你用你选择的工具建立这些模型时应该不会遇到什么困难。这不是一本关于Rhapsody的书，也不是专用于Rhapsody的书。
拓展
如果你对工具、培训或咨询感兴趣，参见www.ibm.com。我在世界范围内教授关于UML、SysML、MDA、DoDAF、架构设计、设计模式、需求建模、用例、安全性关键开发、行为建模、开发流程改进、项目管理与调度等多门高等课程并提供咨询。你可通过[email protected]就培训或咨询服务与我联系。我还开通了一个(免费的)yahoo群组论坛，网址是http://groups.yahoo.com/group/RT-UML——快来参与吧！My IBM Thought Leader页面(http://www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html)也包含你可能感兴趣的白皮书，其涉及不同课题并可供下载。
Bruce Powel Douglass博士

目 录

第1章 什么是基于模型的系统工程 1
1.1 关键的系统工程活动 1
1.1.1 识别客户需要 2
1.1.2 规定系统需求 2
1.1.3 评估可依赖性 3
1.1.4 评价备选架构和技术 3
1.1.5 选择特定架构和技术 4
1.1.6 分配需求和接口到架构 4
1.1.7 向下游工程转交 4
1.1.8 将学科特定的设计综合至系统组成 5
1.1.9 以整体验证系统 5
1.1.10 系统确认 8
1.2 系统工程数据 8
1.2.1 系统开发规划 8
1.2.2 利益攸关者需求 9
1.2.3 系统需求 9
1.2.4 认证规划 9
1.2.5 子系统需求 9
1.2.6 学科特定的需求 9
1.2.7 安全性分析 10
1.2.8 可靠性分析 10
1.2.9 安保性分析 10
1.2.10 系统架构 10
1.2.11 综合测试规划 11
1.2.12 综合测试 11
1.2.13 验证规划 11
1.2.14 验证试验 12
1.2.15 确认规划 12
1.2.16 追溯矩阵 12
1.2.17 综合测试结果 13
1.2.18 验证结果 13
1.2.19 确认结果 13
1.3 系统工程的生命周期 13
1.3.1 V模型生命周期 13
1.3.2 增量式 15
1.3.3 混合式 16
1.4 基于模型的系统工程(MBSE) 17
1.4.1 建模的优势 17
1.4.2 用UML和SysML进行高精度建模 20
1.4.3 建模是敏捷系统工程的根本 20
1.4.4 在你的组织或项目中采纳建模 21
1.4.5 建模规则 25
1.5 总结 27
参考文献 27
第2章 什么是敏捷方法 29
2.1 敏捷宣言 30
2.2 敏捷方法的益处 32
2.2.1 提高工程数据的品质 32
2.2.2 提高工程效率 32
2.2.3 尽早获得投资的回报(ROI) 33
2.2.4 利益攸关者满意 33
2.2.5 增强了项目控制 33
2.2.6 响应变化 33
2.2.7 更早且更大幅度地降低项目风险 33
2.3 将敏捷宣言应用于系统工程 34
2.3.1 增量式地工作 34
2.3.2 动态地规划 34
2.3.3 主动降低项目风险 35
2.3.4 持续地验证 36
2.3.5 连续地综合 36
2.3.6 用例1：在空域中发现轨迹 36
2.3.7 用例2：进行定期的内置测试(PBIT) 36
2.3.8 频繁地确认 37
2.3.9 建模是aMBSE的根本 37
2.4 针对系统工程的敏捷最佳实践 37
2.4.1 工作产品的增量式开发 38
2.4.2 工作产品的持续验证 38
2.4.3 可执行的需求模型 39
2.4.4 链接到文本规范的基于模型的规范 41
2.4.5 连续的可依赖性评估 41
2.4.6 主动的项目风险管理 42
2.4.7 向下游工程的基于模型的转交 43
2.4.8 动态的规划 43
2.5 汇总：Harmony aMBSE流程 45
2.5.1 启动项目 47
2.5.2 定义利益攸关者需求 49
2.5.3 系统需求定义和分析 50
2.5.4 途径1：基于流的用例分析 51
2.5.5 途径2：基于场景的用例分析 51
2.5.6 途径3：基于状态的用例分析 52
2.5.7 架构分析 53
2.5.8 架构设计 55
2.5.9 进行迭代回顾 56
2.5.10 向下游工程转交 57
2.5.11 控制项目 58
2.5.12 进行品质保证审计 59
2.5.13 管理变更 59
2.6 总结 59
参考文献 60
第3章 SysML介绍 61
3.1 SysML概览 61
3.2 UML扩展机制 64
3.2.1 SysML模型元素 65
3.2.2 SysML图 66
3.2.3 行为图 67
3.2.4 需求图 68
3.2.5 结构图 69
3.3 组织你的模型很重要 72
3.4 关键SysML视图和核心语义 76
3.4.1 块、关系、接口和端口 76
3.4.2 顺序图 86
3.4.3 活动、动作和活动图 89
3.4.4 状态机图 94
3.5 最小SysML概要 103
3.6 总结 105
3.6.1 摘自UML 105
3.6.2 修改 105
3.6.3 新元素 106
参考文献 106
第4章 敏捷的利益攸关者需求工程 107
4.1 目标 107
4.2 利益攸关者需求工作流 107
4.2.1 牢记——这是敏捷MBSE 109
4.2.2 什么是用例 109
4.2.3 用例图 112
4.3 示例模型：T-Wrecks工业外骨骼 116
4.4 识别利益攸关者 117
4.4.1 驾驶员 118
4.4.2 机队管理人员 118
4.4.3 维护人员 118
4.4.4 采购方 118
4.4.5 安装人员 119
4.4.6 T-Wreckers测试团队 119
4.4.7 制造工程师 119
4.5 生成利益攸关者需求 119
4.5.1 什么是需求 119
4.5.2 性能需求和其他QoS需求121
4.5.3 需求可视化 122
4.5.4 需求管理工具 124
4.5.5 组织利益攸关者需求规范 124
4.6 对利益攸关者用例场景建模 124
4.6.1 什么是用例场景 125
4.6.2 场景分析工作流 127
4.6.3 T-Wrecks利益攸关者用例场景 129
4.7 创建/更新确认规划 135
4.8 总结 136
4.8.1 识别利益攸关者 136
4.8.2 生成利益攸关者需求 136
4.8.3 对利益攸关者用例场景建模 136
4.8.4 创建/更新确认规划137
4.9 未完待续 137
参考文献 137

第5章 敏捷的系统需求定义和分析 139
5.1 目标 139
5.2 系统需求工作流 139
5.2.1 识别系统用例 140
5.2.2 生成/更新系统需求141
5.2.3 进行用例分析 141
5.2.4 创建逻辑数据模式 142
5.2.5 分析可依赖性 142
5.2.6 创建/更新系统验证规划142
5.3 识别系统用例 142
5.4 生成系统需求 143
5.5 分析用例 144
5.5.1 基于流的用例分析 144
5.5.2 基于场景的用例分析 160
5.5.3 基于状态的用例分析 176
5.6 创建/更新逻辑数据模式 189
5.7 可依赖性分析 192
5.7.1 安全性分析 192
5.7.2 T-Wrecks初始可依赖性分析 201
5.8 创建/更新验证规划 204
5.9 总结 204
5.10 未完待续 205
参考文献 205

第6章 敏捷的系统架构分析与权衡研究 207
6.1 目标 207
6.2 架构分析工作流 208
6.2.1 识别关键的系统功能 209
6.2.2 定义备选解决方案 209
6.2.3 架构权衡研究 209
6.2.4 将多个解决方案并入系统架构 210
6.2.5 定义评估准则 210
6.2.6 向准则分配权重 210
6.2.7 为每个准则定义效用曲线 211
6.2.8 向众多备选解决方案分配MOE 211
6.2.9 确定解决方案 211
6.3 评估方法 211
6.3.1 简单方法 211
6.3.2 高保真方法 213
6.4 识别关键的系统功能(和特性) 216
6.5 定义备选解决方案 218
6.5.1 Speed Demon备选解决方案 218
6.5.2 T-Wrecks备选解决方案 219
6.6 进行架构权衡研究 222
6.6.1 定义评估准则 222
6.6.2 向准则分配权重 223
6.6.3 为每个准则定义效用曲线 224
6.6.4 向备选解决方案分配MOE 226
6.6.5 确定解决方案 229
6.7 将多个解决方案并入系统架构 229
6.8 总结 230
6.9 未完待续 230
参考文献 230

第7章 敏捷的系统架构设计 231
7.1 目标 231
7.1.1 什么是子系统 231
7.1.2 关键架构视图 232
7.2 架构设计工作流 234
7.2.1 识别子系统 234
7.2.2 向子系统分配系统需求 234
7.2.3 向子系统分配用例 235
7.2.4 创建/更新逻辑数据模式235
7.2.5 创建/更新子系统需求235
7.2.6 开发控制律 235
7.2.7 分析可依赖性 235
7.2.8 进行评审 236
7.3 识别子系统 236
7.3.1 Speed Demon子系统 237
7.3.2 T-Wrecks子系统 245
7.4 向子系统分配系统需求 248
7.5 向子系统分配用例 249
7.5.1 自底向上分配 250
7.5.2 自顶向下分配 251
7.5.3 公共任务 253
7.5.4 Speed Demon子系统用例分配示例 254
7.5.5 T-Wrecks子系统用例分配示例 259
7.6 创建/更新逻辑数据模式 265
7.6.1 Speed Demon跑步机示例 266
7.6.2 T-Wrecks示例 267
7.7 创建/更新子系统需求 268
7.8 开发控制律 269
7.9 分析可依赖性 270
7.9.1 安全性分析 271
7.9.2 可靠性分析 271
7.9.3 安保性分析 271
7.10 总结 271
7.11 未完待续 272
参考文献 272

第8章 向下游工程转交 275
8.1 目标 275
8.2 向下游工程转交的工作流 275
8.2.1 收集子系统规范数据 275
8.2.2 创建共享模型 276
8.2.3 定义子系统物理接口 276
8.2.4 创建子系统模型 277
8.2.5 定义跨学科接口 277
8.2.6 将需求分配到工程学科 277
8.3 收集子系统规范数据 277
8.3.1 收集SysML模型数据 277
8.3.2 收集其他工程数据 278
8.4 创建共享模型 279
8.5 定义子系统物理接口 280
8.5.1 从逻辑规范中创建物理规范 281
8.5.2 Speed Demon接口示例 284
8.5.3 T-Wrecks接口示例 287
8.6 创建子系统模型 290
8.7 定义跨学科接口 291
8.7.1 Speed Demon示例：Control Unit子系统接口规范 291
8.7.2 T-Wrecks示例 293
8.8 将需求分配到工程学科 297
8.8.1 Speed Demon示例 298
8.8.2 T-Wrecks示例 299
8.9 下游工程开始 304
8.10 系统工程还在继续 305
参考文献 305
附录A T-Wrecks利益攸关者需求 307
附录B T-Wrecks系统需求 311