软件项目流程规范

第一篇：软件项目流程规范

软件项目开发 过程管理

姓名：李长玺 学号：S314080098

（一）项目实施方案概述

软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。软件开发计划的目的是收集控制项目时所需的所有信息，项目经理根据项目计划来安排资源需求并根据时间表跟踪项目进度。项目团队成员根据项目计划以了解他们的工作任务、工作时间以及他们所依赖的其他活动。项目管理培训可将计划分成总体计划和详细计划，总体计划中每个任务为一个里程碑，详细计划中必须将任务落实到个人。软件开发计划还应包括产品的应收标准及应收任务（包括确定需要制订的测试用例）。下面将按照每个项目实施阶段分别介绍。

（二）项目实施方案介绍

1、项目启动阶段

此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。

公司：在合同签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。公司项目组：进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。商务经理：配合公司项目组，将积累的项目和用户信息转交给项目组。将项目组正式介绍给用户，配合项目组建立与用户的联系。用户：成立项目实施组织，配合前期调研和召开启动会，签署《总体项目计划》和《项目实施协议》。

成立项目组：

部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》，并制定初步方案。

前期调研：

项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别那些个体和组织是项目的干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。

编制《项目总体计划》：

《项目总体计划》是一个文件或文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果。通常包括以下几方面内容：项目描述，项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；沟通管理计划，确定项目干系人对信息和沟通的需要：即什么人何时需要什么信息以及通过什么方式将信息提供给他们。质量管理计划，确定适合于项目的质量标准和如何满足其要求。如果有必要，可以包括上述每一个计划，详细程度根据每个具体项目的要求而定。未解决事宜和未定的决策。

启动会：

项目组与用户共同召开的宣布项目实施正式开始的会议。会程安排如下：共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》。项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；项目实施中用户的参与和领导的支持的重要作用；阶段验收、技术交接和项目结束后如何对用户提供后续服务。

2、需求调研确认阶段

此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。需求调研阶段具体包括如下内容：

1、进行需求调研准备

2、编制《需求调研计划》

3、内部评审是否通过《需求调研计划》，项目组、部门经理、商务等人员根据合同要求和项目实际情况对《需求调研计划》草稿进行评审，如评审通过，则在稍后的时间内签署，如评审不通过则重新修改。

4、用户是否签署《需求调研计划》，如用户签署《需求调研计划》，则作为以后需求调研工作的指南。否则重新修改。

5、《需求调研计划》是否有变更，如果计划存在变更，则执行变更控制流程，否则按计划进行后续工作。

6、编写及发出《需求调研通知》，项目组编写《需求调研通知》，确定进行需求调研的相关事宜，发给用户，为顺利完成需求调研工作做准备。

7、需求调研，项目组以《需求调研手册》为依据，从业务流程、单据使用、打印格式、报表查询几个方面展开深入和全面的调研，并搜集用户的个性化需求。

8、需求调研分析根据调研的结果，项目组和公司其他技术部门将进一步进行分析，确定合理、可行的需求，将分析结果形成《需求分析报告》草稿。

9、内部评审是否通过《需求分析报告》。项目组、部门经理、公司其他技术部门的人员对《需求分析报告》草稿进行评审，如评审通过，则在稍后由用户签署，如评审不通过则重新修改，直至内部评审通过。

10、编写及发出《需求分析报告确认通知》。项目组编写《需求分析报告确认通知》，发给用户，确定进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。

11、用户是否确认《需求分析报告》。如果用户确认，并签署了《需求分析报告》，则需求调研阶段工作结束，进行后续的软件功能实现的工作；如没有确认，则进一步进行调研、分析，直至用户最终确认并签署《需求分析报告》。双方签署了《需求分析报告》，需求调研工作结束之后，如果用户提出新的需求或是变更已有的需求，则执行需求新增及变更流程。

3、软件功能实现确认阶段

此阶段的主要工作是项目实施人员根据需求调研阶段确认的《需求调研分析手册》中的用户需求内容进行具体软件功能的实现工作。在软件功能实现的过程中，项目实施人员将记录软件实现的详细过程。便于公司售后服务之用。每一个实施技术人员必须严格按照要求记录、存档。按照调研要求的所有功能实现完毕后，项目实施人员将编制《软件功能确认表》，将定制好软件功能待用户确认，用户根据《软件功能确认表》上的功能逐一确定软件功能是否达到要求，对不满足要求的功能，项目实施人员将会记录下来并进行功能修改，直到满足用于要求。

