项目质量保证措施

项目质量保证措施

在项目实施过程中，策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。在项目里，评审和测试活动预先策划好，在执行过程中，根据已定义好的过程来执行这些活动。通过执行这些活动来识别缺陷，然后消除这些缺陷。

本项目质量保证贯穿于整个项目的始终，开展有计划、有组织的活动，不断地改进质量。保证通过实施计划中的系统质量活动，确保项目实施满足要求所需的所用过程。项目团队的管理人员采取有效措施，监督项目的具体实施结果，判断它们是否符合项目有关的质量标准，并确定消除产生不良结果原因的途径，通过质量控制确保项目质量目标得以完满实现。通过配置管理控制项目的进化过程，如持续的、变化的变更，为软件系统提供了稳定性，从而保证项目有质量的按规定工期交付。

第一章 质量管理内容 1.1. 编制和评审质量计划

制定质量保证计划：依据项目计划及项目质量目标确定需要检查的主要过程和工作产品，识别项目过程中的干系人及其活动，估计检查时间和人员，并制定出本项目的质量保证计划。

质量保证计划的主要内容包括：例行审计和里程碑评审，需要监督的重要活动和工作产品，确定审计方式，根据项目计划中的评审计划确定质量保证人员需要参加的评审计划。明确质量审计报告的报送范围。

质量保证计划的评审：质量保证计划需要经过评审方能生效，以确保质量保证计划和项目计划的一致性。经过批准的质量保证计划需要纳入配置管理。当项目计划变更时，需要及时更改和复审质量保证计划。

1.2. “过程和工作产品”的质量检查

根据质量保证计划进行质量的审计工作，并发布质量审计报告。

审计的主要内容包括：是否按照过程要求执行了相应的活动，是否按照过程要求产生了相应的工作产品。本项目中对质量的控制主要体现在不同阶段的审计当中。

1.3. 不符合项的跟踪处理

对审计中发现的不符合项，要求项目组及时处理，质量保证人员需要确认不符合项的状态，直到最终的不符合项状态为“完成”为止。

1.4. 质量管理责任分配

我公司在开发项目上按照规范化软件的生产方式进行生产。每个项目除配备了项目开发所需角色外，还专门配备了质量保证小组、配置管理小组、测试小组来确保质量管理的实施，下面针对这三种角色进行说明： 1.4.1. 质量保证小组职责

质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组的主要职责是：以审查方式，从第三方的角度监控软件开发任务的执行，分析项目内存在的质量问题，审查项目的质量活动，给出质量审计报告。就项目是否遵循已制定的计划、标准和规程，给开发人员和管理层提供反映产品和过程质量的信息和数据，使他们能了解整个项目生存周期中工作产品和过程的情况，提高项目透明度，从而支持其交付高质量的软件产品。

质量保证人员依据质量保证计划，通过质量审计报告向项目经理及有关人员提出已经识别出的不符合项，并跟踪不符合项的解决过程，通过审计周报或者审计月报向项目经理提供过程和产品质量数据，并与项目组协商不符合项的解决办

法。

质量保证小组的检测范围主要包括：项目的进度是否按照项目计划执行，用户需求是否得到了用户的签字确认，软件需求是否正确的反映了用户的需求，是否将每一项用户需求都映射到软件需求；系统设计是否完全反映了软件需求；实现的软件是否正确的体现了系统设计；测试人员是否进行了较为彻底的和全面的测试；客户验收和交接清单是否完备；对于系统运行中出现的问题，维护人员是否记录了详细的维护记录；配置管理员是否按照配置管理计划建立了基线，是否严格控制变更过程，是否对配置库进行了维护。 1.4.2. 配置管理小组职责

配置管理活动的目的是通过执行版本控制、变更控制、基线管理等规程，借助配置管理工具的使用，来保证整个生命周期过程产生的所有配置项的完整性、一致性和可追溯性。配置管理是对工作成果（阶段工作成果和产品成果、进展状态成果）的一种有效保护形式，是反映项目及其工作产品的过去、现在、动态的资料和数据集中管理体现。

配置管理小组的主要职责包括：根据项目计划制定配置管理计划，建立配置库，为项目组人员分配配置库权限，创建需求、设计、开发、测试、交付阶段的基线。当纳入基线库的工作产品发生变更时，严格按照配置项变更控制过程执行变更，变更后建立新的基线。 1.4.3. 测试小组职责

作为质量控制的主要手段，如同软件开发一样，测试在执行之前，测试小组制定软件测试计划、测试用例的编写和执行工作。

本项目中，测试可以分为如下几种类型：代码走查、单元测试、集成测试、系统测试。为了保证程序的质量，开发人员需要对同伴的代码进行代码走查，同时对自己编写的程序进行单元测试，确保程序编译、运行正确。

测试人员根据软件需求分析报告进行软件集成测试用例和系统测试用例的

编写。对编写完成的测试用例提交项目组进行评审，同时质量保证人员对评审过程和工作产品进行监测。

测试人员根据测试计划和测试用例执行测试用例，并对发现的缺陷进行记录，只有这样才能确保项目组开发的软件产品满足用户需求。在完成集成测试之后，可以进行软件系统测试，系统测试包括对软件进行功能测试、性能测试、安全测试、压力测试。只有进行了系统测试软件测试才是完整的。系统测试在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。 1.5. 质量保证措施

通过质量管理责任的分配，通过如下几个方面来进行质量保证的实施过程： 1.5.1. 项目进度

项目计划的制定为工程项目实施、管理和支持工作、项目进度、成本、质量及过程产品的有效控制打下了良好的基础，以便所有相关人员能够按照该计划有条不紊地开展工作；制定《项目计划》，必须获得相关干系人的认可，并以此作为项目跟踪的基础。

项目进度是项目进行是否顺利的最直观表现。制定合理的项目计划首要前提是选择从事类似规模和类似业务项目的有经验的项目负责人参加制定项目进度计划。

项目计划由项目负责人制定，由项目各小组组长、项目成员、干系人、质量保证人员参加一起进行评审。评审过程主要讨论项目计划的可行性，对其中不合理的地方提出修改意见，对计划中不合理的地方进行修改完善，并由质量保证人员对其结果进行跟踪处理，以确保项目计划完整性、可行性，项目计划评审通过后，交由配置管理人员进行配置管理。

在计划实施过程中，按项目计划中里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成

的任务时间，动态跟踪和动态调整，以利于项目质量保证的实施。

实际运作中，质量保证人员在对项目执行过程进行检查时，对于发现的项目偏差，以质量审计报告的形式提交项目负责人。由项目负责人组织人员对计划进行维护，对于已经变动的项目计划，由配置管理进行配置管理。 1.5.2. 需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

本项目中，将邀请招标方技术负责人参与需求调研，以便保证需求调研质量，同时形成用户需求说明书。需求评审时会同双方管理层、项目实施层共同进行，对于通过用户确认的需求，交由配置管理员形成需求基线。

用户需求在招标方确认后，由系统分析人员形成软件需求分析报告，同时对软件需求分析报告进行评审，对于评审通过的软件需求分析报告可以交由测试人员进行测试计划和测试用例的编写。

对于开发过程存在的需求变动，招标方填写变更申请单发给项目经理，在质量保证人员参加的情况下，对这个变更进行评审，由项目经理组织项目组成员一起讨论实施变更的可行性及实施后所带来的影响，对于影响小的变更直接记录，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求分析报告、系统设计、安装手册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给招标方并召开协调会议，讨论变更取舍问题或是项目进度变更问题。

决定变更之后，由项目负责人组织实施变更，测试人员检测变更结果，而质量保证人员监督变更实施过程，并协助配置管理员对变更后的成果进行配置管理。

变更实施完后，运行前还需要协助用户一同测试并由招标方签字后同意方可上线。 1.5.3. 系统设计

优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，需要针对项目的结构、项目的特征和用户的需求来分析。本项目中将安排我公司高级系统架构师担当项目总体设计师，汇同总体设计组完成系统设计。

另外对公共类模块的开发。由总体设计组通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义和设计，以减少重复工作。对于项目组提供的设计文档，由项目经理组织，质保小组成员参与，对其设计文档进行评审，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组。最后交由配置管理员进行设计文档的版本控制。 1.5.4. 系统实现

系统实现的目的是依据系统设计文档，由程序员进行程序编写，以便实现设计要求，系统实现过程中，开发人员需要对模块进行代码走查和交叉单元测试，以保证模块代码质量。软件实现也就是代码的生产过程。根据上一阶段形成的设计文档，程序员在完成代码之后，可以开始编码并且进行代码走查和单元测试。对于测试完成的程序可以交由配置管理人员进行配置管理。 1.5.5. 系统测试

系统开发涉及到一系列的过程，每一个过程都有可能引入缺陷（Bug），本系统质量的好坏直接关系到正常使用和日后的维护。在开发过程中，我们将质量控制贯穿于所有阶段和所有参与系统的人员中，包括系统分析、设计和编码。分阶段的评审和测试是软件质量的有力保障。

