【万字精编蓝本】《软件项目管理》期末复习 | 总体全景图+25个常考知识点全覆盖

【万字精编蓝本】《软件项目管理》期末复习 | 总体全景图+25个常考知识点全覆盖

本文为《软件项目管理》课程期末复习专用，系统梳理PMBOK知识体系框架，深度拆解25个高频考点，涵盖概念辨析、公式计算、案例分析、图表解读四大题型。全文按照「总览-分模块精讲-应试技巧」三层结构展开，兼顾基础概念巩固与综合解题能力提升，适合期末突击复习与课程知识体系构建。

📚 软件项目管理总体全景图

软件项目管理是在有限的资源约束下，运用系统的观点、方法和理论，对软件项目涉及的全部工作进行有效管理的过程。其核心框架建立在PMBOK（项目管理知识体系指南） 基础之上，可从「知识维度」「过程维度」「要素维度」三个视角完整把握。

一、PMBOK十大知识体系

PMBOK将项目管理划分为十大知识领域，覆盖项目全生命周期的管理对象：

二、五大标准化过程组

项目管理的五大过程组贯穿项目始终，形成闭环管理：

三、四大核心约束要素

软件项目管理的本质是平衡四大要素：范围、质量、进度、成本，即「项目铁三角」。四要素相互制约，其中范围与质量通常为正向关系，成本与进度、质量往往呈反向变动关系。

🎯 25个常考知识点精讲

第一章 软件项目管理概述

知识点1：项目与日常活动的区别

项目和日常运作（运营）是组织两类基本活动，二者有本质区别，是选择题高频考点。

考试提示：判断一个活动是不是项目，关键看「临时性」和「独特性」两个核心特征。比如「每天编译代码」是日常活动，「开发一个新功能模块」是项目。

知识点2：项目的六大特征

项目具备以下六个基本特征，常以简答题或多选题形式考查：

知识点3：PMBOK十大知识体系的核心职能对应

本题为必考题，直接考查知识领域与管理对象的对应关系：

• 管理项目进度的是：项目进度管理
  负责定义活动、排列活动顺序、估算工期、制定进度计划、控制进度。

• 管理需求的是：项目范围管理
  负责收集需求、定义范围、创建WBS、确认范围、控制范围，确保做且只做范围内的工作。

• 管理钱的是：项目成本管理
  负责估算成本、制定预算、控制成本，确保项目在批准预算内完成。

• 管理人或团队的是：项目资源管理（原人力资源管理）
  负责组建团队、建设团队、管理团队，以及物资资源的调配与管理。

拓展速记：

• 管整体：集成管理
• 管边界：范围管理
• 管时间：进度管理
• 管资金：成本管理
• 管好坏：质量管理
• 管人：资源管理
• 管信息：沟通管理
• 管风险：风险管理
• 管外包：采购管理
• 管人预期：相关方管理

知识点4：五大过程组的常见活动

五大过程组不是孤立的五个阶段，而是相互交叠、循环迭代的，每个过程组包含典型活动：

考试提示：注意区分「规划」和「监控」的区别——规划是做计划，监控是对照计划找偏差。比如「制定进度计划」属于规划，「控制进度」属于监控。

第二章 软件项目初始过程

知识点5：项目章程的定义与作用

项目章程是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。它是项目的「出生证明」，是项目正式启动的标志。

项目章程的核心作用：

项目章程主要内容：
项目目的、可测量目标、高层级需求、高层级项目描述、总体里程碑进度计划、预先批准的财务资源、关键相关方清单、项目审批要求、项目经理及其职责权限、发起人姓名与职权。

重要结论：项目经理最好在制定项目章程时就被任命，最晚也必须在规划开始前任命。项目章程不是详细计划，是高层级的纲领性文件。

知识点6：招投标阶段甲乙双方的任务

软件项目合同签订前的招投标阶段，甲乙双方职责不同，是案例分析题常考点。

