项目实施过程管理方案

1项目实施过程管理方案11=LL1.1总体计划对本项目卖方将采取与买方紧密合作的方式，充分发挥合作双方各自优势完成整个项目的实施。根据项目实施的阶段和任务，邀请买方的工作人员参与到项目管理和技术的每一项工作中来，联合成立相应的组织机构，进行有效的分工。双方共同负责对项目进行组织、实施和控制，并在项目实施的各里程碑到达时召开工程协调会，进行工程的总结、组织、协调工作。项目启动后，将由卖方项目计划控制小组定期召集工作会议，讨论各阶段任务的执行情况，分析存在的问题，提出改进方法，尤其注重讨论那些潜在的风险，提出相应的风险处理对策，并将会议结果及时通报给买方，由买方进行审核和确认，以确保项目按期高质量地完成。1.2项目计划1.2.1获取约定项目经理参与项目的准备工作，并且负责与售前项目的交接，获得项目的《工作说明书》，《工作说明书》是项目与客户及与公司的约定，项目经理还需要获得公司对项目的其他要求。这些信息是项目经理在项目启动阶段需要获取的基本信息，并作为编写项目计划的输入。1.2.2编制项目计划确定项目概要：关于项目的编号、名称信息，本项目的工作说明书（SOW），项目建设目标、最终的可交付物，项目计划文档中使用的专业术语解释，制订项目计划过程中使用的参考资料。项目组织结构：项目组织结构描述了项目的人员与组织结构和项目人力资源分配的信息。项目估算：软件产品规模估算、成本估算、工作量估算、工作进度估算、关键资源的估算。制定风险管理计划：描述项目风险承受度的分析和项目组为有效管理风险所要采取的活动。确定项目里程碑和WBS：WBS是项目计划中重要的工作内容，通过对软件开发工作进行分解，并结合估算的进度要求，编写《项目WBS工作表》，表征每项工作任务完成的标志性事件即所谓“里程碑”。资源计划：分析项目的硬件设备需求、软件设备需求，以及工作环境、计划环境要求，并指定相应的责任人。交流沟通计划和培训计划。评审项目计划：项目经理将项目计划发给技术协调小组、买方相关人员，并组织买方确认工作，买方确认工作采用管理评审的方式的进行，评审的内容主要针对人员组织、关键依赖、估算中的进度、里程碑、提交物和详细的WBS表、风险管理表等内容。根据评审结果对项目计划进行修订，修订后的项目计划要得到买方项目负责人的确认。发布计划：项目经理将通过评审后的项目计划申请基线化，并通过邮件或会议的方式通知所有项目涉及人员。1.2.3项目跟踪任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具、及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。买方反馈：确定项目中对买方反馈、建议、甚至抱怨的应对责任人（比如项目经理或设立专职的客户经理）和纪录跟踪的方式。状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对象、频度、报告文件名称。如：买方、卖方的资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动：每周例会，必要时邀请买方参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作报告和其他。总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前的工作绩效（产品的完成情况）、进度情况、缺陷总结、需求稳定度分析和变更发生情况。总结项目组存在的问题和分析项目进展的风险对重要问题的日常跟踪回顾在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。在必要时出项目工作月报。日常监督和跟踪工作、风险管理工作对项目周报中的项目问题进行跟踪对项目周报中的项目风险问题进行跟踪对项目周报中其他事项进行跟踪1.3软件开发软件开发通常需要经过分析、设计、实现和运行维护等几个阶段；为了用工程化方式来有效的管理软件项目的全过程，软件项目生命周期也可以分成几个阶段。对软件项目生命周期的不同划分，形成不同的软件项目工程模型。目前在本软件开发实践中使用的标准软件项目生命周期，都是以下几个阶段的不同排列组合。项目启动需求分析项目设计核心开发定制开发产品发布产品交付初验终验维护以下分别介绍我们本软件开发中三类典型项目的组织标准软件项目生命周期。1.3.1组织标准软件项目生命周期——研发项目首先，在这里对软件项目生命周期中通用的公共活动进行必要描述:序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周报、不符合报告3软件配置管理配置审计报告、配置状态报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1实施项目可行性研究项目可行性报告2召开项目启动会议3制定项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书4同行评审活动评审报告、缺陷管理

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

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

