軟體工程系列文章一

軟體程序

軟體開發中所遵循的路線圖稱為「軟體程序」

能力成熟度模型 (CMM)

CMM 將軟體程序改進分為以下 5 個成熟度等級

1. 初始級 (Initial)

​ 軟體的特點是雜亂無章，有時甚至很混亂，幾乎沒有明確定義的步驟，專案的完成完全依賴個人的努力和英雄式核心人物的作用

2. 可重複級 (Repeatable)

​ 建立了基本的專案管理程序和實踐來追蹤專案的費用、進度與功能特性，有必要的程序準則來重複以前在同類專案中的成功

3. 已定義級 (Defined)

​ 管理和工程兩方面的軟體程序已經文件化、標準化，並整合為整個軟體開發組織的標準軟體程序。所有專案都採用根據實際情況修改後得到的標準軟體程序來開發和維護軟體

4. 已管理級 (Managed)

​ 制定了軟體程序和產品品質的詳細衡量標準。軟體程序的產品品質都被開發組織的成員所理解和控制

5. 優化級 (Optimized)

​ 加強了定量分析，透過來自程序品質回饋和來自新觀念、新技術的回饋使程序能不斷持續地改進

CMM 模型提供了一個框架，將軟體程序改進的演進步驟組織成 5 個成熟度等級，為程序不斷改進奠定了循序漸進的基礎。這 5 個成熟度等級定義了一個有序的尺度，用來衡量一個組織的軟體程序成熟度與評估其軟體程序能力

能力成熟度模型整合 (CMMI)

CMM 的成功導致了適用不同學科領域的模型衍生，但一個工程常常涉及多個交叉學科，因此有必要將各種程序改進的工作整合起來。CMMI 是若干程序模型的綜合與改進

CMMI 提供了兩種表示方法：階段式模型與連續式模型

1. 階段式模型

階段式模型的結構類似於 CMM，它關注組織的成熟度。CMMI-SE/SW/IPPD 1.1 版中有 5 個成熟度等級

• 初始的：程序不可預測且缺乏控制
• 已管理的：程序為專案服務
• 已定義的：程序為組織服務
• 定量管理的：程序已衡量與控制
• 最佳化的：集中於程序改進

2. 連續式模型

連續式模型關注每個程序領域的能力，一個組織對不同的程序可以達到不同的程序領域能力等級 (Capability Level, CL)。CMMI 中包括 6 個程序領域能力等級，等級號為 0~5。能力等級包括共性目標及相關的共性實踐，這些實踐在程序領域內被新增到特定目標和實踐中。當組織滿足程序領域的特定目標和共性目標時，就說該組織達到了那個程序領域的能力等級

• CL₀ (未完成的) ：程序領域未執行或未達到 CL₁ 中定義的所有目標
• CL₁ (已執行的) ：其共性目標是程序將可識別的輸入工作產品轉換成可識別的輸出工作產品，以實現支援程序領域的特定目標
• CL₂ (已管理的) ：其共性目標集中於已管理的程序的制度化。根據組織級政策規定程序的運作將使用哪個程序，專案遵循已文件化的計畫和程序描述，所有正在工作的人都有權使用足夠的資源，所有工作任務和工作產品都被監控、控制和審查
• CL₃ (已定義級的) ：其共性目標集中於已定義的程序的制度化。程序是按照組織的客製化指南從組織的標準程序集中客製化得到的，還必須收集程序資產和程序的衡量，並用於將來對程序的改進
• CL₄ (定量管理的) ：其共性目標集中於可定量管理的程序的制度化。使用衡量與品質保證來控制和改進程序領域，建立和使用關於品質與程序執行的定量目標作為管理準則
• CL₅ (最佳化的) ：使用量化 (統計學) 手段改變和最佳化程序領域，以滿足客戶要求的改變和持續改進計畫中的程序領域的功效

軟體程序模型

軟體程序模型習慣上也稱為軟體開發模型，它是軟體開發全部程序、活動與任務的結構框架。典型的軟體程序模型有瀑布模型、增量模型、演化模型 (原型模型、螺旋模型) 、噴泉模型、基於元件的開發模型與形式化方法模型等

瀑布模型

瀑布模型是將軟體生命週期中的各個活動規定為依線性順序連接的若干階段的模型，包括需求分析、設計、編碼、測試、運行與維護。它規定了由前至後、相互銜接的固定次序，如同瀑布流水逐級下落

