1、信息系統配置管理規范信息系統配置管理規范目錄1概述31.1. 目的31.2. 范圍31.3. 術語31.4. 角色與職責.32配置管理范圍43項目配置庫建立與使用.43.1 項目配置庫建立43.2 項目配置庫使用44權限變更55配置庫安全56配置庫使用規范6附錄一：配置項命名規則.7附錄二：配置庫目錄結構管理規定8附錄三：基線庫產品清單.9第9頁共10頁1概述1.1. 目的為了保證XXXX研發項目文件的安全性、機密性；保證信息系統的完整性、有效性及可追溯性，以及加強研發項目的協同能力，特制訂本制度。1.2. 范圍適用于本行所有信息系統。1.3. 術語術語描述信息系統配置管理是在信息系統項目開發

2、中，標識、控制和管理軟件變更的一種管理?；€是項目開發庫中每個文件版本在特定時期的一個快照”。它提供一個正式標準，隨后的工作基于此標準，并且只有經過授權后才能變更這個標準。建立一個初始基線后，以后每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。開發庫（devlib）存放開發過程中需要保留的各種信息，供開發人員個人專用。開發人員對其具有編輯、修改、刪除等操作權限?；€庫(baselib)開發庫中產品經過測試小組測試后，行成一個穩定的版本，由配置管理員從開發庫中將該版本提取出來，行成一個新的版本。以后的版本更新將在此基礎上進行更新。所有人員對基線庫的最大權限只能為只讀權限。L_1.4.

3、角色與職責角色職責項目經理確定配置項、確定配置庫目錄權限；審查配置庫艾更；項目開發過程中，監督配置庫使用情況；員，離職時，配置庫歸檔完整性審核。項目小組根據配置管理制度規范，進行配置庫的日常使用。配置管理員負責配置庫的建立、權限設置、負責培訓開發人員使用配置管理工具、對配置庫使用情況進行管理和監督、建立配置庫基線；定期備份配置庫；建立和完善配置管理制度。2配置管理范圍研發項目過程中產生的所有文檔，包括：研發項目管理文檔、研發設計及技術文檔、源代碼、可執行程序，工具及相關資料等。項目文檔主要：立項書、項目計劃、例會會議記錄及項目過程中管理類文檔等。設計及技術文檔主要：需求，需求分析報告、概要設計

4、說明書、詳細設計說明書、數據庫表結構、測試文檔、使用說明書、技術說明書等。工具及其相關資料：開發或測試過程中的工具，以及其使用文檔等，如覺得有必要也納入配置庫的管理。3項目配置庫建立與使用3.1 項目配置庫建立1 .項目立項時，由項目經理申請建立項目配置庫（附錄二X配置庫申請單）2 .配置管理員與項目經理根據配置管理的流程確定配置管理計劃。3 .配置項：項目經理與配置管理員共同確認研發項目的配置庫目錄結構，并建立配置庫目錄結構；所建配置庫目錄結構必需按本文規定目錄結構執行（目錄結構參考附錄二）。4 .項目小組：項目經理提供項目小組成員名單及聯系方式，配置庫權限清單（內容應包括員工姓名、目錄權限

5、等）5 .權限分配：配置管理員為相關人員的設置配置權限。配置庫權限設置完成之后，由配置管理員將配置庫名稱、訪問路徑、訪問權限等信息以郵件方式通知各相關人員；配置庫使用人員以各自的用戶名和密碼進行訪問配置庫。6 .配置庫密碼只能在服務器上設置，如配置庫使用人員密碼遺忘或需要修改，可以與配置管理員取得聯系，進行修改密碼。3.2 項目配置庫使用1 .配置庫目錄說明配置庫基本結構如"附錄二”所示.以項目名稱作為一級目錄，二級目錄包括：devlib、testlib、PMlib、baselib：“devlib”：項目小組日常研發活動區；該目錄包含docs（設計文檔）、src（代碼）目錄?！癙Ml

6、ib”：放項目管理文檔，為科研處項目管理部門和項目經理使用；“testlib”：項目小組在此目錄下記錄項目測試中的文檔，如內部測試、中試申請、中試報告、評審紀要?！癰aselib”：僅放置PLM發布版本，項目經理具有讀權限；開發人員在該目錄下不允許對源代碼等文件進行修改。2 .配置庫使用說明a） 項目開發小級在“devlib”進行日常開發活動。b） 項目經理在“PMlib”中記錄項目管理文檔。c） 項目進行到中試測試階段，由項目經理通過“branch/tag”（中文為：“分支府記”）的方式,將“devlib”在“testlib/測試版本”中建立版本分支。再由項目管理員從此庫中“導出”，并根據P

