軟件配置管理計劃書

1、軟件配置管理計劃編寫規(guī)范案卷號日期V項目名稱軟件配置管理計劃作 者：完成日期：簽收人：簽收日期：修改情況記錄:版本號修改批準人修改人安裝日期簽收人第1頁軟件配置管理計劃編寫規(guī)范目錄1引言11.1目的11.2定義和縮寫詞11.3參考資料12管理12.1機構12.2任務22.3職責22.4接口控制22.5實現22.6適用的標準、條例和約定 32.6.1 指明32.6.2 內容33軟件配置管理活動43.1配置標識43.1.1 基線43.1.2代碼、文檔 43.2配置控制53.3配置狀態(tài)的記錄和報告 53.4配置的檢查和評審 64工具、技術和方法 65對供貨單位的控制 76記錄的收集、維護和保存 77

2、附錄：配置管理報表及其格式 77.1軟件問題報告單（SPR） 77.1.1配置管理人員填寫內容 77.1.2配置管理狀態(tài) 87.1.3配置管理申請人員填寫的內容 87.2軟件修改報告單（SCR）8第2頁軟件配置管理計劃編寫規(guī)范1引言1.1目的本條必須指出特定的軟件配置管理計劃的具體目的。還必須描述該計劃所針對的軟件項目（及其所屬的各個子項目）的名稱和用途。1.2定義和縮寫詞應該列出計劃正文中需要解釋的而在GB/T 11457中尚未包含的術語的定義，必要時，還要給出這些定義的英文單詞及其縮寫詞。1.3參考資料列出要用到的參考資料，如：a. 本項目的經核準的計劃任務書或合同、上級機關的批文；b.

3、屬于本項目的其他已發(fā)表的文件；c. 本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。2管理必須描述負責軟件配置管理的機構、任務及其有關的接口控制。2.1機構必須描述在各階段中負責軟件配置管理的機構。描述內容如下:a. 描述在軟件生存周期各階段中軟件配置管理的功能和負責軟件配置管理的機構;b. 說明項目和子項目與其他有關項目之間的關系；c. 指出在軟件生存周期各階段中的軟件開發(fā)或維護機構與配置控制組的相互關系。2.2任務描述在軟件生存周期各個階段中的配置管理任務以及要進行的評審和檢查工作，并指出各個階段的

4、階段產品應存放在哪一類軟件庫中（軟件開發(fā)庫、軟件受控庫或軟件產品庫）。2.3職責必須描述與軟件配置管理有關的各類機構或成員的職責，并指出這些機構或成員相互之間的關系。A. 指出負責各項軟件配置管理任務（如配置標識、配置控制、配置狀態(tài)記錄以及配置 的評審與檢查）的機構的職責；B. 指出上述機構與軟件質量保證機構、軟件開發(fā)單位、項目承辦單位、項目委托單位 以及用戶等機構的關系；C. 說明由本計劃第2.2條指明的生存周期各個階段的評審、檢查和審批過程中的用戶 職責以及相關的開發(fā)與維護活動；D. 指出與項目開發(fā)有關的各個機構的代表的軟件配置管理職責；E. 指出其他特殊職責，例如為滿足軟件配置管理要求所

5、必要的批準要求。2.4接口控制本條應該描述：a. 接口規(guī)格說明標識和文檔控制的方法；b. 對已交付的接口規(guī)格說明和文檔進行修改的方法;c. 對要完成的軟件配置管理活動進行跟蹤的方法；d. 記錄和報告接口規(guī)格說明和文檔控制狀態(tài)的方法;e. 控制軟件和支持它運行的硬件之間的接口的方法。2.5實現應該規(guī)定實現軟件配置管理計劃的主要里程碑，例如:a. 建立配置控制組；b. 確定各個配置基線；c. 建立接口控制協議；d. 制訂評審與檢查軟件配置管理計劃和規(guī)程；e. 制訂相關的軟件開發(fā)、測試和支持工具的配置管理計劃和規(guī)程。2.6適用的標準、條例和約定261指明本條必須指明所適用的軟件配置管理標準、條例和約