系统存在平台测试和应用系统的测试以及最终的测试。由于测试也存在协调的问题，如错误具体定位，在应用系统发现一个错误，到底是应用系统的自身的错误还是中间件存在的错误，需要测试人员进行准确的判断。

为了达到良好的测试目的，本系统测试工作由测试组来完成，主要采用下列方法进行系统的测试：

从测试方法上来说，分为黑盒测试和白盒测试：

黑盒测试：着重于测试软件系统的外部特性；根据系统的设计要求，每一项功能都要进行逐个测试，检查其是否达到了预期的要求，是否能正确地接受输入，是否能正确地输出结果。

白盒测试：由于软件的所有源代码都要由项目组成员编写，对其内部的逻辑规则和数据流程，都要进行测试，以检查其代码编写是否符合设计要求。

从测试策略上来说分为集成测试和系统测试：

集成测试：在所有模块都通过了单元测试后，将各个模块组装在一起，进行组装测试，用于发现与接口相联系的问题。在通过组装测试后，将经过单元测试的模块组装成一个符合设计要求的软件结构。

系统测试：在本项目通过了以上的测试步骤后，与其它系统元素（如硬件服务器、网络系统等）进行集成测试和系统级的确认测试，将各种可能的缺陷完全排除掉，从根本上保证系统的长期稳定运行。 1.5.6. 系统维护

本项目中，技术支持小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目的技术咨询工作。

系统维护期，对于一般性的错误，如操作不当等引起的问题，全部由技术支持小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，填写变更申请，经项目组讨论分析可行方案在由技术支持小组实施，通过测试后方可提交用户。在这个过程中质量人员需要对维护过程和维护记录单进行检查。

1.6. 质量管理 1.6.1. 质量保证体系

项目组在网络安全建设过程中，项目组将协调各厂家开发质量体系参照ISO9001标准及国内有关软件开发标准（如GB/T8566-1995等），以确保产品的质量符合我国产品质量要求并得到质量认证。

在项目设备开发过程中，过程遵照SSE-CMMI3标准进行设备内软件开发过程控制。实现项目的可重现性，为后期产品提供项目技术保证。并建立相应的配置管理机构、制定配置管理规程，保证在整个产品生命周期中，程序、策略和文档资料的高度一致，清楚的表明每个阶段的配置状态，为有关的过程制定标准化的规范和条例。

在项目产品内软件开发过程中，每一阶段（项目立项、需求调研、需求分析、高层设计、详细设计、代码实现、单元测试、系统移交等）都制定了具体目标、实施步骤、实施要求、完成标志和交付文档等内容，使整个软件开发过程阶段清晰、要求明确、任务具体，并使之规范化、系统化和工程化。

制定并执行文档及数据管理程序，保证软件开发过程中的各个场所和各个阶段产生完备的和有效的文档，并且保证这些文档被开发者及使用者一致的应用，防止作废的文档和陈旧的数据被不恰当的使用。

通过制定质量管理计划，建立设备内软件质量保证机构，规定保证设备内软件质量所必须的文档的编写标准，规定所要进行的评审和检查工作，规定实施配置管理的范围、内容及程度，收集、维护和保存有关设备内软件质量保证活动的记录等各个方面，来实施全面质量管理，保证设备内软件产品最大满足用户要求。 1.6.2. 质量监控体系

项目实施过程中，每个阶段前项目各相关小组组长将下一步工作详细分配到个人。

工程项目实施过程中，项目组成员定期应向其组长汇报工作，并留下详细报告作为质量记录，从而实现项目过程的可重现性。

在重要的质量控制点，由各组组长配合项目协调质量控制负责现场检查，有

关记录必须完整。

在预先定义的评审点或定期进行质量评审，并形成评审报告。 1.6.3. 项目进度

由于项目总体进度，直接关系到用户的正常业务通讯，因此，在项目总体进度的确定下，项目组将进行具体的各项工程项目、技术产品进行论证后，制定出本项目详细进度计划，项目将严格按照项目进度计划表进行具体实施。同时，项目经理部可以充分调动和指挥相关职能部门的各种资源，来保证项目进度的正常进行，从而实现项目目标。

我司承诺并保证按以下方式进行具体进度实施管理：

对于制定《项目工期表》，项目经理部将会同各相关小组在总体项目进度时间的基础上，共同制订详细的《项目工期表》，因此，能够保证所制定的《项目工期表》切实符合项目组的实际情况。因此，所制定的项目进度生效后能够保证得到具体的完整的贯彻与执行，从而保证了的项目进度可控制管理。

对于项目安装调试部署团队，每周末例会总结一周工作进展情况，并根据工程进度时间表制订下周详细《周工作计划》。

若出现重大异常情况，项目经理将会同项目经理部有权制定应急办法，并可调动和指挥相关职能部门的各种资源，来保证安全数据运营中心项目进度的正常进行。

各小组组长定期向项目经理汇报，原则上是每周汇报一次。 项目经理每周向高层经理汇报。 项目经理定期向项目经理部汇报。 1.6.4. 质量监督保证体系

我期以来始终坚持“提供易用、可靠的产品和满意的服务”的质量方针，经过多年的发展，通过对用户发展状况和变化需求的充分了解，并从客户的基础设施的角度出发选择合适的技术，控制用户的投资规模，把用户的需求与技术优化融合。为提供及时周到的服务构建了一个坚实的平台。

1.6.5. 质量保证的基本思想

项目建设全过程将采用最新国际标准的质量保证体系，使总集成服务得到可靠的保证。用户选择我司，可以从两方面得到保证：一方面是我司的实力和技术能力给了用户充分的信心，并且也是工程质量的保证；另一方面，我司把自己的信誉看成企业的生命，对自己的产品以及形象一丝不苟，决不会因一时的得失而损害用户的利益。

质量保证过程中的基本思想是“戴明环”质量控制思想体系，即著名的PDCA原则，如下图说明：

采用PDCA原则进行质量保证

以下对其中的几个工作环节进行说明：

1）计划（Plan）——实施过程中的各阶段工作需要合作双方先经过协商制定出完整的工作计划；例如：当进行实施工作时，需要制定每周的具体工作计划；所有的工作计划都需要双方正式签字，生效，并按照执行。

2）实现（Do）——计划完成的及时性和性需要合作双方共同努力，双方都将监督本方人员按时高效地完成既定计划；都应制定必须的考核和奖惩制度，制定专职人员负责相关工作，使计划能够得以确切的落实；双方还都有考察对方计划执行情况的义务和权利。

3）检查与评审（Check）——每个工作计划到期时都将由双方进行评价，对其中未完成的内容找出具体原因，制定改善和补救措施；项目实施过程中所产生的全部文档、问题反馈、会议及交流记录等都必须以规范的文档化的形式出现，

同时都必须经过双方的确认和评审，签字后才能正式生效；尤其是对于过程中所出现的问题需要双方进行多次的确认评价，直至修改完成。

4）改善（Act）——在整个的项目实施过程中能否具有“持续改善的能力”一定程度将决定项目的成功与否，因此项目实施中双方需要多沟通交流，尽早发现问题和不足，并立即改善，保证整个项目的顺利完成；实施中工程领导小组将负责全局性的工程进展，对出现的问题和不足协商解决，改进。

系统安全等级保护在集成实施的全过程将采用最新国际标准的质量保证体系，使项目实施得到可靠的保证。用户选择我司，可以从两方面得到保证：一方面是我司的实力和技术能力给了用户充分的信心，并且也是工程质量的保证；另一方面，我司把自己的信誉看成企业的生命，对自己的产品以及形象一丝不苟，决不会因一时的得失而损害用户的利益。

具体地说，对于系统安全等级保护工程主要有如下几点：

 在每个阶段开始时，需要对准备情况进行认真审查，并向工程领导小组汇报，确认已经具备了开始当前阶段工作所必须的条件后，才可开始该阶段的具体工作；

 实施中的每个阶段有阶段工作计划，具体工作中每周有工作周计划，所有计划需要经双方讨论确认并签字生效；

 实施中双方都应按时、完成任务，并督促对方的工作；

 实施中每阶段结束，每周工作结束，需对原定计划进行双方参与的总结，形成总结报告，对其中未按时完成部分制定补救措施和整改计划，为下一阶段的工作做好准备；

 实施中所产生的需求分析文档、总体设计、策略设计都必须由项目组进行评审，尽早发现问题所在，及时进行修改使后续工作能够正常进行；

 以上文件评审合格后由双方签署评审意见后生效，将作为下一步工作的规范和标准，用户需求原则上不应再发生变更；如遇特殊情况需要改变需求，届时由双方再协商解决；

 充分考虑到系统安全等级保护工程的复杂性，数据量庞大的特点，我司实施人员在公司只可能进行系统功能测试和在我司的测试部门进行一定部分的系统测试，系统进一步的的系统测试将现场进行，这需要用户项目组提供大力帮助；同时系统安全等级保护工程测试情况数据，协商确定系统测试安排，并根据

