系统工程的传统方法

《系统工程的传统方法》由会员分享，可在线阅读，更多相关《系统工程的传统方法（16页珍藏版）》请在金锄头文库上搜索。

1、, 第十章：系統工程 第十一章：分析概念及原則 第十二章：分析模型的建立 第十三章：規劃概念及原則 第十四章：規劃方法 第十五章：使用者界面 第十六章：元件層次的設計 第十七章：軟體測試技術 第十八章：軟體測試策略 第十九章：軟體的技術度量,第三篇 軟體工程的傳統方法,第十章,系統工程,10.1 電腦化系統 10.2 系統工程階層 10.3 企業過程工程概觀 10.4 產品工程概觀 10.5 需求工程 10.6 建立系統架構的模型 10.7 總結,10.1 電腦化系統,仿照Webster字典的定義，我們定義電腦化系統(computer-based system)為：成組的或安排好的元素，它們透

2、過對資訊的處理被組織起來，以完成某些預定的目標。 這個目標可能是支援某些企業功能或開發一個可以販賣，以產生商業收入的產品。要完成這個目標，電腦化系統必須利用許多元素： 軟體。電腦程式，資料結構及用以完成所需的邏輯方法、程序或控制的相關文件。 硬體。提供計算能力的電子設備(如，網路交換器、電訊裝置)，及提供外部功能的電子機械設備(如，感應器、馬達、幫浦)。 人員。硬體及軟體的使用者及操作者。 資料庫。大型的、有組織的集中的資訊，可經由軟體存取。 文件。使用手冊、表格，及其他描述系統使用及/或操作的資訊。 程序。定義每個系統元素的特殊使用步驟，或系統所在的程序範圍。 這些元素以許多的方式結合以變換

3、資訊。例如，銷售部門將未處理的銷售資料變換成產品買方的特徵描述，而機器人將包含特定指令的命令檔變換為一組控制信號，以造成某些特定的物理動作。建立一個資訊系統以評估銷售部門，及控制軟體以支援機器人，這二者都需要系統工程。,10.2 系統工程階層,若不考慮將焦點放在特定的領域，系統工程包含一組由上而下及由下而上方法的集合以說明如圖10.1的階層架構。系統工程過程常開始於一種整體觀點。也就是說，對整個企業或產品的領域加以考慮，以確認能建立適當的商業或技術背景。整體觀點被改良為將焦點放在某個特定感興趣的領域。在一個選定的領域內，會分析其具備的系統元素(如，資料、軟體、硬體、人員)。最後，對選定的系統元

4、素進行分析、規劃及建構。在階層架構的最頂端，建立的是一個領域十分廣泛的環境，而在底層，則會建立由相關的工程準則(如，硬體或軟體工程)所執行的細節技術活動。,圖10.1：系統工程的階層, 10.2.1 系統模型的建立 系統工程是一個模型建立的過程。不論焦點是在世界觀點或詳細觀點，工程師建立模型的原因一般如下MOT92： 在慎重的考慮下定義滿足某個觀點所需的過程。 表示過程的行為，並假定以這個行為為基礎。 明確的定義模型的外部產生(exogenous)及內部產生(endogenous)的輸入。 描述所有使工程師能較清楚的了解此觀點的連結(包含輸出)。 合成的系統模型可能會需要一個完整的自動解法，半

5、自動解法，或手動的方法。事實上，經常可能描述各種型態的模型特徵以對手邊的問題提供可選擇的解。在本質上，系統工程簡單的修改不同系統元素間相關的影響，以推出每種型態的模型。 10.2.2 系統模擬 許多屬於反應類的控制機器及/或處理(如，商用大型班機或石油煉製機)必具備高度的可靠性。若系統故障，就會造成嚴重的經濟或人員損失。因此，Graham所描述的方法即痛苦又危險。 現在，用於系統模型建立及模擬的CASE工具被用來在建立電腦化系統時，有助於疑點的消除。在硬體、軟體、資料庫及人員被指定後，便在系統工程的過程中使用這些工具。現代及模擬工具使系統工程能對系統的規格進行試車。用來進行試車的技術細節及模型

6、建立技術在第31章中討論。,10.3 企業過程工程概觀,有三種不同的架構必須在企業目標和目的上被加以分析及規劃： 資料架構 應用程式架構 技術的基礎架構 如圖10.2所示，整體觀點經由資訊策略計畫(information strategy planning, ISP)加以完成。ISP將整個企業視為一個實體，並將商業分隔成對整個企業而言重要的領域(如，工程、製造、市場、財政、銷售等)。ISP定義在整個企業階層、它們的關係及它們如何在企業領域間流動的可見資料物件MAR90。,圖10.2：企業過程工程的階層,10.4 產品工程概觀,產品工程的目標是將客戶所需的一組定義好的能力轉換為工作產品。要達到這