6、定，并把它們作為本計劃要實現的一部分；還必須說明這些標準、條例和約定要實現的程度。2.6.2內容必須描述要在本項目中編寫和實現的軟件配置管理標準、條例和約定，內容可如下：a. 軟件結構層次樹中軟件位置的標識方法；b. 程序和模塊的命名約定；c. 版本級別的命名約定；d. 軟件產品的標識方法；e. 規(guī)格說明、測試計劃與測試規(guī)程、程序設計手冊及其他文檔的標識方法；f. 媒體和文檔管理的標識方法；g. 文檔交付過程；h. 軟件產品庫中軟件產品入庫移交或交付的過程；i. 問題報告、修改請求和修改次序的處理過程；j. 配置控制組的結構和作用；k. 軟件產品交付給用戶的驗收規(guī)程；l. 軟件庫的操作，包括準

7、備、存儲和更新模塊的方法；m .軟件配置管理活動的檢查；n.問題報告、修改請求或修改次序的文檔要求，指出配置修改的目的和影響；o.軟件進入配置管理之前的測試級別；p.質量保證級別，例如，在進入配置管理之前，驗證軟件滿足有關基線的程度。3軟件配置管理活動本章必須描述配置標識、 配置控制、配置狀態(tài)記錄與報告以及配置檢查與評審等四方面的軟件配置管理活動的需求。3.1配置標識3.1.1基線本條必須詳細說明軟件項目的基線（即最初批準的配置標識），并把它們與本計劃第 2.2條描述的生存周期的特定階段相聯系。在軟件生存周期中，主要有三種基線，它們是功能基線、指派基線和產品基線。對于每個基線，必須描述下列內容

8、：a. 每個基線的項（包括應交付的文檔和程序）；b. 與每個基線有關的評審與批準事項以及驗收標準；c. 在建立基線的過程中用戶和開發(fā)者的參與情況。例如，在產品基線中，要定義的元素可以包括：a. 產品的名字和規(guī)則；b. 產品標識編號；c. 對每一個新交付的版本，要給出版本交付號、新修改的描述、修改交付的方法、對 支持軟件的修改要求以及對有關文檔的修改要求；d. 安裝說明；e. 已知的缺陷和故障；f. 軟件媒體和媒體標識。3.1.2代碼、文檔本條必須描述本項目所有軟件代碼和文檔的標題、代號、編號以及分類規(guī)程。 例如，對 代碼來說:a. 編譯日期可以作為每個交付模塊標識的一部分;b. 在構造模塊源代

9、碼的順序行號時，應使它適合于對模塊作進一步的修改。3.2配置控制必須描述在本計劃第 2.2條描述的軟件生存周期中各個階段使用的修改批準權限的級 別；必須定義對已有配置的修改建議進行處理的方法，其中包括：a. 詳細說明在本計劃第 2.2條描述的軟件生存周期各個階段中提出修改建議的程序（可以用注上自然語言的流程圖來表達）；b. 描述實現已批準的修改建議（包括源代碼、目標代碼和文檔的修改）的方法；c. 描述軟件庫控制的規(guī)程， 其中包括存取控制、對于適用基線的讀寫保護、 成員保護、 成員標識、檔案維護、修改歷史以及故障恢復等七項規(guī)程；d. 如果有必要修補目標代碼，則要描述其標識和控制的方法。對于各個不

10、同層次的配置控制組和其他修改管理機構，本條必須：a. 定義其作用，并規(guī)定其權限和職責；b. 如果已組成機構，則指明該機構的領導人及其成員；c. 如果還沒有組成機構，則說明怎樣任命該機構的領導人、成員及代理人；d. 說明開發(fā)者和用戶與配置控制組的關系。當要與不屬于本軟件配置管理計劃適用范圍的程序和項目進行接口時，本條必須說明對其進行配置控制的方法。如果這些軟件的修改需要其他機構在配置控制組評審之前或之后進 行評審，則本條必須描述這些機構的組成、它們與配置控制組的關系以及它們之間的相互關系；本條必須說明與特殊產品 （如非交付的軟件、 現存軟件、用戶提供的軟件和內部支持軟 件）有關的配置控制規(guī)程。3

