軟件配置管理流程

1、配置管理流程規(guī)定(Verl.O)擬制：審核：簽發(fā)：目錄1. 配置管理流程1.1概述31.2總體流程圖31.3軟件需求分析階段41.4軟件設計階段41.5制定配置管理計劃41.6配置庫管理41.6.1相關人員分配權限 41.6.2配置項51.7版本控制61.8變更控制61.9配置審計81.9.1配置審核的類別81.9.2配置審核執(zhí)行的時機 81.9.3不符合項的處理 82.0.0配置狀態(tài)報告 82.0.1配置狀態(tài)報告的目的 82.0.2配置狀態(tài)報告記錄的內(nèi)容 82.0.3配置狀態(tài)報告的生成 92.1.0發(fā)行管理92.1.1交付管理92. 軟件基線化規(guī)范 102.1正常開發(fā)期102.2版本發(fā)布期1

2、12.3項目發(fā)布期13Jira配置管理1431. 配置管理流程1.1概述規(guī)范配置管理活動，確保配置項正確地唯一標識并易于存取，保證基準配置項的更改受控，明確基線狀態(tài)，在貫穿整個軟件生命周期中建立和維護項目產(chǎn)品的完整性和可追溯性。1.2總體流程圖1.3軟件需求分析階段參加需求分析會議，配置管理負責人記錄，有關文檔提交歸檔。如需求分析。1.4軟件設計階段參加設計階段，為了詳細制定配置管理計劃 。針對需求分析報告進行系統(tǒng)設計，配置時應說明系統(tǒng)設計的版本與需求分析報告版本的對應關系。設計書評審通過后，建立設計基線。1.5制定配置管理計劃配置管理員制定配置管理計劃，主要內(nèi)容包括配置管理軟硬件資源、配置項

3、計劃、備份計劃等，審批該計劃。1.6配置庫管理配置管理員為項目創(chuàng)建配置庫，并給每個項目成員分配權限。各項目成員根據(jù)自己的權限操作配置庫。1.6.1相關人員分配權限項目經(jīng)理:1）與（有關負責人員）協(xié)商確定項目起始基線2）接受配置管理計劃，并按相關規(guī)定貫徹執(zhí)行;3）接受配置控制委員會的報告。4）提出配置管理計劃的修改要求；5）提出管理管理的建議和要求。配置管理員1）編制配置管理計劃；2）執(zhí)行配置項管理；3）執(zhí)行版本控制和變更控制方案；4）編制配置狀態(tài)報告；5）配置庫的建立和權限分配；6）配置管理工具的日常管理與維護;7）配置庫的日常操作和維護開發(fā)人員1）根據(jù)確定的配置管理計劃和相關規(guī)定，提交配置項

4、2）負責軟件集成和版本生成。3）按照軟件配置管理工具的使用模型來完成開發(fā)任務。測試人員1）根據(jù)配置管理計劃和相關規(guī)定，提交測試配置項。2）負責軟件變更的測試驗證。162配置項配置項的范圍：1）技術文檔：項目開發(fā)計劃、需求分析報告、軟件設計書、質(zhì)量保證 計劃、概要設計書、詳細設計書、測試用例，測試報告總結(jié)報 口等；2）程序：階段產(chǎn)品、源程序、釋放產(chǎn)品等；3）工具：自動設計工具、維護工具等；4）交互文檔：與客戶或項目組內(nèi)交互產(chǎn)生文檔用戶需求說明書。主要歸檔包括：需求分析報告、軟件設計書、用戶需求說明書、測試報告，源程序標 識。每個配置項的主要屬性有：名稱、標識符、文件狀態(tài)、版本、作者、日期等。所有

5、配置 項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程。配置項標識規(guī)則：1）項目有明確標識和追蹤要求時，由按要求進行標識，以保證滿足項目追蹤要求。2）在開發(fā)過程中項目組人員提交的配置項，規(guī)則進行標識。分配權限：一般地，配置管理負責配置項目成員擁有相對開發(fā)模塊權限，不能擁有其他的權限。配置庫的操作與管理：1）開發(fā)人員根據(jù)獲得的授權的資源進行項目的研發(fā)工作，操作配置庫2）配置管理負責人根據(jù)配置管理計劃創(chuàng)建與維護基線，“凍結(jié)”配置項，控制變更。3）配置管理員定期監(jiān)督或清除配置庫里的垃圾文件。4）配置管理員定期備份配置庫。1.7版本控制配置項的狀態(tài)有三種：“草稿”、“正

