（4）需求的变更尽量控制在早期阶段，需求阶段和概要设计阶段能够直接进行大量反复的需求变更，详细设计阶段能够直接进行部分需求变更，在编码阶段一般不能允许需求变更，需要实施严格控制。

  （5）定量目标：需求阶段，需求变更率能控制在20%左右，设计阶段控制在5%左右，编码及测试阶段控制在0%，即不可以进行变更。如果一定要变更则根据变更流程可以改签或续签协议合同。

  （1）项目的需求变更分两级控制：项目经理、CCB，项目经理可以直接决定影响轻微的需求变更。如果需求变更将引起资源、进度或软件质量的变化，则需要CCB共同协商确定、并由双方高级经理确认批准，否则不予变更。

  （2）从变更申请到变更分析、确认、批准、处理直至完成，遵循公司NSP的变更处理规程，流程图如下图所示。

  （3）首先对于发现的任何有关需求的问题，都必须形成文档化的变更申请，提交项目经理

  （4）项目经理初步确认，如果风险很小，则可以直接决定是不是变更，否则提交CCB。

  （5）CCB评审讨论，进行影响分析，确定是不是引起资源与约定的变更，假如没有影响，则协调项目组内部和相关组资源，进行变更。否则提交双方高级经理。

  （6）双方高级经理协商考虑资源与约定的影响，决定是不是批准变更。对于允许的变更需要签定增补合同，协调外部资源，并更新计划和约定。

  （1）沟通的顺畅和有效是保证项目进度按计划实施的关键，因此做好项目的沟通管理非常重要。

  （3）项目沟通管理最重要的包含：项目计划、沟通媒介、定期会议、报告、进度表、假设、依赖、风险和成本，以及其它。

  为了使项目信息更好地共享，我们将根据局方情况设定项目文档电子化管理，使项目成员和有关人员能够依权限从中获得项目管理、项目成果、项目问题、变更、项目消息、联络信息、外来参考资料等信息和文档，同时在其权限范围内发布项目信息和输入项目文档、工作规划等。

  （14）.项目管理文档（项目管理标准、程序、状态报告、阶段总结、问题、变更等）

  对项目文档机密的管理，要求此类文档必须记录机密级别，项目经理对查阅人员进行授权。对保密要求，见开发商与用户签署的保密协议。

  在项目组中设置项目行政管理人员，其职责之一是管理项目文档。各方把其交付的文档同意交付到项目行政管理人员，由其传至各个审核人员，得到批准或审核完毕，由项目行政管理人员发布到网络上，并根据浏览权限进行设置，注明机密级别、版本等。

  对于绝密文件，不进行浏览授权，查阅文件需要得到用户方项目经理的特别批准。

  如果项目文档存在更新版本，发布最新版本，并注明其有效性，同时说明以前版本作废。

  为了确保该系统的质量，我们将采用科学的方法和业界最先进的测试技术与工具，对该系统来进行严格、规范的系统测试。在系统正式交付用户使用前，我们将组织专业测试团队，分别对该系统的应用功能、应用性能进行测试。

  本节描述了各项测试的目标、测试环境和我们将采用的测试工具、测试方法、测试指标体系、测试实施计划、测试报告形式和测试结果确认方式，系统测试实施前，我们将根据系统实施的真实的情况和客户的真实需求，确定最后的测试内容和制定更详细的测试实施方案，在经用户方审核同意后，实施具体的测试。

  以招标文件、总体设计为基础，根据真实的情况，从系统性能、系统功能两个方面，对应用软件制定相应的验收标准草案，经过评审通过后，形成正式的验收标准。

  对系统的验收包括工程组内部验收、用户初步验收（初验）和用户最终验收（终验）三个阶段。工程组对应用软件的内部验收应按照相关规定，组织我公司技术委员会、行业咨询专家等对应用软件进行内部评审和验收。内部验收完成后，应用软件的初验和终验应履行正式手续，双方成立专门的验收委员会，负责组织、监督和裁决整个应用软件的验收过程。

  内部风险管理计划是为了确定项目风险，定义出规避或缩小这些风险所采取的行动。为此，必须定义出所有已知的和潜在的项目风险，充分评估这些风险发生的可能性，并且指定出规避和管理这些风险的行动。

  针对本项目，项目组经过对项目的技术，进度，预算等多方面内容的分析，初步定义以下的项目风险管理表：

  加强项目后勤管理；人力资源管理；最大限度地考虑后备人力资源；关键工作安排两人以上执行。