11、.3配置狀態(tài)的記錄和報告本條必須：a. 指明怎樣收集、驗證、存儲、處理和報告配置項的狀態(tài)信息；b. 詳細說明要定期提供的報告及其分發(fā)辦法；c. 如果有動態(tài)查詢，要指出所提供的動態(tài)查詢的能力；d. 如果要求記錄用戶說明的特殊狀態(tài)時，要描述其實現手段。例如，在配置狀態(tài)記錄和報告中，通常要描述的信息有：a. 規(guī)格說明的狀態(tài)；b. 修改建議的狀態(tài)；c. 修改批準的報告；d. 產品版本或其修改版的狀態(tài)；e. 安裝、更新或交付的實現報告；f. 用戶提供的產品（如操作系統(tǒng)）的狀態(tài)；g. 有關開發(fā)項目歷史的報告。3.4配置的檢查和評審本條必須：a. 定義在軟件配置管理計劃的第 2.2條所定義的軟件生存周期的特

12、定點上執(zhí)行的檢查 和評審中軟件配置管理計劃的作用；b. 規(guī)定每次檢查和評審所包含的配置項；c. 指出用于標識和解決在檢查和評審期間所發(fā)現的問題的工作規(guī)程。4工具、技術和方法必須指明為支持特定項目的軟件配置管理所使用的軟件工具、技術和方法，指明它們的目的，并在開發(fā)者所有權的范圍內描述其用法。 例如，可以包括用于下列任務的工具、 技術 和方法：a. 軟件媒體和媒體文檔的標識；b. 把文檔和媒體置于軟件配置管理的控制之下，并把它正式地交付給用戶。 例如，要 給出對軟件庫內的源代碼和目標代碼進行控制的工具、技術和方法的描述；如果用到數據庫管理系統(tǒng)， 則還要對該系統(tǒng)進行描述。又如，要指明怎樣使用軟件庫工

13、具、技術和方法來處理軟件產品的交付。c. 編制關于程序及其有關文檔的修改狀態(tài)的文檔。因此必須進一步定義用于準備多種 級別（如項目負責人、配置控制小組、軟件配置管理人員和用戶）的管理報告的工 具、技術和方法。5對供貨單位的控制供貨單位是指軟件銷售單位、軟件開發(fā)單位或軟件子開發(fā)單位。必須規(guī)定對這些供貨單位進行控制的管理規(guī)程，從而使從軟件銷售單位購買的、其他開發(fā)單位開發(fā)的或從開發(fā)單位 現存軟件庫中選用的軟件能滿足規(guī)定的軟件配置管理需求。管理規(guī)程應該規(guī)定在本軟件配置管理計劃的執(zhí)行范圍內控制供貨單位的方法；還應解釋用于確定供貨單位的軟件配置管理能力的方法以及監(jiān)督他們遵循本軟件配置管理計劃需求的方法。6記

14、錄的收集、維護和保存本章必須指明要保存的軟件配置管理文檔，指明用于匯總、保護和維護這些文檔的方法和設施（其中包括要使用的后備設施），并指明要保存的期限。7附錄：配置管理報表及其格式7.1軟件問題報告單（SPR）在系統(tǒng)的運行與維護階段對軟件產品的任何修改建議，或在軟件開發(fā)的任一階段中對前面各個階段的階段產品的任何修改建議，都應填入軟件軟件問題報告單。軟件問題報告單位的格式見表1。7.1.1配置管理人員填寫內容表中A、B、C、P和狀態(tài)等項目是由負責修改控制的配置管理人員填寫的。表中其他各項即D、E、F、G、H、丨、K、N和0各項是由發(fā)現問題的人或申請配置管理的人填寫的，他可能還要填寫 J、L和M三

15、項內容。前四項內容的意義如下：A是由配置管理人員確定的登記號，一般按報告問題的先后順序編號；B是由配置管理人員登記問題報告的日期；C是發(fā)現軟件問題的日期；P是填寫若干補充信息和修改建議。關于配置管理七種狀態(tài)的含義在下面解釋。7.1.2配置管理狀態(tài)狀態(tài)一欄分成七種情況，現分別說明如下：1表示軟件問題報告正被評審，已確定采取什么行動；2表示軟件問題報告已由指定的開發(fā)人員去進行維護工作；3表示修改已經完成、測試好，正準備釋放給主程序庫；4表示主程序庫已經更新，主程序庫修改的重新測試尚未完成；5表示已經進行了復測，但發(fā)現問題仍然存在；6表示已經進行了復測，已經順利完成所做的修改，軟件問題報告單被關閉（

