软体开发流程

《软体开发流程》由会员分享，可在线阅读，更多相关《软体开发流程（69页珍藏版）》请在金锄头文库上搜索。

1、第7章 軟體開發流程 本章大綱7.1 何謂軟體流程？7.2 軟體流程的類型 7.3 線性流程模型 7.4 多循環流程模型 7.5 新式軟體流程7.6 如何選擇軟體流程7.7 結語 學習目標瞭解何謂軟體流程瞭解各種軟體流程的類型瞭解何謂新式的軟體流程瞭解如何選擇軟體流程何謂軟體流程？(1/6)所謂流程（process），從字面上來看，是指一系 列的步驟，其中包含：活動、限制、使用的資源， 以及期望產出的描述。根據Humphrey與Feiler的說法：軟體流程是一組 部分相依、為達到目標而執行的一系列步驟。至於軟體流程的內容，則包含了定義、分析、設計 、建構及測試等活動。除了步驟之外，軟體流程還應

2、該包括各個活動的說 明：由誰 執行、何時做、做什麼與如何做，以及 預定產出之文件（或編碼）、使用的電腦資源與組 織結構（或限制）等。何謂軟體流程？(2/6)軟體流程相關術語人員（worker）：定義個別成員或一群人組成 的團隊之角色與責任。任務（activity）：流程裡由人員所執行之活動 單元。產物（artifact）：由流程所產生、修改及使用 的資訊，以程式碼或文件的形式表示。開發週期（cycle）：開發週期就是軟體專案所 涵蓋的範圍，其產出即是產品；通常一個週期 推出一個新的、符合用戶需求的產品。何謂軟體流程？(3/6)階段（phase）：將開發週期進一步地切割，可分 成幾個階段；每個階

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

4、示法，係 從一般性的角度來描述如何組織專案的活動。流程模型可以分成兩種敘述型（descriptive）：提供一些流程設計的原則 與指引，目的在於協助思考，幫助專案經理與團隊 ，決定哪些工作需要完成、以怎樣的順序進行。規範型（prescriptive）：必須照表操課；流程 與流程模型的關係，就好像物件與類別間的關係， 完全繼承模型的所有規範。何謂軟體流程？(5/6)軟體流程的設計考量各階段的活動該如何安排與劃分？流程中的活動往往彼此重疊，甚至交互影響很 難切割。這些要如何解決？如何確保（或知道）每一階段的活動都正確達 成目標？流程的透明度如何？專案管理部分要如何處理 ？何謂軟體流程？(6/6)軟

5、體流程在開發上所扮演的角色軟體流程是軟體開發的方法或步驟，幾乎所有 軟體工程的活動都與流程有關，但這也是最分 歧、最麻煩的部分。選用適當的軟體流程可帶來許多優點，例如： 提高軟體開發速度、改善軟體品質、改善專案 的追蹤與控管、降低風險暴露，以及改善與顧 客間的關係等。選用錯誤的流程，則會減緩開發速度、產生不 必要的問題，以及遭遇到挫折。軟體流程的類型(1/9)依流程步驟之順序 分類線性流程多循環流程編碼與除錯正規模式再用導向開發依流程工作之負載 分類前負載型流程後負載型流程平衡型流程軟體流程的類型(2/9)依流程步驟之順序分類線性流程：Sequential在確認完成前一階段的工作完成後，再進行

6、下一階 段。一旦進入下一階段之後，就很難回頭。工作階段的定義明確而嚴謹，必須遵守流程的規範 進行，不允許跳躍或更改其中的步驟。各個開發階段，如需求分析、系統設計等，係跟隨 著步驟依序進行。軟體流程的類型(3/9)多循環流程：Iterative不要求完成一個階段之後，才能進入下一個階段； 所有的階段都可以被重新進入。流程的核心思想，是要將有缺陷（或瑕疵）的問題 在可能導致災害之前，提早揭露出來。對於工作的安排須詳細定義，依循指導原則與規範多循環流程的缺點是可能會被誤用，變成寫了再 改，或者沒有確定的目標，隨性地修改。更嚴重 的是，專案的進展不易管控，因為流程可以被不斷 地反覆進行，以致很難預期專

7、案何時能夠完成。軟體流程的類型(4/9)編碼與除錯：Code & Debug沒有明確的軟體流程優點：不用花時間在專案規劃、文件製作、品質管 理，以及標準化的實施上。缺點：不能提供明確的開發程序、無法提供確切的 品質及風險識別等。使用時機：軟體開發屬於小型、團隊人數少的專案 ，或者生命週期短的示範性程式或拋棄式雛型。軟體流程的類型(5/9)正規模式：Formal Methods利用數學符號系統來表達軟體的需求、規格及設計 。優點是嚴謹、精確，在表達上不會有含混或模糊的 空間，而且利用數學，可以提供必要的驗證方法， 找出各種潛在的錯誤或瑕疵。缺點是成本太高，不易實施。B-Method, Petri