4、数据标准化初装阶段

此阶段的主要工作是项目实施人员指导用户进行系统标准化资料的准备工作，并对用户进行初装资料的软件操作培训，以便用户能够及时的将标准资料录入系统，初装完成后，项目实施人员会对资料初装的情况进行核查，为以后具体业务功能的开展做好基础。

5、系统培训阶段

系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。要充分认识培训的重要性和艰巨性。在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品，最终自己能够解决使用中的具体的问题。

此阶段的培训工作中将用户参加产品培训的人员划分为三个层次：决策层、技术层、操作层，对不同层次的用户参加产品培训人员的培训内容分别是：决策层：领导在实施中的作用与重要性、决策查询。维护层：系统维护知识、操作方法。操作层：操作方法。具体的培训工作流程为：

1、调研培训信息：在培训开始前3天由用户实施负责人，将参加培训的部门和人员情况填入《受训部门汇总表》、《受训人员情况一览表》。

2、编制培训计划：结合调研结果，与用户实施负责人商议具体培训内容、时间，场地，人员等。项目组编制《培训计划》。

3、签署培训计划：用户签署《培训计划》，进一步确认培训安排。

4、发培训通知：培训开始前2天，按照签署的《培训计划》，将培训内容、时间，场地，人员等信息通知用户实施负责人。

5、搭建培训环境：公司项目组在培训开始前，将培训环境搭建及检查妥当，将培训提纲及培训手册准备好。

6、组织培训：公司项目组培训负责人与用户实施负责人组织相关人员参加培训，按培训制度严格考核。由用户将考勤情况填入《培训人员签到表》。

7、培训考核：公司项目组培训负责人与用户实施负责人组织受训人员参加上机及理论考试。

8、培训总结：公司项目组培训负责人与用户实施负责人一起将出勤情况及考核情况做出总结，填入《培训及考核统计表》，及时向相关负责人汇报。

6、系统安装测试及试运行阶段

此阶段的主要工作是在用户真实环境下，对用户网络及硬件设备进行测试，对软件系统进行容量、性能压力等测试测试及试运行的目的在于确保系统各项功能均能正常使用，并且符合用户签署的《需求分析报告》中描述的需求，同时把尽可能多的潜在问题在正式运行之前发现并改正；同时目的还在于在正式运行前用户的有关人员能进一步提高操作水平，掌握操作规范。此阶段的主要工作内容为：

1、编制计划：与用户实施负责人商议具体测试及试运行时间、地点、人员等安排，项目组编制《测试及试运行计划》。

2、签署计划：用户签署《测试及试运行计划》，进一步确认测试及试运行安排。

3、发测试及试运行通知：在测试及试运行开始前2天，按照签署的《测试及试运行计划》，将时间，地点，人员等信息通知用户实施负责人。

4、搭建环境及数据准备：在试运行开始前搭建好软件环境、硬件环境、网络环境、调通线路；检查软件、硬件、网络、线路等各个环节是否有问题；

5、组织测试及试运行：用户相关各级领导给予全面配合，组织相关人员进行测试及试运行。公司项目组负责担当指挥，检查用户人员组织情况并给予指导，跟踪检查如下情况：跟踪单据流转状况；跟踪新资料登录环节；观察业务流程执行状况；观察操作人员操作表现；观察系统运行速度及异常表现；观察关键数据的正确性；及时纠正错误操作、对于新发生的问题及时与相关人员沟通，确定解决办法。

6、测试及试运行总结：测试及试运行完成，总结试运行中设备、软件的运行情况，总结试运行中业务流程和操作环节的情况，以书面总结形式将测试及试运行结果通知相关负责人。

7、总体验收阶段

此阶段是对项目总体的完成情况进行验收。验收分阶段进行，在每一项目阶段结束时，用户对这一阶段的可交付成果进行验收，在测试及试运行结束后，对系统进行总体验收。需要验收的可交付成果：主要项目阶段组成，主要里程碑可交付成果。