甲方（需求方、买方）的主要任务：

乙方（供方、卖方）的主要任务：

考试提示：甲方核心是「选」——选择合适的乙方；乙方核心是「争」——争取中标并获得有利合同条件。

知识点7：项目经理的职责

项目经理是由执行组织委派，领导团队实现项目目标的个人，是项目的第一责任人。其职责可分为三大层面：

1. 对项目目标负责

• 确保项目在范围、进度、成本、质量约束下交付成果
• 制定项目计划，监控项目执行，管理项目变更
• 识别和管理项目风险，处理项目问题与危机
• 对项目成败承担主要管理责任

2. 对项目团队负责

• 组建项目团队，明确成员职责分工
• 建设高效团队，提升团队能力与士气
• 协调团队内部资源与冲突，营造良好工作氛围
• 指导、激励团队成员，推动绩效提升

3. 对相关方负责

• 与发起人、客户、用户等关键相关方沟通
• 管理相关方期望，平衡各方利益诉求
• 及时汇报项目进展、问题与风险
• 维护客户关系，确保项目满意度

具体工作内容：
制定项目管理计划、WBS分解、进度安排、预算控制、质量保证、沟通协调、风险管理、变更控制、会议组织、文档管理、团队建设、绩效评估、项目收尾总结等。

重要观点：项目经理对项目负有最终责任，但权力往往有限，需要通过影响力和沟通能力推动工作。优秀的项目经理80%的时间在沟通。

第三章 软件生存期模型

知识点8：瀑布模型与V模型的适用场景

软件生存期模型是软件项目全过程的总体框架，决定了项目各阶段的划分、顺序和迭代方式。

1. 瀑布模型（Waterfall Model）
瀑布模型是线性顺序的软件开发模型，将软件生命周期划分为需求分析、设计、编码、测试、维护五个阶段，自上而下、线性推进，如同瀑布逐级下落。

核心特点：

• 阶段间具有顺序性和依赖性，前一阶段输出是后一阶段输入
• 每个阶段有明确的任务和交付物
• 强调文档驱动，每个阶段结束都要评审
• 不支持回溯，变更成本极高

适用场合：

• 需求明确、稳定，需求在项目初期就完整清晰
• 开发技术成熟，团队对业务领域非常熟悉
• 项目周期短，规模不大
• 低风险项目，不确定性低
• 对文档要求高的合规类项目

缺点：

• 难以适应需求变化
• 用户直到后期才能看到产品，风险延后暴露
• 容易阻塞，早期延迟会影响整体工期

2. V模型（Verification and Validation Model）
V模型是瀑布模型的变种，将测试活动与开发阶段对应起来，形成V字形结构。左边是开发各阶段，右边是对应的测试级别。

对应关系：

• 需求分析 → 验收测试
• 概要设计 → 系统测试
• 详细设计 → 集成测试
• 编码 → 单元测试

核心特点：

• 测试与开发并行规划，提前介入
• 不同级别的测试对应不同开发阶段
• 强调质量保证，尽早发现缺陷
• 仍然是线性结构，本质上属于瀑布变种

适用场合：

• 需求明确、变更不频繁的项目
• 对质量要求高、需要严格测试的项目
• 嵌入式系统、安全关键系统
• 有明确测试标准和规范的行业项目

缺点：

• 本质仍是线性，不灵活
• 没有迭代，需求变更代价大
• 容易导致测试与开发脱节

考试对比总结：

第四章 范围计划管理

知识点9：范围/需求管理常见问题与改进方法 + WBS的作用

范围管理是软件项目失败的重灾区，需求蔓延、范围失控是最常见的问题。本题为案例分析必考题。

一、范围/需求管理常见问题分析

二、改进措施

三、WBS的作用

WBS（工作分解结构）是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。它是范围管理的核心工具，被称为「项目管理的基石」。

WBS的主要作用：

重要原则：WBS分解遵循「100%原则」——WBS包含全部项目工作，且只包含项目内的工作。最底层是工作包，每个工作包只属于一个上层任务。

