配置管理計畫

2021-03-04 04:17:19 字數 5423 閱讀 8999

2.2 任務

在軟體工程化生產的各個階段中,與本階段的階段產品有關的全部資訊在軟體開發庫存放,與前面各個階段的階段產品有關的資訊則在軟體受控庫存放。在研製與開發階段的階段產品的過程中,開發者和開發小組組長有權對本階段的階段產品作必要的修改;但是如果開發者或開發小組長認為有必要修改前面有關階段的階段產品時,就必須通過專案的配置管理小組辦理正規的審批手續。因此,軟體開發庫屬開發這個階段產品的開發者管理,而軟體受控庫由專案的配置管理小組管理。

軟體經過組裝與系統測試後,應該送入軟體產品庫,如欲對其修改,必須經軟體配置管理小組研究同意,然後報專案總體組組長批准。關於軟體配置要進行修改時的具體審批手續,將在第3.2條中詳細規定。

2.3 職責

在軟體配置管理小組中,各類人員要互相配合、分工協作,共同擔負起整個專案的軟體配置管理工作。其中各類人員的分工如下:

a. 組長是總體組代表,他對有關軟體配置管理的各項工作全面負責,特別要對更改建議的審批和評審負責;

b. 軟體工程小組組長負責監督在軟體配置管理工作中認真執行軟體工程規範;

c. 專案的專職配置管理人員檢查在作配置更改時的質量保證措施;

d. 各子系統的配置管理人員具體負責實施各自的配置管理工作,並參與各子系統的功能配置檢查和物理配置檢查;

e. 使用者代表負責反映使用者對配置管理的要求,並協助檢查各類人員對軟體配置管理計畫的執**況;

f. 專案專職的配置管理人員協助組長開展各項軟體配置管理活動,負責審查所採用的配置管理工具、技術和方法,並負責彙總、維護和儲存有關軟體配置管理活動的各項記錄。

2.4介面控制

對各類介面進行嚴格、合理的控制,是軟體配置管理中最重要的任務之一。整個軟體專案及其各子系統都必須對進行嚴格的控制。在工程化軟體系統中,主要的介面有如下五類:

a. 使用者介面:使用者介面是指各子系統與設計人員、使用者或維護人員之間的操作約定。同時還指實現這些操作約定的物理部件的功能與效能特性。

b. 系統內部介面:系統內部介面是指各子系統在集成為乙個總的軟體系統時的各種連線約定。

c. 標準程式介面:標準程式介面是指各應用子系統與標準子程式庫(包括宿主計算機系統已有的庫程式)之間的呼叫約定。

d. 裝置介面:裝置介面是指各子系統與各種裝置(包括終端和其他各種輸入/輸出裝置)之間的連線約定。

e. 軟體介面:軟體介面是指各個子系統與宿主計算機上的系統軟體以及與呼叫本軟體的其它軟體系統之間的連線約定。 以上五類介面是乙個軟體系統各項配置的重要組成部分。

對介面修改進行合理的控制,是軟體配置管理的重要任務之一。這五類介面都涉及到glyhglxt軟體系統的全域性,因此,當要求對這五類介面中的任一類介面進行修改時,都必須辦理正規的審批手續,最後要經專案總體組批准。具體的審批程式將在本計畫的第3.

2條中規定(可參閱表1)。

表1 兩類修改的審批程式

步驟 a類修改的審批程式 b類修改的審批程式

1 發現問題,填寫軟體問題報告單發現問題,填寫軟體問題報告單

2 專案組長評審專案組長評審

3 軟體配置管理小組評審子系統配置管理人員評審

4 專案總體組批准子系統負責人批准

5 修改配置並填寫軟體修改報告單修改配置並填寫軟體修改報告單

6 專案組長評審專案組長評審

7 軟體質量保證小組評審子系統質量保證人員評審

8 總體組批准專案的軟體配置管理小組與子系統負責人共同批准並報專案總體組備索

2.5 軟體配置管理計畫的實現

在實現軟體配置管理計畫的過程中,要特別注意實現以下三個里程碑:

a. 建立軟體配置管理小組:在專案總體組批准軟體配置管理計畫之後,立即成立軟體配置管理小組;

b. 建立各階段的配置基線:隨著glyhglxt軟體系統及其所屬各子系統的任務書的評審和批准,建立起功能基線;隨著總體組編寫的《glyhglxt軟體需求規格說明書》的批准,建立起指派基線;隨著glyhglxt工程化軟體系統的整合與系統測試的完成,建立起產品基線。

c. 建立軟體庫:在本專案所屬的各個子系統的研製工作的開始,就建立起各個子系統的軟體開發庫,並在本專案配置管理小組的計算機上建立起有關該系統及其子系統的軟體受控庫。以後在每個開發階段的結束,建立各個子系統的新的開發庫,同時把這個階段的階段產品送入總的軟體受控庫,並在各個子系統的計算機上建立軟體受控庫的副本。