8、系统交接阶段 此阶段是项目实施的最后一个阶段，主要工作是软件公司项目组向用户移交软件项目，包括软件产品、项目实施过程中所生成的各种文档，并签署《售后服务协议》，项目将进入售后服务阶段。软件公司项目组还需要让用户填写《用户满意度调查表》，对软件公司项目实施人员的整个项目实施情况进行评价，软件公司将听取用户的意见，再今后的项目实施管理中进行加强和改进。

下图是整体开发过程：

第二篇：软件项目开发管理流程

研发中心项目开发管理流程

1，新项目开发管理流程

按照项目管理规范，项目管理分为：项目启动—》项目计划—》项目执行—》项目控制—》项目结尾。5个阶段。根据该管理流程和我公司实际情况，将新项目开发的管理流程制定如下图：

1.1 项目立项

项目立项阶段，首先由的项目经理编写《项目立项报告》。

研发项目立项报告模板.doc

1.2 立项评审

《项目立项报告》编写完成后，交由项目管理委员会进行立项评审，评审通过后由副总经理签字确认立项。确定需求分析和项目设计阶段的时间和人员安排。

1.3 需求分析

需求分析阶段，需要与用户交流，双方对软件需求取得共同理解基础上达成的协议。编写并完成软件需求说明书：也称软件规格说明书。

软件需求说明书模板.doc

1.4 系统设计阶段

常规的系统设计需要依次完成《概要设计说明书》，《详细设计说明书》。以下是文档的简要说明：

概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基础。

概要设计说明书.doc

详细设计说明书：着重 描述每一模块是怎样实现的，包括实现算法、逻辑流程等。详细设计说明书.doc

详细设计说明书编写完成后，项目经理应该依次编写安排项目开发工作计划。工作计划安排可以根据项目经理的习惯进行工作计划编写。建议采用project。附件为综合考务平台的工作计划安排，可以供参考：

考试考务综合管理平台工作计划.mpp。并且确定里程碑，以便在后期项目执行过程中，对其进行确认。对于大项目，建议按照项目设计流程，先进行概要设计，再到详细设计。但是对于特殊项目（项目周期较短，小项目），可以讲概要设计和详细设计阶段合二为一，编写功能，接口方案。但是值得注意的是，该方案中，仍然需要涵盖项目模块功能，用户权限和各模块实现逻辑，接口等。

项目设计开发方案.docx。

1.5 项目设计评审

设计阶段完成后，项目经理填写《项目设计评审表》，将相关文档交由项目管理委员会进行项目设计评审。通过评审后，方可进行编码工作。

项目设计评审表.docx

1.6 编码和测试用例编写阶段

项目编码阶段，项目经理需要对项目执行情况进行控制和监督，其中包括（项目输入，项目输出，里程碑）。如果由于特殊情况，如：需求变化，人员临时调配，或者其他原因导致的项目范围和时间，计划等变更，项目经理应该及时填写变更申请。并提交给项目管理委员会。作为之后项目输出验证的重要依据项目变更申请书.doc。

在此阶段，测试人员应该根据《需求说明书》，《概要设计》和《详细设计说明书》的内容，编写相应的《测试用例》。1.7 测试阶段

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到《测试申请》后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

1.8 结项评审与验证

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由研发中心副总经理进行发布确认。

项目结项评审验证表.doc

1.9 新产品发布

编写《用户手册》。方可进行新产品发布。

2，旧项目升级开发管理流程

旧项目的升级，依照如下流程：

2.1项目升级需求分析

项目需求分析，需要收集用户在产品使用过程中，已经技术人员在调试过程中的反馈作为需求分析的输入。并填写对应的项目升级需求报告表。项目升级需求报告表.doc

2.2 升级评审

将《升级需求报告》交由项目管理委员会，评审通过后，进行升级设计。2.2项目升级设计

项目负责人，根据需求报告和升级具体情况，编写升级开发方案。项目升级开发方案.docx。并安排整改工作计划。

2.3 项目升级设计评审

升级开发方案完成后，填写《项目设计评审表》，交由项目管理委员会评审。

2.4 编码

按照项目升级开发方案进行编码设计，如果编码工作中，发生特殊情况需要变更计划，或者项目范围等，同样需要提交《变更申请》，作为项目验证的基础。同样，此阶段，测试人员应该编写或者修改相关测试用例。

2.5 测试

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到测试申请后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

2.6 升级输出评审

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由副总经理进行发布确认后。

