為規範資訊系統的開發內容，保證資訊系統開發的可執行性和嚴肅性，特制訂本管理制度。
一、 崗位和職責
1、 資訊系統關鍵使用者：負責開發需求的整理及分析開發需求是否可行、業務spec文件的編寫、程式測試及終端使用者的使用培訓。
2、 業務部門總部部門第一負責人：負責開發需求的審核。
3、 大區部門經理及以上負責人：負責開發需求整理及開發需求的審核。
4、 總部資訊經理：對開發的業務需求及現有技術能力對開發需求進行評估。
5、 總部資訊總監：負責開發需求的審核。
6、 集團負責人：負責開發需求的審核。
7、 開發工程師：
1）負責協助關鍵使用者整理業務需求，根據業務spec文件開發程式，對程式全程跟蹤測試，編寫技術spec文件。
2）負責資訊系統的二次開發和**備份，確保所開發程式的完整性與可追溯性，保證程式與相關文件相符且要一一對應。
3）負責所開發系統或程式的測試、維護、更新、公升級和推廣應用等工作，對關鍵使用者和部分終端使用者進行指導、培訓、技術支援和問題解決等工作。
8、 basis顧問：負責傳輸開發程式請求並審核開發程式。
9、 開發負責人：負責開發需求的審核及開發整個過程的監督。
10、 安全審計專員：負責監督審核開發程式。
11、 文件專員：負責上傳業務spec文件及技術spec文件，以pdf格式上傳到koa系統中的資訊化專欄模組。
二、 開發總則
由各部門把需求整理後，經過與關鍵使用者及開發工程師溝通，並考慮實際情況，綜合評析後，由關鍵使用者在koa系統中發起sap程式開發管理流程，經關鍵使用者結合實際業務及系統操作審核開發需求，並寫明spec需求文件（文件格式詳見附件），經本部門負責人(部門經理)、本部門第一負責人審批（總監或副總監）、總部資訊經理和資訊總監審批、集團負責人審批、總部開發工程師處理，開發負責人進一步確定是否上傳業務spec文件，與開發工程師及關鍵使用者溝通需求是否可行，最後由開發工程師組織需求評估，確認spec需求文件(檔案內包含測試內容及測試方法)各項內容，將經過評估後確定可開發的需求轉為開發任務，並明確開發完成時間。同時，在開發流程中上傳開發spec文件，開發完成後由需求提交者和關鍵使用者在規定時間內（3天內）完成測試；如沒完成測試或無反饋資訊，開發工程師有義務跟蹤延時2天，測試通過後，完成開發需求，並釋放傳輸請求，釋放傳輸請求後由傳輸請求管理員傳輸到正式系統，流程結束後抄送相關人員。
三、 開發細則
1、 開發類、傳輸請求、程式名的使用和命名規則：
1）開發類的使用：
測試程式使用本地物件開發類 $tmp, ecc6系統正式開發任務使用 zjh開發類，sap bw系統開發任務使用zjh_bps，sap hr系統開發任務使用zhr，邏輯資料庫使用pnp。
2）程式名的命名規則：
sap ecc系統：測試程式的命名規則使用 『ztest+4位編號(程式描述)』，正式程式的命名規則使用 『z模組名+r(sap報表)或f(sap單據)或g（功能）+4位編號(程式描述)』, 如 『zmmr0001』。
bw系統：
a) 系統內開發：
測試程式的命名規則使用 『ztest+4位編號(程式描述)』，正式程式的命名規則使用 『z模組名+ f(sap報表)或g（功能）+4位編號(程式描述)』, 如 『zfir0001』。
b) bw query開發：
測試程式的命名規則使用 『ztest+4位編號(程式描述)』，正式報表的命名規則使用 『z模組名+『_』+4位編號(程式描述)』, 如 『zfi_0001』。
2、 自定義開發程式：
程式表頭需要標明此程式的用途、適用範圍、開發日期、開發人、關鍵變數等資訊。
例如：* system : erp專案
* module : hr人力資源
* programid : zhr***
* program : 程式描述
* author : ***
* date2011.8.10
* description : 人力花名冊報表
* modified recorder :
* date c#no authorcontent
* 修改日期 c票或變更文件id 修改者修改內容
3、 修改系統標準程式：
針對標準程式修改有如下要求：
1）對原始程式進行備份。
2）標記具體修改行，並注釋修改的用途，有具體得描述、適用範圍、日期、修改人等資訊。
3）記錄修改標準程式清單，提交文件管理員儲存。
4、 開發標準：
1）完全按照業務部門的spec為標準進行開發，如有修改需要重新發起開發流程，同時進行對業務spec進行更新。
2）禁止開發人員用**對資料庫原始表進行資料update 和 delete 操作。
3）禁止從伺服器上進行資料提取和變更操作操作。
5、 開發結束：
1） sap ecc系統
需要與業務部門的申請者及關鍵使用者確定及在開發機測試系統中業務測試無誤，開發工程師編寫技術spec文件，業務spec及技術spec都完成後（對於應急程式來不及寫spec文件的傳輸需在流程中詳細說明開發原因、目的，待後期補交spec），方可由申請者在koa系統中發起sap程式傳輸流程，將程式傳入生產機正式系統。
2）bw 系統
需要與業務部門的申請者及關鍵使用者確定及在bw 開發機測試系統中實地業務測試無誤，開發工程師編寫技術spec文件，業務spec及技術spec都完成後（對於應急程式來不及寫spec文件的傳輸需在流程中詳細說明開發原因、目的，待後期補交spec），方可由申請者在koa系統中發起sap程式傳輸流程，將程式傳入bw 生產機正式系統。
6、 開發傳輸：
1）測試資料：
發起傳輸流程中，應附測試資料。
2）spec文件：
技術及業務spec需上傳koa系統資訊化專欄模組中開發文件分類中。
3）安全審計：
由資訊部安全審計專員對程式及spec（無spec則流程中所述開發原因及目的）進行監督審核。
4）開發傳輸流程步驟：
開發邏輯及介面與業務部門需求達成一致後，同時開發的程式經過系統測試，最後由資訊部安全審計專員審核無誤後，申請人需要發起傳輸流程，basis顧問需要看到測試資料及在koa系統中找到對應的技術spec及業務spec後（無spec則流程中所述開發原因及目的），方可傳入到正式系統正式使用。
a) sap ecc系統
b) bw 系統
7、 開發文件管理：
1）文件命名規則：
a) sap ecc系統
技術spec文件命名規則為：j_sap技術_模組_事務**_簡要描述
業務spec文件命名規則為：j_sap需求_模組_事務**_簡要描述
b) bw 系統
技術spec文件命名規則為：j_bw技術_模組_4位編號_簡要描述
業務spec文件命名規則為：j_bw需求_模組_4位編號_簡要描述
c) portal系統
技術spec文件命名規則為：j_ep技術_模組_4位編號_簡要描述
業務spec文件命名規則為：j_ep需求_模組_4位編號_簡要描述
2）文件上傳注意事項：
文件上傳需要標明上傳時間及如有更新也需要標明時間。
3）開發文件上傳步驟：
開發過程中的業務spec及技術spec最終版本需要由開發工程師提交資訊部文件專員，最終以pdf格式上傳至koa系統知識文件中，如程式有改動，開發工程師需要及時更新，在由資訊部文件專員上傳至koa系統中的知識文件中，保證開發的邏輯及實現結果與實際相符，確保資料準確性，提高工作效率。
4）開發工程師提交開發清單
為了掌握各業務模組的需求變化及各開發工程師的工作量考核，是否按時、按質、按效的完成業務部門提出的開發任務，每月提交一次，由開發負責人協同安全審計專員共同檢驗開發成果，檢驗結果計入年底考核標準一項。
清單格式如下：
開發型別（報表\表單\功能\qurery\portal頁面）開發模組、程式技術名稱、程式描述、申請人、開發人、完成狀態、開發時間、完成時間。
資訊管理部
資訊系統開發管理制度V0
愛登堡 中國 內部控制系列檔案 資訊系統管理 資訊系統開發管理制度 第 1 版 更新一覽表 注 1.本表記錄每次制度修訂的內容和版本號 2.每次制度更新時，修訂 審核和批准記錄必須完整，日期必須註明。目錄1.0 目的 2 2.0 適用範圍 2 3.0 資訊系統開發流程 3 4.0 各部門職責 3 5...
商場管理系統開發
摘要 隨著資訊產業的飛速發展，資訊化管理已經引入並應用到各行業管理領域尤其是對於各大商場。企業若想在激烈的競爭中勝出就必須擁有一套完善的且合適自身特點的資訊化管理系統，傳統的人工管理費時，費力，效率極其低，不能夠與現代經濟發展同步，所以我們就企業的發展需要開發了針對商場的商場管理系統，它檢索迅速，查...
校園管理系統開發
重慶理工大學 課程設計 課程物件導向程式設計 題目校園管理系統開發 學院 系 電腦科學與工程學院 班級36 2 q q 9 6 3 2 5 3 6 8 3 1 系統分析 1.1 功能模組分析 賬戶管理 進入系統，首先系統會自動檢測你是否有註冊過賬戶，未註冊，顯示註冊介面。出入賬號，密碼，驗證問題及問...