项目实施过程管理方案

《项目实施过程管理方案》由会员分享，可在线阅读，更多相关《项目实施过程管理方案（28页珍藏版）》请在装配图网上搜索。

1、1 项目实施过程管理方案LL1.1 总体计划对本项目卖方将采取与买方紧密合作的方式，充分发挥合作双方各自优势完 成整个项目的实施。根据项目实施的阶段和任务，邀请买方的工作人员参与到项 目管理和技术的每一项工作中来，联合成立相应的组织机构，进行有效的分工。 双方共同负责对项目进行组织、实施和控制，并在项目实施的各里程碑到达时召 开工程协调会，进行工程的总结、组织、协调工作。项目启动后，将由卖方项目计划控制小组定期召集工作会议，讨论各阶段任 务的执行情况，分析存在的问题，提出改进方法，尤其注重讨论那些潜在的风险， 提出相应的风险处理对策，并将会议结果及时通报给买方，由买方进行审核和确 认，以确保项

2、目按期高质量地完成。1.2 项目计划1.2.1 获取约定项目经理参与项目的准备工作，并且负责与售前项目的交接，获得项目的工 作说明书，工作说明书是项目与客户及与公司的约定，项目经理还需要获得 公司对项目的其他要求。这些信息是项目经理在项目启动阶段需要获取的基本信 息，并作为编写项目计划的输入。1.2.2 编制项目计划确定项目概要：关于项目的编号、名称信息，本项目的工作说明书（SOW）, 项目建设目标、最终的可交付物，项目计划文档中使用的专业术语解释，制订项 目计划过程中使用的参考资料。项目组织结构：项目组织结构描述了项目的人员与组织结构和项目人力资源 分配的信息。项目估算：软件产品规模估算、成

3、本估算、工作量估算、工作进度估算、关 键资源的估算。制定风险管理计划：描述项目风险承受度的分析和项目组为有效管理风险所 要采取的活动。确定项目里程碑和 WBS：WBS 是项目计划中重要的工作内容，通过对软件开 发工作进行分解，并结合估算的进度要求，编写项目 WBS 工作表，表征每项 工作任务完成的标志性事件即所谓“里程碑”。资源计划：分析项目的硬件设备需求、软件设备需求，以及工作环境、计划 环境要求，并指定相应的责任人。交流沟通计划和培训计划。评审项目计划：项目经理将项目计划发给技术协调小组、买方相关人员，并 组织买方确认工作，买方确认工作采用管理评审的方式的进行，评审的内容主要 针对人员组织

4、、关键依赖、估算中的进度、里程碑、提交物和详细的WBS表、风 险管理表等内容。根据评审结果对项目计划进行修订，修订后的项目计划要得到 买方项目负责人的确认。发布计划：项目经理将通过评审后的项目计划申请基线化，并通过邮件或会 议的方式通知所有项目涉及人员。1.2.3 项目跟踪任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安 排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方 法或工具、及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪 等。买方反馈：确定项目中对买方反馈、建议、甚至抱怨的应对责任人（比

5、如项 目经理或设立专职的客户经理）和纪录跟踪的方式。状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对 象、频度、报告文件名称。如：买方、卖方的资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动：每周例会，必要时邀请买方参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作 报告和其他。总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前 的工作绩效（产品的完成情况）、进度情况、缺陷总结、需求稳定度分析和变更 发生情况。总结项目组存在的问题和分析项目进展的风险 对重要问题的日常跟踪回顾 在必要时出项目偏差控制报告。项目偏差控制报告是对估算出

6、现偏差 的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。 在必要时出项目工作月报。 日常监督和跟踪工作、风险管理工作 对项目周报中的项目问题进行跟踪 对项目周报中的项目风险问题进行跟踪 对项目周报中其他事项进行跟踪1.3 软件开发软件开发通常需要经过分析、设计、实现和运行维护等几个阶段；为了用工 程化方式来有效的管理软件项目的全过程，软件项目生命周期也可以分成几个阶 段。对软件项目生命周期的不同划分，形成不同的软件项目工程模型。目前在本 软件开发实践中使用的标准软件项目生命周期，都是以下几个阶段的不同排列组 合。项目启动需求分析项目设计核心开发定制开发产品发布产品交付初验

