Transcript 1-3 軟體開發生命週期

第1章 軟體工程與系統開發概論
 1-1 軟體與資訊系統
 1-2 軟體工程的基礎
 1-3 軟體開發生命週期
 1-4 軟體生命週期模型
1-2 軟體工程的基礎
 1-2-1 軟體工程
 1-2-2 軟體開發的完整流程
1-2-1 軟體工程-說明
 軟體工程（Software Engineering）主要是在研究如何使用
系統化、組織化和量化方法來進行軟體系統的開發，也就
是嘗試使用一些經過驗證且可行的方法，在可接受的時間
和預算內開發出高品質的軟體系統。
 簡單的說，軟體工程是一門學科，可以整合方法、工具和
流程來將真實世界的需求轉換成軟體世界的軟體，如下圖
所示：
1-2-1 軟體工程-方法、工具和流程
 方法（Methods）：一種建立軟體的方法，即第13節軟體開發生命週期的各種活動：需求、分析、
設計、實作、測試和部署等。
 工具（Tools）：自動或半自動支援方法的工具，
包含語法檢查、文件出版、專案管理和系統分析
設計工具等，即所謂的CASE工具（ComputerAided Software Engineering Tools）。
 流程（Procedures）：定義各活動執行順序的流程
來建立軟體，並且提供軟體品質的管控與變更的
協調。
1-2-2 軟體開發的完整流程
 一般來說，當公司或
行號需要軟體來幫助
進行商業活動，或解
決特定問題時，就可
以開始進行軟體開發
的流程，完整的軟體
開發流程如右圖所示
：
1-3 軟體開發生命週期-說明
 「軟體開發生命週期」（Software Development
Life Cycle，SDLC）包含軟體開發過程的活動和建
立的工作產品（Work Products），主要分成兩大
類，如下所示：
• 以活動為中心（Activity-Centered）：專注於整個軟體
開發過程的活動（Activities）。
• 以實體為中心（Entity-Centered）：專注於整個軟體開
發過程中，在上述活動建立的工作產品（Work
Products）。
1-3 軟體開發生命週期-基本活動
 雖然目前有相當多種軟體開發生命週期，不過各
種軟體開發生命週期擁有的基本活動，或稱為階
段（Phases）有：
•
•
•
•
•
•
需求
分析
設計
實作
測試
部署
1-3 軟體開發生命週期-需求
 需求（Requirement）是程式開發者與客戶和使用
者共同定義的系統需求，可以擷取出系統的功能
性和非功能性需求，其簡單說明如下所示：
• 功能性需求（Functional Requirements）：描述系統一
定需要提供的功能，也就是定義系統輸入和輸出行為
的規格。例如：選課系統提供註冊和選課功能。
• 非功能性需求（Nonfunctional Requirements）：描述系
統特性或一些限制條件。例如：選課系統限制學生只
能選15門課。
1-3 軟體開發生命週期-分析
 在定義出系統需求後，就可以針對需求進行分析
（Analysis），以便將系統需求抽象化到應用系統
之中。簡單的說，就是從系統需求找出解決方案
。目前仍然是以高階角度來看問題，並不涉及應
用程式的軟硬體架構，和使用哪一種程式語言來
實作。
1-3 軟體開發生命週期-設計
 在取得系統需求和完成分析（Analysis）後，設計
（Design）是建立完整的解決方案，詳細描述如
何建立整個軟體系統來滿足定義的系統需求。主
要可以分成兩部分，如下所示：
• 系統設計（System Design）：決定系統的軟硬體架構，
使用的作業系統，並且將系統分割成子系統，評估是
否使用資料庫系統來儲存永久性資料（Persistent Data
）等。
• 物件設計（Object Design）：將分析建立的分析模型（
Analysis Model）或概念模型（Conceptual Model）轉換
成設計模型（Design Model），也就是找出完整的物件
屬性、方法和更詳細的類別關係（Relationships）。
1-3 軟體開發生命週期-實作
 實作（Implementation）就是撰寫程式碼（Coding
），將建立的設計模型（Design Model）使用指定
程式語言來撰寫出原始程式碼，例如：C++、C#、
Viaual Basic和Java等語言，即所謂的實作模型（
Implementation Model）。
1-3 軟體開發生命週期-測試
 測試（Testing）如同工廠生產線的品質管制，其
目的是確認已經成功建立一套可用的軟體程式。
其主要工作有兩項，如下所示：
• 證實（Verification）：檢查實作建立的程式是否符合定
義的需求。
• 驗證（Validation）：測試是否真正解決客戶問題和滿
足客戶需求。
1-3 軟體開發生命週期-部署
 部署（Deployment）是在軟體完成測試後，將最
終釋出版本的軟體交至客戶的使用者，包含軟體
安裝、教育訓練和使用手冊等。
1-4 軟體生命週期模型
 1-4-1 瀑布式模型
 1-4-2 反覆式與漸進式模型
 1-4-3 雛型模型
 1-4-4 螺旋模型
 1-4-5 Rational統一流程
 1-4-6 模型驅動架構
