軟件變更管理制度匯編（試行）

1、 軟件變更管理制度（試行）第一節(jié) 總則第一條 為規(guī)X軟件變更與維護管理，提高軟件管理水平，優(yōu)化軟件變更與維護管理流程，特制定本制度。第二條 軟件變更與維護管理主要包括一般性變更、緊急變更、用戶測試、版本控制、系統(tǒng)更新和權限管理等內容。第三條 本制度適用于中國鋁業(yè)股份某總部和各分子公司（含某研究院）（以下簡稱“公司”）。第二節(jié) 一般性變更流程第四條 需求部門提出系統(tǒng)變更需求，并將變更需求整理成變更申請書（附件三），由部門負責人審批后提交給信息部。第五條 信息部負責接受需求、分析需求，并提出系統(tǒng)變更建議。信息部負責人審批變更申請書。第六條 信息部根據自行開發(fā)、合作開發(fā)和外包開發(fā)的不同要求組織實現(xiàn)系

2、統(tǒng)變更需求，產生供發(fā)布的程序。第七條 信息部將所有的變更請求記錄在任務管理表（附件四）中，并按照優(yōu)先級安排實施的先后次序進行跟蹤處理。第八條 信息部負責對系統(tǒng)變更過程的文檔進行歸檔管理，所有文檔至少保存三年。詳細流程參見系統(tǒng)變更流程（附件一）。第三節(jié) 緊急變更流程第九條 對于緊急變更，需求部門可以通過電子或傳真等書面形式提出申請。第十條 信息部按照事先明確的緊急變更定義做出判斷，確定其優(yōu)先級和影響程度，并進行相應的處理。第十一條 緊急變更過程中應使用專設系統(tǒng)用戶某，由專責部門或人員啟動緊急修改變更程序。信息部應對緊急變更的處理進行規(guī)X的文檔記錄。第十二條 在緊急事件處理完成后，必須補辦正式、完

3、整的文檔。詳細流程參見緊急變更流程（附件二）。第四節(jié) 系統(tǒng)的版本控制第十三條 軟件變更時，加強版本控制，確保每次在最新的代碼基礎上進行更改。第十四條 應對下發(fā)的軟件進行版本控制，由專責人員負責發(fā)布軟件的版本管理。第五節(jié) 系統(tǒng)變更的責權分離第十五條 應加強對運行環(huán)境的訪問控制，只允許授權的用戶訪問運行環(huán)境中的應用系統(tǒng)。通過物理和邏輯隔離的手段，控制對運行環(huán)境的訪問。第十六條 限制開發(fā)人員對運行環(huán)境中應用程序文件夾的訪問權限，只有經過授權的人員才擁有相應的權限。第十七條 對授權訪問運行環(huán)境的人員進行詳細記錄，并定期進行檢查。第十八條 普通用戶只能通過前臺登錄系統(tǒng)，不能通過后臺進行操作。第十九條 系

4、統(tǒng)維護人員不應該擁有前臺應用程序的訪問權限，更不應該在前臺應用程序中擔任實際的操作任務。第二十條 禁止系統(tǒng)維護人員共享操作系統(tǒng)級別的賬號。第六節(jié) 附則第二十一條 本制度由公司總部信息部負責解釋和修訂。第二十二條 本制度自發(fā)布之日起開始執(zhí)行。20 / 20附件一 系統(tǒng)變更流程系統(tǒng)變更流程步驟：一、任務提交和接受：本流程中需求部門為應用系統(tǒng)構建時提出需求的業(yè)務部門，維護部門為負責按照需某際構建應用系統(tǒng)的信息部。流程如下：（一） 需求形成：需求方根據業(yè)務的需要，結合收到的其他用戶部門要求，填寫變更申請書。（二） 需求方負責人審批需求方將變更申請書報請部門負責人簽字批準后，經指定途徑提交給信息部相關系

