软体生命周期

第二章軟體生命週期

軟體工程-物件導向程式設計與UML系統分析實作2.1軟體生命週期模型

軟體工程師或其小組必須混合包含過程、方法，及工具層次的開發策略。這個策略經常被稱為軟體發展生命週期模型(SoftwareDevelopmentLifeCycleModel，SDLC)軟體開發程序(SoftwareDevelopProcedure)或稱為軟體工程規範(softwareengineeringparadigm)。

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

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

2.2軟體生命週期模型種類

2.2.1瀑布模型

2.2.2漸增模型

2.2.3快速雛形模型

2.2.4螺旋模型

2.2.1瀑布模型

瀑布模型(WaterfallModel，Royce(1970))有時稱為古典生命週期(classiclifecycle)或線性序列模型。

至少劃分3階段(分析、設計、實施)通常劃分5~7階段不等

圖2-3瀑布模型

瀑布模型需求分析階段(Requirementsanalysisphase)需求搜集的過程是以軟體為特別的焦點。要了解所要建立程式的特性。規格階段(SpecificationPhase):一但客戶同意在需求階段的了解後，規格小組(Specificationteam)將畫出規格文件(Specificationdocument)。設計階段(DesignPhase)設計過程將需求轉變為軟體的表示，以便在程式碼產生前了解其品質。建置階段(ImplementationPhase)設計必須被轉變為機器可讀取的形式。這項工作即進行程式碼產生的步驟。測試階段

(TestingPhase)一旦程式碼產生後，即開始進行程式測試。。維護階段(MaintenancesPhase)軟體在交給客戶後，毫無疑問的一定會有改變的需求。使用瀑布模型會碰到以下的問題很難依照模型的序列流程需求很難明確的表示客戶必須要有耐心2.2.2漸增模型

強調需求可分成幾個部分開發週期可重覆往返進行。

圖2-4漸增模型

2.2.3快速雛形模型

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

圖2-5雛形模型基本觀念

2.2.4螺旋模型

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

圖2-6螺旋模型

2.3選用軟體生命週期模型

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

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

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

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

2.4.1Rational統一流程

Rational統一流程(RationalUnifiedProcess，簡稱RUP註:因為是Rational公司強力發展，現已被IBM公司併購。

共有三大特點、四個階段和九個核心流程。

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

起始階段(Initialphase):進行可行性研究，定義出專案大小及涵蓋範圍，評估專案所需的能力、時程與經費，以及資訊系統預期達到之效益·了解商業模型及需求。2.

精細規劃階段(Elaborationphase):擬定專案計畫、系統特性與架構·確認商業模型及需求·進行系統分析與設計。3.

建構階段(Constructionphase):建構產品並進行單元測試、整合測試。4.

移轉階段(Transitionphase):將產品分批交付給客戶進行驗收測試，並進行使用者訓練。九個核心工作流程(CoreWorkflows)

1.

商業塑模(BusinessModeling)

2.

需求(Requirements)3.

分析和設計(Analysis&Design)4.

實作(Implementation)5.

測試(Test)6.

部署(Deployment)

7.

配置和變更管理(Configuration&Change Management)。8.

專案管理(ProjectManagement)。9.

環境(Environment)。

RUP優點（1）

該程序方法論結合了許多來自眾多的成功方法論，提供完整的軟體開發流程。（2）

結合採用反覆式（Iterative）開發流程失敗,可降低開發的風險。（3）

UML作為其視覺化軟體分析與設計語言，使軟體開發人員之間的溝通與資訊的交換無礙。（4）以UML中的使用者案例（Use-Case）作為整個RationalUnifiedProcess的核心。（5）受到工具的支援:程序經過良好的支援，且受到好的工具支援。例如:RationalRose。（6）

對於軟體開發各階段中所參與之角色皆定義每一個角色所應有之責任與活動。RUP缺點學習困難:為了無所不包，相對使得該程序變的非常巨大，不論是學習或管理都很困難。花費很多時間:各專案使用該方法論，會花上許多的時間。工具受限:支援工具相對受限於Rational自己的產品。(註:Rational公司是該幾位物件導向大師所設立的公司。)圖2-7統一軟體發展流程

圖2-8直線式流程對往覆式與漸增式的流程風險比較2.5能力成熟度模式整合(CMMI)2.5.1CMMI的由來CMMI(CapacityMatureModelIntegration，能力成熟度模式整合)便是軟體工程具體化的最佳例子，並非是一種軟體生命週期模型，而是一個軟體生產標準流程，無關於開發軟體使用何種軟體生命週期模型。2000年底卡內基-梅隆大學軟體工程研究所(SEI)發表了能力成熟度模式整合(CMMI)圖2-9CMMI的歷史沿革示意圖公司引進CMMI後成長實例l

生產力約有10%到20%的提昇。l

產品錯誤率約降低一個數量級。l

對專案的預估與控制能力約提昇40%到50%。l

依據SEI的研究資料顯示，成功公司軟體產品的瑕疵，比不成功的公司少了1/3以上，客戶滿意度也因而較高。l

軟體成熟度每提昇一級，約可降低5%到10%的開發成本。l

洛克希德公司在連續五年改善軟體開發流程後，軟體瑕疵數降低90%，上市時間增快40%，開發成本則降低75%。2.5.2CMMI的模型和層級

分成五個等級(Level)CMMI-Level1初始層（Initial）

CMMI-Level2重覆層（Repeatable）

CMMI-Level3定義層（Defined）

CMMI-Level4管理層（Managed）

CMMI-Level5最佳層（Optimized）

圖2-10CMMI五個層級

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

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

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

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

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

2.5.3CMMI的關鍵流程領域（KeyProcessArea，KPA）

每個成熟度層級內部各包含了數目不等的關鍵流程領域(KeyProcessAreas，KPAs)

圖2-11軟體成熟度模式結構關鍵流程領域（KeyProcessArea，KPA）每一個關鍵流程領域則認定了一群相關的活動，以作為完成該關鍵流程領域的目標,目標中所描述的是關於該關鍵流程領域的關鍵技巧(KeyPractices，KPs)的總體，可由此目來判定組織或專案是否有效地實施此關鍵流程領域。

第一層是毫無章法的管理，所以沒有任何KPA，而第二層到第五層，每一成熟度階層都由一些KPA所組成。

表2-1關鍵流程領域

目標(Goals)

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

關鍵技巧（KeyPractice，KP）

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

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

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

2.5.6CMMI國內現況

目前是由軟體自由協會成立軟體工業生產力提升計畫辦公室來輔導企業進行相關認証，而資策會技術處則取得政府補助，負責導入相關相關技術，以培養人力。

國內的軟體廠商大部份爭取的是CMMI的LevelII認證，目前國內已有多家取得CMMI認證，工研院電通所、碩網資訊、三商電腦、英特連..等。台積電的軟體部門也要透過印度Tataconsulting來取得level3認証。

2.6ISO9000

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

2.6.1ISO9000-3

軟體業也能夠採用ISO9001標準，ISO公佈了ISO9000-3的指導方針來因應具有開發製造，供給維護流程的軟體產業。2.6.2ISO9000品質系統的建置

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

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

2.6.3ISO-9000與軟體工程

軟體工程重點項目:1.

合約與需求管理2.

軟體開發流程與標準3.

建構管理之實施4.

軟體審查與驗證5.

軟體測試6.

專案管理7.

系統維護管理8.

量測與統計2.6.4ISO9000與CMMI

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

2.6.5ISO90