7、终验维护以下分别介绍我们本软件开发中三类典型项目的组织标准软件项目生命周 期。1.3.1 组织标准软件项目生命周期研发项目首先，在这里对软件项目生命周期中通用的公共活动进行必要描述：序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周 报、不符合报告3软件配置管理配置审计报告、配置状态 报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1实施项目可行性研究项目可行性报告2召开项目启动会议3制定项目计划项目计划书、项目软 件配置管理计划书、项目 软件质量保证计划书4同行评审活动评审报告、缺陷管理表

8、需求分析序号关键活动工作产物/输出1编写需求规格书、需求跟踪矩阵需求规格书、需求跟踪矩阵2细化项目计划项目计划书、项目软 件配置管理计划书、项目 软件质量保证计划书3制定项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理 表项目设计序号关键活动工作产物/输出1概要设计概要设计规格书2详细设计详细设计书3细化项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理 表核心开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4进行系统测试系统测试报告5文档编写用户手册、操作手册6同行评审活动评审报告、缺陷管理 表产品发布序号关键

9、活动工作产物/输出1发布版本版本发布报告2项目总结项目总结报告1.3.2 组织标准软件项目生命周期工程项目首先，在这里对软件项目生命周期中通用的公共活动进行必要描述序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周 报、不符合报告3软件配置管理配置审计报告、配置状态 报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1召开项目启动会议2制定项目计划项目计划书、项目软 件配置管理计划书、项目 软件质量保证计划书3同行评审活动评审报告、缺陷管理 表需求分析序号关键活动工作产物/输出1编写需求规格书

10、、需求跟踪矩阵需求规格书、需求跟踪矩阵2细化项目计划项目计划书、项目软件 配置管理计划书、项目软 件质量保证计划书3制定项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理表项目设计序号关键活动工作产物/输出1概要设计概要设计规格书2详细设计详细设计书3细化项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理表核心开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4进行系统测试系统测试报告5文档编写用户手册、操作手册6同行评审活动评审报告、缺陷管理表定制开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测

11、试报告3持续集成测试测试状况报告4编制用户测试计划用户测试计划5进行系统测试系统测试报告6进行用户测试用户测试报告7文档编写用户手册、操作手册8同行评审活动评审报告、缺陷管理 表产品发布/软件交付阶段序号关键活动工作产物/输出1发布版本版本发布报告2编制上线方案上线方案3系统上线上线总结报告软件维护阶段序号关键活动工作产物/输出1确认维护需求（包括BUG）需求变更申请单/Bug 单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理 表初验序号关键活动工作产物/输出1编制试运行报告试运行报告2用户验收测试用户验收报告3

12、初验初验报告终验序号关键活动工作产物/输出1编制技术总结报告技术总结报告2编制项目总结报告项目总结报告3用户验收测试用户测试报告4终验终验报告1.3.3 组织标准软件项目生命周期维护项目首先，在这里对软件项目生命周期中通用的公共活动进行必要描述：序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周 报、不符合报告3软件配置管理配置审计报告、配置状态 报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1召开维护交接会议2制定维护项目计划维护项目计划3同行评审活动评审报告、缺陷管理 表项目实施序号关

13、键活动工作产物/输出1确认维护需求（包括BUG）需求变更申请单/Bug 单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理 表项目结束序号关键活动工作产物/输出1提交维护总结报告维护总结报告1.4 项目执行与控制任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安 排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方 法或工具、及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪 等。买方反馈：确定项目中对买方反馈、建议、甚至抱

14、怨的应对责任人（比如项 目经理或设立专职的客户经理）和纪录跟踪的方式。状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对 象、频度、报告文件名称。如：向买方、资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动： 每周例会，必要时邀请客户参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作 报告和其他。总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前 的工作绩效（产品的完成情况）、进度情况、缺陷总结、需求稳定度分析和变更 发生情况。总结项目组存在的问题和分析项目进展的风险 对重要问题的日常跟踪回顾在必要时出项目偏差控制报告。项目偏差控制