1-4 軟體生命週期模型
 「軟體生命週期模型」（Software Lifecycle Models
）簡稱生命週期模型，或稱為系統開發流程模型
（System Development Process Models），可以用
來指導我們如何進行分析、設計、開發和維護資
訊系統。
1-4-1 瀑布式模型-簡介
 瀑布式模型（Waterfall Model）源於早期結構化系
統開發（Structured System Development），屬於
一種傳統的生命週期模型，它是1970年代最常用
的生命週期模型，並且成功使用COBOL語言建立
多個大型專案。
 瀑布式模型對於程式開發者來說，這是一種相當
直覺的軟體開發過程，它就是循序執行一序列的
開發與管理過程（Processes），每一個過程就是
第1-3節的活動，開發過程需要等到前一個活動完
成後，才允許進入下一個活動。
1-4-1 瀑布式模型-圖例
瀑布模式的缺點
 成本及資源需求估計不準確
1.
需求可完全且清楚描述?
2.
不完整的需求分析經常造成此種結果
 風險高
1. 程式編輯於系統開發週期之後段才開始，故風
險較高，且失敗之成本亦較高。
2. 客戶必須等到了安裝、及驗收的最後階段才能
看到可執行的軟體系統的運作狀況
瀑布模式的缺點(cont.)

1.
2.
3.
4.
5.
在程式編輯前過於強調完整的分析與設計文件。
故一旦需求變更，文件便需大幅修改。
系統開發週期較長且過程中使用者參與不足。
不能迅速反應需求的改變
不能儘早得到使用者對產出系統的回應與建議
程式編輯於系統開發週期之後段才開始，故風險較高，
且失敗之成本亦較高。
1-4-2 反覆式與漸進式模型-簡介
 隨著物件導向技術的成熟，再加上物件導向分析
與設計的普及，瀑布式開發過程因為無法快速建
立產品且缺乏彈性的問題，已經逐漸被反覆式與
漸進式模型（Iterative and Incremental Model）所
取代。
 反覆式與漸進式模型首先針對幾個主要需求來進
行開發，以便快速建立初期版本的產品，然後將
產品交給客戶試用，程式開發者針對試用結果的
回應來修正系統，以便儘早發現可能的錯誤。
1-4-2 反覆式與漸進式模型-圖例
1-4-3 雛型模型-簡介
 雛型模型（Prototyping Model）主要是針對哪些在專案初
期無法了解完整需求的情況，因為使用者只知道系統部分
功能的大概，而無法詳細描述系統完整的特點和功能。此
時，我們可以使用雛型模型來進行系統開發，而不用一開
始就了解使用者的完整需求。
 雛型模型在作法上是先建立一個簡單的初期版本，即雛型
，然後提交給客戶進行評估，這部分也屬於雛型模型流程
的一部分，等到客戶回應後，再依據回應的需求開發新系
統，通常雛型的程式碼會捨棄，然後依據客戶確認的需求
來開發全新的系統。
1-4-3 雛型模型-圖例
雛型模式的潛在問題
•
工作雛型不斷的修改系統文件較不完備，程式亦較難
維護。短期可能較能滿足使用者需求，但長期而言，
系統較易失敗。
•
因缺乏整體之規劃、分析與設計，故較不適用於大型
及多人參與之系統開發專案.
•
缺少有效的設計評估準則
1-4-4 螺旋模型-簡介
 螺旋模型（Spiral Model）是整合瀑布式和雛型模
型的優點，並且導入風險分析（Risk Assessment）
的生命週期模型，風險分析是在開發流程新增步
驟來評估每一個版本的雛型，以決定是否繼續開
發，如果客戶覺的風險太高，整個專案可能會停
止。
 螺旋模型的整個開發流程是使用螺旋方式來進行
每一次的循環，共分為4個象限：計劃（Planning
）、風險分析（Risk Assessment）、工程（
Engineering）和客戶評估（Customer Evaluation）
。
1-4-4 螺旋模型-圖例
螺旋模式缺點
•
•
進化的過程不容易控制
需要很多風險評估的專業知識
1-4-5 Rational統一流程-說明
 IBM公司的Rational統一流程（Rational Unified Process，
RUP）不僅僅是一個生命週期模型，還是一個支援開發者
的完整開發環境，稱為RUP平台（RUP Platform），可以使
用IBM公司的CASE工具來進行Rational統一流程的物件導向
系統開發，即Rational Rose或Software Architect。
 物件導向方法論
 Rational統一流程是Ivar Jacobson、Grady Booch和James
Rumbaugh融合他們的OOSE、Booch和OMT物件導向方法論
後，在Rational公司提出的物件導向方法論，可以使用物
件導向技術來開發軟體或資訊系統。
 方法論（Methodology）是指能夠解決各種問題的方法集