测试结果调整后续工作计划和进度；最终进行第三方测试工作。

 实施过程中加强沟通，包括现场工作周报，用户周报等，通过充分的信息交流了解彼此的进展情况，保证计划按时完成。

根据以上原则，在整个开发过程中，我司将运用一系列的质量保证手段保证开发质量。运用CASE工具进行需求分析及软件设计，使软件易于理解、易于维护、易于测试。确保系统的正确性、完整性、实用性和高效性。

第二章 风险管理 2.1. 风险分析方法

风险分析是一个持续实施的过程。在一个项目从始到终，任何新的或变更的风险应重新进行风险分析。对每一个风险确认应完成以下的风险列表和评估表：

1. 风险描述：针对项目建设中的风险内容进行描述，归类清晰明确； 2. 风险影响类型和可能影响的日期：针对信息安全集成类项目的风险影响类型和可能影响的时间进行确认；

3. 风险告警标记：针对该项目特点进行描述； 4. 风险可能性：针对该项目特点进行描述；

5. 潜在的和可能的风险成本：针对该项目特点进行描述； 6. 风险优先级：针对该项目特点进行描述。

2.2. 风险确定方法

确定项目中潜在负面结果的不确定性。在项目生命周期中尽可能早的确定风险并存放在风险评估报表中，同时风险确定要在项目生命周期中持续进行。

在开始项目风险确定时，所有项目组成员有责任去发现自己负责部分工作中的潜在风险，并在每周的项目组例会上提交，或者在风险比较紧急的情况下直接提交给项目经理。

通过实现软件和技术结构的经验，我公司设计了一个风险评估报表由以下几类构成：

1. 与运行支持相关的风险 2. 与应用操作相关的风险 3. 与人力资源成本相关的风险 4. 与项目实施时间相关的风险 5. 与技术使用相关的风险

每一类列出可能的风险项目，并询问客户此项风险在项目中作为低／中／高风险考虑。

这个评估或者由几个关键小组成员进行并交给项目组讨论，或者由关键的项目组成员在会议上讨论并记录下共同的评估结果。

在这些评估会议中，新的风险项目要加到风险评估报表中。

2.3. 风险控制方法

降低风险即采取行动去除、减少、最小化项目风险的影响。通过风险分析，形成一个风险降低计划，形式为风险降低策略表，其中包括一系列为项目成功而采取的最小化风险影响的行动，针对每一个风险都指定一个负责人，由负责人负责跟踪风险状态并随时更新风险降低计划。

对于那些影响低、可能性低的风险一般不需要制定风险降低计划，但是这些风险必须要监控，避免发展或转化为高风险。对于需要降低的风险，有以下两个降低策略需要考虑：

1. 预前处理策略：通过清除、减少或避免风险来最小化风险带来的威胁； 2. 意外处理策略：在情况发生时采用一个意外处理计划可以最小化风险的影响。

在整个项目过程中，为了有效的管理风险，如果需要，项目经理需执行下面的活动：

1. 实施风险降低计划，如果通过发现风险告警标记为正面，那么可采用预前处理策略，执行风险降低计划；

2. 评估风险降低计划的效率；

3. 再评估：针对项目中动态变化的风险，每周要再评估这些风险的状态。

2.4. 过程风险及控制

在项目实施中，可能遇到管理类和技术类两个方面的风险。

2.4.1. 管理类风险

管理类可能遇到的风险包括：保密风险、政治风险、商业风险和隐私风险，具体描述如下：

管理风险描述 可能遇到的风险 风险描述 主要涉及到内部保密信息的泄露。在我司通过访谈、文档或问卷等评估手段进行评估过程中，某些信息将会保密风险 出现泄露情况，其中技术上不仅包括业务系统的数据流等，还包括管理上某些策略等信息，以及一些技术信息如密码、培植文件等。 主要指内部某些事件的披露会导致某些政治或声誉政治风险 方面的影响，例如某些故障损失或是安全事件的内部信息，这样的风险影响往往造成的是无形资产的损失，而且这些损失的严重性超过一般直接资产的损失。 这类风险主要涉及到信息披露是否违反与第三方厂商之间签订的技术合同。特别在技术文档信息的披露过程中，第三方厂商的众多信息，如设计思想、产品选型、商业风险 技术方案等关键信息的披露都可能违反了和厂商签订的商务或技术合同中的保密性条款，导致违约性的风险。商业性风险也包括披露信息公开化后造成竞争厂商对手之间的矛盾。 这类风险主要涉及到人员信息的披露，人员信息往隐私风险 往包含较多的个人隐私，这部分信息的披露对于工作人员的日常生活和工作存在一定的风险。

针对以上管理类风险，常规的规避措施如下：

管理风险规避措施 可选择的规避措施 规避措施描述 对于非技术信息的披露主要还是通过法律方面的手段进行，包括通过合同、协议的条款方式对双方法律规的责任和义务给予指明，尤其是针对敏感信息的传播避 给予严格的，并提供相应惩罚性条款给予制约。一般来说，建议和合作厂商签订强的保密协议，保证有效的风险规避。 事前规避 对于用于评估的信息，需要从技术、管理和多角度进行筛选，通过敏感信息的过滤、信息实体的模糊筛选规避 化等多种方法对信息披露造成影响实施规避。比如针对网络拓扑情况的披露，可能就需要略去某些IP地址或是具体设备型号的方式；另一方面，也可以针对某些人员的信息采用略去相关人员的名字的方式提供敏感信息。 如果由于非技术手段造成的风险已经发生，那么对于技术类的风险还是采用紧急响应的方式，而对于非技事后规避 术类的，如法律、政治、隐私等范畴的风险，须采用其他方式，原则上建议首选法律方式，同时结合相关信息屏蔽的方法，减小信息披露造成的影响。 2.4.2. 技术类风险

技术类可能遇到的风险以及相应的规避措施如下：

技术类风险描述 在项目实施进场工作之前进行有效的风险预测，同时事先采取手段对风险进行规避，可以有效降低工作中发生事故的概率，不仅如此，我们还提供

了在风险发生以后，如何采取有效的措施进行风险的补救，以使风险造成的系统影响减小到最小。 可能遇到的风险 风险描述 通常会造成轻微的系统性能下降（5%左右），会由于系统扫描造造成短暂的网络性能下成的系统性能下降（5%左右），时间一般降或停止 不超过10分钟。一般不会发生系统停顿等严重故障 在评估过程中由于某些特殊的操作造成的部分实施过程中发生的业务数据丢失 业务数据完整性受到破坏，极少数发生这种情况（<1‰），在做好备份后通常可在短时间内恢复（<半小时） 在评估过程中由于某些实施过程中发生的系统功能丧失 特殊的操作在极少数不可预知的情况下会发生发生系统功能丧失（<1‰） 在项目实施过程中，由于系统割接上线，策略由于系统割接导的配置不完整或有误，致的业务中断 或者系统部署的兼容问题等会造成部分或全部业务的中断 技术类风险常见的规避措施如下：

常规措施：系统备份、冗余规避、规范操作、应急预案和回退预案操作 常规措施：系统备份、冗余规避、规范操作 常规措施：系统备份、冗余规避、规范操作 规避措施 常规措施：系统备份、冗余规避、时间规避 特殊措施：对已知系统上具有的漏洞不再加以扫描以缩短时间和降低发生故障的概率

技术风险常规规避措施 系统备份 时间规避 对系统配置、重要数据等进行备份。 在夜间等系统负载较轻的时候进行工作。 规范服务流程； 规范操作 严格选择服务人员； 用户进行全程监控； 制定可能的恢复计划。 出现实施过程中的故障和不可预见的各种问题可以采应急预案和回退取实现制定好的应急预案和回退预案。割接后造成业务预案 中断，无法短时间内恢复，即宣告割接失败直接，采取回退措施。 第三章 内部管理制度

3.1. 沟通管理

项目沟通管理就是要保证项目信息及时、正确的提取、收集、传播、存储以及最终进行处置，保证项目班子内部的信息畅通。班子内部信息的沟通直接关系到班子的目标、功能和组织结构，对于项目的成功有着重要的意义。

本次项目建设过程中，我公司将采用各种完备的项目沟通流程与协调方法，就项目实施过程中的进度、阶段成果以及实施过程中可能存在的问题和需要双方进行确认的关键过程，与甲方单位相关项目参与人员进行充分的沟通，确保参与项目的各方人员能够随时对项目进行过程跟踪和关键里程碑控制，降低项目实施的相关风险，提高项目实施的效率和双方的项目参与程度，加深甲方单位相关项目人员对项目的了解，提供适时的、必要的关键支持。这些管理和沟通措施将对项目的过程与质量的控制和保障都具有重要而关键的作用。

