第 7 章 軟體開發流程

1. 第7章 軟體開發流程　

2. 本章大綱 7.1　何謂軟體流程？ 7.2　軟體流程的類型　 7.3　線性流程模型 　 7.4　多循環流程模型 　 7.5　新式軟體流程 7.6 如何選擇軟體流程 7.7 結語　

3. 學習目標 瞭解何謂軟體流程 瞭解各種軟體流程的類型 瞭解何謂新式的軟體流程 瞭解如何選擇軟體流程

4. 何謂軟體流程？(1/6) 所謂流程（process），從字面上來看，是指一系列的步驟，其中包含：活動、限制、使用的資源，以及期望產出的描述。 根據Humphrey與Feiler的說法：「軟體流程是一組部分相依、為達到目標而執行的一系列步驟。」 至於軟體流程的內容，則包含了定義、分析、設計、建構及測試等活動。 除了步驟之外，軟體流程還應該包括各個活動的說明：由誰　執行、何時做、做什麼與如何做，以及預定產出之文件（或編碼）、使用的電腦資源與組織結構（或限制）等。

5. 何謂軟體流程？(2/6) • 軟體流程相關術語 • 人員（worker）：定義個別成員或一群人組成的團隊之角色與責任。 • 任務（activity）：流程裡由人員所執行之活動單元。 • 產物（artifact）：由流程所產生、修改及使用的資訊，以程式碼或文件的形式表示。 • 開發週期（cycle）：開發週期就是軟體專案所涵蓋的範圍，其產出即是產品；通常一個週期推出一個新的、符合用戶需求的產品。

6. 何謂軟體流程？(3/6) • 階段（phase）：將開發週期進一步地切割，可分成幾個階段；每個階段代表軟體開發特定的活動。至於階段如何劃分？代表的活動為何？則由軟體流程決定。 • 循環（iteration）：當前的軟體流程思維傾向將軟體開發分成許多小段落來進行，一個段落就是一個循環，包含從用戶需求到程式產出中間所有的活動。 • 工作流（workflow）：是指一系列的活動，會產出被觀察到的結果、模型、程式碼等。工作流可以跨越不同的階段，使一些軟體開發相關重要的工作，能夠串接起來而不被中斷。 • 軟體流程的分解與透視，如圖7.1所示。

7. 階段 需求 循環 設計 測試 編碼 活動 (b) 階段一 階段n 階段二 (a) 圖7.1 軟體流程循環與分層透視圖

8. 何謂軟體流程？(4/6) • 軟體流程模型 • 軟體流程模型是軟體流程的抽象化表示法，係從一般性的角度來描述如何組織專案的活動。 • 流程模型可以分成兩種 • 敘述型（descriptive）：提供一些流程設計的原則與指引，目的在於協助思考，幫助專案經理與團隊，決定哪些工作需要完成、以怎樣的順序進行。 • 規範型（prescriptive）：必須「照表操課」；流程與流程模型的關係，就好像物件與類別間的關係，完全繼承模型的所有規範。

9. 何謂軟體流程？(5/6) • 軟體流程的設計考量 • 各階段的活動該如何安排與劃分？ • 流程中的活動往往彼此重疊，甚至交互影響很難切割。這些要如何解決？ • 如何確保（或知道）每一階段的活動都正確達成目標？ • 流程的透明度如何？專案管理部分要如何處理？

10. 何謂軟體流程？(6/6) • 軟體流程在開發上所扮演的角色 • 軟體流程是軟體開發的方法或步驟，幾乎所有軟體工程的活動都與流程有關，但這也是最分歧、最麻煩的部分。 • 選用適當的軟體流程可帶來許多優點，例如：提高軟體開發速度、改善軟體品質、改善專案的追蹤與控管、降低風險暴露，以及改善與顧客間的關係等。 • 選用錯誤的流程，則會減緩開發速度、產生不必要的問題，以及遭遇到挫折。