2制定项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书3同行评审活动评审报告、缺陷管理表需求分析序号关键活动工作产物/输出1编写需求规格书、需求跟踪矩阵需求规格书、需求跟踪矩阵2细化项目计划项目计划书、项目软件配置管理计划书、项目软件质量保证计划书3制定项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理表项目设计序号关键活动工作产物/输出1概要设计概要设计规格书2详细设计详细设计书3细化项目测试计划（包括方案）测试计划4同行评审活动评审报告、缺陷管理表核心开发阶段序号关键活动工作产物/输出1编写代码代码

2进行单元测试单元测试报告3持续集成测试测试状况报告4进行系统测试系统测试报告5文档编写用户手册、操作手册6同行评审活动评审报告、缺陷管理表定制开发阶段序号关键活动工作产物/输出1编写代码代码2进行单元测试单元测试报告3持续集成测试测试状况报告4编制用户测试计划用户测试计划5进行系统测试系统测试报告6进行用户测试用户测试报告7文档编写用户手册、操作手册8同行评审活动评审报告、缺陷管理表产品发布/软件交付阶段序号关键活动工作产物/输出1发布版本版本发布报告2编制上线方案上线方案3系统上线上线总结报告软件维护阶段序号关键活动工作产物/输出

1确认维护需求（包括BUG）需求变更申请单/Bug单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理表初验序号关键活动工作产物/输出1编制试运行报告试运行报告2用户验收测试用户验收报告3初验初验报告终验序号关键活动工作产物/输出1编制技术总结报告技术总结报告2编制项目总结报告项目总结报告3用户验收测试用户测试报告4终验终验报告1.3.3组织标准软件项目生命周期——维护项目首先，在这里对软件项目生命周期中通用的公共活动进行必要描述:

序号关键活动工作产物/输出1项目跟踪与监督项目周报、项目例会纪要、问题跟踪管理表、风险管理计划2软件质量保证QA审核报告、QA工作周报、不符合报告3软件配置管理配置审计报告、配置状态报告4阶段退出会议纪要、阶段总结报告项目启动序号关键活动工作产物/输出1召开维护交接会议2制定维护项目计划维护项目计划3同行评审活动评审报告、缺陷管理表项目实施序号关键活动工作产物/输出1确认维护需求（包括BUG）需求变更申请单/Bug单2维护设计、开发设计书3内部测试修改测试单4用户测试用户测试报告5维护需求上线上线申请与批准报告6同行评审活动评审报告、缺陷管理表项目结束序号关键活动工作产物/输出1提交维护总结报告维护总结报告1.4项目执行与控制任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出产物。事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具、及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。买方反馈：确定项目中对买方反馈、建议、甚至抱怨的应对责任人（比如项目经理或设立专职的客户经理）和纪录跟踪的方式。状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对象、频度、报告文件名称。如：向买方、资深管理层的相应报告。项目跟踪和监督需要有下列具体的子活动：每周例会，必要时邀请客户参加提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作报告和其他。总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前的工作绩效（产品的完成情况）、进度情况、缺陷总结、需求稳定度分析和变更发生情况。总结项目组存在的问题和分析项目进展的风险对重要问题的日常跟踪回顾在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。出会议纪要和项目工作周报。在必要时出项目工作月报。日常监督和跟踪工作、风险管理工作对项目周报中的项目问题进行跟踪对项目周报中的项目风险问题进行跟踪对项目周报中其他事项进行跟踪修改项目计划（包括子计划）：当项目计划出现偏差时，需要对项目计划进行及时的调整。引起项目计划变更存在多种可能的因数，如原来的进度估计不准确、发生了没有估计到的问题、项目执行过程中的各种变更等等。项目计划应该定期的被检查，发现可能影响项目计划的变更因数，对这些因素进行分析，并在项目例会中确定是否要对项目计划进行调整。修改项目计划之前，必须首先编写《项目偏差控制报告》，该报告是修改项目计划的直接依据。在项目计划的修改前、修改后，需要通过《项目计划变更控制报告》，要求公司的管理层和买方的管理层签字确认。在修改后的项目计划中，必须体现所有受项目计划变更的影响，并做对应的修改。项目计划修改后在必要时必须通过评审。项目计划变更后，需要通知与项目组相关的人员或组织。项目计划变更的工作流程示意图如下。通过项目计划的变更流程，实施对项目计划文档的控制和管理。