16、維護已完成）；7表示留待以后關閉，因問題不是可重產生的，或者是屬于產品改善方面的，或者只具有很低的優(yōu)先級等等。7.1.3配置管理申請人員填寫的內容在軟件問題報告單中，屬于配置管理申請人填寫的各項內容的意義如下：D、E兩項是項目和子項目的名稱，F是該子項目的代號，這應按配置標識的規(guī)定來命名代號；階段名和報告人的姓名、住址和電話等的含義是顯而易見的；G表示問題屬于哪一方面的，是程序的問題還是例行程序的問題，是數據庫的問題還是文檔的問題，是功能性修改還是性能改進性修改問題，也可能是它們的某種組合；H表示子例行程序/子系統(tǒng)，即要指出出現問題的子例行程序名字，如果不知是哪個子例行程序，可標出子系統(tǒng)名，總

17、之，盡可能給出細節(jié)；I是修訂版本號，指出出現問題的子例行程序版本號；J是媒體，表示包含有問題的子例行程序的主程序庫存儲媒體的標識符；K是數據庫，表示當發(fā)現問題時所使用的數據庫標識符；L是文檔號，表示有錯誤的文檔的編號；M表示出現錯誤的主要測試實例的標識符；N是硬件，表示發(fā)現問題時所使用的計算機系統(tǒng)的標識；O是問題描述/影響，填寫問題征候的詳細描述，如果可能則寫明實際問題所在，還要 給出該問題對將來測試、界面軟件和文檔等的影響。7.2軟件修改報告單（SCR）對軟件產品或其階段產品的任何修改，都必須經過評審、批準后才能重新投入運行或作為階段產品釋放。這一過程用軟件修改報告單（software ch

18、ange report ）給以記錄。軟件修改報告單的格式表 2。當收到了軟件問題報告單之后，配置管理人員便填寫軟件修改報告單。 軟件修改報告單要指出修改類型、修改策略和配置狀態(tài)，它是供配置控制小組進行審批的修改申請報告。表中各項內容的意義如下：A是登記號，它是配置修改小組收到軟件修改報告單時所作的編號；B是配置管理人員登記軟件修改報告單的日期；C是已經準備好軟件修改報告單、可以對它進行評審的時間；D、E和F的意義與軟件問題報告單中的D、E和F的意義相同；G填寫被處理的軟件問題報告單的編號，如該編號中提出的問題只是部分解決，則在填寫時要在該編號后附以字母 P（ Part表示部分之意）；H指出是程

19、序修改、文檔更新、數據庫修改還是它們的組合，如果僅是指出用戶文檔的缺陷則在解釋處作上記號；I是修改的詳細描述，如果是文檔更新，則要列出文檔更新通知單的編號；如果是數據庫修改，則要列出數據庫修改申請的標識號；J是批準人，經批準人簽字、批準后才能進行修改；K是語句類型，程序修改中涉及到的語句類型包括：輸入/輸出語句類、計算語句類、邏輯控制語句類、數據處理語句類（如數據傳送、存放語句）；L是程序名，指被修改注程序、文檔或數據庫注名字。如果只要求軟件修改報告單做解釋性工作，則注重復軟件問題報告單給出的名字；M指當前注版本/修訂本標識；N指修改后的新版本/修訂本標識；O指數據庫，如果申請數據庫修改，這里給出數據庫的標識符；P是數據庫修改申請?zhí)?DBCR ；Q指文檔，即如果要求文檔修改，則在這里給出文檔的名字；R是文檔更新通知單編號 DUT ；S表示修改是否已經測試，指出已對修改做了哪些測試，如單元、子系統(tǒng)、組裝、確認和運行測試等，并注明測試成功與否；T指出在軟件問題報告單中給出的問題描述是否準確，并回答是或否；U是問題注釋，準確地重新敘述要修改的問題；V指明問題來自哪里，如系統(tǒng)設計規(guī)格說明書、 軟件需求規(guī)格說明書、 概要設計說明書、詳細設計說明書、數據庫、