5、統(tǒng)維護人員。（三） 需求評估系統(tǒng)維護人員審查需求，會同相關開發(fā)負責人進行需求評估，產生評估結果。（四） 信息部負責人審批系統(tǒng)維護人員將評估結果附在變更申請書后，報請部門負責人簽字批準后，正式向開發(fā)負責人下達任務。如果任務實現(xiàn)由合作廠商完成，則由開發(fā)負責人按照與合作廠商簽訂的技術服務合同，填寫廠商維護申請單（附件五），報請部門負責人簽字批準后，正式向合作廠商下達任務。（五） 任務登記為了便于追蹤各個系統(tǒng)變更需求的狀態(tài)，維護人員需要對需求進行登記。信息部每周對任務管理表中的需求完成狀態(tài)進行更新，以便信息部負責人監(jiān)控系統(tǒng)變更任務進度。二、任務實現(xiàn)信息部開發(fā)負責人（或由開發(fā)負責人會同合作廠商）根據變更

6、申請書的需求描述，按照與軟件開發(fā)流程同樣的步驟，進行分析、設計、編碼、測試，最終完成系統(tǒng)變更需求。三、任務驗收及用戶測試（一） 任務驗收以需求部門為主，信息部配合完成。（二） 任務開發(fā)測試完成后，由開發(fā)負責人通知維護人員，并提供可用于驗收測試的文檔和程序升級包。系統(tǒng)維護人員檢查開發(fā)負責人提交的資料是否完整、有效，版本是否最新，并對移交程序的內容進行驗收并形成記錄。（三） 維護人員制定用戶測試計劃，由需求部門按照測試計劃構建驗收測試環(huán)境，進行驗收測試并對測試內容進行記錄。驗收測試通過后，由需求部門在驗收報告書（附件六）上出具驗收結論并會同信息部門簽署下發(fā)意見。（四） 如果任務實現(xiàn)由合作廠商完成，

7、則由開發(fā)負責人員在內部任務驗收完成后，根據需求部門的驗收意見，在廠商維護申請單上出具驗收結論并會同需求部門簽署下發(fā)意見。 四、程序下發(fā)及系統(tǒng)上線（一） 下發(fā)程序經需求部門正式驗收后由系統(tǒng)維護人員將要發(fā)布的程序進行打包下發(fā)。程序下發(fā)前，系統(tǒng)維護人員需填寫程序下發(fā)申請表（附件七）并經過維護部門負責人審批。（二） 如果通過網絡發(fā)布程序，則需通過指定路徑或程序服務器發(fā)布，并且對相關訪問人員的權限進行控制。（三） 下發(fā)程序接收公司的系統(tǒng)維護人員在收到下發(fā)的程序包后，聯(lián)系需求部門進行安裝測試，測試結束后在系統(tǒng)上線申請表（附件八）的“需求部門意見”中填寫驗收意見，并簽字確認。（四） 程序上線實施完畢以后，系

8、統(tǒng)維護人員需填寫升級情況反饋表（附件九），填寫完畢后將升級情況反饋表上報到上級公司信息部程序下發(fā)人員。（五） 各級公司系統(tǒng)維護人員應在軟件程序變更上線前，嚴格遵照程序下發(fā)要求，建立完善的“回退”計劃（參見軟件開發(fā)制度中試運行計劃的應急預案）以避免升級失敗，并確保系統(tǒng)及時更新到最新版本。 五、文檔整理歸檔系統(tǒng)變更任務結束后，由專門人員將整個過程中產生文檔的最終版本進行統(tǒng)一歸檔管理。附件二 緊急變更流程緊急變更流程步驟緊急變更處理過程中的上報、請示、批準等需通過電子、傳真等書面形式進行，待問題解決后再按照一般系統(tǒng)變更流程補辦各類文檔和審批記錄。一、 緊急變更的報告用戶部門人員或其他人員發(fā)現(xiàn)系統(tǒng)異常