1.5项目验收与结束1.5.1系统投入使用验收验收过程•系统投入使用验收申请•系统投入使用验收计划•系统设备验收文档审查、环境检查•制定投入使用测试大纲和测试方案•投入使用测试•制定系统割接计划和割接方案•系统上线或割接验收标准•系统基本功能已经开发完成，能够满足业务的基本要求，系统功能的进一步开发对已开发完成功能的使用不会造成影响时。验收成果《上线报告》1.5.2系统初验验收过程•系统稳定验证•系统初验评审•系统初验表决•系统移交验收标准•系统开发建设完成，满足业务要求后进行的验收。初验完成后，允许系统存在少量遗留问题。时限要求•上线后3个月内。验收成果《初验报告》1.5.3系统终验验收过程•系统终验评审•系统终验表决•系统最终移交验收标准•统完全符合合同要求，经过试运行，系统调整优化到满足目前各业务要求，且基本满足系统性能要求后进行的验收。时限要求•初验后3个月内。验收成果•《终验报告》1.5.4项目结束按照合同约定免费维护期结束后项目结束。1.6项目文档资料《技术建议方案》《需求规格书》《概要设计规格书》《详细设计规格书》《系统测试计划》《集成测试报告》《系统测试报告》《用户测试报告》《上线申请报告》《试运行报告》《用户维护手册》《用户使用手册》《数据字典》《技术总结报告》《系统初验报告》《系统终验报告》1.7软件配置管理软件配置管理是项目运作的一个支撑平台，它将项目所有成员（包括公司中对项目负责的高层经理）的工作协同起来，实现高效的团队沟通，使工作成果及时共享。当然，这种支撑是贯穿项目的整个生命周期的。1.7.1配置管理计划在实现软件配置管理计划的过程中，主要实现以下三个里程碑：建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组；建立各阶段的配置基线：随着系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的《软件需求规格说明书》的批准，建立起指派基线；随着工程化软件系统的集成与系统测试的完成，建立起产品基线。建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。1.7.2基线库管理基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。1.7.2.1配置项基线化前楚吱入电提型幽试版本楚吱入电提型幽试版本核心思想：开发人员在每天下班之前将当天工作成果提交到开发库开发区。原则：允许多人对一个文件进行CHECKOUT操作。每天开始开发工作之前，所有开发人员访问开发库开发区将要修改的文件进行CHECKOUT操作。每天下班之前，所有开发人员将当天修改的文件进行CHECKIN操作，以及将当天新增的文件加入开发库开发区中。每天下班之前，配置管理员检查所有开发人员是否已经按要求完成第2步操作。配置管理员将开发库开发区锁住，将当前版本提取至测试区。配置管理员解锁并通知项目组开发人员。1.7.2.2配置项基线化配置项符合以下任一项要求，才可将其纳入基线库:通过GRB评审或通过CCB审核或通过配置经理批准项目经理/技术经理填写“配置项纳入基线请求单”，配置经理审批，配置管理员建立基线。1.7.2.3配置项基线化后核心思想：配置项基线化后纳入基线库，由配置管理员完全控制。原则：不允许多人对一个文件进行CHECKOUT操作，由配置管理员对此做严格控制。项目组所有人员需对基线库中的配置项进行变更，必须先填写变更单，该申请必须通过CCB审核。配置管理员根据变更单，将基线库需变更的配置项进行CHECKOUT操作或向变更修改人开放权限。当变更修改人完成变更后，将变更单提交给配置管理员，配置管理员或变更修改人更新基线库。项目经理/技术经理填写“配置项纳入基线请求单”，配置经理审批，配置管理员建立基线。1.7.3配置管理实施流程1.7.3.1识别配置项配置项基线化的要求配置经理确定项目配置项标识规定，配置项以及基线计划，GRB对其进行评审。配置经理在配置管理计划中明确系统版本升级策略。配置项包括：文档类配置项软件类配置项配置项标识规定技术文档表示规定：客户名称-项目名称-文档类型名称质量记录标识规定：客户名称-项目名称-文档类型名称-序号代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。项目管理文档标识规定：会议纪要：客户名称-项目名称-文档类型名称-开会日期项目周报：客户名称-项目名称-文档类型名称-提交日期技术讨论记录：客户名称-项目名称-文档类型名称-讨论日期软件发布标识内部版本标识：内部版本号：X.Y.Z外部版本标识：版本号二VXX.XX.港华燃气，分别为:主版本号+次版本号+补丁号

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

