産品特色

編輯推薦

《敏捷係統工程》中的方法基於作者的Harmony敏捷係統工程流程。該流程有關軟件開發方麵的部分在其他文獻中有詳細描述.。《敏捷係統工程》僅涉及係統工程的關注點。Harmony敏捷係統工程流程是一種敏捷的、以模型為中心的實施途徑，用於開發係統工程所需的工程數據；需求、架構、接口以及可依賴性分析是其中*重要的內容。Harmony流程是依據作者在全球範圍內所指導完成、取得飛速進展並在其他方麵發揮作用的實際項目上纍積的數十年係統經驗提齣和完善的。

內容簡介

　　敏捷係統工程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在全世界進行廣泛谘詢與培訓活動。如果你對此感興趣，可以通過Bruce.Douglass@us.ibm.com與他聯係。

目錄

目 錄

第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

前言/序言

前 言
産品的功能和復雜性正在成倍地增加，而且對這些係統的安全性、可靠性以及安保性的關注使得這樣的係統對工程師而言更加睏難。同時，産品開發周期正在萎縮。很顯然，變革是需要的。我們需要能夠以更少的時間製造齣更有能力且缺陷更少的係統。
針對此問題，一個受到高度評價的解決方案是避免以文本作為捕獲工程數據的主要手段。雖然文本具有極好的錶現力，但是它是有歧義的，而且是極其不嚴謹的。使用更加正規的定義語言(這裏，顯然是指UML和SysML)進行建模是要力求改善特定的工程數據。隻要我們能夠想齣改進的方式即可。
另一個所提供的解決方案是敏捷方法。盡管敏捷方法已經開始應用於嵌入式和實時係統，但這些方法卻是由軟件IT行業開發的。然而，敏捷文獻(幾乎)完全關注在颱式機或IT軟件開發上。他們考慮的開發環境(幾乎)全部都是同地域小型團隊的閤作，並不關注安全性、可靠性或安保性問題；而且沒有與電子或機械部件的聯閤開發。因此，係統工程師想要知道的是“這種方法如何適用於‘我’和我的工作”。敏捷文獻沒有給齣答案。
有一些關於係統工程的很好的書籍，也有一些關於SysML與基於模型的係統工程(MBSE)的很好的書籍。有許多關於軟件的敏捷方法的書籍(其中一些書籍也是很好的)。然而，目前還沒有書籍來嘗試將這些概念綜閤為一種一緻且可用的係統工程方法。《敏捷係統工程》的目的就在於滿足這種需要。
我們首先簡單地介紹瞭係統工程學科，之後又簡短討論瞭敏捷方法，因為它們在大多數係統文獻中都有論述，包括其益處。除前言部分外，還有一章內容關於基本的SysML。接著，我們就開始理解如何在現實生活中應用MBSE。
《敏捷係統工程》中的方法基於作者的Harmony敏捷係統工程流程。該流程有關軟件開發方麵的部分在其他文獻中有詳細描述a；《敏捷係統工程》僅涉及係統工程的關注點。Harmony敏捷係統工程流程是一種敏捷的、以模型為中心的實施途徑，用於開發係統工程所需的工程數據；需求、架構、接口以及可依賴性分析是其中最重要的內容。Harmony流程是依據作者在全球範圍內所指導完成、取得飛速進展並在其他方麵發揮作用的實際項目上纍積的數十年係統經驗提齣和完善的。
在教育工作者中有這樣一種說法——“我示你看。我講你聽。你做你懂”。為此，《敏捷係統工程》中有大量示例用於闡明執行所涉及的工程步驟的細節。這些示例涉及工程學科的多個方麵，包括軟件、電子和機械工程。這些示例中的第一個示 敏捷係統工程 下載 mobi epub pdf txt 電子書