6、式發(fā)布”和“正在修改”，本規(guī)程制定了配置項 狀態(tài)變遷與版本號的規(guī)則。配置控制使用戶能夠通過對適當版本的選擇，（版本）組裝成各種各樣、不同功能模塊的模型。在開發(fā)過程中，我們在不同階段要建立各種Tag。狀態(tài)報告能夠報告所有配置項以及變更請求的狀態(tài)。1.8變更控制修改處于“草稿”狀態(tài)的配置項不算是“變更”，修改者按照版本控制規(guī)則執(zhí)行即可。當配置項的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時任何人都不能隨意修改， 必須依據(jù)申請執(zhí)行變更的規(guī)則執(zhí)行。如圖簡單例子78變更請求用戶#1.9配置審計1.9.1配置審核的類別配置審核分為：1）功能配置審核：審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審

7、查 測試方法、流程、報告和設計文檔等。2）物理配置審核：審核要交付的組成項是否存在，是否包含所有必需的項目，如正確 版本的源代碼、資源、文檔等等。1.9.2配置審核執(zhí)行的時機選擇以下幾種情況由測試經(jīng)理實施配置審核：1）軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前；2）軟件開發(fā)的階段工作結(jié)束后；3）在產(chǎn)品維護工作中，定期地進行。1.9.3不符合項的處理對配置審核中發(fā)現(xiàn)的不符合現(xiàn)象，測試負責人員進行記錄，并填寫不符合項報告， 交由責任部門限期進行糾正。所有的不符合項報告均關閉后，才能發(fā)布新版本。2.0.0配置狀態(tài)報告2.0.1配置狀態(tài)報告的目的記錄和報告整個軟件生命周期演化狀態(tài)。2.0.2配置狀態(tài)報告記錄的

8、內(nèi)容配置狀態(tài)報告記錄的內(nèi)容包括：1）軟件和文檔的標識；2）目前狀態(tài)；3）基線演化狀態(tài)；4）變更狀態(tài)；5）版本交付信息等。2.0.3配置狀態(tài)報告的生成配置管理報告自第一個基線創(chuàng)建時建立，由配置管理系統(tǒng)生成，及時反映當前配置狀態(tài)。2.1.0發(fā)行管理通過配置審核后，由項目經(jīng)理負責生產(chǎn)新版本，并由配置管理負責人檢入產(chǎn)品庫中，并 按照標識規(guī)則進行版本標識。2.1.1交付管理配置負責人從配置庫中提取配置項，交付給客戶或項目外的人員。交付出去的配置項 必須有據(jù)可查，避免發(fā)生混亂。流程如下：1）“索取人”向配置負責人提出交付申請。2）審批該申請。如果該申請不合法（合理），則拒絕交付配置項。如果同意交付，交 付

9、清單入檔。3）配置負責人從配置庫中提取配置項交付給“索取人”。4）“索取人”驗收后簽字。102. 軟件基線化規(guī)范2.1正常開發(fā)期在一些功能模塊需要測試，研發(fā)人員需tag注釋或提1 正常開發(fā)期間，私有工作區(qū)提交, 交配置管理員打tag。TrunkB u lid版本Tags釋釋22版本發(fā)布期 關鍵活動1技術總監(jiān)審計發(fā)布新版本，有關研發(fā)人員打Tag，命名標準為版本號加 alpha,在期間配置管理負責人build 一個內(nèi)部版本測試，持續(xù)到 final版本，測試驗證通過。如果在版本發(fā)布期間，研發(fā)還有功能增加，必須臨時分支，等到版本發(fā)布完成后，才能合并到主版本上， 關閉分支。配置管理負責人打tag注釋。如

10、流程圖。T em p tru nk審計幵臨時分支1. 在版本發(fā)布后，測試人員審驗發(fā)布的版本存在問題。用起先Tag2.0_final標識分支到branch的version下，為ver2.0維護版本。修改后建立內(nèi)部 測試版本2.0build，持續(xù)到2.0_final_sp1 .同時驗證主版本上是否存在問題，存在問題的話， 合并到Trunk上。如流程圖。Trunk152.3項目發(fā)布期1. 新的一個項目，項目沒有特制功能需求，配置管理員交付最新final版本，確定 版本標識。2. 新的一個項目，項目有特制功能需求，配置管理建Project branch,以最新的Tags。 涉及到正在開發(fā)的功能，那么所

11、有研發(fā)人員打 alphaTags . Project branch直維 護。有些需要的功能審計合并到主版本上。Tags163. Jira配置管理針對每個項目建版本標記，項目名加版本號，對該項目檢查到的 bug需要測試人員提交到該項目目錄中，一般bug的來源有兩種，一種是由測試人員發(fā)現(xiàn)的bug，一種是在項目實施過程中用戶發(fā)現(xiàn)的，開發(fā)人員需要通過優(yōu)先級修改Bug，測試人員可從jira上根據(jù)bug狀態(tài)進行驗證。都可以在jira平臺上實現(xiàn)管理，有關人員都可在jira上查看bug情況。在項目上發(fā)現(xiàn)bug，是通用bug時，測試人員打上特別的標記，審計合并到trunk版本上。1）配置管理員監(jiān)督jira提交的問題，執(zhí)行分配人員（研發(fā)人員預計修