第五章 软件项目成本计划

知识点10：各阶段成本估算方法

成本估算在项目不同阶段精度要求不同，采用的方法也不同，是选择题和简答题高频考点。

1. 合同竞标阶段（项目前期，信息最少）

• 采用方法：类比估算法（专家判断法）
• 特点：基于历史类似项目的成本进行估算，精度最低
• 优点：速度快、成本低，适合信息不足时
• 缺点：误差大，受项目相似性和专家经验影响
• 精度范围：±30% ~ ±50%

2. 项目起始阶段（立项启动，初步需求）

• 采用方法：参数估算法、功能点法
• 特点：利用历史数据建立数学模型，通过参数计算成本
• 典型代表：COCOMO模型、功能点估算、W-F模型
• 优点：客观性较强，有数据支撑
• 缺点：依赖历史数据质量，不适合创新性项目
• 精度范围：±15% ~ ±30%

3. 需求确定后（详细设计阶段，信息充分）

• 采用方法：自下而上估算法（工料清单法）
• 特点：从最底层工作包开始估算，逐层向上汇总
• 优点：精度最高，细节详实
• 缺点：耗时费力，需要完整的WBS
• 精度范围：±5% ~ ±10%

补充：三点估算法
三点估算法通过乐观值、最可能值、悲观值三个值计算期望成本，考虑了不确定性：

• 期望成本 = (乐观 + 4×最可能 + 悲观) / 6
• 标准差 = (悲观 – 乐观) / 6

常与自下而上估算结合使用，提高估算可靠性。

考试记忆口诀：竞标用类比，立项用参数，需求确定自下而上。

知识点11：直接成本与间接成本

项目成本按计入方式可分为直接成本和间接成本，是成本核算的基础概念。

直接成本：直接归属于项目工作的成本，可以直接计入项目账目。

包含内容：

• 项目团队人员的工资、奖金、福利
• 项目专用的硬件设备、软件工具采购费
• 项目专用的物料、耗材、差旅费
• 外包给第三方的专项服务费
• 项目专属的培训费用

特点：

• 与特定项目直接相关
• 可准确计量和追溯
• 项目经理有较大控制权

间接成本：不能直接归属于某个具体项目，需要分摊到多个项目的成本。

包含内容：

• 公司管理人员工资（行政、财务、人力等）
• 办公场地租金、水电费、物业费
• 公司级的基础设施、网络、公共软件
• 员工福利、团建、企业文化费用
• 企业税费、审计费、法律咨询费

特点：

• 多个项目共同分担
• 按一定比例分摊计入项目
• 项目经理控制权有限

考试提示：判断直接还是间接，关键看「是否专为这个项目发生」。比如项目经理工资是直接成本，部门经理工资是间接成本。

知识点21：W-F模型与COCOMO 81模型

这是两个经典的软件成本估算模型，属于参数估算方法，计算题常考。

一、Walston-Felix（W-F）模型

W-F模型是基于IBM项目数据总结的经验模型，以代码行数（LOC）为自变量：

$$E=5.2\times L^{0.91}$$
$$D=4.1\times L^{0.36}$$

其中：

• E：工作量，单位为人月（PM）
• D：项目工期，单位为月
• L：源代码行数，单位为千行代码（KLOC）

特点：

• 结构简单，只有代码行数一个变量
• 适用于中型软件项目估算
• 不区分项目类型和应用领域

二、COCOMO 81模型（构造性成本模型）

COCOMO模型由Barry Boehm提出，是最经典的软件成本模型，分为三个层次：

1. 基本COCOMO模型
静态单变量模型，按项目类型分为三种模式：

• 有机模式（Organic）：小型、简单项目，团队经验丰富
  $$E=2.4\times L^{1.05}$$
  $$D=2.5\times E^{0.38}$$

