CM_產(chǎn)品發(fā)布規(guī)程

1、密級：普通 秘密 機密 絕密產(chǎn)品發(fā)布子過程定義(PR， Product Release)文件狀態(tài) 草 稿 正式發(fā)布 正在修改項目編號模板標識文件標識當前版本總頁數(shù)8頁正文8 頁附件0個0頁審批生效日期Error! Reference source not found. 第 8 頁 共 8 頁版本歷史版本號生效日期版本說明/變更理由/變更內(nèi)容作者備注變更說明： C 創(chuàng)建 ；A添加 ；M 修改 ；D刪除目錄1介紹(Introduction)41.1目的(Purpose)41.2參考資料(References)41.3術語(Abb. & Glossary Commentation)42總體概

2、述(Process Overview)42.1子過程目標(SubProcess Goals)42.2角色和職責(Roles and Responsibility)42.3進入準則(Entry Criteria)42.4輸入(Output)42.5總體流程圖(GeneralFlow)52.6輸出(Input)52.7退出準則(Exit Criteria)53活動描述(Activity Description)63.1過程版本發(fā)布控制63.1.1活動流程圖(Activity Flow)63.1.2活動描述73.2最終產(chǎn)品發(fā)布控制73.2.1活動流程圖(Activity Flow)73.2.2活動描

3、述74裁剪指南85過程、規(guī)范與工作產(chǎn)品(Process、Criterion & Work Product)81 介紹(Introduction)1.1 目的(Purpose)為規(guī)范項目或產(chǎn)品發(fā)布的步驟和方法，特制定此子過程。1.2 參考資料(References)CMMI-SW, V1.1, Staged Representation，CMU/SEI-2002-TR-0291.3 術語(Abb. & Glossary Commentation)術語說明CMConfiguration Management，配置管理。CCBConfiguration Control Board，配

4、置控制委員會QA Quality Assurance，質(zhì)量保證PMProject Manager，項目經(jīng)理2 總體概述(Process Overview)2.1 子過程目標(SubProcess Goals)管理發(fā)布過程，保持版本完整性和正確性。2.2 角色和職責(Roles and Responsibility)參見：(1) CM-過程-配置管理過程定義-1.0.doc。(2) 3.1,3.2章節(jié)中具體的職責描述。2.3 進入準則(Entry Criteria)項目經(jīng)理申請發(fā)布的配置項所有變更均已完成并得到驗證；產(chǎn)品經(jīng)過測試或正式評審，符合發(fā)布的時機和準則；受控庫所有的配置項均已check

5、in；2.4 輸入(Output)輸入具體要求發(fā)布申請單2.5 總體流程圖(GeneralFlow)2.6 輸出(Input)輸出具體要求產(chǎn)品/項目發(fā)布申請單被批準了的申請單產(chǎn)品發(fā)布公告Mail或網(wǎng)絡其他方式2.7 退出準則(Exit Criteria)產(chǎn)品發(fā)布，并通知相關人員。3 活動描述(Activity Description)3.1 過程版本發(fā)布控制3.1.1 活動流程圖(Activity Flow)3.1.2 活動描述活 動參與者活動描述發(fā)布申請(發(fā)布前)項目經(jīng)理方式一：項目經(jīng)理確定發(fā)布時機、發(fā)布時間、發(fā)布頻次，通知CM開始發(fā)布并要求開發(fā)人員將此次發(fā)布相關文件提交入庫；(首次需提交申

6、請單，見CM-模板-發(fā)布申請單-1.0，以后可用BQQ或其它形式通知)。方式二：項目經(jīng)理和CM約定，定期(例如：每天一次、每兩天一次)或事件驅(qū)動（例如需求變更實現(xiàn)后等）發(fā)布。工作成果入庫(發(fā)布前)開發(fā)人員提交入庫：接到項目經(jīng)理的開始發(fā)布信息后及時將本階段的工作成果提交入庫。發(fā)布審批、執(zhí)行發(fā)布(發(fā)布中)CM工程師1. 核 實：CM根據(jù)PM的申請和要求，再次提醒開發(fā)人員提交代碼入庫，確認后，取得最新的源程序；2. 控制權限：CM根據(jù)項目的實際情況，與項目經(jīng)理確認每次發(fā)布時是否停止開發(fā)人員修改的權限；3. 打標簽：CM對獲得的最新源程序打標簽進行標識，并把做過標識的新版本存儲路徑發(fā)給編譯人員；標識的