7、個目的，產品工程(product engineering)就像企業過程工程一樣必須推演出架構及基礎架構。架構包含四種不同的系統元件：軟體、硬體、資料(和資料庫)及人員。有一種支援基礎架構會被建立，並包含將這些元件集中在一起所需的技術，及用來支援這些元件的資訊(如，文件、CD-ROM及視訊資料等)。 如圖10.3所示，整體觀點是經由需求工程(requirements engineering)所達成。產品的整體需求是自客戶處取得。這些需求包含資訊及控制需求、產品控能及行為、整體的產品效能、規劃、界面限制，及其他特殊的需求。一旦這些需求都知道了，系統分析的工作將會為以上所述的四種元件配置(alloc

8、ate)功能及行為。,圖10.3：產品工程的階層,10.5 需求工程, 10.5.1 需求提取 這看起來很簡單詢問客戶、使用者，及其他人這個系統或產品的目標為何，要完成的是什麼，系統或產品如何滿足企業的需要，及最後，這個系統或產品每天如何被使用。但它並不簡單相反的卻很困難。 Summerville及Sawyer SOM97建議了一組對需求提取的詳細指引，並總結為以下幾個步驟： 為計畫進行的系統評估企業及技術可行性。確認將能夠有助於明敘需求並了解他們組織偏見的人。 為系統或產品將放置之處定義技術環境(如，計算架構、作業系統、電訊需求)。 確認將限制即將建立的系統或產品功能或效能的領域限制(即，對

9、應用領域的 企業環境特性描述)。 定義一或多種需求提取方式(如，面談、焦點分組、小組會議)。 鼓勵許多人參與，以使需求定義能有許多不同的觀點；確定對每個記錄下來的需 求都能確認。 確認不明的需求做為候選的原型製作。 建立有用的情節(見第11章)以幫助客戶/使用者易於確認關鍵需求。, 10.5.2 需求分析及協調 一旦需求被搜集後，之前所介紹的工作產品便形成需求分析(requirement analysis)的基礎。分析會將需求分類，並將它們組織成為相關的子集合；瀏覽每個需求和其它需求的關係；考查需求的一致性、是否有所忽略或不明之處；並基於客戶/使用者的需求為需求分等級。 對客戶及使用者而言要求

10、超過可達成的，而卻只給有限的企業資源並不是不尋常的事。而對不同的客戶或使用者建議了彼此矛盾的需求，或強調他們的版本是對我們特別的需要而言十分重要也是經常發生的。 系統工程師必須經由一個協調過程來調停這些衝突。客戶、使用者及相關人員被要求將需求排序並優先討論有衝突的部份。結合每個需求的風險被辨別出來並加以分析(詳見第6章)。對開發的工作量進行粗略的評估以用來評量每個需求對專案開銷和交付日期的影響。使用一個反覆進行的方法來評估、結合，及/或修改需求，以使每個部份都能到達某種滿意的程度。 10.5.3 需求規格說明 系統規格說明(system specification)是由系統及需求工程師所產生的

11、最終工作產品。它被視為硬體工程、軟體工程、資料庫工程及人員工程的基礎。它描述了一個電腦化系統的功能及效能，及在開發過程中的限制。規格說明限制了每個已配置的系統元素。系統規格說明也描述了系統的輸入及輸出資訊(資料及控制)。, 10.5.4 系統模型的建立 假設你被要求為一個美食家的廚房建構訂定所有需求。你知道房間的大小，門和窗的位置，以及牆壁的可用空間。你可以訂定所有廚櫃及廚具甚至他們被放在廚房內的什麼位置。這是否是有用的規格說明呢？ 答案是明顯的。為了完整的指定要建立什麼，你應該需要一個有意義的廚房模型，即，一個藍圖或三維圖以顯示廚櫃及廚具的位置，還有它們彼此間的關係。從這個模型，應該能十分簡