11. 軟體流程的類型(1/9) • 依「流程步驟之順序」分類 • 線性流程 • 多循環流程 • 編碼與除錯 • 正規模式 • 再用導向開發 • 依「流程工作之負載」分類 • 前負載型流程 • 後負載型流程 • 平衡型流程

12. 軟體流程的類型(2/9) • 依「流程步驟之順序」分類 • 線性流程：Sequential • 在確認完成前一階段的工作完成後，再進行下一階段。一旦進入下一階段之後，就很難回頭。 • 工作階段的定義明確而嚴謹，必須遵守流程的規範進行，不允許跳躍或更改其中的步驟。 • 各個開發階段，如需求分析、系統設計等，係跟隨著步驟依序進行。

13. 軟體流程的類型(3/9) • 多循環流程：Iterative • 不要求完成一個階段之後，才能進入下一個階段；所有的階段都可以被重新進入。 • 流程的核心思想，是要將有缺陷（或瑕疵）的問題在可能導致災害之前，提早揭露出來。 • 對於工作的安排須詳細定義，依循指導原則與規範 • 多循環流程的缺點是可能會被誤用，變成「寫了再改」，或者沒有確定的目標，隨性地修改。更嚴重的是，專案的進展不易管控，因為流程可以被不斷地反覆進行，以致很難預期專案何時能夠完成。

14. 軟體流程的類型(4/9) • 編碼與除錯：Code & Debug • 沒有明確的軟體流程 • 優點：不用花時間在專案規劃、文件製作、品質管理，以及標準化的實施上。 • 缺點：不能提供明確的開發程序、無法提供確切的品質及風險識別等。 • 使用時機：軟體開發屬於小型、團隊人數少的專案，或者生命週期短的示範性程式或拋棄式雛型。

15. 軟體流程的類型(5/9) • 正規模式：Formal Methods • 利用數學符號系統來表達軟體的需求、規格及設計。 • 優點是嚴謹、精確，在表達上不會有含混或模糊的空間，而且利用數學，可以提供必要的驗證方法，找出各種潛在的錯誤或瑕疵。 • 缺點是成本太高，不易實施。 • B-Method, Petri nets, RAISE, VDM

16. 軟體流程的類型(6/9) • 再用導向開發：Reuse • 以再用其它的軟體元件為開發重心，其模式近似於演化式開發。 • 元件分析：找出既有、可用的元件 • 需求修正：根據新的需求修改元件規格或需求功能 • 系統設計與再用：設計新的架構或利用既有的 • 開發與整合：加入新元件並整合到現有的架構中 • 優點是快速且有效地開發流程，可降低成本與風險。 • 限制是系統可能沒有真正滿足用戶需求、對於繼承下來的元件缺乏控制等，導致日後產生維護上的困擾。

17. 軟體流程的類型(7/9) • 前段：需求、分析、設計 • 後段：程式建構、測試 • 依「流程工作之負載」分類 • 前負載型流程： • 流程的規劃與重心，主要放在軟體開發的前段，包含專案的計劃與目標的設定等。 • 事前多一分規劃可以省下事後更多的溝通與挫折。 • 陷阱：無用的分析。在專案早期分析不明確的事項，浪費時間，獲得無用甚至有害的資訊。

18. 軟體流程的類型(8/9) • 後負載型流程： • 主要是把軟體開發大部分的工作放在程式的建構與測試；在軟體建構的過程中，才深入進行需求分析與系統設計。 • 好處：避免無用的分析，提早交付系統早期的版本，讓用戶看到可以觸摸的結果； • 潛在的缺點則包括：缺乏長期規劃、專案時程無法掌握、系統架構不良及程式碼混亂等。

19. 軟體流程的類型(9/9) • 平衡型流程： • 嘗試將投入軟體開發的人力，平均分配在專案的前段與後段的一種流程。 • 前面盡量想清楚，但是儘快著手行動 • 平衡型流程可以滿足計畫型的管理者，先做一些基本規劃、分析或甚至設計，然後才進行建構程式；缺點則是可能兩方都不討好，結果變成什麼都不是。

