1、目 录1 本规范编制的目的 .22 缩略语及专有名词解释 23 项目组织机构 .24 实施规范的内容 .54.1 沟通管理 .54.1.1 沟通类别 .54.1.2 沟通方法 .64.1.3 沟通计划 .74.1.4 沟通效果要求 .94.1.5 沟通争议解决处理 .94.2 文档管理 .94.2.1 文档管理方法 .104.2.2 文档编写过程 .114.3 风险管理 .144.3.1 风险管理策略 .144.3.2 风险管理办法 .154.3.3 风险汇报制度 .164.3.4 风险管理模板 .174.4 变更管理 .174.4.1 变更级别 .174.4.2 变更管理过程 .174.5
2、测试与交付 .204.5.1 系统集成测试规范 .204.5.2 交付管理 .204.6 质量管理 .204.6.1 测试 .204.6.2 设计联络会 .214.6.3 质量保证 .214.6.4 质量管理和控制 .214.7 应急管理 .234.7.1 突发事件分类 .234.7.2 处理预案及要求 .231 本规范编制的目的本项目工期紧张，参与项目建设的单位多，工程复杂，为如期实现项目的建设目标，编制一套敏捷、高效、务实的项目实施规范势在必行。2缩略语及专有名词解释3项目组织机构（1）项目领导小组职责 对项目进度、组织及资源管理负总体责任； 指挥并推进工程建设总体工作，协调解决工程建设及
3、中的重大问题，对重大事项进行审定和决策；（2）项目经理职责项目经理对项目全局进行整体把控，是本项目具体实施负责人，并对项目的进度、质量、风险、协调、接口、项目实施人员调度进行负责。项目经理主要承担三类工作：项目整体实施管理、总体技术的管控、商务管理。（3）项目执行经理职责对项目进行测试管理、施工管理、现场管理、采购仓储（采购计划、各子项目组的台账管理） 、接口协调、各子项目组计划跟进、考勤管理、投资控制管理，同时接收各子项目经理上报的风险、变更问题的接收、汇总，并协助项目经理处理风险和变更。（4）商务组职责负责整个项目的总体商务工作，包括厂商资源协调和责任落实，设计联络和采购产品原产地培训等的
4、商务工作的落实；（5）项目管理办职责项目管理办的职责是按照项目管理的知识体系为项目组编制各种管理制度和流程规范，制定各类计划给项目经理审核，并负责审定计划的监管，并负责项目团队中各子项目经理（团队）的工作协调，同时负责施工管理、现场管理和文档管理工作。1） 主任：项目管理流程和规范的制定，项目计划的收集、汇总并协助项目经理审核，项目计划的监管，现场管理、施工管理和文档管理，协助项目经理进行项目的风险和变更管理。2） 副主任：项目管理办副主任由各子项目经理兼任。他们的职责是制定项目实施方案交由项目经理审核，整体把握各子项目技术、质量、开发、集成、采购、施工、变更及风险的管理。发现重大风险，直接向
5、项目经理进行汇报，对于重大变更，需要向执行副经理、项目经理及时汇报。参与项目流程、规范和总体计划的定制。按要求业主、监理和用户的要求提交项目周报。3） 办公室主要职责： 负责项目总体计划的制定； 督促检查工程整体进展情况，按照项目计划，对未按期完成的工程项目进行催办、督办； 负责按照项目会议决议督办工作任务落实情况； 负责有关项目建设工作信息的收集、上报工作； 协调解决项目建设工作进展中项目组内存在的各项问题，同时负责项目组外的事件的协调解决； 项目标准规范宣导，系统间接口相关问题的管理和协调； 负责项目的过程跟踪，协助各子项目组完成重要工作的落实； 负责项目采购管理、文档和测试管理。 负责各
6、子项目组的集成方案的审核与验证。同时按集成检查点检查本项目及子项目集成工作，对施工组织方案、组织设备现场调试，现场的安装督导、设备和环境的兼容性验证； 负责项目周报的编制与发布； 完成业主交办的临时任务。二、项目组横向管理组织及职责（1）生产扩容子项目组职责 完成二期应用系统开发、通用软硬件采购及安装、调试、集成测试（部分）等工作，二期系统上线与一期系统并行运行。 完成清分模型系统开发、通用软硬件采购及安装、调试、集成测试等工作： 完成与信息中心系统接口定义、设计、开发和联调测试，能够为信息中心系统提供数据。（2）扩容子项目组职责 新线接入相关工作 系统优化升级，新线接入工作的工作目标是完成接
7、入测试，并完成新线接入相关应用生产系统部署与调试，确保系统具备正式接入的条件。系统优化的年底工作目标是完成所有子系统的软件需求及详细设计的确认，并完成所有子系统的开发及内部模块测试工作，以便在明年顺利开展工厂测试，联调测试等正式测试工作。 完成与年底信息中心应用系统需要的接口开发（3）集中显示平台组负责集中显示平台工程实施，实现年底系统验收并上线试运行。（4）基础设施平台组基础平台建设是本项目正常上线试运行的前提和保证，它包括 ACC 生产系统扩容、TCC 系统扩容、信息中心系统工程的机房基础设施建设、网络及安全系统部署、服务器及存储系统（含数据仓库软硬件）部署等工作。（5）数据中心组 数据仓
8、库对接入源系统的调研 数据仓库对源系统的接入以及历史数据的加载 数据仓库对应用系统的数据支撑 非结构化硬件采购、硬件安装部署；非结构化产品采购、非结构化产品安装及部署；主要完成业主提出的第一批次非结构化数据录入工作。4实施规范的内容围绕敏捷、高效、务实的目标，本规范分沟通管理、文档管理、风险管理、变更管理、测试与交付管理、质量管理、应急管理、考核管理八个方面的内容。4.1 沟通管理本节用于指导项目全过程的沟通工作、沟通方法、沟通渠道等各方面的计划与安排。通过描述本项目实施全过程中进行沟通工作时需要采用的沟通方法、沟通渠道等方面的计划与安排，帮助项目干系人员了解沟通需求，明确需求内容、获取时间及
9、获取渠道。按照矩阵组织建立沟通层次的基础上，对沟通种类、沟通方法和沟通计划方面说明沟通实施过程，并对沟通方法中所借助的沟通工具给予介绍，最后对沟通活动整体作出要求及出现争议，制定争议解决制度。4.1.1 沟通类别 内部报告项目内部的报告机制分为书面报告和口头报告两种。书面报告采用专门报告模版或Email 的形式。专门报告模版使用经业主、项目及监理确认的项目文档模版。Email 形式为通用的沟通方式，项目内部大部分事务沟通，交流和报告均可使用 Email 形式进行。项目团队成员需要根据实际情况对所分配的任务进行完成情况的任务报告，把任务的执行情况及时地报告给相应的负责人。报告对象根据项目的组织结
10、构，由下至上地进行。 项目新闻与简报与项目相关的一些新闻与简报可由两种方式传递给所有项目成员。对于重大的新闻或项目相关的消息可以通过邮件列表进行新闻发布或简报发布。对于一些非重大的消息可以由相关负责人 Email 或口头通知所有项目成员。 外部沟通所有外部沟通由项目经理负责。其他项目成员除非具有项目经理或子项目经理的授权与指派，不得与项目外部人员( 包括业主) 进行任何直接沟通 (需求调研除外)与承诺。 外部报告项目外部的报告机制为书面报告。书面报告采用专门报告模版或 Email 的形式。书面报告分为项目周报、项目月报、项目季报等，报告内容包括（但不限于）项目进度、项目风险及应对措施和项目质量
11、报告，模版使用经业主、 、监理确认的项目文档模版。 公开任何与项目相关的信息公开活动，统一由项目经理发起与负责，其他项目成员除非具有项目经理的授权与指派，不得擅自进行任何公开活动。 外部调查任何与项目相关的外部调查活动，统一由项目经理或子项目经理发起与负责，其他项目成员除非具有项目经理或子项目经理授权与指派，不得擅自进行任何外部调查活动，包括任何书面调查和口头调查( 需求调研除外) 。4.1.2 沟通方法项目建设期间，将使用正式的程序来促进交流。沟通方法包括（但不限于）： 报告主要指项目周状态报告，项目经理将与业主方项目经理一起工作，编制状况报告，分发给业主、监理和。 临时会议或直接交谈按需要
12、组织会议进行沟通，或直接与相关人员（不限于项目组成员）进行讨论，会后以邮件或会议记录形式记录沟通和讨论结果。 电话或电话会议对于异地或者涉及非项目实施地点人员的沟通以电话或电话会议为主，此类电话或电话会议视为与面对面会议同等的作用，要求记录沟通和会议结果，并以邮件的形式对结果进行确认。 传真对于重大事项，可通过传真通知业主、监理和。 电子邮件电子邮件可以有效提高沟通效率、降低项目成本，本项目视邮件沟通记录与纸质记录具有同样的作用，要求各方在收到需要应答的邮件时必须给予回复，未在规定期限内回复的成员，默认接受邮件发送人的安排并同意邮件发送人的意见。 会议项目会议必须按照规定的频度和时间准时执行，
13、会议必须提前准备，安排主持人和记录员。本项目涉及会议主要包括（但不限于）：a) 周项目例会：审查总体状况、项目时间表和状况报告中提到的未决问题，提出问题，解决问题（可会上处理） ；追踪问题，风险，和依赖条件；确定下周计划分工。b) 项目启动会议：使项目参与人明确本次项目的目标，工作范围，本项目实施的方法及各自的角色和职责。c) 设计联络会：承建单位向建设单位及其代表提供系统设计的信息资料及详细介绍，并提供机会讨论和澄清有关设计方面的各种问题。d) 协调沟通会：针对项目执行过程中的遇到的风险和问题进行多方沟通协调解。e) 专题协调会（监理）/业务专题会 (招标文件): 为解决项目实施中的专项问题
14、，合同各方与专题有关的负责人及专业人员参加的不定期会议。f) 验收会：在初步验收、最终验收等验收环节，召开验收会。g) 技术评审会：在项目实施过程中，根据需要甲方有权提出召开专家技术评审会，专家由甲方指定，乙方需根据技术评审会的意见和结论对系统相关内容进行整改落实。h) 其它会议：为保证合同的顺利执行，甲方和乙方可商定在必要的时候召开会议，讨论并解决本项目工程进行中出现的问题。说明：本计划涉及范围为项目，对各子项目内部沟通管理由各子项目自行规定。4.1.3 沟通计划沟通分为内部沟通和外部沟通两个方面。内部沟通是指项目组内，与各子项目组、子项目组与子项目组间、项目组成员间的沟通动。沟通工具辅助上
15、述提到的各种沟通方法，方要求各专项项目组采用统一的沟通/汇报工具，具体如下：一、工作联系单制度工作联系单是为了有效解决本工程实施过程中存在的问题，增加项目相关各单位之间的工作沟通而制定的联系方式。工作联系单采用统一格式编制，适用于项目相关各单位之间有关工程的工作问题解决的联系。工作联系单应用流程为：1. 签发工作联系单的单位依照具体要求填写联系单，经负责人审核签字后发送，并交监理单位统一登记、备案和跟踪。2. 工作联系单主送单位和涉及单位应在一周内将填写完回复意见的联系单返回签发单位，并返回建设单位，由建设单位备案。3. 每周工作联系单的情况在周例会上进行通报。工作联系单模板如下所示：工作联系
16、单编号：主题 问题级别 正常 急 紧急联系人 签发时间 年月日联系方式 签发人发文单位主送单位涉及单位 建设单位 监理单位 设计单位 承建单位问题描述及影响解决建议联系及处理要求或建议请审核 请审阅修改 请传阅请审批 请回复 其它（注明具体要求）接收单位 接收时间 年月日回复意见签名：备注二、沟通中所示用的文档模板本项目中各类沟通所使用的文档模板如下表所示，各子项目在沟通时如需下列模板，请向监理或来索取相应模板。4.1.4 沟通效果要求1、会议类沟通 各专项项目组在组织沟通会议前，要求会议召集人确认好会议资源、分发会议议题及材料，确认与会人是否准时参加，或者替代人等； 对应评审类的会议，要求不
17、能参加的评审人员，通过邮件给出评审意见，会议主持人需将邮件评审意见在评审会予以说明；2、现场协调 现场项目资源定期给予识别，出现资源短缺，要求十五日内向项目经理和业主提出资源申请。 对于硬件采购设备的厂商沟通，各专项项目组的采购负责人在成方的牵头下组织实施采购设备的出厂检验、开箱检验等活动。4.1.5 沟通争议解决处理 评审出现的问题争议由评审组织者组织意见分歧人员会后进一步沟通确认，如果未果，则提交由业主、监理、组成的仲裁组进行仲裁解决。 项目管理等方面问题争议对于此类问题的争议解决，采用逐级汇报仲裁的方式进行解决。即首先应向产生争议的群体所属上层负责人进行汇报，由上层负责人给予仲裁。如果上
18、层负责人无法给予仲裁，应继续向上汇报。 与业主有直接关系的问题争议对于此类问题，各专项项目组向方上报，由方为统一出口，向业主和监理进行汇报，由业主的仲裁解决。对于沟通中出现的争议，按照由下往上、先内后外的方针，逐级进行协调和仲裁。各级仲裁人员的职责和范围分工如下表所示：4.2 文档管理指导本项目实施建设中的文档管理方面活动。4.2.1 文档管理方法（1）责任划分各子项目负责对本子项目的文档成果物进行配置管理，并需要根据的要求及时反馈成果物的状态，负责管理把握项目整体成果物的状态。（2）受控文档类型 软件工程类文档：项目实施过程中的所有输出文档； 项目管理类文档：编制的项目管理体系文件、的项目管
19、理类文档、各子项目组需向提交的项目管理类文档，如子项目计划，子项目的阶段里程碑总结报告等； 外来文件：包括采购设备厂商提供的与设备相关的技术说明书/测试报告、业主提供的文件、国家标准及法律法规等； 图纸：项目建设输出的工程图纸、各子项目组的图纸清单等。（3）文档编制1) 各子项目根据所需编写文档的模板、规范要求进行文档编写；2) 各子项目组对所编写的文档进行内部评审；3) 评审通过后，文档编写人员向所在子项目组申请文档编号；4) 文档编写人员添加编号后，提交文档进行上报审批。 上报审批时，应按照、监理和业主的顺序，进行逐层审批。 对于技术方案类文档，还应通过业主指定的专家审批。（4）文档发布1
20、) 正式文档发布的机构有两个：项目管理办公室和总工办，所有由发布的文档都由这两个组织向业主、监理、设计院、项目组成员。2) 各子项目组发布的文档分成两个部分：子系统内部文档和外部文档。 内部文档是子系统内部交流、沟通、备案用所产生的文档，由各子系统自行管理。 外部文档是子系统间或各承建单位之间的交互文档，这部分文档在发布之前先以电子邮件的形式根据文档的内容发送给项目经理，由其审核后再做发布。（5）文档发放使用发布及管理的文档由管理员统一进行文档发放管理。1. 电子类文档，文档管理员向文档使用申请人指明文档存放的项目配置库路径，使用者通过递交申请后，由配置管理员添加相应的权限后，方可访问；2.
21、纸质类文档，文档使用填写文档领取申请，经相关责任人审批签字后，文档管理员复印发放，并做文档发放去向记录。注：对于子项目组的纸质类文档，文档管理员确认文档领取申请签字后，由子项目组文档管理员进行文档发放。（6）文档保存与归档文档由负责保存，各子项目文档由各子项目负责保存，各子项目有责任将子项目的文档状态及时向进行通告，由子项目组织的有多方参加的会议沟通的相关记录文档需在处备案。文档需由专人进行管理，纸质文档需保存在文件柜中，电子文档需保存在受控的配置库中。文档归档需按照业主的要求来实施。（7）文档日常管理1) 每季度对文件柜进行季度盘点，核实记录与实际文档的是否一一对应，以保护记录的有效性；2)
22、 对文件夹损坏的，及时更换，标签遗失的，及时粘贴；3) 项目组内人员发生异动，文档管理员需对文件返还情况，在工作交接单上给予签字确认。（8）文档变更管理1) 纸质类文档变更，在文件夹中将新版本文档置顶，并根据文件递交部门的要求，保留前一版本文档至保管期限后，进行作废处理，及时更新文档归档清单；2) 电子类文档变更，在所变更的文档变更履历中添加变更内容，再次提交项目配置库。4.2.2 文档编写过程本项目围绕着可操作性、务实的指导原则，把项目的全生命周期过程流程与要求进行梳理与划分。从成、子项目组、监理、业主各方如何进行配合做了详细的要求与说明。（1）各项目组工作任务和范围划分过程和用户根据招标文
23、件的要求和各子系统投标文件的表述，对整个项目的工作内容和范围按各子系统进行划分，划分完毕和各子系统承建商进行沟通，确认各子系统承建商的工作内容和工作范围，接口规则，项目执行计划。研究各承建商的计划找到各系统建设过程中的相互依赖关系，对其进行分析，做为项目总体计划编制的输入条件。（2）项目预备启动会议完成项目面向各子系统承建商的任务划分（草案） ，项目实施规范（草案） 、项目总体架构（草案） 、接口和标准管理（草案） 、基于年内的目标及实施计划（草案）后，可以召开项目的预启动会，用户、和各子系统承建商进行交互，对草案中的问题进行调整和修改形成可操作的计划和内容规范。（3）项目启动过程预启动会议结
24、束后，根据业主和各承建商的意见做相应的调整，确认后召开项目启动会议，落实整个项目总体计划、实施规范、架构及标准和基于年内目标达成的实施计划，要求各承建商共同遵守。项目启动后，由各子项目组 向监理提请开工申请（项目实施总体进度计划、年内项目实施计划、技术架构、组织及资源安排） ，监理转发业主和，并召集内部讨论，会签监理、意见、主架构师和质量经理意见。子项目组 审核开工申请没有通过，则给出具体意见，各子项目组根据要求重新申请。通过则由子项目组 在开工申请上签字确认，并提交业主，由业主的对应 进行审批，如审批通过，监理发出开工通知，并转发给成项目经理和执行副经理。（4）项目计划过程依本项目的特点，项
25、目的软件开发计划有一个关键的里程碑，各子系统 首先要围绕年底目标编制出自己的项目计划，上报给用户和，由和用户牵头，各子系统负责人共同参与，根据项目各项目组工作任务和范围划分的成果物对整个项目计划做调整，以实现项目年底的总体目标。同时各子项目组还要制定整个项目的实施计划，提交计划报审表：开发项目报软件开发计划、软件配置管理计划、软件质量保证计划；集成项目报采购与施工组织计划、接口配合计划给成和监理，用户、 、监理对计划进行讨论，会签三方意见，通过则子项目组可以按计划实施。（5）需求分析设计过程各子项目组在软件需求深入调研与分析的基础上，编制软件需求规格说明，并在征得业主对软件需求规格说明的认可后
26、，提交软件需求报审表（附软件需求规格说明）给成和监理，主架构师召集内部讨论，会签监理、意见，通过则主架构师在软件需求报审表上签字确认。审批通过则由监理组织召开需求评审会，子项目组、总工办、项目管理组、监理、在评审报告上确认签字，提交业主，由业主方 进行审批。（6）概要设计过程软件概要设计完成后，子项目组提交软件设计报审表（附软件概要设计说明、数据库设计说明）给成和监理，业主授权、监理审核， 、监理均审核通过后，由监理方将报审材料和审核意见报业主处进行备案。项目进入详细设计和编码阶段。业主如对收到的备案材料有异议，可要求、监理方重新审核。（7）详细设计和编码过程子项目组在详细设计和编码完成后，子
27、项目组提交出厂测试计划报审表（附详细设计说明、软件测试计划、软件测试说明（含测试用例） 、可执行程序生成说明等文档）给成和监理，业主授权、监理审核意见， 、监理均审核通过后，由监理方将报审材料和审核意见报业主处备案。项目进入出厂测试阶段。业主如对收到的备案材料有异议，可要求、监理方重新审核。在出厂测试报审前，监理方适时召集业主、子项目组、 、承建方召开系统演示会，由监理方归纳各方达成一致的修改意见，形成会议纪要，责成子项目组在出厂测试阶段处理。（8）出厂测试过程子项目组依据出厂测试计划进行出厂测试（包括对用户文档的正确性测试） ，完成后提交产品交付申请表（附软件出厂测试报告、用户手册、安装部署
28、手册、产品安装盘、产品源代码和源代码交付说明等）给成和监理，方和监理方分别出具意见（如同意则需附各方产品交付测试计划和测试说明）报业主处；审批通过则业主在交付产品验证申请上签字确认，进入产品交付测试阶段。（9）产品交付测试过程和监理同时对交付产品进行测试，在任何一方测试不通过的情况下，如果达到重新出厂测试的条件，直接要求子项目组重新出厂测试，并建议业主对承建方进行惩罚；如不需要重新出厂测试，通知子项目组进行整改，处理结果抄送业主处。如测试通过，监理和分别编制测试报告提交业主。业主 接到监理和的测试报告后在成、监理、子项目组的配合下组织业主内部测试，如通过测试，业主组织编制业主测试报告，业主在测
29、试报告上签字确认，由监理通知子项目组产品交付验证通过，进入系统部署阶段。（10）系统部署过程子项目组提交部署申请（附部署实施方案）给成和监理，业主召集内部讨论，会签监理、意见，通过则业主在部署申请上签字确认，并提交业主领导小组审批。审批通过则由业主协调落实业主方部署运维人员，由监理通知子项目组实施部署，方现场汇同子项目组进行部署测试并在子项目组部署实施报告上签字，由子项目组报监理方，监理方审核通过并签字后提交业主处，审核通过后业主在子项目组的部署实施报告上签字确认，由监理通知子项目组提交初验申请。4.3 风险管理为规范项目管理，保证项目顺利实施，对项目实施过程进行风险管理及防范，以防止风险对项
30、目造成影响。本节对专项（子）项目组内、子项目组外定义了风险汇报及处理机制，本项目部及所属各专项（子）项目部需遵从执行。4.3.1 风险管理策略根据业主及监理的要求建立风险管理策略。1）确定风险来源，风险来源涵盖内部风险和外部风险，包括但不限于： 2）确定风险分类。风险的分类包括但不限于：3）确定风险控制策略。a. 定义风险的危险度（风险一旦发生对项目造成的威胁程度） 。危险度划分为四个等级：致命：风险的发生会对项目的目标造成极大影响，导致目标无法完成。严重：风险的发生可能导致目标无法达成，或者项目计划不能顺利执行。一般：风险的发生对项目产生影响，但不足以影响项目目标的达成。轻微：项目组在现有情
31、况下可以承担风险带来的影响。b. 定义风险的发生概率（风险发生的可能性） 。发生概率一般划分为 3 个等级：高：大多数情况下可能发生或发生的概率在 75%以上中：某些情况下可能发生或发生的概率在 25%-75%之间低：只在某些特定的情况下才可能发生或发生的概率在 25%以下c. 定义风险的优先级。风险优先级有助于使有限的项目资源得到最有效的应用，避免将过多的资源投入到不可避免的风险或对项目影响很小的风险上。根据风险的危险度和发生概率，一般将优先级划分为 4 个等级，即 I, II, III, IV，如下表：d. 定义风险管理要求。根据风险的优先级，定义不同的风险管理要求，举例如下表：e. 确定
32、风险缓解措施的启动标准。风险缓解措施的启动标准用于明确在何种情况下，项目应该执行风险缓解措施。4.3.2 风险管理办法（1）风险识别各专项（子）项目经理组织项目成员和其他相关干系人参与风险识别活动。参考项目部定义的风险来源识别项目的风险，将识别出来的风险记录到“风险管理表”中。a. 在进行风险识别前要明确业主和监理的管理要求，同时尽可能收集项目的有关资料，包括项目背景、项目需求、项目目标、技术方案、WBS、估计结果等，以从中识别项目的风险。b. 风险识别并不仅限于项目策划阶段，在项目执行的任何阶段，各专项（子）项目经理和项目组成员都应该关注新风险的识别。（2）风险分析1. 各专项（子）项目经理
33、和项目组成员对识别出来的风险进行分析，确定每个风险的分类、生存期、危险度和发生概率。2. 参考定义的风险优先级的确定方法，根据风险的危险度和发生概率确定风险的优先级。（3）制定风险管理措施各专项（子）项目经理和项目组成员参考定义的风险管理要求，制定风险管理措施。1. 确定风险的缓解措施。2. 确定风险的应急措施。3. 根据风险的优先级，确定风险的跟踪频率。4. 针对风险缓解措施和风险应急措施，各专项（子）项目经理指定措施的责任人。5. 各专项（子）项目经理将上述信息记录在“风险管理表”中。（4）风险跟踪1. 各专项（子）项目经理根据确定的风险跟踪频率，对风险进行跟踪：a. 监控风险状态，记录状
34、态变更。风险的状态包括：（1） 已识别：风险已经被识别（2） 已发生：风险已经发生且转化为问题（3） 已消失：风险消失，不会对项目产生影响b. 对风险的危险度、发生概率、生存期进行重新分析并计算风险优先级，必要时调整风险缓解措施和风险应急措施。2. 当达到风险缓解措施的启动标准时，风险责任人和项目负责人共同确定措施的计划开始和结束时间，并按计划执行和监控风险缓解措施。3. 各专项（子）项目经理将跟踪信息记录在“风险管理表”中。4. 风险一旦发生，即转化为问题。各专项（子）项目经理应依据项目管理办法中问题管理要求进行管理。4.3.3 风险汇报制度根据项目组织结构，本项目拟采用两层次风险管理机制。
35、依据风险影响范围，将风险分为系统风险及子系统风险。系统风险涉及项目整体，与多个专项项目部相关，系统级风险由项目经理及项目执行副经理负责管理。子系统风险与某个专项项目部相关，子系统级风险由各专项项目部专项 负责管理。1、风险汇报的方式及工具统一采用项目周报邮件或会议等形式进行风险汇报，系统风险及 I 类风险，采用会议的方式；其他级别的风险采用邮件的方式汇报。统一采用风险管理表作为风险管理及上报工具。2、建立适合的风险通报机制 系统级风险通报机制该级别风险通报按照如下组织机构示意图进行逐层报告。1）系统级风险由其对应的负责人向项目执行副经理汇报；2）项目执行副经理对上述收集到的风险，向项目经理汇报
36、； 子系统级风险通报机制1）子系统风险负责人将风险向所属的专项项目经理汇报；2）专项项目经理对风险进行总结整理，在项目组内发布。3、风险管理实施领导负责制。针对所识别出的风险，均应给出缓解措施和风险应急措施，并应指定措施执行的责任人。如果系统级风险涉及多个专项项目部，应明确每个专项项目部的责任人。根据风险解决措施及计划，各专项项目组的质量控制管理工程师与风险责任人为接口，对其进行定期跟进风险的解决情况。4.3.4 风险管理模板4.4 变更管理为确保项目中的需求变更被有效的管理、跟踪和控制，本项目对需求变更采用正式的变更控制流程进行控制，并根据变更的影响及提出者的不同，进行针对性管理。4.4.1
37、 变更级别一级变更：即重大变更，是由业主提出的影响到合同的变更、项目内部发起的影响到业主或多个子系统的变更。此类变更由本项目的业主、监理、设计和进行仲裁处理。二级变更：即一般问题，是不影响合同、及项目相关方业务的并且只影响某个子系统的可控变更。此类变更在子项目间进行横向沟通与讨论，形成变更结论后，由项目执行副经理及项目经理进行会签， 审批通过后为变更生效。4.4.2 变更管理过程根据变更的不同来源，对变更采用不同的变更管理过程：外部变更（业主提出的变更，如需求变更、合同变更、计划变更等） 、内部变更（项目内任意成员提出的变更，如计划变更等） 。（1）外部变更管理流程外部变更管理流程如： 变更请
38、求提出1、在项目进行中，业主可能会向项目组提出变更请求，填写工程变更单 ；2、项目的配置管理负责人需要对该变更请求分配变更请求的编号并开始跟踪记录该变更请求的状态。 变更仲裁1、项目经理需要对该变更请求进行仲裁，判断该变更请求为一级变更请求还是二级变更请求；2、当项目经理无法准确判断变更请求的级别时，需要召集一级成员共同进行仲裁。 项目变更分析根据变更请求被确认为一级/二级变更，项目经理/ 子项目经理负责根据本次提出的变更内容，指定相关人员对该变更进行变更分析，包括变更范围、变更对规模、工作量/成本、进度、质量等的影响； 下发变更通知（2）内部变更管理流程 变更请求提出1、在项目进行中，项目组
39、任何成员都可以提出变更请求，填写工程变更单 ；2、项目的配置管理负责人需要对该变更请求分配变更请求的编号并开始跟踪记录该变更请求的状态。 变更仲裁1、子项目组 需要对该变更请求进行仲裁，判断该变更请求为一级变更请求还是二级变更请求；2、当子项目组 无法准确判断变更请求的级别时，可以向项目执行副经理申请召集二级成员共同进行仲裁。 提交一级变更申请当判断该变更请求为一级变更时，子项目组 向项目经理提交一级变更申请。 项目变更分析当该变更为一级/二级变更请求时，项目经理 /子项目组 负责根据本次提出的变更内容，指定相关人员对该变更进行变更分析，包括变更范围、变更对规模、工作量/成本、进度、质量等的影
40、响； 提交审批1、根据变更等级，项目经理/项目执行副经理组织召开一级/ 二级来对一级变更请求进行审批，基于变更分析结果来审批变更请求，并确定是否需要执行配置审计。2、如果二级否决了该变更申请，项目执行副经理需要将变更分析结果和评审结果提交给项目经理，重新进行仲裁。3、项目的配置管理负责人需要将的审批结果在配置管理计划中的变更请求记录中做相应的更新。 下发变更通知当一级或二级批准该变更后，项目执行副经理需要将该变更请求下发到相应的子项目组。开始执行各子项目组的变更管理过程。（3）变更实施及验证过程变更实施及验证过程如下图所示： 接收变更通知1、子项目组负责接收变更通知。2、子项目组的配置管理负责
41、人分配变更请求的编号，在子项目组的配置管理计划中记录变更请求的状态，开始跟踪记录该变更请求的状态。 变更实施1、子项目组进行变更的实施。变更实施涉及如下内容：1） 、变更实施人员；2） 、计划完成时间；3） 、变更验证方式和人员；4） 、详细的进度表。2、子项目组的配置管理负责人根据变更实施信息更新配置管理计划表，子项目组的质量控制负责人跟踪变更的执行情况。3、变更实施人员接收变更信息后，应修改受变更影响的配置项。如果变更引起基线变更，子项目组的配置管理负责人根据变更后的内容重新建立基线。 变更验证1、子项目组的配置管理负责人负责对变更的验证。2、子项目组的配置管理负责人收到变更完成的通知后，
42、依据变更策划结果，通知本项目中对本次变更有关的人员执行变更验证；3、当变更验证完毕后，验证者通知子项目组配置管理负责人，由其负责确认验证结果。1） 、对于验证方式为测试的变更内容，子项目组配置管理负责人确认有关测试的结果；2） 、对于验证方式为评审的变更内容，子项目组配置管理负责人确认有关评审的结果；3） 、当确认变更通过了评审/测试后，如果需要执行配置审计，子项目组配置管理负责人应对相关内容执行配置审计。 变更生效通知1、如果变更引起了基线的变更，当变更通过了评审/测试，且通过了变更批准活动中指定的配置审计后，子项目组配置管理负责人从开发环境中取得有开发人员标准的临时版本的配置项放入“ 基线
43、库”，进行正式版本标识并更新配置管理计划，对变更状态做相应的更新。2、子项目组 将变更生效结果通知质量经理。4.5 测试与交付测试与交付是项目执行的关键环节，负责系统集成测试。交付不仅仅是系统交付，还包括与系统相关的文档的交付。4.5.1 系统集成测试规范（1）集成测试的前提条件（2）集成测试的准备（3）集成测试的内容应用系统集成测试的内容由成单位提出，由监理审核。包括但不限于以下内容：1）功能测试2）UI 界面测试3）性能测试4）安全测试5）配置测试6）安装测试7）稳定性测试（4）集成测试执行过程（5）集成测试总结（6）测试发现问题的处理流程（7）测试沟通会议4.5.2 交付管理交付阶段的流
44、程与要求包括：初验阶段、试运行阶段、终验阶段、终验通过阶段。4.6 质量管理4.6.1 测试各子项目在提交之前需要实施子项目内部的出厂测试，内容包括单元测试、功能测试、安全测试、性能测试及 144 小时连续检验等，并记录和管理测试所发现的缺陷。各子项目提交到之后，由负责实施系统集成测试。要求各子项目在概要设计结束之前，完成测试大纲的制定和评审，集成测试前提交各自系统测试用例及测试总结报告，并由、监理审核通过。系统集成测试所发现的缺陷，由 Jira 系统进行管理。各子项目的测试的状况和数据信息需要包括在子项目周报中，实施的系统集成测试的状况和数据信息需要包括在的项目周报中。信息包括，测试进展状况
45、，缺陷修复进展状况等。4.6.2 设计联络会本项目目前计划实施三次设计联络会（简称设联会） ，由业主、监理、和各子项目相关人员参加。一联会的评审的时机为概要设计完成时，评审内容为需求、架构和概要设计，目的是相关各方就需求和高层设计达成共识。二联会的评审时机为详细设计完成时，评审内容未详细设计，目的是相关各方就项目的具体设计在相关各方间达成共识。三联会的评审时机为实现之后（对软件来说是编码和单元测试之后） ，目的是相关各方就产品的实际实现内容达成共识。4.6.3 质量保证为保证各子项目均能按项目中已制定的规范来推进和实施项目，在本项目中引入质量保证机制。各子项目均配置质量工程师，负责对项目的规范
46、实施状况进行审计。各质量工程师需要制定质量保证计划，用以确定质量保证活动的实施频率和方式，以及实施质量保证活动的规范标准。各子项目的质量工程师的质量保证计划需要质量工程师的评审和批准。4.6.4 质量管理和控制为保证质量管理的各项措施的有效实施，以及质量状况的透明化，质量工程师需每月汇总各子项目的质量状况，并作为项目月报的一部分。质量状况包括但不限于以下等方面的内容：（1）技术评审的实施状况 计划实施的技术评审次数 实际实施的技术评审次数 评审发现的缺陷数 评审发现缺陷的解决状况（2）测试实施状况 测试进展状况 测试发现的缺陷数 缺陷的收敛趋势 缺陷的解决状况（3）设计联络会 设联会进展状况
47、设计联络会的通过率 设计联络会发现的问题数 设计联络会发现问题的解决状况4.7 应急管理4.7.1 突发事件分类根据项目特点，识别项目执行期间可能存在的突发事件分为如下几种： 项目管理维度，如：1) 某子项目组进度严重延期且无解决措施；2) 项目风险未识别或者已识别但无解决措施；3) 合同/需求发生变更，但未及时通知到相关干系人；4) 人员异动，新调项目成员对项目不了解，影响项目进度等。 质量管理维度，如：1) 发生因版本混乱，导致后期项目工作量无效投入的重大质量事故；2) 验收阶段，144 小时系统连续运行，系统可靠性低下，无法正常运行。 采购管理维度，如：1) 采购进度严重延期，导致项目组
48、的整体进度延期，且无解决措施；2) 采购硬件设备到达现场，开箱损坏，或者零部件缺失；3) 特殊硬件设备，选取新的供应商，导致采购到的硬件设备质量不达标。 集成管理维度，如：1) 集成方案在实施过程中受阻、事前未作充分的影响因素考虑；2) 集成部件到货进度不一致或者是部分部件进度严重延迟，影响整体的集成进度；3) 集成测试环境不达标，如设备及环境的电磁兼容性不合格，导致集成测试不通过，影响验收。 安全管理维度，如：1) 施工现场出现重物落下、触电等人身伤害事件发生；2) 项目组信息安全不到位，导致项目信息外泄，或系统被病毒侵入导致系统塌陷。4.7.2 处理预案及要求（1）应急反应组织机构根据上述
49、所识别的在项目执行期间，可能出现的突发事件，成方策划安排相应的应急反应组织机构与之相匹配，以保证各类事件发生后，分别由不同的人员给予对应处理。（2）应急处理预案根据上述识别的各类突发事件，分别制定不同的应急处理预案，当事件发生时，及时启动相应的处理预案。项目管理类应急预案 项目进度问题1) 周报汇报，及时以每周周报的形式对项目进度延期问题反映出来；2) 沟通会议，以子项目经理为主要问题收集、整理人，召集项目执行副经理及相关项目组成员，会议沟通，提出解决方案；3) 进一步上报项目经理，必要时，向领导小组做情况说明汇报。 人员异动问题1) 进入项目前，实施必要的项目技能培训；2) 采取专人辅导制，即指定专人辅导新项目成员，逐级了解项目业务，到最好独立完成工作任务。质量管理类应急预案1） 指定质量事故处理牵头人，即问题出现在某个子项目组，即以此子项目组的质量负责人为此次事故处理的牵头人，分析本次质量事故发生的原因；2） 召集质量经理，组织召开专题讨论会，制定解决措施；3） 落实措施，质量事故处理牵头人监控措施执行的有效性，并做最终结果上报。采购