15、报告是对估算出现偏差 的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。 在必要时出项目工作月报。日常监督和跟踪工作、风险管理工作 对项目周报中的项目问题进行跟踪 对项目周报中的项目风险问题进行跟踪 对项目周报中其他事项进行跟踪 修改项目计划（包括子计划）：当项目计划出现偏差时，需要对项目计划进 行及时的调整。引起项目计划变更存在多种可能的因数，如原来的进度估计不准 确、发生了没有估计到的问题、项目执行过程中的各种变更等等。项目计划应该定期的被检查，发现可能影响项目计划的变更因数，对这些因 素进行分析，并在项目例会中确定是否要对项目计划进行调整。修改项目计划之前，必须首先编

16、写项目偏差控制报告，该报告是修改项 目计划的直接依据。在项目计划的修改前、修改后，需要通过项目计划变更控制报告，要求 公司的管理层和买方的管理层签字确认。在修改后的项目计划中，必须体现所有受项目计划变更的影响，并做对应的 修改。项目计划修改后在必要时必须通过评审。项目计划变更后，需要通知与项目组相关的人员或组织。 项目计划变更的工作流程示意图如下。通过项目计划的变更流程，实施对项目计划文档的控制和管理。1.5 项目验收与结束1.5.1 系统投入使用验收验收过程系统投入使用验收申请系统投入使用验收计划系统设备验收 文档审查、环境检查 制定投入使用测试大纲和测试方案 投入使用测试 制定系统割接计划

17、和割接方案 系统上线或割接验收标准 系统基本功能已经开发完成，能够满足业务的基本要求，系统功能的进 一步开发对已开发完成功能的使用不会造成影响时。验收成果 上线报告1.5.2 系统初验验收过程 系统稳定验证 系统初验评审 系统初验表决 系统移交验收标准 系统开发建设完成，满足业务要求后进行的验收。初验完成后，允许系 统存在少量遗留问题。时限要求 上线后 3 个月内。验收成果 初验报告1.5.3 系统终验验收过程 系统终验评审系统终验表决系统最终移交验收标准 统完全符合合同要求，经过试运行，系统调整优化到满足目前各业务要 求，且基本满足系统性能要求后进行的验收。时限要求 初验后 3 个月内。验收

18、成果 终验报告1.5.4 项目结束按照合同约定免费维护期结束后项目结束。1.6 项目文档资料技术建议方案需求规格书概要设计规格书详细设计规格书系统测试计划集成测试报告系统测试报告用户测试报告上线申请报告试运行报告用户维护手册用户使用手册数据字典技术总结报告系统初验报告系统终验报告1.7 软件配置管理软件配置管理是项目运作的一个支撑平台，它将项目所有成员（包括公司中 对项目负责的高层经理）的工作协同起来，实现高效的团队沟通，使工作成果及 时共享。当然，这种支撑是贯穿项目的整个生命周期的。1.7.1 配置管理计划在实现软件配置管理计划的过程中，主要实现以下三个里程碑：A 建立软件配置管理小组：在项

19、目总体组批准软件配置管理计划之后，立 即成立软件配置管理小组；B 建立各阶段的配置基线：随着系统及其所属各子系统的任务书的评审和 批准，建立起功能基线；随着总体组编写的软件需求规格说明书的批准，建 立起指派基线；随着工程化软件系统的集成与系统测试的完成，建立起产品基线。C 建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起 各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系 统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新 的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的 计算机上建立软件受控库的副本。软件受控库必须以

20、主软件受控库为准。当全部 开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的 计算机上建立软件产品库的副本。1.7.2 基线库管理基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标 准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个 初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基 线。1.7.2.1配置项基线化前淖笈人城提戰测试版本核心思想：开发人员在每天下班之前将当天工作成果提交到开发库开发区。 原则：允许多人对一个文件进行CHECK OUT操作。每天开始开发工作之前，所有开发人员访问开发库开发区将要修改的文件进