第三篇：软件项目变更管理流程

变更管理流程 2 概述.......................................................................................错误！未定义书签。变更流程.................................................................................................................2

2.1 摘要.........................................................................................................................................2 2.2 提交变更申请.........................................................................................................................3 2.3 审核变更申请.........................................................................................................................4 2.4 识别变更可行性.....................................................................................................................4 2.5 批准变更申请.........................................................................................................................4 2.6 实施变更申请.........................................................................................................................4 变更任务.................................................................................................................5

3.1 变更申请人.............................................................................................................................5 3.2 变更经理.................................................................................................................................5 3.3 变更可研小组.........................................................................................................................5 3.4 变更审批小组.........................................................................................................................5 3.5 变更实施小组.........................................................................................................................5 5 变更登记.................................................................................................................6 变更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如：

变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。

对项目的变更管理是通过对以下五个关键步骤的实施引入的。，:  提交和接收变更申请  审核和记录变更申请  确定变更申请的可行性  批准变更申请

 实施和结束变更申请变更流程

对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交变更申请

本步骤中项目团队中的任何成员都可以提交项目变更申请，需要完成以下工作：

 变更申请人识别项目中任何方面的变更需求（如范围、可交付成果、时限、组织）. 变更申请人完成变更申请表（CRF），并将其呈交变更经理。变更申请表对需要进行的变更做一概述，包括：

 变更描述

 变更原因（包括商业驱动） 变更利益  变更成本

 变更带来的影响  支持性文件

2.3 审核变更申请

本步骤授权变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是：

 呈交的可选择变更数目Number of change options presented  申请变更可选反性的复杂程度Complexity of the change options requested  提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 识别变更可行性

本步骤涉及完成一份完整的变更可行性研究，以确保对所有的变更可选项进行调查并上报，变更可行性研究包括对以下各项的定义：

 变更需求

 变更可选项Change options  变更成本及利益

 变更风险及事项Change risks and issues  变更带来的影响  变更的建议和计划

对对可行性研究进行认真审核以确保研究是切题的，同时确保（经过变更后的）最终的可交付成果是可以通过的—那研究报告就可以上报变更审批小组了。变更经理将整理所有变更文件并报变更审批小组做最终审核。这些文件包括：:  原始的变更申请表

 已通过的变更可行性研究报告  所有支持性文件

2.5 批准变更申请

本步骤涉及变更审批小组对变更申请的正式审核。变更审批小组可能做出下列任何一种结论：

 拒绝变更Reject the change  要求与变更相关的更多信息Request more information related to the change  批准变更申请Approve the change as requested  在特定条件下批准变更Approve the change subject to specified conditions

决定是否变更的标准大致为：

 实施变更给项目带来的风险  不实施变更给项目带来的风险

 实施变更对项目产生的影响（时间、资源、财务、质量方面）

2.6 实施变更申请

本步骤涉及对变更的全面实施，包括:       确定变更进度（如：实施变更的日期）

实施前对变更进行测试Testing the change prior to implementation 实施变更

对实施变更的成功度进行审核 就实施变更的成功度进行沟通 在变更日志中结束变更 变更职责

对项目中启动、审核和实施变更所涉及的所有资源（包括项目中或项目之外的资源）的职责和责任进行定义，如：

3.1 变更申请人

变更申请人最初意识到对项目进行变更的必要性并就此需求与变更经理进行正式沟通。其主要职责为:  及早识别对项目进行变更的需求

 通过完成变更需求表来完成对更申请的正式文件  将变更申请表提交变更经理以供审

3.2 变更经理

变更经理对一个项目中所有的变更进行接收、记录、监测和控制。其主要职责为：

 接收所有的变更申请并将其记录于变更登记簿中  将所有的变更申请进行分类、优选

 审核所有变更申请以确定在提交变更审核小组前是否还需增加有关信息  确定是否需要进行一个正式的可行性研究并提交变更审核小组  通过委派变更可行性研究小组来启动变更可行生研

 对所有的变更申请进展情况进行监测以确保项目按时完成  将所有的变更申请问题和风险上报变更审批小组  就变更审批小组做出的所有决定进行下达和沟通

3.3 变更可行性研究（可研）小组