8、 nets, RAISE, VDM軟體流程的類型(6/9)再用導向開發：Reuse以再用其它的軟體元件為開發重心，其模式近似於 演化式開發。元件分析：找出既有、可用的元件需求修正：根據新的需求修改元件規格或需求功能系統設計與再用：設計新的架構或利用既有的開發與整合：加入新元件並整合到現有的架構中優點是快速且有效地開發流程，可降低成本與風險 。限制是系統可能沒有真正滿足用戶需求、對於繼承 下來的元件缺乏控制等，導致日後產生維護上的困 擾。軟體流程的類型(7/9)前段：需求、分析、設計後段：程式建構、測試依流程工作之負載分類前負載型流程：流程的規劃與重心，主要放在軟體開發的前段，包 含專案的計劃與

9、目標的設定等。事前多一分規劃可以省下事後更多的溝通與挫折。陷阱：無用的分析。在專案早期分析不明確的事項 ，浪費時間，獲得無用甚至有害的資訊。軟體流程的類型(8/9)後負載型流程：主要是把軟體開發大部分的工作放在程式的建構與 測試；在軟體建構的過程中，才深入進行需求分析 與系統設計。好處：避免無用的分析，提早交付系統早期的版本 ，讓用戶看到可以觸摸的結果；潛在的缺點則包括：缺乏長期規劃、專案時程無法 掌握、系統架構不良及程式碼混亂等。軟體流程的類型(9/9)平衡型流程：嘗試將投入軟體開發的人力，平均分配在專案的前 段與後段的一種流程。前面盡量想清楚，但是儘快著手行動平衡型流程可以滿足計畫型的管理

10、者，先做一些基 本規劃、分析或甚至設計，然後才進行建構程式； 缺點則是可能兩方都不討好，結果變成什麼都不是 。線性流程模型(1/7)原始瀑布模型（waterfall model）讓各個開發階段依序進行，一步一步往下一階段走。每一階段都有清楚的定義，階段間的進行只有一個方 向，後者承接前一階段的工作結果，中間只有極少的 反饋或交互作用。（如圖7.2所示）優點：有助於專案的計劃與文件的製作。缺點：回應給用戶的產出時間過長。易導致過早確認還不成熟的需求。進行過程中不能遺忘任何重要事項。流程不夠彈性，很難回頭修改錯誤。文件修改是一件龐大工程。又稱為：文件導向流程圖7.2 最原始未修正過的瀑布模型圖導入

11、及上線測試線性流程模型(2/7)瀑布模型的改良瀑布模型大部分的缺點，並非來自於其所定義 的活動，而在於將這些活動以非重疊及循序的 方式進行；所以改良的方向主要在於如何突破 這些限制，思考的方向包括：允許流程逆行。讓各階段有重疊性。縮短一個來回的時間（turn around time）。縮小專案規模。進行先導作業。線性流程模型(3/7)鮭魚模型以鮭魚來形容瀑布流程可以逆流而上。多數的瀑布模型允許流程在某種情況下，可以回到 上一個階段，不過在執行上，各有不同程度的限制 。生魚片模型其特色是允許兩個相鄰階段可有較大程度的重疊， 藉著後一階段的提早進行，提供有用的回饋資訊給 前面階段，以減少誤解或錯誤

12、的發生（如圖7.3） 。採用此一模型時，應避免里程碑的混淆、假設不當 、無效率，以及溝通不良等情況，並清楚掌控真正 的進度。圖7.3 生魚片模型需求定義及分析系統分析及設計建構及單元測試整合及系統測試導入及上線測試線性流程模型(4/7)子專案式瀑布模型完成系統的初步分析與架構設計後，嘗試將專 案拆解成幾個子系統視每一個子系統為獨立的專案以，縮短專案時 程，及早獲得顧客或用戶的回饋（如圖7.4）風險：子專案間的相依性不易維護、關鍵人力 資源的搶奪圖7.4 子專案式瀑布模型線性流程模型(5/7)降低風險的瀑布模型在原有的流程之外，增加風險分析在瀑布流程的頂端（或各階段之前）進行先導 作業，排除定義

13、不清的風險。期望藉由先導作業的投入，提早發現問題並予 以克服，以避免後續各階段可能發生問題，並 提高流程的順暢性（如圖7.5）。主要缺點是增加流程的複雜性與專案的成本。圖7.5 降低風險之瀑布模型導入及上線 測試線性流程模型(6/7)階段交付模型（staged delivery）前半段是瀑布模型，後半段類似漸進式雛型開發當架構設計完成後，以階段性交付的方式，提早將 有用的功能交給顧客，而非等到系統全部完成後， 才一次交付。好處：能夠提早將可用的功能交由顧客確認，以獲 得必要的回饋，降低專案的風險，同時又可以呈現 明確的專案進展情況。缺點：倘若缺乏管理與技術層面良好的規劃，可能 系統開發至最後，

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

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

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