軟體生命週期管理與實作  主講者 : 蘇中和  經歷 : 鼎升科技軟體工程處技術顧問兼專案 經理  樹德科大資管系兼任講師  專業證照 : SCJP,SCWCD,MCSD.NET,MCDBA,Oracle 美國 PMP 專案管理師證照

軟體生命週期 軟體工程

2.1 軟體生命週期模型  軟體工程師或其小組必須混合包含過程、 方法，及工具層次的開發策略。 軟體發展生命週期模型 (Software Development Life Cycle Model ， SDLC) 軟體開發程序 (Software Develop Procedure) 稱為軟體工程規範 (software engineering paradigm) 。

軟體發展生命週期模型  軟體發展生命週期模型 描述或定義軟體開發一系列的步驟或階段 目的是提供開發者一個系統性的流程，以成功 地開發使用者所需要的軟體。

系統開發模型之演進

物件導向軟體工程概念模型圖

2.2 軟體生命週期模型種類  瀑布模型  漸增模型  快速雛形模型  螺旋模型

2.2.1 瀑布模型  瀑布模型 (Waterfall Model ， Royce(1970)) 有 時稱為古典生命週期 (classic life cycle) 或線 性序列模型。  至少劃分 3 階段 ( 分析、設計、實施 ) 通常 劃分 5~7 階段不等

瀑布模型

 需求分析階段 (Requirements analysis phase) 需求搜集的過程是以軟體 為特別的焦點。要了解所要建立程式的特性。  規格階段 (Specification Phase): 一但客戶同意在需求階段的了解後，規 格小組 (Specification team) 將畫出規格文件 (Specification document) 。  設計階段 (Design Phase) 設計過程將需求轉變為軟體的表示，以便在 程式碼產生前了解其品質。  建置階段 (Implementation Phase) 設計必須被轉變為機器可讀取的形式。 這項工作即進行程式碼產生的步驟。  測試階段 (Testing Phase) 一旦程式碼產生後，即開始進行程式測試。。  維護階段 ( Maintenances Phase) 軟體在交給客戶後，毫無疑問的一定 會有改變的需求。

使用瀑布模型會碰到以下的問題 1. 很難依照模型的序列流程 2. 需求很難明確的表示 3. 客戶必須要有耐心

2.2.2 漸增模型  強調需求可分成幾個部分 開發週期可重覆 往返進行。

2.2.3 快速雛形模型  開始於需求的搜集。開發者和客戶會面， 定義整個軟體目標，確認需求是否已明確 了解，並描繪更進一步的定義。

雛形模型基本觀念

2.2.4 螺旋模型  將瀑布模型的最終結果導回源頭，成為一 個往復式的圓圈（ Cycle ），使整個流程具 備回饋與檢驗機制，這就是螺旋模型 (Spiral model ， Boehm(1988)) 。

圖 2-6 螺旋模型

2.3 選用軟體生命週期模型  該採用何種模型並沒有一定，必須取決於 程式語言程序型或物件導向型、時程長短、 成本大小、人力充足與否、組織型態.. 等各 種因素，來選擇適合該軟體專案的過程模 型。

2.4 軟體開發程序  軟體開發程序 (Software Develop Process) 則 是著重在於達成某一特定目標的一系列活 動。

軟體程序  軟體程序是一組的工具、方法、作法，用 以製造軟體產品。

RUP  軟體工程在近代最有名且使用在物件導向 是 Rational 統一流程 (Rational Unified sProcess ， 簡稱 RUP)

