敏捷系统工程 PDF 完整清晰版

敏捷系统工程

内容扩充

项目总结在有些公司也叫项目复盘，推广敏捷开发的项目会觉得迭代已经有开展回顾会了，没必要再做项目总结。我觉得这两者的定位是不一样的，回顾会偏重当前迭代，项目总结则是对整个项目周期工作的复盘。不过项目总结实际操作起来往往效果较差，经常出现 SM 一人完成所有总结活动，总结会议上 SM 一人在念报告，其他成员各顾各的，应付式完成总结。

本场 Chat 将会跟大家分享好视通 MCU 团队的项目总结实践，有利于调动项目成员积极性，共同参与到总结活动中，主动发表各自的意见，并关注他人的观点，让 SM 知道他不能只是一个人在战斗！

好视通MCU项目简介：视频会议系统私有化部署服务器项目，特性团队9人，从2017年下半年开始尝试采用敏捷开发模式，团队成员对敏捷转型较支持，积极参与敏捷教练组织的各项活动。

本场 Chat 您将学到以下内容：

• 如何获取项目团队对本项目的整体感受？
• 如何借助项目总结调查问卷进行项目总结？
• 如何进行项目团队交叉互评？
• SM 展示项目总结报告。
• 团队如何总结出计划在下个项目执行的活动？

内容介绍

《敏捷系统工程》表达了系统工程的一种愿景，即在敏捷的工程背景环境中，精确的需求规范、结构和行为可满足系统安全性、安保性、可靠性及性能等更大的关注。阐述了系统开发的整个生命周期，包括需求、分析、设计及向特定工程学科的转交。Douglass博士自始至终都将敏捷方法与SysML和MBSE相结合，进而为系统工程师提供概念和方法层面应用的流程指南，使他们可避免规范中的缺陷并改进系统的质量。同时，敏捷方法可以降低系统工程的工作和成本。

目录

• 第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