瀑布模型為軟體的開發與維護提供了一種有效的管理模式，根據這一模式制定開發計畫，進行成本預算，組織開發力量，以專案的階段審查與文件控制為手段有效地對整個開發程序進行指導，所以它是以文件作為驅動、適合於軟體需求很明確的軟體專案的模型

瀑布模型假設，一個待開發的系統需求是完整的、簡潔的、一致的，而且可以先於設計和實現完成之前產生

瀑布模型的優點是，容易理解，管理成本低；強調開發的階段性早期計畫及需求調查與產品測試 不足之處是，客戶必須能夠完整、正確與清晰地表達他們的需求；在開始的兩個或三個階段中，很難評估真正的進度狀態；當接近專案結束時，出現了大量的整合與測試工作；直到專案結束之前，都不能展示系統的能力 在瀑布模型中，需求或設計中的錯誤往往只有到了專案後期才能夠被發現，對於專案風險的控制能力較弱，因而導致專案常常延期完成，開發費用超出預算

V 模型

瀑布模型的一個變體是 V 模型

V 模型描述了品質保證活動與溝通、建模相關活動以及早期建構相關活動之間的關係。隨著軟體團隊工作沿著 V 模型左側步驟向下推進，基本問題需求逐步細化，形成問題及解決方案的技術描述。一旦編碼結束，團隊沿著 V 模型右側的步驟向上推進工作，其實際上是執行了一系列測試 (品質保證活動) ，這些測試驗證了團隊沿著 V 模型左側步驟向下推進過程中所生成的每個模型。V 模型提供了一種將驗證確認活動應用於早期軟體工程工作中的方法

增量模型

增量模型融合了瀑布模型的基本成分與原型實現的迭代特徵，它假設可以將需求分段為一系列增量產品，每一增量可以分別開發。該模型採用隨著時程進展而交錯的線性序列，每一個線性序列產生軟體的一個可發布的「增量」

當使用增量模型時，第一個增量往往是核心產品。客戶對每個增量的使用與評估都作為下一個增量發布的新特徵與功能，這個程序在每一個增量發布後不斷重複，直到產生了最終的完善產品。增量模型強調每一個增量均發布一個可操作的產品

增量模型作為瀑布模型的一個變體，具有瀑布模型的所有優點。此外，它還有以下優點：第一個可交付版本所需要的成本與時間很少；開發由增量表示的小系統所承擔的風險不大；由於很快發布了第一個版本，因此可以減少使用者需求的變更；運行增量投資，即在專案開始時，可以僅對一個或兩個增量投資

增量模型有以下不足之處：如果沒有對使用者的變更要求進行規劃，那麼產生的初始增量可能會造成後來增量的不穩定；如果需求不像早期思考的那樣穩定與完整，那麼一些增量就可能需要重新開發、重新發布；管理發生的成本、進度與配置的複雜性可能會超出組織的能力

演化模型

軟體類似於其他複雜的系統，會隨著時間的推移而演化。在開發程序中，常常會面臨以下情形：商業與產品需求經常變化，直接導致最終產品難以實現；嚴格的交付時間使得開發團隊不可能圓滿地完成軟體產品，但是必須交付功能有限的版本以應對競爭或商業壓力；很好地理解了核心產品與系統需求，但是產品或系統拓展的細節問題卻沒有定義。在上述情況和類似情況下，軟體開發人員需要一種專門應對不斷演變的軟體產品的程序模型

演化模型是迭代的程序模型，使得軟體開發人員能夠逐步開發出更完整的軟體版本。演化模型特別適用於對軟體需求缺乏準確認識的情況。典型的演化模型有原型模型與螺旋模型等

原型模型 (Prototype Model)

並非所有的需求都可預先定義，大量的實踐表明，在開發初期很難得到一個完整的、準確的需求規格說明。這主要是由於客戶往往不能準確地表達對未來系統地全面要求，開發者對要解決的應用問題模糊不清，以至於形成的需求規格說明常常是不完整的、不準確的，有時甚至是有歧義的。此外，在整個開發程序中，使用者可能會產生新的要求，導致需求的變更。而瀑布模型難以適應這種需求的不確定性與變化，於是出現了快速原型 (Rapid Prototype) 這種新的開發方法。原型方法比較適合於使用者需求不清、需求經常變化的情況。當系統規模不是很大也不太複雜時，採用該方法比較好

原型是預期系統的一個可執行版本，反映了系統性質的一個選定子集。一個原型不必滿足目標軟體的所有限制，其目的是能快速、低成本地建構原型。當然，能夠採用原型方法是因為開發工具的快速發展，使得能夠迅速地開發出一個讓使用者看得見、摸得著的系統框架。這樣，對於電腦不是很熟悉的使用者就可以根據這個框架提出自己的需求。開發原型系統首先確定使用者需求，開發初始原型，然後徵求使用者對初始原型的改進意見，並根據意見修改原型

