2內部控制-信息系統(tǒng)更新改造升級方案(7頁).doc
下載文檔
上傳人:t***
編號:907808
2024-03-26
7頁
63.50KB
1、內部控制-信息系統(tǒng)更新/改造/升級方案第一節(jié) 總 則第一條 為規(guī)范軟件變更與維護管理,提高軟件管理水平,優(yōu)化軟件變更與維護管理流程,特制定本制度。第二條 本制度適用于應用系統(tǒng)已開發(fā)或采購完畢并正式上線、且由軟件開發(fā)組織移交給應用管理組織之后,所發(fā)生的生產應用系統(tǒng)(以下簡稱應用系統(tǒng))運行支持及系統(tǒng)變更工作。第二節(jié) 變更流程第三條 系統(tǒng)變更工作可分為下面三類類型:功能完善維護、系統(tǒng)缺陷修改、統(tǒng)計報表生成。功能完善維護指根據業(yè)務部門的需求,對系統(tǒng)進行的功能完善性或適應性維護;系統(tǒng)缺陷修改指對一些系統(tǒng)功能或使用上的問題所進行的修復,這些問題是由于系統(tǒng)設計和實現上的缺陷而引發(fā)的;統(tǒng)計報表生成指為了滿足業(yè)2、務部門統(tǒng)計報表數據生成的需要,而進行的不包含在應用系統(tǒng)功能之內的數據處理工作。第四條 系統(tǒng)變更工作以任務形式由需求方(一般為業(yè)務部門)和維護方(一般為信息部門的應用維護組織和軟件開發(fā)組織,還包括合作廠商)協作完成。系統(tǒng)變更過程類似軟件開發(fā),大致可分為四個階段:任務提交和接受、任務實現、任務驗收和程序下發(fā)上線。第五條 因問題處理引發(fā)的系統(tǒng)變更處理,具體流程參見問題處理管理制度。第六條 需求部門提出系統(tǒng)變更需求,并將變更需求整理成系統(tǒng)變更申請表(附件一),由部門負責人審批后提交給系統(tǒng)管理員。第七條 系統(tǒng)管理員負責接受需求并上報給IT主管。IT主管分析需求,并提出系統(tǒng)變更建議。IT經理根據變更建議審3、批系統(tǒng)變更申請表。第八條 系統(tǒng)管理員根據自行開發(fā)、合作開發(fā)和外包開發(fā)的不同要求組織實現系統(tǒng)變更需求,將需求提交至內部開發(fā)人員、合作開發(fā)商或外包開發(fā)商,產生供發(fā)布的程序。第九條 實現過程應按照軟件開發(fā)過程規(guī)定進行。系統(tǒng)變更過程應遵循軟件開發(fā)過程相同的正式、統(tǒng)一的編碼標準,并經過測試和正式驗收才能下發(fā)和上線。第十條 系統(tǒng)管理員組織業(yè)務部門的系統(tǒng)最終用戶對系統(tǒng)程序變更進行測試,并撰寫用戶測試報告(附件二),提交業(yè)務部門負責人和IT主管領導簽字確認通過。第十一條 在系統(tǒng)變更完成后,系統(tǒng)管理員和業(yè)務部門的最終用戶共同撰寫程序變更驗收報告(附件三),經業(yè)務部門負責人簽字驗收后,報送IT經理審批。第十二條 4、培訓管理員負責對系統(tǒng)變更過程的文檔進行歸檔管理,變更過程中涉及的所有文檔應至少保存兩年。第三節(jié) 緊急變更流程第十三條 對于緊急變更,需求部門可以通過電子郵件或傳真等書面形式提出申請。第十四條 信息技術部根據重要性和緊迫性做判斷,確定其優(yōu)先級和影響程度,并進行相應處理。第十五條 緊急變更過程中應使用專設的系統(tǒng)用戶賬號,由專責部門或人員啟動緊急修改變更程序。信息技術部應對緊急變更的處理進行規(guī)范的文檔記錄。第十六條 在緊急事件處理完成后,必須在一周內補辦正式、完整的文檔,其中包括問題發(fā)現人填寫的緊急變更申請、問題發(fā)現人所在部門負責人對該申請的審批、需求部門/信息技術部測試記錄(包括簽字確認測試結果)5、。第四節(jié) 系統(tǒng)變更的權責分離第十七條 系統(tǒng)變更過程中,應采取各種措施保證維護環(huán)境程序代碼訪問權限受到良好控制。這些措施包括:1、通過系統(tǒng)用戶的授權管理,確保只有特定人員能進行系統(tǒng)維護工作;2、如果使用專用程序開發(fā)工具,只有授權人員才能使用程序開發(fā)工具(通過只有特定開發(fā)人員擁有程序開發(fā)工具);3、通過對源代碼的訪問控制,限制只有授權人員才能獲得源代碼以進行系統(tǒng)維護;4、在進行自有系統(tǒng)的程序變更時,應建立版本控制制度確保每次在最新的代碼基礎上進行更改,當多名程序員同時進行更改工作時,能夠進行適當協調;5、通過對系統(tǒng)日志的審閱,監(jiān)督系統(tǒng)維護人員在系統(tǒng)中的操作,確認維護工作的授權;6、在進行自有系統(tǒng)的6、程序變更時,應防止源代碼在完成測試到正式上線之間的非授權修改。第十八條 系統(tǒng)變更過程中,采取各種措施保證生產系統(tǒng)應用程序訪問權限受到良好控制。這些措施包括:1、通過生產環(huán)境的訪問控制,限制對生產環(huán)境的訪問;2、通過物理隔離的手段,限制對生產環(huán)境的訪問;3、通過邏輯隔離的手段,限制對生產環(huán)境的訪問;4、對授權訪問生產環(huán)境的人員進行詳細記錄,使用該記錄對生產環(huán)境訪問權限的檢查,確保只有經授權人員才能訪問生產環(huán)境;5、普通用戶只能通過前臺登錄系統(tǒng),不能通過后臺(如使用生產環(huán)境操作系統(tǒng)的命令行)進行操作;6、信息技術人員不應該擁有前臺應用程序的業(yè)務操作訪問權限,更不應該在前臺應用程序中擔任實際的業(yè)務操7、作任務;7、從技術角度限制開發(fā)人員對生產環(huán)境中應用程序文件夾的訪問權限,只有經過授權的人員對程序擁有讀、寫和執(zhí)行的權限;8、禁止信息技術人員共享操作系統(tǒng)級別的賬號。第五節(jié) 附則第十九條 本制度由公司總部信息技術部負責解釋和修訂。第二十條 本制度自發(fā)布之日起開始執(zhí)行。附件一 系統(tǒng)變更申請表系統(tǒng)變更申請表編號:變更請求類型用戶方變更 開發(fā)方變更 需求增加 需求修改 需求縮減其它:請說明: 變更申請人申請日期實施人員驗證人原需求內容描述變更內容描述變更的影響業(yè)務部門負責人意見: 簽字:IT人員意見: 簽字:備注:附件二 用戶測試報告1. 基本信息測試依據例如:參照標準、客戶需求、需求規(guī)格說明書、測試8、用例等測試范圍測試驗收標準測試環(huán)境描述測試驅動程序描述提示:可以把測試驅動程序當作附件測試人員測試時間須注明每次回歸測試的時間測試工具2. 實況記錄模塊測試用例編號期望結果測試結果缺陷密度是否執(zhí)行了回歸測試3. 測試總評價根據對測試結果提出一個關于軟件能力的全面分析,需標明遺留的主要缺陷、局限性和軟件的約束限制等,并提出軟件測試過程中程序中的不足。根據測試標準及測試結果,綜合評價軟件的開發(fā)是否已達到預定目標。4. 缺陷修改記錄提示:如果采用了缺陷管理工具,能自動產生缺陷報表的話,則無需本表。缺陷名稱缺陷類型嚴重程度模塊原因駐留時間解決方案測試人員簽字/日期:附件三 程序變更驗收報告驗收報告書需9、求部門系統(tǒng)名稱系統(tǒng)名稱英文縮寫系統(tǒng)版本任 務 完 成 情 況 欄 *由信息技術部根據任務完成實際情況填寫*任務名稱實際開始時間實際完成時間實際工作量人天,合 人月本次任務實際稅前開發(fā)費用(含報酬)*注明小寫金額和大寫金額*¥ 元,(大寫) 【任務完成情況】:*由信息技術部簡要概述任務完成情況*【提交文檔清單】:*由信息技術部提交相關文檔清單*業(yè)務部門接受人簽字: 信息技術部提交人簽字: 日 期: 日 期: 驗 收 過 程 信 息 欄 *由信息技術部根據驗收過程填寫*驗收開始時間驗收完成時間驗收地點需求部門驗收人員角色/職責信息部門協助人員角色/職責任 務 驗 收 情 況 欄 *由業(yè)務部門根據驗收情況出具*【驗收意見】:*由業(yè)務部門項目負責人出具對實際驗收結果的意見*業(yè)務部門項目負責人簽字: 日期: 任務管理處室項目負責人簽字: 日期: 任務管理處室負責人簽字: 日期: 任 務 驗 收 結 論 欄 *由業(yè)務部門出具,雙方負責人簽字確認*【驗收結論】:*由業(yè)務部門根據驗收意見出具任務驗收結論*【下發(fā)意見】:*由業(yè)務部門根據驗收結論出具程序下發(fā)意見*業(yè)務部門負責人簽字: 信息技術部負責人簽字: 日 期: 日 期: 注:該表格一式兩份,業(yè)務部門、信息技術部雙方各執(zhí)一份。
地產規(guī)劃
上傳時間:2024-12-17
16份
地產規(guī)劃
上傳時間:2025-02-06
34份