開發(fā)和運維的職責分離管理

1、業(yè)務系統(tǒng)變更管理制度開發(fā)和運維的職責分離管理第一節(jié) 總 則第一條為規(guī)范軟件變更與維護管理，提高軟件管理水平，優(yōu)化軟件變更與維護管理流程，特制定本制度。第二條本制度適用于應用系統(tǒng)已開發(fā)或采購完畢并正式上線、 且由軟件開發(fā)組織移交給應用管理組織之后，所發(fā)生的生產(chǎn)應用系統(tǒng)（以下簡稱應用系統(tǒng)）運行 支持及系統(tǒng)變更工作。第二節(jié) 變更流程第三條 系統(tǒng)變更工作可分為下面三類類型：功能完善維護、系統(tǒng)缺陷修改、統(tǒng)計報 表生成。功能完善維護指根據(jù)業(yè)務部門的需求，對系統(tǒng)進行的功能完善性或 適應性維護； 系統(tǒng)缺陷修改指對一些系統(tǒng)功能或使用上的問題所進行的修復， 這些問題是由于系統(tǒng)設(shè)計和實現(xiàn)上的缺陷而引發(fā)的； 統(tǒng)計報表

2、生成指為了滿 足業(yè)務部門統(tǒng)計報表數(shù)據(jù)生成的需要， 而進行的不包含在應用系統(tǒng)功能之內(nèi) 的數(shù)據(jù)處理工作。第四條 系統(tǒng)變更工作以任務形式由需求方（一般為業(yè)務部門）和維護方（一般為信 息部門的應用維護組織和軟件開發(fā)組織，還包括合作廠商）協(xié)作完成。系統(tǒng) 變更過程類似軟件開發(fā)， 大致可分為四個階段： 任務提交和接受、 任務實現(xiàn)、 任務驗收和程序下發(fā)上線。第五條因問題處理引發(fā)的系統(tǒng)變更處理，具體流程參見問題處理管理制度。第六條需求部門提出系統(tǒng)變更需求，并將變更需求整理成系統(tǒng)變更申請表（附件一），由部門負責人審批后提交給系統(tǒng)管理員。第七條系統(tǒng)管理員負責接受需求并上報給 IT 主管。 IT 主管分析需求，并提出

3、系統(tǒng)變更建議。 IT 經(jīng)理根據(jù)變更建議審批系統(tǒng)變更申請表 。第八條系統(tǒng)管理員根據(jù)自行開發(fā)、 合作開發(fā)和外包開發(fā)的不同要求組織實現(xiàn)系統(tǒng)變更需求，將需求提交至內(nèi)部開發(fā)人員、合作開發(fā)商或外包開發(fā)商，產(chǎn)生供發(fā) 布的程序。第九條實現(xiàn)過程應按照軟件開發(fā)過程規(guī)定進行。 系統(tǒng)變更過程應遵循軟件開發(fā)過程相同的正式、統(tǒng)一的編碼標準，并經(jīng)過測試和正式驗收才能下發(fā)和上線。第十條系統(tǒng)管理員組織業(yè)務部門的系統(tǒng)最終用戶對系統(tǒng)程序變更進行測試， 并撰寫用戶測試報告 （附件二），提交業(yè)務部門負責人和 IT 主管領(lǐng)導簽字確認 通過。第十一條 在系統(tǒng)變更完成后，系統(tǒng)管理員和業(yè)務部門的最終用戶共同撰寫程序變更 驗收報告（附件三），經(jīng)

4、業(yè)務部門負責人簽字驗收后，報送 IT 經(jīng)理審批。第十二條 培訓管理員負責對系統(tǒng)變更過程的文檔進行歸檔管理， 變更過程中涉及的所 有文檔應至少保存兩年。第三節(jié) 緊急變更流程第十三條 對于緊急變更，需求部門可以通過電子郵件或傳真等書面形式提出申請。 第十四條 信息技術(shù)部根據(jù)重要性和緊迫性做判斷，確定其優(yōu)先級和影響程度，并進行 相應處理。第十五條 緊急變更過程中應使用專設(shè)的系統(tǒng)用戶賬號， 由專責部門或人員啟動緊急修 改變更程序。信息技術(shù)部應對緊急變更的處理進行規(guī)范的文檔記錄。第十六條 在緊急事件處理完成后，必須在一周內(nèi)補辦正式、完整的文檔，其中包括問 題發(fā)現(xiàn)人填寫的緊急變更申請、 問題發(fā)現(xiàn)人所在部門

5、負責人對該申請的審批、 需求部門 / 信息技術(shù)部測試記錄（包括簽字確認測試結(jié)果） 。第四節(jié) 系統(tǒng)變更的權(quán)責分離第十七條 系統(tǒng)變更過程中， 應采取各種措施保證維護環(huán)境程序代碼訪問權(quán)限受到良好 控制。這些措施包括：1、通過系統(tǒng)用戶的授權(quán)管理，確保只有特定人員能進行系統(tǒng)維護工作；2、如果使用專用程序開發(fā)工具，只有授權(quán)人員才能使用程序開發(fā)工具（通 過只有特定開發(fā)人員擁有程序開發(fā)工具） ；3、通過對源代碼的訪問控制，限制只有授權(quán)人員才能獲得源代碼以進行系 統(tǒng)維護；4、在進行自有系統(tǒng)的程序變更時，應建立版本控制制度確保每次在最新的代碼基礎(chǔ)上進行更改， 當多名程序員同時進行更改工作時， 能夠進行適當協(xié) 調(diào)；