7、LM入庫相關的規定，通過PLM相關流程進行中試測試。中試測試過程中產生的文檔記錄在“testlib”相關目錄中。d）中試測試合格，科研處在進行對項目發布前，將“testlib/測試版本”中建立的版本分支在"baselib”建立發布版本分支。4權限變更使用配置庫的過程中需要變更配置庫管理權限，由項目經理填寫配置庫權限變更單，并以郵件方式通知配置管理員，配置管理員變更之后，將變更結果以電子郵件方式通知受影響的人員、項目經理及其相關人員。配置管理員根據配置庫權限變更頻率，每隔一段時間將配置庫權限清單與各項目經理進行審核確認。5配置庫安全配置服務器系統安全：配置管理員進行服務器的日常管理與維

8、護，做好防入侵、防病毒工作。配置庫備份：配置管理員定期做好配置庫的備份，以防意外，避免給公司帶來嚴重的損失。配置管理員每日進行硬盤備份一次，每周進行異地硬盤備份一次，每月進行光盤備份一次，備份后的光盤標記上備份日期并附上內容清單，移交公司相關部門保管。6配置庫使用規范1 .各項目必需使用科研處提供的配置管理環境建立配置管理庫。2 .配置管理員由科研處任命，科研處負責進行配置管理的管理工作。3 .所有立項的科研項目，都必須申請建立配置庫。開發過程中所有文檔和代碼必須納入配置庫管理。4 .配置庫服務器密碼只有配置管理員及科研處領導掌握。5 .各配置庫的使用人員必須使用各自的用戶名和密碼進入配置庫，

9、訪問各自的配置庫。各使用人員不得將自己的用戶名和密碼泄漏給其他人員，若因泄露密碼而引起的后果將由泄漏密碼者本人承擔。6 .項目組成員未經項目經理同意不得更改他人的文檔和代碼。各項目的配置庫用于項目組正式開發使用，項目組成員不得惡意對其進行修改、刪除、增加等操作；若因對配置工具不熟悉，需要學習，可以向配置管理員提出需求，由配置管理員為其提供可以練習的配置庫。7 .配置管理員負責定期檢查配置庫的使用情況，查看是否有員工進行無故刪除或惡意修改文件的行為；并對開發人員提交的文檔和代碼的及時性、準確性和完整性進行檢查。8 .在研發人員離職時，由其項目經理負責檢查配置庫，檢查該人員提交的代碼或文檔是否完全

10、放入配置庫管理，確認版本和相應文件完整無誤后，項目經理在“員工離職申請單”中簽字，該員工方可離職。同時項目經理應及時通知配置管理員，取消該人員的所有權限。若因項目經理審核不細致造成的代碼或文檔移交不完整，或項目經理未及時通知配置管理員取消權限，而造成的損失，該責任完全由項目經理承擔。9 .代碼提交原則(1)每次提交代碼前，先進行更新，以避免提交沖突。(2)代碼提交前，應對每個文件與前一版本進行比較，仔細查看差異之處，減少錯誤以及避免提交臨時代碼。(3)提交到配置管理中的代碼必須能正確編譯。常見的問題是創建了新文件，但沒有加到配置管理中，導致其它人更新代碼后編譯不過。(4)代碼提交前先使用代碼格

11、式化工具和代碼規范檢查工具處理。(5)原則上應在完成某個功能或函數的開發或修改之后，再提交代碼，避免提交功能不完整的代碼。(6)如果在修改了涉及多個子任務的多個文件后進行提交，最好按問題的相關性分成幾次進行提交，每次只提交單個子任務相關的文件并寫上注釋。附錄一：配置項命名規則配置項目命名基本要求：唯一性；可追溯性。1 .項目名稱命名規范：要求項目名稱不能太長，且必須要求使用該項目的英文縮寫命名。項目名稱中最好不出現空格，若有空格，在建立配置庫時，配置庫名中將以“_”來代替空格。2 .配置庫命名配置庫分為開發庫和基線庫。?項目的基線庫有多個，可以在其下建立各版本的基線庫，子基線庫命名規則為：項目

12、名稱縮寫+版本號_bas?若一個項目的開發庫有多個，可以在其下建立各版本的開發庫，子開發庫的命名規則為：項目名稱縮寫+版本號_dev3 .技術文檔命名：技術文檔的標識體現在相應文件的封面上，規范如下：文檔名稱+版本，由開發人員參照相應文檔模板的格式要求，對技術文檔進行標識。附錄二：配置庫目錄結構管理規定每一個項目的配置庫可分為devlib（開發庫）、testlib（測試庫）、PMlib（ProjectManagementLib項目管理庫）和baselib（基線庫或產品庫）；基線庫與開發庫結構相同，但基線庫和開發庫各自獨立，分開管理，其中基線庫只有配置管理員有操作權限，其他人員只有讀權限。每個項目的都按如下表目錄規則規劃，其中devlib、testlib、PMlib、baselib、docs、src目錄為必選項,其它目錄可以根據實際情況增減:一級目錄二級目錄三級目錄四級目錄部門代號_項目名稱版本號devlibdocs需求分析概要設計詳細設計數據庫結構技術規范產品相關資料使用說明書技術說明書鑒定文檔其它技術文檔src源代碼數據