20. 線性流程模型(1/7) • 原始瀑布模型（waterfall model） • 讓各個開發階段依序進行，一步一步往下一階段走。 • 每一階段都有清楚的定義，階段間的進行只有一個方向，後者承接前一階段的工作結果，中間只有極少的反饋或交互作用。（如圖7.2所示） • 優點：有助於專案的計劃與文件的製作。 • 缺點： • 回應給用戶的產出時間過長。 • 易導致過早確認還不成熟的需求。 • 進行過程中不能遺忘任何重要事項。 • 流程不夠彈性，很難回頭修改錯誤。 • 文件修改是一件龐大工程。 • 又稱為：文件導向流程

21. 導入及上線測試 圖7.2 最原始未修正過的瀑布模型圖

22. 線性流程模型(2/7) • 瀑布模型的改良 • 瀑布模型大部分的缺點，並非來自於其所定義的活動，而在於將這些活動以非重疊及循序的方式進行；所以改良的方向主要在於如何突破這些限制，思考的方向包括： • 允許流程逆行。 • 讓各階段有重疊性。 • 縮短一個「來回的時間」（turn around time）。 • 縮小專案規模。 • 進行先導作業。

23. 線性流程模型(3/7) • 鮭魚模型 • 以鮭魚來形容瀑布流程可以逆流而上。 • 多數的瀑布模型允許流程在某種情況下，可以回到上一個階段，不過在執行上，各有不同程度的限制。 • 生魚片模型 • 其特色是允許兩個相鄰階段可有較大程度的重疊，藉著後一階段的提早進行，提供有用的回饋資訊給前面階段，以減少誤解或錯誤的發生（如圖7.3）。 • 採用此一模型時，應避免里程碑的混淆、假設不當、無效率，以及溝通不良等情況，並清楚掌控真正的進度。

24. 需求定義及分析 系統分析及設計 建構及單元測試 整合及系統測試 導入及上線測試 圖7.3 生魚片模型

25. 線性流程模型(4/7) • 子專案式瀑布模型 • 完成系統的初步分析與架構設計後，嘗試將專案拆解成幾個子系統 • 視每一個子系統為獨立的專案以，縮短專案時程，及早獲得顧客或用戶的回饋（如圖7.4） • 風險：子專案間的相依性不易維護、關鍵人力資源的搶奪

26. 圖7.4 子專案式瀑布模型

27. 線性流程模型(5/7) • 降低風險的瀑布模型 • 在原有的流程之外，增加風險分析 • 在瀑布流程的頂端（或各階段之前）進行先導作業，排除定義不清的風險。 • 期望藉由先導作業的投入，提早發現問題並予以克服，以避免後續各階段可能發生問題，並提高流程的順暢性（如圖7.5）。 • 主要缺點是增加流程的複雜性與專案的成本。

28. 導入及上線測試 圖7.5 降低風險之瀑布模型

29. 線性流程模型(6/7) • 階段交付模型（staged delivery） • 前半段是瀑布模型，後半段類似漸進式雛型開發 • 當架構設計完成後，以階段性交付的方式，提早將有用的功能交給顧客，而非等到系統全部完成後，才一次交付。 • 好處：能夠提早將可用的功能交由顧客確認，以獲得必要的回饋，降低專案的風險，同時又可以呈現明確的專案進展情況。 • 缺點：倘若缺乏管理與技術層面良好的規劃，可能系統開發至最後，卻發現有些東西設計錯誤，或者漏掉了某些重要的東西，導致專案進展受阻。 • 如圖7.6所示。

30. 圖7.6 階段交付模型

