开发工作规范0911v4Word文档下载推荐.docx
《开发工作规范0911v4Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《开发工作规范0911v4Word文档下载推荐.docx（12页珍藏版）》请在冰点文库上搜索。
1）汇集用户开发新增和变更需求，提交集团信息部批准；
编写并提交开发或变更功能说明书；
实施系统上线前必须配合做好回归测试。
2）针对运维单位提出的客制化需求进行必要性分析；
在变更申请明确注明是否属于“新增/修改”开发需求，并提出“共性/个性”开发建议，以及是否进行开发的建议；
3）负责向集团业务部门汇报运维客制化开发需求；
4）负责向信息部提出开发申请，经审批同意后才允许进行开发；
5）负责按照XX功能说明书模板，编制功能说明书，负责与开发顾问沟通功能说明书；
6）负责运维开发程序的测试工作和测试文档的编写工作；
7）负责运维开发功能操作手册的编写和培训工作；
8）负责运维开发传输CR申请清单的备份存档。
3、XX信息开发组职责
1）负责按照开发工作规范，编写实施和运维线的开发程序；
2）负责实施和运维线的开发技术说明书的编写工作；
3）负责实施和运维线开发retrofit相关工作，解决开发冲突；
4）与项目组和运维顾问进行沟通，确保开发符合用户使用要求；
5）负责测试文档验收和确认。
6）负责实施和运维线各系统环境的开发传输请求管理工作，确定传输顺序，负责传输申请工作，提供开发传输审批需要的各种文档；
4、总体组开发管理职责
1）负责集团项目文件服务器中开发文档库（包括功能说明书、技术说明书、测试文档）的统一管理工作，包括文档版本、文档命名规范；
2）负责组织各实施项目组顾问进行讨论，对开发的差异进行统一，对实施项目的开发合理性和必要性进行控制，要求实施项目组对每项开发的合理性和必要性提出解释说明；
3）与模板组配合，组织实施项目组向集团业务部门汇报客制化开发差异情况；
4）负责功能说明书、技术说明书的质量审核工作，抽查程序质量，检查是否符合XX程序编制规范；
5）负责开发传输的监控工作，审核回归测试环境开发传输清单，检查传输请求是否符合规范；
6）负责对开发计划和开发清单进行统一管理，及时了解各项目组需求，并与XX信息开发组沟通，确保每项工作按时完成；
7）负责每周向集团汇报开发进展、开发变更、以及开发文档质量情况；
8）负责文档的以及开发测试、传输制度；
5、各实施单位和运维单位职责
1）对于实施开发需求，要编制需求说明书，并对开发需求进行签字确认；
2）对于运维开发需求，要求在“需求变更单”上对需求进行明确，并签字确认；
3）负责开发完成后的测试和验收工作，并书面签署开发测试文档。
6、集团业务部门职责
1）根据实施项目组和运维顾问的开发建议，确定是否允许进行开发，或者集团内统一考虑开发；
7、集团信息管理部职责
1）负责组织和修订开发工作规范；
2）负责最终审批实施项目组和运维的开发清单和开发变更申请单；
3）负责审批开发变更申请；
4）负责生产机开发传输清单的最终审批；
5）负责开发管理相关工作的考核。
第四条、具体工作要求
1、开发环境
运维线开发环境为DEV-200，实施线的开发环境为TD1-350。
2、实施项目开发需求管理
各实施项目组需要认真了解、梳理、分析并统计用户开发需求，详细了解集团已开发的程序功能，按照合理性和必要性原则编制开发清单，由实施项目经理统一提交给总体组开发管理专员。
总体组开发管理专员汇总各实施项目的开发需求，以模块为单位，组织各实施组模块顾问共同讨论，合并相同或者类似的开发需求，对不合理的开发需求提出质疑，并提出参考意见。
总体组开发管理专员形成该模块最终的开发清单后，注明开发需求单位，列入项目组差异汇报内容，上报给集团业务部门进行审核；
集团业务部门审核通过后的，总体组开发管理专员将清单提交信息部进行审批，信息部确认后才能进行具体的开发工作。
开发组接到已审批的开发清单后，组织开发资源。
各模块根据开发计划的优先顺序，开始进行功能说明书的编写。
3、运维的开发需求管理
ERP支持中心顾问接到运维单位的“需求变更单”后，需要对新增和修改需求进行认真评估，结合系统中已开发的程序，按照合理性和必要性原则，提出“开发建议”和相关理由，开发建议包括修改原有开发，建议集团统一考虑共性开发，不建议开发、新增个性开发几种情况，并更新到“需求变更单”中。
运维顾问及时将开发变更需求情况与集团业务部门进行汇报，征求业务部门的意见，并获得业务部门的同意。
与业务部门汇报完毕后，报信息管理部审批通过后才能最终提交给开发组进行开发。
4、开发计划编制
总体组开发管理专员负责开发计划编制工作，开发计划中必须填写：
开发需求单位、模块、类型、描述、复杂性、开发优先级别、功能说明编制人，测试人等内容。
开发项中如有参考程序，应注明参考程序名称或TCODE。
各模块可以注明开发先后顺序，如不注明，则按优先级别高低区分。
总体组开发管理专员负责每周更新开发计划与进度，向集团项目办公室进行汇报，同时发送给各实施项目组项目经理和顾问。
开发计划一旦编制并确定后，各实施项目组和开发组应该严格遵守，如有变更需及时告诉总体组开发管理专员。
5、开发计划变更流程
开发计划变更包括开发项的增加和删除，须由各实施项目经理提报给总体组开发管理专员。
总体组开发管理专员向集团信息部汇报，经信息部批准后方可更改。
开发清单中的更改，须通过状态和标注颜色以作区别。
6、开发过程管理
1）实施项目的开发过程管理
各实施项目组每个模块需指定一名开发对口人，与总体组开发管理专员对接《功能说明书》相关事宜。
如果是已有程序的修改的功能说明书，应从总体组开发管理专员的取得已有功能说明书的最新版。
总体组开发管理专员接到功能说明书后进行审核，对不符合要求的功能说明书打回项目组。
符合要求的功能说明书，发给XX信息开发组负责人，明确开发完成的时间，同时存档到集团项目文档服务器。
开发过程中，经与开发人员沟通后，如果对功能说明书产生变动，实施项目组顾问需要修改、补充功能说明书内容，应从集团项目文档服务器获取最新版，修改后的功能说明书再存放到项目文件服务器。
每修改一次，版本需要变动一次。
开发人员完成程序的编码后先自行初步测试，然后提交项目组业务顾问测试。
业务顾问编写测试文档需关键用户确认，完成后通知总体组开发管理专员，并将测试文档存档到文件服务器。
开发完成后，开发人员需将相关的《技术说明书》存放到集团文档服务器中，如果中间有变动，需要进行版本控制。
总体组开发管理专员定期对技术文档、程序代码编写质量进行检查，检查结果及时反馈给项目管理办公室领导。
2）运维的开发过程管理
集团信息部同意开发需求变更后，如果针对原有的开发调整，运维顾问、开发人员需从集团文件服务器中获取最新版本的功能说明书和技术说明书，编写完成后需要将最新版本上传到文件服务器。
开发完成后，运维顾问负责提交测试文档到文件服务器中。
7、功能说明书编制要求
1）对功能说明书的要求
功能说明书必须包括以下部分：
功能信息、版本控制、用户签字、业务需求、功能设计。
功能说明书必须对程序功能明确界定，文档语言要求清晰简洁，语法通顺。
功能说明书能向开发人员清楚展现开发需求、程序功能，要详细描述用户界面、数据源对应的表和字段、数据之间的运算关系及输出表达形式。
增强需求应注明出口和增强点。
功能说明书是开发组开发的依据和实现目标，并可用于评估程序复杂程度及控制开发进度。
各模块顾问写好功能说明书（包括变更）后，应上传到文档服务器中相应模块功能说明书目录中，并需由模块组长或项目负责人通过邮件发送到开发组长，开发组长接到功能说明书后，经技术审核及工作量评估，安排开发人员开发。
未审核通过的功能说明书退回原功能说明书提交人修改，修改完成后，再次提交直到审核通过后，方可交由开发人员开发。
关于报表及表单相关需求，各模块除了提供开发功能说明书外，还要提交报表及表单样式，并经集团相关部门领导审核后，才能提交开发组开发。
2）功能说明书的版本控制
功能说明书的变更包括业务需求的变更及功能设计的变更。
业务顾问必须将变更功能说明书同时提交开发组长及对应开发人员，才能进行变更的开发。
不同版本应标记不同的版本号，版本号需标记为V1.0、V2.0等。
高版本的说明书必须在最新的版本基础上改写，如V3.0应在V2.0基础上改写，新改写的内容必须以红色文字表示，以标明差异。
8、技术说明书编制要求
技术说明书由开发人员负责编制，用于描述客户化开发程序的技术解决方案和方法，实现功能说明书描述的业务需求向编程技术转换。
技术说明书针对功能说明书中描述的业务需求，定义详细的技术实现手段和逻辑，文档语言要求清晰简洁。
技术说明书是开发技术的总结，也是运维变更、维护的参考依据，技术说明书有助于开发人员积累开发经验，提高程序开发效率。
技术说明书应该在开发过程中通过记录、积累素材及截屏，逐步编写、修订和改进，在开发测试通过后予以完善并定稿。
技术说明书是连接功能说明书与代码的纽带，开发人员编制完成技术说明书后，由开发组长进行审核，以确保文档质量。
9、编程规范
开发顾问应严格按照开发流程及编程规范编写程序代码，实现功能说明书中相应的要求和业务逻辑。
开发完的程序由开发组长检查代码的规范性，不合规范需要开发顾问重新更改，直到符合规范。
程序要结构清晰、逻辑严密、注释详细。
要注意提高程序运行效率。
各模块开发内容需按模块归类，如ZMM00。
程序及TCODE命名规则：
∙针对SAP试点单位及二期推广（除双钱集团以外）的单位，开发或变更流水号使用0、1、2开头编号，新建开发使用8开头编号。
∙针对双钱集团，新建及变更需求流水号使用3开头编号。
∙针对三期推广项目，新建需求流水号使用5开头编号。
具体编程规范详见附件四。
10、ABAP程序测试
开发完成后，由程序人员进行初步测试，然后转给实施项目顾问/运维顾问，先在开发环境（实施TD1、运维DEV）中进行功能测试，没有问题后，可传到测试环境（实施TQ1、运维PND）中，再进一步测试。
只有在PND中经过回归测试，确定没有问题后，经集团审批通过才能传到正式环境（PRD800）。
测试人员在进行功能测试时，需要提交测试文档备案。
具体测试文档格式详见附件五。
11、ABAP运维线开发传输要求
1）传至测试环境（PND500）
由测试人员在DEV400测试通过后，通知开发顾问可以传测试环境。
开发顾问在SLM中释放请求，并作Retrofit，由BASIS在每周三集中传输到测试环境（PND500）。
当用户要求紧急传输时，开发顾问向XX信息开发组负责人提出请求，由他通知BASIS紧急传输。
测试人员依据需求在500测试，测试成功，测试人员XX信息开发负责人提交传输请求报告及测试文档。
2）传至正式环境（PRD800）
运维线开发由测试环境传到正式环境需由XX信息开发负责人向集团信息部请求，集团信息部批准后通知BASIS传输。
BASIS在每周五集中传输到生产环境（PRD800），当用户要求紧急传输时，须由开发顾问（测试人员）向XX信息开发负责人提出请求，由XX信息开发负责人向集团信息部请求紧急传输，集团信息部批准后才能通知BASIS传输。
12、ABAP实施线开发传输要求
1）传至测试环境（TQ1550）
测试人员在TD1测试通过后，通知开发顾问可以传测试环境；
开发顾问在SLM中释放请求，由BASIS每天集中传输到测试环境（TQ1550）；
当用户要求紧急传输时，须由开发顾问向XX信息开发组长提出请求，由开发组长通知BASIS紧急传输。
2）传至回归测试环境（PRN800）
PRN800用于模拟运行、用户培训及回归测试。
业务组要传开发至PRN800必须提供开发传输申请及TQ1550中的测试文档给开发组进行审核。
实施项目上线前，必须保证有2周左右的时间进行集中Retrofit冲突处理，并保证业务顾问有1周左右时间进行回归测试。
Retrofit完成后的传输将向TQ1、PND和PRN传输。
Retrofit的问题全部解决并经回归测试通过后，才能申请把最终的开发内容向PRD800传输。
3）传至生产环境（PRD800）
实施系统的开发包向PRD800的生产机传输，传输请求由开发组长（确认Retrofit处理完成）会同实施项目经理（确认实施开发测试完成）、运维部门经理（确认回归测试完成）向集团信息部提出申请，经集团信息部批准后，将实施的开发包向PRD800传输。
传输请求报告模板参见附件六。
13、ABAP开发的Retrofit管理
1）Retrofit处理及其必要性
Retrofit是SAP开发的适应于运维和实施的开发、测试环境分开，生产系统合并的一种管理系统。
目的是使运维和实施的开发、测试服务器的配置及开发内容保持同步。
它能比较二者的差异，并用绿、黄、红灯表示差异的程度。
但它的功能有限，它既不能保证找出所有差异，更无法代替人工来消除差异。
由于运维和实施2条线分开，2条线可能对同一开发需求进行多次修改变更，因此与开发有关的2条线上的程序、接口、表、数据元素、屏幕、打印的smartform格式、增强、替换等会发生功能冲突。
如果在实施系统上线前不解决这些冲突问题，一旦实施系统的应用开发传入PRD生产机，就会严重破坏已运行SAP应用的单位的正常业务工作。
2）Retrofit操作规程
1、进SLM-SCMA-TASKLIST-OTHERTASKLIST-选相应周期及开发系统新建请求号。
2、将开发系统中新建程序或变更程序放在上述申请的请求号下，并将所有需要的自建数据元素、表均放在此请求号下。
3、传输请求：
先运行SE09把要传输的请求号里的任务清单释放，再到SLM里去释放要传输的请求号。
注意不要释放不是自己的请求号。
4、运维系统执行Retrofit操作：
执行Retrofit之前必须切换回运维的Tasklist再运行STARTRETROFIT。
5、实施项目要使用运维线已上线的开发内容时，必须复制运维线最新的开发内容至实施线进行变更，开发完成进行测试。
特别注意不可改变运维线上的程序功能，程序中实施项目的新增内容必须有明显的注释信息。
注意：
系统不提供实施项目开发的Retrofit操作功能。
6、实施项目上线前，必须保证有2周左右的时间进行集中Retrofit冲突处理。
运维线上Retrofit操作积累的红灯或黄灯问题仅可作为Retrofit冲突处理的一个参考。
7、开发顾问每人检查自己在TD1做的开发，包括报表程序、增强、接口、打印，除去以本实施项目编号开头的程序外，列出清单，并与Retrofit操作积累的红灯或黄灯清单对照，确定自己的相关工作任务清单，不得遗漏，由于遗漏发生上线事故，要追究责任。
注意需在清单中列出最后一名修改者姓名。
8、最后一名修改者负责此项开发的retrofit工作（称为责任工作任务）。
每个开发顾问要列出自己的责任工作任务清单。
开发顾问处理retrofit冲突工作的根本目的是：
整合实施线和运维线对同一开发对象的需求，保证此开发对象在传输到PRD800后能同时满足实施线和运维线用户的需求，保证程序正确运行。
9、完成责任工作任务清单内的一项任务就把黄灯、红灯去掉。
把有关的内容打成一个请求包，向TQ1、PND和PRN传输。
在传输后要请运维和实施的顾问进行测试。
发现问题要重新处理，重新传输。
测试成功后，须在自己的责任工作任务清单中标志“完成”。
10、回归测试在PRN上进行，只有Retrofit冲突全部解决，回归测试通过后，开发内容才可传PRD800，实现实施项目正式上线。
14、其他
BI的开发工作遵循集团统一的闭环管理要求，但具体的程序编制工作，详见《BI应用开发规范》。
第五条、解释和发布
本规范由集团信息管理部负责解释。
2014年9月18日
附件一：
开发计划格式：
附件二：
功能说明书样式
附件三：
技术说明书样式
附件四：
编程规范：
附件五：
测试文档格式
附件六：
传输请求报告：
升级会员 