第11章軟件質量管理與配置管理(編輯修改稿)
2025-01-27 16:59 本頁面
【文章內容簡介】 配置項的一個實例。有一個唯一的標示符（如名字 +版本號） 18 基線 開發(fā)各階段不能輕易改變的軟件版本（底線）。基線是受控的，即構成系統(tǒng)的軟件版本是不能輕易改變的。 基線作用用于控制變更，禁止開發(fā)人員隨便修改一個 “已凍結 ”的工作成果。 代碼線 軟件組件以及組件所依賴的其它配置項的集合。 主線 系統(tǒng)不同版本的基線的序列。 工作空間 一個私有的工作空間中，對軟件的修改不會影響其他開發(fā)者對該軟件的使用。 分支 從現存的代碼線版本中創(chuàng)建一個新的代碼線，新代碼線和已存在的代碼線可以并行開發(fā)。 合并 通過合并在不同代碼線中的單獨版本來創(chuàng)建軟件的新版本。這些代碼線可能由某個代碼線先前存在的分支所創(chuàng)建。 系統(tǒng)構建 通過鏈接組件和庫中適當版本創(chuàng)建一個可執(zhí)行的系統(tǒng)版本。 IEEE對 基線的定義 ： 已經通過正式評審和批準的規(guī)約或產品，可以作為進一步開發(fā)的基礎，并且只能通過正式的變更控制規(guī)程才能改變它。 19 SCI SCI SCI SCI SCI 配置項庫 基線： 軟件需求規(guī)約軟件設計規(guī)約源代碼 測試規(guī)程 /用例 可運行的系統(tǒng) 存儲 提取 軟件工程任務 修改 正式技術評審 批準 SCM控制 基線化的 SCI和項目數據庫（參考教材 1） 20 A B C L1 L2 EX1 EX2 代碼線（ A） 代碼線（ B） 代碼線（ C） 庫和外部組件 A L1 L2 EX1 基線 V1 L1 L2 EX1 基線 V2 代碼線、基線、主線 主線（基線的序列） 21 變更管理 ? 變更管理的任務 ? 分析變更請求：研究變更的必要性、經濟可行性（成本－效益比，是否合理）和技術可行性。 ? 記錄和追蹤變更、評估變更的影響。 ? 采取措施保證變更在受控狀態(tài)下進行。 ? 變更管理過程 見下圖： 22 變更管理過程（參考教材 1） 23 ? 變更管理過程從分析變更請求開始，處于開發(fā)狀態(tài)的配置項 尚未穩(wěn)定下來，不受 SCM的控制，對配置項的變更不受限制。 ? 當開發(fā)人員認為工作已告完成，可供其他配置項使用時，配置項進入評審狀態(tài)，若通過評審就作為基線允許進入配置項數據庫（ checkin)， 配置項 處于受控狀態(tài)，開發(fā)人員不允許隨便對其做任何修改 。 ? 配置項的狀態(tài)變化見下圖。 對配置項的變更控制 24 兩個主要的變更控制因素： ? 訪問控制 ：管理哪個程序員有權訪問和修改 SCI。 ? 同步控制 ：保證兩個不同人員完成的并行變更不會相互覆蓋。 訪問控制與同步控制流程如下圖所示： 配置項的狀態(tài)變化 評審狀態(tài) 受控狀態(tài) 工作狀態(tài) 開發(fā)人員滿意 通過評審check in 未通過評審 check out 25 配置對象的同步存取控制流程 加鎖 ： 使得當前被提取的版本在放回之前別人不能對它 作任何修改（同步控制）。 解鎖 ：在經過 SQA和測試后，提交修改后的版本（新的 基線對象）并被解鎖。 （該變更管理的模式為 LockModifyUnlock 模式） 26 . 版本管理 ? 版本管理是跟蹤軟件組件或配置信息由于變更而產生的不同版本的過程。 ? 一個系統(tǒng)版本就是一個系統(tǒng)的具體實例。版本有內部版本和發(fā)布版本。一個系統(tǒng)的內部版本要比發(fā)布版本多得多。系統(tǒng)的內部版本是為內部開發(fā)或測試而創(chuàng)建，內部版本趨于穩(wěn)定后，才決定產生發(fā)布版本。 ? 版本管理也包括確保由不同開發(fā)者做出的變更不會彼此影響，因此也看做是管理 代碼線 和 基線 的過程。 27 ? 基線很重要，開發(fā)者常常不得不重建一個完整系統(tǒng)的特定版本。如，一個產品線需要實例化為不同客戶產生不同的個人系統(tǒng)版本。假如客戶報告了系統(tǒng)中的錯誤，開發(fā)者不得不重建這個版本。 ? 為了支持版本管理，使用版
物理相關推薦
鄂ICP備17016276號-1