3.1.1. 日常沟通

鼓励项目参加各方在项目进行过程中随时对相关问题进行沟通。所有重要的、有主题的日常沟通活动都应留下记录或形成备忘录。日常沟通的主要渠道包括：

1) 非正式会议 2) 电话 3) 电子邮件 4) 传真等 3.1.2. 沟通报告

各种沟通报告是项目各方互相沟通的最正式的渠道和证据。一些必备的项目报告包括：

1) 项目计划和进展报告 2) 项目问题报告 3) 项目总结报告

4) 以及在各个阶段输出的项目成果文本等 3.1.3. 临时沟通

当项目实施过程中，遇到影响较大的意外事件时，项目组须召开临时项目组会议进行通知和研究。项目组临时沟通会议纪要同项目沟通例会的《会议纪要》。 3.1.4. 应急沟通

对于非工作时间区间内发生的意外事件，采用应急沟通办法，主要采用电话、邮件沟通方式，在必要情况下，召开现场会议进行研讨和处理。 3.1.5. 问题与争议管理

在项目中，任何不能达成一致的观点均为争议，争议发生时应立即向项目的上级单位呈报，并报本公司项目管理组。争议应由可以协调争议各方的机构加以

裁决，并对裁决承担责任。争议裁决人由本公司项目经理选择。争议的最高仲裁机构为项目领导决策组，如项目领导决策组仍不能达成一致意见，则遵循 “谁决策，谁承担决策失误给对方和项目带来的损失”之原则。 3.1.6. 项目协调会

会议是项目管理活动的重要形式，是项目各方进行正式沟通的渠道。本项目实施过程中，项目双方需要安排各种不同形式的项目协调会议，对项目实施过程中的关键里程碑和关键过程进行合理、有效地安排，确保项目的顺利执行。

1) 项目启动会议

项目启动会议是项目正式启动和开始的标志，项目启动会议之后，项目正式开始，双方项目组从此进入了项目状态。此会议的主要工作是宣告项目正式开始，双方的领导阐明对项目的期望和支持，双方就项目组的组织架构和工作计划进行沟通和确认，此会议对项目的后期发展方向非常重要。 输入 《甲方单位本项目工程实施计划》 1、我公司相关领导和项目成员 参与者 2、甲方单位方面相关领导和项目成员 时间安排 项目正式开始时，持续时间（2－3个小时） 1、介绍双方项目组织架构和成员 过程描述 2、甲方单位的相关领导讲话，阐明对项目的期望和支持 3、我司相关领导讲话，阐明对项目的重视、投入和支持 《甲方单位本项目工程项目启动会会议纪要》——此文件将记输出 录和描述在项目启动会中参与的相关人员的情况，包括各自的发言、讨论和达成的重要一致等，此报告将作为项目启动的和进展的重要依据。 2) 项目蓝图会议

蓝图会议的主要工作是双方项目组定义项目详细范围，双方就项目的详细工作计划、流程和项目输出成果进行沟通和交流，并达成共识，最终会签署项目蓝图系列文档。项目蓝图系列文档会作为项目验收的重要依据。

蓝图会议中双方就项目计划和最后成果进行了充分的沟通，可以调整双方的项目期望和衡量标准，保证最后的输出成果符合甲方单位的期望，为项目的成功打好基础。 输入 《甲方单位本项目工程总体实施计划》 1、我公司项目经理及项目主要成员 参与者 2、甲方单位项目负责人及主要项目成员 时间安排 过程描述 输出 项目启动会后，即项目正式开始后的第一周的前两个工作日 1、沟通、讨论、修改和确认项目实施计划 ➢ 实施方案 ➢ 《本项目工程实施时间表》 3) 项目周例会

为确保项目正常进行和对项目实施工作进展进行监控和管理，项目双方每1周举行一次项目例会，汇报本周项目进展状况、出现的问题和下周的工作计划。 输入 《甲方单位本项目工程本周工作进展》 1、我公司项目经理 参与者 2、甲方单位项目负责人及主要项目成员 时间安排 初步确定项目正式开始后的每周周五作为双方的周例会时间，例会持续时间大致为下午一到两个小时 1、本周项目完成情况汇报，每日主要工作成果汇报 2、存在的问题及解决办法分析 过程描述 3、下周的工作计划 4、对可能发生的配置管理和变更控制签署相应的文件

➢ 《甲方单位本项目工程周例会会议纪要》——此报告将描述本项目在各个阶段进展的具体情况，使得项目的各方输出 对项目的进度有全面的了解，促进各方对项目的支持和投入； ➢ 可能的变更文件 4) 项目阶段工作会议

在每个项目关键阶段结束时，项目双方需要召开一个正式的项目阶段工作会议。该会议对前一个阶段进行总结，对项目的阶段成果进行评审和验收，同时对下一个阶段工作计划进行确认和沟通。 输入 《甲方单位本项目工程各阶段成果》 1、我公司项目经理 参与者 2、甲方单位项目负责人及主要项目成员 时间安排 项目关键阶段结束时 1、项目完成情况汇报 2、阶段工作成果评审 过程描述 3、存在的问题及解决办法分析 4、对可能的配置管理和变更控制签署相应的文件 5、下阶段的工作计划确认和沟通 ➢ 《甲方单位本项目工程进展报告》——此报告将描述本项目在各个阶段进展的具体情况，使得项目的各方对项目的进度输出 有全面的了解，促进各方对项目的支持和投入； ➢ 项目阶段工作评审意见 ➢ 可能的变更文件 5) 项目预审会议

在本项目的各阶段工作结束后，针对项目阶段工作成果，双方项目组需要进行内部预审。本公司项目组讲解和汇报阶段成果，甲方单位项目组进行评审，并

提出改进意见。双方意见一致后，标志内部评审通过，会安排项目组外的专家与相关各方参加对项目阶段成果的正式评审会议。

1、最终阶段成果和输出报告 输入 2、项目蓝图系列文档 1、我公司项目经理、相关领导及项目主要成员 参与者 2、甲方单位项目负责人及主要项目成员 时间安排 过程描述 1个工作日，项目阶段工作完成后 1、最终成果和输出报告讲解和汇报 2、项目工作成果评审意见 《项目预审意见》——此文档将描述甲方单位项目组的内部评审意见 输出 6) 项目评审会议

在项目的阶段或具体工作全部结束后，双方项目组完成内部评审，达成一致，会安排项目的相关各方和专家参加对整个项目的成果和过程的正式评审工作。

1、《甲方单位本项目工程评审申请表》 输入 2、最终成果和输出报告 1、我公司项目经理、相关领导及项目主要成员 参与者 2、甲方单位项目负责人及主要项目成员 3、甲方单位邀请的相关专家 时间安排 项目的阶段或具体工作全部结束后 1、最终成果和输出报告讲解和汇报 过程描述 2、项目工作成果评审意见 输出 《项目评审意见》——此文档将描述本次项目的评审意见和评价，标志着项目最终评审通过

3.2. 变更管理

对于任何复杂的项目，项目目标和实现方法的修改都是不可避免的。在项目变更申请被提交及获得许可后，需要进行修改依然是可能的。我们将会对项目中可能出现的新增需求变更进行评估，并通知项目建设方这项变更是否被通过。如果某项变更对项目的影响很大时，项目建设方将需要决定是否批准所需的花费及是否将其作为项目中一个单独的阶段加以完成。根据我们的经验，变更管理不力是导致项目不能按质如期完成的重要原因之一。所以，项目建设方和本公司双方应该进行恰当的项目变更管理。

附图 项目变更处理流程

3.2.1. 变更流程

项目发生变更前，由项目组提出变更申请（，说明变更原因、变更利益、变更成本、变更带来的影响以及变更实施计划等，并提供相应的支持性文件。

按以下流程进行变更审批：

——对于一般变更由项目组提出，经工程部批准后进行实施；

——对于未超出项目总批复预算的重大变更， 由项目组提出， 经设计单位技术确认， 工程部审核，公司分管副总经理批准后实施；

——对于超出项目总批复预算的重大变更、 技术方案的变更， 由项目组提出， 工程部组织相关部门进行论证，论证通过后，拟文上报公司批复后实施；

对已批准的项目变更，项目组应按计划进行实施，并确保变更内容的实施质量及安全性满足相关要求。

3.2.2. 变更评估

项目经理为变更请求分配唯一的一个变更请求号，并记录在变更请求登记表中。

评估者(通常是项目经理)将检查变更对项目各个因素的影响，并在变更请求中将评估结果形成文档。评估者要特别注意决定：

1. 对项目范围和项目进度的可能变更； 2. 对评估目标和需求的变更； 3. 不进行变更的影响；

4. 对变更的任何其它可能的选择；

5. 与变更有关的所有成本包括：对硬件和网络配置、能力和性能的影响，涉及第三方成本，其它的软件产品，任何进度延迟的成本，任何其它发布、整合或测试周期的全部成本；

