【正文】 生產(chǎn)用軟件維護(hù)管理制度 第一節(jié) 總則 第一條 本制度適用于應(yīng)用系統(tǒng)已開發(fā)或采購?fù)戤叢⒄缴暇€、且由軟件開發(fā)組織移交給應(yīng)用管理組織之后，所發(fā)生的生產(chǎn)應(yīng)用系統(tǒng)（以下簡稱應(yīng)用系統(tǒng)）運行支持及系統(tǒng)變更工作。 第一條 本制度所指的軟件開發(fā)組織，在公司總部層面為信息技術(shù)部各軟件開發(fā)處，在分公司層面為信息技術(shù)部相關(guān)的軟件開發(fā)科室或崗位；本制度所指的應(yīng)用管理組織，在總公司層面為信息技術(shù)部應(yīng)用管理處，在分公司層面為信息技術(shù)部相應(yīng)的應(yīng)用維護(hù)科室或崗位。 第二節(jié) 生產(chǎn)用軟件系統(tǒng)的運行支持 第二條 運行支持工作可分為下面兩種類型：運行維護(hù)和技術(shù)支持。運行維護(hù)指后臺程序（ 批作業(yè)）運行、數(shù)據(jù)庫備份、數(shù)據(jù)清理等日常工作；技術(shù)支持指提供系統(tǒng)使用、技術(shù)知識上的幫助。 第三條 生產(chǎn)用軟件系統(tǒng)的運行維護(hù)工作由各級公司信息部門應(yīng)用維護(hù)組織完成。技術(shù)支持工作由各級公司信息部門應(yīng)用維護(hù)組織向本公司用戶部門和下級公司信息部門應(yīng)用管理組織提供。 第四條 應(yīng)用管理的主要職責(zé)是：處理總部各部門和分公司對目前已上線系統(tǒng)的應(yīng)用問題的工作主要由應(yīng)用管理處負(fù)責(zé)，主要工作包括提供相應(yīng)的技術(shù)咨詢及技術(shù)支持，以及接收問題報告，并對問題加以解決。 第五條 技術(shù)咨詢指為通過電話、電子郵件、技術(shù)論壇等形式為分公司及總公司相關(guān)部門提供關(guān)于應(yīng)用系 統(tǒng)的使用及維護(hù)等方面的技術(shù)支持；接收問題報告指接收由下級分公司上報的，以“問題報告單”形式反映的應(yīng)用系統(tǒng)問題，并加以處理、反饋和匯總整理。 第六條 為方便管理，提高服務(wù)效率，應(yīng)制定默認(rèn)處理制度。即要求回復(fù)的工作或問題，在默認(rèn)的時間內(nèi)未接到回復(fù)的按默認(rèn)辦法處理。 第七條 負(fù)責(zé)處理具體應(yīng)用管理的人員應(yīng)每月出具問題報告，統(tǒng)計匯總、分析經(jīng)辦的問題，提出相關(guān)意見和建議，并請直管領(lǐng)導(dǎo)簽字審閱。 第八條 接收問題，提供咨詢等工作中發(fā)生的文檔應(yīng)妥善保存，紙質(zhì)文檔保存時間為 2 年，電子文檔每年以 CDR 進(jìn)行統(tǒng)一刻錄，保存時間為 5 年。 第九條 要求各級單位以問題 報告單的形式報告應(yīng)用系統(tǒng)出現(xiàn)的問題。上級單位接收問題上報的時間以收到問題報告單位問題報告單的時間為準(zhǔn)。問題報告單位應(yīng)對其反映的問題做出初步定位。 第十條 問題報告單位填寫問題報告單應(yīng)規(guī)范，并詳細(xì)描述問題出現(xiàn)時的狀況、當(dāng)時的環(huán)境以及錯誤提示信息等一切有助于準(zhǔn)確定位問題的信息。同時，應(yīng)完整填寫上報人信息及聯(lián)系方式（電話、 OA），以方便聯(lián)絡(luò)。對于不符合要求的問題報告單應(yīng)返回問題報告單位重新填寫。 第十一條 接到用戶通過電話、 OA 提出的咨詢應(yīng)盡量給予對方滿意的解答。電話、 OA 提出的咨詢不視為正式的問題上報。 第十二條 論壇主要作為供各層信息技 術(shù)人員交流經(jīng)驗的平臺。對于正式問題上報還是應(yīng)采取提交“問題報告單”形式上報；問題咨詢應(yīng)通過 OA 或電話形式。應(yīng)用管理處應(yīng)用系統(tǒng)維護(hù)崗的負(fù)責(zé)同志應(yīng)有取舍的對論壇中有共性的問題進(jìn)行答復(fù)。 第十三條 對屬于操作類的問題，須判斷屬于誤操作，還是存在臟數(shù)據(jù)，應(yīng)按問題的性質(zhì)分別給出處理辦法。如果發(fā)現(xiàn)問題屬于系統(tǒng)中存在臟數(shù)據(jù)，應(yīng)請當(dāng)?shù)貑栴}單位及時清理。如其中數(shù)據(jù)涉及數(shù)據(jù)擁有部門（如：財務(wù)部、業(yè)管部等），應(yīng)向相關(guān)部門申請，在獲得書面同意后方可進(jìn)行修改。同時，如果需要直接修改后臺數(shù)據(jù)庫中的數(shù)據(jù)，具體流程應(yīng)參考運行管理流程中關(guān)于修改后臺數(shù) 據(jù)庫中的相關(guān)規(guī)定。 第三節(jié) 生產(chǎn)用軟件系統(tǒng)的系統(tǒng)變更 第十四條 系統(tǒng)變更工作可分為下面三類類型：功能完善維護(hù)、系統(tǒng)缺陷修改、統(tǒng)計報表生成。功能完善維護(hù)指根據(jù)業(yè)務(wù)部門的需求，對系統(tǒng)進(jìn)行的功能完善性或適應(yīng)性維護(hù)；系統(tǒng)缺陷修改指對一些系統(tǒng)功能或使用上的問題所進(jìn)行的修復(fù)，這些問題是由于系統(tǒng)設(shè)計和實現(xiàn)上的缺陷而引發(fā)的；統(tǒng)計報表生成指為了滿足業(yè)務(wù)部門統(tǒng)計報表數(shù)據(jù)生成的需要，而進(jìn)行的不包含在應(yīng)用系統(tǒng)功能之內(nèi)的數(shù)據(jù)處理工作。 第十五條 系統(tǒng)變更工作以任務(wù)形式由需求方（一般為業(yè)務(wù)部門）和維護(hù)方（一般為信息部門的應(yīng)用維護(hù)組織和軟件開發(fā)組織，還包括合作廠商 ）協(xié)作完成。系統(tǒng)變更過程類似軟件開發(fā)，大致可分為四個階段：任務(wù)提交和接受、任務(wù)實現(xiàn)、任務(wù)驗收和程序下發(fā)上線。具體流程，前三個階段參見《系統(tǒng)變更流程》，第四個階段參見《程序下發(fā)流程》。 第十六條 因問題和緊急事件處理引發(fā)的系統(tǒng)變更處理，具體流程參見《 問題變更流程 》和《緊急變更流程》。 第十七條 系統(tǒng)變更需求只能由應(yīng)用系統(tǒng)具體擁有部門作為需求部門提出，由具體開發(fā)應(yīng)用系統(tǒng)的信息技術(shù)部作為維護(hù)部門接受。需求部門變更需求提出人應(yīng)將變更需求整理成《內(nèi)部任務(wù)書》，以部門名義提交給信息技術(shù)部，《內(nèi)部任務(wù)書》在提交前應(yīng)由需求部門負(fù)責(zé)人審批。維護(hù) 部門由應(yīng)用管理組織負(fù)責(zé)接受需求、分析需求，并提出系統(tǒng)變更建議，對《內(nèi)部任務(wù)書》的處理意見應(yīng)經(jīng)過信息技術(shù)部負(fù)責(zé)人審批。 第十八條 應(yīng)用管理組織在變更需求的分析過程中應(yīng)評估并核實變更對現(xiàn)有運行帶來的影響，并給出優(yōu)先級分配的建議。上述評估結(jié)果和處理意見應(yīng)做為處理意見的一部分包含于《內(nèi)部任務(wù)書》中。 第十九條 需求部門對變更需求本身的變更，應(yīng)以《需求變更書》的形式向維護(hù)部門正式提出。 第二十條 應(yīng)用管理組織負(fù)責(zé)系統(tǒng)變更需求的實現(xiàn)，按照分配的優(yōu)先級安排變更實施的先后次序，并據(jù)此產(chǎn)生供發(fā)布的程序，同時確保所有的變更請求都已經(jīng)記錄，并且能跟蹤處理所有 已記錄的變更請求。信息技術(shù)部負(fù)責(zé)人應(yīng)根據(jù)應(yīng)用管理組織提供的變更情況記錄審核系統(tǒng)變更的進(jìn)度。 第二十一條 實現(xiàn)過程應(yīng)按照軟件開發(fā)過程規(guī)定進(jìn)行。系統(tǒng)變更過程應(yīng)遵循軟件開發(fā)過程相同的正式、統(tǒng)一的編碼標(biāo)準(zhǔn)，并經(jīng)過測試和正式驗收才能下發(fā)和上線。 第二十二條 系統(tǒng)變更過程中，應(yīng)用管理組織應(yīng)采取各種措施保證維護(hù)環(huán)境程序代碼訪問權(quán)限受到良好控制。這些措施包括：通過系統(tǒng)用戶的授權(quán)管理，確保只有特定人員能進(jìn)行系統(tǒng)維護(hù)工作；如果使用專用程序開發(fā)工具，只有授權(quán)人員才能使用程序開發(fā)工具（通過只有特定開發(fā)人員擁有程序開發(fā)工具）；通過對源代碼的訪問控制，限制只 有授權(quán)人員才能獲得源代碼以進(jìn)行系統(tǒng)維護(hù)；在進(jìn)行自有系統(tǒng)的程序變更時，應(yīng)建立版本控制制度確保每次在最新的代碼基礎(chǔ)上進(jìn)行更改，當(dāng)多名程序員同時進(jìn)行更改工作時，能夠進(jìn)行適當(dāng)協(xié)調(diào)；通過對系統(tǒng)日志的審閱，監(jiān)督系統(tǒng)維護(hù)人員在系統(tǒng)中的操作，確認(rèn)維護(hù)工作的授權(quán)；在進(jìn)行自有系統(tǒng)的程序變更時，應(yīng)嚴(yán)格遵循《系統(tǒng)變更流程》以防止或者發(fā)現(xiàn)源代碼在完成測試到正式上線之間的非授權(quán)修改。 第二十三條 系統(tǒng)變更過程中，應(yīng)用管理組織應(yīng)采取各種措施保證生產(chǎn)系統(tǒng)應(yīng)用程序訪問權(quán)限受到良好控制。這些措施包括：通過生產(chǎn)環(huán)境的訪問控制，限制對生產(chǎn)環(huán)境的訪問；通過物理 隔離的手段，限制對生產(chǎn)環(huán)境的訪問；通過邏輯隔離的手段，限制對生產(chǎn)環(huán)境的訪問；對授權(quán)訪問生產(chǎn)環(huán)境的人員進(jìn)行詳細(xì)記錄，使用該記錄對生產(chǎn)環(huán)境訪問權(quán)限的檢查，確保只有經(jīng)授權(quán)人員才能訪問生產(chǎn)環(huán)境；普通用戶只能通過前臺登錄系統(tǒng)，不能通過后臺（如使用生產(chǎn)環(huán)境操作系統(tǒng)的命令行）進(jìn)行操作；信息技術(shù)人員不應(yīng)該擁有前臺應(yīng)用程序的訪問權(quán)限，更不應(yīng)該在前臺應(yīng)用程序中擔(dān)任實際的操作任務(wù)；從技術(shù)角度限制開發(fā)人員對生產(chǎn)環(huán)境中應(yīng)用程序文件夾的訪問權(quán)限，只有經(jīng)過授權(quán)的人員對程序擁有讀、寫和執(zhí)行的權(quán)限；禁止信息技術(shù)人員共享操作系統(tǒng)級別的賬號。 第二十四條 相關(guān)軟件開發(fā)處室 完成系統(tǒng)變更后，應(yīng)向 應(yīng)用管理處提交修改的程序。應(yīng)用管理處 收到修改的程序后，判斷是否需要通過下發(fā)補丁的形式更新程序。如問題屬于暫時、僅個別單位存在且影響不大的，可先將修改程序交存在問題的單位。除因緊急情況需臨時下發(fā)外，程序應(yīng)按周期固定下發(fā)時間。接收相關(guān)開發(fā)處室提交的程序時，應(yīng)要求其將問題跟蹤單一并反饋。 第二十五條 當(dāng)生產(chǎn)用軟件需要下發(fā)新版本，進(jìn)行系統(tǒng)變更時，應(yīng)由相關(guān)軟件開發(fā)處室負(fù)責(zé)相應(yīng)系統(tǒng)的人員以提交《發(fā)版申請表》的形式，向應(yīng)用管理處負(fù)責(zé)相應(yīng)系統(tǒng)的人員提出下發(fā)的軟件的申請。同時應(yīng)一并提交軟件升級包、源程 序、驗收測試報告、升級說明等相關(guān)文檔。相關(guān)軟件開發(fā)處室負(fù)責(zé)相應(yīng)系統(tǒng)的人員提交的《發(fā)版申請表》，必須由相關(guān)開發(fā)處室經(jīng)理及負(fù)責(zé)相應(yīng)系統(tǒng)的人員簽字后方生效。 第二十六條 負(fù)責(zé)應(yīng)用管理的系統(tǒng)維護(hù)的人員檢查軟件開發(fā)處室負(fù)責(zé)相應(yīng)系統(tǒng)的人員提交的資料是否完整、內(nèi)容是否齊全、表示是否清楚、版本是否最新；同時，將升級包在測試機上進(jìn)行安裝測試，測試結(jié)束后，在《上線申請表》中出具意見，并簽字確認(rèn)。 第二十七條 相關(guān)文檔經(jīng)檢查無誤，且升級包在測試機上進(jìn)行安裝測試通過后，應(yīng)用管理負(fù)責(zé)相應(yīng)系統(tǒng)維護(hù)的人員確定升級包的版本名稱，并填寫《系統(tǒng)上線申請表》，并提交應(yīng) 用管理處經(jīng)理。如在檢查中發(fā)現(xiàn)問題，則請相關(guān)處室修改后重新提交。 第二十八條 系統(tǒng)維護(hù)人員將升級包上傳到發(fā)版用 FTP 服務(wù)器之前，應(yīng)取得主管領(lǐng)導(dǎo)的授權(quán)，授權(quán)以主管領(lǐng)導(dǎo)在《系統(tǒng)上線申請表》上的簽字為準(zhǔn)。發(fā)版升級包及發(fā)版用 FTP 服務(wù)器只能由系統(tǒng)維護(hù)人員更新，下發(fā)的升級包只能由下級公司的指定人員獲取。 第二十九條 應(yīng)用維護(hù)組織應(yīng)通過正式的途徑向下級公司系統(tǒng)維護(hù)人員發(fā)出程序下發(fā)通知，通知中需列出分發(fā)途徑、軟件識別的方法（如程序包的名稱、版本及程序包的大?。⑾掳l(fā)時間及期限。 第三十條 各級公司系統(tǒng)維護(hù)人員應(yīng)在自有系統(tǒng)的程序變更上線前，應(yīng)嚴(yán)格遵照《程序下 發(fā)流程》，建立足夠的“回退”計劃以避免升級失敗的發(fā)生，并確保生產(chǎn)環(huán)境和生產(chǎn)庫以及全部的相同應(yīng)用系統(tǒng)都及時更新到最新版的程序。 第三十一條 各級公司系統(tǒng)維護(hù)人員應(yīng)按照《問題和應(yīng)急事件處理》制度的規(guī)定，依據(jù)《問題變更流程》和《緊急變更流程》對應(yīng)用系統(tǒng)各類問題和各級緊急事件進(jìn)行處理。對于緊急事件，只能由維護(hù)部門應(yīng)用管理組織按照事先明確的緊急事件定義做出判斷，確定其優(yōu)先級和影響程度，并啟動應(yīng)用系統(tǒng)緊急變更。緊急變更過程中應(yīng)使用專設(shè)系統(tǒng)用戶帳號。應(yīng)用管理組織應(yīng)對緊急事件的處理進(jìn)行規(guī)范、明確的文檔記錄，并在緊急事件處理完成后，按照 一般問題處理的要求補充正式、完整的文檔。 第三十二條 應(yīng)用維護(hù)組織負(fù)責(zé)對系統(tǒng)變更項目的文檔進(jìn)行歸檔管理，變更過程中涉及的所有文檔應(yīng)至少保存三年。 第四節(jié) 附則 第三十三條 本制度由公司總部信息技術(shù)部負(fù)責(zé)解釋和修訂。 第三十四條 本制度自發(fā)布之日起開始執(zhí)行。 附件一 系統(tǒng)變更流程 應(yīng)用系統(tǒng)維護(hù)方（信息部門）應(yīng)用系統(tǒng)需求方（業(yè)務(wù)部門）開 始系 統(tǒng) 變 更 流 程填 寫 《 內(nèi) 部任 務(wù) 書 》結(jié) 束提 交 《 內(nèi) 部任 務(wù) 書 》部 門 負(fù) 責(zé) 人審 批 《 內(nèi) 部任 務(wù) 書 》形 成 需 求進(jìn) 行 溝 通內(nèi) 部 任 務(wù) 書部 門 負(fù) 責(zé) 人審 批 《 內(nèi) 部任 務(wù) 書 》審 查 評 估 需求形 成 《 內(nèi) 部任 務(wù) 書 》 意見應(yīng) 用 管 理 組織 進(jìn) 行 任 務(wù)登 記任 務(wù) 管 理 表軟 件 開 發(fā) 組織 進(jìn) 行 任 務(wù)實 現(xiàn)軟 件 開 發(fā) 組織 提 供 驗 收測 試 程 序 包應(yīng) 用 管 理 組織 構(gòu) 建 驗 收測 試 環(huán) 境組 織 進(jìn) 行 驗收 測 試驗 收 報 告 書程 序 下 發(fā)生 成 文 檔 最終 版 本 歸 檔 系統(tǒng)變更流程描述： 一、概要說明 系統(tǒng)變更范圍 目前全系統(tǒng)內(nèi)自有應(yīng)用系統(tǒng)按來源可分為兩類：由總公司組織開發(fā)完成的應(yīng)用系統(tǒng)和由省公司組織開發(fā)完成的應(yīng)用系統(tǒng)。對于上述兩類已上線應(yīng)用系統(tǒng)，均會因下面三種原因產(chǎn)生系統(tǒng)變更 需求： ? 功能完善維護(hù) 業(yè)務(wù)部門由于業(yè)務(wù)發(fā)展或業(yè)務(wù)處理的需要，所產(chǎn)生的對系統(tǒng)的現(xiàn)有功能進(jìn)行修改、完善的需求。 ? 系統(tǒng)缺陷修改 系統(tǒng)設(shè)計和實現(xiàn)上的缺陷會 引發(fā)業(yè)務(wù)操作中的異常。對系統(tǒng)缺陷進(jìn)行修復(fù)的需求。 ? 統(tǒng)計報表生成 業(yè)務(wù)部門統(tǒng)計報表數(shù)據(jù)生成的需求。所要求的統(tǒng)計報表數(shù)據(jù)不能夠通過應(yīng)用系統(tǒng)現(xiàn)有功能提供。 這些報表有的只是一次性使用，有的需要經(jīng)常使用。 需求方和維護(hù)方 為保證應(yīng)用系統(tǒng)與業(yè)務(wù)管理要求的一致性，系統(tǒng)變更需求只能由特定的需求方形成并提出，由特定的維護(hù)方接受并處理。 需求方以外的各個部門，如果形成系統(tǒng)變更需求 ，必須先提交給需求方，經(jīng)采納后再由需求方提出。 信息部門如果接到未按本制度要求的途徑提交的系統(tǒng)變更需求，應(yīng)向提出方解釋不能受理的原因，并就提交方式按本制度要求向提出方提供建議。 三類系統(tǒng)變更需求的需求方和維護(hù)方，在流程描述中具體說明。 二、流程描述 系統(tǒng)變更流程按照需求類型分別以功能完善維護(hù)、系統(tǒng)缺陷修改和統(tǒng)計報表生成三個子流程進(jìn)行描述，各個子流程同時適用于總公司開發(fā)系統(tǒng)和省公司開發(fā)系統(tǒng)。 流程中涉及的 《內(nèi)部任務(wù)書》、《外部任務(wù)書》和《驗收報告書》的使用細(xì)則，參見《任務(wù)書填寫說明及流程說明》。 ㈠ 、功能完善維護(hù)子流程 功能完善維護(hù)子流程由 任務(wù)提交和接受、任務(wù)實現(xiàn)、任務(wù)驗收和程序下發(fā)四個階段構(gòu)成。 任務(wù)提交和接受 功能完善維護(hù) 需求的需求方為應(yīng)用系統(tǒng)構(gòu)建時提出需求的業(yè)務(wù)部門，維護(hù)方為負(fù)責(zé)按照需求實際構(gòu)建應(yīng)用系統(tǒng)的信息部門。以總公司開發(fā)的業(yè)務(wù)系統(tǒng)為例，需求方是總公司業(yè)務(wù)管理部，維護(hù)方是總公司信息技術(shù)部。 需求應(yīng)滿足一定要求。具體規(guī)范見《系統(tǒng)變更需求規(guī)范》。 流程如下： ① 、需求形成 需求方根據(jù)業(yè)務(wù)發(fā)展或業(yè)務(wù)處理