变更可行性小组负责完成由变更经理签发的对于某变更申请的正式的可行性研究，主要职责为：

 通过进行摸拟研究来确定变更可能的要素：成本、利益和变更带来的影响。 将变更可行性研究报告中的所有发现形成文字  对报告进行认真审核并批准交其上报。 将报告转变更经理以提交变更审批小组 

3.4 变更审批小组

变更审批小组决定是否批准变更经理转来的所有变更申请。其主要职责为：

 审核变更经理转来的所有变更申请  考虑所有变更支持性文件

 根据每个变更申请的相关价值决定批准还是拒绝  解决变更争议（当两个或两以上变更撞车时） 解决变更问题Resolving change issues  决定实施变更时间表

3.5 变更实施小组

变更实施小组对项目中所有变更的实施进行计划、落实和审核。变更实施小组主要负责：      计划所有变更的进度（在变更审批小组提供的总体时间框架范围内）)在实施前对所有变更进行测试 实施项目中的所有变更 实施后审核变更的成功度 在变更日志中请求结束变更 变更登记簿

变更登记簿是用于登记、跟踪变更申请进展情况的日志/数据库。描述项目变更登记簿的目的和用途，在下面插入一个真实的变更登记文本 变更模版

插入所需的每个模版（如变更申请表）以对项目中变更的效果加以启动、执行、实施和考量。

第四篇：软件项目上线发布流程

布比项目上线部署发布流程

V1.0 2017/9/14

1、目的

规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。

2、范围

适用于公司所有项目和产品

3、发布人员

开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库）测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责

*数据库操作均由DBA统一负责(或运维人员)

4、发布流程

在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。

一、提交测试

a)开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。

b)测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。

c)测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉及数据库操作可提请DBA操作。

d)记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。

e)内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。

二、预热发布

a)测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。

b)如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。

三、正式上线

a)在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。b)确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。

c)运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。d)发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。e)（紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。）。测试通过后测试人员回复邮件，发布结束。

四、应用服务监控

a)运维人员添加新增外部应用服务监控和新增云主机的系统监控 b)运维人员对相关业务保持上线后正式生产系统进行有计划地监控其服务的性能和可用性，及时发现问题处理及反馈问题。

五、总结报告

a)上线成功后，撰写或总结系统需求、架构以及开发文档进行备案。

附：上线流程图 系统上线部署发布流程开发人员测试人员运维人员开发环境调试

1、BUG修复开发自测提交测试申请

1、上线方案

2、其他上线文档确认测试版本

1、内容无误

2、无明显BUG开发负责人发起部署大会1.数据库脚本2.部署顺序3.部署时间4.回滚方案5.项目相关负责人同意上线发布上线公告邮件通知运维1.上线方案2.数据库脚本部署上线线上测试有无系统BUGY上线完成、持续监控Y执行一般修复流程（线上修复或迭代改进）是否修复NN是否为严重bugY确认回退Y执行回滚

第五篇：软件配置管理规范流程

概述 1.1 目的

本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

1.2 适用范围

本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。

1.3 术语和缩略语

1.3.1 软件配置管理（Software Configuration Management，SCM）软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。

1.3.2 配置项（Configuration Item，CI）

凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。

每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

1.3.3 基线（Baseline）

在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。

基线的主要属性有：名称、标签、版本、日期等。1.4 权限与职责 1.4.1 研发总经理助理 1）审核变更请求。

1.4.2 项目经理（Project Manager，PM）1)审核批准配置管理计划； 2)接收或拒绝小范围的变更申请； 3)召集评估变更；

4)提出配置管理的建议和要求； 5)配合配置管理员的工作。

1.4.3 配置管理员（Configuration Management Officer，CMO）1)编写配置管理计划；

2)执行版本控制和变更控制方案； 3)制定访问控制策略；

4)负责项目的配置管理工作，包括搭建环境、权限分配、配置库的建立、配置项的控制等；

5)配置管理工具的日常管理与维护； 6)配置库的日常操作和维护； 7)负责配置审核并提交报告；

8)根据配置部署表单编译发布版本，并维护版本； 9)对开发人员进行相关的培训；

10)对配置审核中发现的不符合项，拟订纠正措施，要求相关责任人进行纠正。

11)监督项目组成员规范的执行情况。1.4.4 开发人员（Developer）

