软体程序.pptVIP

軟體程序 一組緊密的活動集合，包括系統軟體的規格指定、設計、實作以及測試等。 本章目的 瞭解軟體開發程序模型 瞭解幾個不同的軟體程序模型與適用時機 概略的瞭解軟體需求工程、軟體開發、測試以及演進等程序模型 瞭解支援軟體程序的CASE 技術 本章內容 軟體程序模型 反覆式程序 軟體規格制定 軟體設計與實作 軟體確認 軟體演化 自動化程序支援 軟體程序 開發一個軟體系統需要下列這些結構化的活動 規格制定 設計 確認 演化 軟體程序模型是流程的抽象表示，它是以某些特殊的觀點來表示流程的描述 通用的軟體程序模型 瀑布式模型 規格制定和開發分屬不同的階段 演化式開發 規格制定與開發交錯進行 正規化系統開發 將數學式的系統模型正規的轉換成實作 再利用式開發 以現有的元件組合成系統 瀑布式模型 瀑布式模型各階段 需求分析與定義 系統與軟體設計 實作與單元測試 整合與系統測試 運作與維護 瀑布式模型的缺點是，在進行中的程序很難配合變更 瀑布式模型的問題 將專案分割成這些階段會讓整個專案不具彈性 如此不容易對顧客的需求變更做回應 因此，瀑布式模型最好只用在需求非常清楚的情況下 演化式開發(Evolutionary development) 探索式開發 (Exploratory development) 目的是與顧客合作，探究出顧客的需求，然後從最初始的慨略規格開發成最後系統。應該先從系統需求最清楚的部分開始進行 丟棄式雛形法(Throw-away prototyping) 目的是瞭解系統的定義，應該從不是很瞭解的部分開始進行 演化式開發 演化式開發 問題 缺乏流程的能見度，使得程序不是很清楚 系統的結構通常不會很好 需要特殊技能，例如快速雛形法的語言 應用 小型或中型的互動式系統 部分的大型系統，例如使用者介面部分 使用壽命短的系統 正規化系統開發 根據正規的數學式規格經過不同的表示式，轉換成可執行的程式 轉換過程中可以保留其正確性，所以可以很容易的證明程式是否符合它的規格 最有名的正規化開發程序是 「淨室法」(Cleanroom) 正規化系統開發 正規化轉換 正規化系統開發 問題 需要特殊的專門技能與訓練才能應用此技術 有些系統的特性很難以正規化的方式指定，例如使用者介面 應用 一些關鍵系統，尤其是系統在上線運作之前必須完成的安全與保全情況下 再利用式開發 有系統的再利用，以現有的元件或 COTS (Commercial-off-the-shelf) 系統來整合成完整的系統 程序階段 元件分析 需求修改 再利用式的系統設計 開發與整合 這個方法愈來愈重要，但是實際的經驗仍然有限 再利用式開發 反覆式程序 在專案的過程中，系統需求「永遠」需要演進，所以在大型系統的開發流程中，早期階段的程序可能需要重做多次 反覆式程序也可以應用到任何通用的程序模型 有兩個相關的方法 增量式開發 (Incremental development) 螺旋式開發 (Spiral development) 增量式開發 系統不是一次完整的全部交付，而是將系統和交付成果分成不同的增量模組，每一個增量模組則完成某部分所需的功能 使用者需求必須經過優先順序的排列，有最高優先權的需求必須包含在較早期的增量模組中 某一個增量模組的開發一旦開始進行，該需求就應該被凍結，以便讓後續的增量模組可以繼續演化 增量式開發 增量式開發的優點 顧客不需要等到整個系統完成之後才開始使用 早期的增量模組可以當成雛形，以幫助取得後續增量模組的需求 整體專案的失敗率風險較低 優先權最高的系統服務可以被測試最多次 極限程式設計 (Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式 必須依賴不斷的程式碼改善、使用者的參與以及成對的程式設計方式 螺旋式開發 程序是以螺旋方式來表示，而非具回溯的一系列順序活動 螺旋中的每一個迴圈表示程序中的一個階段 它沒有固定的階段，例如規格制定或設計，螺旋中的迴圈是根據需求選取的 整個流程中的風險可以明確的被評估及解決 軟體程序的螺旋式模型 螺旋式模型的區段 目標設定 定義此專案目前階段的特定目標 風險評估與降低風險 評估風險，並且在適當的地方加入活動以便降低風險 開發與確認 選用適當的開發模型，這個模型可以是任何通用的模型 規劃 審查此專案，並且決定是否繼續進行下一個螺旋迴圈 軟體規格制定 建立系統運作與開發時所需服務與限制的程序 需求工程程序 可行性研究 (Feasibility study) 需求提取與分析 (Requirements elicitation and analysis) 需求規格制定 (Requirements specification) 需求確認 (Requirements validation