系统测试 系统上线 试运行 项目成本 预计 实际 计划 阶段 工作量分布％ 工作量 偏差 实际 工作量 （人时） 偏差 说明 工作量分布％ （人时） 需求开发 系统设计 工作量 系统实现 系统测试 系统上线 试运行 项目管理 小计： 缺陷解决率非常严重： 严重： 较严重： 中等： 较小： （%） 软件质量 缺陷分布%
项目相关活动总结 需求 测试 需求（个） 测试用例（个） 评审内容 计划评审 评审 需求评审 设计评审 代码评审 培训 内部培训 客户培训 阶段 小计： 引入 缺陷数量 发现问题次数 解决缺陷数量 解决问题次数 缺陷解决率 上报问题次数 评审次数 发现问题数 占总数比重 发现缺陷数 占总数比重 － － － － － － － － － 需求变更（个） 需求评审 设计评审 测试 问题 缺陷 31
需求评审 设计评审 测试 小计： 变更类型 计划 变更 需求 其它 小计： 风险(个) 变更申请次数 发生风险(个) 发生风险统计 风险名称 项目风险 预测阶段 发生阶段 建议新风险 问题描述 其它信息 项目成果 过程改进建议 经验与教训 附件清单 确认 项目主管 项目经理 质量保证员
签字日期 签字日期 签字日期 参见《项目成果清单》 1. 项目成果清单 2. 结项确认书 发生阶段 采取措施 建议新风险名称 风险策略 采取措施 变更次数 变更次数比重
32
第4章 管理过程
本章定义**软件项目管理过程。描述了项目管理过程如何做，包括了9个过程，描述了过程、产出物、检查点。
4.1. 范围管理过程
该过程描述了项目经理在对项目的范围管理的内容，范围管理包括项目范围的识别、界定、计划、跟踪和范围验收。 4.1.1. 过程描述 4.1.1.1. 范围识别
项目经理在项目前期与客户经理和售前人员一起配合，收集项目背景资料，查阅与客户沟通的会议纪要、备忘录、投标文件、报价单等。在此基础上编写《合同》、《工作说明书》的初稿，必要时要组织签约前的需求范围的调研；软件项目的范围的识别是一个持续的过程，在需求分析结束后，范围才基本明确。
范围的识别从两个方面来进行，一是项目的范围，包括项目有哪些工作构成、提供哪些服务、交付的内容；二是产品的范围，包括要开发的软件的功能和非功能要求。需求分析的过程就是对产品范围识别、界定、计划的过程。 4.1.1.2. 范围界定
软件项目的范围界定比较复杂，主要通过以下文档来定义项目范围：
《合同》和《工作说明书》：确定项目的大致的工作范围和软件开发的功能范围； 《业务模型》或《售前技术方案》：业务建模往往从客户业务的整体和未来来看，落实到项目本身，往往可以明确项目的范围边界，明确了哪些工作不是该项目的范围；
《需求规格说明书》：细化了产品的范围，是项目验收的主要的依据； 《调研记录》或会议纪要：从点上对项目范围进行了界定和修正。
界定的方式通过需求调研、评审、调查等方式。
对于项目范围的界定，项目经理应该站在解决客户问题的角度，不可死扣合同，坚持原则又要灵活处理。并在对范围边界充分理解的情况下预测项目可能的范围变更。 4.1.1.3. 范围计划
项目经理要将识别的项目范围记录在《项目经理工具集》-范围跟踪表中，应用8/2规则找出20%的范围作为核心范围，将产品功能范围分类，分为必须的、需要的和可选的三类。 4.1.1.4. 范围跟踪
项目经理要定期（每周、每里程碑）更新范围状态。
33
4.1.1.5. 范围验收
项目经理要根据项目的范围与客户协调验收标准，组织客户验收项目。
4.1.2. 主要产出物
《项目经理工具集》-范围跟踪表 4.1.3. 过程检查点 序号 检查点 1. 客户是否已经签署界定项目范围的《工作说明书》？ 2. 项目组是否参与需求调研工作？ 3. 范围跟踪表是否完成？ 4. 范围跟踪表中是否标记出20%的核心需求？ 5. 范围跟踪表中是否对功能需求进行了分类？ 6. 项目经理是否每周更新范围跟踪表？ 7. 项目经理是否在每个里程碑结束更新范围跟踪表？ 8. 验收标准是否制定并与客户达成一致？ 9. 项目经理对将来可能发生的范围的变更是否有一定的预测？ 4.1.4. 主要模板 4.1.4.1. 范围跟踪表模板
检查结果 □是□否□免 □是□否□免 □是□否□免 □是□否□免 □是□否□免 □是□否□免 □是□否□免 □是□否□免 □是□否□免
项目工作范围分解 项目工作范围估计总工作量 任务编号 实际总工作0 量 优先描述 类型 级 实际总工作0 量 优先功能 类型 级 0 重估算工初始估计工作量(人作量(人天) 天) 累计完成度 实际工作量(人天) #DIV/0! 任务 子任务 完成百分比 功能需求范围 项目功能范围估计总工作量 需求编号 0 重估算工初始估计工作量(人作量(人天) 天) 累计完成度 实际工作量(人天) #DIV/0! 系统 模块 完成百分比 34
4.2. 进度管理过程
4.2.1. 过程描述 4.2.1.1. 制定目标
项目经理在每个里程碑开始前要根据项目的总体进度和当前项目的情况制定项目的里程碑目标，即该阶段项目组要完成哪些工作？要交付什么内容？
目标要明确、可检查。制定的目标要与客户方、开发小组组长和成员达成一致。
4.2.1.2. 任务分解
任务分解一般由项目组长、成员完成初稿，项目经理、技术经理要检查任务分解的初稿，并查漏补缺，以及检查是否符合目标。
任务分解的粒度要做到一个开发任务对应一个人员，任务的工期不超过3天。 所有的任务必须有产出物提交，作为任务检查和完成的依据。 任务分解记录在Project工具中。
4.2.1.3. 滚动细化
项目经理与组长在项目每周开始前要对下周的周计划进行滚动细化，细化的任务要
记录在Project工具中。 4.2.1.4. 估计工期
项目经理与任务分解人和任务责任人要一起估计任务完成的工期。（可以由任务分解人员在分解任务和分配资源时要填写初步的估计工期，然后再一起评审。）
任务工期不超过3天，尽量不要跨休息日。任务工期记录在Project工具中。 4.2.1.5. 分配资源
为任务分配资源，要考虑人员的技术特长、兴趣、稳定性等因素。尽量做到一项任
务一个人负责。资源分配要进行资源平衡，避免过度分配和闲置资源。 4.2.1.6. 跟踪计划
项目经理与开发组长要定期跟踪项目计划，检查计划中任务的完成情况。任务的完成情况根据任务的交付物来检查，检查的手段包括：评审、代码走查、测试、文档查阅等。
35