1)根据确定的配置管理计划和相关规定，提交配置项和基线； 2)负责项目组内部测试； 3)负责软件集成和版本生成；

4)按照软件配置管理工具的使用模型来完成开发任务。2 实施细则 2.1 配置项管理 2.1.1 配置项的范围

软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。

l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。

l 代码主要指：源代码等。

l 工具主要指：脚本文件、插件、第三方控件等。2.1.2 配置项基线管理

结合SPP和ISO9000的相关规定，配置管理员根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目的一个基线。

l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立发布基线。

l 需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。产品需求规格说明书经过客户的确认后，建立需求基线。如需升级版本则必须通过评审或审批并得到客户的确认。

l 项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审通过后，建立项目计划基线。

l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批通过后，建立设计基线。l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。代码在提交项目组系统测试时建立Beta版本，系统测试产品正式发布后建立Version版本。

l 测试：单元测试和系统测试。单元测试通过提交《单元测试报告》，项目启动后应提交《系统测试计划》，系统测试完成后应提交《系统测试报告》。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。

l 版本发布：项目组提交《部署表单》，CMO根据部署表单进行编译，发布测试服务器上，并对版本进行维护。同时将发布的版本上传到文档服务器上备份。

l 交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。

l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。

l 相关资料：相关资料也应作为配置项纳入配置管理，此部分包括： 1)相关法律、法规；必须遵照或项目组约定的技术规范；

2)与客户或项目组内部重要的交互信息记录，如会议记录、会谈记录、e-mail和MSN记录等；

2.2 版本控制 2.2.1 文档的版本控制

所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现，主要分为以下几类：

2.2.1.1 版本变化型文档

命名方式：[文档名称]+[子系统名称]（可选）

适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等。

示例：项目计划.doc 详细设计_SP门户.doc 标签结构：[大版本] + [子系统简称] + [版本号] + 日期（标签控制说明版本信息）

l [大版本]： 可选，表示同一项目为不同用户定制的版本。l [子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

l [版本号]：采用[Vs_x_y]的形式。

l 日期：纳入基线管理的日期，用8位表示，如20071031 说明：

a.文档发布名称采用[文档名+ Vs_x_y]的形式，文档的版本号应该和版本控制工具中相应标签上的版本号一致。

b.对文档的修改需要从配置管理库中取到本地进行。

c.对于文档小的修改，如文字错误，格式调整，变更Vs_x_y中的y来区别（如：V1_0_1）。

d.文档内容没有大的增加和删节，意思表述没有发生重大的变化，版本标识通过版本工具中加上x标签来表示（如：V1_1_0），以及在文档内部控制页标注变化来表示。

e.文档有重大增加和删节，意思表述有重大变化的，版本标识通过在相应文档加上s标签来表示（如：V2_0_0）。

f.对于纳入基线库的文档的修改需要提交变更申请，经批准才能进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为后续阶段的参考文档。

2.2.1.2 时间区别型文档 命名方式：[文档名称＋撰写时间] 适用文档：文档名称有明确的含义，需要用时间标识的日常性文档。如周例会会议纪要，项目月计划，项目月总结,阶段性计划等等。

示 例：周例会会议纪要20030901.doc 2.2.1.3 时间序号型文档

命名方式：[文档名称+人员姓名（拼音）+撰写时间+序列号] 适用文档：测试报告

示例：单元测试报告_lixiaohong_20071112_01.dco 2.2.1.4 其他文档：

对于不能按照前四种类型进行命名的文档 会议纪要：会议纪要YYYYMMDD()示 例：9月9日召开的项目启动会 命名为：会议纪要20030909(项目启动).doc 评审报告：评审报告YYYYMMDD()同”会议纪要”要求一致。

示 例：10月9日召开的项目总体方案评审 命名为：评审报告20030910(总体方案).doc 2.2.2 发行版本表示

发行版本采用标签说明，结构如下：

[大版本] + [版本类型] + [版本号] + [子系统简称(拼音)]+日期 +序号 [大版本]： 可选，表示同一项目为不同用户定制的版本。

[子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

版本类型：分为3种

Beta表示项目组内部测试，标签：B1_0_0-20071015-01 Release系统测试，标签：Release1_0_0-SPmenhu-20071112-01 Version正式发行版，标签：Version1_0_0-SPmenhu-20071112-01 [版本号] 对于Version正式发行版 是必须要注明的，而其它可选。发行产品基线在版本号前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签； Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签。2.3 配置库管理 2.3.1 配置库的分类

配置库统一由配置管理员负责管理，服务器端使用cvsnt2.0.4，客户端主要使用乌龟CVS。配置库目录结构如下：

2.3.2 配置库的建立 所有项目应建立配置库，以便管理各配置项，配置管理员组织建立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理：

1)开发库：开发人员相对比较自由的存储空间，开发人员可以在自己的权限范围内任意取出提交。

2)基线库：配置管理员有最高权限，其余相关人员均为读的权限，发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。