6、5、通過對系統(tǒng)日志的審閱，監(jiān)督系統(tǒng)維護人員在系統(tǒng)中的操作，確認維護 工作的授權(quán)；6、在進行自有系統(tǒng)的程序變更時，應防止源代碼在完成測試到正式上線之 間的非授權(quán)修改。第十八條 系統(tǒng)變更過程中， 采取各種措施保證生產(chǎn)系統(tǒng)應用程序訪問權(quán)限受到良好控制。這些措施包括：1、通過生產(chǎn)環(huán)境的訪問控制，限制對生產(chǎn)環(huán)境的訪問；2、通過物理隔離的手段，限制對生產(chǎn)環(huán)境的訪問；3、通過邏輯隔離的手段，限制對生產(chǎn)環(huán)境的訪問；4、對授權(quán)訪問生產(chǎn)環(huán)境的人員進行詳細記錄，使用該記錄對生產(chǎn)環(huán)境訪問權(quán)限的檢查，確保只有經(jīng)授權(quán)人員才能訪問生產(chǎn)環(huán)境；5、普通用戶只能通過前臺登錄系統(tǒng)，不能通過后臺（如使用生產(chǎn)環(huán)境操作 系統(tǒng)的命令行）進

7、行操作；6、信息技術(shù)人員不應該擁有前臺應用程序的業(yè)務操作訪問權(quán)限，更不應該在前臺應用程序中擔任實際的業(yè)務操作任務；7、從技術(shù)角度限制開發(fā)人員對生產(chǎn)環(huán)境中應用程序文件夾的訪問權(quán)限，只 有經(jīng)過授權(quán)的人員對程序擁有讀、寫和執(zhí)行的權(quán)限；8、禁止信息技術(shù)人員共享操作系統(tǒng)級別的賬號。第五節(jié) 附則第十九條 本制度由公司總部信息技術(shù)部負責解釋和修訂第二十條 本制度自發(fā)布之日起開始執(zhí)行。附件一系統(tǒng)變更申請表系統(tǒng)變更申請表編號:變更請求類型用戶方變更開發(fā)方變更需求增加需求修改需求縮減其它：請說明：變更申請人申請日期實施人員驗證人原需求內(nèi)容描述變更內(nèi)容描述變更的影響業(yè)務部門負責人意見：簽字：IT人員意見：簽字：備注

8、：附件二用戶測試報告1.基本信息測試依據(jù)例如：參照標準、客戶需求、需求規(guī)格說明書、測試用例等測試范圍測試驗收標準測試環(huán)境描述測試驅(qū)動程序描述提示：可以把測試驅(qū)動程序當作附件測試人員測試時間須注明每次回歸測試的時間測試工具2.實況記錄模塊測試用例編號期望結(jié)果測試結(jié)果缺陷密度是否執(zhí)行了回歸測試3.測試總評價根據(jù)對測試結(jié)果提出一個關(guān)于軟件能力的全面分析，需標明遺留的主要缺陷、局限性和軟件的約束限制等，并提出軟件測試過程中程序中的不足。根據(jù)測試標準及測試結(jié)果，綜合評價軟件的開發(fā)是否已達到預定目標。4.缺陷修改記錄提示：如果采用了缺陷管理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。缺陷名稱缺陷類型嚴重程度

9、模塊原因駐留時間解決方案測試人員簽字/日期:附件三程序變更驗收報告需求部門驗收報告書系統(tǒng)名稱系統(tǒng)名稱英文縮寫系統(tǒng)版本任 務完成 情況欄*由信息技術(shù)部根據(jù)任務完成實際情況填寫*任務名稱實際開始時間實際完成時間實際工作量人天，合人月本次任務實際稅 前開發(fā)費用（含 報酬）*注明小寫金額和大寫金額*元，（大寫呂）【任務完成情況】：*由信息技術(shù)部簡要概述任務完成情況*【提交文檔清單】：*由信息技術(shù)部提交相關(guān)文檔清單*業(yè)務部門接受人簽字：信息技術(shù)部提交人簽字：日期：日期：驗 收過程 信 息 欄*由信息技術(shù)部根據(jù)驗收過程填寫*驗收開始時間驗收完成時間驗收地點需求部門 驗收人員角色/職責信息部門 協(xié)助人員角色/職責任 務驗收 情 況 欄*由業(yè)務部門根據(jù)驗收情況出具 【驗收意見】：*由業(yè)務部門項目負責人岀具對實際驗收結(jié)果的意見 *業(yè)務部門項目負責人簽字：日期：任務管理處室項目負責人簽字：日期：任務管理處室負責