• 半分离模式（Semidetached）：中等规模，复杂度中等
  $$E=3.0\times L^{1.12}$$
  $$D=2.5\times E^{0.35}$$

• 嵌入模式（Embedded）：复杂、高约束、硬件紧密相关
  $$E=3.6\times L^{1.20}$$
  $$D=2.5\times E^{0.32}$$

2. 中间COCOMO模型
在基本模型基础上，引入15个成本驱动因子（产品属性、硬件属性、人员属性、项目属性），乘以工作量调整系数，精度更高。

3. 详细COCOMO模型
分阶段计算，每个阶段应用不同的成本驱动因子权重，精度最高。

考试要点：

• 记住基本COCOMO三种模式的公式系数和指数
• 有机模式指数最小，嵌入模式指数最大
• 规模越大、越复杂，工作量增长越快（超线性）

第六章 软件项目进度计划

知识点12：里程碑图、甘特图、网络图对比

进度管理有三大核心工具，各有特点，适用于不同场景。

问题：可以方便查看任务的工期、开始时间、结束时间及资源的是？
答案：甘特图

甘特图通过条形长度表示工期，位置表示起止时间，还可通过颜色、标注展示资源分配，是最常用的进度展示工具。

不同类别的甘特图：

问题：里程碑图中是真实的任务吗？
答案：不是。

里程碑是项目中的关键事件或时点，标志着某个阶段的完成或某个重要交付物的提交，它不消耗时间和资源，不是一个需要执行的任务，而是一个检查点。比如「需求评审通过」「代码冻结」「正式上线」都是里程碑。

知识点13：任务之间的四种依赖关系

网络图中活动之间的逻辑关系（依赖关系）有四种类型，是绘制网络图的基础。

1. 完成-开始（Finish-to-Start, FS）

• 定义：前置任务完成后，后置任务才能开始
• 示例：代码编写完成后，才能开始测试
• 最常见、最通用的关系

2. 完成-完成（Finish-to-Finish, FF）

• 定义：前置任务完成后，后置任务才能完成
• 示例：文档编写完成，文档校对才能完成
• 两个任务同时进行，但结束有先后

3. 开始-开始（Start-to-Start, SS）

• 定义：前置任务开始后，后置任务才能开始
• 示例：需求分析开始一段时间后，架构设计就可以开始
• 适用于并行搭接的任务

4. 开始-完成（Start-to-Finish, SF）

• 定义：前置任务开始后，后置任务才能完成
• 示例：新系统上线后，旧系统才能停用
• 最少见，多用于交接班类场景

相关概念：

• 前置任务（紧前活动）：排在某个活动之前的活动
• 后置任务（紧后活动）：排在某个活动之后的活动
• 提前量（Lead）：后置任务可以提前开始的时间
• 滞后量（Lag）：前置任务完成后需要等待的时间

考试提示：FS是默认关系，题目没说的都按FS处理。

知识点22：两类甘特图的时间节点解读

甘特图分为计划甘特图和跟踪甘特图（实际甘特图），是图表分析题常考题型。

计划甘特图（基准甘特图）：

• 每个任务对应一条条形
• 条形左端对应计划开始时间
• 条形右端对应计划结束时间
• 条形长度对应计划工期
• 是项目基准，作为进度对比依据

跟踪甘特图（双条形甘特图）：
同一任务显示上下两条条形：

• 上方条形（通常浅色）：计划开始时间、计划结束时间
• 下方条形（通常深色）：实际开始时间、实际结束时间
• 条形内部填充比例表示完成百分比

解读方法：

• 实际条形在计划条形左侧：任务提前开始/完成
• 实际条形在计划条形右侧：任务延期开始/完成
• 实际条形比计划条形长：实际工期超出计划
• 实际条形比计划条形短：实际工期少于计划

考试技巧：看横坐标对齐位置，左端对比开始时间，右端对比结束时间。注意区分「进度提前」和「工期缩短」的区别。

知识点23：ADM网络图的常见错误与修正

