Chapter 1 資訊系統的
開發
1.1
1.2
1.3
1-4
基本觀念
系統開發方法論與生命週期模式
開發環境
文件的製作
1.1 基本觀念






1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
系統分析與設計ch1
何謂資訊系統？
資訊系統的種類
什麼是好的資訊系統？
什麼是應用軟體？
什麼是軟體工程？
企業整合成熟度模型 (CMMI)
2
1.1.1 何謂資訊系統？(1/5)

資訊系統 (Information Systems, IS)







軟體 (Software)
硬體 (Hardware)
資料庫 (Database)
人員 (People)
網路 (Networks)
其他各式各樣相關的科技技術 (Technologies)
透過這些元素的整合與互動，執行完成特定的
功能
系統分析與設計ch1
3
1.1.1 何謂資訊系統？(2/5)

資訊系統應用的種類與數量與日俱增





從日常生活的衣食住行育樂
到企業組織營運
學校的教學與學術研究
政府運作、國防措施等等，都有大大小小功能不同的資訊系
統在運作
系統的功能





大者如複雜的氣象預報、銀行金融業務、大眾運輸系統控制
小到便利商店補貨、甚至學生交作業等，
電腦系統在收集、處理、搜尋、過濾、排序、計算資料
提供正確適用的資訊、準確的分析結果、或是控制訊號、決
策建議等
資訊系統在現代人類生活中的重要性是無庸置疑的。
系統分析與設計ch1
4
1.1.1 何謂資訊系統？(3/5)

狹義來說

資訊系統可以定義成支援企業的運作






運用各種硬體及科技
配合應用軟體 (Application software)
加上人員熟練的操作
將企業所需的作業流程自動化
資訊系統已是必要工具
資訊系統的開發與運用，卻是需要有系統性的統籌
和規劃，才能將複雜的人、事、物做良好的協調運
作
系統分析與設計ch1
5
1.1.1 何謂資訊系統？(4/5)
系統分析與設計ch1
圖1-1 資訊系統的組成
6
1.1.1 何謂資訊系統？(5/5)

資訊系統的建置與開發需要一套整合的方法和步驟





幫助開發團隊以一定的標準和進行方式
在有限的資源和時間等限制下
建構出一定品質的資訊系統
軟體工程即是提供開發資訊系統所需的概念、方法、
理論和建議
本書的內容主要在討論開發資訊系統所需要的規劃、
分析與設計，因此均屬於軟體工程的一部分
系統分析與設計ch1
7
1.1.2 資訊系統的種類(1/3)

資訊系統是指在企業中使用的資訊系統




其主要的目的在加速企業作業流程
減少企業運作成本
以增加企業競爭力
包括企業內部的不同層級員工所使用的功能性資訊系
統






銷售資訊系統 (Sales and distribution systems)
會計資訊系統 (Accounting Information Systems, AI)
生產控制資訊系統 (Production planning/controlling system)
倉儲庫存管理資訊系統 (Material management systems)
人力資源管理系統 (Human resource management systems)
採購管理資訊系統 (Purchasing management systems)
系統分析與設計ch1
8
1.1.2 資訊系統的種類(2/3)

跨部門的整體性資訊系統，比如像是：




企業資源規劃系統 (Enterprise Resource Planning
Systems, ERP)
供應鏈管理系統 (Supply Chain Management
Systems, SCM)
顧客關係管理系統 (Customer Relationship
Management Systems CRM)
知識管理系統 (Knowledge Management systems,
KM )
系統分析與設計ch1
9
1.1.2 資訊系統的種類(3/3)

企業內特殊用途的資訊系統，比如像是：





專家系統 (Expert Systems, ES)
支援決策系統 (Decision Support Systems, DSS)
高階主管資訊系統 (Executive Information
Systems, EIS)
群組軟體 (Groupwares)
視訊會議系統 (Video conference systems)
系統分析與設計ch1
10
1.1.3 什麼是好的資訊系統？(1/3)

資訊系統的品質好壞可由下列這些角度來看，
包括




使用者的滿意度
開發的成本和時間是否在 (合理的) 控制範圍內
系統安全性
可維護性及擴充性
系統分析與設計ch1
11
1.1.3 什麼是好的資訊系統？(2/3)

使用者的滿意度



容易使用:使用者的喜好程度
使用性 : 資訊系統有沒有提供必要的功能，包含資
訊的正確性、即時性和適用性
開發的成本和時間


資訊系統開發不可能達到所謂的「完美」，開發資
訊系統不論是經費或時間都有一定的預算
控制的開發成本和時間內，衡量什麼功能是該資訊
系統一定要有的，將各種資源分配到真正重要的地
方
系統分析與設計ch1
12
1.1.3 什麼是好的資訊系統？(3/3)

安全性


系統強健度 (Robustness)，包含能否容忍使用者無意的操作
錯誤、有意的竊取資料、惡意的攻擊等
容易維護、有擴充性



企業組織使用資訊系統所花費的成本，大半都是在系統的維
護 (Maintenance) 上
商業環境的快速變遷，企業組織需要各種的促銷策略與戰術，
以及各種嶄新的、能改善企業運作的作業流程、作業方式、
管理方式、管理觀念，乃至於新產品的研發等等
舊有的資訊系統要能符合企業的新運作方式，透過系統的維
護與擴充來修改、新增功能和資料
系統分析與設計ch1
13
1.1.4 什麼是應用軟體？(1/4)

應用軟體 (Application software)




