軟件配置管理計劃(ISS-MDCC-CMP)

項目名稱文檔編號MDCC項目項目ID密級：機密共10頁配置管理計劃擬制日期2011-6-1評審人日期2011-6-1批準日期簽發(fā)日期配置管理計劃配置管理計劃第第#頁共10頁文檔修訂記錄版本完成人修改內容審核批準時間V.00凌廣美創(chuàng)建文檔2011-6-1目錄TOC\o"1-5"\h\z\o"CurrentDocument"\h引言 4編寫目的 4適用范圍 4背景描述 4\o"CurrentDocument"\h縮略語 4參考資料 4\o"CurrentDocument"\h命名規(guī)則 5工程類文檔 5過程類文檔 5\o"CurrentDocument"\hCode代碼 5\o"CurrentDocument"\hTools工具 6\o"CurrentDocument"\h配置庫 6\o"CurrentDocument"\h配置庫結構 6\o"CurrentDocument"\h文檔 6\o"CurrentDocument"\h非配置項 7\o"CurrentDocument"\h基線計劃 8\o"CurrentDocument"\h變更控制 9\o"CurrentDocument"\h基線更改 9\o"CurrentDocument"\h變更請求流程 9\o"CurrentDocument"\hCCB會議： 10\o"CurrentDocument"\h版本控制和發(fā)布 10\o"CurrentDocument"\h版本控制 10\o"CurrentDocument"\h發(fā)布策略和計劃 10\o"CurrentDocument"\h備份及歸檔 10\o"CurrentDocument"\h配置庫的備份 10\o"CurrentDocument"\h項目文件夾備份 10\o"CurrentDocument"\h長假期間的備份 10\o"CurrentDocument"\h歸檔 10引言編寫目的本計劃描述了貫穿本項目軟件生命周期的由SCM組織識別并定義的一系列的軟件配置項的實踐過程。描述項目的配置管理計劃標識項目的配置項定義項目配置庫及其特征定義項目組遵循的變更控制過程適用范圍本計劃適用于《MDCC項目》的軟件配置管理活動。背景描述為保證軟件的質量與進度，指導軟件過程中出現的變更，提供一個規(guī)范的流程使得軟件過程中的所有活動都有據可尋；并且通過識別配置項和將要建立基線的點，來確定SCM工作的需求范圍和時間。在此背景之下，制定本軟件配置管理計劃?？s略語縮略語 英文全名中文解釋SCM SoftwareConfigurationManagement軟件配置管理CCB ConfigurationControlBoard配置控制小組CMO ConfigurationManagementOfficer配置管理員CI ConfigurationItem配置項CR ChangeRequest變更申請CSA ConfigurationStatusAccounting配置狀態(tài)發(fā)布參考資料《軟件開發(fā)計劃(ISS_MDCC_PPL)》《MDCC項目開發(fā)工作任務書》《MDCC項目設計規(guī)格》命名規(guī)則每個配置項都必需被唯一地標識，這個唯一的標識被用于與其它配置項進行區(qū)分，跟蹤和報告該配置項的狀態(tài)。一般地，每個配置項被賦予一個標識符。工程類文檔對于工程類文檔命名格式采用如下命名：＜產品名稱＞+＜文檔類型＞舉例：MDCC軟件需求規(guī)格說明書文檔類型參見如下定義：文檔類型對于英文文檔對于中文文檔軟件需求規(guī)格SRS軟件需求規(guī)格說明書軟件設計SD軟件設計說明書編碼CODE源代碼過程類文檔對于資料命令管理系統(tǒng)項目采用的過程文檔的命名方式：＜項目名稱＞-＜文檔助記符＞.＜擴展名＞舉例：MDCC項目-PPL.doc下面是一些重要過程文檔的助記符。助記符文檔類型SOW工作任務書EST估計記錄表格PPL項目計劃CMP配置管理計劃PSR項目狀態(tài)報告EOP階段結束報告EXR例外報告CLR項目結束報告CRF變更申請表格MTX度量表格WBS工作分解結構MOM會議紀要Code代碼源代碼各個文件的命名規(guī)范，請項目組討論確定。在項目中，整個代碼作為一個配置項，使用“項目名稱-CODE”作為配置項標識。Tools工具以工具本身的名稱命名。配置庫配置庫中存放所有配置項，由配置管理員負責維護。配置管理工具采用VSS6.0。配置庫位置在\server2003配置庫結構配置庫結構列表配置項CI客戶文檔Customers客戶提供的《工作任務書》等文檔項目計劃Plan軟件估計Estimation軟件估計書（規(guī)模、資源、進度等估計）軟件開發(fā)計劃PPL軟件開發(fā)計劃（含風險管理、測試策略等內容）、項目WBS配置管理計劃CMP配置管理計劃需求文檔SRS需求規(guī)格說明書設計文檔SD設計說明書單元測試UT單元測試計劃、單元測試用例集成測試IT集成測試計劃、集成測試用例系統(tǒng)測試ST系統(tǒng)測試計劃、系統(tǒng)測試用例代碼Code源代碼需求跟蹤RTM需求跟蹤矩陣表用戶手冊Help用戶手冊、在線幫助、技術白皮書文檔文檔配置項列表配置項山條目名稱分發(fā)對象MDCC-SOW工作任務書MDCC-EST軟件估計書MDCC-PPL項目計劃

