第二十九章.pptVIP

組態管理 管理系統產品的改變 本章目的 瞭解軟體組態管理的重要性 (CM) 說明四種組態管理活動：組態管理規劃、變更管理、版本與發行管理以及系統的建置 瞭解CASE工具如何用在組態管理支援組態管理流程 本章內容 組態管理規劃 變更管理 版本和發行管理 系統建置 組態管理的CASE工具 組態管理 軟體系統當被創造就代表版本的變更 不同的機器/OS 提供不同的機能 依使用者量身定做的系統 組態管理是有關於軟體發展的系統 系統改變是一個小組活動 CM並控制成本並且將其變成為一個系統 組態管理 專精於發展和應用流程和標準都是用來管理一個發展軟體產品 有時被視為較廣泛的軟體品質管理流程之一 組態管理小組負責軟體變更的控制。因為這些系統是管控演化的開始，所以受控制的系統也稱為基準(baseline) 系統家族 CM 標準 CM 要有一定的標準且符合組織的要求 定義出何種項目需要的標準，如何變更控制和如何做新版管理 外部的CM標準 (如 IEEE 標準中針對 CM的部份) 以瀑布式模型為基礎的軟體開發流程 - 新標準是為了演進發展 同時開發與測試 允許開發組織設定系統元件的遞交時間 新版的系統就是透過編譯與連結這些元件建構出完整的系統 系統會被交付給測試團隊，進行一些預先規定的系統測試 系統測試期間被發現的錯誤都必須記錄下來，並傳回給系統開發者 每日系統建置 有機會儘早發現由元件互動所產生的問題 鼓勵經由單元的測試 – 開發者怕開發失誤而造成整個系統發生故障 一個非常嚴格的變更管理流程來追蹤已經被發現及修復的問題 組態管理計畫 所有軟體流程產品都要被管理 規格 設計 程式 測試計畫 使用者手冊 數以萬計分開的文件產生一個大軟體系統 制定CM 計畫 開始專案之前 需定義文件及文件管理等級(正式文件) 文件應有系統維護、被定義和詳細的管理 CM 計畫 管理定義文件型態和文件命名計畫 定義CM責任和創造的基準 定義變更控制的政策和版本管理 定義 CM 記錄的維護 CM 計畫 描述用於組態管理的工具限制和使用 定義使用工具時所套用的流程 定義用來記錄組態資訊的組態管理資料庫 CM計畫中也會包含其他資訊，例如：外部供應商的軟體管理，以及CM流程，中的稽核程序 組態項目定義 開發大型軟體系統中，會有大量的文件產生，這些都是技術性的工作文件需要被定義 有些文件是用來維護軟體生命週期 文件的命名方式應與文件名稱有相關性 運用階層命名方法來達到最靈活的命名方式 組態階層 組態資料庫 所有組態管理的資訊維護都必需存於組態資料庫 能夠提供對系統組態各種查詢的答案 哪一個客戶已經取用某個系統版本的交付成果 ? 執行給定的系統版本需要什麼硬體和作業系統的組態 ? 變更元件 X有多少影響? 版本 T有多少錯誤回報? 組態管理資料庫應整合到軟體管理 組態資料庫的運作 組態資料庫應該和版本管理系統整合在一起，版本管理系統是用來儲存與管理正式的專案文件 透過一些整合式CASE工具的支持，可以將變更直接連結到受影響的文件和元件 組態資料庫放在獨立分開的系統內，而這個方法很便宜且具有彈性 變更管理 軟體系統經常會需要進行變更 從使用者 從開發者 從市場因素 變更管理能夠以合乎成本效益的方式記錄與應用 變更管理流程 變更要求 變更管理流程中的第一個階段是先完成變更要求單 記錄變更要求和建議變更理由(從請求變更的表單) 記錄變更的預估，分析，成本的變更和推薦 (系統維護員工) 變更要求 變更追蹤工具 變更管理最主要的問題在變更情況的追蹤 變更追蹤工具可以針對每一次情況變更時做自動的記錄 整合 E-mail 系統並允許電子交換來發行 變更管制委員會 從策略組織的角度而非技術上的觀點來考慮變更的影響 可以決定系統是否變更的小組。而這個小組有時叫變更管制委員會(change control board) 變更管制委員會組織應該包括資深的客戶與契約負責人員 衍生歷程 軟體元件變更後，必須維護對每一個元件所做的變更記錄 如記錄、外型、變更理由、誰變更和什麼時候執行 有時也包含了程式碼的註解。利用工具可以自動處理這個衍生歷程 元件標頭資訊 版本與發行管理 針對系統版本發展辨識方法 計畫什麼時候發行新版本 確認版本管理程序和工具的應用 計畫和配置新系統的發行 版本/差異/發行 版本 - 新版的系統可能有不同的功能、執行效能或錯誤的修正 特殊 - 版本可能功能相同，只是專為不同硬體或軟體組態做設計 發行 - 系統的版本通常會比發行多，因為版本是在內部開發或測試用的，不會發行給客戶使用 版本識別 版本識別程序可定義出清楚的元件版本方法 三種基本的元件識別技術 版本編號 屬性式識別 變更式識別 版本編號 簡單命名法如 V1, V1.1,