6. 对项目文档的变更； 7. 其它的培训需求。 3.2.3. 变更的审批

变更申请提出后，业主单位根据变更可能影响合同工期、质量、进度、造价等要素进行综合审查，提出书面变更审查意见交代建单位，由代建单位组织业主、施工、设计等单位共同研究同意后，形成会议纪要，交由原设计单位出具设计变更，并经业主、代建共同签署后下发工程设计变更文件，由施工单位组织实施。 3.2.4. 变更实施

施工单位必须严格按设计变更后施工图要求组织施工，不得随意更改，设计变更通知书作为工程结算的依据。 3.2.5. 变更结束

结束变更请求之前，需要确认： 变更实施工作已完成。

采取了任何其它正确的行动。

根据需要产生了新的或更新的项目文档。 对配置项目的变更记录在“项目交付清单”中。

更新了项目变更登记表，所有相关文档归档在项目管理手册中。 3.3. 风险控制

风险控制是项目管理计划的组成部分之一，基于项目启动前的风险评估、分析和减负而产生。风险管理是一个重复的过程，从项目开始时贯穿整个项目生命周期。

由于本次项目系统建设内容复杂、技术含量高，且建设过程中涉及的部门众多、实施范围广、项目建设流程复杂、技术实施难度大，给项目的建设带来较大的难度。同时还存在与外部多个不同部门及单位进行协调， 需要面对项目最终的验收及审计， 工程整体建设过程存在极大的风险，鉴于本项目的实际情况，以及本公司在类似大型项目中的实施经验，建议和措施如下：

一、针对项目实施带来质量风险的建议和措施

结合前面所阐述的质量控制， 对于工程实施中的质量风险， 本公司建议成立项目联合质量控制组，对工程质量进行全过程的跟踪与监督。并定期组织关于工程质量的专题会议。在实施过程中，对于工程建设的质量控制针对各分项工程在不同阶段的不同特点，采用检查、督导、旁站、审核等措施，实施对工程建设的质量控制。

二、针对工程合同造成法律风险的建议和措施

在合同谈判阶段，建议对合同建设内容、范围、质量目标、职责、违约、验收等进行严格界定，并进行必要的审核， 对合同中存在的漏洞和不清晰地方进行修改， 规范合同签订的流程，同时规范、 谨慎的处理合同变更问题。 在合同执行过程中严格履行合同内容， 并进行跟踪检查，切实落实工程建设合同所约定的内容。

三、针对变更和设计带来投资风险的建议和措施

针对变更和设计问题所带来的投资风险问题，结合前面章节中所谈到对投资、变更的控制，

对投资风险的控制主要集中在： （1）招投标工程范围界定

（2）承建合同中关于合同金额的签订 （3）实施过程中对变更的控制 （4）最终的工程结算

建议在工程建设过程中必须做好方案的论证工作，建立规范的申请 /批复流程，严格进行工程中设计及实施方面的变更审核，并制定付款的申请 /支付审查流程和审查措施，同时，对涉及投资的各个环节和审查进行监督，避免项目建设的投资风险。

四、针对建设目标风险的建议

需求方需要明确本工程建设的最终总目标； 确定了最终目标才能保证各项系统需求方向的一致性。需要根据最终总目标倒推的方式科学的确定分项建设目标和阶段性目标； 以确保整体目标的可实现性。 在确定目标后及时通过会议的形式在工程建设范围内的各部门和相关人员中普及并统一建设思想。 正式移交之前， 需求方应根据既定目标对已经完成的工作成果或工程活动结果进行重新审查， 在进行工程范围核实时，承建方应向需求方出示能够明确说明工程（或工程阶段）成果的文件，如工程计划、技术要求说明书、技术文件、图纸等；并由业主方负责将核查结果记录在案。 3.4. 进度计划保证 3.4.1. 严格进行进度控制

针对本项目建设，我公司采用分级控制方法进行进度控制，有两种类型即总进度控制和各详细进度控制，项目经理和PMO主要控制总进度，各项目小组控制各自工作范围内的详细进度。下面我简要说明本项目总进度控制。

一、进度控制过程

进度控制活动包括编制计划、实施计划、检查、对比分析、确定对策、更新计划，是一个封闭循环不断运行的过程。该过程的描述如图所示。

编制或更新进度计划组织措施实施进度计划管理措施资源动态监测技术措施对比分析Y与进度计划一致？N对策

进度控制过程图

二、建立三级计划进度管理体系 1、组织措施

专职的进度控制组，项目经理和进度控制组是进度控制的主要责任人。 2、三级计划进度管理体系的贯彻途径 （1）完善例会制度

①每周召开至少一次由各方负责人参加的项目例会； ②必要时召开有关进度问题的专题会议。 （2）建立沟通渠道

①各单位相互通告进度管理体系架构，建立本工程进度管理体系成员的联系总表；

②各相关单位之间，需建立纵向、横向联系。各级负责人之间，应及时进行指导、反馈、预警、建议等工作交流；

3、三级计划进度管理体系的工作流程 （1）一级计划——总控制进度计划

①此计划为项目指出最终进度目标，为各阶段和子系统建设均指出明确的开工、完工时间，并能反映各阶段工程相互间的逻辑制约关系以及关键路线；

②总控计划一经确定，便成为项目实施的纲领性文件，各方均要严格遵照执

行，不做轻易调改；

③应规定建设各方必须遵守总控计划，任何一方符合或违反工期规定，在合同中均应规定有对应、明确的奖惩措施。

（2）二级计划——阶段性工期计划或分部工程计划

①二级计划的制订是为了保证一级计划的有效落实，故而有针对性地对具体某一阶段任务做出安排；

②二级计划的制订，原则上必须符合总控制进度计划的工期要求，如出现不一致情况，需经甲方认可，或修改后再报；

③对于外包的开发任务，应对分包单位的二级计划的执行情况引起足够重视，加强落实、检查的管理力度，出现异常进度动向时，必须拿出有效的解决措施，务必保证阶段工期或子系统工程的进度目标实现，为总进度目标的实现奠定基础；

（3）三级计划——周计划

①周计划的制订是将二级计划进一步细化到日常的工作安排中，是最基本的操作性计划，应具备很强的针对性、操作性、及时性和可控性；

②周计划的制订最主要是切合现场实际需要，可具有相当的灵活性，可在灵活性、全面性和可操作性等方面给一、二级计划以极大弥补；

③周计划的上报时间是每周项目例会之前。 4、三级计划进度管理体系的管理措施

为保证项目进度，在三级计划进度管理体系中采取了以下管理措施： （1）加强进度计划的贯彻。其工作内容包括：项目经理和进度控制组负责组织检查各类计划，形成严密的计划保证体系；要求各小组依据项目总计划制定自己的工作计划，并保证与总计划保持一致。项目部在每次计划调整以后应召集相关责任人进行计划全面交底，明确责任，使管理层与作业层协调一致。

（2）调度工作：项目经理和进度控制组通过监督、协调、调度会议的方式掌握项目计划的实施情况，协调各方面的工作，采取措施解决各种矛盾，加强薄弱环节，实现动态平衡，保证完成计划和实现进度目标。

（3）抓关键工作：集中优势力量保证关键工作按期完成。协调保证人力资源、资金、办公环境等资源的及时供应。加强组织管理和进度控制工作。技术负

责人定期总结各组的工作经验并推广先进的技术方法。

三、项目动态监测

项目各级管理人员运用项目管理信息系统监测进度。具体方法为：日常监测分析使用实际进度前锋线记录法和甘特图比较法。定期监测分析采用项目进展报告方法，项目管理员定期把进度监测的结果以项目进展报告和S曲线图的形式向项目经理汇报；项目经理审批后分别以不同的形式和内容向有关部门汇报。

本项目采用的项目进展报告形式有：项目/任务进度报告，任务完成报告，重大突发事件报告，项目管理报告，项目变更报告；报告应符合事先制定的工程管理制定的标准格式。

四、项目采用的进度控制 1、合理制定计划

根据历史数据较准确地估算项目规模，制订切实可行的项目计划，在项目进度表中保留缓冲时间。

2、工作会议制度

各组织之间的良好沟通和协作非常重要，我们除了采用一般的电话、EMAIL的沟通方式外还将执行会议制度，包括定期例会和不定期技术交流、讨论。目前确定为每周召开项目例会，由项目经理、质量专员以及相关小组人员发参加，每天由项目经理组织召开项目通气会，各个小组之间相互进行情况交流。

3、阶段划分与评审

使用项目里程碑，大里程碑 + 小里程碑。在软件开发过程中，请顾问专家和用户按照里程碑评审阶段性的成果，判定开发成果是否与软件项目定义的里程碑保持一致。

4、进度控制

（1）对照任务网络图检查各子任务的实际开始时间是否与计划时间一致。如果拖后，应查明原因，尽快采取措施，利用机动时间赶上进度，尽量保证不要影响后面的计划。

