軟體配置管理的一些基本概念

2021-06-19 01:34:29 字數 3312 閱讀 6202

配置管理的定義

(1)是採用技術手段和行政手段進行管理和監督的一套規範化方法;

(2)對配置項的功能特性和物理特性加以標誌,並將其檔案化,並控制這些特性的變更;

(3)報告變更進行的情況、變更實施的狀態,以及驗證與規定要求的一致性。

配置管理的意義

配置管理能夠解決的問題:

1)多重維護問題:解決多個使用者對同一檔案進行修改所引起的版本不一致問題;

2)同時修改問題:解決多個使用者對同一檔案同時進行修改所引起的資源衝突問題;

3)丟失版本或不知版本問題:即要明確保留哪個版本,銷毀哪個版本。

配置管理的主要內容:

制定配置管理計畫、配置項識別、建立配置管理系統、基線化、建立配置庫、變更控制、配置狀態統計、配置審計

1、制定配置管理計畫

制訂配置管理計畫的主要步驟如下:

(1)建立並維護配置管理的組織方針

(2)確定配置管理需使用的資源

(3)分配責任

(4)培訓計畫

(5)確定「配置管理」的專案干係人,並確定其介入時機

(6)制訂識別配置項的準則

(7)制訂配置項管理表

(8)確定配置管理軟硬體資源

(9)制訂基線計畫

(10)制訂配置庫備份計畫

(11)制訂變更控制流程

(12)制訂審批計畫

2、配置識別和建立基線

配置識別:

確定需要納入配置管理的配置項

確定配置項的獲取時間和所有者

為識別的配置項分配唯一的標識

配置項:專案計畫書、需求文件、設計文件、源**、可執行**、測試用例

基線:指乙個配置項在其生存週期的某一特定時間,被正式標明、固定並經正式批准的

版本。可看做是乙個相對穩定的邏輯實體,其組成部分不能被任何人隨意修改

對於配置管理,有以下三種基線:分配基線(需求)、功能基線(設計)和產品基線(測試)。

分配基線(allocated baseline)

分配基線指在軟體需求分析階段結束時,經過正式評審和批准的軟體需求規格說明。分配基線是最初批准的分配配置標識。

功能基線(functional baseline)

功能基線指在系統分析與軟體定義階段結束時,在經過正式評審和批准的系統設計規格說明書中對開發系統的規格說明;或是指在經過專案委託單位和專案承辦單位雙方簽字同意的協議書或合同中,所規定的對開發軟體系統的規格說明;或是由下級申請並經上級同意或直接由上級下達的專案任務書中所規定的對開發軟體系統的規格說明。功能基線是最初批准的功能配置標識。

產品基線(product baseline)

產品基線指在軟體組裝與系統測試階段結束時,經過正式評審和批准的有關軟體產品的全部配置項的規格說明。產品基線是最初批准的產品配置標識。

3、建立配置管理系統(svn、vss、cvs、配置庫)

配置庫:記錄配置項有關的所有資訊,存放受控的配置項

動態庫、開發庫、程式設計師庫、工作庫 

受控庫、主庫、系統庫

靜態庫、軟體倉庫、軟體產品庫

備份庫建庫模式:按配置項型別分類建庫、按任務建庫

配置庫許可權的定義和設定

r(read)

c(check out/checkin)

a(add/rename/delete)

d(destory)

4、版本管理

配置項狀態:草稿、正式(評審後)、修改

配置項版本號規則

配置項的版本號與配置項的狀態緊密相關。

處於「草稿」狀態的配置項的版本號格式為:0.yz

隨著草稿的不斷完善,yz的取值應遞增。yz的初值和增幅由開發者自己把握。

處於「正式發布」狀態的配置項的版本號格式為:x.y

x為主版本號,取值範圍為1~9,y為此版本號,取值範圍為1~9

配置項第一次「正式發布」時,版本號為1.0

如果配置項的版本公升級幅度比較小,一般只增大y值,x值保持不變。只有當配置項版本公升級幅度比較大時,才允許增大x值

處於「正在修改」狀態的配置項的版本號格式為:x.y.z

配置項上在修改時,一般只增大z值,x.y值保持不變

當配置項修改完畢時,狀態重新成為「正式發布」時,將二值設定為0,增加x.y值

5、變更控制

變更申請:變更申請人

變更評估(ccb)

變更實施:cm工程師、變更實施人

變更驗證與確認(ccb)

變更的發布(配置管理員)

基線的變更 :基線以內的。不用走。基線外要走變更流程

6、配置狀態報告:通用case工具自動生成

能夠及時、準備地給出配置項的當前狀況,加強配置管理工作

what:發生了什麼事?

who:誰做的此事?

when:此事是什麼時候發生的?

why:為什麼做此事?

報告所有配置項以及變更請求的狀態

7、配置審計(配置審核)

變更控制的補充手段,來確保某一變更需求已被切實實現

配置項審計包括功能配置審計和物理配置審計。 

配置審計內容包括:

(1)評估基線的完整性

(2)檢查配置記錄是否正確反映了配置項的配置情況

(3)審核配置項的結構完整性

(4)對配置項進行技術評審

(5)驗證配置項的完備性和正確性

(6)驗證是否符合配置管理標準和規程

配置審核的任務便是驗證配置項對配置標識的一致性。配置審核的實施是為了確保專案配置管理的有效性,體現配置管理的最根本要求,不允許出現任何混亂現象,如:

(1)防止出現向使用者提交不適合的產品,如交付了使用者手冊的不正確版本。

(2)防止不完善的實現,如開發出不符合初始規格說明或未按變更請求實施變更。

(3)找出各配置項間不匹配或不相容的現象。

(4)確認配置項已在所要求的質量控制審核之後作為基線入庫儲存。

(5)確認記錄和文件保持著可追溯性。

文件種類

按重要性和質量要求:非正式文件、正式文件

按專案週期角度:開發文件、產品文件、管理文件

按14類文件:

1、可行性研究報告、2、專案開發計畫、3、軟體需求說明書、4、資料要求說明書、5、概要設計說明書、6、詳細設計說明書、7、資料庫設計說明書、8、使用者手冊、9、操作手冊、10、模組開發卷宗、11、測試計畫、12、測試分析報告、13、開發進度月報、14、專案開發總結報告

軟體配置管理的一些基本概念

原文 配置管理的定義 1 是採用技術手段和行政手段進行管理和監督的一套規範化方法 2 對配置項的功能特性和物理特性加以標誌,並將其檔案化,並控制這些特性的變更 3 報告變更進行的情況 變更實施的狀態,以及驗證與規定要求的一致性。配置管理的意義 配置管理能夠解決的問題 1 多重維護問題 解決多個使用者...

C 一些基本概念

建構函式的作用是對物件本身做初始化工作,也就是給使用者提供初始化類中成員變數的一種方式。析構函式是釋放物件執行期間所申請的資源。函式的過載,過載構成的條件 函式的引數型別不同 引數個數不同,才能構成函式的過載 在乙個類中 注意,只有函式的返回型別不同是不能構成函式的過載。在函式過載時,要注意函式帶有...

linux OS一些基本概念

1.什麼是os?好簡單好x的問題,可是如果真的要自己用稍微官方稍微正規的語言或文本來回答,我真的能回答清楚嗎?好吧,我先來用自己的語言來回答。再去找點官方的定義。我自己的回答 os就是乙個可以管理並且相對合理分配計算機資源的軟體。官方回答 作業系統 英語 operating system,簡稱os ...