目的是用來解決、執行某件特定的工作
在這裡狹義的說是必須配合企業的作業流程來執行
應用軟體不僅僅是程式碼而已，還包括企業作業流
程以及相關開發技術文件
是一種智慧型的整合創作，所以是有智慧財產權的，
可以申請專利
系統分析與設計ch1
14
1.1.4 什麼是應用軟體？(2/4)

程式碼




第一代語言，0、1組成的機器碼。
第二代語言，組合語言，即通稱的Assembly。
第三代語言，結構化程式語言，需透過編譯器或是解譯
器來執行，如C、COBAL、Fortran等等；另外還有一
種物件導向的程式語言，如C++、Java、VB等。
第四代語言，比第三代更接近人類的語法，如SQL等。
系統分析與設計ch1
15
1.1.4 什麼是應用軟體？(3/4)

企業作業流程規則




使用者所指定的各項企業作業流程規則
比如採購的作業流程中，所需要的表單、審核、內控的
方法等，如何一步一步完成採購的任務
應用軟體的執行，就是來滿足企業作業流程
另外使用軟體所需要的安全性控管、功能和資料的授權，
如何備份等等，都是可以由企業來決定最適當的規則。
系統分析與設計ch1
16
1.1.4 什麼是應用軟體？(4/4)



相關文件
 主要的文件包括系統計劃書、需求書、規格書、使用者手冊、
會議紀錄等，用來記錄系統開發，並且作為發展者與使用指
之間的溝通工具。
應用軟體是整合式的智慧型產品，不僅僅是電腦的程
式碼而已。
軟體在企業內實施時，必須配合相關的硬體設備、所
運用的科技、企業流程以及企業組織架構修改、使用
者的教育訓練、再加上MIS人員的支援等等，如此才
能形成執行特定功能的資訊系統
系統分析與設計ch1
17
1.1.5 什麼是軟體工程？(1/7)


資訊系統的開發是一項非常複雜的工作，所牽
涉到的範圍包含人、事、物、時間、金錢、技
術、溝通、團隊合作、控制、排程等等，相關
要素眾多
在經過各種技術的發展、概念的產生、以及各
種經驗的累積之後，漸漸的形成一門用工程概
念來開發資訊系統的學科，我們稱之為軟體工
程 (Software engineering)
系統分析與設計ch1
18
1.1.5 什麼是軟體工程？(2/7)





資訊系統的開發就像是建一棟在電腦裡的虛擬大樓，
實體上看不見，但它的複雜和專業的程度，卻和建一
棟實體的大樓不相上下
它同樣需要各式各樣的人力，當然這裡所用的不是勞
力而是智力
材料是各種的電腦設備、資料和專業知識
需要大量的時間和資金，更要加上專業的管理和控制
透過團隊合作的努力來結合各種專業的技術和設備，
生產出各式各樣功能的資訊系統
系統分析與設計ch1
19
1.1.5 什麼是軟體工程？(3/7)

軟體工程所包含的議題

資訊系統開發所需要的模式




即一般所說的方法論 (Methodology)
指導整個系統開發的過程
較著名的有生命週期模式、螺旋模式、漸進模式、雛型
模式等等，
主要是在區隔開發過程的各個階段，並定義開發的每個
階段該做些什麼、怎麼做、和如何評估等
系統分析與設計ch1
20
1.1.5 什麼是軟體工程？(4/7)

系統分析與設計




提供各種不同角度的分析模型以及圖形化工具，以解析
資訊系統的需求與設計
先了解使用者對系統的需求
再根據這些需求設計出開發規格
有了規格後才能交由系統建置師建置的系統開發、測試
以及線上環境，程式設計師撰寫程式，資料庫管理師建
置資料庫，網路工程師架構出所需的網路等。
系統分析與設計ch1
21
1.1.5 什麼是軟體工程？(5/7)

軟體度量的方法



提出一套衡量軟體大小以及複雜度的方法，讓系統開發
人員可以預估所需的人力資源、成本和時間
最常見的是用程式碼的行列數和功能點來計算
品質的管理



設定一套維護品質的標準以及流程，由品質管理小組來
執行
比如程式或模組開發之後，必須做程式碼的測試，看看
有沒有符合使用者的需要、以及符合系統設計所開出的
規格，包含正確性、速度和可靠性等，
又比如，開發文件必須經過一定程序的審核，以確認文
件的正確性以及可行性等
系統分析與設計ch1
22
1.1.5 什麼是軟體工程？(6/7)

風險的管理


對於可能面臨的風險種類、評估方式、管理方法和流程，
都有許多建議
組態的管理


軟體的開發，尤其是大型的軟體，必須配合許多的其他
系統，因此模組之間的組態管理就顯得更形重要
不僅是程式碼，還有文件規格的組態，也需要管理
系統分析與設計ch1
23
1.1.5 什麼是軟體工程？(7/7)

專案的排程與追蹤


關於排程的方法，已有許多學者提出各種的模型和技術，
以供專案管理在工作分配和進度的控管上使用
市面上也有一些成熟的軟體，提供排程和追蹤的環境和
功能
系統分析與設計ch1
24
1.1.6 企業整合成熟度模型
(CMMI)(1/7)




許多學界及業界的研究單位紛紛嘗試提出不同的標準，
來規範資訊系統開發的程序與文件
比如說ISO認證單位，就針對企業內部的標準作業流
程作認定以及監督，以確保企業內部作業流程的品質
CMMI認證，則更進一步提供流程發展時所需要的指
引，其目的在改善組織流程，以發展、取得及維護產
品或服務的管理能力
CMMI的全名是the Capability Maturity Model
Integration project，可以翻譯成企業整合成熟度模型
系統分析與設計ch1
25
1.1.6 企業整合成熟度模型
(CMMI)(2/7)