（2）采用每日构造过程，开发与测试同步并进。

（3）使用时间表安排和管理所有项目组成员的每天的时间（精确到工作单元）。

（4）个人的工作进度误差不允许跨越小里程碑，工作小组的进度误差不允许跨越大里程碑。

5、过程监控

向项目开发人员及时了解项目进展情况及存在的主要问题。管理人员确保项目能够按照进度表的要求正常进行。一旦发现问题，管理人员迅速查明原因，尽快采取措施，争取在尽可能小的范围内解决问题。 3.4.2. 做好进度偏差管理

一、进度偏差产生的原因

根据项目的大小和不同，在进度偏差产生的原因多少会有区别，且进度偏差产生的原因也较多，针对于本项目概况起来主要有以下几方面进度偏差产生的原因：

1、业主方面的原因引起的进度偏差：业主提供的开发准备工作完成不足;业主未按期提供本系统所需的技术资料;业主未按合同规定及时提供材料、资金等。

2、设计方面的原因引起的进度偏差：设计交底不清，承包方对设计意图理解不够，造成对技术处理方面的分歧而影响建设进度;设计变更频繁，工程量变化大或返工浪费大;出现问题处理不及时，相互协调配合差等。

3、承建方面原因引起的进度偏差：项目实施不落实，管理混乱;技术方案变动频繁；人员变动；与业主、设计等单位配合不协调等。

4、业主单位方面的原因引起的进度偏差：重视质量控制而忽视进度控制; 业主工程师履行职责不力，决策不果断，甚至发布错误指令; 业主工程师未按建设合同规定及时处理开发项目中出现的问题，拖延工期; 业主工程师与业主、设计及承建方配合不协调等。

5、不可抗拒的因素引发的进度偏差。 6、工期提前所引起的进度偏差等。 二、进度偏差管理手段

项目实施过程中出现进度偏差是在所难免的，实施进度控制就是要求能对偏差能进行有效的控制，提出相应的解决方案，使之有利于项目的进展。在项目中，

我公司总结的一系列简单有效的偏差解决方法。 3.4.3. 针对本项目的进度保障措施

在项目管理上，我们在多年从事工程项目实施的基础上，形成了一整套项目质量控制管理办法，而且这些项目的质量控制体系已经通过了国际ISO9001认证，公司有多名认证项目经理。在工程实施上我们采用项目经理负责制，项目组中不但有工程技术人员，还配有专门的进度及质量保障人员对整个项目实施过程中进行监控和管理。

项目管理是对项目实施过程的管理。项目管理过程有5个基本的管理过程：启动、计划、执行、控制和收尾。

项目的实施过程是由一系列的项目阶段或项目工作过程构成的，任何项目都可以划分为多个不同的项目阶段或项目工作过程。同样，对于一个项目的全过程所开展的管理工作也是一个的过程，这种项目管理过程也可以进一步划分成不同的阶段或活动。我们通过对每个阶段或活动的严格管理和控制，实现对本项目的进度保障。

1.1.1.1. 人力资源保障措施

我公司将调用技术骨干人员参与本项目的建设，并组建合理的组织机构。 针对本项目的实施要求及项目规范，我公司设置的项目组织机构包括项目组领导、项目组办公室、基础服务组、质量管理组及测试组、配置管理组、商务保障组、培训组以及售后服务组等。其中项目组领导由公司信息安全事业部总经理郭峰担任。

我公司还将专门安排一名10年以上相关经验的资深商务经理，全面负责业主方与承建商的商务和财务管理，建立良好客户关系，做好项目预算和成本控制，最大限度保证公司对本项目的资金支持，并在项目的每一个阶段严格控制预算支出，以防止某一个阶段大量超出预算，从而导致工期的整体延误和项目失败。

1.1.1.2. 进度计划保障措施

1、目标

（1）为项目软硬件产品实施和管理控制制定合理的计划；

（2）对项目的规模、工作量、成本、进度、关键计算机资源等进行估算； （3）建立对软件项目的约定，并取得相关人的认可。 2、人员与职责 角 色 项目经理 职 责 制定项目的总体实施进度计划 根据需求变更的影响修改项目的实施进度计划 组织项目计划评审 制定验收计划 协商与相关组或个人的相关约定 项目组成员 参加项目策划 参加项目计划评审 SQA工程师 参与制定项目的实施进度计划, 为满足项目需求, 在剪裁组织的过程方面提供指导 参加项目的实施进度计划评审以保证符合相关标准及组织过程 制定SQA计划 软件工程师 制定基线计划 参加项目的软件开发计划评审 高级经理 为项目提供人力和资源 评审/批准项目计划以保证满足组织的目标 评审对项目组外部的组和个人所做的约定 测试工程师 制定测试计划 参加项目计划评审 3、开始条件

（1）具备客户需求，例如：合同、项目任务书、项目建议书等； （2）项目经理已指定；

（3）项目策划所需的资源和资金已到位； （4）相关人员已接受软件估计和计划规程的培训。

4、有效输入

（1）《客户需求》、《合同》、《项目建议书》或《项目任务书》 （2）《需求规格说明书》 5、活动说明 （1）项目预备会

在项目策划早期阶段且具备了客户的需求时，由项目经理主持召开项目预备会议。会议内容包括：

 项目背景、用户需求介绍；  人员的人员、职责；

 技术方案讨论：如开发的生命周期模型、项目的规模、工作量、开发平台、支持工具等；

 项目风险分析；

 根据需求制定相关组/个人的约定。

会议结束后，应形成会议记要，对于制定相关组/个人的约定要经过高级经理的评审。

（2）识别项目的软硬件产品

列出要实施或开发的软硬件产品清单，例如目标码、数据库设计书、概要设计、详细设计、使用手册、操作手册、维护手册等。

（3）确定项目的工作分解结构 (WBS--Work Breakdown Structure) 项目经理依据客户需求和选定的软件生命周期模型，对各阶段的软件工作产品进行工作分解。

工作分解结构是将软件工作产品按时间序列进行串行分解和按逻辑结构进行并行分解，工作任务的分解尽可能地做到详尽、可操作、可度量。

整个项目的工作分解成若干个工作包（Work Package），每一个工作包应是可以被分配、执行和跟踪的。为了便于管理，建议每个工作包小于10个工作日（2周）。

（4）对软件规模、工作量、成本、关键计算机资源进行估算

规模估计的基础是已分解的工作包，软件规模的例子有功能点、特征点、源代码行、需求页数等。对代码规模的估算，其结果用源代码行数表示；对文档规模的估算，其结果用页数表示；用例用个数表示。

工作量估计的基础是规模估计的结果，对于工作量的估算，其结果用人*天表示。

成本估计的基础是工作量估计的结果，对于成本的估计，是对具有不同技术级别的人员*规定的系数，转换为标准人*天，以进行核算。

对关键计算机资源进行估计时应先识别项目的关键计算机资源。关键计算机资源的例子有服务器、PC机、路由器等。对于关键计算机资源的估计，其结果用计算机数量、配置或外设的型号、配置表示，例如内存容量、硬盘容量、处理器能力、网络通信带宽、工作站能力、外设能力等。要确定在关键计算机资源中哪些项必须估计。

估计过程中采用的假设和理由记录在估计结果报告中。具体内容参见《项目估计结果模板》。

将估计结果写入项目开发计划，并与项目计划一起进行评审。 （5）制定项目的软件工程设备和支持工具计划 软件开发设备和支持工具包括：

 用于软件开发的计算机及其外部设备。  用于软件测试的计算机及其外部设备。  用户计算机环境软件。  其它支持软件。

就采购或开发上述设备和支持工具事项，分配职责，商谈约定；此计划应经过受影响的所有相关组的评审。

（6）制定项目进度

项目进度采用Project和中科软协同开发管理平台的形式来进行反映，制定各阶段的开发进度时间表，确定各阶段的任务、目标、完成时间、所需资源等。

在进度中要标明关键路径和里程碑，例如时间段、里程碑描述、里程碑成果、里程碑活动、活动参加人等。

项目经理在制定项目进度时，应遵循以下规程：

 要考虑用户要求的进度，根据软件的规模、工作量、成本、关键计算机资源；

 以及已往的经验进行估计；

 进度表要适应项目的里程碑日期、关键点日期及其他；

 制定进度表的前提条件应记录在文档中；  进度表应形成文档，并提交高级经理进行评审。 （7）确定并分析项目风险

项目组应确定项目环境中存在的风险，分析风险的影响，可能发生的概率及时间范围，对风险进行排序，并给出规避风险的方法。

风险的发生概率可分为五个等级，每一级的概率因子为0.9、 0.7、 0.5、 0.3、 0.1。

风险的影响范围分为三级，各级的因子分别为0.9、 0.6、 0.3。 风险的发生的时间范围分为三级，各级风险的发生时间因子为 0.9（近期/随时）、 0.6（中期）、0.3（远期）。