21、 行CHECK OUT操作。每天下班之前，所有开发人员将当天修改的文件进行CHECK IN操作，以及 将当天新增的文件加入开发库开发区中。每天下班之前，配置管理员检查所有开发人员是否已经按要求完成第2步操 作。配置管理员将开发库开发区锁住，将当前版本提取至测试区。配置管理员解锁并通知项目组开发人员。1.7.2.2配置项基线化配置项符合以下任一项要求，才可将其纳入基线库：通过GRB评审或通过CCB审核或通过配置经理批准项目经理/技术经理填写“配置项纳入基线请求单”，配置经理审批，配置管理员建立基线。1.7.2.3配置项基线化后提交壹更養更单H吏更单测试记录核心思想：配置项基线化后纳入基线库，由配

22、置管理员完全控制。原则：不允许多人对一个文件进行CHECK OUT操作，由配置管理员对此做严 格控制。项目组所有人员需对基线库中的配置项进行变更，必须先填写变更单，该申 请必须通过CCB审核。配置管理员根据变更单，将基线库需变更的配置项进行CHECK OUT操作或向 变更修改人开放权限。当变更修改人完成变更后，将变更单提交给配置管理员，配置管理员或变更 修改人更新基线库。项目经理/技术经理填写“配置项纳入基线请求单”，配置经理审批，配 置管理员建立基线。1.7.3配置管理实施流程1.7.3.1 识别配置项配置项基线化的要求配置经理确定项目配置项标识规定，配置项以及基线计划，GRB对其进行评 审

23、。配置经理在配置管理计划中明确系统版本升级策略。配置项包括： 文档类配置项软件类配置项配置项标识规定技术文档表示规定：客户名称 - 项目名称 - 文档类型名称质量记录标识规定：客户名称-项目名称-文档类型名称-序号 代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。 项目管理文档标识规定：会议纪要：客户名称-项目名称-文档类型名称-开会日期 项目周报：客户名称-项目名称-文档类型名称-提交日期 技术讨论记录：客户名称-项目名称-文档类型名称-讨论日期软件发布标识内部版本标识：内部版本号：X.Y.Z外部版本标识：版本号二VXX.XX 港华燃气，分别为:主版本号+次版本号+补

24、丁号1.7.3.2 版本控制配置库开发库，基线库，发布库，这三库的目录结构都是相同的。项目经理，技术经理，测试经理裁减标准目录结构，共同确定项目目录结构， 填写“项目配置管理库建库申请单”，提交至配置经理，将其纳入配置管理计划 配置管理员负责创建。开发库开发区用途开发阶段：为项目组所有成员提供私有的工作区域。数据来源项目组成员提交权限项目组所有人员：可读/可写测试区用途开发阶段:存放待测试的代码版本数据来源开发区权限配置管理员，测试人员：可读/可写 其他人员：可读基线库用途存放项目过程中配置项的所有基线版本。数据来源开发库权限配置管理员：可读/可写 其他人员：可读变更控制项目组所有人员需变更该

25、库中的配置项，需按照变更控制流程严 格执行。发布库用途存放待发布，已发布的系统版本。数据来源基线库权限配置管理员：可读/可写其他人员：可读发布管理1.7.3.3 变更控制变更申请当需要对基线或基线中的配置项修改时,变更申请人提交变更申请至 CCB 变更申请工作内容包括：1、描述变更的需求或来源，说明变更的必要性；2、分析需要变更的内容；3、说明变更来源：需求变更:新增需求、需求变化、需求分析缺陷；设计变更:设计缺陷；上线系统代码变更：编码缺陷。变更评估变更申请提出以后，CCB评估该变更申请，变更决定的结果要求通知所有 相关的人员。评估人员要求具备相关的业务、技术、项目、质量素质，以达到评估的效

26、果。 如果是变更涉及到客户的变更，或者是上线后的变更，CCB需要吸收客户负 责人员参与。评估内容包括： 变更申请内容。包括方案、性质、起因、对其他部分的影响； 根据变更对系统其他部分的影响，分析变更的工作范围，进行工作的分解。（参见项目管理WBS）根据不同的变更，可能发生的工作范围包括： 需求变更实施；设计变更实施；代码变更实施； 项目计划变更实施，主要指进度相关； 项目预算变更实施；其他相关的变更实施； 以上各变更工作根据分析的结果决定先后关系。变更对进度、成本的影响和带来的风险。根据变更的WBS估算增加的工作量, 从而得到变更对进度和成本的影响。其中成本以人工时为单位进行计算。评估结果有三