1991年起，由美國國防部國防工業協會的系統工程委
員會委託卡內基美隆大學軟體工程學院所共同發展出
來
包含需求管理、流程管理、專案管理等，以協助軟體
工程的執行
CMMI中的軟體工程模組涵蓋軟體系統的發展過程，
包括


系統工程、軟體工程、軟體採購、工作團隊管理與發展、以
及整合的產品與發展
整體的主要目的是發展企業的整合架構，用來提升全面作業
流程
系統分析與設計ch1
26
1.1.6 企業整合成熟度模型
(CMMI)(3/7)

CMMI將企業分為5個不同等級的成熟度，每
個成熟度分別描述企業流程所需要達到的狀態

初始級 (Initial)



作業流程屬於第1級 (初始級) 的企業，其企業專案開發
流程是混亂的
組織沒有固定的環境
專案的進行往往依賴成員的能力，因人而治，沒有一定
的開發流程
系統分析與設計ch1
27
1.1.6 企業整合成熟度模型
(CMMI)(4/7)

初始級 (Initial)的專案常會




會超過預算
無法在預定時程內完成
過度承諾使用者將來可達成之功能 (但最終卻無法達成
而放棄流程)
有了成功的經驗也無法累積下來供以後參考
系統分析與設計ch1
28
1.1.6 企業整合成熟度模型
(CMMI)(5/7)

管理級 (Managed)：




企業專案開發流程是被良好管理的
代表其開發流程是經過計劃、執行、評量及控制
即使在時間的壓力下，為了確保開發品質，開發流
程仍能保持不變
專案的執行和管理可以依照一定的計畫進行，管理
階層可以了解專案的狀況及掌握交付時辰
系統分析與設計ch1
29
1.1.6 企業整合成熟度模型
(CMMI)(6/7)

定義級 (Defined)：


企業流程都已詳細說明、落實，並使用標準程序來表現
量化管理級 (Quantitatively managed)：





企業可以使用統計等量化技術來控制企業所制定的標準
流程
根據客戶、最終使用者、組織及流程執行者的需求，每
個流程都可以訂定流程效率量化的目標
量化的控制可以了解每個作業流程執行的狀況
整理分析之後再檢討問題發生之原因
即可知道問題所在，並加以重視及力求改善，避免再度
發生類似的情況。
系統分析與設計ch1
30
1.1.6 企業整合成熟度模型
(CMMI)(7/7)

最佳化級 (Optimizing)：


企業能反應持續變動的經營目標，並持續地改善作業流
程
依照所選定的開發方法論，定義出開發階段以
及每個階段所要交付的產品


探討系統開發的規劃、分析使用者的需求；
並提供一些圖形化的模型和工具，幫助系統開發者
由不同的角度來架構系統，

比如由資料設計、系統功能、使用者介面、物件、流程
的角度來看系統，都有不同的工具，用來設計、連結和
規範諸如資料、程式和介面等所要開發的內容
系統分析與設計ch1
31
1.2 系統開發方法論與生命週期模
式



1.2.1
1.2.2
1.2.3
系統分析與設計ch1
方法論
系統發展生命週期
統一流程模式
32
1.2.1

方法論(1/11)
資訊系統的建置必須用心思去了解企業組織的
現況，考慮許多的問題 :







企業實際的營運上有哪些問題？
現在的作業流程是怎樣的？
有哪些員工參與這些流程？
未來的營運作業流程將會怎樣？
要建置怎樣的資訊系統？
需要怎樣的軟體和硬體設備？
需要怎樣的資料庫和網路支援？
系統分析與設計ch1
33
1.2.1









方法論(2/11)
目的是什麼？
有什麼好處？
有哪些人員參與開發團隊？
建置系統的時程需要多久？
實際的工作內容是什麼？
預計會花多少成本？
與其他系統之間的關聯如何？
需要開發幾支程式？
需要怎樣的開發、測試以及建置環境？
系統分析與設計ch1
34
1.2.1

資訊系統的建置是個複雜的問題，需要一個提
綱挈領的架構




方法論(3/11)
將複雜的資訊系統建置工作切割成多個階段
然後依時間的進行進入不同的階段
進行不同的工作
這就是所謂的資訊系統開發模式，或稱為系統
發展流程 (System development process)，也
就是方法論。
系統分析與設計ch1
35
1.2.1



方法論(4/11)
方法論提供一個建置資訊系統的工作架構
(Framework)，給系統開發者提供建置資訊系
統的過程中，從頭到尾該做的程序和步驟
讓整個資訊系統開發專案有條理可循
更讓參與資訊系統開發專案的人能夠了解整個
專案的進行過程，明白現在開發的進度到哪裡、
該做些什麼工作

系統分析與設計ch1
36
1.2.1

1950年代 編碼與修正模式 (Code-and-fix
model)


方法論(5/11)
此為早期簡單的開發模式，程式設計師只管寫程式，
一旦檢查到錯誤則修改的模式
1956年，Bengington提出階段模式
(Stagewise model)

將資訊系統開發劃分成八個階段，並定義每個階段
該做哪些事
系統分析與設計ch1
37
1.2.1

方法論(6/11)
1970年，Royce提出瀑布模式 (Waterfall
model)，又稱系統開發生命週期模式 (System
Development Life Cycle, SDLC)




也是將資訊系統的開發分成幾個階段，並定義每階
段所要做的事以及所要交付的產品
每階段在得到使用者與開發團隊的同意結束之後，
才進入下一個階段的工作
各個階段循序進行
這是目前主流的資訊系統開發模式
系統分析與設計ch1
38
1.2.1