变更控制项目组所有人员需变更该库中的配置项，需按照变更控制流程严格执行。发布库用途存放待发布，已发布的系统版本。数据来源基线库权限配置管理员：可读/可写其他人员：可读发布管理1.7.3.3变更控制变更申请当需要对基线或基线中的配置项修改时,变更申请人提交变更申请至CCB,变更申请工作内容包括：1、描述变更的需求或来源，说明变更的必要性；2、分析需要变更的内容；3、说明变更来源：需求变更:新增需求、需求变化、需求分析缺陷；设计变更:设计缺陷；上线系统代码变更：编码缺陷。变更评估变更申请提出以后，CCB评估该变更申请，变更决定的结果要求通知所有相关的人员。评估人员要求具备相关的业务、技术、项目、质量素质，以达到评估的效果。如果是变更涉及到客户的变更，或者是上线后的变更，CCB需要吸收客户负责人员参与。评估内容包括：变更申请内容。包括方案、性质、起因、对其他部分的影响；根据变更对系统其他部分的影响，分析变更的工作范围，进行工作的分解。（参见项目管理WBS）根据不同的变更，可能发生的工作范围包括：需求变更实施；设计变更实施；代码变更实施；项目计划变更实施，主要指进度相关；项目预算变更实施；其他相关的变更实施；以上各变更工作根据分析的结果决定先后关系。变更对进度、成本的影响和带来的风险。根据变更的WBS估算增加的工作量，从而得到变更对进度和成本的影响。其中成本以人工时为单位进行计算。评估结果有三种情况：拒绝变更：需要通知相关人员拒绝的原因。变更活动结束，或由申请人重新提出申请。提交管理评审：如果变更带来的进度和成本的变化超出项目经理所能控制的范围，由项目经理申请高层管理评审，请高层决定是否执行变更。如果否决则过程活动结束。提交管理评审的后续结果包含拒绝变更、接受变更两种。决定进行变更：如果决定接收变更则由项目经理根据关键路径图实施变更计划，并由CCB根据变更的类型、内容决定如何进行变更的验证，包括验证的人员和方式。1.7.3.4变更实施变更实施指实际发生的对配置项的修改行为。变更实施是变更评估后的步骤，修改产生的影响已经在变更的评估中考虑。1.7.3.5变更验证变更实施工作完成以后，提交指定的人员按指定的方式进行验证。需求和设计方面的变更内容采用文档评审的方式，代码方面变更内容进入测试流程。变更内容得到验证以后，执行配置管理流程，对应成果确定新的基线。1.8质量保证产品的价值取决于产品的质量，软件质量的特性是多方面的。必须包括：与明确确定的功能和性能需求的一致性。即软件需求是质量度量的基础，缺少与需求的一致性就无质量可言。与明确成文的开发标准的一致性。不遵循专门的开发标准，将导致软件质量低劣。与所有专业开发的软件所期望的隐含的特性的一致性。忽视软件隐含的需求，软件质量将不可信。1.8.1参与制订和评审项目的软件项目计划、标准和规程为项目软件过程的确定和裁剪提供建议；为软件生存周期各阶段工作指出并协助制定所依据的标准和规程；审查项目所选用的有关标准、规程与项目外部强制标准和规程的一致性；评审软件项目计划及选用的标准和规程；提供开发流程的咨询；验证计划、标准和规程是否可得到，且可用于评审和审核活动。1.8.2制订项目SQA计划在软件项目计划制定的同时提出项目SQA计划初稿，SQA计划不应与软件项目计划的内容冲突。项目SQA计划制订并经QA经理的同意后，提交项目经理、软件工程组和配置管理人员进行评审。经过评审的项目SQA计划再经配置控制委员会的批准后，配置管理人员将SQA计划纳入配置管理。1.8.3评审工作产品软件质量保证人员需要评审的工作产品包括但不限于：软件项目计划，软件配置管理计划，测试计划等。需要进行评审的具体工作产品详见SQA计划评审工作产品的目的是确保软件产品符合软件开发标准和规程的要求。在工作产品评审结束后的一个工作日内，软件质量保证人员应报告软件工作产品评审的结果。如果发现了不合格项，软件质量保证人员应向项目经理报告，并按审核后续活动的方法跟踪不合格项的处理，并验证不合格项的纠正结果直至关闭。1.8.4过程审核依据项目SQA计划，软件质量保证人员在项目进行的各个阶段对软件研发过程和工作产品进行审核。当过程审核需要项目组提供支持和配合时，审核前应提前通知项目经理，通知可以用邮件或书面方式。项目经理在得到通知后应准备有关资料，与软件质量保证人员沟通以确定审核时间。实施审核前软件质量保证人员应根据标准检查单剪裁出审核检查单，剪裁后的检查单需经QA经理批准。审核报告：在现场审核结束的一个工作日内，软件质量保证人员应向项目经理和项目组提交审核报告。过程审核后续活动：软件质量保证人员对审核发现的问题，应在现场审核结束的一个工作日内报告给项目经理和项目组。软件质量保证人员在规定的日期后进行验证，验证合格则关闭不合格项；如验证不合格或未采取措施，软件质量保证人员应通过QA经理及时向项目总监报告；报告后，软件质量保证人员必须跟踪该项不合格的处理，必要时进行再验证。所有SQA审核报告、不符合报告等SQA的过程记录，都需要纳入配置管理进行管理和控制。1.8.5SQA报告机制软件质量保证人员应向项目经理和项目组提交审核报告和工作产品评审报告（可和检查单合在一起）。对于在项目组层面未能关闭的不符合报告，应由项目总监裁决，软件质量保证人员跟踪后续活动。SQA活动的定期报告周报：软件质量保证人员为每一个项目准备一份SQA活动周报，其内容为软件质量保证人员一周内对某项目所开展的SQA活动和项目SQA计划状态等情况的总结。汇报对象是项目经理和QA经理。月报：SQA月报是QA经理每月对SQA活动的执行情况、项目SQA计划的进展情况和项目总监裁决不合格项等情况的总结。QA经理每月向项目总监汇报，并抄送SEPG组组长。1.9风险管理1.9.1风险管理约定“风险管理”的目的是识别潜在的问题，以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。风险管理是一个连续的前瞻性的过程，它是业务和技术管理过程的重要组成部分。风险管理需要处理可能危及关键目标的问题。应用持续风险管理的方法来确保有效地抵御和缓解项目生存周期中具有关键影响的风险。有效的风险管理包括，按照项目策划过程中所拟订的共利益者介入计划，与共利益者合作，早期识别风险。为了建立起能够自由而开放地揭示和讨论风险的环境