3 實施細則
3.1 成立ccb小組
在專案發啟後由專案經理或高層經理組織成立ccb小組。
ccb成員人數在3～8人範圍內（具體組成視實際情況而定），一般包括：
1) 專案經理pm；
2) 專案總監
3) 高層經理
4) 組織級cm；
5) qa人員；
6) 測試主管；
7) 顧客代表；
8) 開發主管等。
ccb小組的決策原則：尋求ccb成員的一致意見。若不能達成一致，可採取由顧客代表做出決策；或採取少數服從多數的原則，由ccb成員投票確定，投票超過半數即為通過。
3.2 配置管理人員確定
在專案發啟時，由專案總監確定該專案組織級cm，負責專案配置計畫的制定和整體專案的配置管理。
3.3 制定配置管理計畫
3.3.1 配置管理計畫的約束條件
1） 配置管理計畫必須以專案開展的工作為基礎；
2） 配置管理計畫的編寫必須以公司的流程為模版，與專案開發計畫、質量保證計畫以及度量計畫相一致；
3） 配置管理計畫能夠指導未來的配置管理工作，配置管理工作必須以配置管理計畫為基準；
4） 配置管理計畫必須經過最終的評審通過，才能夠發布；
5） 如配置管理計畫不能滿足未來配置管理工作的需要，可以再增加配置管理工作計畫作為配置管理計畫的輔助，指導未來的配置管理工作。
3.3.2 編制配置管理計畫
1） 制定計畫
在專案立項初期，組織級cm要參考專案計畫書並與相關人員協商制定配置管理計畫，規劃未來的配置管理工作，通常情況下，由組織級cm在專案計畫書完成後，開始編制《配置管理計畫》；如有特殊需要，根據合同或專案要求，由組織級cm在某一專案或專案的某一階段開始前制定《配置管理計畫》。
《配置管理計畫》應包括以下方面的內容：
a. 實施配置管理的相關責任人、組織及其職責；
b. 配置管理需要的軟硬體環境；
c. 開發工具和方法；
d. 配置項計畫和基線計畫以及其進度安排，立項初期組織級cm要和專案經理討論，確定出專案的配置項，並確定基線的組成和發布時間點。
e. 配置庫備份計畫。
2） 規範配置管理環境
配置管理計畫制定結束後，組織級cm要依據計畫實施配置管理的前期工作。首先必須規範配置管理的環境，實現專案組內的專機專用，與專案經理協商，開發用機、測試用機、配置用機的情況，並最終生成配置管理環境維護清單，便於後期對環境的維護。
3） 確定配置項的範圍
ccb成立後，由ccb組織會議根據專案的開發計畫確定各個里程碑和開發策略，組織級cm負責整理確定的專案基線和配置項列表，並在編制《配置管理計畫》時列明，按約定的時機收集配置項和建立初始基線。結合公司專案目前的情況，過程中主要的配置項包括：
專案計畫：專案開發計畫，wbs計畫、風險管理計畫、質量保證計畫、配置管理計畫、總體測試計畫（依據專案的不同，或者還包括效能測試計畫）等；
需求階段：業務需求說明、業務藍圖、軟體需求說明，需求跟蹤矩陣、調研大綱、調研資料；
設計階段：設計文件（包括概要設計和詳細設計），模型設計、原型設計（包括資料庫、bi模型等）；
開發階段：程式源**、資料、可執行檔案、資料庫部分、介質（對於資料中心專案程式源**部分包括etl部分、cognos部分、框架部分等） 、工具、基準庫
測試階段：測試用例、測試計畫和測試資料、測試報告、測試方案、測試總結；
實施階段：實施計畫、實施方案、實施總結
發布階段：發布的程式版本（主要包括可執行程式和資料庫，其中可執行程式部分對於資料中心類專案主要包括etl部分、bi部分和程式，資料庫部分主要包括資料庫和增量資料，屬於該階段的配置項還應該包括使用者文件，但是把使用者的文件作為專案的管理文件進行管理，組內的配置管理人員對此不做管理）；
其餘的配置項包括：會議紀要、專案週報、風險記錄、專案計畫、培訓記錄、會議紀要、質量保證過程文件等。
3.3.3 審批配置管理計畫
《配置管理計畫》的由專案經理負責審批、給出審批意見，審批未通過必須由組織級cm重新編寫，直到審批通過為止。
3.4 配置庫的建立
所有專案應建立配置庫，以便管理各配置項，組織級cm負責組織建立配置庫。配置庫統一由組織級cm管理，根據各開發階段的實際情況定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。
3.4.1配置項標識要求
合同有明確標識和追蹤要求時，由相關人員按合同要求進行標識，以保證滿足合同追蹤要求。
在開發過程中由專案組人員提交的配置項，由專案組人員按照標識規則進行標識。
專案組人員將要標識或已標識的配置項提交給組織級cm納入配置庫統一管理，組織級cm做好配置項管理記錄，並填寫詳細的備註資訊。
3.4.2配置項標識規則
1. 專案命名
產品標識是在專案開始立項時就確定下來的，由專案管理部門分配的，根據組織內當年專案的先後順序，依次產生。
1) 專案的名稱由客戶和開發部門協商確定，一般以專案所實現的系統功能來命名。
2) 專案編號則用代號表示為：「aa-bbbb-xxyyyy-zz」。各符號位的含義如下：
「aa」為客戶所在省份，如陝西為「sx」
「bbbb」為客戶單位名稱，2~4皆可。
「xx」為產品類別號，用兩位英文本母表示，在產品產生的過程中定義，按產品分類（生產類（sc），辦公自動化（oa），資料中心（dc），企業門戶（ep），服務外包（fw），檔案（da））。
「yyyy」為專案立項年份代號，用四位數字表示。例如，2023年記為「2001」。
「zz」為順序號，用兩位數字表示：「01~99」。按立項的先後順序編號。
示例：sx-dl-ep2009-02為2023年第02號專案為陝西電力的企業門戶專案。
2. 檔案標識
檔案標識主要由三部分組成：專案名稱（英文本母縮寫）+檔名稱（英文本母縮寫）+版本號，其表現形式為：中文檔名（專案名稱（英文本母縮寫）_檔名稱（英文本母縮寫），版本資訊在檔案內的版本說明中進行體現。舉例：寧夏資料中心二期建設專案需求規格說明書（nxdl_dc_sr），其版本號在文件內部的版本記錄中表現。
3.5 管理配置庫
3.5.1 配置庫目錄結構
svn配置庫主要分為**區和文件區兩個部分。其中，**區包括：開發區、構建區、測試區和發布區。文件區分為：個人工作區、緩衝區、基線區和管理文件區。上述區域由組織級cm統一管理，根據各開發階段的實際情況定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進
3.5.1.1 **區
編碼區：**區的編碼區對應的是開發團隊的公共空間。凡是要為同組人員共享的配置項都從該分支獲得。即各開發人員必須將私有工作空間中的開發成果歸併（merge）到該分支後才能進入下乙個開發活動。所有涉及多人協調的開發工作（如整合測試等）都必須工作在這一空間中。該開發團隊擁有對該整合分支的讀寫許可權，而其他成員只有唯讀許可權。該分支的管理工作由專案級cm及相關指定人員負責。
構建區：構建區是專案級cm的工作空間，只有專案級cm對該區有讀寫許可權， 組織級cm和qa人員該區有唯讀許可權，專案組其他人員無權操作。該區域主要是對送測程式進行產品整合並對程式原始碼按版本進行備份（如：系統的乙個大的模組）。
測試區：測試區也是專案級cm的工作空間，只有專案級cm對該區有讀寫許可權， 組織級cm、qa人員、測試人員對該區有唯讀許可權。專案級cm將整合好的程式進行編譯後，提交到測試區以供測試人員對程式進行驗證。（該區域不包含程式的源**）
發布區：組織級cm對該區有讀寫許可權，qa人員、實施人員對該區有唯讀權。即該區域儲存通過測試驗證並正式發布的程式檔案。每次發布組織級cm要對發布的程式進行版本控制，並向專案組傳送產品發布通知。
3.5.1.2 文件區
個人工作區：**區的個人工作區對應的是專案組成員的私有開發空間。專案組成員根據任務分工獲得對相應配置項的操作許可之後，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有空間上的版本的推進，除該專案組成員以及組織級cm外，其他人員均無權操作該私有空間中的元素。
快取區：主要用於放置專案過程中的各個階段（包括：需求階段、設計階段、測試階段、實施階段）產生了的一些臨時性文件，如需求階段需求人員收集的一些和使用者需求相關的資料、業務需求說明書、需求規格說明書（未經過評審或在建立、修改過程中）。緩衝區由組織級cm授權的相應人員進行相關操作，具體操作許可權可見3.5.2配置庫各目錄許可權說明。
基線區：基線區是整個svn配置庫管理的重點，只有組織級cm有寫入許可權，專案組其他人員有可讀許可權。基線區存放軟體生命週期各個階段產生的重要工作產品，基線區的配置項是一般是穩定版本或者趨於穩定的產品版本，不能輕易變更，如需要變更，必須走變更流程（可參見3.7變更控制）。
管理文件區：管理文件區主要用來存放軟體開發過程中，產生的管理文件或支援文件，包括：計畫、週報、評審記錄、會議紀要、風險記錄、出差記錄、配置記錄、質量保證等工作產品。該區域同基線區一樣只有組織級cm有寫入許可權，專案組其他人員有可讀許可權。
翻譯活動實施細則（拋磚稿）
翻譯活動實施細則 一 活動成果用途 作為社群貢獻提供給qt社群，以及廣大的qt愛好者使用者免費使用。二 參加人員職責 1 翻譯貢獻 貢獻者 願意了解qt有英文基礎 將認領頁面翻譯為中文 強烈不建議用機器翻譯 盡量保持和英文頁面的格式一致 統計所翻譯部分的詞數 英文 及時提交校對審查 2 校對編輯 校...
描述不符的認定和處罰的規則與實施細則
規則解讀 一 達成交易時是指什麼時候？指買家拍下商品的時候。二 商品瑕疵怎麼理解?是指不影響商品本身功能和質量的小缺陷 例如 如衣服上的個別跳線 三 附帶品指什麼？指產品包裝清單中所列的所有物品。四 為什麼賣家要對商品瑕疵 保質期 附帶品等必須說明的資訊進行披露？賣家對商品瑕疵 保質期 附帶品等資訊...
快手電商修訂服務違規實施細則 處罰更嚴了
程式設計客棧 www.cp程式設計客棧pcns.com 1月12日 訊息 日前，快手電商發布公告稱，將對 服務違規 實施細則 商戶 服務違規 實施細則 跨境 進行修訂，修訂後的規程式設計客棧則均將於 2022 年 1 月 19 日生效。針對 服務違規ecpobhvpjj 實施細則 商戶 具體修訂內容...