【導讀】軟件配置管理規(guī)范。中山森創(chuàng)信息技術(shù)有限公司文件編號STD-ZS-KF-2020-001版本/修改A/0. ©版權(quán)所有，未經(jīng)雙方許可不得復制或?qū)ν鈧鏖?

　　

【正文】 務功能的增改編幅或重要性均微小。 版本號的起始標識為： VER 版本號的變動：根據(jù)其實際情況選擇相應位置的數(shù)值加 1，并將該位置右邊的所有數(shù)值置 0。如果在同一次的修訂中，同時出現(xiàn)兩個或以上位置的數(shù)值都符合改變的情況時，只需按照符合條件的最左位的數(shù)值加 1，并將該位置右邊的所有數(shù)值置 0。如果后兩個數(shù)字同時為 0 時，可以同時省去。 例如： VER VER VER VER VER VER VER VER VER 定版的具體操作方法 每個項目必須有一份《版本記錄表》。當需要生成一個測試版本時，填寫測試版本一欄信息。當某一個測試版本通過了測試，有條件生成一個版本時，在該測試版本所對應的一行中填上版本一欄信息。當某一個版本需要發(fā)布，在該版本所 對應的一行中填上發(fā)布一欄信息測試版本號和版本號均由項目配置管理員與項目經(jīng)理協(xié)商，在項目經(jīng)理同意下制定。 版本號欄可根據(jù)實際情況填寫，發(fā)布版本號為空。 版本類型欄選擇填寫以下之一：測試版本、版本、發(fā)布。 對于測試版本的注釋欄填寫該測試版本與上一測試版本的不同之處，對于版本的注釋欄填寫該版本對應的測試版本號以及與上一版本的不同之處，對于發(fā)布的注釋欄填寫該版本發(fā)布對應的版本號以及對生產(chǎn)的影響等情況。 項目負責人欄電子文檔填寫項目負責人姓名，紙質(zhì)文件由項目負責人簽名。 配置管理員欄電子文檔填寫項目配置管理員姓名，紙 質(zhì)文件由項目配置管理員簽名。 其他相關(guān)人員欄如有需要電子文檔填寫其他相關(guān)人員姓名，紙質(zhì)文件由其他相關(guān)人員簽名。其他相關(guān)人員如公司經(jīng)理。 項目配置管理員負責填寫《版本記錄表》，并對 VSS 庫中的源代碼加上版本號并填上注釋。 軟件配置管理規(guī)范 STDZSKF2020003 20/24 版本記錄表 項目名稱： 序號 版本號 定版日期 版本類型 注釋 項目負責人 配置管理員 其他相關(guān)人員 在 VSS 上定版的具體操作方法 在 VSS 上，可以通過加 Lable 的功能實現(xiàn)對系統(tǒng)中所有的源代碼文件進行加版本號的管理。 當需要加測試版本號 是，選擇所有源代碼的最高一級目錄，為其加上 Lable， Lable 為： （ 為具體的測試版本號），并在 Comment 中填上該測試版的定版日期和注釋。操作完成后， VSS 對該目錄一下的所有子目錄及文件均加上相同的 Lable 和 Comment。 當需要加版本號時，選擇所有源代碼的最高一級目錄，按右鍵并選擇顯示歷史信息，然后在信息中選中標有該版本對應的測試版本號的 Lable，雙擊。在回顯框上，修改 Lable，加上當前的版本號，修改后的 Lable 為： － （ 為具體的測試版本號 , 體的版本號），并在 LableComment 中填上該版本的定版日期和注釋。操作完成后， VSS對該目錄一下的所有子目錄及文件均改為相同的 Lable 和 LableComment。 當某一版本需要發(fā)布時，按上述操作，選擇對應的 Lable，并在相應的 LableComment 中加上發(fā)布日期及注釋。 版本發(fā)布流程 軟件配置管理規(guī)范 STDZSKF2020003 21/24 項目組軟件版本發(fā)布流程如下圖所示： 序號 流程 責任人 相關(guān)人員 文件 /記錄 說明 A01 開 始A 0 1 提 交 版 本 發(fā) 布 申 請A 0 2 審 核 版 本 發(fā) 布 申 請A 0 3 版 本 交 付是 否 需 要 業(yè) 務部 門 驗 證 測 試A 0 4 業(yè) 務 驗 證 測 試 通 知是A 0 5 版 本 安 裝 技 術(shù) 支 持否A 0 6 業(yè) 務 驗 證 測 試A 0 7 系 統(tǒng) 運 行 技 術(shù) 支 持A 0 8 保 存 版 本結(jié) 束 配置管理員 配置管理員 、軟件開發(fā)人員 《 用戶測試報告》、開發(fā)、維護文檔、《應用軟件版本發(fā)布申請表》 開發(fā)及維護文檔必須存放項目配置庫中 A02 各項目部門負責人、局領(lǐng)導 項目經(jīng)理、開發(fā)人員 《應用軟件版本發(fā)布申請表》 嚴格審核出部門、公司的技術(shù)文檔。 A03 配置管理員、 相關(guān)部門 項目經(jīng)理 軟件版本、技術(shù) 資料 A04 軟件接收部門 開發(fā)人員 書面通知書 內(nèi)容包括：版本發(fā)布原因、版本業(yè)務功 能、安裝時間、影響范圍、安裝后業(yè)務驗證內(nèi)容 A05 項目負責人 開發(fā)人員 必要時提供現(xiàn)場技術(shù)支持。 A06 用戶、測試組 開發(fā)人員 業(yè)務驗證測試報告 根據(jù)需要進行 A07 項目負責人 維護人員、開發(fā)人員 必要時現(xiàn)場技術(shù)支持 A08 配置管理員 綜合人員 光盤 可備份配置庫時進行備份 版本保存 配置管理員必須保證發(fā)布版本源程序的完整性及一致性，質(zhì)量保證人員保證發(fā)布版本的文檔的完整性，配置經(jīng)理及對每一次發(fā)布的版本，在配置庫中對應地建立版本標識，隨配置庫備份刻錄光盤時，交綜合人員登記并永久保存，綜合人員應在光盤標簽上標注光盤內(nèi)容、 備份時間 、提交人員，以便查閱。對光盤的查閱必須經(jīng)部門負責人同意。 軟件配置管理規(guī)范 STDZSKF2020003 22/24 11 公用程序庫的建立及維護 公用程序主要包括： ? 公用函數(shù)模塊：提供某一特定功能。 ? 公用類模塊：提供具有通用性的類的定義及方法實現(xiàn)。 ? 加密模塊：各項目組涉及加密的功能模塊由專人開發(fā)。 ? 自行開發(fā)實用工具：各項目組開發(fā)的實用工具。 ? 實現(xiàn)某一功能的完整程序；例如采用 SOCKET 的通訊程序。 ? 具有普遍實用的程序框架；例如 SCO UNIX 下終端程序框架。 ? 其他； 各項目組在項目開發(fā)過程中應注意提煉公用程序，共同建設好公用程序庫，為今后的項目開發(fā)省時省力。配置 經(jīng)理建立及維護公用程序庫，接受、審核公用程序，定期公布公用程序清單。項目負責人可以根據(jù)需要提出使用公用程序的申請，部門負責人審核同意后，配置經(jīng)理提供相應程序。 12 配置庫的安全管理 版本保存 項目負責人必須明確每個項目成員的操作權(quán)限，對配置項的永久刪除權(quán)限必須嚴格控制。 配置服務器的安全控制 配置經(jīng)理負責配置服務器的系統(tǒng)管理，不允許其他人登錄配置服務器進行操作。配置經(jīng)理必須做好配置服務器的病毒防范及網(wǎng)絡安全控制 。 配置庫備份 配置經(jīng)理負責進行配置庫的備份，主要有： 1) 每日備份 每日下班前，配置經(jīng)理備份配置庫中所有 配置項，每周循環(huán)。 軟件配置管理規(guī)范 STDZSKF2020003 23/24 2) 每月備份 配置經(jīng)理每月定期備份文件服務器的共享目錄及配置服務器中配置庫文件，刻錄光盤由綜合人員存放，填寫《配置庫備份登記表》。 配置管理平臺維護 配置經(jīng)理負責配置管理平臺的維護，填寫《開發(fā)部配置管理平臺維護日志》、《配置管理平臺信息表》，具體包括： ? 建立項目配置庫； ? 維護相關(guān)人員的權(quán)限： ? 系統(tǒng)軟件升級； ? 病毒防范； ? 系統(tǒng)資源維護； 13 工作空間管理 整個配置庫是一個統(tǒng)一的工作空間，可以進一步劃分為個人空間、項目組空間和共享空間這三類工作空間。個人空間是開發(fā)人員的私有工作空間，開發(fā)人員在自己的 個人空間進行開發(fā)活動，不會受到他人的影響，也不會影響到其他開發(fā)人員，在個人開發(fā)空間開發(fā)出的成果，最終提交到項目組空間中。項目組空間是開發(fā)團隊的成果空間以及團隊共享空間，對項目組空間的配置項的操作，配置管理員必須做好權(quán)限控制及協(xié)調(diào)管理。共享工作空間是項目組中子項目組共同工作的空間，子項目組成員擁有對該空間的讀寫權(quán)限。共享工作空間根據(jù)需要建立。 配置管理員及項目負責人必須做好工作空間的分配及管理。 14 變更文件的審批與確認 為了規(guī)范化管理，明確責任，避免風險，項目組要做好變更文件的審批與確認工作。 規(guī)定每個項目一本 《變更文件審批與確認登記表》，在項目啟動時由項目經(jīng)理負責建立，填寫好項目名稱和相關(guān)職責人員姓名。 軟件配置管理規(guī)范 STDZSKF2020003 24/24 在項目開發(fā)生命周期內(nèi)，由項目組配置代表管理，不得遺失和毀壞。 屬于下列情況之一者，必須有相關(guān)人員在《變更文件審批與確認登記表》上簽字： ? 項目的各項計劃的制定需要主管部門經(jīng)理審批，并得到相關(guān)部門、相關(guān)組或客戶的確認。 ? 對用戶需求進行分析整理而成的文檔需要經(jīng)過相關(guān)組和部門的確認，并得到用戶的認可。 ? 各個階段的技術(shù)文檔要得到相關(guān)組和個人的認可。 ? 項目組內(nèi)所有的變更要得到項目經(jīng)理的認可。 ? 涉及到資源、約定的變更要得到主 管部門經(jīng)理的批準，并和相關(guān)部門進行協(xié)調(diào)確認。 ? 所有的變更要通知所有受影響的組和個人。 ? 工作產(chǎn)品交接需要相關(guān)人員確認。 ? 工作匯報或狀態(tài)報告需要上級主管確認。 凡簽名者，均對相關(guān)內(nèi)容負責，包括風險、保密和責任等方面。如果不能承擔責任者，則需要報送高一級經(jīng)理批準。 簽名者必須用黑色墨水筆認真書寫自己真實、完整的姓名，不得隨意涂改。 在項目交付完成后，將《變更文件審批與確認登記表》交開發(fā)部綜合人員歸檔保存。 （完）