軟體受控庫必須以主軟體受控庫為準。當全部開發工作結束,在配置管理小組的計算機上建立起軟體產品庫,並在各子系統的計算機上建立軟體產品庫的副本。

2.6 適用的標準、條例和約定

除應奠定本計畫第1.3條中指出的參考資料以及本計畫中的其他章條所作的各項規定外,還應該遵守如下標準、條例和約定:

a. 軟體開發庫、軟體受控庫與軟體產品庫的操作規程與管理規程;

b. 系統、子系統、模組和程式單元的命名約定;

c. 文件和測試用例的命名和管理規程。

這引起命名約定、操作規程與管理規程應由glyhglxt專案技術組負責制訂,並應認真聽取各子系統專案負責人的意見,最後報專案總體組審批。在執行過程中,如果發現某些條款需要修改,則必須辦理正規的審批手續,最後要經專案總體組批准。具體的審批程式將在本計畫的第3.

2條中規定。

3 軟體配置管理活動

3.1 配置標識

3.1.1 文件

所有為本專案編制的文件,都要符合gb 8567中的規定。glyhglxt軟體系統及其所屬的各個子系統所編寫的文件數目,可根據gb 8567的規定作適當的剪裁。剪裁方案由技術組提出建議,報總體組批准。

3.1.2 程式

所有屬於本專案的程式、分程式、模組和程式單元,都要按照由專案技術組制訂,且經總體組批准的軟體系統的命名約定的規定來標識。

3.1.3 各類基線

所有屬於本專案及其各子系統的各類基線,首先要按照任務書、軟體需求規格說明書的規定確定其技術內容,然後按照軟體系統的上述命名約定的規定來標識。

3.2 配置控制

軟體配置的更改管理適用於本專案的所有文件和**,其中包括本專案的各個執行軟體,也包括為本專案專門開發的支援軟體。配置控制的要點如下:

a. 修改批准許可權;對本專案各個子系統及其專用支援軟體的功能基線、指派基線、產品基線及其整合系統的任何修改(稱為a類修改),都必須通過專案配置管理小組討論,並必須經總體組批准;對本專案各個子系統及其專用支援軟體的其他階段產品的任何修改(稱為b類修改),都必須通過本專案各個子系統的配置管理人員審查,並經專案的軟體配置管理小組與各個子系統負責人的共同批准並報專案總體組備案。

b. 修改審批程式:上述兩類修改的審批程式如表1。

c. 修改控制工具:修改控制工具是協助軟體配置管理人員進行配置控制的有效手段。

3.3 配置狀態審計

利用軟體問題報告單和軟體修改報告單對專案子系統及其支援軟體的配置狀態進行追蹤。對軟體問題報告單和軟體修改報告單的追蹤應由軟體配置管理工具自動實現,使用者可通過該軟體系統對其進行查詢。 注:

本計畫在此處應給出軟體問題報告單與軟體修改報告單的具體格式,並作出必要的說明。鑑於本計畫擬採用附錄b(參考件)中建議的格式,因而這兩個報告單的格式及其說明可參閱附錄b。

3.4 配置的檢查和評審

專案軟體配置管理小組要對所有由第三方提供的軟體進行物理配置檢查;對本專案及其各個子系統的每乙個新的釋放進行功能配置檢查和物理配置檢查;對宿主計算機系統所提供的軟體和硬體配置要每隔半年檢查一次;在軟體驗收前要對宿主計算機系統、各個子系統及其專用支援軟體的配置進行綜合檢查。

在軟體開發周期各階段的評審與檢查工作中,要對該階段所進行的配置管理工作進行必要的評審和檢查。應該進行評審與檢查的內容與次數,由glyhglxt軟體質量計畫規定。配置修改的審批程式按本計畫第3.

2條的規定處理(見表1)。

4 工具、技術和方法

在軟體的開發過程中,與軟體配置有關的工具有軟體測試工具、軟體配置管理工具、文件輔助生成工具與圖形編輯工具等到三種。

a. c軟體測試工具:它支援用c語言編寫的模組的靜態分析、結構測試與功能測試。主要功能為:

協助測試人員判斷程式結構與變數使用情況是否有錯;給測試人員提供模組語句覆蓋c0和分支覆蓋率   c1的值、並顯示未覆蓋語句和未覆蓋分支的號碼及其分支謂詞,給出不同測試用例有效性的**;同時提出功能測試的有效情況,並協助組織最終交付給使用者的有效測試用例的集合。

b. 軟體配置管理工具:它支援使用者對源**清單的更新管理以及對重新編譯與連線的**的自動組織;支援使用者在不同文件相關內容之間進行相互檢索並確定同一文件某一內容在本文件中的涉及範圍;同時還應支援軟體配置管理小組對軟體配置更改進行科學的管理。

