在軟件開發這個龐大而復雜的過程中，需求涉及到各方面的人員，信息的交流反饋不僅僅是研發小組成員之間及各個研發小組之間，還存在于客戶與研發著之間。所有的這些交流反饋意見信息都有可能導致對軟件的修改，小的可能只是對某個源文件中的某個變量的定義的改動，大到重新設計程序模塊甚至可能是整個需求分析變動。在整個軟件生命周期中，會形成眾多的版本，但誰也不敢百分百保證不出現錯誤的修改。版本管理條例，不僅是對源代碼的版本進行管理，而且還要對整個項目進行管理。
公司很早就引進 Microsoft 公司的 Visual SourceSafe 6.0 ( VSS )版本管理產品進行版本管理。但在使用過程中，存在一定的問題，特別是在項目處于維護階段時的版本管理不盡人意，經常出現反復的問題。因此，在實行 VSS 上的管理的基礎上，特制定企業方案事業部版本管理條例，重點是減少由于版本管理不善而造成的錯誤。
1. 開發階段版本管理條例
1.1數據庫、源碼和 jsp 頁面的一致性問題
在開發階段，數據庫、源碼和 JSP 可能會有團隊中不同的成員進行的修改，經常會出現不一致。必須嚴格執行如下規定：
1. 對涉及與其他共用的數據庫、源碼和 JSP ，除遵守項目組的約束外，必須在 check out 下的文件進行修改，并避免長時間不 check in ;
2. 對涉及與其他共用的數據庫、源碼和 JSP check out 、 check in 必須要有注釋;
1.2 用戶對需要的變更
在得到用戶簽字確認的需求文檔后，在開發階段，對用戶提出的需求，必須執行如下規定：
1. 修改工作量不大，用戶提出的需求不會出現反復的情況下，盡量滿足用戶的要求，但必須有書面記錄，并上傳到 VSS 上;
2. 修改工作量較大，或者是工作量不大，但會容易出現反復，如進行修改，則必須得到用戶負責人的簽字確認或郵件確認，不管是否修改，都必須有書面記錄，上傳到 VSS 上，并打印到紙質文檔中保管;
3. 對修改工作量大，除執行上面規定外，還必須用郵件等方式知會到項目經理、部門經理以及相關人員;
4. 對在后期提出的需求，涉及數據庫或者源程序的大量修改，盡可能不作修改;
1.3 開業人員對需求的變更
在得到用戶簽字確認的需求文檔后，在開發階段，如在技術上或者工作量等方面由開發人員提出的需求變更，必須執行如下規定：
1. 對在需求文檔范圍內，縮小需求范圍的需求變更，必須得到用戶負責人的簽字確認或郵件確認，并形成文檔，上傳到 VSS 上
2. 對可能影響回款，用戶驗收意見等的需求變更，必須用戶公章，還必須用郵件等方式知會到項目經理、部門經理以及相關人員;
2. 維護階段版本管理條例
2.1 維護管理必備資料
項目在用戶驗收后，進行系統維護期，必須具備如下資料：
1. 由項目經理編寫竣工資料;
2. 由項目盡量與測試組中共同編寫維護規定;
3. 用戶驗收運行環境及數據庫備份;
2.2 用戶問題反饋
用戶反饋的問題，屬于軟件質量范圍內的問題，統一提交到測試組中。對用戶反饋的問題，必須執行如下規定：
1. 對確認的缺陷，必須按需求變更、完善系統方式進行分類， OA 問題、業務問題(可細分到子模塊中)，并記錄到 XX 項目缺陷 .xls 的表“最新 BUG 報告”中，并上傳到 VSS 上;
2. 測試組通知項目經理，項目經理從 VSS 上取“最新 BUG 報告”(強制要求行為)，確認哪些內容是需要修改的，并在“最新 BUG 報告”上填寫修改人，解決時間;對屬 OA 問題，由項目經理整理到“ OA 缺陷提交報告”中，并與電子政務協調修改;
2.3 修改人員管理
為了避免同一個問題反復出現，源代碼在經過多人修改后，無人相信 VSS 的局面，修改過程中必須如下規定：
1. 從 VSS 上獲取用戶最新的運行環境;
2. 對修改內容必須從 VSS 上 check out ;
3. 對不執行 check out 而造成的對他人修改的影響，罰款 100 元作為項目活動經費;
4. 缺陷修改完，必須將所修改的內容 check in 到 VSS 上，制定修改清單，清單中必須說明經編譯后的類文件的路徑;
5. 從新從 VSS 上獲取最新的運行環境，根據修改清單對開發環境進行升級;
6. 將修改清單提交到測試組中;
2.4 測試組測試
1. 在修改內容的文件夾下，建立以修改日期命名的文件夾;在修改結果的文件夾下，建立以修改日期命名的文件夾;
2. 根據清單，從 VSS 上取得相應的文件 ，并將寫上當日修改日志，總的修改日志;
3. 利用 Ant 將 *.java 編譯成 *.class 文件;
4. 將 *.class ，將文件復制到 jar 包及 classess 的目錄下，將其他文件復制到相應目錄下，在修改的修改日期文件下夾應該只有一個 public.war 文件夾， jar 包， * 。 sql 文件，并將寫上當日修改日志，總的修改日志;
5. 從新從 VSS 上獲取最新的運行環境;
6. 根據修改結果步驟，在對內服務器對應的應用上進行升級;
7. 還原數據庫，測試，如有問題，返回修改人員進一步修改，重復上述步驟 ;如開發人員提供的修改清單名稱錯誤超過兩次，罰款 100 元作為項目活動經費;
8. 如無問題，則將修改結果整理到用戶升級文件中，提交給項目經理;
9. 測試組將“最新 BUG 報告”中修改確認正確的缺陷轉到已修改 BUG 報告，并將內容上傳到 VSS 上;
2.5 升級及備份
1. 項目經理收到測試組提交的用戶升級文件后，根據項目作進一步檢查;
2. 項目經理聯系用戶負責人進行升級，填寫升級記錄，并將與用戶交流的電子郵件等上傳到 VSS 上;
3. 升級后，應將用戶環境、數據庫進行備份，如情況不允許，應將對內服務器的對應的環境盡心備份，將部分內容上傳到 VSS 上;用戶環境應是不包括附件外的所有環境;
4. 過一段時間后，與用戶聯系，確認缺陷是否解決!
