软体生命周期课件.ppt

1、第二章 軟體生命週期 軟體工程-物件導向程式設計與UML系統分析實作2.1軟體生命週期模型 o軟體工程師或其小組必須混合包含過程、方法，及工具層次的開發策略。o這個策略經常被稱為軟體發展生命週期模軟體發展生命週期模型型(Software Development Life Cycle Model，SDLC)o軟體開發程序(Software Develop Procedure)o或稱為軟體工程規範(software engineering paradigm)。 軟體發展生命週期模型軟體發展生命週期模型o軟體發展生命週期模型軟體發展生命週期模型描述或定義軟體開發一系列的步驟或階段，其目的是提供開發者

2、一個系統性的流程，以成功地開發使用者所需要的軟體。圖 2-1 系統開發模型之演進 圖 2-2 物件導向軟體工程概念模型圖 2.2 軟體生命週期模型種類 o2.2.1 瀑布模型 o2.2.2 漸增模型 o2.2.3 快速雛形模型 o2.2.4 螺旋模型 2.2.1 瀑布模型 o瀑布模型瀑布模型(Waterfall Model，Royce(1970)有時稱為古典生命週期(classic life cycle)或線性序列模型。 o至少劃分3階段 (分析、設計、實施 ) 通常劃分57階段不等 圖2-3瀑布模型 瀑布模型o需求分析階段需求分析階段(Requirements analysis phase)

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

4、維護階段維護階段( Maintenances Phase) 軟體在交給客戶後，毫無疑問的一定會有改變的需求。使用瀑布模型會碰到以下的問題1. 1.很難依照模型的序列流程很難依照模型的序列流程2. 2.需求很難明確的表示需求很難明確的表示3. 3.客戶必須要有耐心客戶必須要有耐心2.2.2 漸增模型 o強調需求可分成幾個部分 開發週期可重覆往返進行。 圖2-4 漸增模型 2.2.3 快速雛形模型 o開始於需求的搜集。開發者和客戶會面，定義整個軟體目標，確認需求是否已明確了解，並描繪更進一步的定義。 圖2-5 雛形模型基本觀念 2.2.4 螺旋模型 o將瀑布模型的最終結果導回源頭，成為一個往復式的

5、圓圈（Cycle），使整個流程具備回饋與檢驗機制，這就是螺旋模型螺旋模型(Spiral model，Boehm(1988)。 圖2-6 螺旋模型 2.3 選用軟體生命週期模型 o該採用何種模型並沒有一定，必須取決於程式語言程序型或物件導向型、時程長短、成本大小、人力充足與否、組織型態.等各種因素，來選擇適合該軟體專案的過程模型。2.4 軟體開發程序 o軟體開發程序(Software Develop Process)則是著重在於達成某一特定目標的一系列活動。 軟體程序軟體程序o軟體程序軟體程序是一組的工具、方法、作法，用以製造軟體產品。 RUPo軟體工程在近代最有名且使用在物件導向是Ration

6、al統一流程(Rational Unified sProcess， 簡稱RUP) 2.4.1 Rational統一流程 oRational統一流程統一流程(Rational Unified Process，簡稱RUP註:因為是Rational 公司強力發展，現已被IBM公司併購。 o共有三大特點、四個階段和九個核心流程。 RUP最重要的它有三大特點o軟體開發是一個疊代(Iteration,註:有人翻譯程重覆往返)過程。o軟體開發是由Use Case驅動的。o軟體開發是以構架設計（Architectural Design）為中心的。四個階段o1. 起始階段起始階段(Initial phase):

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

8、iness Modeling)(Business Modeling) o2. 需求需求(Requirements) (Requirements) o3. 分析和設計分析和設計(Analysis & Design) (Analysis & Design) o4. 實作實作(Implementation) (Implementation) o5. 測試測試(Test) (Test) o6. 部署部署(Deployment) (Deployment) o7. 配置和變更管理配置和變更管理(Configuration & Change (Configuration & Change Managemen

9、t) Management) 。 o8. 專案管理專案管理(Project Management) (Project Management) 。 o9. 環境環境(Environment) (Environment) 。 RUP優點o（1） 該程序方法論結合了許多來自眾多的成功方法論，提供完整的軟體開發流程。o（2） 結合採用反覆式（Iterative）開發流程失敗,可降低開發的風險。o（3） UML作為其視覺化軟體分析與設計語言，使軟體開發人員之間的溝通與資訊的交換無礙。o（4）以UML中的使用者案例（Use-Case）作為整個Rational Unified Process的核心。o（5）

10、受到工具的支援:程序經過良好的支援，且受到好的工具支援。例如:Rational Rose。o（6） 對於軟體開發各階段中所參與之角色皆定義每一個角色所應有之責任與活動。RUP缺點o學習困難: 為了無所不包，相對使得該程序變的非常巨大，不論是學習或管理都很困難。o花費很多時間: 各專案使用該方法論，會花上許多的時間。o工具受限: 支援工具相對受限於Rational自己的產品。(註:Rational公司是該幾位物件導向大師所設立的公司。)圖2-7統一軟體發展流程 圖圖 2-8 2-8 直線式流程對往覆式與漸直線式流程對往覆式與漸增式的流程風險比較增式的流程風險比較2.5能力成熟度模式整合(CMMI

11、) 2.5.1 CMMI的由來 oCMMI(Capacity Mature Model Integration，能力成熟度模式整合)便是軟體工程具體化的最佳例子，並非是一種軟體生命週期模型，而是一個軟體生產標準流程，無關於開發軟體使用何種軟體生命週期模型。 o2000年底卡內基-梅隆大學軟體工程研究所 (SEI)發表了能力成熟度模式整合(CMMI) 圖 2-9 CMMI 的歷史沿革示意圖 公司引進CMMI後成長實例 ol 生產力約有10%到20%的提昇。ol 產品錯誤率約降低一個數量級。ol 對專案的預估與控制能力約提昇40%到50%。ol 依據 SEI 的研究資料顯示，成功公司軟體產品的瑕疵

12、，比不成功的公司少了1/3以上，客戶滿意度也因而較高。ol 軟體成熟度每提昇一級，約可降低5%到10%的開發成本。 ol 洛克希德公司在連續五年改善軟體開發流程後，軟體瑕疵數降低90%，上市時間增快40%，開發成本則降低75%。2.5.2 CMMI的模型和層級 o分成五個等級(Level )nCMMI-Level 1Level 1初始層初始層（Initial） nCMMI-Level 2Level 2重覆層重覆層（Repeatable） nCMMI-Level 3Level 3定義層定義層（Defined） nCMMI-Level 4Level 4管理層管理層（Managed） nCMMI-L

13、evel 5Level 5最佳層最佳層（Optimized） 圖 2-10 CMMI 五個層級 CMMI-Level 1Level 1初始層初始層（Initial）o軟體程序漫無章法，程序未被定義。 CMMI-Level 2Level 2重覆層重覆層Repeatable）o已建立基本的管理程序，對成本、時程、和職務權責能加以追蹤、查詢。已有作業程序所須具有的紀律，所以有能力重覆使用相類似的專案成功的案例與經驗。 CMMI-Level 3Level 3定義層定義層（Defined）o屬於管理和工程的活動都已設計、定義好，並且文件化，完整地整合成組織內的標準作業程序。 CMMI-Level 4Le

14、vel 4管理層管理層（Managed）o組織可收集詳細的軟體程序以及軟體產品的量測資料。 CMMI-Level 5Level 5最佳層最佳層Optimized）o評估革新性的新技術，做反省與提升，有規則地依序導入採用，以持續不斷地改進程序。 2.5.3 CMMI的關鍵流程領域（Key Process Area，KPA） o每個成熟度層級內部各包含了數目不等的關鍵流程領域關鍵流程領域(Key Process Areas，KPAs) 圖圖2-11 2-11 軟體成熟度模式結構軟體成熟度模式結構關鍵流程領域（Key Process Area，KPA）o每一個關鍵流程領域則認定了一群相關的活動，以作

15、為完成該關鍵流程領域的目標,目標中所描述的是關於該關鍵流程領域的關鍵技巧(Key Practices，KPs)的總體，可由此目來判定組織或專案是否有效地實施此關鍵流程領域。 o第一層是毫無章法的管理，所以沒有任何KPA，而第二層到第五層，每一成熟度階層都由一些KPA所組成。 表2-1關鍵流程領域 目標(Goals) o每個KPA都設定有一組目標，標示出KPA的範圍、界限與企圖。 關鍵技巧（Key Practice，KP） o每一個KPA是由幾個KP來描述，而KP是描述將KPA有效地的實現和制度化所需的重要活動與基礎建設（infrastructure）。 共同特徵（Common feature）

16、o共同特徵是屬性的表徵，經由它們可以來判定KPA的實施與制度化上是否具有效性、可否重複使用執行、以及是否可持續下去。 表2-2 CMMI中四個特徵2.5.5 CMMI鑑定鑑定(CBA)oCMMI鑑定工作須由SEI授權之主導評審員負責依SEI之方法及資料執行，並將執行結果回報給SEI。 2.5.6 CMMI國內現況 o目前是由軟體自由協會成立軟體工業生產力提升計畫辦公室來輔導企業進行相關認証，而資策會技術處則取得政府補助，負責導入相關相關技術，以培養人力。 o國內的軟體廠商大部份爭取的是CMMI的Level II認證，目前國內已有多家取得CMMI認證，工研院電通所、碩網資訊、三商電腦、英特連.等

17、。台積電的軟體部門也要透過印度Tata consulting來取得level 3認証。 2.6 ISO 9000 oISO9000本質上是一個品質管理系統標準，在品質系統建置的過程中，對品質系統架構面提供了一個良好的指導，可以幫助組織建立一個完整且能持續改善的品質系統。 2.6.1 ISO 9000-3 o軟體業也能夠採用ISO 9001標準，ISO公佈了ISO 9000-3的指導方針來因應具有開發製造，供給維護流程的軟體產業。2.6.2 ISO 9000品質系統的建置 o流程導向的品質管理系統，是為了更切合客戶的需要，新的標準在概念及結構上，被“流程方式”所取代，新的流程化架構和計劃-實施-

18、檢查-執行（Plan-Do-Check-Action）改善循環程序一致。 圖 2-12 品質管理系統的架構圖 2.6.3 ISO-9000與軟體工程 o軟體工程重點項目:o1. 合約與需求管理o2. 軟體開發流程與標準o3. 建構管理之實施o4. 軟體審查與驗證o5. 軟體測試o6. 專案管理o7. 系統維護管理o8. 量測與統計2.6.4 ISO 9000與CMMI oISO 9000是以架構整體品質系統為優先，再透過持續改善的過程，加強每一流程到理想的程序。o而CMMI模式則對每一關鍵流程的導入有著較嚴格的要求，但以分批逐步導入的方式架構整個品質系統。o雖然導入的邏輯不同，但如果能確實的建

19、置、實施、與持續改善品質系統，兩者都可以為軟體業建置出一個能有效提昇企業競爭力與品質的品質系統。 2.6.5 ISO 9000國內現況 o國內目前也已經有四十家以上之資訊軟體公司取得ISO-9000認證。 o國內軟體公司卻常常迫於績效或市場需要，而期望在六個月以內通過ISO-9000認證，通過後亦不積極於進行持續改善。 2.7 CASE Tool oCASE Tool (Computer-Aided Software Engineering Tool，電腦輔助軟體工程工具) 是一種電腦工具，是用以將資訊系統的開發與維護的流程自動化的利器。oRational的Rose 作為業界普遍公認的標準，S

20、ybase PowerDesigner也符合此一標準。 2.8 案例研討-訂房系統 採用RUP的精神o可先將飯店管理系統，如圖2-13是其功能架構圖，先拆成房間管理系統、訂房處理系統、會員管理系統、財務報表系統和系統設定系統等。再將訂房處理系統再拆成若干子系統，例如: 訂房子系統、取消訂房子系統、Check-in系統、Check-out子系統等。 o每次重覆循環只發展一個重要的子系統，依照開發系統流程從需求、分析、設計、實作和測試等，完成每一個子系統並且釋出一個可執行的版本 圖2-14訂房系統開發順序圖 2.9 總結 o必須依據該軟體專案的各種特性，例如程式語言程序型或物件導向型、時程長短、成本大小、人力充足與否、組織型態。等各種因素，來選擇適合該軟體專案的生命週期模型。