方法論(7/11)
1971年，Mills提出漸增模式 (Incremental
model)




改進瀑布模式的開發模式
將企業所需開發的資訊系統分成幾個部分，先開發
重要的功能，接著再開發其他次要的功能
每部分也是依照生命週期模式分成幾個階段實施
縮小每次開發的範圍，能加快開發的速度，減少風
險
系統分析與設計ch1
39
1.2.1

方法論(8/11)
1977年，Bally等人提出雛型模式 (Prototyping
model)



改進瀑布模式中的需求確認部分
強調應先快速的開發出一個使用者可以操作的雛型，
增進和使用者之間的溝通，用以確認使用者的需求
此法又分成演進式雛型和拋棄式模型，前者是直接
將雛型開發成最終產品，後者只用來確認使用者的
需求。
系統分析與設計ch1
40
1.2.1

方法論(9/11)
1986年、1988年，Mills等人和Boehm提出螺
旋模式 (Spiral model)


改進瀑布模式的開發模式，加入風險管理的概念，
每個階段要進行前都需要經過四個象限的幾個工作：


做計劃、決定目標、可行方案及限制評估、風險評估、
以雛型確認使用者的需求、實施和驗證
其時間線以螺旋的形狀向外擴開，表示系統開發所
用的資源和成本，越到開發的末期越高
系統分析與設計ch1
41
1.2.1

方法論(10/11)
1993年，Aoyama提出同步模式 (Concurrent
model)


主要的訴求在縮短開發時間，以多個開發團隊一起
來實施，
開發團隊之間的合作和訊息的透通就變得格外重要
系統分析與設計ch1
42
1.2.1

1998年，Jacobson等人整合發展出統一流程模式
(Rational Unified Process, RUP)





方法論(11/11)
提出「反覆與漸增」的軟體發展模式
包含初始、細化、建構與轉移等四個階段
強調能快速的開發出可以操作的軟體，再逐次的進行微調、
修正、新增等工作
這是物件導向的系統開發模式，特別適合小型專案的開發
其中以系統開發生命週期模式影響最為深遠，許多後
來的學者所提出的開發模式都是為了要改進生命週期
模式
系統分析與設計ch1
43
1.2.2 系統發展生命週期(1/14)

生命週期模式的五大階段



Royce, W.W. 於1970年首先提出瀑布模式的開發方
法論
依照資訊系統開發之生命週期的各個階段，像是瀑
布的水從上層流到下一層一樣，由上而下逐段來進
行規劃
此法又稱系統發展生命週期模式，將資訊系統開發
的完整過程分成幾個階段，並定義出每一個階段的
工作內容和產出的產品，一個階段執行結束後才進
入下一個階段
系統分析與設計ch1
44
1.2.2 系統發展生命週期(2/14)





1. 系統規劃 (System planning)
2. 系統需求分析 (System requirement
analysis)
3. 系統設計 (System design)
4. 系統建置與測試 (System implementation
and testing)
5. 系統上線與維護 (System roll out and
maintenance)
系統分析與設計ch1
45
1.2.2 系統發展生命週期(3/14)
系統規劃
系統規劃書
系統需求分析
系統需求書
系統設計
系統設計規格書
系統建置與測試
軟體硬體建置
測試計畫及結果
系統上線與維護
圖1-2 系統發展生命週期的各個階段
系統分析與設計ch1
系統上線計劃
系統維護文件
教育訓練教材
46
1.2.2 系統發展生命週期(4/14)



每個階段的工作結束後，都會有各自不同的產
出
當階段工作結束之後，還要使用者、開發團隊
雙方同意該階段的內容，並且簽名，才進入下
個階段的開發
當在一個階段的工作中發現上一個階段的設計
或是工作內容有問題時，可以回到那個階段做
修改的動作；但是如果一直回去修改，就失去
階段性開發的意義，也許表示上一個階段的工
作做得很差
系統分析與設計ch1
47
1.2.2 系統發展生命週期(5/14)

生命週期模式五大階段的內容與產出

(1)系統規劃：主要目的是在找出系統的範圍，並預估專案所
需要的資源，包括人力、資金、軟硬體設備和時間。
 目前企業運作上和專案系統所面臨的相關問題、大約需要有
哪些系統功能、預計可以帶來哪些效益、為企業爭取到哪些
好處，可以說是一個系統開發的企劃案 (Proposal)
 這個階段主要的產出是系統規劃書 (System plan)，內容包括
摘要、問題描述、系統範圍及定義、人力資源架構、成本效
益分析、系統開發時程表、可行性評估等，用很短的時間，
將所面臨的問題定義出解決方案，並且列出所需的資源和可
以帶來的效益
系統分析與設計ch1
48
1.2.2 系統發展生命週期(6/14)

(2)系統需求分析：系統的需求是指使用者希望資訊系統將來
能為他們做些什麼，因此這個階段就是在確認資訊系統的範
圍
 從觀察目前企業作業的狀況，到針對所遇到的問題提出資訊
系統的功能需求
 系統開發團隊透過收集資料、訪問、調查、開會等方法，加
入開發者的專業知識和經驗，將系統的需求以各種適合的圖
形化工具和文字加以描述和說明，規劃出適當的範圍和系統
的功能需求，確認範圍和目標
 指出到底要開發什麼 (What)，其主要產出物是系統需求書
(System requirement specification)，主要的內容包括摘要、
產業現況、企業背景、企業流程現況、問題描述、功能需求
等
系統分析與設計ch1
49
1.2.2 系統發展生命週期(7/14)

