Transcript 系統分析與軟體工程

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