31. 線性流程模型(7/7) • 依時程設計（design-to-schedule） • 類似分段交付模型。將高優先項目的功能納入早期完成，低優先項目留到最後面處理。 • 確保在特定的時間內，一定有成品可以呈現，使得工作變得較有彈性，減輕了專案時程不必要的壓力，或事前必須預估專案能否在最後期限內完成。 • 專案團隊能集中注意力在重要的工作項目上，避免無謂的風險，浪費時間在不值得或不確定的工作項目上。 • 缺點：假若沒有全部完成所規劃的項目，會浪費一些時間在無法交付的規格說明、架構或功能設計上。 • 如圖7.7所示。

32. 圖7.7 依時程設計之流程模型

33. 多循環流程模型(1/5) • 漸進式開發（incremental development） • 將軟體規劃成若干個段落，逐次進行開發。 • 藉由前面的產出來修正後面的設計，以降低專案風險，同時使專案的進展更具體且容易驗證。 • 優點：不用在專案初期做太多不切實際的假設，使得較大的專案有能力在進行中改變開發方向。 • 雛型法（prototyping） • 能夠讓系統開發在初期階段，就有具象的系統功能外觀在使用者面前展現，使得需求分析或系統功能規格能有直接、具體的討論（如圖7.8所示）。

34. 圖7.8 演進式雛型之流程

35. 多循環流程模型(2/5) • 拋棄式雛型（throwable prototyping） • 在建構時應儘量求其簡化，不花太多時間，其目的在於展示而非實用，所以此一雛型基本上是一個「應急」（quick-and-dirty）的產物，用後即丟棄。 • 演進式雛型（evolutionary prototyping） • 妥善規劃，以雛型為基礎，不斷地擴展，直到發展成最後的產品。 • 製作多個雛型與顧客討論，當顧客確認後，再進一步製作另一個更完整的雛型。 • 提早進行軟體開發，早期獲得用戶的回饋； • 透明化的專案進度，讓專案不易偏離目標。 • 缺點：若無真正的需求分析與系統設計，很可能導致系統架構的混亂，變成「編碼與除錯」的模式。

36. 多循環流程模型(3/5) • 演進式交付（evolutionary delivery） • 以產品版本來定義循環的終了（或里程碑），基於顧客的回應改善軟體。 • 兼具漸增式開發和階段性交付的流程特性。 • 先開發出一個粗略的產品版本，呈現給顧客看，並根據顧客的回應，確認後續尚未進行的工作。 • 如圖7.9所示。 • 80/20法則： • 滿足客戶80%的需求只需要20%的開發時間 • 儘快交付產品給客戶確認

37. 圖7.9 演進式交付之流程

38. 多循環流程模型(4/5) • 螺旋模型（spiral model） • 如同螺旋狀般的流程，一次一次地迴轉直到專案結束為止 • 解決軟體開發時所可能遭遇的風險，利用每一次的迴轉將風險一一排除。 • 螺旋模型的每一個循環，各有六個步驟： • 決定目標、可選擇的方案及其限制。 • 辨認並化解風險。 • 評估可選擇的方案。 • 發展該循環的產出並驗證它們。 • 計劃下一個循環。 • 確定下一個循環所使用的模型。

39. 多循環流程模型(5/5) • 好處：專案投入的資源愈多，所承擔的風險就愈低。 • 缺點：複雜性，專案目標與可驗證的里程碑不易定義，專案時程也不容易預測。 • 使用此一模型的時機是，需求不確定或目標不清，以及風險較高的專案。

40. 新式軟體流程(1/18) 新式軟體流程最大的特點，在於將軟體流程從一維空間擴展成二維，並各自賦予不同的任務。 二維軟體流程將傳統的「階段」以「工作流」取代，而另外增加一維管理用的階段；前者用來處理需要銜接與連續性的工作，而後者則分配給需要計劃與管控的工作。 二維流程模型類似一個演化樹，縱向由上往下展開的是軟體流程「循環」，目的是解決軟體開發上的問題；而橫向水平呈現的則是軟體的各個階段，用以表示專案的進展，如圖7.10所示。

41. 圖7.10 二維流程模型展開圖