(3)系統設計：系統設計的主要工作內容是將上一個階段所交
付的系統需求做進一步的設計
 包括建構怎樣的基礎建設，內容涵蓋硬體環境、網路系統、
作業系統等
 還有建構哪些企業流程與軟體功能；並且進行資料儲存和處
理的規劃、使用者介面設計、物件開發、各種程式設計等
 通常此階段都會運用各種的圖形化工具來建構，也就是以各
種角度來看系統
 本階段的主要目的是設計出要如何 (How) 進行開發
 這個階段的產出是系統設計規格書 (System design
specification)，內容則是以各種不同的角度來設計資訊系統，
包括企業流程、硬體的建置、軟體的功能、資料庫的建置、
使用者介面的建置等等，使用各種不同的圖形化工具和文字
的說明
系統分析與設計ch1
50
1.2.2 系統發展生命週期(8/14)

(4)系統建置與測試：至此系統發展與建置進入了實施的階段，
即是將上一個階段所開出來的系統規格實作出來
 系統的硬體需購入；網路工程要發包、並建置連線；軟體若
是自行開發，則進入程式的撰寫階段，若是向外購買，也要
進入了程式的修改階段
 每個模組、物件、程式、介面和資料庫，都必須一一根據上
個階段的設計來實作，並且做測試，看看有沒有錯誤，有沒
有符合系統的規格需求
 最後將整個資訊系統整合，做使用者的環境測試。當然這個
階段的主要產出不僅僅是文件而已，而是整個資訊系統的軟
硬體環境，程式碼的紀錄文件，和系統測試的計畫和結
系統分析與設計ch1
51
1.2.2 系統發展生命週期(9/14)

(5)系統上線與維護：這個階段是最後的階段，包括
系統的上線和後續的維護工作


系統正式上線必須採取一定的策略，計劃詳細的時程和
任務分配，包括什麼時候該哪一個模組上線、什麼時候
做資料的轉換、什麼時候轉換新的作業流程、使用者該
負哪些責任與該有哪些能力
對於未能於系統發展過程和上線初期就發現的錯誤，必
須進行系統的維護，以改進、加強系統的功能
系統分析與設計ch1
52
1.2.2 系統發展生命週期(10/14)

生命週期模式的重要性



生命週期開發模式並沒有規定一定要有哪些階段
它所強調的是要有規劃、有控制的來發展資訊系統
如果沒有採用某種開發模式來建置資訊系統，可能造成的後
果和缺點
 沒有人用的系統



資訊系統常出錯，不是資料錯誤，就是系統掛了
企業的實際流程完全不符合，導致系統產出的資訊也沒有人要用
失去控制的系統

系統分析與設計ch1
資訊系統的開發超出了預算，投入的人力和時間太多，以致於企業
難以負荷
53
1.2.2 系統發展生命週期(11/14)

跟著別人買的資訊系統



系統分析與設計ch1
企業常常會落到這樣的陷阱裡：同業都已經引進或是導入某
種資訊系統了，所以我們也一定要趕快購買，免得失去競爭
優勢或是無法生存
不管是向外購買或是自行開發，企業都應先做好需求的分析，
才不會盲目跟著別人買資訊系統
企業的需求在哪裡很重要
 企業真正的核心能力究竟是什麼，也就是說我們和別人不
同的、做得最好的部分在哪裡？
 要導入的資訊系統可以增加我們最強部分的能力嗎？能怎
麼做？可行嗎？
54
1.2.2 系統發展生命週期(12/14)

生命週期模式的缺失與改善建議

生命週期模式的缺點和改善的做法

開發的時間長



系統分析與設計ch1
生命週期開發模式需事先考量整體的需求，再做整個資訊系
統的設計，然後才進入程式撰寫、硬體配置的階段，循序地
一個階段一個階段開發
等到程式開發出來的時候，也許已經是一、兩年後的事了，
系統開發的時間可能會很長；結果，原先的需求可能早就改
變了
主要的解決辦法是將系統切割成多個子系統，將每次開發的
範圍縮小，一次只開發一小部分，或是由多個團隊同時平行
的來開發，以此來加快開發的速度。
55
1.2.2 系統發展生命週期(13/14)

直到系統完成後，使用者才看到資訊系統




系統分析與設計ch1
使用者都看不到所要開發的東西，光憑文字或是設計流程圖，
很難完全正確的溝通
資訊系統的運作是很複雜的，而且是和使用者互動的，有時
非要使用者使用系統一段時間之後，才會發現問題
解決這個問題的方法是採用雛型模式，在系統發展的早期，
採用快速開發的小系統
或是利用市面上現有的相似軟體，讓使用者試著操作，藉此
模擬將來的資訊系統作業，以確認需求和作業流程，把使用
者和開發者溝通的風險減低
56
1.2.2 系統發展生命週期(14/14)





在實務上，很多企業顧問公司或軟體公司都自行發展
適合自己資訊系統的方法論
大多仍根據規劃、需求分析、設計、開發、導入等階
段來實施
因為階段性的做法很嚴謹，能讓專案的發展容易控制、
且易於分配資源
每一個階段定義出要做的工作項目和產出的產品，然
後只要在每個階段都專心的做好該做的事情，就不會
讓專案失去重心、甚或是失控
每個專案中的成員都能了解專案的目標、目前的進度
和自己在專案中扮演的角色，並且能知道每一個階段
要做什麼，有所歸屬，因此也較能互相合作、包容
系統分析與設計ch1
57
1.2.3 統一流程模式(1/3)

統一流程模式 (RUP)