9、，導致業(yè)務處理無法正常進行，必須迅速處理解決時，應及時將問題報告給信息部。如公司信息部相關人員判定此問題需進行程序緊急變更，則報相關負責人要求執(zhí)行程序緊急變更流程。二、 緊急變更的啟動信息部相關負責人接到緊急變更申報后，指定緊急變更任務負責人（通常為應用系統(tǒng)管理人員），負責解決本次的緊急變更問題。緊急變更任務負責人根據重要性和緊迫性區(qū)分變更的優(yōu)先級，組織人員采取相應的處理措施。三、 緊急變更的處理緊急變更流程涉處理同一般程序變更流程處理步驟。其中包括需求分析、程序設計、程序實施、程序測試、程序驗收，但需使用專設的系統(tǒng)用戶賬號進行緊急變更處理，并進行緊急變更的記錄。四、 緊急變更程序的下發(fā)/上線

10、緊急變更任務負責人組織完成變更處理后，盡快向公司信息部相關負責人報告，并提出下發(fā)/上線申請，經批準后，進行程序下發(fā)/上線操作。五、 補辦文檔和領導審批記錄緊急問題得到妥善解決后，需要分別補辦各類文檔和審批記錄，其中包括：（1） 問題發(fā)現(xiàn)人填寫的緊急問題變更申請，其中包含問題發(fā)現(xiàn)人對問題的描述。（2） 問題發(fā)現(xiàn)人所在部門的負責人對申請審批的記錄。（3） 公司信息部相關負責人對需求的審批和任務分派記錄。（4） 開發(fā)人員書面的設計方案和公司信息部相關負責人對設計方案的審批記錄。（5） 需求部門/信息部的測試記錄和簽字確認的測試結果。（6） 程序下發(fā)/上線專責人員填寫的下發(fā)/上線申請和公司信息部相關負

11、責人的審批記錄。信息部負責人指派專人定期對緊急變更記錄文檔進行檢查，六、 文檔整理歸檔按照一般問題系統(tǒng)變更流程的要求，各級公司將緊急事件變更整個過程中的各類文檔進行統(tǒng)一歸檔管理附件三 變更申請書變更申請書中國鋁業(yè)股份某需求部門任務書編號格式：RWSN-年份-序號廠商維護申請單編號對應的廠商維護申請單編號，廠商維護申請單下達后補錄系統(tǒng)名稱系統(tǒng)名稱英文縮寫系統(tǒng)版本 任 務 提 交 欄 *由需求部門填寫*任務名稱建議開始時間建議完成時間任務緊急程度普通 緊急 特急【任務概述】：*如包含多項內容，按順序列出*【附加文檔】：*由雙方確認的需求說明書、變更說明書或系統(tǒng)BUG管理表*【需求部門意見】： 申請

12、人簽字： 日期：部門負責人簽字： 日期： 任 務 接 收 欄 *由信息部填寫*任務性質A:開發(fā)B:改正性維護（識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用）C:適應性維護（因外部環(huán)境或數據環(huán)境的變化引發(fā)的修改）D:完善性維護（因用戶對軟件功能提出新的功能和性能需求引發(fā)的修改）E:其他（上述以外的修正）計劃開始時間計劃完成時間處理優(yōu)先級排隊 優(yōu)先 緊急任務實現(xiàn)方式自行開發(fā) 外包開發(fā) 合作開發(fā)預計工作量 人天，合 人月本次任務計劃費用預估i. *注明小寫金額和大寫金額*ii. ￥元，（大寫）【變更風險評估】：*任務實現(xiàn)對現(xiàn)有系統(tǒng)運行性能和功能等方面帶來的影響評估*· 對原

13、有系統(tǒng)的數據和程序是否有可能破壞的風險？· 對原有系統(tǒng)的安全設計是否有可能破壞的風險？· 對整個網絡的構架是否有可能破壞的風險？· 其他可能存在的風險？【信息部意見】： 系統(tǒng)維護負責人簽字： 日期： 部門負責人簽字： 日期： 附件四 任務管理表任務管理表日期變更申請書編號廠商維護申請單編號需求部門系統(tǒng)名稱任務名稱信息部負責人任務狀態(tài)備注                   &#

