混合敏捷方法論與系統工程
管孟忠 博士開南大學企業與創業管理學系 教授
■ 摘要
滿足新要求和使用者驅動功能特徵是開發敏捷系統(agile systems)及/或大型複雜系統的主要挑戰。遵循系統開發方法通常是成功實現系統或專案的必要條件。
敏捷系統專案帶來了新的挑戰，需要在許多領域開展合作。傳統的系統工程方法雖然有助於開發系統結構和框架，但不適應系統未來的增長。使用者期望新的功能特徵或要求可以增加到遺留系統(legacy systems)，但通常需要進行權衡與決策。
為了滿足新的要求，混合敏捷方法論(Hybrid-Agile Methodologies, HAM)是採用了使用傳統系統工程和敏捷原則的混合方法。傳統的系統工程方法處理原始概念開發和設計要求，而具體實現是敏捷的。混合敏捷方法論提出了一些應用議題，例如抽象化（在敏捷實現之前應該設計多少系統）。其他包括如何促進需要重大設計變更的使用者功能特徵；什麼是可接受的權衡。當系統無法滿足特定要求時，這些議題在驗證和確認階段尤其成問題，這需要進行設計變更。本文介紹了一種新的混合敏捷方法與系統工程的方法，並討論了其在敏捷系統開發專案方面的優勢。
■ 系統工程
系統工程(System engineering, SE)是一門訓練有素的活動，為問題和機會提供工程解決方案 – 通常涉及多個利害關係者的活動，跨多個工程學科的協調以及問題和解決方案的複雜性。
與其他工程學科不同，它採用自然法則在一門學科內確定地指導和管理工程設計，系統工程涉及管理跨越多個學科的專案的社會、政治和技術方面。這些專案可能非常龐大和複雜，需要跨學科統一架構和操作概念，需要多方團體來解決權衡，並且隨著專案的進展經常出現非預期的緊急行為。
SE演變為如何描述專案的通用方法，強調在隨著時間推移的規劃和專案工作，這通常包括技術創新。SE是一種跨學科的方法，專注於如何在其生命週期中設計和管理複雜的工程系統(complex engineering systems)。
SE可用於任何系統開發，因此無論我們是在開發製造流程，建造房屋，制定採購流程，還是實施複雜的資訊系統。SE側重於在開發週期的早期定義客戶需求和所需功能，文件化需求，以及繼續進行設計綜合(synthesis)和系統確認(validation)。考慮到所有客戶的業務和技術需求，目標是提供滿足使用者需求的高品質產品。
根據Arthur D. Hall 的說法，系統工程過程(SE process)利用了五個系統生命階段。
在第一階段有必要對系統深入研究或專案規劃。
第二階段是探索性規劃(exploratory planning)，包括：問題的定義，目標的選擇，綜合系統，系統分析，最佳系統的選擇，以及結果的溝通。
第三階段是發展規劃(development planning)，更詳細地重複第二階段。
第四階段在開發過程中進行跟踪，包括：系統部件的開發和該系統的測試。最後階段是當前的工程(current engineering)，這是在系統運行和改進時發生的。
系統工程知識體係指南（System Engineering Body of Knowledge, SEBoK）中提供了系統工程方法和基本原理的重要概述，也提供了系統工程標準化的指引。
當然，多年來已經開發了許多不同的方法和方法來解決系統工程問題。系統工程管理計劃（System Engineering Management Plan, SEMP）側重於專案的技術計畫和用於專案的系統工程過程。其主要目的是提供有關所使用的流程，可交付成果，角色和品質閘門的詳細資訊。
Whitten提供了不同開發方法的分類概述(註1)：
● 第I類：
‒ 結構化設計(Structured Design)
‒ 瀑布開發(Waterfall Development)
‒ 並行開發(Parallel Development)
● 第二類：快速應用程序開發(Rapid Application Development)
‒ 分階段開發(Phased Development)
‒ 基於原型的方法論(Prototyping-based Methodology)
‒ 基於原型的丟掉方法(Throwaway Prototyping-based Methodology)
● 第三類：敏捷開發(Agile Development)
‒ 基於極限編程的方法論(Extreme Programming-based Methodology)
‒ SCRUM
‒ 功能特徵驅動開發(Feature Driven Development)
‒ 看板開發(Kanabn development)
‒ 精實開發(Lean Development)
肯定不僅有最好的方法論。選擇方法論的過程取決於許多不同的和專案特定的方面，例如，要開發的系統的複雜性、時間限制、對時程的可見性的需求，開發團隊的經驗甚至客戶的參與程度。在本文中，我們想提出兩種不同的方法，涵蓋系統開發方法的範圍。第一種方法基於第I類 – 系統工程管理計畫（SEMP）的傳統方法 第二種方法屬於敏捷開發(agile development)的範疇。
■ 系統工程管理計劃（SEMP）
前述討論中提出了對標準化系統工程方法的需求，並簡要介紹了不同的方法。 在本節中，我們將重點介紹一種特殊方法，尤其是在由軟體和硬體組成的系統中。系統工程管理計劃介紹了V模型，旨在實現一般SEMP框架的實際應用，如圖1所示。
圖 1 系統工程管理計畫框架
SEMP不僅定義了特定的步驟，更重要的是定義了特定步驟的可交付性以及品質要求和檢查表。這個SEMP有幾個優點，其中包括清晰度，不同利害關係者理解的事實以及客戶參與的方式：首先透過需求管理，基本上形成了客戶與開發人員之間的合約，並在最後透過使用者驗收測試證明符合客戶期望的過程。
在傳統的SEMP中，任務和問題首先被分成單獨的子系統/子問題，並且定義了介面。對於專案目標確定而系統開發方法或解決方法還沒確定的複雜系統開發專案來說，例如智慧城市系統工程專案(註2)，此時使用傳統的SEMP變得非常困難。此時，我們需要改變這種傳統觀念。 這也是本文的主要動機。必須定義一種經過修改的系統工程方法才能實現。
■ 敏捷方法(Agile Methodologies)
SCRUM是本文討論的下一個方法，即敏捷方法論類(Agile methodologies)的方法。敏捷方法論最初設計是用於開發基於迭代(iterative)和增量(incremental)開發的軟體開發。2001年出版了“敏捷軟件開發宣言(Manifesto for Agile Software Development)”，並提出了12項敏捷基本原則。並為軟體專案定義這些原則如下所示：
1) 我們的最高目標/最優先任務是，透過儘早和持續地交付有價值的軟體來滿足客戶需求。
2) 竭誠歡迎對需求提出變更，即使是在專案開發後期。要利用敏捷流程掌握變更，並善於利用需求變更，以維護客戶的競爭優勢。
3) 要持續不斷交付可用的軟體，週期從幾周到幾個月不等，且時間越短越好。
4) 專案過程中，業務人員與開發人員必須在專案權過程中一起工作。
5) 要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。
6) 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
7) 可用的軟體是衡量進度的主要指標。
8) 敏捷過程提倡可持續的開發。專案贊助者、開發人員和使用者應該能夠保持穩定的進展速度。
9) 對技術的精益求精以及對設計的持續完善將強化敏捷性。
10) 要做到簡潔，即盡可能減少不必要的工作。這是一門藝術。
11) 最佳的架構、需求和設計出自於自我組織的團隊。
12) 團隊要定期反省如何能夠做到更有效，並相應地調整與修正團隊的行為。
根據這些方法論，只需透過快速開發，向客戶展示並直接整合客戶反饋來驗證系統的準確性。敏捷方法(Agile approach)不僅限於軟體編程，還發現其在商業智能和行銷規劃中的應用。它可以幫助專案團隊透過漸進的，迭代的工作節奏（稱為衝刺sprints）來應對不可預測性和不確定性。敏捷方法是瀑布或傳統順序開發的備選方法。
敏捷方法的缺點是客戶喜歡他們的合約在時間和預算上得到確定。在敏捷開發(Agile development)的情況下，不可能提前確定它將花費多少，因為它取決於在整個專案期間和與客戶討論期間表達的要求。這可能是公共合約方面的問題，因為每一個選民都想知道合約執行的成本是多少。下一個缺點是，不良的客戶參與會直接影響產品的品質。這意味著客戶必須直接參與整個開發過程並與開發團隊密切合作。另一個眾所周知的敏捷方法問題最初是為小型軟體專案設計的，但現在是大型專案的備選方案(註3)。
■ Scrum過程
Scrum是敏捷方法在實踐中的特殊應用。它為產品開發定義了一種彈性的策略，開發團隊作為一個單元來實現共同目的。Scrum的一個關鍵原則是客戶可以改變他們想要和需要的東西（通常稱為“需求集(set of requirements)”），並且在專案期間無法簡單地解決傳統預測和計劃中的意外任務。Scrum使用經驗方法，其中問題無法完全理解或定義，因此側重於最大團隊快速交付和響應新要求的能力。
整個Scrum流程中有3個關鍵團隊角色：
1） 開發團隊(development team)負責在每一個衝刺結束時（衝刺目標）交付潛在地可交付增量（potentially shippable increments, PSIS）產品。該團隊通常由3到9個人組成，他們必須完成當前的工作（分析、設計、開發、測試、技術溝通、文件等）。
2） 產品負責人(Product Owner, PO)代表利害關係者和客戶的聲音。他負責確保團隊為業務增加價值。產品負責人應了解客戶的需求和期望，並向開發團隊明確說明，評估特定的工作任務並為其分配優先級，並將其添加到產品待辦事項(product backlog)中。產品負責人處於開發的業務方面，除了預定的會議（衝刺會議, Sprint meeting）之外，在開發期間與團隊成員從不會互動。
3） Scrum Master負責消除團隊在產品交付目的方面的障礙。Scrum Master不是傳統的團隊領導者或專案經理，而是充當團隊和任何負面影響之間的中間人。 Scrum Master確保Scrum流程按計劃使用，團隊成員應遵守商定的流程。組織會議並鼓勵團隊改善。
衝刺（或迭代）是Scrum的基本開發單元。衝刺(sprint)是一個時間盒裝的努力(time boxed effort)；限於特定的持續時間。 每一個衝刺都以衝刺規劃事件開始，該事件旨在定義衝刺事項(sprint backlog)，識別出衝刺的工作，並為衝刺目的(sprint-goal)做出估計的承諾。 每一個衝刺都以衝刺回顧和衝刺回顧(sprint review)結束。 在衝刺期間，團隊每天都會舉行Scrum活動。 Scrum方法的概述如圖2所示是V-SCRUM示意圖，顯示SCRUM方法的七個步驟並以系統工程的V模型展示。
圖 2 V-Scrum 框架
■ 敏捷系統-工程v.s.敏捷-系統工程
在討論混合敏捷方法與系統工程之前，先了解敏捷性、系統合工程之間的關係和意義─ “敏捷系統-工程”和“敏捷-系統工程”。
敏捷系統-工程(Agile systems-engineering)和敏捷-系統工程(Agile-system engineering)是兩個不同的概念，它們共享敏捷(agile)這個詞。在第一種情況下，感興趣的系統是工程過程，而在第二種情況下，感興趣的系統是工程過程產生的。 在這兩種情況下，敏捷一詞指的是在不確定和不斷變化的環境中的商務適應性和對這種適應性的維持。對於許多人來說，使用大寫字母A的敏捷這個詞被用作名詞，指的是一系列軟體開發過程，這些過程遵循2001年發布的敏捷軟體開發宣言中的一套原則。對於INCOSE敏捷系統和系統工程（AS＆SE）工作組而言，敏捷這個詞有一個小的a，是一個形容詞，指的是系統在不確定和不可預測的演變環境中的操作適應能力。
最近對系統工程(System Engineering)中“敏捷性(agility)”的關注表明了新產品和系統的設計和引入市場的速度越來越快。然而，不僅僅是速度，在未來的使用者需求和操作條件中存在不確定性，並且導致驅動新系統開發方式的“真實(true)”需求的模糊性。 因此，本文的一個重要目的是澄清其用途，並找到對“敏捷(agile)”一詞的正確理解，這一術語在系統工程的背景下以各種有時令人困惑的方式使用。“敏捷系統-工程(Agile SYSTEM ENGINEERING)與敏捷-系統工程(AGILE SYSYEMS engineering)”反映的事實是，前者的概念係在工程系統的過程中以及後者的概念係由工程過程中產生的系統本身中，這兩者都可以找到敏捷性。
在第一種Agile SYSTEM ENGINEERING情況下，重點是系統工程的敏捷性(註4)。這種思考敏捷性的方式側重於構思、設計和實施產品和系統的上游過程中的靈活性和速度。
通用的“敏捷”產品開發過程可以表徵為：
● 靈活(nimble)，靈巧(dexterous)和迅捷(swift)。
● 適應(adaptive)和響應(response)在產品/系統開發過程中可用的新資訊，新資訊有時是意外的。
● 與傳統的工程設計理念相反，要求和設計解決方案應儘早凍結。
另一方面，AGILE SYSTEMS engineering強調在工程系統本身中嵌入敏捷性。這通常在預測系統的未來需求或功能要求的能力受到嚴重損害時完成。敏捷系統既靈活又能夠快速從一種狀態或操作狀態轉換到另一種狀態或操作狀態，而無需大的轉換成本或系統複雜性的增加。
敏捷系統的特徵可以是：
● 靈活(flexible)，可重新配置(reconfigurable)，可擴展(extensible)。
● 在容量(capacity)意義上可擴展。一個例子是彈性製造系統，可以快速改變容量（輸出/單位時間）以適應實際的市場需求。
● 在功能和性能水平方面具有靈活性。在初始部署之後，可以透過添加模組或修改性能級別來修改這樣的系統。
我們應該清楚的是，這兩種方法，即設計過程中的敏捷性和產品本身的敏捷性，並不是相互排斥的。
■ 持續系統工程
如今，智能的產品(smart products)擁有比以往更多的電子產品和編碼。這些產品給製造商帶來了巨大的挑戰，他們中的許多人剛剛開始將系統工程作為一種處理複雜性的方式。事實上，大眾市場的消費者要求價格低廉的客製化產品，以滿足他們不斷變化的需求。
因此，製造商正在幾個方面苦苦掙扎：管理複雜性、實現品質，更快地將產品推向市場並始終掌握不斷變化的客戶需求。智能系統工程方法(Smart system engineering)提供了一種開發複雜系統的方法，可以降低成本，滿足客戶需求，並使工程師更快樂。
企業需要一種方法來改變產品開發的結構的一部分。持續工程(Continuous engineering)就是答案(註5)。它是一種企業能力，透過使企業能夠在管理成本、品質和風險的同時，獲取和應用洞察力，加速日益複雜和互聯產品的交付。
持續工程可幫助您處理產品所在生態系統(ecosystem)中所有變化的影響。它將產品開發視為一個迭代過程(iterative process)，應用敏捷開發(agile development)和精實工程(lean engineering)等實踐中的技術來擁抱/實現變革。雖然它保留了必要的嚴謹性和里程碑，但所使用的方法適用於整合變化。
持續的工程技術在變革，知識和無縫協作方面蓬勃發展。從根本上說，持續工程是關於(註6)：
● 解鎖工程知識(Unlocking engineering knowledge)：存取、解鎖和理解所有工程資訊，無論資訊來源如何，都可以使您在正確的時間做出正確的決策 ─ 這樣您就可以將洞察力轉化為業務成果。
● 持續驗證(Continuous verification)：在產品生命週期的所有階段驗證要求和設計有助於防止重工並更快實現品質要求。學習是透過實際或虛擬運行系統完成的，因此您需要確定流程的方向，以便盡可能早地獲取可執行的內容，並在生命週期的所有階段建構可執行系統(executable systems)。
● 戰略性重用(Strategic reuse)：在整個工程生命週期中重用組件有助於提高設計效率，設計產品線，並降低複雜性。
持續工程標誌著一種新的系統工程方法。它保持了整個系統的重點，抽象層次和核心活動，構成了系統工程的基礎，但卻對活動的執行方式產生了新的影響。 它還增加了一些新鮮的成分，從外部傳統流程中吸取市場和運營知識，並提出了利用戰略資產的方法，例如工程數據和可重複使用的程式碼。見圖3所示。
在持續工程中，“V”模型不再代表一系列連續的步驟（與傳統的V系統工程模型不同）; 相反，它代表了在整個產品開發過程中根據需要迭代地（並且，最大程度地、並行地）進行的活動，活動之間的關係以及工程，運營和市場數據之間的聯繫。
圖3還顯示了工程背景中數據關係的重要性。持續工程的最佳實踐包括跨工程學科共享數據，盡可能重用設計元素以及將市場和運營數據整合到產品開發活動中。諸如開放式生命週期協作服務（Open Services for Lifecycle Collaboration , OSLC）等開放標準有助於鏈接數據和工程工具，使連續工程成為現實。
圖 3 持續工程涉及關鍵活動的迭代執行
透過採用開放的整合系統方法進行產品開發，您可以讓您的產品開發團隊：
● 持續獲得所需的所有工程資訊。
● 持續看到他們的工程決策對其他學科(disciplines)的影響。
● 持續利用和使用已經完成的設計 ─ 並且已知可行的設計。
持續的工程設計提供改變遊戲規則的機會，以利用新技術，從而可以從根本上提高效率並降低成本，同時滿足那些數十種智能產品的客戶不斷變化的需求。
■ 混合敏捷方法與系統工程
在本文前述中，簡要概述了任何系統開發過程所需的不同開發方法。但是，現有的方法都不適合與智能產品及/或複雜系統開發相關的挑戰。因此，本節介紹一種稱為混合敏捷方法（Hybrid-Agile Methodology, HAM）的新方法(註7)。
當實施敏捷產品或複雜系統開發共同合約時，需要一種將敏捷原則與SEMP原則相結合的新混合方法，例如智慧型城市的政府專案。這種新的混合方法基於敏捷的12個基本原則，具有一定的適應性。首先，我們必須在整個過程中指定各種角色。角色基於敏捷方法，但它們的定義可能不同。
產品負責人（Product Owner, PO）是最為關鍵的角色。PO應該了解客戶的需求和期望，理解技術術語，並能夠同時定期做出某些決策。由於客戶幾乎不具備所需的技術知識，因此很難將此角色置於客戶身上。解決方案提供商(solution provider)所在的產品負責人不具備決策權，必須確認客戶的決策。因此，Hybrid- Agile方法論中有兩個產品所有者：第一個是客戶（PO-C），第二個是解決方案提供商（PO-P）。他們必須共同努力，彼此密切合作。這是敏捷和混合敏捷方法論之間的第一個也是非常重要的區別。產品所有者(PO)必須與整個過程完全整合，並在雙方溝通中發揮關鍵作用。他們的聯合談判總是導致團隊遵循的要求。開發團隊的表現與標準的敏捷方法類似。Scrum Master也以傳統方式支持開發團隊。
Hybrid- Agile方法論中，標準敏捷方法在的基本原則和變更如下：
1） 客戶應在所有專案步驟中充分參與，即不僅要準備招標並選擇合適的解決方案提供商，而且還要在實施過程中向開發商提供反饋並做出決策。雙方的產品負責人(PO)全權負責收集指定要求並在常規會議期間將其呈現給團隊。這不是一開始就執行過的活動，而是正在進行的活動。提出問題時，客戶方（PO-C）的產品負責人必須能夠做出決定。
2） “要求”（通常以提案或招標材料的形式）在發展過程中仍然發揮著重要作用。這是與標準敏捷方法相比的主要差異之一。由於客戶要求必須能夠以透明的方式管理專案，因此必須從一開始就透過要求了解客戶所表達的專案範圍。 但是，這種混合方法可以最大限度地減少需求的主要問題 ─ 它們很少以允許直接實施的形式編寫，並確保客戶獲得預期的結果。我們不僅依賴於系統需求規範（System Requirements Specification, SRS）文件，而且還將其與PO-Customer的知識和決策相結合。透過這樣的組合，我們可以準備專案計畫(project plan)並管理專案，同時最大限度地減少客戶與解決方案提供商之間的期望差異。
3） 整個合約被分解為短週期 ─ Scrum sprint（建議一到四周）可以快速響應任何變化。產品負責人收集需求並輸入到產品清單(Product Backlog)中，由開發團隊進一步處理。在每一個短週期（sprint）的開始處是sprint規劃會議，在必須完成時指定。客戶的主要優勢是定期監控進度 ─ 在每個衝刺結束時。這些衝刺的目的是提供詳細的審查以及在後續週期中規劃下一步驟。
4） 不要害怕改變規格和要求，如果事實證明它更有效且更便宜，即使它處於實施階段也可以改變規格和要求。這一點是最重要也是最困難的一點，因為它需要從採購者和開發者以及其他利害關係者那裡完全改變其思維方式。基於這樣一個事實，即在合約的規劃和早期執行過程中，它並不確切地知道客戶想要什麼，並且不可能預測實施過程中可能出現的情況（新技術，改變任務以精簡整個的實施）。這個原則表明，如果這有助於精簡，就必須簡化和完善整個過程，那麼客戶和開發人員都不會擔心在實施過程中提出全新的要求和規範。但是，這並不一定意味著跟踪專案存在問題。由於PO-C與開發過程密切相關，並且必須了解變更的所有原因，因此PO-C必須能夠並準備好向使用者證明其合理性。
5） 客戶代表(PO-C)和開發商代表(PO-P)之間的緊密日常合作。產品負責人之間必須進行特別日常的溝通，他們應該溝通並收集需求並將其放入產品積壓中。面對面(Face-to-Face)交談是最佳的溝通方式（共址 co-location）。這是一個相當簡單的規則，表示面對面交流是例如電子郵件之前的首選溝通形式。原因是雙方更好地理解口頭交流是對方要求的。由於溝通通常是系統開發中的關鍵成功因素，因此必須將重點集中在溝通和特別是該規則上。
6） 合約授予的實現是衡量專案成功的標準。目標成功是最終完成，它必須滿足透過產品負責人的要求給出的各個步驟。因此，可以採取成功的衡量標準來執行總是輸入到各個衝刺中的任務。當然，敏捷方法論是基於流程中的變化。因此，如果在開發期間改變某些任務，則不能將其視為失敗。但是，這些更改應有助於提高系統性能/績效。
7） 可持續發展能夠保持穩定步伐是必要的，在創建合約授予期間，以及隨後的實施確定了整個專案可持續的步伐。如果它不能管理這個過程，請求應該找出起訴(prosecute)的原因。Hybrid-Agile Methodology的主要任務顯然是執行速度最快的任務，但速度永遠不會優先於任務的品質及其完成。
8） 簡單(simplicity) ─ 最大化未完成工作量的藝術 ─ 至關重要。這是敏捷方法論的關鍵原則。只做必要的事情。該原則表明產品負責人和開發團隊應該快速準確地分析是否需要完成任務以實現性能完成。還有必要評估這一步驟是否有助於我們進行其他一些保存。這非常複雜，直接取決於整個團隊的經驗。
如果我們分析上述HAM原則，我們發現混合敏捷方法論在複雜系統(如武器系統)獲得過程中的應用有可能解決上面討論的兩種專用方法的主要缺點。所提出的HAM的詳細概述如圖4所示。
圖 4 混合敏捷方法論框架(註8)
HAM的第一個缺點是無法提前確定固定的最終價格和交貨日期。透過敏捷方法論的結合以及對文件需求的強烈關注，情況不再如此。此外，定期監控專案進度，並透過定期衝刺向客戶通報任何新的發展或挑戰。應用混合敏捷方法論的主要優點是在整個實施過程中實現開發人員、客戶和其他專家之間的合作和溝通。 這是在最短的時間內實現最佳結果並實現複雜系統目標的關鍵要求。由於我們的產品負責人 ─ 客戶和產品負責人 ─ 提供商的角色非常注重面對面的溝通，因此以最佳方式支持合作。此外，在專案生命週期中由於客戶和供應商之間的誤解而出現額外專案成本的危險將被最小化。一般範圍和方向從開始到要求設定。但是，它們可以透過產品負責人進行澄清。
■ 結語
本文討論了將系統工程用於複雜系統和敏捷系統領域專案的必要性。這些專案主要要求是強調不同學科之間的合作和溝通、反饋和積極的客戶方法，以及創建高度參與的跨學科團隊。因此，本文介紹了持續系統工程和新的混合敏捷方法論(HAM)。
該HAM是基於敏捷開發的12個基本原則，基本上使用了Scrum方法和系統工程管理計畫(SEMP)的最佳特性。然而，這種新方法的應用需要我們的思維發生重大轉變，並特別對這些專案的客戶提出新的要求 ─ 緊密的日常合作。敏捷原則要求客戶方積極參與複雜系統專案。客戶只準備招標材料是不夠的。複雜系統必須逐步建立，客戶必須在整個專案期間積極參與所有專案生命週期階段。
註1 :J. L. Whitten, L. D. Bentley. Systems analysis and design methods. 7th ed. Boston: McGraw-Hill/Irwin, 2007, xv, 747 p. ISBN 9780073052335.
註2 :Michal LOM, Ondrej PRIBYL, Tomas ZELINKA (2016), System Engineering for Smart Cities – Hybrid-Agile Approach in Smart Cities Procurement, Proceedings of The 20th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2016).
註3 :Ken Schwaber (2004). Agile project management with Scrum. Redmond, Wash.: Microsoft Press, 2004, xix, 163 p. ISBN 073561993x.
註4 :敏捷性(Agility)=可以快速改變的系統屬性。靈活性(flexibility)=可以輕鬆更改的系統屬性。
註5 :HTTPS://WWW.IBMBIGDATAHUB.COM/BLOG/NEW-APPROACH-SYSTEMS-ENGINEERING. IBM在2014年引入了持續工程，作為企業能力開發複雜的電子產品，有望為物聯網製造商提供支持。 持續工程建立在超過25年的經驗基礎上IBM為汽車，航空航天和國防，電子，能源，醫療設備，石油和天然氣以及半導體和電子設計行業提供系統工程和嵌入式軟體開發解決方案。
註2 :Michal LOM, Ondrej PRIBYL, Tomas ZELINKA (2016), System Engineering for Smart Cities – Hybrid-Agile Approach in Smart Cities Procurement, Proceedings of The 20th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2016).
註3 :Ken Schwaber (2004). Agile project management with Scrum. Redmond, Wash.: Microsoft Press, 2004, xix, 163 p. ISBN 073561993x.
註4 :敏捷性(Agility)=可以快速改變的系統屬性。靈活性(flexibility)=可以輕鬆更改的系統屬性。
註5 :HTTPS://WWW.IBMBIGDATAHUB.COM/BLOG/NEW-APPROACH-SYSTEMS-ENGINEERING. IBM在2014年引入了持續工程，作為企業能力開發複雜的電子產品，有望為物聯網製造商提供支持。 持續工程建立在超過25年的經驗基礎上IBM為汽車，航空航天和國防，電子，能源，醫療設備，石油和天然氣以及半導體和電子設計行業提供系統工程和嵌入式軟體開發解決方案。
註6 :Cathleen Shamieh (2014), Continuous Engineering for Dummies, IBM Limited Edition, John Wiley & Sons, Inc.
註7 :Michal LOM, Ondrej PRIBYL, Tomas ZELINKA (2016), System Engineering for Smart Cities – Hybrid- Agile Approach in Smart Cities Procurement, Proceedings of The 20th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2016).
註8 :Michal LOM, Ondrej PRIBYL, Tomas ZELINKA (2016), System Engineering for Smart Cities – Hybrid- Agile Approach in Smart Cities Procurement, Proceedings of The 20th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2016).