軟體程序.pptVIP

軟體開發程序 蔡進義 Chin-Yi Tsai (Matt) cyt@.tw 5/~cyt Review複習 系統是由一群相關的組成元件集合而成的，為了達成某個抽象目的而共同運作。 Review複習 突顯性質不是系統中某個組成元件的特性，而是當系統以整體來考量時所出現的性質。 系統的整體價值 這個性質可以從個別組成元件的性質計算而來 系統的可靠性 這個性質必須根據系統組成元件的可靠性以及各元件之間的關係而定 系統的可使用性 這是一個非常複雜的性質，它不是直接從系統的軟硬體而來，而是根據系統的操作人員和使用環境而定 Review複習 系統可靠度 硬體可靠度 指硬體元件發生故障的可能機率，以及修護該元件所需的時間 軟體可靠度 指軟體元件產生錯誤結果的可能性。軟體故障通常不同於硬體的故障，因為軟體不會被用壞 作業員可靠度 指系統操作人員造成失誤的可能性 Review複習 系統與環境 Review複習 建立系統架構模型 架構模型可以表示組成系統的各個子系統的抽象檢視 模型中可以包含子系統之間的主要資訊流 模型通常是以方塊圖來表示 可以分辨出模型中不同類型的功能元件 Review複習 侵入者警報系統 Review複習 系統工程程序 Review複習 不同學科領域的參與 本章目的 瞭解軟體開發程序模型 瞭解幾個不同的軟體程序模型與適用時機 概略的瞭解軟體需求工程、軟體開發、測試以及演進等程序模型 瞭解支援軟體程序的CASE 技術 Outline 軟體程序模型 反複式程序 軟體規格制定 軟體設計與實作 軟體確認 軟體演化 自動化程序支援 軟體程序 軟體程序模型 軟體程序 開發一個軟體系統需要下列這些結構化的活動 規格制定 設計 確認 演化 軟體程序模型是流程的抽象表示，它是以某些特殊的觀點來表示流程的描述 通用的軟體程序模型 瀑布式模型 規格制定和開發分屬不同的階段 演化式開發 規格制定與開發交錯進行 正規化系統開發 將數學式的系統模型正規的轉換成實作 再利用式開發 以現有的元件組合成系統 瀑布式模型 瀑布式模型的問題 將專案分割成這些階段會讓整個專案不具彈性 如此不容易對顧客的需求變更做回應 因此，瀑布式模型最好只用在需求非常清楚的情況下 演化式開發(Evolutionary development) 探索式開發 (Exploratory development) 目的是與顧客合作，探究出顧客的需求，然後從最初始的慨略規格開發成最後系統。應該先從系統需求最清楚的部分開始進行 丟棄式雛形法(Throw-away prototyping) 目的是瞭解系統的定義，應該從不是很瞭解的部分開始進行 演化式開發 演化式開發 問題 缺乏流程的能見度，使得程序不是很清楚 系統的結構通常不會很好 需要特殊技能，例如快速雛形法的語言 應用 小型或中型的互動式系統 部分的大型系統，例如使用者介面部分 使用壽命短的系統 正規化系統開發 根據正規的數學式規格經過不同的表示式，轉換成可執行的程式 轉換過程中可以保留其正確性，所以可以很容易的證明程式是否符合它的規格 最有名的正規化開發程序是 「淨室法」(Cleanroom) 正規化轉換 正規化系統開發 問題 需要特殊的專門技能與訓練才能應用此技術 有些系統的特性很難以正規化的方式指定，例如使用者介面 應用 一些關鍵系統，尤其是系統在上線運作之前必須完成的安全與保全情況 再利用式開發 有系統的再利用，以現有的元件或 COTS (Commercial-off-the-shelf) 系統來整合成完整的系統 程序階段 元件分析 需求修改 再利用式的系統設計 開發與整合 這個方法愈來愈重要，但是實際的經驗仍然有限 反複式程序 在專案的過程中，系統需求「永遠」需要演進，所以在大型系統的開發流程中，早期階段的程序可能需要重做多次 反複式程序也可以應用到任何通用的程序模型 有兩個相關的方法 增量式開發 (Incremental development) 螺旋式開發 (Spiral development) 增量式開發 系統不是一次完整的全部交付，而是將系統和交付成果分成不同的增量模組，每一個增量模組則完成某部分所需的功能 使用者需求必須經過優先順序的排列，有最高優先權的需求必須包含在較早期的增量模組中 某一個增量模組的開發一旦開始進行，該需求就應該被凍結，以便讓後續的增量模組可以繼續演化 增量式開發的優點 顧客不需要等到整個系統完成之後才開始使用 早期的增量模組可以當成雛形，以幫助取得後續增量模組的需求 整體專案的失敗率風險較低 優先權最高的系統服務可以被測試最多次 極限程式設計(Extreme progra