X敏捷系统工程 读者 本书的主要读者不言而喻是系统工程师。系统工程师的主要关注点集中在（通常）由多个 工程学科所实施的系统规范与设计上。系统工程师规定了产品的系统特性而将学科特有的细 节留给适当的下游工程团队。一些下游工程师也可能在本书中找到感兴趣的信息，特别是系 统工程数据如何被格式化并采纳以满足转交活动中他们需要的细节。 目标 在游历世界期间，我感受到系统工程师在应用MBSE方法时所遇到的困难。主要的语 言一一SysML一令人望而生畏。SysML包括800页左右的UML规范并且增加了数百页。它 是一种功能极为强大但是十分复杂的语言。 除了语言本身，随着产品复杂性成倍增加以及产品交付周期的不断缩减，亟须同时提高 系统工程工作的效率并改进质量。我们看到系统在安全关键的、高可靠性和安保性环境中正 日益取代人类，并且我们必须能够始终依靠这些系统的功能正常运转。 本书有一个简单目标一为系统工程师提供足够的指导，以便他们能方便有效地将敏捷 方法和MBSE应用到复杂系统的开发中，因为现实世界越来越依赖于这些系统的运行。 工具 本书中的所有建模示例都使用IBM RhapsodyTM工具进行建模。然而，关于标准的一个 好处是对不同工具的多种选择。如果你偏爱的其他工具支持SysML标准，那么你用你选择的 工具建立这些模型时应该不会遇到什么困难。这不是一本关于Rhapsody的书，也不是专用于 Rhapsody的书。 拓展 如果你对工具、培训或咨询感兴趣，参见www.ibm.com。我在世界范围内教授关于 UML、SysML、MDA、DoDAF、架构设计、设计模式、需求建模、用例、安全性关键开 发、行为建模、开发流程改进、项目管理与调度等多门高等课程并提供咨询。你可通过 Bruce.Douglass(@us.ibm.com就培训或咨询服务与我联系。我还开通了一个（免费的）yahoo群 组论坛，网址是htp:/∥groups..yahoo.com/group/RT-UML一快来参与吧！My IBM Thought Leader(http://www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html) 含你可能感兴趣的白皮书，其涉及不同课题并可供下载。 Bruce Powel Douglass博士
X 敏捷系统工程 读者 本书的主要读者不言而喻是系统工程师。系统工程师的主要关注点集中在(通常)由多个 工程学科所实施的系统规范与设计上。系统工程师规定了产品的系统特性而将学科特有的细 节留给适当的下游工程团队。一些下游工程师也可能在本书中找到感兴趣的信息，特别是系 统工程数据如何被格式化并采纳以满足转交活动中他们需要的细节。 目标 在游历世界期间，我感受到系统工程师在应用MBSE方法时所遇到的困难。主要的语 言——SysML——令人望而生畏。SysML包括800页左右的UML规范并且增加了数百页。它 是一种功能极为强大但是十分复杂的语言。 除了语言本身，随着产品复杂性成倍增加以及产品交付周期的不断缩减，亟须同时提高 系统工程工作的效率并改进质量。我们看到系统在安全关键的、高可靠性和安保性环境中正 日益取代人类，并且我们必须能够始终依靠这些系统的功能正常运转。 本书有一个简单目标——为系统工程师提供足够的指导，以便他们能方便有效地将敏捷 方法和MBSE应用到复杂系统的开发中，因为现实世界越来越依赖于这些系统的运行。 工具 本书中的所有建模示例都使用IBM® Rhapsody™工具进行建模。然而，关于标准的一个 好处是对不同工具的多种选择。如果你偏爱的其他工具支持SysML标准，那么你用你选择的 工具建立这些模型时应该不会遇到什么困难。这不是一本关于Rhapsody的书，也不是专用于 Rhapsody的书。 拓展 如果你对工具、培训或咨询感兴趣，参见www.ibm.com。我在世界范围内教授关于 UML、SysML、MDA、DoDAF、架构设计、设计模式、需求建模、用例、安全性关键开 发、行为建模、开发流程改进、项目管理与调度等多门高等课程并提供咨询。你可通过 Bruce.Douglass@us.ibm.com就培训或咨询服务与我联系。我还开通了一个(免费的)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.3 系统工程的生命周期…13 1.3.1V模型生命周期…13 1.1关键的系统工程活动…1 1.32增量式…15 1.1.1识别客户需要…2 1.3.3混合式…16 1.1.2规定系统需求 2 1.4基于模型的系统工程MBSE)…17 1.1.3评估可依赖性…3 1.4.1建模的优势… …17 1.1.4评价备选架构和技术…3 1.4.2用UML和SysML进行高精度 1.1.5选择特定架构和技术 建模…20 1.1.6分配需求和接口到架构 0…4 1.4.3建模是敏捷系统工程的根本…20 1.1.7向下游工程转交…4 1.4.4在你的组织或项目中采纳 1.1.8将学科特定的设计综合至系统 建模…2 组成…5 1.4.5建模规则…25 1.1.9以整体验证系统…5 1.5总结…27 1.1.10系统确认…8 参考文献…27 12系统工程数据… 8 1.2.1系统开发规划…8 第2章 什么是敏捷方法 …29 12.2利益攸关者需求…9 2.1 敏捷宣言… …30 1.2.3系统需求 9 2.2敏捷方法的益处 32 1.2.4认证规划 9 2.2.1提高工程数据的品质……32 1.2.5子系统需求 9 2.2.2提高工程效率…32 12.6学科特定的需求…9 2.2.3尽早获得投资的回报(RO0…33 1.2.7安全性分析…10 2.2.4利益攸关者满意……33 1.2.8可靠性分析…10 2.2.5增强了项目控制… 1.2.9安保性分析…10 2.2.6响应变化…33 1.2.10系统架构 …10 2.2.7更早且更大幅度地降低项目 1.2.11综合测试规划 …11 风险…33 1.2.12综合测试…11 2.3 将敏捷宣言应用于系统工程…34 1.2.13验证规划 2.3.1增量式地工作…34 1.2.14验证试验 12 2.3.2动态地规划…34 1.2.15确认规划 12 2.3.3 主动降低项目风险 …35 12.16追溯矩阵…12 2.3.4持续地验证…36 1.2.17 综合测试结果…13 2.3.5连续地综合… 36 12.18验证结果…13 2.3.6用例1：在空域中发现轨迹…36 1.2.19确认结果…13
第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
第1章 什么是基于模型的系统工程 系统工程是跨学科的活动，它更多地关注系统特性而不是特定的技术，其总体目标是产 生优化的系统以满足潜在的复杂需要。该关注包括必要的系统特性规范（需求）、大规模系统 的组织原则（系统架构）、在其环境中系统和元素间以及构成该系统的大型架构元素间移动的 “流”和事件的定义（接口）以及通过优化分析对关键方法和技术的选择（权衡研究）。 简而言之，系统工程是构建复杂的技术多元化系统的跨学科方法。 贯穿于系统规范、开发和验证的活动中都涉及系统工程。系统工程提供关键的系统级项 目监管。在本书中，我们将关注规范活动，但系统工程所包括的远不止这些。 系统工程区别于学科特定工程，学科特定工程统称为“下游工程”。这些工程学科包括 机械、电子、化学、光学、核电和软件工程。因此，当系统工程可以定义分配到这些特定工 程学科的需求时，这些需求不应规定这些学科中所采用的设计或技术，除非是在高的层级上。 1.1关键的系统工程活动 图1.1指明系统工程的主要方面，它们连接成“传统的”或“经典的”流。 当然，系统工程比这要多很多，在本书中，我们会涵盖很多方面。当前，它提供 套有用的高层次的论点。关于更多的正式的系统工程定义，请读者参考INCOSE Systems Engineering Handbook (1]. 识别客户需要 规定系统需求 评价备选架 选择特定的 分配需求和 构和技术 架构和技术 接口到架构 评估可依赖性 确认系统 以整体验证 系统 综合架构组件 综合多样化的 向下游工程 技术解决方案 转交 图1.1基本系统工程活动
什么是基于模型的系统工程 系统工程是跨学科的活动，它更多地关注系统特性而不是特定的技术, 其总体目标是产 生优化的系统以满足潜在的复杂需要。该关注包括必要的系统特性规范(需求)、大规模系统 的组织原则(系统架构)、在其环境中系统和元素间以及构成该系统的大型架构元素间移动的 “流”和事件的定义(接口)以及通过优化分析对关键方法和技术的选择(权衡研究)。 简而言之，系统工程是构建复杂的技术多元化系统的跨学科方法。 贯穿于系统规范、开发和验证的活动中都涉及系统工程。系统工程提供关键的系统级项 目监管。在本书中，我们将关注规范活动，但系统工程所包括的远不止这些。 系统工程区别于学科特定工程，学科特定工程统称为“下游工程”。这些工程学科包括 机械、电子、化学、光学、核电和软件工程。因此，当系统工程可以定义分配到这些特定工 程学科的需求时，这些需求不应规定这些学科中所采用的设计或技术，除非是在高的层级上。 1.1 关键的系统工程活动 图1.1指明系统工程的主要方面，它们连接成“传统的”或“经典的”流。 当然，系统工程比这要多很多，在本书中，我们会涵盖很多方面。当前，它提供一 套有用的高层次的论点。关于更多的正式的系统工程定义，请读者参考 INCOSE Systems Engineering Handbook [1]。 䆚߿ᅶ᠋䳔㽕 㾘ᅮ㋏㒳䳔∖ 䆘Ӌ䗝ᶊ ᵘᡔᴃ 䗝ᢽ⡍ᅮⱘ ᶊᵘᡔᴃ 䆘Ԅৃձ䌪ᗻ ⹂䅸㋏㒳 ҹᭈԧ偠䆕 ㋏㒳 㓐ড়ᶊᵘ㒘ӊ 㓐ড়ḋ࣪ⱘ ᡔᴃ㾷އᮍḜ ϟ␌Ꮉ 䕀Ѹ ∖䜡䳔ߚ ষࠄᶊᵘ 图1.1 基本系统工程活动 第1章
2敏捷系统工程 下面将论述活动的目的和意图，但不会论述活动如何进行、何时进行（这些内容将在后 续章节中论述)。由于本书的焦点在于描述如何用敏捷的方式达到系统工程的目标，因此如 何执行这些任务将有别于这种简单化的论述。我们将在第2章中从总体上讨论敏捷方法，并 在后续章节中详细阐述敏捷方法的最佳实践。 1.1.1识别客户需要 我们创建系统最终是要满足客户的一整套需要。它通常作为利益攸关者需求或客户需 求集来捕获。我更喜欢这两个术语中的前者，因为利益攸关者的集合超出了采购方或甚至主 要用户的范围。我们必须满足广大利益攸关者的需要，例如： ·采购方 ·用户@ ●评价者 ●市场人员 ●卖方 ●培训人员 ●制造商 。采办方 。安装人员 ●维护人员 。支持服务 ·运行管理 。认证机构 客户支持 ●处置服务 表达利益攸关者需要的最常用方式是采用文本形式的利益攸关者需求规范②，但模型可 以单独使用或与文本需求相结合使用。利益攸关者需求必须是针对利益攸关者的需要是什么 的准确表述，理解这一点很重要。 1.1.2规定系统需求 利益攸关者需求是对利益攸关者需要的表述，系统需求则是对可观察到的系统特性的精 确的、可测试的表述。系统需求最常关注的是系统做什么，但也可包括其他种类的需求，如 服务品质(QoS)、安全性、可靠性、安保性、耐久性、可制造性、可维护性、可复用性、所 谓的“设计需求”和参数需求。第4章会更详细地论述这个主题。要点在于系统需求是关于 ①也可理解为，可能有很多不同类型的用户以不同的方式使用本系统以实现不同的目标。对于一辆汽车，乘客和 司机都是用户，但他们以不同的方式参与到系统中。 ②为清楚起见，在我使用“文本XXX规范”术语时，我所指的是自然语言规范，而不是以精确的文本语言方式表 述的规范，如数学、Z、SysML以及临时逻辑语言
2 敏捷系统工程 下面将论述活动的目的和意图，但不会论述活动如何进行、何时进行(这些内容将在后 续章节中论述)。由于本书的焦点在于描述如何用敏捷的方式达到系统工程的目标，因此如 何执行这些任务将有别于这种简单化的论述。我们将在第2章中从总体上讨论敏捷方法，并 在后续章节中详细阐述敏捷方法的最佳实践。 1.1.1 识别客户需要 我们创建系统最终是要满足客户的一整套需要。 它通常作为利益攸关者需求或客户需 求集来捕获。我更喜欢这两个术语中的前者，因为利益攸关者的集合超出了采购方或甚至主 要用户的范围。我们必须满足广大利益攸关者的需要，例如： ● 采购方 ● 用户a ● 评价者 ● 市场人员 ● 卖方 ● 培训人员 ● 制造商 ● 采办方 ● 安装人员 ● 维护人员 ● 支持服务 ● 运行管理 ● 认证机构 ● 客户支持 ● 处置服务 表达利益攸关者需要的最常用方式是采用文本形式的利益攸关者需求规范b，但模型可 以单独使用或与文本需求相结合使用。利益攸关者需求必须是针对利益攸关者的需要是什么 的准确表述，理解这一点很重要。 1.1.2 规定系统需求 利益攸关者需求是对利益攸关者需要的表述，系统需求则是对可观察到的系统特性的精 确的、可测试的表述。系统需求最常关注的是系统做什么，但也可包括其他种类的需求，如 服务品质(QoS)、安全性、可靠性、安保性、耐久性、可制造性、可维护性、可复用性、所 谓的“设计需求”和参数需求。第4章会更详细地论述这个主题。要点在于系统需求是关于 a 也可理解为，可能有很多不同类型的用户以不同的方式使用本系统以实现不同的目标。对于一辆汽车，乘客和 司机都是用户，但他们以不同的方式参与到系统中。 b 为清楚起见，在我使用“文本XXX规范”术语时，我所指的是自然语言规范，而不是以精确的文本语言方式表 述的规范，如数学、Z、SysML以及临时逻辑语言
第1章什么是基于模型的系统工程3 系统行为和特性的表述。很明显，为确保我们正在构建的系统满足于利益攸关者，我们需要 在这两种需求间建立相关的特定表述。 系统需求规范的主要工作关注于两种特定种类的需求：功能需求和QoS需求。功能需求 规定系统做什么一系统的行为、用户和其他系统如何交互、系统提供什么能力以及系统所 消耗和传递的信息。这些是系统的动词。与此相反，QoS需求规定行为达成得多好（副词）： 例如行为的性能、可靠性和安全性。除了QS需求外，还有其他非功能需求，包括可承受 性、成本、系统效能、可处置性、可维护性、包装和处理等[1]。 简而言之，功能需求规定系统执行的控制和数据转换，而Q0S需求是这些转换的非功能 方面。 系统需求不做的是规定内部架构、设计和实现技术③。常见的错误是，通过规定不必要 的约束过分地约束内部设计，导致架构师和下游工程师有效工作的灵活性受到限制。对所需 的数据或控制转换进行规定是完全恰当的，但在需求中规定该转换的设计或实现通常是不恰 当的。 1.1.3评估可依赖性 术语“可依赖性”指的是我们在预期的环境下以预期的使用方式以及在违反了这些假设 的情况下依赖于系统的能力。可依赖性有三个主要方面：安全性、可靠性和安保性。从图1.1 中可以注意到，该活动与所有其他工程活动并行完成。这是因为可依赖性关注既是内在的又是 外在的。内在的关注是从系统或其背景环境的基本本质属性中产生的。例如，汽车是很重的东 西，它的主要作用是移动，因此内在的关注是能够开始、控制和结束移动。这些关注点不管用 什么技术启动汽车都是存在的。可是，如果在设计中选择燃油发动机，那么这个决策引入了对 燃油可燃性和烟雾的关注：如果选择电动发动机，则引入了对触电和危险材料泄漏的关注。因 而，在做出技术决策时，必须评估这些关注对安全性、可靠性和安保性的影响。 1.1.4评价备选架构和技术 系统需求是从黑盒的视角不断细化的。这意味着不应规定设计内部的技术解决方案。系 统工程师的任务是识别要使用的系统架构和关键技术。这是因为系统工程师有整体的系统视 角并处在最佳位置做出可能影响多重学科（如电子和软件）的权衡。凭借他们的自由发挥④， 电子工程师可以以软件和机械设计对系统成本或性能产生负面影响为代价做出对他们的设计 的最优决策。但如果决策的后果完全特定于某个工程学科，那么这种决策最好留给特定学科 的专家去做。 换句话说，除非缺乏此类规范会对其他工程学科或系统整体产生负面影响，否则系统工 程师不应规定内部软件架构、电子组件或机械零件。 由于系统工程师具备这种整体视角，他们的职责之一是定义大规模系统架构。为此，他 们通常必须评价备选方法。这被称为进行权衡研究。在权衡研究中，为定义设计的某一方面 ③或至少不该做的！ ④双关语
第1章 什么是基于模型的系统工程 3 系统行为和特性的表述。很明显，为确保我们正在构建的系统满足于利益攸关者，我们需要 在这两种需求间建立相关的特定表述。 系统需求规范的主要工作关注于两种特定种类的需求：功能需求和QoS需求。功能需求 规定系统做什么——系统的行为、用户和其他系统如何交互、系统提供什么能力以及系统所 消耗和传递的信息。这些是系统的动词。与此相反，QoS需求规定行为达成得多好(副词)： 例如行为的性能、可靠性和安全性。除了QoS需求外，还有其他非功能需求，包括可承受 性、成本、系统效能、可处置性、可维护性、包装和处理等[1]。 简而言之，功能需求规定系统执行的控制和数据转换，而QoS需求是这些转换的非功能 方面。 系统需求不做的是规定内部架构、设计和实现技术c。常见的错误是，通过规定不必要 的约束过分地约束内部设计，导致架构师和下游工程师有效工作的灵活性受到限制。对所需 的数据或控制转换进行规定是完全恰当的，但在需求中规定该转换的设计或实现通常是不恰 当的。 1.1.3 评估可依赖性 术语“可依赖性”指的是我们在预期的环境下以预期的使用方式以及在违反了这些假设 的情况下依赖于系统的能力。可依赖性有三个主要方面：安全性、可靠性和安保性。从图1.1 中可以注意到，该活动与所有其他工程活动并行完成。这是因为可依赖性关注既是内在的又是 外在的。内在的关注是从系统或其背景环境的基本本质属性中产生的。例如，汽车是很重的东 西，它的主要作用是移动，因此内在的关注是能够开始、控制和结束移动。这些关注点不管用 什么技术启动汽车都是存在的。可是，如果在设计中选择燃油发动机，那么这个决策引入了对 燃油可燃性和烟雾的关注；如果选择电动发动机，则引入了对触电和危险材料泄漏的关注。因 而，在做出技术决策时，必须评估这些关注对安全性、可靠性和安保性的影响。 1.1.4 评价备选架构和技术 系统需求是从黑盒的视角不断细化的。这意味着不应规定设计内部的技术解决方案。系 统工程师的任务是识别要使用的系统架构和关键技术。这是因为系统工程师有整体的系统视 角并处在最佳位置做出可能影响多重学科(如电子和软件)的权衡。凭借他们的自由发挥d， 电子工程师可以以软件和机械设计对系统成本或性能产生负面影响为代价做出对他们的设计 的最优决策。但如果决策的后果完全特定于某个工程学科，那么这种决策最好留给特定学科 的专家去做。 换句话说，除非缺乏此类规范会对其他工程学科或系统整体产生负面影响，否则系统工 程师不应规定内部软件架构、电子组件或机械零件。 由于系统工程师具备这种整体视角，他们的职责之一是定义大规模系统架构。为此，他 们通常必须评价备选方法。这被称为进行权衡研究。在权衡研究中，为定义设计的某一方面 c 或至少不该做的！ d 双关语