系統分析與設計王堯天前言

為什麼要系統分析與設計?
從一個人可完成的數百行至數萬行的程式以至於到數十人才能完成的專案, 想想看它的複雜性.
系統分析與設計的進行方式有哪些?
結構化系統分析與設計 (本文的主題)
物件導向式系統分析與設計
系統的種類?
Operational Systems (操作性系統)
Management Information Systems (管理資訊系統; MIS)
Decision Support Systems (決策支援系統; DSS)
Executive Information Systems (高階主管資訊系統; EIS)
Expert Systems (專家系統)
Office Automation Systems (辦公室自動化系統; OA)
系統分析與設計的目標
使得錯誤降低
完成使用者所需要的系統
使得專案人員的合作更容易
使系統的完成更有效率
使系統能重複使用
使系統易於維護
何謂系統發展生命週期?

系統發展生命週期 (System Development Life Cycle; SDLC) 是一有組織的方式用來開發一個企業的資訊系統。 SDLC 又稱為瀑布模式 (Waterfall Model)， 它將系統發展的流程分為幾個階段來進行。 雖然每本書的作法大同小異， 本文以 (Shelly 1995) 為主。
初步調查 (Preliminary Investigation)
系統分析 (System Analysis)
系統設計 (System Design)
系統開發 (System Development)
系統實施與評估 (System Implementation and Evaluation)
系統分析師的基本條件
具有資訊管理， 資訊科學， 或管理相關領域。
合群。
溝通能力強。
瞭解商業資訊系統。
有二至三年的程式寫作經驗。
初步調查
SDLC 是由使用者提出 System Request 開始。 系統分析師接收到 System Request 後， 進行：
可行性評估
排定優先順序
進一步調查
口頭與書面報告
可行性評估
技術性的可行性評估
操作性的可行性評估
經濟性的可行性評估
進一步調查的目的
瞭解問題的真正原因
定義專案的範圍與限制
確認可帶來的利益
估計專案的成本
進一步調查的進行步驟
授權
確認所需的資訊
完成組織圖
進行面談
閱讀現有的系統文件與觀察現行的操作方式
分析收集到的資料
將結果向管理者與使用者報告
系統分析
系統分析的工作大概分為下列幾個步驟：
需求確認 (Requirement Determination)
需求分析 (Requirement Analysis)
評估各項可行方案 (Evaluation of Alternatives)
完成系統需求規格書 (System Requirement Specifications)


進行時， 可不斷尋求下列的解答來完成。

