软体工程.ppt

軟體開發流程 軟體流程 軟體流程定義：是一組部份相依、為達到目標而執行的一系列步驟。 軟體流程步驟：包含軟體定義、分析、設計、建構及測試等活動。 流程也應包含各個活動的說明：由誰執行、何時做、做什麼、如何做、預定產出之文件﹝或編碼﹞、使用的電腦資源與組織結構﹝或限制﹞ 軟體流程基本元件 靜態： 1.人員 2.任務 3.產物 4.工作流 動態： 1.開發週期 2.階段 3.循環 軟體流程的分解與透視 軟體流程模型 敘述型：提供一些流程設計的原則與指引，目的在於協助思考，以幫助專案經理與團隊，決定哪些工作需要完成、以怎樣的順序進行 規範型：類似於食譜，必須「照表操課」；流程與流程模型的關係，就好像物件與類別間的關係，完全繼承模型的所有規範。 軟體流程的設計考量 各階段的活動該如何安排與劃分？ 流程中的活動往往彼此重疊，甚至交互影響很難切割。這些要如何解決？ 如何確保（或知道）每一階段的活動都正確達成目標？ 流程的透明度如何？專案管理部分要如何處理？ 軟體流程類型 依流程步驟之順序分類 1.編碼與除錯 2.正規模式 3.再用導向開發 4.線性流程 5.多循環流程 依流程步驟之負載分類 1.前負載型 2.後負載型 3.平衡型 編碼與除錯 優點：不用花時間在專案規劃、文件製作、品質管理，以及標準化的實施上，任何曾經撰寫過程式者都會使用。 缺點：無法提供明確的開發程序、無法提供確切的品質及風險識別。 使用時機：軟體開發屬於小型、團隊人數少的專案，或者生命週期短的示範性程式或拋棄式雛型。 正規模式 利用數學符號系統來表達軟體的需求、規格及設計。 優點：嚴謹、精確，在表達上不會有含混或模糊的空間，且利用數學可以提供必要的驗證方法，找出各種潛在的錯誤或瑕疵。 缺點：成本太高，不易實施。 再用導向開發 以再用其它的軟體元件為開發重心，其模式近似於演化式開發。﹝元件分析、需求修正、系統設計與再用、開發與整合﹞ 優點：快速且有效地開發流程，可降低成本與風險。 缺點：系統可能沒有真正滿足用戶需求、對於繼承下來的元件缺乏控制等，導致日後產生維護上的困擾。 線性流程 在確認完成前一階段工作後，再進行下一個步驟。 工作階段的定義明確而嚴謹，必須遵守流程的規範進行，不允許跳躍或更改其中的步驟 線性流程 原始瀑布模型 瀑布模型的改良 鮭魚模型 生魚片模型 子專案式瀑布模型 降低風險之瀑布模型 階段交付模型 依時程設計 最原始未修正過的瀑布模型圖 線性流程—原始瀑布模型 使用時機：專案有穩定的產品定義，以及熟悉的技術方法。 優點：有助於專案的計劃與文件的製作。 缺點：1.回應給用戶的產出時間過長。 2.易導致過早確認還不成熟的需求。 3.過程中不能遺忘任何重要事項。 4.流程不夠彈性，很難回頭修改錯誤。 5.文件修改是一件龐大工程。 線性流程—瀑布模型的改良 瀑布模型大部分的缺點，並非來自於其所定義的活動，而在於將這些活動以非重疊及循序的方式進行。 改良的方向主要在於如何突破這些限制，思考的方向包括： 1.允許流程逆行。 2.讓各階段有重疊性。 3.縮短一個「來回的時間」 （turn around time） 4.縮小專案規模。 5.進行先導作業。 線性流程—鮭魚模型 以鮭魚來形容瀑布流程可以逆流而上。 多數的瀑布模型允許流程在某種情況下，可以回到上一個階段，不過在執行上，各有不同程度的限制。 生魚片模型 線性流程—生魚片模型 使用時機：與瀑布模型相同，適用於定義明確或功能較少，且必須循序進行的軟體開發專案。 缺點：里程碑的混淆、假設不當、無效率，以及溝通不良等。 子專案式瀑布模型 線性流程—子專案式瀑布模式 使用時機：當系統的上層結構被模組化，可以拆成幾個彼此相互獨立的系統。 缺點：可能因關鍵人力資源的共用，造成專案彼此之間相互等待。﹝子專案間有相依性﹞ 降低風險之瀑布模型 線性流程—降低風險之瀑布模型 缺點：是增加流程的複雜性與專案的成本。 階段交付模型 線性流程—階段交付模型 優點：能夠提早將可使用的功能交由顧客確認，以獲得必要的回饋，降低專案的風險，同時又可以呈現明確的專案進展情況。 缺點：倘若缺乏管理與技術層面良好的規劃，可能系統開發至最後，卻發現有些東西設計錯誤，或者漏掉了某些重要的東西，導致專案進展受阻。 依時程設計之流程模型 線性流程—依時程設計 優點：使專案團隊能集中注意力在重要的工作項目上，避免了無謂的風險，浪費時間在不值得或不確定的工作項目上。 缺點：假若沒有全部完成所規劃的項目，將會浪費一些時間在無法交付的規格說明、架構或功能設計上。 多循環流程 不要求完