系统分析与软体工程课件.ppt
第12章系統分析與軟體工程,陳邦治編著旗標出版社,資電學院計算機概論F7810,2,本章重點,本章將介紹系統分析(system analysis)與軟體工程(software engineering)二個主題系統分析是指在設計系統前，對系統所進行的分析工作軟體工程則是研究如何運用系統化、規範化及數量化等工程方法去進行軟體的開發和維護軟體工程通常被分為軟體發展技術和軟體專案管理二部份，而系統分析是軟體發展技術的重要主題，所以可將系統分析視為軟體工程的一部份,3,大綱,導論 軟體開發生命週期 結構化分析工具及結構化方法 結構化軟體開發生命週期 軟體測試 系統轉換 軟體開發模式,3,3,4,導論,電腦資訊系統開發過程中擔任編寫程式工作的人稱為程式設計師(programmer)，而擔任規劃系統架構工作的人則稱為系統分析師(System Analyst；SA)電腦資訊系統品質的優劣絕大部份是取決於系統分析師所執行的系統分析工作品質的好壞，因此系統分析師的素質及專業能力將會影響整體電腦資訊系統的運作績效,5,系統分析師主要的工作,定義問題列出系統目標蒐集資料分析及評估提出解決方案擬定系統開發計畫定義系統規格系統實作,6,執行系統切割工作時應注意事項,系統分析工作會將系統切割成子系統(subsystem)子系統間的複雜度會與切割後的子系統數量成正比，但子系統內部本身的複雜度會與切割後的子系統數量成反比；也就是說，切割後的子系統數量愈多，子系統間的複雜度將愈高，但子系統本身內部的複雜度將愈低。盡量提高子系統本身之內聚力(cohesion)，但應盡量降低子系統間之耦合力(coupling),7,軟體工程基礎,是一種可描述軟體工程產品特性的理論與科學之基礎是一種可對軟體工程產品與產品間關係建構模式進行推論的數學基礎是一種可對所發展的軟體產品之特性建立預測能力的基本原理,8,傳統系統分析過程中，可能遭遇的問題,使用者需求可能經常變更使用者與系統分析師之間不易溝通使用者不易理解系統完整架構系統不易分割，導致分工不易,9,軟體開發生命週期,傳統軟體開發生命週期分為九個階段初步分析與可行性研究細部分析初步設計硬體研究評估細部設計系統製作撰寫系統文件系統評估系統運轉與維護,10,初步分析,初步分析是依據使用者的需求對系統有初步的了解，本部分主要的工作是分析並瞭解問題確認系統範圍與目標初步分析結束時會將結果撰寫成可行性分析文件，提供可行性研究階段使用,11,可行性研究,可行性研究主要是根據已知的相關資料研究評估新系統是否可行，評估的方向包括以下幾點：成本因素：評估開發新系統所需支出的成本是否能接受社會因素：評估新系統是否能被使用者接受時間因素：評估開發新系統是否有足夠的時間技術因素：評估開發新系統所需的人力及設備是否足夠法律因素：評估新系統是否符合現行法令或將來可能修訂的新法令的規定管理因素：評估新系統是否能有較佳的管理功能,12,假設有一家販售運動彩卷的公司X想要開發一套資訊系統提供客戶利用手持式行動裝置(例如手機或PDA)，隨時隨地都可利用行動電話業者提供的通訊連線服務登錄運動彩卷下注系統進行下注，則此系統的可行性分析文件可能如下,13,細部分析,輸入使用者需求及可行性分析文件。輸出確定系統的需求、範圍及目標後產生實體需求(physical requirement)及功能規格書(function specification),14,初步設計,輸入功能規格書輸出藉由把系統切割成子系統(subsystem)，確定每個子系統在軟體、硬體及人工作業方面的規格，本階段輸出為系統規格書(system specification),15,硬體研究評估,輸入實體需求(細部分析階段的輸出)及硬體規格資料(初步設計階段的輸出)。輸出硬體組態描述(hardware configuration description)及硬體訂單,16,細部設計,輸入系統規格書(初步設計階段的輸出)及硬體組態描述(硬體研究評估階段的輸出)。輸出程式規格書(program specification)，程式規格書中包括輸出入格式、人工作業流程、文件及表格、程式細部流程及實體資料庫等資料之設計,17,系統製作,本階段的工作包括撰寫程式系統測試系統實際操作測試系統實施等,18,撰寫系統文件,編寫系統文件說明書(system documents),19,系統評估,評估系統的優缺點,20,系統運轉與維護,藉由修改軟體使系統能符合使用者需求,21,結構化分析工具及結構化方法,結構化分析是一種具嚴謹性及組織性的方法利用結構化分析工具有容易學習及方便維護等優點結構化方法(structured methodology)是指利用結構化分析工具來表達資料處理之過程常用的結構化分析工具有以下四種資料流程圖資料字典資料結構圖迷你規格書,22,資料流程圖,資料流程圖的作法是將系統分成幾個部份，並利用圖形來描述系統中每個部份之間資料流動的情形，並以網狀結構來表示資料流程圖包含四個基本元件 處理程序（process）資料流（data flow）源頭或終點(source or sink)資料儲存體(data store),23,資料流程圖的繪製原則,先畫資料流，若資料必須轉換，則在轉換處處理程序符號。資料儲存體最後才處理資料流先命名，處理程序次之。處理程序命名原則最的是由一個動詞和一個名詞組成如果某個處理程序無法適當命名，必須考慮是否應與其他處理程序合併或自行執行分割動作,24,資料流程圖範例,教師與學生之間關於成績的輸入及輸出間的資料流程圖,25,資料流程圖的三個階層,頂層(top level)資料流程圖只有一個尚未分割的處理程序，又稱為context diagram，本類流程圖可顯示出系統的範圍(boundaries)底層(bottom diagram)資料流程圖由一些不能再被分割的處理程序所構成，此時每個處理程序代表一種基本功能中層(middle diagram)資料流程圖介於頂層資料流程圖及底層資料流程圖間的資料流程圖,26,三個階層的資料流程圖範例,在上圖的範例中，頂層只有一個名稱為1的處理程序，中層則是將處理程序1分割為三個子程序1.1、1.2及1.3。中層的三個子程序再各自切割為底層中不可再分割的處理程序,27,資料字典,資料字典是指所有在資料流程圖中所用到項目，分別是處理程序、資料流、資料儲存體及資料元素(data element)的邏輯定義集合資料元素是指不可再細分的資料流組成元素,28,製作資料字典時應遵守的原則,資料定義應簡單清楚且不可重複定義容易更新搜尋快速,29,資料字典的運算子,：表示等於。：表示多個元素依序出現。例如成績單准考證號碼+姓名+國文成績+數學成績：表示在內的資料出現0次、1次、.。比方說考生姓名的可能結果有無窮多種，如0位考生、1位考生、2位考生、.：表示從多個元件中選擇一項。比方說 代表由三個考場中選擇一個()：表示選擇或不選擇某一元件*註解說明*：表示在*.*間的內容為註解,30,資料字典的階層化結構,階層化結構是利用由上而下的方式來定義資料例如：考場台北考場台中考場高雄考場台北考場台大考場師大考場+政大考場台中考場興大考場東海考場+靜宜考場+逢甲考場高雄考場中山考場台大考場電機系考場+資工系考場+醫學系考場+外文系考場+中文系考場,31,資料字典的組成,資料字典包含四種不同的項目資料流項目資料元素項目 資料儲存體項目 處理程序項目,32,資料流項目,資料流項目由以下四部份所構成資料流名稱(name)簡明易懂的名稱為佳別名(alias)若資料流有二個或二個以上的名稱，則這些不同的名稱彼此互為別名組成(composition)資料流的組成項目說明(notes)用來記錄其他有關的特性,33,資料流項目範例,34,資料元素項目,資料元素是指不能再被細分的資料流，由以下四部份所構成：資料元素名稱(name)別名(alias)值和意義分為連續式(continuous)及離散式(discrete)二種說明(notes),35,資料元素範例,36,資料儲存體項目,資料儲存體名稱(name)別名(alias)組成(composition)組織(organization)組織欄位是用來描述檔案中記錄(record)的存取方式，如索引存取(index access)或循序存取(sequential access)等方法說明(notes),37,資料儲存體範例,38,處理程序項目,處理程序項目含以下四項處理程序名稱(name)編號描述處理程序的處理邏輯描述，通常使用結構化英文、決策樹或決策表描述說明(notes),39,處理程序範例,40,資料結構圖,第三個要介紹的結構化分析工具是資料結構圖(Data Structure Diagram；DSD)資料結構圖是用於顯示資料儲存體中，各種資料的存取途徑及描述系統中檔案間的關係或是資料庫組織架構,41,資料結構圖之繪製原則,一個資料儲存體(或檔案)利用一個方形來表示，該資料儲存體的存取鍵(access key)標示在此圖形的上半部如果資料儲存體X能夠存取資料儲存體Y時，則用箭頭線連結兩個資料儲存體，箭頭的方向是由X到Y。若欲執行存取動作時，X與Y的存取鍵不同時，應把名稱註明在箭頭線旁邊，相同時則可不寫若被允許存取某個資料儲存體，則該資料儲存體以及該資料儲存體在資料結構圖中所指向的任何資料儲存體的內容均可被存取,42,資料結構圖範例,43,迷你規格書,第四個要介紹的結構化分析工具是迷你規格書（mini-specification）迷你規格書是資料字典中用來描述階層化資料流程圖中最底層處理程序的基本功能製作迷你規格書必須符合簡潔且完整之規定,44,迷你規格書製作原則,在階層化的資料流程圖中的每一個最底層處理程序均必須有對應的迷你規格書來描述，其內容必須包含該處理程序的輸入和輸出資料流的轉變原則描述做什麼？(What to do?)，不必描述如何做？(How to do?)迷你規格書的內容和結構化規格書的內容不得重複迷你規格書的內容應盡量不重覆，也就是達到正交(orthogonal)的目標,45,迷你規格書內容,46,結構化英語(structured English),結構化英語(structured English)是迷你規格書的一種作法結構化英語是用英語來表達計算過程，主要的處理對象是邏輯結構較複雜且包含重覆結構敘述之問題結構化英語的限制是僅提供結構化程式設計之三大結構：循序、選擇及反覆結構的語法規則。用英語來表達計算過程,47,結構化英語使用的字彙,在結構化英語中使用的字彙有以下三種在資料字典中已定義的字彙循序、選擇及反覆結構中的保留字如for、while、if-then-else等命令式動詞,48,結構化英語特點,不需語言處理器加以處理，因此較不受語法之限制具高度之機器獨立性可幫助檢查設計之邏輯觀念是否正確英語不佳者難以使用 通常用來表達程式的計算過程的演算法若是以英語來寫作便可視為是以結構化英語來設計的方法,49,結構化軟體開發生命週期,本節將介紹利用前節介紹的結構化分析工具及結構化方法設計出來的結構化軟體開發生命週期之相關細節,50,結構化軟體開發生命週期五個階段,初步分析與可行性研究 結構化分析階段 結構化設計階段 系統製作階段 系統維護階段,51,初步分析與可行性研究,本階段主要的工作分為二項初步分析期望能初步瞭解系統的目的、功能、需求、作業流程、及限制條件等事項。可行性研究(feasibility study)根據已知的相關資料研究評估是否有足夠的金錢與時間來完成系統，並將結果撰寫成文件，提供給下一個分析階段來使用,52,結構化分析階段,本階段包含七個子階段目前系統環境研究目前邏輯資料流程圖推導產生出新的邏輯系統得到新的邏輯資料流程圖、迷你規格書以及資料字典決定系統自動化的程度量化選擇得到成本與效益研究報告選擇根據新的實體資料流程圖以及成本效益研究報告，加以選擇，產生出所要的實體需求，預算及進度規劃產生結構化規格書將迷你規格書、資料字典及選擇好的資料流程圖，加以整理成結構化規格書,53,結構化設計階段,本階段包含推導出結構圖推導出結構圖是根據資料流程圖導出結構圖模組設計包裝設計包裝設計則是得到設計結果及測試計畫,54,系統製作階段,系統製作階段主要應進行的工作撰寫程式碼(coding）測試測試工作分為白箱測試(white-box testing)與黑箱測試(black-box testing)二類系統文件撰寫系統評鑑等工作,55,系統維護階段,系統維護是指修改軟體使其能滿足目前的需求系統維護是一種高成本的工作,56,結構化軟體開發生命週期各個階段之關連圖,57,軟體測試,測試階段的工作是檢測在製作階段完成之成品的正確性常見的測試法白箱測試黑箱測試,58,白箱測試,白箱測試是測試軟體元件的內部結構，檢查軟體元件是否能依照設計正確無錯誤的執行本技術的測試實例是以程式的控制結構(control structure)為依據進而設計而得，包括的測試細節如下測試所有內部資料結構對於所有含有條件結構及反覆結構中的布林運算式之所有可能值均必須被執行過對於所有反覆結構的內部敘述與所有條件可能值均須檢查確保程式中的每一組獨立路徑控制流程均應被檢查,59,黑箱測試,黑箱測試是依據軟體元件由外部所見的功能來測試軟體元件是否能夠正確執行此類測試主要的目標是以程式功能為導向通常白箱測試會先做，確認程式本身沒問題後才會執行黑箱測試測試過程應特別注意檢驗輸入資料的最大可能值及最小可能值之執行結果是否有誤,60,範例,假設有一個程式可針對最多50筆輸入的整數資料(值介於0100之間)進行排序，輸出為排序之結果執行受測程式內的每一個敘述至少一次，以確定程式沒有錯誤，這類的測試模式屬於白箱測試若以最大值(100)和最小值(0)，以及最靠近最大值(99)和最小值(1)的數值來做作為輸入資料，這種測試方法稱為邊界值分析法(boundary testing)，屬於黑箱測試的一種,61,系統轉換,當系統完成了程式設計與測試後，便進入上線前的系統轉換階段系統轉換應考慮到新舊交替的適應性問題，同時程式雖然經過測試，但是多半是在模擬的情況下進行，在真實的工作環境下可能會發生事先未曾料到的問題，因此系統轉換的過程就顯得十分重要系統轉換是指由一個舊系統轉換為新系統，通常是系統開發過程中的最後一個步驟,62,系統轉換的方式,直接轉換(direct conversion)平行轉換(parallel conversion)試辦轉換(pilot conversion)漸進式轉換(phase-in conversion),63,直接轉換,直接轉換又稱為立即轉換(immediate conversion)以新系統立即完全替換舊系統若要採用直接轉換法必須滿足以下條件新系統已經測試完全並保證不會有任何問題本轉換法是最簡單的轉換方式，系統轉換的成本最低風險最高，因為一旦舊系統完全被取代而新系統卻無法正常運作，會有很大之影響,64,平行轉換,平行轉換方式適合較複雜的系統在轉換的過程中(通常是二至三週)，新舊系統同時運作所有的作業新舊系統皆同時處理，藉此檢驗新系統之運作是否正常，待新系統可以正常後才停止舊系統之運作本法十分可靠方法但成本很高,65,試辦轉換,利用過去的資料供新系統進行處理，然後再與舊系統之結果比較此法可對新系統做全面性之檢測，因此安全性較高本方法可以讓新系統在轉換前徹底被測試，並可讓系統管理人員熟悉新系統之操作系統可靠度較高，但成本很高,66,漸進式轉換,本法混合上述至少兩種的轉換方法且將系統細分成數個部份，各個部份分批且可能利用不同轉換方法進行轉換工作,67,軟體開發模式,軟體開發通常會包含分析、設計與製作三個主要階段常用的軟體開發模式建構修改循環模式瀑布式開發模式,68,建構修改循環模式(build and fixed model),本模式的作法是先推出一個初始版本給使用者使用，再根據使用者的回應意見持續修改系統，這個修改的過程要持續進行到使用者滿意後才會結束系統在使用一段時間之後，若發現程式有問題或功能不足，另一個修改循環將會開始，而這樣的循環會一直持續下去,69,建構修改循環模式圖示,若使用建構修改循環模式將耗費許多時間在修改的動作上，如此一來將使得系統維護工作比較困難，無法對軟體之功能上做較大幅度的擴充，進而使得軟體品質不佳,70,瀑布式開發模式(waterfall model),在本模式中必須將系統的開發流程定義成多個階段，各個階段的開始與結束均應定義明確，不同階段間的轉換必須進行審查，而且應交付的文件也必須清楚定義，各個階段依順序執行且僅循環一次若系統需求一旦變更，將導致後方的階段也必須變更，因此本模式存在相當大的依存問題(dependency)通常這種開發模式比較適合大型的專案開發，如作業系統或編譯程式等,71,瀑布式開發模式圖示,假設一系統的開發分為分析階段、設計階段及製作階段等三個階段，則其瀑布式開發模式將被定義如右圖,