14、160;                                                 &#

15、160;           附件五 廠商維護申請單廠商維護申請單甲方（委托方）中國鋁業(yè)股份某乙方（受托方）任務書編號格式：系統(tǒng)名稱英文縮寫-RWSW-年月-序號變更申請書編號對應的變更申請書編號系統(tǒng)名稱系統(tǒng)名稱英文縮寫系統(tǒng)版本 任 務 下 達 欄 *由甲方填寫*任務名稱任務性質 A:開發(fā) B:改正性維護（識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用）C:適應性維護（因外部環(huán)境或數據環(huán)境的變化引發(fā)的修改）D:完善性維護（因用戶對軟件功能提出新的功能和性能需求引發(fā)的修改）

16、E:其他（上述以外的修正）計劃開始時間計劃完成時間處理優(yōu)先級排隊 優(yōu)先 緊急預計工作量 人天，合 人月本次任務計劃稅前開發(fā)費用預估（含報酬）iii. *注明小寫金額和大寫金額*iv. ￥元，（大寫）【任務概述】：*如包含多項內容，按順序列出*【附加文檔】：*由雙方確認的需求規(guī)格說明書、變更說明或系統(tǒng)BUG管理表*【甲方意見】： 開發(fā)負責人簽字： 日期：信息部負責人簽字： 日期： 任 務 接 收 欄 *由乙方填寫*【乙方意見】：項目負責人簽字： 日期：負責人簽字： 日期： 任 務 完 成 情 況 欄 *由乙方填寫，雙方簽字確認*實際開始時間實際完成時間實際工作量人天，合 人月本次任務實際稅前開發(fā)

17、費用（含報酬）*注明小寫金額和大寫金額*￥元，（大寫）【完成情況】：*由乙方簡要概述任務完成情況*【提交文檔】：*由乙方提交的技術文檔、測試文檔、使用文檔與程序代碼等* 甲方開發(fā)負責人簽字： 乙方項目負責人簽字： 日 期： 日 期：任 務 驗 收 情 況 欄 *由甲方填寫，雙方簽字確認*【驗收結論】：*由甲方根據驗收報告出具驗收結論* 甲方開發(fā)負責人簽字： 乙方項目負責人簽字： 日 期： 日 期： 甲方負責人簽字： 乙方負責人簽字：日 期： 日 期：注：該表格一式兩份，甲乙雙方各執(zhí)一份。附件六 驗收報告書驗收報告書中國鋁業(yè)股份某需求部門對應任務書編號對應的變更申請書編號系統(tǒng)名稱系統(tǒng)名稱英文縮寫

18、系統(tǒng)版本 任 務 完 成 情 況 欄 *由信息部根據任務完成實際情況填寫*任務名稱實際開始時間實際完成時間實際工作量人天，合 人月本次任務實際稅前開發(fā)費用（含報酬）*注明小寫金額和大寫金額*￥元，（大寫）【任務完成情況】：*由信息部簡要概述任務完成情況*【提交文檔清單】：*由信息部提交相關文檔清單*需求部門接受人簽字： 信息部提交人簽字： 日 期： 日 期：驗 收 過 程 信 息 欄 *由信息部根據驗收過程填寫*驗收開始時間驗收完成時間驗收地點需求部門驗收人員角色/職責信息部協(xié)助人員角色/職責任 務 驗 收 情 況 欄 *由需求部門根據驗收情況出具*【驗收意見】：*由需求部門項目負責人出具對實際驗收結果的意見*任 務 驗 收 結 論 欄 *由需求部門出具，雙方負責人簽字確認*【驗收結論】：*由需求部門根據驗收意見出具任務驗收結論*【下發(fā)意見】：*由需求部門根據驗收結論出具程序下發(fā)意見*需求部門負責人簽字： 信息部負責人簽字： 日 期： 日 期：注：該表格一式兩份，需求部