ADM（箭线表示活动法），又称双代号网络图，用箭线表示活动，节点表示事件。考试中常考找错改错题。

ADM网络图的绘制规则：

常见错误类型：

修正方法：

• 多个起点：增加统一的开始节点，用虚箭线连接
• 多个终点：增加统一的结束节点，用虚箭线连接
• 循环回路：调整箭线方向，理顺逻辑
• 编号问题：重新编号，保证从小到大
• 平行活动：插入虚活动区分
• 逻辑错误：根据实际业务调整依赖关系

知识点24：关键路径计算与最短工期

关键路径是网络图中总工期最长的路径，决定了项目的最短完成时间，是必考计算题。

关键路径特点：

• 是项目从开始到结束的最长路径
• 关键路径上的活动称为关键活动
• 关键活动的总时差为0
• 关键路径决定项目最短工期
• 关键路径延迟，项目总工期延迟
• 一个项目可能有多条关键路径

计算步骤（正推法）：

例题：
活动A工期3天，活动B工期5天，活动C工期2天。A完成后做C，B完成后做C。

• A: ES=0, EF=3
• B: ES=0, EF=5
• C: ES=max(3,5)=5, EF=5+2=7
• 关键路径：B→C，总工期7天

考试提示：

• 关键路径一定是最长的那条，不是最短的
• 多条路径时，逐条计算工期，最长的就是关键路径
• 压缩工期只能压缩关键路径上的活动

知识点25：正推法、逆推法与工期压缩

一、正推法（计算最早时间）
从左向右计算，取大值：

• 最早开始时间 ES
• 最早完成时间 EF = ES + 工期
• 规则：多个紧前活动时，ES取最大值

二、逆推法（计算最晚时间）
从右向左计算，取小值：

• 最晚完成时间 LF = 总工期（终点活动）
• 最晚开始时间 LS = LF – 工期
• 规则：多个紧后活动时，LF取最小值

三、时差计算

• 总时差 TF = LS – ES = LF – EF
  不影响总工期的前提下，活动可延迟的最大时间
  关键活动总时差 = 0

• 自由时差 FF = 紧后ES – 本活动EF
  不影响紧后活动最早开始的前提下，可延迟的最大时间

四、工期压缩方法

当项目需要缩短工期时，采用进度压缩技术：

1. 赶工（Crashing）

• 增加资源投入，以最小成本增量压缩工期
• 只压缩关键路径上的活动
• 优先压缩单位赶工成本最低的活动
• 会增加成本，可能引入风险
• 注意：压缩后可能出现新的关键路径

2. 快速跟进（Fast Tracking）

• 将本来顺序执行的活动改为并行执行
• 不增加资源，通过改变逻辑关系压缩工期
• 可能造成返工，增加风险
• 适用于风险低、依赖弱的活动

压缩原则：

• 只能压缩关键路径上的活动
• 每次压缩后重新计算关键路径
• 不能把关键路径压缩成非关键路径
• 优先选择成本低、风险小的活动压缩

第七章 软件项目质量计划

知识点14：质量管理核心要点

一、质量管理的主要过程

二、质量管理的关键
质量管理的关键是预防胜于检查。质量是规划出来、设计出来、建造出来的，不是检查出来的。预防成本远低于缺陷修复成本。

三、判断：软件质量可以通过后期测试得以提高，对吗？
答案：不对。

测试只能发现缺陷，不能提高软件质量本身。测试是质量控制手段，只能验证质量，不能提升质量。真正的质量提升来源于开发过程的改进、技术的提升、流程的优化。后期测试发现缺陷再修复，成本高且治标不治本。

四、代码走查与技术评审的区别

五、改善软件质量的建议

第八章 软件配置管理计划

知识点15：基线变更管理

判断：基线变更不需要按规范流程走，只要项目经理口头同意即可，对吗？
答案：不对。