Ø 文档评审通过后，文档严格受控。由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。

Ø 代码一般在移交系统测试时纳入基线库受控，可根据项目的具体情况设置基线。

3)产品库：产品库的产品均出自于基线库，产品库存储的产品用于交付和存档。

配置三库统一由配置管理员管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

2.3.3 分配权限

项目开始后配置管理员编写《配置库目录结构表》明确项目组成员以及相关人员的权限。在wincvs里有三种权限，读（r）、写（w）、添加删除（c）权限。在开发库内，文档部分项目组成员有rcw权限，其他相关人员只r权限；代码部分项目组成员有rcw权限，其他相关人员没有任何权限。在基线库内，项目组成员仅有r权限，其他相关人的权限视情况而定。在产品库内，所有人没有任何权限。配置管理员在三库内均拥有最高权限。

2.4 配置变更控制 2.4.1 变更的分类

软件及其相关文档的变更按照变更的影响范围进行分类：

1)A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认。

2)B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可。3)C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准。

Ø 系统测试前变更控制流程：

Ø 系统测试完毕发布release版本后变更控制流程

图2 变更控制流程 2.4.2 变更请求的提出

a． 由技术支撑中心汇集顾客意见，影响到需求变更则填写《配置项变更控制报告》，并提交给配置管理员。

b． 配置管理员对申请表是否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请者。对通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。

2.4.3 评估变更

a． 配置管理员将《配置项变更控制报告》发送给项目经理（或者其他授权人员），由项目经理负责对变更进行评估。

b． 项目经理对变更进行分解，一般的BUG修正不需要审批直接由项目经理决定是否需要变更。新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更。变更评估文档在完成变更评估后发送给配置管理员。

2.4.4 变更实施和确认

a． 变更被批准后，项目经理提交变更实施进度计划，开发人员开始实施变更，并详细记录变更的内容；质量部对变更的实施进行跟踪。

b． 对于代码变更，必须进行回归测试，以确保变更没有引入新的Bug。另外与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，进行提交。

c． 通过测试后，质保人员需对变更进行审核，审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号。

a． 审核后，由配置管理员更新到基线库中。2.5 配置状态报告 2.5.1 目的

记录和报告整个软件生命周期演化状态。2.5.2 记录内容

配置状态报告记录的内容包括： 1)软件和文档的标识； 2)目前状态； 3)基线演化状态； 4)变更状态； 5)版本交付信息等。2.5.3 生成报告

配置管理报告自第一个基线创建时建立，由配置管理系统生成，及时反映当前配置状态。

2.6 配置审核 2.6.1 类别 配置审核分为：

1)功能配置审核（Functional Configuration Audit，FCA）：审核软件功能是否与需求一致，并符合基线文档要求，通常要审查测试文档等。

2)物理配置审核（Physical Configuration Audit，PCA）：审核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本的源代码、资源、文档、安装说明等等。

2.6.2 执行时机

通常选择以下几种情况由质量保证人员负责实施配置审核： 1)软件产品交付或是软件产品正式发行前； 2)软件开发的阶段工作结束后； 3)在产品维护工作中，定期地进行。2.6.3 不符合项处理

对配置审核中发现的不符合现象，配置管理员进行记录，并交由责任部门限期进行纠正，配置管理员负责纠正措施的验证。所有的不符合项报告均关闭后，才能发布新版本。

2.7 发行管理

通过配置审核后，经项目经理批准，由配置管理员负责生产新版本。2.7.1.1 交付管理

这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：

1)交付人向质量部申请；

2)质量部如果不同意交付，则拒绝交付配置项。如果同意交付，配置管理员应给出详细的交付清单；

3)交付人验收后签字。