基本上是依照生命週期模式的觀念，將資訊系統開
發分成幾個階段
強調反覆 (Iterative) 和漸增 (Incremental) 的觀念，
縮短每個階段所需要的時間
快速的開發出一個可以執行的版本，然後經由使用
者測試、評估之後，再進行下一個版本的開發
這樣反覆開發的觀念，使得系統開發風險降低，並
且更貼近使用者需求，尤其小型的團隊開發更為適
用
系統分析與設計ch1
58
1.2.3 統一流程模式(2/3)

1. 初始階段 (Inception phase)




定義使用者以及系統主要功能，採用使用案例 (Use case)
來擷取需求，
決定專案管理、風險管理、及需求管理機制
建立開發環境，決定開發語言、測試工具以及整合工具
2. 詳述階段 (Elaboration phase)



定義本階段的目標，設計並建立測試計畫、資料庫、使用者
介面
撰寫並測試第一支程式
決定主要技術以及工具
系統分析與設計ch1
59
1.2.3 統一流程模式(3/3)

3. 建構階段 (Construction phase)




進行版本控制以及需求管理
撰寫、修改、測試程式以及使用者介面
撰寫使用手冊，持續建置資料庫
4. 轉移階段 (Transition phase)



整合測試，根據使用者需求修改系統
進行使用者教育訓練
打包系統並建立新版本，支援使用者，同時準備下
一版本的開發
系統分析與設計ch1
60
1.3 開發環境




1.3.1
1.3.2
1.3.3
1.3.4
系統分析與設計ch1
系統開發環境
版本控制與上版管理
專案管理
CASE－電腦輔助軟體工程工具
61
1.3.1

系統開發環境(1/6)
系統開發環境包含軟體以及硬體的環境


為避免在開發中因軟硬體設定不同而造成問題，開發團隊必
須要將各個工作團隊及個人的開發環境制度化，根據組織的
需要，決定一個可運作的開發環境
軟體環境
 包含伺服器端以及PC端的作業系統 (Operating System, OS )
 資料庫管理系統 (Database Management Systems, DBMS)
 程式語言整合開發環境 (Program Integrated Development
Environment, IDE)
 以及其他應用軟體，像是專案管理軟體 (Project
management software)
 電腦輔助軟體工程軟體 (Computer-Aided Software
Engineering, CASE)
系統分析與設計ch1
62
1.3.1
系統開發環境(2/6)
圖1-3 開發軟體環境架構圖
系統分析與設計ch1
63
1.3.1

系統開發環境(3/6)
在軟體環境的選擇上，開發團隊要考慮是目前
市面上最成熟、穩定、市場佔有率最高的軟體，
而不是考慮採用最新版本的軟體



最新的軟體可能有更快的速度以及更好的功能，但
是尚未經由廣大的使用者操作，穩定性堪慮
若使用太新的軟體，員工要先經過教育訓練，甚或
根本找不到會用的人
外界的資源也可能不足，像是市面上缺乏最新軟體
參考書，結果可能無法掌控該軟體
系統分析與設計ch1
64
1.3.1

系統開發環境(4/6)
硬體環境


開發機器 (Development machine)
 開發機器是指程式設計人員所使用的機器，也就是本地的
(Local) PC及伺服器
測試機器 (Test machine)
 專門用來測試程式設計師已完成的程式，並且整合既有的功
能，
 一面要確保舊有的功能不受新功能影響，且整合後的功能也
要運作順暢
 單元測試 (Unit test)、模組測試 (Modular test)、壓力測試
(Stress test)、系統整合測試 (System Integration test)、使
用者接受度測試 (User Acceptance test)、或商業模擬測試
(Business simulation test) 等
系統分析與設計ch1
65
1.3.1

系統開發環境(5/6)
線上機器 (Production machine)

測試完成的系統經過開發團隊及使用者開會同意，確認
目前開發的品質已能接受之後，此時的「目前最終版
本」，也就是所謂的產品 (Production)，才能放置於上
線機器上
系統分析與設計ch1
66
1.3.1
系統分析與設計ch1
系統開發環境(6/6)
圖1-4 開發硬體環境架構圖
67
1.3.2 版本控制與上版管理 (1/5)



現代資訊系統的開發需要團隊合作，而開發系
統又是一種智慧型的工作，隨著工作的需求，
團隊的人員可能會有所增減
因為成本的考量，開發團隊可能分散於不同的
地點，甚至將部分的系統或功能外包
(Outsourcing) 給企業外廠商，也是常見的狀
況
因此不論是需求、設計文件、會議紀錄、或是
程式碼，都需要做版本的控制和管理
系統分析與設計ch1
68
1.3.2 版本控制與上版管理 (2/5)

開發本地 (Workspace) 與線上產品
(Repository)


Workspace指的是系統在開發機器上的狀況，與之
前提到的開發機器一樣，只不過前述的是硬體的概
念，而Workspace則是邏輯的概念，包含硬體和軟
體
無論是程式碼或是文件，都需要有開發本地和線上
產品的區隔。Repository即是線上機器上的產品，
包含文件以及程式碼的最終版本
系統分析與設計ch1
69
1.3.2 版本控制與上版管理 (3/5)

提出 (Checkout) 與上傳 (Import)



開發人員平時在Workspace工作，當工作的內容已
經經過測試、審查，確認已完成了之後，才能上傳
合併到Repository去
當Repository需要做新增、修改或刪除時，開發人
員必須先由Repository做提出的動作
無論是上傳或是提出都需要做記錄，這個動作由一
個統一的中心控管
系統分析與設計ch1
70
1.3.2 版本控制與上版管理 (4/5)
系統分析與設計ch1
圖1-5 版本控管 － 提出與上傳
71
1.3.2 版本控制與上版管理 (5/5)
系統分析與設計ch1
圖1-6 上版管理
72
1.3.3 專案管理