原型模型開始於溝通，其目的是定義軟體的總體目標，識別需求，然後快速制定原型開發的計畫，確定原型的目標與範圍，採用快速設計的方式對其進行建模，並建構原型。被開發的原型應交付給客戶使用，並收集客戶的回饋意見，這些回饋意見可在下一輪中對原型進行改進。在前一個原型需要改進，或者需要擴展其範圍的時候，進入下一輪原型的迭代開發

螺旋模型

對於複雜的大型軟體，開發一個原型往往達不到要求。螺旋模型將瀑布模型與演化模型結合起來，加入了兩種模型均忽略的風險分析，彌補了這兩種模型的不足

螺旋模型將開發程序分為幾個螺旋週期，每個螺旋週期大致與瀑布模型相符合，每個螺旋週期分為如下 4 個工作步驟

1. 制定計畫。確定軟體的目標，選定實施方案，明確專案開發的限制條件
2. 風險分析。分析所選的方案，識別風險，消除風險
3. 實施工程。實施軟體開發，驗證階段性產品
4. 使用者評估。評估開發工作，提出修正建議，建立下一個週期的開發計畫

螺旋模型強調風險分析，使得開發人員與使用者對每個演化層出現的風險有所了解，因而做出應有的反應。因此，該模型特別適用於龐大、複雜並且具有高風險的系統

與瀑布模型相比，螺旋模型支援使用者需求的動態變化，為使用者參與軟體開發的所有關鍵決策提供了方便，有助於提高軟體的適應能力，並且為專案管理人員及時調整管理決策提供了便利，因而降低了軟體開發的風險。在使用螺旋模型進行軟體開發時，需要開發人員具有相當豐富的風險評估經驗與專業知識。另外，過多的迭代次數會增加開發成本，延遲提交時間

噴泉模型

噴泉模型是一種以使用者需求為動力，以物件作為驅動的模型，適合於物件導向的開發方法。它克服了瀑布模型不支援軟體重用和多項開發活動整合的局限性。噴泉模型使開發程序具有迭代性與無間隙性

迭代意味著模型中的開發活動常常需要重複多次，在迭代程序中不斷地完善軟體系統，無間隙是指在開發活動 (如分析、設計、編碼) 之間不存在明顯地邊界，也就是說，它不像瀑布模型那樣，在需求分析活動結束後才開始設計活動，在設計活動結束後才開始編碼活動，而是允許各開發活動交叉、迭代地進行

噴泉模型的各個階段沒有明顯的界限，開發人員可以同步進行。其優點是可以提高軟體專案的開發效率，節省開發時間。由於噴泉模型在各個開發階段是重疊的，在開發程序中需要大量的開發人員，不利於專案的管理。此外，這種模型要求嚴格管理文件，使得審核的難度加大

統一程序 (UP) 模型

統一程序模型是一種「用例和風險驅動，以架構為中心，迭代並且增量」的開發程序，由 UML 方法與工具支援。迭代的意思是將整個軟體開發專案劃分為許多個小的「袖珍專案」，每個「袖珍專案」都包含正常軟體專案的所有元素：計畫、分析與設計、建構、整合與測試，以及內部與外部發布

統一程序定義了 4 個技術階段及其產物

1. 起始階段 (Inception Phase)

   初始階段專注於專案的初創活動，產生的主要工作產品有構想文件 (Vision Document) 、初始用例模型、初始專案術語表、初始業務用例、初始風險評估、專案計畫 (階段及迭代) 、業務模型以及一個或多個原型 (需要時)

2. 精化階段 (Elaboration Phase)

   精化階段在理解了最初的領域範圍之後進行需求分析與架構演進，產生的主要工作產品有用例模型、補充需求、分析模型、軟體架構描述等

3. 建構階段 (Construction Phase)

   建構階段關注系統的建構，產生實現模型，產生的主要工作產品有設計模型、軟體元件、整合的軟體增量、測試計畫及步驟、測試用例以及支援文件

4. 移交階段 (Transition Phase)

   移交階段關注於軟體提交方面的工作，產生軟體增量，產生的主要工作產品有提交的軟體增量、β 測試報告與綜合使用者回饋

每次迭代產生包括最終系統的部分完成的版本與任何相關的專案文件的基準，透過逐步迭代基準之間相互建構，直到完成最終系統。在每個迭代中有 5 個核心工作流程：