42. 新式軟體流程(2/18) • 二維流程模型具有以下優點： • 提供一個架構，將專案管理與工程技術分開，互不干擾。 • 將經過實踐驗證的軟體開發方法—漸進（incremental）與循環，整合在一個架構中。 • 可處理開發過程中，不可避免的專案變更，例如，「射擊飛靶」的問題。 • 適用於各種規模的系統，大型系統可分解成子系統開發。 • 即使是小系統，亦可進一步分解成模組，徹底瞭解之後再進行開發。

43. 新式軟體流程(3/18) • RUP（Rational Unified Process） • RUP有幾項特色，其軟體開發是由「使用案例」所推動，透過一個一個的案例，逐步從構思、擴展到實作，逐項增加系統功能。過程中以瞭解並建立系統架構為核心，然後透過多循環、漸進式流程模型，逐漸擴展系統的規模，直到完成最後的產品。 • RUP流程的週期基本上是由「階段」與「循環」所組成。週期的產出是產品，一個新的、符合用戶需求的產品，如圖7.11所示。

44. 圖7.11 RUP流程模型

45. 新式軟體流程(4/18) • RUP週期可分成四個連續階段 • 構思階段(Inception) • 是專案的起始，主要目的是找出軟體的願景，澄清專案的工作目標、風險評估等。 • 其任務內容為： • 明確定義專案關係人同意的軟體系統範圍和邊界條件。 • 使用統一塑模語言（Unified Modeling Language, UML）描繪商業及系統的使用案例。 • 從重要的使用案例中，描繪出系統架構的輪廓。 • 找出重要的風險因子，並且確認在什麼樣的情況下會發生。 • 對專案進行粗略的成本和時程估算。 • 預備好專案的支援環境。

46. 新式軟體流程(5/18) • 本階段的產出及里程碑包括： • 專案願景文件（包含專案價值分析、主要關係人、關鍵需求、主要限制等）。 • 商業用語表（可能部分表達為商業模型）。 • 高階商用案例模型（完成10%～20%）。

47. 新式軟體流程(6/18) • 擴展階段(Elaboration) • 深入探討各種需求的定義，並設計出軟體系統的架構與物件模型。 • 其工作內容為： • 完成系統剩餘需求的蒐集。 • 定義整體系統的架構與物件模型。 • 處理專案中會遇到的重要風險。 • 完成系統在商業應用上的使用案例。 • 確保軟體之結構、需求、計畫已足夠穩定。 • 建立一個包含高品質元件的可演化產品原型。

48. 新式軟體流程(7/18) • 本階段的產出與里程碑包括： • 更完整的系統規格與架構模型。 • 更新過的使用案例（完成至少80%）——所有使用案例均已確認，且多數已被開發。 • 軟體體系結構描述——初步可執行的軟體原型。 • 經修訂過的風險清單和商業案例。 • 總體專案的開發計畫，包含略為粗糙的專案計畫，其中顯示循環和對應的審核標準。 • 用戶手冊的初始版本（可選）。

49. 新式軟體流程(8/18) • 建構階段(Construction) • 正式開始建造系統，將軟體雛型擴充成為正式系統，藉由雛型取得顧客對功能的確認，或者需求的變更。 • 根據使用案例的重要性，逐漸擴增系統的新功能；藉由每一次的新版本測試，顧客可以知道開發之系統，是否與其需求一致，或者有所出入並加以修正。 • 本階段的產出與里程碑包括： • 可以交付給最終用戶的初步產品。 • 用戶手冊。 • 當前版本的描述。

50. 新式軟體流程(9/18) • 轉移階段(Transition) • 審查以下兩件事情： • 產品是否已足夠穩定和成熟可發布給用戶？ • 專案團隊與用戶是否已經準備好接受移交？ • 如果這兩項答案都是肯定的，表示專案已進入最終完成階段，也就是可將產品逐步轉移交給用戶使用。 • 本階段的里程碑為： • 產品發布。 • 用戶是否滿意。 • 上線是否順利。