27、种情况：拒绝变更: 需要通知相关人员拒绝的原因。变更活动结束，或由申请人重新提出申请。提交管理评审: 如果变更带来的进度和成本的变化超出项目经理所能控制的范围，由项目经 理申请高层管理评审，请高层决定是否执行变更。如果否决则过程活动结束。提 交管理评审的后续结果包含拒绝变更、接受变更两种。决定进行变更:如果决定接收变更则由项目经理根据关键路径图实施变更计划，并由CCB根据变更的类型、内容决定如何进行变更的验证，包括验证的人员和方式。1.7.3.4 变更实施变更实施指实际发生的对配置项的修改行为。变更实施是变更评估后的步骤修改产生的影响已经在变更的评估中考虑。1.7.3.5 变更验证变更实施工作

28、完成以后，提交指定的人员按指定的方式进行验证。需求和设计方面的变更内容采用文档评审的方式，代码方面变更内容进入测 试流程。变更内容得到验证以后，执行配置管理流程，对应成果确定新的基线。1.8 质量保证产品的价值取决于产品的质量，软件质量的特性是多方面的。必须包括：与明确确定的功能和性能需求的一致性。即软件需求是质量度量的基础，缺 少与需求的一致性就无质量可言。与明确成文的开发标准的一致性。不遵循专门的开发标准，将导致软件质量 低劣。与所有专业开发的软件所期望的隐含的特性的一致性。忽视软件隐含的需求 软件质量将不可信。1.8.1 参与制订和评审项目的软件项目计划、标准和规程为项目软件过程的确定和

29、裁剪提供建议；为软件生存周期各阶段工作指出并协助制定所依据的标准和规程； 审查项目所选用的有关标准、规程与项目外部强制标准和规程的一致性； 评审软件项目计划及选用的标准和规程；提供开发流程的咨询；验证计划、标准和规程是否可得到，且可用于评审和审核活动。1.8.2制订项目SQA计划在软件项目计划制定的同时提出项目SQA计划初稿，SQA计划不应与软件项 目计划的内容冲突。项目 SQA 计划制订并经 QA 经理的同意后，提交项目经理、软件工程组和配 置管理人员进行评审。经过评审的项目 SQA 计划再经配置控制委员会的批准后，配置管理人员将 SQA 计划纳入配置管理。1 . 8. 3评审工作产品软件质

30、量保证人员需要评审的工作产品包括但不限于：软件项目计划，软件 配置管理计划，测试计划等。需要进行评审的具体工作产品详见 SQA 计划评审工 作产品的目的是确保软件产品符合软件开发标准和规程的要求。在工作产品评审结束后的一个工作日内，软件质量保证人员应报告软件工作 产品评审的结果。如果发现了不合格项，软件质量保证人员应向项目经理报告， 并按审核后续活动的方法跟踪不合格项的处理，并验证不合格项的纠正结果直至 关闭。1 . 8. 4过程审核依据项目SQA计划，软件质量保证人员在项目进行的各个阶段对软件研发过 程和工作产品进行审核。当过程审核需要项目组提供支持和配合时，审核前应提前通知项目经理，通 知

31、可以用邮件或书面方式。项目经理在得到通知后应准备有关资料，与软件质量 保证人员沟通以确定审核时间。实施审核前软件质量保证人员应根据标准检查单剪裁出审核检查单，剪裁后 的检查单需经QA经理批准。审核报告：在现场审核结束的一个工作日内，软件质量保证人员应向项目经 理和项目组提交审核报告。过程审核后续活动：软件质量保证人员对审核发现的问题，应在现场审核结 束的一个工作日内报告给项目经理和项目组。软件质量保证人员在规定的日期后 进行验证，验证合格则关闭不合格项；如验证不合格或未采取措施，软件质量保 证人员应通过 QA 经理及时向项目总监报告；报告后，软件质量保证人员必须跟 踪该项不合格的处理，必要时进

