計算機等級考試三級信息管理：版本管理條例

　　在軟件開發(fā)這個龐大而復(fù)雜的過程中，需求涉及到各方面的人員，信息的交流反饋不僅僅是研發(fā)小組成員之間及各個研發(fā)小組之間，還存在于客戶與研發(fā)著之間。所有的這些交流反饋意見信息都有可能導(dǎo)致對軟件的修改，小的可能只是對某個源文件中的某個變量的定義的改動，大到重新設(shè)計程序模塊甚至可能是整個需求分析變動。在整個軟件生命周期中，會形成眾多的版本，但誰也不敢百分百保證不出現(xiàn)錯誤的修改。版本管理條例，不僅是對源代碼的版本進行管理，而且還要對整個項目進行管理。

　　公司很早就引進 Microsoft 公司的 Visual SourceSafe 6.0 ( VSS )版本管理產(chǎn)品進行版本管理。但在使用過程中，存在一定的問題，特別是在項目處于維護階段時的版本管理不盡人意，經(jīng)常出現(xiàn)反復(fù)的問題。因此，在實行 VSS 上的管理的基礎(chǔ)上，特制定企業(yè)方案事業(yè)部版本管理條例，重點是減少由于版本管理不善而造成的錯誤。

　　1. 開發(fā)階段版本管理條例

　　1.1數(shù)據(jù)庫、源碼和 jsp 頁面的一致性問題

　　在開發(fā)階段，數(shù)據(jù)庫、源碼和 JSP 可能會有團隊中不同的成員進行的修改，經(jīng)常會出現(xiàn)不一致。必須嚴(yán)格執(zhí)行如下規(guī)定：

　　1. 對涉及與其他共用的數(shù)據(jù)庫、源碼和 JSP ，除遵守項目組的約束外，必須在 check out 下的文件進行修改，并避免長時間不 check in ;

　　2. 對涉及與其他共用的數(shù)據(jù)庫、源碼和 JSP check out 、 check in 必須要有注釋;

　　1.2 用戶對需要的變更

　　在得到用戶簽字確認(rèn)的需求文檔后，在開發(fā)階段，對用戶提出的需求，必須執(zhí)行如下規(guī)定：

　　1. 修改工作量不大，用戶提出的需求不會出現(xiàn)反復(fù)的情況下，盡量滿足用戶的要求，但必須有書面記錄，并上傳到 VSS 上;

　　2. 修改工作量較大，或者是工作量不大，但會容易出現(xiàn)反復(fù)，如進行修改，則必須得到用戶負(fù)責(zé)人的簽字確認(rèn)或郵件確認(rèn)，不管是否修改，都必須有書面記錄，上傳到 VSS 上，并打印到紙質(zhì)文檔中保管;

　　3. 對修改工作量大，除執(zhí)行上面規(guī)定外，還必須用郵件等方式知會到項目經(jīng)理、部門經(jīng)理以及相關(guān)人員;

　　4. 對在后期提出的需求，涉及數(shù)據(jù)庫或者源程序的大量修改，盡可能不作修改;

　　1.3 開業(yè)人員對需求的變更

　　在得到用戶簽字確認(rèn)的需求文檔后，在開發(fā)階段，如在技術(shù)上或者工作量等方面由開發(fā)人員提出的需求變更，必須執(zhí)行如下規(guī)定：

　　1. 對在需求文檔范圍內(nèi)，縮小需求范圍的需求變更，必須得到用戶負(fù)責(zé)人的簽字確認(rèn)或郵件確認(rèn)，并形成文檔，上傳到 VSS 上

　　2. 對可能影響回款，用戶驗收意見等的需求變更，必須用戶公章，還必須用郵件等方式知會到項目經(jīng)理、部門經(jīng)理以及相關(guān)人員;

　　2. 維護階段版本管理條例

　　2.1 維護管理必備資料

　　項目在用戶驗收后，進行系統(tǒng)維護期，必須具備如下資料：

　　1. 由項目經(jīng)理編寫竣工資料;

　　2. 由項目盡量與測試組中共同編寫維護規(guī)定;

　　3. 用戶驗收運行環(huán)境及數(shù)據(jù)庫備份;

　　2.2 用戶問題反饋

