（2015年2月6日项目报竣总结）

一、 项目组织架构

根据我们以往在项目管理和实施方面的经验，建议项目的组织机构如下设置：

 图4-1项目组结构示意图

二、 项目过程管理

2.1  项目进度控制办法

本项目中我们将采用下列进度控制办法：

（1）. 合理划分项目任务

（2）. 根据技术人员情况进行合理分工

（3）. 采用并行开发和施工，本地化开发与工程实施并行进行。

（4）. 关注关键任务的进展

（5）. 每周进展分析报告

（6）. 里程碑进展状态评审

（7）. 加强原型技术预研

（8）. 计划提前评审和测试，尽早发现问题

（9）. 风险识别、跟踪与规避。

三、 需求变更管理

3 

3.1 需求变更控制原则

（1）及时、反复、全面地评审需求，及早发现需求问题。

（2）测试尽可能早的参与项目需求工程。

（3）对于不能明确的需求可以进行原型探索。

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

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

3.2  需求变更管理流程

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

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

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

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

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

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

（7）项目组和相关组处理并跟踪需求变更。

图4-2  需求变更申请流程示意图

3.3 项目沟通管理

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

（2）在项目实施过程中建立项目沟通管理的目的是：

（10）. 识别项目实施过程中需要的信息；

（11）. 定义信息收集需要的资源；

（12）. 把信息流向、时间跨度、接收信息者和发生的频率进行文档化；

（13）. 选择信息有效流动的技术方法和载体。

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

3.4 项目文档管理

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

为了有序的管理项目电子文档，这里规定项目文档按照以下方式进行管理。

（1）项目文档分类

我们把项目文档划分为以下类别：

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

（15）. 质量报告

（16）. 需求报告

（17）. 测试文档（测试计划、案例、测试结果、测试接受等）

（18）. 培训文档

（19）. 开发文件（含源代码）

（20）. 系统设计与分析

（21）. 接口文档

（22）. 系统管理

（23）. 合同等

（24）. 会议安排和记录

（2）项目阶段

为了把项目文档与项目发生的时间或阶段联系起来，需要明确项目的阶段如下：

（25）. 项目准备

（26）. 需求分析

（27）. 系统设计

（28）. 应用开发

（29）. 测试

（30）. 部署与运行

（3）项目文档机密级别

定义项目文档机密级别如下：

保密、机密、绝密和公开

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

（4）项目文档电子化管理处理说明

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

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

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

不允许任何个人私自发布项目文档。

3.5 系统测试和验收方案

3.5.1系统测试方案

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

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

3.5.2项目验收方案

（1）验收标准

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

（2）验收环境准备

验收环境准备包括：

（31）. 验收数据的准备

（32）. 验收运行环境准备

（33）. 验收用例准备

（3）验收内容

系统完成测试运行后，我公司将拟制初验计划和验收内容，供用户确认。

1) 应用软件。

2) 应用软件源程序。

3) 相关文档。

应用软件验收项目包括

（34）. 系统功能度；

（35）. 界面友好性；

（36）. 系统可靠性和安全性；

（37）. 容错性；

（38）. 可伸缩性。

应用系统文档验收包括：

（39）. 应用软件需求分析说明书；

（40）. 应用软件概要设计说明书；

（41）. 应用软件详细设计说明书；

（42）. 应用软件功能说明书；

（43）. 应用软件用户手册；

（44）. 应用软件安装手册；

（45）. 系统管理手册；

（46）. 系统安装手册；

（47）. 系统维护手册；

（48）. 应用系统源程序。

（4）验收程序

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

依据甲方单位授予合同的相关条款要求，组织项目的用户最终验收。

四、 项目风险分析

1、对于项目风险管理的定义：

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

2、风险管理计划：

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

表4-1 风险管理计划