需求確認 需求分析
What is done? Why is it done? What should be done?
Where is it done? Why is it done there? Where should it be done?
When is it done? Why is it done at this time? When should it be done?
How is it done? Why is it done this way? How should it be done?
Who does it? Why does this person it do it? Who should do it?
需求的五個種類
1Outputs (輸出)
2Inputs (輸入)
3Processes (處理程序)
4Timings (時機)
5Controls (控制)
收集資料的方法
面談：
1決定面談對象
2決定面談的目的
3面談前的準備
4面談的進行
5面談中的記錄
6面談的事後評估
資料收集：
1系統文件
2表單與報表
3現有程式
4觀察現行的作業流程
5問卷調查
研究：
1報章雜誌
2專業書籍與期刊
3與其他專家討論
4廠商拜訪
Joint Application Design (JAD)
雛形方法
需求分析
目前最普及的需求分析方法為資料流圖 (Data Flow Diagram; DFD)。 DFD is a structured analysis technique that shows how data moves and changes through an information system in a graphical, top-down fashion. (Shelly 1995)
Data Flow Diagram
DFD 有兩種主要的表示方法。 一種是 DeMarco/Yourdon 提出的， 而另一種是 Gane/Sarson 提出的。 不論哪一種方法， 其 DFD 的組成元件有四種：
1處理程序 (Process)
2資料檔 (Data Store)
3外在個體 (External Entity)
4資料流 (Data Flow)
個案討論
成績系統
請假系統 （練習）
Data Dictionary
Data Dictionary 記錄了處理程序， 資料檔， 外在個體， 與資料流的內容與彼此之間的關係。 Data Dcitionary 的最小組成單位稱 data element (資料元素)。
如何記錄資料元素?
名稱
其他名稱
型態與長度
輸出格式
預設值
標題
資料來源
安全性
負責人
可接受的值與其他驗證的方式
計算公式
描述與註解
範例：
名稱: name
其他名稱: s_name
型態與長度: Char(20)
輸出格式:
預設值:
標題: 學生姓名
資料來源: 學生基本資料
安全性: update: 人事室
query: 每一個人
負責人: 人事室
可接受的值與其他驗證的方式: 不能含有阿拉伯數字
計算公式:
描述與註解: 學生的姓名
如何記錄資料流?
名稱
其他名稱
縮寫
記錄
描述
數量與頻率
範例：
名稱: COMMISION
其他名稱: COMMISION EARNED
縮寫:
記錄: COMMISION
描述: 一個業務員應得之佣金
數量與頻率: 約每天 20 筆
如何記錄記錄?
名稱
其他名稱
定義
所包含的資料元素
範例：
名稱: CREDIT STATUS
其他名稱:
定義: 顧客之信用情形
所包含的資料元素:
CUSTOMER NUMBER PK
CUSTOMER STATUS CODE
REMAINING CREDIT LIMIT
如何記錄處理程序?
名稱
目的
輸入的資料流
輸出的資料流
範例：
名稱: 登錄學生資料
目的: 將學生名冊上的學生資料登錄到資料庫
輸入的資料流: 學生名冊
輸出的料流: 學生資料
處理程序的描述：
for each STUDENT on the 學生名冊
get STUDENT_NAME
get STUDENT_ID
get STUDENT_ADDR
get STUDENT_PHONE
write STUDENT_NAME, STUDENT_ID, STUDENT_ADDR,
STUDENT_PHONE to 學生資料檔
如何記錄外在實體?
名稱
其他名稱
輸入的資料流
輸出的資料流
描述
範例：
名稱: 學生
其他名稱:
輸入的資料流: 改過的作業
輸出的資料流: 作業
描述
程序描述
常用的程序描述的方法有：
Structured English: 結構化英文的三個基本組成結構為： （1） Sequence， （2） Selection， 與 （3） Iteration。
範例：
for each COMMISION EARNED
if EXTRA BONUS equals Y
if PAYMENT TOTAL is greater than $50,000
add 2% to COMISSIOSN PERCENT
output SPECIAL LETTER
output AWARD LIST
else
add 1% to COMISSIOSN PERCENT
output AWARD LIST
else
if PAYMENT TOTAL is greater than $50,000
add 1% to COMISSIOSN PERCENT
output SPECIAL LETTER
calculate COMMISION = COMMISION PERCENT times PAYMENT TOTAL
Decision Table
Decision Tree
其他系統分析的工具
System Flowchart
Nasi-Shneiderman Diagram
狀態轉換圖 (State-Transition Diagram; STD)
DFD， STD， 與 ERD (Entity-Relationship Diagram) 合稱系統分析與設計的三大工具。 STD is a graphical tool for showing events, states, and time-dependent behavior of a real-time or on-line system. (Shelly 1995)。 此類即時系統的特性為：
高速的外來資料輸入。
必須提供足夠快的反應。
系統一般來說是屬事件驅動式的。
STD 的組成元件有：
狀態 (state)
轉換 (transition)
事件 (event)
什麼是 CASE?
CASE 即 Computer-Aided Software Engineering 是一種電腦工具， 是用以將資訊系統的開發與維護的流程自動化的利器。 其優點包括：
提昇生產力
將無聊的行政工作自動化
提供一個標準化與一致性的環境給所有開發者
改進系統品質
但是它也有缺點：
成本增加
因為並無國際標準， 會受限於某一特定產品
有可能需更改你目前系統的開發與維護方式
有取代系統分析師的危機
評估解決方案
完成一個資訊系統有四個方向：
自製 (developemtn of in-house software)
外購 (purchase of a software package)
外包 (contracting other company)
使用者自行開發 (end user computing)
系統設計
系統設計分為邏輯設計 (logical design) 和實體設計 (physical design)。
一個資訊系統的邏輯設計需定義出這個系統的所有輸入， 由這個系統所產生的輸出， 以及為達成此系統的需求所必須執行的處理程序， 而此定義卻與完成這系統的方式與工具毫不相干。
一個資訊系統的實體設計是依照邏輯設計而進行設計， 它是用來敘述所有系統元件是如何被完成的。
邏輯設計， 實體設計， 與開發程式的差別
舉例來說：
邏輯設計： 需要排序功能
實體設計： 敘述排序的方法
開發程式： 選擇開發工具並完成排序程式
系統設計究竟做些什麼?
依照 (Shelly, 1995)， 邏輯設計以在系統分析階段完成，在此階段僅需完成實體設計， 而其工作則包含資料庫設計， 表單與報表的設計，所有 I/O 介面的設計等。
依照 (Hoffer, 1996)， 邏輯設計的工作包含資料庫設計， 表單與報表的設計，所有 I/O 介面的設計等。 而實體設計的工作包含實際檔案與資料庫的設計與程式與處理程序的設計。
系統設計的進行步驟
一般來說， 建議的進行方式為先複習系統需求規格書， 然後依照下列步驟進行後， 將結果報告給管理者與使用者。
設計系統輸出
設計系統輸入
設計系統檔案與資料庫
設計系統的處理程序
設計軟體
系統設計的準則
一般的準則是以下列三個方向來考量：
使用者的方面
系統與使用者互相交談的地方
預估未來使用者的需求
資料的方面
資料在產生的時候， 便在產生的地點輸入系統。
資料輸入後馬上檢查。
盡可能使用自動的方法作資料輸入。
控制資料的存取， 並記錄每一重大資料的改變。
料避免重複輸入。
避免重複的資料儲存在檔案或資料庫中。
處理程序方面
處理程序愈簡單愈好 （？？）
使用獨立的模組， 且此模組只執行單一功能
組的內聚力與聯結力
一般來說，一個系統設計的好壞很難直接判斷，於是內聚力與聯結力就常被用來判斷系統設計好壞的基礎。
內聚力 (cohesion): 如果一個模組內的組成元件之間的相關性很高， 而且都是為了完成同一目標而組成的， 那我們說這個模組的內聚力很高。在系統設計時， 我們要求模組的內聚力愈高愈好。 Constantine 與 Yourdon 認為內聚力有七個層次， 其由低而高的次序為：
偶然的內聚力 (coincidental cohesion)
邏輯的內聚力 (logical cohesion)
時間性的內聚力 (temporal cohesion)
程序的內聚力 (procedual cohesion)
聯絡的內聚力 (communication cohesion)
依序的內聚力 (sequential cohesion)
功能的內聚力 (functional cohesion)
聯結力 (coupling)： 如果一個模組內的組成元件之間緊密的結合在一起，而且彼此的相依性很高， 那我們說這個模組的聯結力很高。在系統設計時， 我們要求模組的聯結力愈低愈好。 Constantine 與 Yourdon 認為聯結力有七個層次， 其由低而高的次序為：
無直接聯結 (no direct coupling)
資料聯結 (data coupling)
郵戳聯結 (stamp coupling)
控制聯結 (control coupling)
外部聯結 (external coupling)
共同聯結 (common coupling)
內容聯結 (content coupling)