# 软件项目管理

> 计算机科学 · CIE A-Level 9618
> 来源: https://www.owlsprep.com/zh/study/cie-9618-u12-software-project-management/

本子主题涵盖CIE A-Level 9618计算机科学中软件项目管理的核心原则，包括方法论、进度规划、风险管理和团队角色。该内容经常在试卷1的简答题和扩展回答题中考查。

**先修:** [对软件开发生命周期的基本理解](https://www.owlsprep.com/zh/study/cie-9618-u12-software-development-lifecycle/)

## 学习目标

- 解释软件项目管理的核心原则和关键术语
- 针对不同开发场景比较瀑布模型和敏捷开发方法论
- 识别常见项目风险和合适的缓解策略
- 牢记软件项目团队中的关键角色及其职责

## 核心原则与关键术语

软件项目管理是对软件开发进行规划、监控和控制的实践，旨在在约定的时间、成本和质量约束下交付满足利益相关者需求的产品。所有项目都受范围、时间、成本三重约束的限制，必须平衡这三者才能获得成功的结果。

**软件项目管理** — 为实现特定目标和成功标准，启动、规划、执行、监控和结项软件开发工作的过程

*例:* 开发学生考勤应用的团队管理开发工时、截止日期和客户不断变化的功能需求，以在预算内交付可用产品。

- **范围**：项目必须交付的功能和需求集合
- **利益相关者**：所有受项目结果影响的个人或群体
- **风险**：任何会对项目产生正面或负面影响的不确定事件
- **可交付成果**：项目过程中产生的有形或无形产出

**例题:** 请为当地小型企业开发新电商网站的项目找出4项关键约束。

1. 步骤1：定义项目约束：任何限制项目交付的因素。
2. 步骤2：找出前两项约束：范围（所需功能：结账、用户账户、库存追踪）和时间（假日购物季前的截止日期）。
3. 步骤3：找出剩余两项约束：成本（小型企业用于支付开发工时的预算有限）和质量（必须满足处理客户支付数据的安全标准）。

## 项目管理方法论

CIE 9618经常要求对比两种最常见的项目管理方法论：瀑布模型和敏捷开发。方法论是一种组织和完成项目工作的结构化方法。

**方法对比**

以下是考试中考查的两种核心方法论的对比：

- **瀑布模型** — 线性顺序方法，每个开发阶段完成后才进入下一个阶段。需求在项目启动时就已固定并完整记录。
  - 优点: 易于管理和规划进度; 清晰完整的文档; 适用于需求稳定的小型项目
  - 缺点: 对需求变化的适应性差; 测试阶段靠后，会导致代价高昂的返工; 完整产品仅在项目结束时交付

- **敏捷开发** — 迭代增量方法，将工作拆分为固定长度的短冲刺。需求随时间演变，每次冲刺后都会收集利益相关者的定期反馈。
  - 优点: 轻松适应需求变化; 早期即可获得可工作产品进行测试; 发生代价高昂的大规模返工的风险更低
  - 缺点: 发生不受控范围蔓延的风险更高; 文档完整性较低; 最终成本和工期很难提前预测

> **tip**
>
> 当考试题目要求你推荐方法论时，始终要将你的选择和场景的具体细节关联起来。绝不要只说敏捷开发总是更好。

**例题:** 某项目要开发新的社交应用，需求未完全定义，客户需要定期更新来调整功能，请为该项目推荐合适的方法论。

1. 步骤1：分析场景的关键特征：初始需求不明确，需要客户定期输入意见和进行变更。
2. 步骤2：排除瀑布模型：瀑布模型要求所有需求在项目启动时就固定，若项目中期发生变更，会带来重大干扰和额外成本，因此无法适应。
3. 步骤3：论证敏捷开发的合理性：敏捷开发将工作拆分为2-4周的冲刺，每次冲刺后客户都可以审核可工作产品并调整需求，完全符合该场景的需求。

## 进度规划与风险管理

项目进度规划包括将工作拆分为任务、识别任务之间的依赖关系，并对照截止日期跟踪进度。风险管理是识别潜在问题并制定缓解策略以降低其影响的过程。

**关键路径** — 决定整个项目最短完工时间的最长依赖任务序列。关键路径上任何任务的延误都会推迟项目的整体完工日期。

*例:* 如果数据库设计必须在编写应用后端代码之前完成，那么这两个任务都是关键路径的一部分。

常见的软件项目风险包括范围蔓延、人员流动、不切实际的截止日期和未经验证的技术复杂度。每种风险都有对应的缓解策略来降低影响。

**例题:** 某软件项目因客户经常要求添加新功能而面临范围蔓延风险，请解释一种应对该风险的有效缓解策略。

1. 步骤1：先定义范围蔓延：项目范围发生不受控、未获批准的变更，会导致工期延误和成本增加。
2. 步骤2：描述正式变更控制流程：所有新功能需求都需要书面记录，评估其对项目时间、成本和范围的影响，在任何工作开始前，只能由项目指导小组批准或拒绝该需求。
3. 步骤3：解释该策略的有效性：它可以防止在不调整截止日期和预算来适应变更的情况下，将未计划工作添加到项目中，保证项目按计划推进。

## 团队角色与利益相关者管理

CIE考试经常考查软件项目团队中关键角色的职责。以下是你需要牢记的核心角色：

- **项目经理**：整体负责规划、进度安排、预算和按时交付
- **业务分析师**：从利益相关者处获取并记录需求
- **开发人员**：编写、测试和维护产品代码
- **测试人员**：独立验证产品是否符合需求，并识别缺陷
- **客户/最终用户**：定义需求并验收最终产品

**例题:** 开发团队不清楚客户对产品的需求，哪个角色负责解决这个问题，为什么？

1. 步骤1：确定正确角色：业务分析师。
2. 步骤2：解释该角色的核心职责：业务分析师直接与客户和利益相关者沟通，为开发团队获取、澄清并清晰记录需求。
3. 步骤3：论证：业务分析师编写的清晰需求文档可以消除歧义，确保团队开发出符合客户需求的产品。

## 常见错误

- **错误做法:** 无论场景背景如何，都默认敏捷开发是正确答案
  - 原因: 许多学生知道敏捷开发是更现代的方法，因此会自动选择它，即使场景描述的是固定需求。
  - 正确做法: 始终将方法论与场景匹配：需求固定稳定时使用瀑布模型，需求变化不明确时使用敏捷开发。
- **错误做法:** 声称任何任务的任何延误都会延误整个项目
  - 原因: 学生忘记只有关键路径上的任务会影响项目整体完工日期。
  - 正确做法: 只有关键路径上的任务的松弛/浮动时间为零。非关键任务可以在不改变项目完工日期的前提下，延误不超过其松弛时间的时长。
- **错误做法:** 将所有范围变更都称为范围蔓延
  - 原因: 受控的、已批准的范围变更是任何项目的正常部分。范围蔓延专门指不受控的变更。
  - 正确做法: 只有未获批准、未计划的项目范围变更，即在不调整时间或成本的情况下增加工作量，才被定义为范围蔓延。
- **错误做法:** 声称敏捷项目没有文档
  - 原因: 敏捷开发优先考虑可工作软件而非完整文档，这经常被误解为完全不需要文档。
  - 正确做法: 敏捷项目仍然包含足够的文档用于维护和后续开发，只是完整性低于瀑布模型。
- **错误做法:** 将需求收集工作分配给项目经理
  - 原因: 学生经常混淆项目经理和业务分析师的职责。
  - 正确做法: 业务分析师负责获取和记录需求；项目经理专注于规划、进度安排和预算。

## 速查表

| 概念 | 瀑布模型 | 敏捷开发 |
| --- | --- | --- |
| 开发方法 | 线性顺序 | 迭代增量 |
| 需求 | 启动时固定 | 随时间演变 |
| 适用场景 | 需求稳定、重监管项目 | 需求变化、创新型项目 |
| 文档 | 完整全面 | 足够即可、及时更新 |
| 范围蔓延风险 | 低 | 高（若不受控） |
| 交付 | 项目结束交付完整产品 | 每个冲刺交付可工作增量 |
| 变更灵活性 | 低 | 高 |

## 下一步

软件项目管理是所有后续软件工程学习的核心基础，为理解复杂项目的系统开发、需求收集和质量保证奠定基础。本子主题在CIE 9618试卷1中占比很高，经常出现6-8分的扩展回答题，考查你将概念应用到特定场景的能力。专注练习方法论对比和风险缓解示例才能得满分。点击下方链接拓展你对相关概念的知识。

- [计算思维与问题解决（含声明式、面向对象和人工智能）](https://www.owlsprep.com/zh/study/cie-9618-u13-overview/)
- [问题分解](https://www.owlsprep.com/zh/study/cie-9618-u13-problem-decomposition/)
- [抽象](https://www.owlsprep.com/zh/study/cie-9618-u13-abstraction/)

---

来自 [OwlsPrep](https://www.owlsprep.com) —— A-Level / IB / AP / IGCSE 免费学习指南，依据官方考纲编写。原页面：https://www.owlsprep.com/zh/study/cie-9618-u12-software-project-management/