1. 捕捉系統應該做什麼的需求工作流程
2. 精化與結構化需求的分析工作流程
3. 在系統架構內實現需求D的設計工作流程
4. 建構軟體的實現工作流程
5. 驗證實現是否如期望那樣運作的測試工作流程

隨著 UP 的階段進展，每個核心工作流程的工作量發生了變化。4 個技術階段由主要里程碑所終止

• 初始階段：生命週期目標
• 精化階段：生命週期架構
• 建構階段：初始運作功能
• 移交階段：產品發布

統一程序的典型代表是 RUP (Rational Unified Process)。RUP 是 UP 的商業擴展，完全相容 UP，但比 UP 更完整、更詳細

敏捷方法

敏捷開發的總體目標是透過「盡可能早地、持續對有價值的軟體的交付」使客戶滿意。透過在軟體開發程序中加入靈活性，敏捷方法 (Agile Development) 使用者能夠在開發週期的後期新增或改變需求

敏捷程序的典型方法有很多，每一種方法基於一套原則，這些原則實現了敏捷方法所宣稱的理念 (敏捷宣言)

1. 極限編程 (XP)

XP 是一種輕量級 (敏捷) 、高效、低成本、彈性、可預測的、科學的軟體開發方式。它由價值觀、原則、實踐與行為 4 個部分組成，彼此相互依賴、關聯，並透過行為貫穿於整個生命週期

• 4 大價值觀：溝通、簡單性、回饋與勇氣
• 5 大原則：快速回饋、簡單性假設、逐步修改、提倡修改與優質工作
• 12 個最佳實踐
  • 計畫遊戲 (快速制定計畫、隨著細節的不斷變化而完善)
  • 小型發布 (系統的設計要能夠盡可能早地交付)
  • 隱喻 (找到合適的譬喻傳達訊息)
  • 簡單設計 (只處理目前的需求，使設計保持簡單)
  • 測試先行 (先寫測試程式碼，然後再編寫程式)
  • 重構 (重新審視需求與設計，重新明確地描述它們以符合新的與現有的需求)
  • 結對編程
  • 集體程式碼所有制
  • 持續整合 (可以按日甚至按小時為客戶提供可運行的版本)
  • 每週工作 40 個小時
  • 現場客戶 (系統最終使用者代表應該全程配合 XP 團隊)
  • 編碼標準

2. 水晶法 (Crystal)

水晶法認為每一個不同的專案都需要一套不同的策略、約定與方法論

認為人對軟體品質有重要的影響，因此隨著專案品質與開發人員素質的提高，專案與程序的品質也隨之提高。透過更好地交流與經常性的交付，軟體生產力得到提高

3. 並列爭球法 (Scrum)

並列爭球法使用迭代的方法，其中，把每 30 天一次的迭代稱為一個「衝刺」，並按需求的優先級別來實現產品。多個自組織與自治的小組平行地遞增實現產品，協調是透過簡短的日常情況會議來進行，就像橄欖球中的「並列爭球」。步驟如下：

4. 自適應軟體開發 (ASD)

ASD 有 6 個基本的原則

• 有一個使命作為指導
• 特徵被視為客戶價值的關鍵點
• 程序中的等待是很重要的，因此「重做」與「做」同樣關鍵
• 變化不被視為改正，而是被視為對軟體開發實際情況的調整
• 確定的交付時間迫使開發人員認真考慮每一個生產的版本的關鍵需求
• 風險也包含其中

5. 敏捷統一程序 (AUP)

敏捷統一程序 (Agile Unified Process, AUP) 採用「在大型上連續」以及「在小型上迭代」的原理來建構軟體系統。採用經典的 UP 階段性活動 (初始、精化、建構與轉換) ，提供了一系列活動，能夠使團隊為軟體專案構想出一個全面的程序流程。在每個活動裡，一個團隊迭代使用敏捷，並將有意義的軟體增量盡可能快地交付給最終使用者。每個 AUP 迭代執行以下活動

• 建模。建立對商業與問題領域的模型表述，這些模型「夠好」即可，以便團隊繼續前進
• 實現。將模型翻譯為原始程式碼
• 測試。像 XP 一樣，團隊設計與執行一系列的測試來發現錯誤以確保原始程式碼滿足需求
• 部署。對軟體增量的交付以及取得最終使用者的回饋
• 組態與專案管理。著眼於變更管理、風險管理以及對團隊的任一產物的控制。專案管理追蹤與控制開發團隊的工作進展並協調團隊活動
• 環境管理。協調標準、工具以及適用於開發團隊的支援技術等程序基礎設施