项目要对风险发生的综合因素进行分析，综合影响为三个因子相乘，并根据综合分析的结果对风险进行排序。

（8）制订项目计划

项目计划通常包括软件开发计划、质量保证计划、配置管理计划等。 软件开发组负责制定《软件开发计划》、《项目验收计划》。项目组根据客户需求和对软件规模、工作量、成本、关键计算机资源、进度及风险估计的结果制定软件开发计划，计划内容参见《软件开发计划模板》。

项目的测试人员，按经批准的《需求规格说明书》制定项目的《测试计划》。《测试计划》在需求分析阶段完成。

SQA工程师依据制定的项目软件开发计划，制定《质量保证计划》。 SCM工程师负责制定《配置管理计划》。 （9）项目计划评审  内部评审

所有项目组成员都要参加项目计划的内部评审。内部评审以例会的形式进行，要有内部评审会议记录。

 会签

项目组内部评审通过后，项目经理组织会签，参加会签的人员有项目经理、相关组负责人。会签意见填入会签表。

 高级经理审批项目计划

会签通过后，项目经理将会签表和项目计划提交高级经理审批。

（10）SCM工程师将项目计划纳入配置管理库

项目计划经批准后，提交给SCM工程师纳入配置管理库。 （11）项目计划的修改

 项目计划执行的过程中，通过对软件项目的跟踪和监控过程发现的软件项目活动与计划偏离后，通过项目经理或其指定人员测量产生的度量数据作为修改的基础。

 通过测量产生的数据与经过审批的计划偏离超出规定的阀值时，项目经理或其指定的项目组内的人员通过对过程现状的分析提出对计划的改进建议，并按《基线变更控制规程》执行变更。

 计划的修改应受控。 6、度量

（1）项目计划活动里程碑的完成情况，与计划比较；（里程碑评审报告） （2）项目计划活动中完成的工作和耗费的工作量，与计划比较。（项目周报） 7、验证和确认

（1）高级经理定期评审项目策划活动。（里程碑评审）

（2）项目经理组织项目计划评审，并提交高级经理批准。（项目计划评审） （3）SQA工程师评审软件计划活动和工作产品，并报告结果。（SQA周报、项目审计报告）

8、有效输出

（1）项目软件开发计划（工作分解结构、估计结果、进度表等） （2）SQA计划 （3）SCM计划 （4）测试计划 （5）验收计划 （6）项目估计结果报告 9、结束条件

（1）软件开发计划、SQA计划、SCM计划通过评审，并提交到配置管理库 （2）项目结束

1.1.1.3. 过程进度保障措施

1、目标

（1）依据项目计划对实际情况进行跟踪

（2）当实际情况与计划相差甚远时，采取相应的调整措施 （3）软件约定的更改应由相关小组和个人同意认可 2、人员与职责 人员 项目经理 跟踪项目的执行情况 监测项目的实际数据，并计算规模、工作量、进度等项的偏差 跟踪需求变更情况 跟踪、标识项目存在的风险 根据偏差情况，按相应的规程修订项目的软件开发计划 项目组成员 按照项目计划执行承担的工作 报告工作完成情况 收集项目有关的数据 提出变更请求 SCCB SQA工程师 评审变更请求，决定项目计划是否需要修订 参加项目计划的评审 对项目组的活动/工作产品进行审核，以保证项目活动与计划和公司的过程/标准相符 对项目组工作产品进行审核，以保证工作产品与客户需求，计划，质量标准，和公司的过程/标准相符 高级经理 参加正式项目评审，评审项目的进展情况 评审/批准项目计划的变化 SCM工程师 将修订后的项目计划纳入基线库 职 责 3、开始条件

（1）项目计划已经制定并且被批准； （2）有关项目的人员，资源，资金到位； （3）项目的工作已经被明确地分配到每个人；

（4）项目经理具备项目管理和有关技术的知识。 4、有效输入 （1）项目计划

（2）《需求规格说明书》 5、项目进展的日常监督

（1）项目组成员通过个人周报向项目经理报告进展情况，所承担任务的进展和投入的工作量，以及相关风险。

（2）项目经理根据项目计划对以下方面进行监督：任务的开始和结束、开发的软件工作产品的规模、工作量、进度、里程碑、成本、关键计算机资源、项目风险管理进展情况、问题及其纠正措施、需求与基线变更，通过填写项目周报和项目月报，报告项目状态。

（3）当项目的实际结果和性能明显偏离项目计划时，重新修订项目计划。 6、召开项目例会

项目例会每周或事件驱动地由项目经理组织召开，项目组成员参加项目例会。参加会议的所有人员要准备有关的项目信息与状态报告。例会的内容如下：

（1）当前的进展及偏差 （2）存在的问题 （3）潜在的风险 （4）技术交流

（5）针对偏差，进行分析，确定解决办法 （6）下一步的工作安排 （7）制定新的行动计划

（8）项目例会的会议记录要归档，项目组全体人员要根据会议结果执行新的行动计划。

7、召开正式项目评审会议（里程碑评审）

通过召开正式项目评审会议，使相关人，尤其是高层管理人员，了解项目的进展情况和项目所取得的成就，决定项目下一阶段的启动。

正式项目评审可以有两种：一个是基于项目的里程碑，召开正式项目评审；另一个是每月定期举行一次。

8、度量

（1）项目的实际规模、工作量、成本、进度 （2）项目的规模、工作量、成本、进度的偏差 （3）需求变化的个数 9、验证和确认

（1）高级经理定期评审项目进展情况。（里程碑评审报告、项目总结） （2）项目经理定期评审项目进展情况。（项目周报、项目月报） （3）SQA检查项目的进展情况。（SQA周报） 10、有效输出

（1）被修订/批准的项目计划（SQA计划、SCM计划） （2）项目里程碑评审报告 （3）个人周报 （4）项目周报 （5）项目月报 （6）项目总结 11、结束条件

（1）项目计划已经被修订并批准 （2）项目结束

第四章 应急措施 4.1. 应急服务内容

我方提供针对应急事件提供应急事件响应服务。我方工程师及硬件产品原厂商工程师将迅速响应，并承诺响应时间完全满足招标要求，尽快提出应急解决方案，及时到达用户现场。

4.2. 应急服务方式

我方将成立一个专门的应急响应小组（Emergency Response Team），制定事

件响应计划，从而建立起一套有效的响应机制。事件响应计划为应对突发事件提供指导，而应急响应小组具体负责计划的实施。

应急小组负责调查突发事件的起因，预期将来可能的发生情况，定期研究并分析历史数据，应急小组得出的结论是补救行动的依据。

4.3. 应急响应内容

4.3.1. 设备及系统故障应急处理

当设备或系统出现损坏造成系统重大故障无法正常运行，我司将启动设备故障应急响应处理，具体处理方法、流程如下所述。

4.3.2. 服务内容

为了保证安全防护系统的正常运转，我方将提供安全硬件产品的备机服务。当产品或系统出现故障时，能够迅速启用备机，导入最近一次备份的策略配置，恢复安全产品的相应功能。备机的硬件配置不低于实际部署的产品。

4.3.3. 服务方式

我方不但将本次工程中的安全产品备机存放在指定地点，同时在我方备件产品库房中也维持同种类同型号安全产品的稳定存量。如果网络内正常的安全设备出现故障，则将立刻用备机替换现场的损坏设备，并用库存中完好设备补充到备机，以保证始终保有状态良好的备机。损坏的设备维修后作为备机继续作为后续储备。如果系统出现故障，我方会指派专业工程师远程支持或赶往现场第一时间将系统恢复正常。

4.3.4. 服务流程

当现场硬件损坏后，申请备件的流程如下：

设备故障

故项目负责库房发货 工程师现场 工程师携带备机到现场后，需要客户核对备件清单，填写备件签收单，并加盖单位公章。损坏的硬件维修后入库继续作为后续储备。

如果情况紧急，则启用应急流程：

在故障出现后先库房发货，保障客户业务运行，同时抄送公司领导备案。损坏的备件维修后继续作为后续储备。

4.3.5. 质量持续改进

定期的服务总结将收集服务过程的形成的《维护报告》、HelpDesk记录、客户投拆、《客户满意度调查》等信息，并对这些信息进行分析处理,找出工作中可改进的地方，优化服务流程，持续提高、改进服务质量。

4.3.6. 附件

《客户满意度调查表》

客户单位：

客户电话：_____________________ 服务时间：_____________________

客户联系人： Case No.： 尊敬的客户：

工程师：

感谢贵方对我公期以来的大力支持和帮助，为了确保今后我们能派遣出优秀的工程师，高质量地为您服务，特别烦请您，将本次任务的服务情况及您的意见及时反馈给我们，以便我们对今后的工作做出调整。谢谢您的合作！

我们服务的质量会直接影响您的切身利益，所以请您告诉我们您真实的感受：

