abc集团软件系统开发管理规定。
一、 目的。
规范营运管理及信息化中心软件开发流程，提高软件开发质量，降低团队成员的沟通难度，降低软件的维护难度，提高软件项目成本及交期的可控性。
二、 范围。
适用于营运管理及信息化中心2023年10月1日后所有的软件开发项目及开发部、信息部所有成员。
三、 软件开发流程。
it部软件开发流程共包括：启动、需求获取、需求分析及整理、设计、编码实现、实施、维护七个阶段。流程图如下：
四、管理规定。
1. 启动。
4.1.1 启动软件项目开发团队至少包括一名信息部经理，一名程序员和需求部门安排的熟识业务流程的人员。
4.1.2 信息经理及程序员由营运管理及信息化中心总监指定，需求部门业务人员由需求部门负责人指定。
2. 需求获取。
4.2.1 项目成员主要以观察、实习、访谈及会议的形式获得需求。项目成员在生产或办公现场观察、实习时，需要遵守公司相关管理规定，不得干扰他人工作。
4.2.2 项目成员在提出访谈前应该收集与当前系统相关的所有在用**及单据，收集到的**及单据必需是已经使用过的，如果不能获得原件，可借出复印。
4.2.3 访谈应该提前预约，在得到用户同意后才能进行访谈。访谈的地点应尽量安排在用户办公区，除非用户的工作环境确实会影响访谈效果。
4.2.4 访谈前需要做好充分的准备工作，列出问题清单，严禁毫无准备地进行访谈，浪费用户时间。
4.2.5 首次需求访谈原则上只由信息部人员参与，不需要程序员直接参与，信息部经理记录需求访谈的内容。
3. 需求分析及整理。
4.3.1 信息部经理或程序员在进行充分的调研后需要撰写《需求分析规格说明书》,并整理功能点清单。
《需求分析规格说明书》的格式需要按《需求分析规格说明书模板》提供的格式编写。《需求分析规格说明书》编写完毕后需要提交项营运管理及信息化中心总监预审。
4.3.2 召开需求评审会需要有营运管理及信息化中心总监及软件项目开发团队参与。
4.3.3 信息部经理在oa走“软件开发申请专用流程”并提交《需求分析规格说明书》作为附件。oa流程必须转需求提出部门负责人进行审批。
4.3.4 信息部经理或程序员根据需求oa评审意见修改《需求分析规格说明书》，直到获得用户代表或公司领导的确认。
4.3.5 在需求分析与整理期间，用户可以主动提出需求，信息部经理应该更新《需求分析规格说明书》相关信息。
4.3.6 如果在oa评审中或以后用户提出了较多的新需求或对原来提出的需求有重大变更，信息部经理在修改《需求分析规格说明书》后应该再次提交oa审批。
4. 设计。
4.4.1 程序员根据《需求分析规格说明书》编写《开发计划书》，说明所开发软件各程序员分工及各阶段工期。
4.4.2 程序员根据《需求分析规格说明书》设计界面原型，对于一些不太直观的功能需要写一些简单**，以支持界面功能演示，这些**在编码过程中可能继续使用，也可能被丢弃。
4.4.3 程序员根据界面用户代表的讨论成果修改界面原型，直到得到用户代表的确认。如果牵涉到需求变更，还需要修改《需求分析规格说明书》。
4.4.4 在用户确认了界面原型后，程序员进行数据库设计。
4.4.5 数据库设计完成且通过预审后，项目经理或程序员编写《详细设计说明书》，《详细设计说明书》的格式需要按《详细设计说明书模板》提供的格式编写。
4.4.6 对于不太复杂的系统，在得到软件开发组负责人允许的情况下，可将《详细设计说明书》的编写工作与**编写工作并行进行，但在申请测试前必须完成。
5. 编码实现。
4.5.1 在编码过程中，如果用户有新需求或需求变更，必须向信息部经理提出书面申请，申请格式参见《需求增加变更申请模板》，在获得同意后，项目经理或程序员修改《需求规格说明书》及《详细设计说明书》。
编码期间对《需求规格说明书》的修改需要使用“修订”的方式。
4.5.2 **初稿完成后，编码者需要自己测试**，只要有可能，每行**都应该被测试过。
4.5.3 程序员测试**无误后开始编写《用户操作手册》，《用户操作手册》需要按《软件操作手册模板》提供的格式编写。
4.5.4 在完成《需求分析规格说明书》、《详细设计说明书》、《用户操作手册》、程序**后，信息部经理或程序员开始协助测试员进行整体集成测试。
4.5.5 整体集成测试的计划应该尽早安排，信息部经理应该组织信息部相关人员进行测试。
4.5.6 系统规模较大时，在获得信息部负责人同意后，程序员也可将系统分模块提交测试，但被提交测试模块的相应文档必须齐全。
4.5.7 测试人员在得到软件项目的**、《需求分析规格说明书》、《详细设计说明书》、《用户操作手册》、《测试计划》后开始测试。
4.5.8 测试员主要采用黑盒测试法进行**测试，但对一些关键**也可采用白盒测试。
4.5.9 如果程序员提供的文档或**不符合开发部相关的文档规范，或质量太差（如文档太过简略、前后矛盾、明显不合逻辑，**bug太多等），测试员应拒绝测试，并告知软件开发项目负责人。
4.5.10 测试员在测试过程中应该与程序员保持良好沟通，必要时可以要求程序员帮助搭建测试环境，讲解程序的操作方法及一些复杂程序的运算逻辑。
4.5.11 无论测试通过与否，测试员都应该以文本的形式正式通知信息部经理。
6. 实施。
4.6.1 系统上线需要严格按照集团信息安全管理规定进行（拟定相关规定）。
4.6.2 用户在试用程序的过程中如果发现问题，需要及时反馈给信息部经理，程序员不接收任何口头提出的修改需求。
4.6.3 在试用期间，如果用户提出的修改要求属于新增需求或需求变更的范畴，必须向信息部经理提出书面申请，申请格式参见《需求增加变更申请模板》，在获得同意后，信息部经理或程序员修改《需求规格说明书》，在得到用户书面签名确认后才能修改《设计说明书》，编写与新需求相关的**。
试用期间对《需求规格说明书》的修改需要使用“修订”的方式。
4.6.4 如果有新增需求或需求变更，程序员在修改了《需求规格说明书》、《详细设计说明书》、《用户操作手册》以及程序**后需要提交测试员重新测试，要求参见实现部分。
4.6.5 用户试用无误，且停止旧的业务处理流程后，程序进入正式使用阶段。
7. 异人维护。
4.7.1 程序进入正式使用阶段后，信息经理组织召开验收评审会，需向用户代表阐述系统应用现状，并请用户对系统进行评分。
4.7.2 外部验收评审通过后，信息部经理需组织信息部实施人员交接异人维护。
异人维护必需具备的文档有：《需求分析规格说明书》、《用户操作手册》，《用户操作手册》,《报表说明》。项目经理需要在《用户操作手册》中写明本系统的维护人及****。
维护接手人由信息部经理指定。
4.7.3 维护接手人在收到信息经理提交的资料后需在十五个工作日内明确答复文档是否合格。如文档不符要求，需及时反馈意见并退回程序员修改。
4.7.4 维护人员在进行系统维护时需要及时登记《系统维护日志》，系统维护日志的格式见《系统维护日志模板》。
4.7.5 维护期间，如果用户需要新增需求或修改需求，必须向信息部经理提出书面申请，申请格式参见《需求增加变更申请模板》，在获得同意后，程序员安排开发，参见开发流程中的相关管理规定。
五、 软件质量控制。
1. 软件项目经理负责项目开发过程中的文档规范及**规范，需进行日查、周查或不定期抽查，发现不符规范的地方需及时通知相关人员整改。
2. 软件开发过程中，由软件开发组长负责组织中期质量评。
3. 文档规范、**规范以及中评结果也是项目奖励的依据之一。
六、 vss管理规定。
1. 运管理及信息化中心在发出软件开发通知后，需要在vss中建立项目，项目名为该系统的英文缩写（三或四个字母）。
2. vss中的项目如是非。net项目则至少包括如下子项目：bin、doc、source,否则以开发环境自动生成的文件夹为准，但需自建一个doc目录以供存放文档材料。
3. 调研、需求、设计、操作说明等文档应该存放在doc中。
4. **文件的命名及存放参见《开发部编码规范》（需要编写）。
5. 软件开发过程中，如果vss中的某文件被checkout，那么至少每两天上传到vss中一次。
七、 附件文档。
1. 需求分析规格说明书模板。
2. 详细设计说明书模板。
3. 需求增加变更申请模板。
4. 软件操作手册模板。
5. 测试计划模板。
6. 系统维护日志模板。
7. 《开发部编码规范》
8. 《集团信息安全管理规定》
软件开发流程管理规范
编制日期 2015 5 25 版本号 v1.0 征求意见稿 批准人 发布日期 项目管理的根本目的是按时 保质 保量完成预期交付的成果。项目管理要让整个组织能清楚理解项目实施的目的 影响 进度，应做到项目组所有员工都应理解项目实施的原因 意义及客户的要求。在项目管理中还能看到公司高层领导通过实际行动表...
软件开发流程规范
自控所软件项目开发流程规范。sdjt x 2011 1 范围。本流程规定了软件开发项目的基本内容和要求，适用于技术中心自动控制研究所属各项目软件开发的工作开展及软件文档的管理。2 目的。提高软件开发的效率，保证软件开发的质量。形成的软件文档在软件的使用过程中有指导，帮助，解惑的作用，尤其在维护工作中...
软件开发模式分析
作者 刘雪飞。中外企业家 中旬刊 2018年第01期。摘要 软件开发是上世纪新兴的行业，由于软件的复杂性使得开发过程漫长且质量参差不齐，随着软件技术和工程化技术的发展，软件工程也得到了较大的发展。多种开发模型应运而生，那么如何根据要开发的软件选择开发模型值得我们思考，本文就介绍比较了常见的开发模型的...