合。方法（Methods）則是定義一種可重複使用的技術來
解決指定的問題，這是一個能夠複製的流程，以便取得解
決指定問題的可靠結果，如下圖所示：
1-4-5 Rational統一流程-物件導向方法論
 Rational統一流程是Ivar Jacobson、Grady Booch和James
Rumbaugh融合他們的OOSE、Booch和OMT物件導向方法論
後，在Rational公司提出的物件導向方法論，可以使用物
件導向技術來開發軟體或資訊系統。
 方法論（Methodology）是指能夠解決各種問題的方法集
合。方法（Methods）則是定義一種可重複使用的技術來
解決指定的問題，這是一個能夠複製的流程，以便取得解
決指定問題的可靠結果，如下圖所示：
1-4-5 Rational統一流程-主要特點
 使用案例驅動（Use-Case Driven）：Rational統一流程是一
種使用案例驅動的軟體程式開發過程，使用案例不只可以
使用在需求階段，它還主導整個開發過程。在方法論的每
一個反覆過程都是由選擇的使用案例來啟動，程式開發者
從使用案例出發進行物件導向分析與設計；測試者以使用
案例來測試實作的系統是否符合使用案例的需求。
 架構中心（Architecture-Centric）：因為軟體架構會影響系
統重要的靜態和動態觀點，所以，Rational統一流程是以
架構為中心來進行軟體系統開發。在選擇的軟體架構下建
立多種使用案例來描述系統功能，不過只有5%到10%的主
要使用案例會用來建構系統的核心功能，呈現出子系統、
建立類別和元件。
 反覆式與漸進式（Iterative and Incremental）：Rational統
一流程是一種反覆式與漸進式的軟體開發過程。
1-4-5 Rational統一流程-工作流程
 Rational統一流程共有9個核心工作流程（Core Workflows
），分為6個核心處理工作流程（Core Process Workflows）
和3個核心支援工作流程（Core Supporting Workflows），
如下圖所示：
1-4-5 Rational統一流程-四個階段
 Rational統一流程是一種反覆式與漸進式的生命週期模型
，提供一套完整的軟體開發工作流程，包括商業塑模、需
求、分析、設計、實作、測試和部署等。基本上，
Rational統一流程適用在大型資訊系統的開發，其開發過
程分成四個階段，如下圖所示：
1-4-5 Rational統一流程-反覆過程
 Rational統一流程的四個階段各自擁有多個反覆過程，每
個反覆過程包含商業塑模、需求、分析、設計、實作、測
試和部署等工作流程，如下圖所示：
1-4-5 Rational統一流程-四個階段的說明
 初始階段（Inception Phase）：在此階段訂出專案的範圍
與目標，列出可能的軟體架構，識別出可能的風險和決定
如何處理它。
 強化階段（Elaboration Phase）：在此階段的目標是建立
足夠的能力，在開發小組面對財務、時程和其他限制條件
下建立新系統，其主要工作是以使用案例來執行需求擷取
和定義系統架構。
 建構階段（Construction Phase）：使用反覆式和漸進式模
型來建立軟體系統，可以在客戶測試環境成功的執行此系
統。
 轉換階段（Transition Phase）：將軟體系統安裝與上線使
用，釋出Beta測試版本取得使用者回應，以便依據使用者
的回應來更新系統，完成此階段的主要里程碑就是釋出正
式版本。
RUP模式生命週期
階段、目標與里程碑
 初始階段
目標：
 瞭解專案範圍  建立企業個案  取得有關人員對推展該專案的認同
里程碑：完成專案生命週期目標
 詳述階段
目標：
 降低主要技術之風險  創造系統基本結構  瞭解用何資源以建構系統
里程碑：完成生命週期結構
 建構階段
目標：
 建構與演化可運作的系統版本
里程碑：初步可運作的系統版本 （常稱為β版）
 轉移階段
目標：
 建立最終版本的軟體系統，並移交給客戶
里程碑：完成軟體產品出版
1-4-6 模型驅動架構-說明
 模型驅動架構（Model Driven Architectiure，MDA）是由
OMG（Object Management Group）組織開發的生命週期框
架（Lifecycle Framework），這是使用模型驅動方式（
Model Driven Approach）來進行軟體系統的開發。
 模型（Models）是使用文字或圖形來描述系統規格和其環
境，模型驅動就是在生命週期的分析、設計、實作、測試
和部署流程，專注於不同層次模型的建立。
 MDA是將統一塑模語言（Unified Modeling Language）視為
一種可執行規格（Executable Specifications），可以將我們
使用UML建立的模型直接轉換成不同平台的程式碼。
1-4-6 模型驅動架構-架構流程
1-4-6 模型驅動架構-變形與對映
 變形（Transformation）是一種過程，可以將PIM加上其他
資訊來變形轉換產生PSM，多個PSM變形產生不同的程式
碼，例如：Java或C#程式碼。一般來說，CASE工具可以支
援模型之間的自動變形轉換，當然部分變形轉換仍然需要
人工來處理，換句話說，在MDA建立的模型是一種「變形
模型」（Transformation Model），如下圖所示：