服务评价 要素 您对该服务要1分:非常不满意；2分:不满意；3分:一般；素的重视程度 4分:比较满意；5分:非常满意。 (0-100分) 响应速度 工作完成情况 工作效率 服务态度 技术水平

1分 2分 3分 4分 5 分 分数： 1分 2分 3分 4分 5 分 分数： 1分 2分 3分 4分 5 分 分数： 1分 2分 3分 4分 5 分 分数： 1分 2分 3分 4分 5 分 分数：

意见与建议： 客户签字 日期 第五章 项目实施中割接保障方案 5.1. 割接原则

在本次工程的割接中，需要对原有网络及承载的业务系统访问需求进行充分了解及详尽的技术准备，在整个割接中尽量不间断原有的业务运行或者将影响控制在用户可接受的范围。在割接前要准备详细的割接文档，并在实验室对方案的可行性进行测试验证；在割接过程中采用以往割接时使用的成功的测试手段来验证割接是否成功，一旦出现问题，按照割接文档中的应急预案解决问题，使得割接可控。我们基于以下原则设计割接方案：

 平滑实施：业务不受影响或将影响控制在用户可接受的范围。  步骤简单：将整个割接分为多个简单步骤，降低每一步割接复杂度和操作难度，保证割接的成功。

 步骤可控：每个步骤都有验证手段，避免错误的扩散。

 步骤可逆：每个步骤都可以回退到上一步，如果发生意外，仍然可以保持网络的正常运营。

5.2. 割接关注点 5.2.1. 业务影响层面

针对每次割接，均需要对割接业务影响范围、割接涉及业务配合人、业务运行的时间段及可接受断网时间段进行统计分析。

割接方案中要考虑割接的前后顺序，先调整谁、对哪些业务有影响，先调业务还是先调网络。

考虑分阶段、分设备区域来减小业务割接风险。对公众业务、内网关键业务的割接在充分调研业务影响后，如割接有公众影响需要考虑通过新闻媒体、网站公告等形式提前通知。如割接对内部业务系统产生影响，需要通过邮件、部门协作、召开部门间割接沟通会等形式予以提前通知，以便各部门提前做好各项准备工作。

5.2.2. 数据通信层面

网络是数据访问的基础，网络的割接调整直接影响到业务系统访问及终端用户的切实感知。因此网络设备的扩容、替换需要充分对割接涉及的现网设备进行调研分析。

调研工作主要包含如下内容：

 对需要保障实时性较高业务的处理措施（例如通过调整动态或静态路由的优先级、COS值提前将流量迁移）

 现网设备的硬件运行状态  配置脚本的逐项分析  链路状态的检查  各端口流量情况统计

 路由走向、动态路由的重分发、静态路由的掩码范围及下一跳的梳理

 网络设备的访问控制策略

 与本次割接相关的安全设备的调整考虑（包括防火墙、审计、流量过滤设备、入侵防御设备等）

 设备二层现状的梳理（STP、Trunk）  热备份路由协议的主备关系

 针对负载均衡设备同时还需考虑探针与业务的配合算法调整，如有必要需要提前搭建测试环境对相关业务进行模拟测试。

5.2.3. 人员层面

每次割接的成败关键除了详细的业务调研分析、完善的割接方案外，起到决定因素的还是对割接操作、审核、监控、技术支持、管理人员的监督管理，责任要落实到人。 1. 操作人员：

 严格按照事先项目组审定的割接步骤进行操作。

 禁止割接操作人员跳、漏步骤，不得随意变更未通过审核的配置脚本。 2. 审核人员：

 割接步骤的每一步操作要有审核人员进行确认，并在纸质割接步骤上进行

标注。

 审核人员有权对操作人员的动作进行和纠正。

 对于割接中遇到的问题审核人员必须第一时间上报现场管理人员进行处

置。 3. 监控人员：

 按照事先准备好的测试方案利用设备或软件对网络设备、业务系统进行实

时监控。

 割接期间出现业务或网络异常及时反馈现场业务支撑人员，并报告现场管

理人员。 4. 技术支持人员：

针对网络或业务系统，割接现场需要配备硬件设备原厂技术人员或业务系统软件开发人员进行保障工作，当割接过程中硬件设备或业务系统软件出现异常时技术支持人员能够第一时间提供问题分析及解决方案。 5. 管理人员：

每次割接管理人员通常包含客户方现场负责人、集成侧项目经理，上述人员统一负责对割接现场的指挥、调度、应急故障的处理、回退预案的启动负责。

5.2.4. 割接过程监控

割接过程的监控对割接的顺利进行有着关键作用，割接期间除通过网络层面的检查外，一些业务系统还需业务系统的维护人员、开发商配合来完成业务系统的测试、验证及调整工作。割接过程的监控可分为两个层面： 1. 网络层面：

通过ping、telnet、tracert验证设备的运行状态、业务系统的运行情况、及路由的可达性。 2. 业务层面：

通过web登陆、应用系统客户端程序登陆及检查应用系统日志来检验业务系统的运行状态。

5.2.5. 异常场景处理

在割接前需要充分考虑割接过程中可能会出现的异常情况，并做好相对应的应急预案，异常场景主要包含如下内容： 1. 网络设备：

机框故障、引擎故障、板卡异常、端口UP/DOWN、路由表与预期不一致、访问控制策略异常、二层链路有环路、流量异常、IP地址冲突等。 2. 安全设备：

设备宕机、端口协商不一致、策略无效异常等。

针对上述情况，在接到监控人员的通报后，现场管理人员与技术保障人员进行沟通，确认启动相对应的应急预案，如发现问题短时间得不到解决，处理的时间超过割接窗口期时经项目组一致决定后启动回退方案。

5.3. 割接前准备措施

1. 详细的需求调研

包括明确新增设备用途、上线后承载的业务访问需求、设备安装位置。

新增设备上下联端口分配，对端互联设备的端口占用情况、Vlan使用情况、STP情况、trunk对Vlan的影响评估、动态或静态路由配置情况、访问控制策略梳理。

对割接业务影响范围评估、割接涉及业务配合人联系方式的统计、业务运行的时间段及可接受断网时间段。 2. 方案准备

实施方案包括如下内容：  本次割接要达到的目标

 现状分析：割接前后拓扑、割接涉及设备的端口状态统计、涉及设备端口对应的业务名称，现网设备路由配置梳理、访问控制策略梳理统计、业务影响评估。

 资源需求：新增设备名称、新增板卡分配规划、物理接口分配规划、线缆及光模块使用统计、各互联接口描述、访问控制策略规划、IP地址规划、Vlan规划、Trunk规划、STP规划、热备份路由协议的分配、动态或静态路由分配规划、设备操作系统版本、其它安全基础配置（口令、SNMP、AAA、NTP等）。

 割接思路：对整个割接过程的关键里程碑进行描述、并对断网次数进行数量统计说明。

 割接步骤：对整个割接过程的每一步操作要有配置命令、对应时间点、操作人员及核查人员。

 割接完成后的设备状态检查：割接完成后需要对本次割接涉及的网络设备进行状态检查、比对割接前后配置脚本排除误操作。

 设备割接期间出现的异常场景处理预案  回退预案

 割接现场人员及涉及业务测试配合人联系方式 3. 对上线设备的状态检查

 在设备割接上线前首先将设备上架加电、对设备的引擎、业务板卡、电源模块、风扇、运行温度、线缆连接情况进行确认检查，确保设备在正式割接上线时是以稳定状态工作。

 对割接涉及的互联设备进行配置备份、告警信息分析、对设备CPU、内存、引擎状态、业务板卡情况、电源、风扇、线缆连接情况进行确认统计。 4. 业务测试

割接前对涉及业务进行全量测试，如下表：

涉及的序号 段号 IP 系统名称 ping结果 telnettracertC/S或B/S测试结论 业务端路由结业务登陆口结果 果 结果 5.4. 割接中保障措施

严格按照事先项目组审定的割接步骤进行操作。 禁止割接操作人员不按割接步骤顺序随意变更操作内容。

割接步骤的每一步操作要有审核人员进行确认，并在纸质割接步骤上进行标注。

割接期间对部分关键业务的实时监控，出现业务或网络异常及时反馈现场业务支撑人员，并报告现场各负责人。

对割接过程中出现的异常情况经现场客户、集成双方确认后启动应急预案或回退预案。

5.5. 割接后保障措施

割接完成后，严格按照预先制定的测试方案，逐一进行测试验证，在测试验证后设备才能正式上线提供服务。

设备正式提供上线服务后的3天内为设备观察期，严格对进行状态监控，保证上线设备及所承载业务可用性。

5.6. 割接业务测试步骤

整个割接业务测试分为四部分： 1. 割接前对业务的全量测试。

2. 割接期间对部分关键业务的实时监控。 3. 割接后对业务的再次全量测试。

4. 割接完成后对割接前后全量业务测试结果进行对比确认业务运行正常。