c. 文件輔助生成工具與圖形編輯工具:它主要協助使用者繪製描述程式流程與結構的dfd圖與sc圖、繪製描述軟體功能(輸入、輸出關係)的曲線以及繪製描述系統特性的一些其他圖形,同時還可生成若干與glyhglxt軟體文件編制大綱適應的文件模板。使用者利用這個工具的正文與圖形編輯功能以及上述輔助功能,可以比較方便地產生清晰悅目的文件,也有利於對文件進行更改,這有助於提高文件的編制質量。

有關這些工具的詳細需求可參閱這三項工具的需求規格說明書中的規定。

5 對供貨單位的控制

glyhglxt軟體專案所屬的各個子系統開發組如果需要從軟體銷售單位購買、委託其他開發單位、從開發單位現存軟體庫選用或從專案委託單位或使用者的現有連鎖反應加中選用軟體時,則在選用前應向glyhglxt總體組報告,然後由glyhglxt總體組組織"軟體選用評審小組"進行評審、測試與檢查,只有當演示成功、測試合格後才能批准使用。如果只選用其中部分內容,則按等待開發軟體的處理過程辦理,此時glyhglxt總體組不予預。在進行上述工作過程中,軟體配置管理人員要進行下列工作:

a. 專案的軟體配置管理小組要參加對上述四類由間接供貨單位提供的軟體的物理配置檢查; 這些軟體的功能配置檢查由專案的軟體質量保證小組負責。

b. 在這些軟體送入軟體受控庫與其他軟體成分進行組裝之前,軟體配置管理小組要對其存放**和配置標識進行認真的審查。

c. 由軟體質量保證小組審查選用的上述四類軟體,必須經過正式的驗收手續,並由專案技術管理小組負責人批准,然後置於軟體配置管理小組的控制之下。維護的記錄要儲存在本專案及其所屬的各個子系統的研製與開發期間,要進行各種軟體配置管理活動。準確記錄、及時分析並妥善存放有關這些活動的記錄,對這些軟體的下沉執行與維護工作十分有利。

在軟體配置管理小組中,應有專人負責收集、彙總與儲存這些記錄。

a. 基礎上組裝系統、各個子系統、專用支援軟體及選用軟體的功能基線、指派基線與產品基線要送入軟盤或磁帶,至少必須一式兩份且存放在兩個不同的地點。這些記錄應該每6個月拷貝一次,以免意外損傷與自然老化。

b. 上述這些軟體的文件也應送入軟盤或磁帶,至少必須工式兩份且存放在兩個不同的地點,並應有乙份列印的硬拷貝。磁**應該每隔6個月拷貝一次,以免意外損傷與自然老化。

c. 軟體產品的源程式、測試資料、測試報告及其他有關文件,除了按a、b規定妥善存放外,要在專案結束後再儲存2年,或在條件成熟時轉交給這些軟體產品的生產系統。

注:具體儲存年限要根據專案的性質與開發單位的任務來確定,此處僅作為乙個示例。

d. 上述這些軟體的各項配置的個性狀態、評審記錄與修改歷史,要作為這些軟體的歷史記錄來儲存,目前可用列印硬拷貝一式兩份存放,有條件時再轉移到**光學儲存**中。

e. 鑑於處理版權或清理財務的需要,本軟體系統的各項配置可能要求存放5~7年,但由於我國對這些問題尚無明確的規定,因此,有關本條款的具體規定待將來有必要與可能時再作修改與補充。

配置管理計畫

專案名稱 the english name 專案小組 修訂表審批記錄 目錄1.引言 4 1.1 目的 4 1.2 適用範圍 4 1.3 參考資料 4 1.4 術語和縮略語 4 2.人員與責任 4 3.用於配置管理的軟硬體資源 5 4.配置庫結構與許可權 5 4.1 配置庫列表 5 4.2 配置庫結構...

配置管理計畫

專案名稱 檔案修改記錄 變化狀態 c 建立,a 增加,m 修改,d 刪除 文件審批資訊 目錄1 概述 1 1.1 目的 1 1.2 適用範圍 1 1.3 背景 1 1.4 參考資料 1 2 資源描述 1 2.1 角色職責 1 2.2 軟體資源 2 2.3 硬體資源 2 3 配置管理活動 2 3.1 ...

配置管理計畫

此頁為模板文件本身的版本控制記錄表,按模板生成的正式文件中不需要此頁 目錄1.簡介 5 1.1 目的 5 1.2 範圍 5 1.3 專業術語定義 5 1.4 參考資料 5 2.組織和管理 5 2.1 配置管理組織架構 5 2.2 角色和職責 5 2.3 scm指導方針 6 3.scm活動 6 3.1...