12、單的評估工作流程的效率(所有廚房的需求)，這個房間的美學外觀(一個私人的，但非常重要的需求)。 10.5.5 需求確認 由一系列需求工程(一個系統規格說明及相關資訊)所產生的工作產品被一組確認的步驟所評估。需求確認(requirements validation)檢視規格說明以確認所有系統需求已被明白的敘述；不一致、被忽略或錯誤之處都已被發現及更正；且工作產品順從為過程、專案及產品所建立的標準。 主要需求確認的機制是正式技術複審(第8章)。複審小組包含系統工程師、客戶、使用者及其它相關人員，他們檢視系統規格說明以尋找內容或解釋上的錯誤、必需澄清的部份、遺失的資訊、不一致(大型專案或系統進行時最

13、主要的問題)、彼此衝突的需求，或不實際的(無法達成的)需求。雖然需求驗證複審可以以任何達到需求錯誤被發現的方法進行，以一組檢查表問題來考查每個需求是最有用的方法。, 10.5.6 需求管理 需求管理(requirements management)是一組活動，用以幫助專案小組確認、控制及追蹤需求，並在專案進行中的任何時後改變需求。 一旦需求被確認了，就可開發追蹤表。概略的顯示如圖10.4所示，每個追蹤表的確認需求有一或多個部份相關於系統或環境。在許多追蹤表中包含：,圖10.4：一般的追蹤表,特色追蹤表。顯示相關於重要的、客戶可觀察的系統/產品特色的需求。 來源追蹤表。確認每個需求的來源。 相依

14、追蹤表。描述需求如何彼此相關。 子系統追蹤表。子系統所管理的分類需求。 介面追蹤表。顯示需求如何相關於內部及外部二者的介面。,10.6 建立系統架構的模型,要開發系統模型，我們使用一個系統模型樣板(system model template) HAT87來完成。系統工程師會配置系統元素至樣板中的五個元素：(1)使用者界面，(2)輸入，(3)系統功能及控制，(4)輸出以及(5)維護及自我測試。這個架構樣板的格式如圖10.5所示。,圖10.5：系統模型樣板,在圖10.6中每個盒子代表一個外部實體(external entity)也就是說，來自系統的一個資訊生產者或消費者。例如，條碼閱讀器產生輸入至

15、CLSS系統的資訊。整個系統(或較低階的主要子系統)的符號是具有圓角的長方形。因此，CLSS是整個SCD的處理及控制區域。在SCD帶有標記的箭號表示資訊(資料及控制)，它是從外部環境到達CLSS系統中。外部實體條碼閱讀器產生標有條碼的輸入資訊。實際上，SCD將任何系統都放在其外部環境的範圍內。,圖10.6：CLSS 擴充版的系統環境圖,系統工程師經由更詳細的考慮圖10.6中有陰影的長方形來改良架構環境圖。使傳送帶排序系統能在SCD所定義的環境中工作的主要子系統會被識別出來。在圖10.7中，在系統流程圖(system flow diagram, SFD)中定義的主要子系統是從SCD推衍出來的。跨

16、越SCD的資訊流用來引導系統工程師開發SFD一個更詳細的CLSS示意圖。架構流程圖顯示主要子系統及更重要的資訊(資料及控制)流線。除此之外，架構樣板分割子系統處理至前面討論的五個區域之一。在這個階段，每個子系統都能包含一或多個系統工程師所配置的子系統元素(如，硬體、軟體、人員)。,圖10.7：擴充版 CLSS 的系統流程圖,最初的系統流程圖(SFD)成為SFD階層結構的頂點。在原始的SFD中每個圓角長方形可以擴充為另一個僅屬於它的架構樣板。這個過程的說明如圖10.8所示。每個系統的SFD都能被當成一個被描述的子系統其後續工程步驟的開始點。,圖10.8：建立一個 SFD 層次結構,10.7 總結

17、,高技術的系統包括了許多元素：軟體、硬體、人員、資料庫、文件及程序。系統工程有助於利用這些元素將客戶的需要轉換為一個系統模型。 系統工程開始於一個整體觀點。企業領域或產品會被加以分析以建立所有的基礎需求。接著將焦點縮小至領域觀點，以個別分析系統元素。每個元素會經由相關的工程規範配置一種或多種系統元件。 企業過程工程是一種系統工程方法，用來定義架構，以使企業能有效率的使用資訊。企業過程工程的目的是推動範圍廣泛的資料架構、一個應用程式架構，以及一個技術公用設備，以合乎企業策略的需要及每個企業區域的目標及目的。企業過程工程包括資訊策略計畫(ISP)、企業區域分析(BAA)及軟體工程中實際部份的應用指定分析。 產品工程是一個以系統分析開始的系統工程方法。系統工程會鑑定客戶的需要，決定經濟及技術的可能性，並為關鍵功能元件軟體、硬體、人員及資料庫配置功能及效能。 系統工程需要和客戶及資訊或系統工程師間的緊密聯繫。這是經由一組稱為需求工程提取、分析及協調、規格說明、模型建立、驗證及管理的活動來完成的。 在需求被獨立出來後，系統模組便可產生且每個主要子系統的需求可以被開發出來。系統工程任務的重頭戲為系統規格說明它是一份文件，以成為所有後續工程工作的基礎。,