專案管理 (Project management) 針對專案作規劃、
管理、控制開發的進度、人力的配置、定義工作項目
的前後順序 (Work Breakdown Structure, WBS)、定
義每個任務 (Task) 等
讓資訊系統的開發能有效控制成本及時間，達到預定
的控管
開發資訊系統的時間很長，相關的人、事、物很複雜，
需要的資金龐大
需要事先作良好的規劃，設定工作階段、安排適切的
工作項目以及時程表、建立專案進行之制度，比如像
工作的審查以及工作紀錄，開發環境的建制等
系統分析與設計ch1
73
1.3.4 CASE－電腦輔助軟體工程
工具





CASE工具是一種套裝軟體，用來輔助資訊系統的開
發
主要的內容是提供多種的圖形化工具，它不僅能從不
同的角度來解析資訊系統
還能將定義的名詞統一
甚至由系統設計的結果自動產生程式碼
CASE可以分成:




以語言為中心的環境 (Language-centered environments)
由結構來主導之環境 (Structure oriented environments)
工具組所組成之環境 (Toolkit environments)
以方法論為基礎的環境 (Method-based environments) 等不
同的種類
系統分析與設計ch1
74
1-4 文件的製作(1/2)



資訊系統的開發時間長，參與的人、事、物均
相當的複雜，在各階段的過程中，必須要加以
記錄 (Documentation)，否則相關開發人員無
法整合、協調、溝通
系統完成之後，更無法維護系統
記錄開發的過程，將產生各式技術文件
(Documents)
系統分析與設計ch1
75
1-4 文件的製作(2/2)

資訊系統開發文件的種類








1.系統規劃書 (System plan)
2.系統需求書 (System requirement specification)
3.系統規格書 (System design specification)
4.測試計畫及測試報告 (Test plan and Test report)
5.釋出計畫 (Release plan)
6.安裝說明 (Installation guide)
7.使用者手冊 (User manual)
8.會議紀錄 (Meeting minutes)
系統分析與設計ch1
76
1.4.1 文件的功能(1/2)


1. 溝通 :如果沒有將系統開發的計畫、需求、
設計、程式碼等，用正式的文件記錄下來，那
麼就沒有共同統一的標準 ，每個人的認知也
許會產生很多誤會。
2. 控制：文件是系統開發的進度紀錄，也是
功能範圍的依據，當確認了使用者的需求之後，
文件中的紀錄可以確保系統的開發不會偏離了
方向，並可確保開發者的工作範圍。
系統分析與設計ch1
77
1.4.1 文件的功能(2/2)

3. 記錄：資訊系統是智慧型人力密集開發的
工作成果，如果沒有將系統的開發細節記錄下
來，將來系統的維護會非常困難

如果沒有將每個人的工作內容以技術文件記錄下來，
當員工調職或離職時，其擔任的工作將無法由繼任
者承接
系統分析與設計ch1
78
1.4.2 文件的撰寫(1/3)

專業的文件：







專業的文件最需要的是清楚的格式，全份文件應該使用統一
的格式標準
圖和表要編號
有圖就要有文字說明
項目要前後一致
文件的封面和目錄，都要有一定的樣子
文字的格式也要一致 ，包括字體、大小、行距、空格等
文件是由正式的、一定規格的細節所組成，基本的樣子要符
合專業的期望
系統分析與設計ch1
79
1.4.2 文件的撰寫(2/3)

客觀的描述




以「報導式」的方法來撰寫
文件內不應該出現我、我們、你、你們、他、他們
當主詞的句子
應該避免太過於主觀情緒化的形容方式
找到大家可以接受的標準，以量化方式來衡量
系統分析與設計ch1
80
1.4.2 文件的撰寫(3/3)

盡量用條列式的方法



除了在摘要的部分之外，盡量用逐點條列的方式呈
現
最適當的大約是3到5點，不要大於7點
文件的使用


文件是記錄資訊系統的開發，以提供相關使用者查
詢用的，所以在撰寫文件時，每個部分必須能容易
查詢
一定要做好備份
系統分析與設計ch1
81
1.4.3 規格

規格 (Specification)





將顧客所需的樣子用專業的尺寸和標準的衡量制度一一寫下
來，就是規格
軟體的開發也是一樣，對於顧客的需求，必須以開發團隊都
看得懂的格式和符號來表示，也就是開出專業的系統規格，
這樣子，才能讓系統開發團隊達成溝通
系統的規格是設計圖和說明文件
由資料、功能、使用者、物件、物件狀態或網路的角度，定
義出所需要的內容和需求
系統分析與設計這門學科，主要的目的就是要講如何製作系
統的規格和設計、有哪些常用的圖形化工具、以及如何使用
這些工具，當學習完這些常用的工具之後，便能有專業的能
力來閱讀、使用、並製作軟體系統設計規格書
系統分析與設計ch1
82
1.4.4 文件的大綱(1/7)

系統規劃 (快速的描述、規劃將要開發的系統)
1. 摘要 (Why和What － 為什麼需要這個規劃中的資訊系統？企業目
前所遇到什麼問題？這個將要開發的系統到底是做什麼用？會給
企業帶來什麼好處？不要列點敘述)
2. 系統概述
a. 系統目的 (簡短)
b. 系統功能 (5個以上)
c. 系統效益 (列點說明，3~5點)
3. 資源需求
a. 人力組織 (開發團隊架構圖)
b. 時程表 (甘特圖)
c. 成本效益分析
附錄 (包含會議紀錄和同意書，要有使用者的簽名，表示同意本階段結
束並進入下一個階段；附錄中也可以包含參考資料)
系統分析與設計ch1
83
1.4.4 文件的大綱(2/7)