　　用戶反饋的問題，屬于軟件質(zhì)量范圍內(nèi)的問題，統(tǒng)一提交到測試組中。對用戶反饋的問題，必須執(zhí)行如下規(guī)定：

　　1. 對確認(rèn)的缺陷，必須按需求變更、完善系統(tǒng)方式進行分類， OA 問題、業(yè)務(wù)問題(可細(xì)分到子模塊中)，并記錄到 XX 項目缺陷 .xls 的表“最新 BUG 報告”中，并上傳到 VSS 上;

　　2. 測試組通知項目經(jīng)理，項目經(jīng)理從 VSS 上取“最新 BUG 報告”(強制要求行為)，確認(rèn)哪些內(nèi)容是需要修改的，并在“最新 BUG 報告”上填寫修改人，解決時間;對屬 OA 問題，由項目經(jīng)理整理到“ OA 缺陷提交報告”中，并與電子政務(wù)協(xié)調(diào)修改;

　　2.3 修改人員管理

　　為了避免同一個問題反復(fù)出現(xiàn)，源代碼在經(jīng)過多人修改后，無人相信 VSS 的局面，修改過程中必須如下規(guī)定：

　　1. 從 VSS 上獲取用戶最新的運行環(huán)境;

　　2. 對修改內(nèi)容必須從 VSS 上 check out ;

　　3. 對不執(zhí)行 check out 而造成的對他人修改的影響，罰款 100 元作為項目活動經(jīng)費;

　　4. 缺陷修改完，必須將所修改的內(nèi)容 check in 到 VSS 上，制定修改清單，清單中必須說明經(jīng)編譯后的類文件的路徑;

　　5. 從新從 VSS 上獲取最新的運行環(huán)境，根據(jù)修改清單對開發(fā)環(huán)境進行升級;

　　6. 將修改清單提交到測試組中;

　　2.4 測試組測試

　　1. 在修改內(nèi)容的文件夾下，建立以修改日期命名的文件夾;在修改結(jié)果的文件夾下，建立以修改日期命名的文件夾;

　　2. 根據(jù)清單，從 VSS 上取得相應(yīng)的文件 ，并將寫上當(dāng)日修改日志，總的修改日志;

　　3. 利用 Ant 將 *.java 編譯成 *.class 文件;

　　4. 將 *.class ，將文件復(fù)制到 jar 包及 classess 的目錄下，將其他文件復(fù)制到相應(yīng)目錄下，在修改的修改日期文件下夾應(yīng)該只有一個 public.war 文件夾， jar 包， * 。 sql 文件，并將寫上當(dāng)日修改日志，總的修改日志;

　　5. 從新從 VSS 上獲取最新的運行環(huán)境;

　　6. 根據(jù)修改結(jié)果步驟，在對內(nèi)服務(wù)器對應(yīng)的應(yīng)用上進行升級;

　　7. 還原數(shù)據(jù)庫，測試，如有問題，返回修改人員進一步修改，重復(fù)上述步驟 ;如開發(fā)人員提供的修改清單名稱錯誤超過兩次，罰款 100 元作為項目活動經(jīng)費;

　　8. 如無問題，則將修改結(jié)果整理到用戶升級文件中，提交給項目經(jīng)理;

　　9. 測試組將“最新 BUG 報告”中修改確認(rèn)正確的缺陷轉(zhuǎn)到已修改 BUG 報告，并將內(nèi)容上傳到 VSS 上;

　　2.5 升級及備份

　　1. 項目經(jīng)理收到測試組提交的用戶升級文件后，根據(jù)項目作進一步檢查;

　　2. 項目經(jīng)理聯(lián)系用戶負(fù)責(zé)人進行升級，填寫升級記錄，并將與用戶交流的電子郵件等上傳到 VSS 上;

　　3. 升級后，應(yīng)將用戶環(huán)境、數(shù)據(jù)庫進行備份，如情況不允許，應(yīng)將對內(nèi)服務(wù)器的對應(yīng)的環(huán)境盡心備份，將部分內(nèi)容上傳到 VSS 上;用戶環(huán)境應(yīng)是不包括附件外的所有環(huán)境;

　　4. 過一段時間后，與用戶聯(lián)系，確認(rèn)缺陷是否解決!