信息系统开发管理制度
为规范信息系统的开发内容，保证信息系统开发的可执行性和严肃性，特制订本管理制度。

一、岗位和职责
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 : ZHRXXX
* Program : 程序描述
* Author : XXX
* Date : 2011.8.10
* Description : 人力花名册报表
********************************************************************
* Modified Recorder :
* Date C#NO Author Content
* ----------- ------- ------------------ ------------------
* 修改日期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页面）开发模块、程序技术名称、程序描述、申请人、开发人、完成状态、开发时间、完成时间。

信息管理部。