系統需求 (使用者的現況和未來的流程設計，以確認
系統功能)
1. 摘要 (說明本份文件的內容，包含哪些重要的項目；不要列
點)
2. 產業現況 (說明產業狀況，主要是描述企業所在的產業特性，
以及企業競爭者的資訊系統實施狀況、有哪些套裝軟體可以
使用；盡量列點敘述，或是圖形描述)
3. 企業背景 (說明企業的現況，企業的組織架構、經營理念、
產品、營業額、現有電腦設備、既有的資訊系統等，可以運
用企業診斷模型做分析和建議；盡量列點敘述，或是圖形描
述)
系統分析與設計ch1
84
1.4.4 文件的大綱(3/7)
4. 現行作業描述 (描述企業現行的作業流程，將來會被新系統取代的
功能目前的作業狀況；可以使用各種圖形來幫忙表示，如流程圖
來解析目前工作流程，主要問題的數量控制在大約3~5點，描寫的
時候要注意語氣，千萬不能流於批評，儘量以量化來表達作業所
需的時間和資源，找出作業的瓶頸或是問題)
5. 系統功能 (確認系統所要開發的功能；可以使用各種圖形來幫忙表
示，如Use case等情境描述的工具，標示出新作業方法所能改善
的地方，主要的功能大約是5~7個，每個功能作業都應該以圖形畫
出來，並且要加以說明；另外，應列出需求清單，詳細說明系統
需求，將系統效能的要求量化)
6. 系統取得評估 (主要是在決定本系統該如何取得：自行開發或是向
外購買？有沒有既有的套裝軟體是比較適合企業使用的？大約的
價錢如何？)
附錄 (包含會議紀錄和同意書，有使用者的簽名，表示同意本階段
結束並進入下一個階段；附錄中也可以包含參考資料)
系統分析與設計ch1
85
1.4.4 文件的大綱(4/7)

系統設計 (用各種角度來看這個資訊系統該開發成什麼樣子，才能
符合使用者的需求；最後將要開發的程式寫成虛擬碼，交給程式
設計師開發出所需的程式)
1. 摘要 (說明本分文件的內容，包含哪些重要的項目；不要列點)
2. 功能設計 (主要是設計系統該有哪些功能，以資料流程圖 [Data
Flow Diagram, DFD] 來架構)
a.
b.
c.
d.
e.
系統環境圖 (System context diagram)
圖0
圖1，圖2，圖3，…
圖1-1，圖1-2，圖1-3，…，圖2-1，圖2-2，圖2-3，…
資料字典 (Data dictionary)
3. 資料庫設計 (主要是架構資料庫)
a. 實體關係圖 (Entity Relationship Diagram, ERD)
b. 基本表
c. 外鍵關聯圖
系統分析與設計ch1
86
1.4.4 文件的大綱(5/7)
4. 物件導向設計 (以物件為角度設計系統)
a. 類別圖 (Class diagram)
b. 循序圖 (Sequence diagram)
c. 狀態圖 (State diagram)
5. 介面設計 (主要是在做使用者的介面)
a. 介面架構圖
b. 細部設計圖
6. 系統架構 (主要是在做硬體設備的建置設計)
a. 部署圖 (Deployment diagram)
7. 系統安全及授權 (主要是在為資訊系統的運作構想出安全的
措施，包含系統及資料的運作管理、備份、授權、災難回復
計畫等)
附錄 (包含會議紀錄和同意書，有使用者的簽名，表示同意
本階段結束並進入下一個階段；附錄中也可以包含參考資料)
系統分析與設計ch1
87
1.4.4 文件的大綱(6/7)

系統內容 (說明系統的軟硬體、測試、架構和使用者
手冊，頁數不定)
1. 摘要 (說明本份文件的內容，包含哪些重要的項目；不要列
點)
2. 系統軟體版本管理文件 (說明系統軟體的架構，包含作業系
統、資料庫軟體、應用程式等的版本以及之間的關係，記錄
下開發期間程式及文件版本的Check out及Import的人、事、
時、地、物等；另外，也需要記錄下每個釋出版本的細節，
包含每個版本的編號、名稱、功能、日期、使用者、以及在
需求文件中的對應編號)
3. 程式碼 (說明本系統自行開發的部分，有哪幾支程式？各應
對應哪一個模組、物件或是介面？說明程式的版本、內容、
撰寫程式的人、完成的日期、以及程式碼等)
系統分析與設計ch1
88
1.4.4 文件的大綱(7/7)
4. 系統測試計劃以及測試報告 (說明系統的測試設計、資料、
測試方法、日期、以及結果，並比較系統需求和測試結果)
5. 系統硬體架構 (說明硬體的設備狀況，包含主機、PC、周邊
設備、網路的架構等，將硬體的規格也做整體的說明，所購
買的廠商以及保固的狀況，都應加以描述)
6. 安裝手冊 (說明如何安裝系統，包含安裝、不同版本的異動、
以及移除的程序)
7. 使用者手冊 (這是給終端使用者用的，說明系統的主要功能
和操作方法；以往的系統比較重視使用者手冊，但現在的系
統大多僅簡單的描述)
附錄 (包含會議紀錄和同意書，有使用者的簽名，表示同意
本階段結束並進入下一個階段；附錄中也可以包含參考資料)
系統分析與設計ch1
89

系統分析與設計