基线是经过正式评审和批准的规范或产品，作为后续工作的基准，只能通过正式的变更控制流程进行修改。基线一旦建立，就具有严肃性和稳定性，不能随意变更。

基线变更的正确流程：

重要原则：

• 所有变更必须留痕，禁止口头变更
• 基线变更必须走正式流程
• 不同级别变更对应不同审批权限
• 变更必须评估影响，不能盲目修改
• 变更后必须验证和同步更新文档

知识点16：配置项标识与Git/SVN架构区别

一、软件配置项标识

配置项（CI）是纳入配置管理的工作产品，需要进行唯一标识。

标识方法：
通常采用「名称-版本号」的标识体系，例如：项目名-模块名-文件类型-Vx.y.z

版本号规则（语义化版本）：

• 主版本号：重大架构变更，不兼容
• 次版本号：功能新增，向下兼容
• 修订号：bug修复，完全兼容

问题：标识号可以重复吗？
答案：不可以。

每个配置项必须有唯一的标识号，确保可以准确识别和追踪。同一配置项的不同版本用版本号区分，标识号+版本号全局唯一。

标识原则：

• 唯一性：每个配置项有唯一标识
• 系统性：命名有规则，便于理解和管理
• 可追溯：能追溯到历史版本和变更记录
• 稳定性：标识一旦确定不轻易改动

二、Git与SVN的架构区别

Git和SVN是最主流的两种版本控制工具，架构上有本质区别。

核心区别总结：
SVN是「一个中心，多个终端」，所有版本信息存在服务器，本地只有当前版本；Git是「对等网络」，每个节点都是完整仓库，去中心化。

第九章 人员与沟通计划

知识点17：项目组织图与沟通渠道

一、项目组织图的作用

项目组织图（Organization Breakdown Structure, OBS）展示项目团队成员及其报告关系，说明谁向谁汇报、每个角色的职责和人员配置。

主要用途：

常见组织结构类型：

• 职能型：按职能部门划分，项目经理权力小
• 项目型：按项目划分，项目经理权力大
• 矩阵型：平衡职能与项目，分弱矩阵、平衡矩阵、强矩阵

二、沟通渠道计算

沟通渠道数量计算公式：

$$N=\frac{n\times (n-1)}{2}$$

其中n为参与沟通的人数。

示例：

• 3个人：3×2/2 = 3条渠道
• 5个人：5×4/2 = 10条渠道
• 10个人：10×9/2 = 45条渠道

结论：人越多，沟通渠道呈指数级上升。
每增加一个人，沟通渠道增加n条（n为原有人数）。团队规模扩大，沟通成本急剧增加。

三、问题：项目沟通渠道越多越好吗？
答案：不是。

沟通渠道过多会带来以下问题：

最佳实践：

• 控制团队规模，小规模团队沟通效率高
• 建立分层沟通机制，减少全员沟通
• 明确沟通规则和信息分发方式
• 统一信息出口，避免多头传递
• 重要信息书面化，减少口头传递

第十章 软件项目风险计划

知识点18：风险管理全流程

一、风险管理的过程

风险管理包括六个核心过程：

二、每个软件项目的风险都一样吗？
答案：不一样。

不同项目的风险差异很大，影响因素包括：

• 项目规模：规模越大风险越高
• 技术复杂度：新技术、创新多的项目风险高
• 需求清晰度：需求模糊的项目风险高
• 团队经验：团队不熟悉业务技术则风险高
• 项目周期：周期越长不确定性越高
• 外部依赖：依赖第三方多的项目风险高

没有通用的风险清单，每个项目都要单独做风险识别。

三、风险识别的四种方法

最常用且比较简单的是：专家判断法。

四、风险应对策略

针对威胁（负面风险）的四种策略：

回避与转移的区别：

• 回避：让风险根本不发生，消除风险源
• 转移：风险还在，只是让别人承担后果
• 举例：怕下雨取消户外活动是回避；买天气保险是转移。

五、决策树分析技术

