项目计划编写及变更规程(1).doc

卓越软件 第 PAGE 第 PAGE 1页(共 NUMPAGES 10页) 项目计划编写及变更规程  目录 TOC \o 1-5 \h \z 1 前言 3 1.1 适用范围 3 1.2 术语与缩略语 3 2 概述 3 3 项目计划编写的启动 3 4 项目计划编写的活动描述 4 4.1 概述 4 4.2 确定项目的假设和约束条件 4 4.3 选择生命周期模型 5 4.4 创建WBS 5 4.5 复用计划 6 4.6 项目估计 6 4.7 支持工具与环境 7 4.8 风险识别 7 4.9 外部约定 8 4.10 计划变更与重策划的约定 9 5 项目计划编写的退出条件 9 6 项目计划变更的启动 9 7 项目计划变更的活动描述 9 8 项目计划变更的退出条件 10  前言 适用范围 本文档描述了项目计划编写和变更活动的步骤和流程，适用于使用过程规范的所有软件项目，同时也可作为其他项目的管理参考。 术语与缩略语 SOW：工作说明书 WBS：工作分解结构 概述 与项目计划编写相关的一系列活动，其结果都将在项目计划中有所体现。对于编写项目计划来讲，计划文档本身的重要性无庸置疑，而计划相关活动的过程也是非常重要的，在计划的过程中，对于项目的各个方面都会进行较为细致的分析和考察，从而使得在项目过程中，对于项目进展有较为可靠的预见能力。 由于项目计划的重要性，项目计划的变更对于项目组也同样重要。因此，项目计划的变更需要有比较正式的规程。在此规程之下，使项目计划的变更活动有序、可控。 项目计划编写的启动 针对于某个特定的项目，项目计划的第一次编写通常由组织制度规定，启动于项目立项之后，其它项目活动之前；在此之后，项目计划处于维护和跟踪的状态；在项目里程碑处，以及有重大变更的情况下（例如某些约定的变更和需求的变更），需要对项目计划进行正式的变更，此处正式的含义是指需要根据情况的变化，依据本规程进行，变更的含义是指以原计划为基础，在原计划的基础上，进行各项活动，包括计划的细化、和变更，此时本规程中的各项输入要以当前版本为准。 在项目计划的第一次编写时，通常具备的工作基础为经过评审的SOW，以及确认的初始需求。需求的不清晰是这一阶段编写项目计划的主要问题，项目经理需要判断在什么样的需求状况下，可以进行项目计划的活动。建议的时机是在项目组一致认为需求的边界比较清晰，需求蔓延的可能比较小的情况下，进行项目计划的编写工作。由于需求的不明确，第一次编写的项目计划通常会比较粗，在需求分析之后，随着项目的进行，项目计划需要进行进一步的细化。 另一方面难以确定的问题在于项目的技术风险，通常在SOW评审通过后，项目已经不存在重大的技术路线的风险，但还可能存在某些较低层次的技术难点，在这种情况下，建议项目组依据经验，对项目计划进行较为保守的估计，选择和裁减适当的生命周期，将技术风险在项目的早期判明。 项目计划编写的活动描述 概述 项目计划编写活动的目标是完成项目计划，而项目计划中的各项内容是相关活动的结果，因此项目计划的编写活动与相关活动是交织在一起的。以下的活动规程最终都是将活动结果纳入项目计划。 确定项目的假设和约束条件 角色：项目经理、SQA工程师 输入：文档化的需求、组织制度、相关文件(如项目合同) 活动： 项目经理根据项目的实际情况和组织的相关制度，确定项目的约束条件。约束是指项目实施过程中需要遵守的限制条件，不得超越，如本项目遵从的设计和编码标准。 项目经理根据项目的实际情况，建立项目策划的假设。假设是指为进行项目策划，目前被认为是正确、真实、可靠的一些因素。假设是随着项目的进展不断变化的，通常会导致一定程度的风险。假设的例子如“竞争对手的产品在项目期间没有重大突破、客户的组织结构在项目期间没有重大变化等”。 将确定后的假设和约束条件文档化。 输出：文档化的项目假设和约束条件 备注：进行项目策划活动前，通常总会建立一些假设，由于假设会导致一定程度的风险，过多的假设将会使得项目计划的确定性降低，风险加大，因此，需要注意减少不必要的假设。 由于假设会导致一定程度的风险，在项目进展过程中，对于可靠性变低的假设需要作为风险进行处理。 选择生命周期模型 角色：项目经理、项目组、SQA工程师、SCM工程师 输入：文档化的需求 活动： 1、项目经理标识需要提交客户的软件产品。 2、根据项目的特点，为项目选择生命周期模型。由于项目生命周期模型的重要性，如果组织定义的生命周期模型需要变更或裁剪，需要SQA工程师的协助和认可。参见《软件生命周期模型》。 3、项目经理与SQA工程师一同标识选定的生命周期各个阶段的工作产品。 4、项目经理、SQA工程师和S