32、行再验证。所有SQA审核报告、不符合报告等SQA的过程记录，都需要纳入配置管理进 行管理和控制。185SQA报告机制软件质量保证人员应向项目经理和项目组提交审核报告和工作产品评审报 告（可和检查单合在一起）。对于在项目组层面未能关闭的不符合报告，应由项 目总监裁决，软件质量保证人员跟踪后续活动。SQA 活动的定期报告周报：软件质量保证人员为每一个项目准备一份SQA活动周报，其内容为软 件质量保证人员一周内对某项目所开展的 SQA 活动和项目 SQA 计划状态等情况 的总结。汇报对象是项目经理和QA经理。月报：SQA月报是QA经理每月对SQA活动的执行情况、项目SQA计划的进 展情况和项目总监裁

33、决不合格项等情况的总结。QA经理每月向项目总监汇报， 并抄送SEPG组组长。1 9风险管理191 风险管理约定“风险管理”的目的是识别潜在的问题，以便策划处理风险的活动和在必要 时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。风险管理是一个连续的前瞻性的过程，它是业务和技术管理过程的重要组成 部分。风险管理需要处理可能危及关键目标的问题。应用持续风险管理的方法来 确保有效地抵御和缓解项目生存周期中具有关键影响的风险。有效的风险管理包括，按照项目策划过程中所拟订的共利益者介入计划，与 共利益者合作，早期识别风险。为了建立起能够自由而开放地揭示和讨论风险的 环境，有必要在所有受影响的

34、各方之间形成强有力的领导关系。1.10 项目总体进度安排在此项目中，根据我们对工程的理解，明确要求“2015 年 3 月 15 日在项目 中标之后开始项目的启动计划。”。为此，本公司根据实际情况，制定了详细的工程计划，由于项目涉及系统众 多，参与部门众多，因此必须严格按照计划的关键时间点完成相应任务，才能顺 利完成系统上线工作，其关键历程碑如下：项目启动：2015.3.15日召开项目启动会，启动会前做好总体项目计划及 人员组织计划等项目准备工作。 需求确认：2015.4.15 日前完成基础业务功能、关键业务/跨系统解决方 案及内外集成接口需求的调研及评审确认工作，这个是所有后续工作的基 础，因

35、此此里程碑式重中之重；同时需求控制也是关键环节，需求不断变 化，将直接导致应用无法风版，从而工程延期。 设计评审：2015.4.25日完成设计及评审工作。版本发布：2015.5.15 日发布RV1，5月21日发布RV2。其中：RV1版本 为准上线颁布，其开发内容主要是根据前期基础业务功能要求、关键业务 /跨系统方案以及内外部接口须求做的适应性开发。RV2是在RV1基础上 进行全部 bug 修正后产生的版本。 测试： 2015. 6. 25日完成自建系统所有测试，包括： 接口联调测试、集成 测试、全业务端到端测试、性能/压力测试、UAT测试等。 港华燃气系统试点上线： 6 月 31 日，港华燃气

36、系统准备就绪（业务、方 案等），完成上线 吴江港华系统试点上线： 7 月 31 日，吴江港华系统准备就绪（业务、方 案等），完成上线 徐州港华系统试点上线： 8 月 31 日，徐州港华系统准备就绪（业务、方 案等），完成上线1.11 本项目存在的风险分析和控制方法风险序列风险级别风险名称控制措施1高VCC和TCIS系统的接 口能力可能不具备条件1、需要TCIS系统厂商积极配合。2、需要项目经理加大协调力度。2高需求迟迟不能确定或需求经常变更1、明确需求责任人和需求提出、变更流 程，规定需求提出的截止时间和封版时 间。2、对于不重要需求，放到上线后再进行实 施。3高项目复杂度咼，涉及系统和部门众多；1、尽可能的合理安排项目计划和工作，避 免工作冲突或有安排不合理导致的工作等 待。2、多增加工作检查环节，预先发现工作漏 洞。3、尽量简化工作流程，提咼工作效率。4中时间短，测试不充分。1、加大测试力度。2、充分发动业务人员，尽早介入测试。3、对业务功能进行梳理，分出优先级，本 着急用先行的原则。5中外围厂家不能按时交付结果以及涉及外围系统改造导致该风险存在1、需要外围厂商积极配合。2、需要项目经理加大协调力度。