2.4.1 Rational 統一流程  Rational 統一流程 (Rational Unified Process ， 簡稱 RUP 註 : 因為是 Rational 公司強力發展， 現已被 IBM 公司併購。  共有三大特點、四個階段和九個核心流程。

RUP 最重要的它有三大特點  軟體開發是一個疊代 (Iteration, 註 : 有人翻譯 程重覆往返 ) 過程。  軟體開發是由 Use Case 驅動的。  軟體開發是以構架設計（ Architectural Design ）為中心的。

四個階段  1. 起始階段 (Initial phase): 進行可行性研究，定義 出專案大小及涵蓋範圍，評估專案所需的能力、 時程與經費，以及資訊系統預期達到之效益 · 了 解商業模型及需求。  2. 精細規劃階段 (Elaboration phase): 擬定專案計畫、 系統特性與架構 · 確認商業模型及需求 · 進行系統 分析與設計。  3. 建構階段 (Construction phase): 建構產品並進行 單元測試、整合測試。  4. 移轉階段 (Transition phase): 將產品分批交付給 客戶進行驗收測試，並進行使用者訓練。

九個核心工作流程 (Core Workflows)  1. 商業塑模 (Business Modeling)  2. 需求 (Requirements)  3. 分析和設計 (Analysis & Design)  4. 實作 (Implementation)  5. 測試 (Test)  6. 部署 (Deployment)  7. 配置和變更管理 (Configuration & Change Management) 。  8. 專案管理 (Project Management) 。  9. 環境 (Environment) 。

RUP 優點  （ 1 ） 該程序方法論結合了許多來自眾多的成功方法論， 提供完整的軟體開發流程。  （ 2 ） 結合採用反覆式（ Iterative ）開發流程失敗, 可降低 開發的風險。  （ 3 ） UML 作為其視覺化軟體分析與設計語言，使軟體 開發人員之間的溝通與資訊的交換無礙。  （ 4 ）以 UML 中的使用者案例（ Use-Case ）作為整個 Rational Unified Process 的核心。  （ 5 ）受到工具的支援 : 程序經過良好的支援，且受到好的 工具支援。例如 :Rational Rose 。  （ 6 ） 對於軟體開發各階段中所參與之角色皆定義每一個 角色所應有之責任與活動。

RUP 缺點  學習困難 : 為了無所不包，相對使得該程序變的 非常巨大，不論是學習或管理都很困難。  花費很多時間 : 各專案使用該方法論，會花上許 多的時間。  工具受限 : 支援工具相對受限於 Rational 自己的產 品。 ( 註 :Rational 公司是該幾位物件導向大師所設立的公 司。 )

圖 2-7 統一軟體發展流程

直線式流程對往覆式與漸增式的 流程風險比較

2.5 能力成熟度模式整合 (CMMI)

2.5.1 CMMI 的由來  CMMI(Capacity Mature Model Integration ， 能力成熟度模式整合 ) 便是軟體工程具體化 的最佳例子，並非是一種軟體生命週期模 型，而是一個軟體生產標準流程，無關於 開發軟體使用何種軟體生命週期模型。  2000 年底卡內基 - 梅隆大學軟體工程研究所 (SEI) 發表了能力成熟度模式整合 (CMMI)

圖 2-9 CMMI 的歷史沿革示意圖

公司引進 CMMI 後成長實例  l 生產力約有 10% 到 20% 的提昇。  l 產品錯誤率約降低一個數量級。  l 對專案的預估與控制能力約提昇 40% 到 50% 。  l 依據 SEI 的研究資料顯示，成功公司軟體產品的瑕疵， 比不成功的公司少了 1/3 以上，客戶滿意度也因而較高。  l 軟體成熟度每提昇一級，約可降低 5% 到 10% 的開發成 本。  l 洛克希德公司在連續五年改善軟體開發流程後，軟體瑕 疵數降低 90% ，上市時間增快 40% ，開發成本則降低 75% 。

2.5.2 CMMI 的模型和層級  分成五個等級 (Level ) CMMI-Level 1 初始層（ Initial ） CMMI-Level 2 重覆層（ Repeatable ） CMMI-Level 3 定義層（ Defined ） CMMI-Level 4 管理層（ Managed ） CMMI-Level 5 最佳層（ Optimized ）

圖 2-10 CMMI 五個層級

CMMI-Level 1 初始層（ Initial ）  軟體程序漫無章法，程序未被定義。

CMMI-Level 2 重覆層 Repeatable ）  已建立基本的管理程序，對成本、時程、 和職務權責能加以追蹤、查詢。已有作業 程序所須具有的紀律，所以有能力重覆使 用相類似的專案成功的案例與經驗。

CMMI-Level 3 定義層（ Defined ）  屬於管理和工程的活動都已設計、定義好， 並且文件化，完整地整合成組織內的標準 作業程序。

CMMI-Level 4 管理層（ Managed ）  組織可收集詳細的軟體程序以及軟體產品 的量測資料。

CMMI-Level 5 最佳層 Optimized ）  評估革新性的新技術，做反省與提升，有 規則地依序導入採用，以持續不斷地改進 程序。

2.5.3 CMMI 的關鍵流程領域（ Key Process Area ， KPA ）  每個成熟度層級內部各包含了數目不等的 關鍵流程領域 (Key Process Areas ， KPAs)

圖 2-11 軟體成熟度模式結構

關鍵流程領域（ Key Process Area ， KPA ）  每一個關鍵流程領域則認定了一群相關的 活動，以作為完成該關鍵流程領域的目標, 目標中所描述的是關於該關鍵流程領域的 關鍵技巧 (Key Practices ， KPs) 的總體，可 由此目來判定組織或專案是否有效地實施 此關鍵流程領域。  第一層是毫無章法的管理，所以沒有任何 KPA ，而第二層到第五層，每一成熟度階 層都由一些 KPA 所組成。

表 2-1 關鍵流程領域

目標 (Goals)  每個 KPA 都設定有一組目標，標示出 KPA 的範圍、界限與企圖。

關鍵技巧（ Key Practice ， KP ）  每一個 KPA 是由幾個 KP 來描述，而 KP 是描 述將 KPA 有效地的實現和制度化所需的重 要活動與基礎建設（ infrastructure ）。

共同特徵（ Common feature ）  共同特徵是屬性的表徵，經由它們可以來 判定 KPA 的實施與制度化上是否具有效性、 可否重複使用執行、以及是否可持續下去。

表 2-2 CMMI 中四個特徵

2.5.5 CMMI 鑑定 (CBA)  CMMI 鑑定工作須由 SEI 授權之主導評審員 負責依 SEI 之方法及資料執行，並將執行結 果回報給 SEI 。

2.5.6 CMMI 國內現況  目前是由軟體自由協會成立軟體工業生產 力提升計畫辦公室來輔導企業進行相關認 証，而資策會技術處則取得政府補助，負 責導入相關相關技術，以培養人力。  國內的軟體廠商大部份爭取的是 CMMI 的 Level II 認證，目前國內已有多家取得 CMMI 認證，工研院電通所、碩網資訊、 三商電腦、英特連.. 等。台積電的軟體部門 也要透過印度 Tata consulting 來取得 level 3 認証。

2.6 ISO 9000  ISO9000 本質上是一個品質管理系統標準， 在品質系統建置的過程中，對品質系統架 構面提供了一個良好的指導，可以幫助組 織建立一個完整且能持續改善的品質系統。

2.6.1 ISO  軟體業也能夠採用 ISO 9001 標準， ISO 公佈 了 ISO 的指導方針來因應具有開發 製造，供給維護流程的軟體產業。

2.6.2 ISO 9000 品質系統的建置  流程導向的品質管理系統，是為了更切合 客戶的需要 新的標準在概念及結構上，被 “ 流程方式 ” 所取 代，新的流程化架構和計劃 - 實施 - 檢查 - 執行 （ Plan-Do-Check-Action ）改善循環程序一致。

圖 2-12 品質管理系統的架構圖

2.6.3 ISO-9000 與軟體工程  軟體工程重點項目 :  1. 合約與需求管理  2. 軟體開發流程與標準  3. 建構管理之實施  4. 軟體審查與驗證  5. 軟體測試  6. 專案管理  7. 系統維護管理  8. 量測與統計

2.6.4 ISO 9000 與 CMMI  ISO 9000 是以架構整體品質系統為優先，再透過 持續改善的過程，加強每一流程到理想的程序。  而 CMMI 模式則對每一關鍵流程的導入有著較嚴 格的要求，但以分批逐步導入的方式架構整個品 質系統。  雖然導入的邏輯不同，但如果能確實的建置、實 施、與持續改善品質系統，兩者都可以為軟體業 建置出一個能有效提昇企業競爭力與品質的品質 系統。

2.6.5 ISO 9000 國內現況  國內目前也已經有四十家以上之資訊軟體 公司取得 ISO-9000 認證。  國內軟體公司卻常常迫於績效或市場需要， 而期望在六個月以內通過 ISO-9000 認證， 通過後亦不積極於進行持續改善。

2.7 CASE Tool  CASE Tool (Computer-Aided Software Engineering Tool ，電腦輔助軟體工程工具 ) 是一種電腦工具，是用以將資訊系統的開 發與維護的流程自動化的利器。  Rational 的 Rose 作為業界普遍公認的標準， Sybase PowerDesigner 也符合此一標準。

2.8 案例研討 - 訂房系統

採用 RUP 的精神  可先將飯店管理系統，如圖 2-13 是其功能架構圖， 先拆成房間管理系統、訂房處理系統、會員管理 系統、財務報表系統和系統設定系統等。再將訂 房處理系統再拆成若干子系統，例如 : 訂房子系 統、取消訂房子系統、 Check-in 系統、 Check-out 子系統等。  每次重覆循環只發展一個重要的子系統，依照開 發系統流程從需求、分析、設計、實作和測試等， 完成每一個子系統並且釋出一個可執行的版本

圖 2-14 訂房系統開發順序圖

總結  必須依據該軟體專案的各種特性，例如程 式語言程序型或物件導向型、時程長短、 成本大小、人力充足與否、組織型態。等 各種因素，來選擇適合該軟體專案的生命 週期模型。