7、規(guī)則見CM-規(guī)范-配置項標識規(guī)范-1.0；4. 通知測試：CM得到編譯/部署人員的信息后，把測試環(huán)境的相關路徑發(fā)給測試組相關人員；5. 開通權限：若在步驟2控制了權限此時需要開通，若沒有控制此步驟省去；6. 備 份：把編譯后的包、此次發(fā)布更改的內(nèi)容及影響到相關系統(tǒng)、數(shù)據(jù)庫信息等進行記錄和備份、記錄到項目版本發(fā)布信息；7. 記錄測試結果：測試完成后，應返回一個測試結果即版本級別(初始版、已編譯版、已測試版、拒絕版、推薦使用版、正式對外發(fā)布版)，由CM一并記錄備案到項目版本發(fā)布信息。編譯、布署(發(fā)布中)項目經(jīng)理或指定人員1. 編 譯：從CM指定的路徑獲得發(fā)布的最新版本，進行編譯打包；2. 部 署1

8、：把編譯后的文件部署到開發(fā)環(huán)境，項目經(jīng)理確認是否成功，成功轉(zhuǎn)3；若不成功重新編譯/打包/部署；3. 部 署2：把編譯后的包部署到測試環(huán)境中；4. 告 知CM：部署完畢后，把部署到測試環(huán)境的路徑、此次發(fā)布更改的內(nèi)容及有修改的相關系統(tǒng)信息告知CM。測試(發(fā)布后)測試工程師1. 測試：收到CM的版本發(fā)布完畢通知后，在指定的測試環(huán)境下開始新版本的軟件測試；2. 反饋：當一個版本測試完成應把測試結果反饋給CM，以便記錄。3.2 最終產(chǎn)品發(fā)布控制3.2.1 活動流程圖(Activity Flow)無。3.2.2 活動描述活 動參與者活動描述發(fā)布申請項目經(jīng)理項目經(jīng)理提交產(chǎn)品/項目發(fā)布申請，詳細說明要求發(fā)布時

9、間、內(nèi)容、版本及發(fā)布準備情況。發(fā)布審批CCB1. 檢 查：CM工程師參照發(fā)布申請信息對發(fā)布對象進行檢查。檢查發(fā)現(xiàn)的問題需與項目經(jīng)理溝通并記錄處理結果。并填寫版本發(fā)布歷史。2. 產(chǎn)品構建：集成負責人從CM工程師提供的基線庫路徑提取相應內(nèi)容，編繹打包，組成可交付的產(chǎn)品。3. 審 計：PPQA工程師審計待發(fā)布的產(chǎn)品與產(chǎn)品發(fā)布申請、產(chǎn)品發(fā)布公告以及與需求、計劃、標準等的一致性和產(chǎn)品的規(guī)范性。4. 意見收集：CCB其他成員參照CM工程師及PPQA工程師的檢查結果及意見，分別發(fā)表審批意見。5. 審批結論：CCBLeader綜合大家的意見，并最終決策，若批準發(fā)布，則繼續(xù)活動3；若拒絕發(fā)布，則將結果和原因通知相關人員。執(zhí)行發(fā)布CM工程師項目經(jīng)理1. 交付通知：項目經(jīng)理交付產(chǎn)品，并將正式發(fā)布結果通知項目相關人員。2. 配置審計：CM工程師根據(jù)產(chǎn)品發(fā)布清單進行全面的配置審計，并填寫配置狀態(tài)報告。3.