敏捷系統(tǒng)工程Agile Systems Engineering
《敏捷系統(tǒng)工程》表達(dá)了系統(tǒng)工程的一種愿景，即在敏捷的工程背景環(huán)境中，精確的需求規(guī)范、結(jié)
構(gòu)和行為可以滿足系統(tǒng)安全性、安保性、可靠性以及性能等更大的關(guān)注。
世界著名的作家及演說家Bruce Powel Douglass博士將敏捷方法和基于模型的系統(tǒng)工程(MBSE)有機(jī)結(jié)
合在一起，定義了系統(tǒng)整體的特性，從而避免傳統(tǒng)的基于文檔規(guī)范的方式所帶來的錯誤。
《敏捷系統(tǒng)工程》闡述了系統(tǒng)開發(fā)的整個生命周期，包括需求、分析、設(shè)計以及向特定工程學(xué)科的
轉(zhuǎn)交。Douglass博士自始至終都將敏捷方法與SysML和MBSE相結(jié)合，進(jìn)而為系統(tǒng)工程師提供概念和方法
層面應(yīng)用的流程指南，使他們可以避免規(guī)范中的缺陷并改進(jìn)系統(tǒng)的質(zhì)量。與此同時，敏捷方法可以降低
系統(tǒng)工程的工作和成本。主要特色
◆ 識別出在系統(tǒng)工程的環(huán)境中如何更有效地應(yīng)用敏捷方法的概念和技術(shù)
◆ 展示了如何進(jìn)行基于模型的功能分析并將分析的結(jié)果往回與系統(tǒng)需求和利益攸關(guān)者需要相關(guān)聯(lián)，并往
前與系統(tǒng)架構(gòu)和接口定義相關(guān)聯(lián)
◆ 提供了一種用于保證系統(tǒng)工程數(shù)據(jù)質(zhì)量和正確性的方式(并且是在系統(tǒng)建造之前)
◆ 解釋了敏捷系統(tǒng)架構(gòu)的規(guī)范以及系統(tǒng)功能到系統(tǒng)組件的分配
◆ 闡釋了如何將工程規(guī)范數(shù)據(jù)傳遞到下游工程而不發(fā)生保真度的丟失
◆ 包括了跨行業(yè)系統(tǒng)全生命周期中不同階段的詳細(xì)案例，其中以工業(yè)外骨骼Waldo為例介紹了復(fù)雜系
統(tǒng)的系統(tǒng)工程過程
《敏捷系統(tǒng)工程》中的方法基于作者的Harmony敏捷系統(tǒng)工程流程。該流程有關(guān)軟件開發(fā)方面的部分在其他文獻(xiàn)中有詳細(xì)描述.。《敏捷系統(tǒng)工程》僅涉及系統(tǒng)工程的關(guān)注點。Harmony敏捷系統(tǒng)工程流程是一種敏捷的、以模型為中心的實施途徑，用于開發(fā)系統(tǒng)工程所需的工程數(shù)據(jù)；需求、架構(gòu)、接口以及可依賴性分析是其中*重要的內(nèi)容。Harmony流程是依據(jù)作者在全球范圍內(nèi)所指導(dǎo)完成、取得飛速進(jìn)展并在其他方面發(fā)揮作用的實際項目上累積的數(shù)十年系統(tǒng)經(jīng)驗提出和完善的。
前 言
產(chǎn)品的功能和復(fù)雜性正在成倍地增加，而且對這些系統(tǒng)的安全性、可靠性以及安保性的關(guān)注使得這樣的系統(tǒng)對工程師而言更加困難。同時，產(chǎn)品開發(fā)周期正在萎縮。很顯然，變革是需要的。我們需要能夠以更少的時間制造出更有能力且缺陷更少的系統(tǒng)。
針對此問題，一個受到高度評價的解決方案是避免以文本作為捕獲工程數(shù)據(jù)的主要手段。雖然文本具有極好的表現(xiàn)力，但是它是有歧義的，而且是極其不嚴(yán)謹(jǐn)?shù)�。使用更加正�?guī)的定義語言(這里，顯然是指UML和SysML)進(jìn)行建模是要力求改善特定的工程數(shù)據(jù)。只要我們能夠想出改進(jìn)的方式即可。
另一個所提供的解決方案是敏捷方法。盡管敏捷方法已經(jīng)開始應(yīng)用于嵌入式和實時系統(tǒng)，但這些方法卻是由軟件IT行業(yè)開發(fā)的。然而，敏捷文獻(xiàn)(幾乎)完全關(guān)注在臺式機(jī)或IT軟件開發(fā)上。他們考慮的開發(fā)環(huán)境(幾乎)全部都是同地域小型團(tuán)隊的合作，并不關(guān)注安全性、可靠性或安保性問題；而且沒有與電子或機(jī)械部件的聯(lián)合開發(fā)。因此，系統(tǒng)工程師想要知道的是這種方法如何適用于我和我的工作。敏捷文獻(xiàn)沒有給出答案。
有一些關(guān)于系統(tǒng)工程的很好的書籍，也有一些關(guān)于SysML與基于模型的系統(tǒng)工程(MBSE)的很好的書籍。有許多關(guān)于軟件的敏捷方法的書籍(其中一些書籍也是很好的)。然而，目前還沒有書籍來嘗試將這些概念綜合為一種一致且可用的系統(tǒng)工程方法。《敏捷系統(tǒng)工程》的目的就在于滿足這種需要。
我們首先簡單地介紹了系統(tǒng)工程學(xué)科，之后又簡短討論了敏捷方法，因為它們在大多數(shù)系統(tǒng)文獻(xiàn)中都有論述，包括其益處。除前言部分外，還有一章內(nèi)容關(guān)于基本的SysML。接著，我們就開始理解如何在現(xiàn)實生活中應(yīng)用MBSE。
《敏捷系統(tǒng)工程》中的方法基于作者的Harmony敏捷系統(tǒng)工程流程。該流程有關(guān)軟件開發(fā)方面的部分在其他文獻(xiàn)中有詳細(xì)描述a；《敏捷系統(tǒng)工程》僅涉及系統(tǒng)工程的關(guān)注點。Harmony敏捷系統(tǒng)工程流程是一種敏捷的、以模型為中心的實施途徑，用于開發(fā)系統(tǒng)工程所需的工程數(shù)據(jù)；需求、架構(gòu)、接口以及可依賴性分析是其中最重要的內(nèi)容。Harmony流程是依據(jù)作者在全球范圍內(nèi)所指導(dǎo)完成、取得飛速進(jìn)展并在其他方面發(fā)揮作用的實際項目上累積的數(shù)十年系統(tǒng)經(jīng)驗提出和完善的。
在教育工作者中有這樣一種說法我示你看。我講你聽。你做你懂。為此，《敏捷系統(tǒng)工程》中有大量示例用于闡明執(zhí)行所涉及的工程步驟的細(xì)節(jié)。這些示例涉及工程學(xué)科的多個方面，包括軟件、電子和機(jī)械工程。這些示例中的第一個示例是高端跑步機(jī)。第二個更復(fù)雜的示例是能夠承載1500千克的可穿戴工業(yè)用機(jī)器人外骨骼(被稱為waldo)。Harmony敏捷系統(tǒng)工程流程的每個主要活動都是以這些和其他示例展開討論和演示的。我們鼓勵讀者針對提出的問題構(gòu)建自己的解決方案并建立這些章節(jié)中所描述的模型。
a 例如，參見Real-Time
Agility(Addison-Wesley, 2009)或Real-Time
UML Workshop for Embedded Systems(Elsevier， 2014)。
X 敏捷系統(tǒng)工程
讀者
《敏捷系統(tǒng)工程》的主要讀者不言而喻是系統(tǒng)工程師。系統(tǒng)工程師的主要關(guān)注點集中在(通常)由多個工程學(xué)科所實施的系統(tǒng)規(guī)范與設(shè)計上。系統(tǒng)工程師規(guī)定了產(chǎn)品的系統(tǒng)特性而將學(xué)科特有的細(xì)節(jié)留給適當(dāng)?shù)南掠喂こ虉F(tuán)隊。一些下游工程師也可能在《敏捷系統(tǒng)工程》中找到感興趣的信息，特別是系統(tǒng)工程數(shù)據(jù)如何被格式化并采納以滿足轉(zhuǎn)交活動中他們需要的細(xì)節(jié)。
目標(biāo)
在游歷世界期間，我感受到系統(tǒng)工程師在應(yīng)用MBSE方法時所遇到的困難。主要的語言SysML令人望而生畏。SysML包括800頁左右的UML規(guī)范并且增加了數(shù)百頁。它是一種功能極為強(qiáng)大但是十分復(fù)雜的語言。
除了語言本身，隨著產(chǎn)品復(fù)雜性成倍增加以及產(chǎn)品交付周期的不斷縮減，亟須同時提高系統(tǒng)工程工作的效率并改進(jìn)質(zhì)量。我們看到系統(tǒng)在安全關(guān)鍵的、高可靠性和安保性環(huán)境中正日益取代人類，并且我們必須能夠始終依靠這些系統(tǒng)的功能正常運轉(zhuǎn)。
《敏捷系統(tǒng)工程》有一個簡單目標(biāo)為系統(tǒng)工程師提供足夠的指導(dǎo)，以便他們能方便有效地將敏捷方法和MBSE應(yīng)用到復(fù)雜系統(tǒng)的開發(fā)中，因為現(xiàn)實世界越來越依賴于這些系統(tǒng)的運行。
工具
《敏捷系統(tǒng)工程》中的所有建模示例都使用IBM
Rhapsody工具進(jìn)行建模。然而，關(guān)于標(biāo)準(zhǔn)的一個好處是對不同工具的多種選擇。如果你偏愛的其他工具支持SysML標(biāo)準(zhǔn)，那么你用你選擇的工具建立這些模型時應(yīng)該不會遇到什么困難。這不是一本關(guān)于Rhapsody的書，也不是專用于Rhapsody的書。
拓展
如果你對工具、培訓(xùn)或咨詢感興趣，參見www.ibm.com。我在世界范圍內(nèi)教授關(guān)于UML、SysML、MDA、DoDAF、架構(gòu)設(shè)計、設(shè)計模式、需求建模、用例、安全性關(guān)鍵開發(fā)、行為建模、開發(fā)流程改進(jìn)、項目管理與調(diào)度等多門高等課程并提供咨詢。你可通過Bruce.Douglass@us.ibm.com就培訓(xùn)或咨詢服務(wù)與我聯(lián)系。我還開通了一個(免費的)yahoo群組論壇，網(wǎng)址是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博士
Bruce Powel Douglass 3歲時開始自學(xué)讀書，不到12歲就開始學(xué)習(xí)微積分。他14歲輟學(xué)游歷美國，幾年后進(jìn)入俄勒岡大學(xué)學(xué)習(xí)數(shù)學(xué)專業(yè)。他最終獲得俄勒岡大學(xué)運動生理學(xué)科學(xué)碩士學(xué)位以及USD醫(yī)學(xué)院神經(jīng)生理學(xué)博士學(xué)位。他在USD醫(yī)學(xué)院期間提出了一個名為自相關(guān)因子分析的數(shù)學(xué)分支，用于研究多細(xì)胞生物神經(jīng)系統(tǒng)中的信息處理。
Bruce作為軟件開發(fā)人員和系統(tǒng)工程師在實時嵌入式系統(tǒng)領(lǐng)域已經(jīng)工作超過30年，是實時嵌入式系統(tǒng)領(lǐng)域著名的演說家、作者與顧問。他是嵌入式系統(tǒng)大會和UML世界大會的顧問委員會的成員之一，并在會議上講授過關(guān)于系統(tǒng)工程、項目估算和調(diào)度、項目管理、面向?qū)ο蟮姆治雠c設(shè)計、通信協(xié)議、有限狀態(tài)機(jī)、設(shè)計模式以及安全性關(guān)鍵系統(tǒng)設(shè)計方面的課程。Bruce 在實時系統(tǒng)、軟件設(shè)計以及項目管理方面有多年的開發(fā)、授課與咨詢經(jīng)驗。他還為很多(特別是實時領(lǐng)域內(nèi)的)雜志和期刊撰文。
Bruce是IBM物聯(lián)網(wǎng)(IoT)業(yè)務(wù)部的首席布道師。作為首席布道師，除了披荊斬棘開拓道路，他更像是一位首席科學(xué)家。Bruce與UML合作伙伴在UML與SysML標(biāo)準(zhǔn)的規(guī)定方面密切合作。他開發(fā)了用于Rhapsody建模工具的第一個DoDAF的UML概要以及其他概要，例如故障樹分析概要以及安保性分析概要。他是對象管理組組織的實時分析和設(shè)計工作組的副主席。他還撰寫了其他幾本關(guān)于系統(tǒng)與軟件開發(fā)方面的書籍，包括Doing Hard Time: DevelopingReal-Time Systems with UML, Objects, Frameworks and Patterns(Addison-Wesley, 1999)、Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems(Addison-Wesley,2002)、 Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems(Addison-Wesley, 2004)、Real-Time Agility(Addison-Wesley, 2009)、Design Patterns for Embedded Systemsin C(Elsevier, 2011)、 Real-Time UML Workshop for Embedded Systems(Elsevier, 2014)等，以及一本關(guān)于乒乓球方面的短篇教材。
Bruce喜歡古典音樂，古典吉他彈奏水平達(dá)到專業(yè)水準(zhǔn)。他參加過多場體育比賽，包括乒乓球、自行車極限馬拉松賽、賽跑以及全接觸跆拳道，盡管目前還只是與打不還手的靜物交手。他最近重新回到三項全能運動比賽以及自行車極限馬拉松賽，并在2014年首次參加了鐵人三項比賽。
Bruce在全世界進(jìn)行廣泛咨詢與培訓(xùn)活動。如果你對此感興趣，可以通過Bruce.Douglass@us.ibm.com與他聯(lián)系。
目 錄
第1章 什么是基于模型的系統(tǒng)工程 1
1.1 關(guān)鍵的系統(tǒng)工程活動 1
1.1.1 識別客戶需要 2
1.1.2 規(guī)定系統(tǒng)需求 2
1.1.3 評估可依賴性 3
1.1.4 評價備選架構(gòu)和技術(shù) 3
1.1.5 選擇特定架構(gòu)和技術(shù) 4
1.1.6 分配需求和接口到架構(gòu) 4
1.1.7 向下游工程轉(zhuǎn)交 4
1.1.8 將學(xué)科特定的設(shè)計綜合至系統(tǒng)組成 5
1.1.9 以整體驗證系統(tǒng) 5
1.1.10 系統(tǒng)確認(rèn) 8
1.2 系統(tǒng)工程數(shù)據(jù) 8
1.2.1 系統(tǒng)開發(fā)規(guī)劃 8
1.2.2 利益攸關(guān)者需求 9
1.2.3 系統(tǒng)需求 9
1.2.4 認(rèn)證規(guī)劃 9
1.2.5 子系統(tǒng)需求 9
1.2.6 學(xué)科特定的需求 9
1.2.7 安全性分析 10
1.2.8 可靠性分析 10
1.2.9 安保性分析 10
1.2.10 系統(tǒng)架構(gòu) 10
1.2.11 綜合測試規(guī)劃 11
1.2.12 綜合測試 11
1.2.13 驗證規(guī)劃 11
1.2.14 驗證試驗 12
1.2.15 確認(rèn)規(guī)劃 12
1.2.16 追溯矩陣 12
1.2.17 綜合測試結(jié)果 13
1.2.18 驗證結(jié)果 13
1.2.19 確認(rèn)結(jié)果 13
1.3 系統(tǒng)工程的生命周期 13
1.3.1 V模型生命周期 13
1.3.2 增量式 15
1.3.3 混合式 16
1.4 基于模型的系統(tǒng)工程(MBSE) 17
1.4.1 建模的優(yōu)勢 17
1.4.2 用UML和SysML進(jìn)行高精度建模 20
1.4.3 建模是敏捷系統(tǒng)工程的根本 20
1.4.4 在你的組織或項目中采納建模 21
1.4.5 建模規(guī)則 25
1.5 總結(jié) 27
參考文獻(xiàn) 27
第2章 什么是敏捷方法 29
2.1 敏捷宣言 30
2.2 敏捷方法的益處 32
2.2.1 提高工程數(shù)據(jù)的品質(zhì) 32
2.2.2 提高工程效率 32
2.2.3 盡早獲得投資的回報(ROI) 33
2.2.4 利益攸關(guān)者滿意 33
2.2.5 增強(qiáng)了項目控制 33
2.2.6 響應(yīng)變化 33
2.2.7 更早且更大幅度地降低項目風(fēng)險 33
2.3 將敏捷宣言應(yīng)用于系統(tǒng)工程 34
2.3.1 增量式地工作 34
2.3.2 動態(tài)地規(guī)劃 34
2.3.3 主動降低項目風(fēng)險 35
2.3.4 持續(xù)地驗證 36
2.3.5 連續(xù)地綜合 36
2.3.6 用例1：在空域中發(fā)現(xiàn)軌跡 36
2.3.7 用例2：進(jìn)行定期的內(nèi)置測試(PBIT)
36
2.3.8 頻繁地確認(rèn) 37
2.3.9 建模是aMBSE的根本 37
2.4 針對系統(tǒng)工程的敏捷最佳實踐 37
2.4.1 工作產(chǎn)品的增量式開發(fā) 38
2.4.2 工作產(chǎn)品的持續(xù)驗證 38
2.4.3 可執(zhí)行的需求模型 39
2.4.4 鏈接到文本規(guī)范的基于模型的規(guī)范 41
2.4.5 連續(xù)的可依賴性評估 41
2.4.6 主動的項目風(fēng)險管理 42
2.4.7 向下游工程的基于模型的轉(zhuǎn)交 43
2.4.8 動態(tài)的規(guī)劃 43
2.5 匯總：Harmony aMBSE流程 45
2.5.1 啟動項目 47
2.5.2 定義利益攸關(guān)者需求 49
2.5.3 系統(tǒng)需求定義和分析 50
2.5.4 途徑1：基于流的用例分析 51
2.5.5 途徑2：基于場景的用例分析 51
2.5.6 途徑3：基于狀態(tài)的用例分析 52
2.5.7 架構(gòu)分析 53
2.5.8 架構(gòu)設(shè)計 55
2.5.9 進(jìn)行迭代回顧 56
2.5.10 向下游工程轉(zhuǎn)交 57
2.5.11 控制項目 58
2.5.12 進(jìn)行品質(zhì)保證審計 59
2.5.13 管理變更 59
2.6 總結(jié) 59
參考文獻(xiàn) 60
第3章 SysML介紹 61
3.1 SysML概覽 61
3.2 UML擴(kuò)展機(jī)制 64
3.2.1 SysML模型元素 65
3.2.2 SysML圖 66
3.2.3 行為圖 67
3.2.4 需求圖 68
3.2.5 結(jié)構(gòu)圖 69
3.3 組織你的模型很重要 72
3.4 關(guān)鍵SysML視圖和核心語義 76
3.4.1 塊、關(guān)系、接口和端口 76
3.4.2 順序圖 86
3.4.3 活動、動作和活動圖 89
3.4.4 狀態(tài)機(jī)圖 94
3.5 最小SysML概要 103
3.6 總結(jié) 105
3.6.1 摘自UML 105
3.6.2 修改 105
3.6.3 新元素 106
參考文獻(xiàn) 106
第4章 敏捷的利益攸關(guān)者需求工程 107
4.1 目標(biāo) 107
4.2 利益攸關(guān)者需求工作流 107
4.2.1 牢記這是敏捷MBSE 109
4.2.2 什么是用例 109
4.2.3 用例圖 112
4.3 示例模型：T-Wrecks工業(yè)外骨骼 116
4.4 識別利益攸關(guān)者 117
4.4.1 駕駛員 118
4.4.2 機(jī)隊管理人員 118
4.4.3 維護(hù)人員 118
4.4.4 采購方 118
4.4.5 安裝人員 119
4.4.6 T-Wreckers測試團(tuán)隊 119
4.4.7 制造工程師 119
4.5 生成利益攸關(guān)者需求 119
4.5.1 什么是需求 119
4.5.2 性能需求和其他QoS需求121
4.5.3 需求可視化 122
4.5.4 需求管理工具 124
4.5.5 組織利益攸關(guān)者需求規(guī)范 124
4.6 對利益攸關(guān)者用例場景建模 124
4.6.1 什么是用例場景 125
4.6.2 場景分析工作流 127
4.6.3 T-Wrecks利益攸關(guān)者用例場景 129
4.7 創(chuàng)建/更新確認(rèn)規(guī)劃 135
4.8 總結(jié) 136
4.8.1 識別利益攸關(guān)者 136
4.8.2 生成利益攸關(guān)者需求 136
4.8.3 對利益攸關(guān)者用例場景建模 136
4.8.4 創(chuàng)建/更新確認(rèn)規(guī)劃137
4.9 未完待續(xù) 137
參考文獻(xiàn) 137
第5章 敏捷的系統(tǒng)需求定義和分析 139
5.1 目標(biāo) 139
5.2 系統(tǒng)需求工作流 139
5.2.1 識別系統(tǒng)用例 140
5.2.2 生成/更新系統(tǒng)需求141
5.2.3 進(jìn)行用例分析 141
5.2.4 創(chuàng)建邏輯數(shù)據(jù)模式 142
5.2.5 分析可依賴性 142
5.2.6 創(chuàng)建/更新系統(tǒng)驗證規(guī)劃142
5.3 識別系統(tǒng)用例 142
5.4 生成系統(tǒng)需求 143
5.5 分析用例 144
5.5.1 基于流的用例分析 144
5.5.2 基于場景的用例分析 160
5.5.3 基于狀態(tài)的用例分析 176
5.6 創(chuàng)建/更新邏輯數(shù)據(jù)模式 189
5.7 可依賴性分析 192
5.7.1 安全性分析 192
5.7.2 T-Wrecks初始可依賴性分析 201
5.8 創(chuàng)建/更新驗證規(guī)劃 204
5.9 總結(jié) 204
5.10 未完待續(xù) 205
參考文獻(xiàn) 205
第6章 敏捷的系統(tǒng)架構(gòu)分析與權(quán)衡研究 207
6.1 目標(biāo) 207
6.2 架構(gòu)分析工作流 208
6.2.1 識別關(guān)鍵的系統(tǒng)功能 209
6.2.2 定義備選解決方案 209
6.2.3 架構(gòu)權(quán)衡研究 209
6.2.4 將多個解決方案并入系統(tǒng)架構(gòu) 210
6.2.5 定義評估準(zhǔn)則 210
6.2.6 向準(zhǔn)則分配權(quán)重 210
6.2.7 為每個準(zhǔn)則定義效用曲線 211
6.2.8 向眾多備選解決方案分配MOE 211
6.2.9 確定解決方案 211
6.3 評估方法 211
6.3.1 簡單方法 211
6.3.2 高保真方法 213
6.4 識別關(guān)鍵的系統(tǒng)功能(和特性) 216
6.5 定義備選解決方案 218
6.5.1 Speed Demon備選解決方案 218
6.5.2 T-Wrecks備選解決方案 219
6.6 進(jìn)行架構(gòu)權(quán)衡研究 222
6.6.1 定義評估準(zhǔn)則 222
6.6.2 向準(zhǔn)則分配權(quán)重 223
6.6.3 為每個準(zhǔn)則定義效用曲線 224
6.6.4 向備選解決方案分配MOE 226
6.6.5 確定解決方案 229
6.7 將多個解決方案并入系統(tǒng)架構(gòu) 229
6.8 總結(jié) 230
6.9 未完待續(xù) 230
參考文獻(xiàn) 230
第7章 敏捷的系統(tǒng)架構(gòu)設(shè)計 231
7.1 目標(biāo) 231
7.1.1 什么是子系統(tǒng) 231
7.1.2 關(guān)鍵架構(gòu)視圖 232
7.2 架構(gòu)設(shè)計工作流 234
7.2.1 識別子系統(tǒng) 234
7.2.2 向子系統(tǒng)分配系統(tǒng)需求 234
7.2.3 向子系統(tǒng)分配用例 235
7.2.4 創(chuàng)建/更新邏輯數(shù)據(jù)模式235
7.2.5 創(chuàng)建/更新子系統(tǒng)需求235
7.2.6 開發(fā)控制律 235
7.2.7 分析可依賴性 235
7.2.8 進(jìn)行評審 236
7.3 識別子系統(tǒng) 236
7.3.1 Speed Demon子系統(tǒng) 237
7.3.2 T-Wrecks子系統(tǒng) 245
7.4 向子系統(tǒng)分配系統(tǒng)需求 248
7.5 向子系統(tǒng)分配用例 249
7.5.1 自底向上分配 250
7.5.2 自頂向下分配 251
7.5.3 公共任務(wù) 253
7.5.4 Speed Demon子系統(tǒng)用例分配示例 254
7.5.5 T-Wrecks子系統(tǒng)用例分配示例 259
7.6 創(chuàng)建/更新邏輯數(shù)據(jù)模式 265
7.6.1 Speed Demon跑步機(jī)示例 266
7.6.2 T-Wrecks示例 267
7.7 創(chuàng)建/更新子系統(tǒng)需求 268
7.8 開發(fā)控制律 269
7.9 分析可依賴性 270
7.9.1 安全性分析 271
7.9.2 可靠性分析 271
7.9.3 安保性分析 271
7.10 總結(jié) 271
7.11 未完待續(xù) 272
參考文獻(xiàn) 272
第8章 向下游工程轉(zhuǎn)交 275
8.1 目標(biāo) 275
8.2 向下游工程轉(zhuǎn)交的工作流 275
8.2.1 收集子系統(tǒng)規(guī)范數(shù)據(jù) 275
8.2.2 創(chuàng)建共享模型 276
8.2.3 定義子系統(tǒng)物理接口 276
8.2.4 創(chuàng)建子系統(tǒng)模型 277
8.2.5 定義跨學(xué)科接口 277
8.2.6 將需求分配到工程學(xué)科 277
8.3 收集子系統(tǒng)規(guī)范數(shù)據(jù) 277
8.3.1 收集SysML模型數(shù)據(jù) 277
8.3.2 收集其他工程數(shù)據(jù) 278
8.4 創(chuàng)建共享模型 279
8.5 定義子系統(tǒng)物理接口 280
8.5.1 從邏輯規(guī)范中創(chuàng)建物理規(guī)范 281
8.5.2 Speed Demon接口示例 284
8.5.3 T-Wrecks接口示例 287
8.6 創(chuàng)建子系統(tǒng)模型 290
8.7 定義跨學(xué)科接口 291
8.7.1 Speed Demon示例：Control Unit子系統(tǒng)接口規(guī)范 291
8.7.2 T-Wrecks示例 293
8.8 將需求分配到工程學(xué)科 297
8.8.1 Speed Demon示例 298
8.8.2 T-Wrecks示例 299
8.9 下游工程開始 304
8.10 系統(tǒng)工程還在繼續(xù) 305
參考文獻(xiàn) 305
附錄A T-Wrecks利益攸關(guān)者需求 307
附錄B T-Wrecks系統(tǒng)需求 311
書單推薦