决策树是定量风险分析工具，用于在多个备选方案中选择最优方案。

计算方法：

• 每个方案分支计算预期货币价值（EMV）
• EMV = 收益 × 概率 – 成本
• 选择EMV最大的方案

适用场景： 方案A或方案B二选一，或多个方案比选。每个方案有不同的成本、成功概率和收益，通过计算期望值比较优劣。

第十一章 项目执行控制与集成管理

知识点19：项目集成管理与四要素关系

一、项目集成管理管什么

项目集成管理是十大知识领域的核心，负责协调其他所有知识领域，确保项目各要素有机配合。它是唯一的综合性知识领域。

核心管理内容：

核心作用：

• 统一协调各个知识领域
• 平衡相互冲突的目标
• 全局视角决策
• 确保项目整体性

二、四大要素的关系

软件项目管理四要素：范围、质量、进度、成本。

成本与其他要素的关系：

• 成本与范围：正比关系
  范围越大，工作量越大，成本越高；范围缩小，成本降低。

• 成本与质量：正比关系
  质量要求越高，需要投入更多资源、更多测试、更好技术，成本越高。但质量差会导致返工成本上升，存在最优质量成本。

• 成本与进度：通常呈反向关系（在一定范围内）
  要压缩工期，需要赶工增加资源，成本上升；工期宽松可以优化资源，成本降低。但工期过长也会因管理成本增加导致总成本上升，存在最优工期。

补充：进度与质量的关系
通常反向，赶工往往牺牲质量；质量要求高会减慢进度。

三、变更管理

变更是项目的常态，集成管理的核心就是整体变更控制。所有变更都必须：

• 书面记录
• 评估影响
• 按权限审批
• 批准后执行
• 更新基准
• 验证效果

变更控制的目的不是禁止变更，而是管理变更，确保变更有序进行，避免失控。

第十二章 项目结束过程

知识点20：项目结束的条件与流程

一、项目结束要不要总结？要不要评审？
答案：必须总结，必须评审。

项目结束不是做完就完事，收尾是正式的管理过程。总结和评审是收尾的核心工作：

• 总结：沉淀经验教训，形成组织过程资产，供未来项目参考
• 评审：正式验收交付成果，确认是否满足要求，完成移交

没有总结的项目，组织无法积累经验，同样的错误会反复发生。

二、项目结束的条件

项目正式结束需要满足以下条件：

正常结束是第一种，非正常结束包括项目取消、终止等。

三、项目结束的具体过程

项目收尾包括管理收尾和合同收尾两部分，具体步骤：

📝 期末复习应试建议

一、题型应对策略

1. 选择题

• 重点掌握概念辨析、分类、特点、适用场景
• 关注「最核心」「最重要」「第一步」「错误的是」等关键词
• PMBOK过程组与知识领域对应关系务必记牢

2. 简答题

• 分点作答，条理清晰
• 先答核心概念，再展开说明
• 特点、作用、步骤类题目优先记忆框架

3. 计算题

• 重点掌握：沟通渠道、关键路径、正推逆推、成本估算模型
• 步骤写清楚，公式先列再代入数值
• 注意单位统一，结果标注单位

4. 案例分析题

• 先读问题，再看案例
• 对照知识点找问题，给出改进建议
• 答案要结合案例，不要只背理论
• 范围管理、质量管理、风险管理是案例高频考点

二、复习重点排序

三、记忆技巧

• 框架先行：先记住十大知识领域和五大过程组的整体框架
• 对比记忆：相似概念放在一起对比，比如瀑布vsV模型、GitvsSVN
• 口诀记忆：比如「启动规划执行监控收尾」「规避转移减轻接受」
• 结合做题：通过做题巩固知识点，查漏补缺

本文覆盖了软件项目管理课程95%以上的高频考点，建议结合教材和课堂笔记进行二轮复习。计算题部分务必动手多练，案例分析注意培养「找问题-分析原因-提对策」的解题思路。祝考试顺利！