1 / 61

軟體生命週期管理與實作

軟體生命週期管理與實作. 主講者 : 蘇中和 經歷 : 鼎升科技軟體工程處技術顧問兼專案經理 樹德科大資管系兼任講師 專業證照 : SCJP,SCWCD,MCSD.NET,MCDBA,Oracle 美國 PMP 專案管理師證照. 軟體生命週期. 軟體工程. 2.1 軟體生命週期模型. 軟體工程師或其小組必須混合包含過程、方法，及工具層次的開發策略。 軟體發展生命週期模型 (Software Development Life Cycle Model ， SDLC) 軟體開發程序 (Software Develop Procedure)

gallia
Download Presentation

軟體生命週期管理與實作

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 軟體生命週期 軟體工程

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

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

  5. 系統開發模型之演進

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

  7. 2.2 軟體生命週期模型種類 • 2.2.1 瀑布模型 • 2.2.2 漸增模型 • 2.2.3 快速雛形模型 • 2.2.4 螺旋模型

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

  9. 瀑布模型

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

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

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

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

  14. 雛形模型基本觀念

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

  16. 圖2-6 螺旋模型

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

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

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

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

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

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

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

  24. 九個核心工作流程(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) 。

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

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

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

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

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

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

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

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

  33. 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）

  34. 圖 2-10 CMMI 五個層級

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

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

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

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

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

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

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

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

  43. 表2-1關鍵流程領域

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

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

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

  47. 表2-2 CMMI中四個特徵

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

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

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

More Related