配置項山條目名稱分發(fā)對象MDCC-CMP配置管理計劃MDCC-SRS軟件需求規(guī)格MDCC-SD軟件詳細設計文檔MDCC-RTM需求跟蹤矩陣xxx用戶手冊〈用戶相關文檔〉xxx技術白皮書〈用戶相關文檔〉非配置項非配置項列表項目管理PM會議紀要MOM開工會Kick-off項目開工會議紀要周例會Weekly周例會會議紀要階段結束會議EOP各階段結束會議紀要關閉會議Closure項目關閉會議紀要技術討論會議Technical技術討論會議紀要其它會議Other項目報告Report項目周報Weekly項目周報階段結束報告EOP各階段結束總結報告項目結束報告Closure項目結束報告例外報告Exception出現異常時的說明報告問題跟蹤Tracking遺留問題跟蹤、風險管理團隊建設TeamBuliding紅黑星記錄，績效考核，成長計劃I配置管理CM配置狀態(tài)發(fā)布CSA配置狀態(tài)發(fā)布文檔變更請求CR變更請求文檔CCB會議紀要CCB會議紀要配置庫備份記錄Backup配置庫備份記錄文檔質量管理QM度量Metrics度量表檢視ReviewPlan階段階段輸出物的Review記錄SRS階段階段輸出物的Review記錄STCSD階段階段輸出物的Review記錄UTCCode階段階段輸出物的Review記錄

公共各種ReviewChecklist匯總審計AuditSQA各階段審計報告測試記錄TestRecord單元測試UT單元測試用例執(zhí)行記錄集成測試IT集成測試用例執(zhí)行記錄系統(tǒng)測試ST系統(tǒng)測試用例執(zhí)行記錄驗收測試AT驗收測試執(zhí)行記錄培訓及總結TrainingPlan階段各階段啟動前的培訓文檔各階段結束時的組員總結SRS階段工具使用Tools工具使用培訓文檔參考資料Reference甲方提供的參考資料日志TimeSheet工時統(tǒng)計TimeSheet組員每天工時統(tǒng)計表工作日志Log組員每天工作日志技術問題跟蹤Tracking技術問題跟蹤表基線計劃在配置管理系統(tǒng)中，基線就是配置項在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)，而這個過程被稱為“基線化”。每一個基線都是其下一步開發(fā)的基準。每個基線都將接受配置管理的嚴格控制，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發(fā)階段結束時，上一個基線加上增加和修改的內容形成下一個基線?；€具有以下屬性：通過正式的評審過程建立?；€存在于配置庫中，基線的變更由CCB控制。基線是進一步開發(fā)和修改的基準?；€計劃：1）計劃階段文檔批準、簽發(fā)后基線化；2）需求階段：需求規(guī)格說明書初稿文檔完成，放入項目文件夾中，同時提交評審。文檔評審完成，輸出評審報告，完成需求跟蹤矩陣，并由部門經理批準簽發(fā)后，建立SRS基線。3）設計階段：軟件設計文檔初稿完成后，存放在項目文件夾中，必須提交評審、輸出評審報告、完成需求跟蹤矩陣的更新，然后項目經理批準，此時基線化完成。4）代碼基線化：當代碼完成時，在完成代碼Review，項目經理批準以后，進行代碼基線化。5）測試階段在測試報告被批準后代碼重新基線化；6）從需求階段開始，各階段文檔基線化后，需求跟蹤距陣同時也要基線化。7）對已基線化配置項的更改將遵循基線變更操作，更改后的配置項獲得批準簽發(fā)后,將形成新的基線。變更控制基線更改配置項的基線通常只在下述事件發(fā)生時才進行更改：評審發(fā)現的問題所導致的前面階段的修改，如由SD評審導致的SRS更改單元測試、系統(tǒng)測試檢測到的錯誤引起的前面階段的修改內部/外部審計發(fā)現引起的修改維護活動產生的問題報告引起的修改內部或客戶產生的需求變更由于某種原因引起的計劃文檔的修改。任何與已基線化的工作產品相關的變更必須以變更申請表的形式提出，由項目組成員填寫。發(fā)生分配需求變更必須召開CCB會議。除分配需求外的其它變更，CCB會議是可選的，但需要由PM批準。CR的狀態(tài)包括“已提交”、“已批準”、“已拒絕”、“掛起”、“已驗證”及“關閉”。填寫CR的項目組成員應是CR的提交人，提交人要確保提供了充分的信息。如可能，提交人應提供一個推薦的解決方案。變更請求流程變更請求一一＞填寫CR――＞CCB會議討論批準（分配需求變更）或PM批準一一＞CMO授權修改相關配置項一一＞更改驗證一一＞CMO批準驗證后的配置項一一＞關閉。特別說明：代碼在編碼完成后，代碼review前，由配置項責任人提交后，受控。在每個開發(fā)階段后，為了維護文檔與文檔之間、文檔與代碼之間的一致性，對前各階段的文檔進行集中修改。CCB會議：CCB組長根據更改請求的情況事件驅動地召集CCB會議。CCB也可以批量處理更改請求或采用定期的方式進行處理。根據修改的影響范圍，CCB召開相應的評估會議，并邀請相關人員參加。版本控制和發(fā)布版本控制單個配置項在每一次修改后都會發(fā)生變化，為了標識配置項在兩次修改之間的不同，需要對配置項的版本進行標識。文檔評審以前放在單獨的目錄中，當文檔在基線化后，保存在文件夾baselineXXX中，其中XXX為從1.0開始編號，號碼最大的文件夾中的文檔為最新的基線文檔；每次對基線化的文檔進行修改都不在原來基線的文檔上進行修改，而是在最新基線的文檔的COPY上進行修改，修改后的文檔