# 软件生命周期

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

本模块涵盖软件开发生命周期的核心阶段、业界和考试中常见的模型，以及如何根据特定项目需求选择合适的模型，内容符合CIE 9618的学习要求。

**先修:** [掌握软件开发基础概念](https://www.owlsprep.com/zh/study/cie-9618-u11-introduction-to-software/)

## 学习目标

- 描述所有软件生命周期共有的核心阶段
- 对比不同主流软件生命周期模型
- 针对给定项目场景选择合适模型并给出理由
- 指出常见模型的优缺点

## 所有软件生命周期的核心阶段

所有软件生命周期模型都是用于构建和维护软件的结构化框架。无论使用哪种具体模型，它们都有共同的核心高层阶段，覆盖从最初构思到最终退役的完整过程。

**软件生命周期** — 描述软件产品从最初构思到开发、部署、维护直至退役所有阶段的结构化框架。

| 阶段 | 核心活动 |
| --- | --- |
| 可行性研究 | 评估项目在技术、财务、运营层面的可行性 |
| 需求分析 | 收集并记录所需的软件功能 |
| 设计 | 规划架构、数据结构和用户界面 |
| 实现 | 编写代码，构建可运行的软件 |
| 测试 | 验证需求是否满足，修复缺陷 |
| 部署 | 向终端用户发布软件 |
| 维护与退役 | 更新/修复软件，在过时后停用 |

**例题:** 列出可行性研究获批后、部署前发生的软件生命周期核心阶段。

1. 1. 可行性研究获批后，第一个阶段是需求分析。团队会与干系人会面，收集并记录所有功能性和非功能性需求，然后获得签字确认。
2. 2. 接下来是设计阶段，产出符合需求文档的架构图、数据库模式和界面原型。
3. 3. 之后是实现阶段，开发人员根据设计规范编写代码来构建软件。
4. 4. 最后，测试会验证软件符合需求，修复所有已发现的缺陷，之后才进入部署阶段。

## 瀑布模型

瀑布模型是最早的传统顺序生命周期模型，每个阶段按顺序全部完成，一旦某个阶段结束就无法返回前一阶段。

**瀑布模型** — 线性顺序生命周期模型，每个阶段全部完成后才进入下一阶段，没有内置的回溯或迭代机制。

*例:* 适用于需求完全固定、已达成一致且不会发生变更的小型低风险项目。

**例题:** 一家本地小企业需要一个简单的静态网站，所有需求都已固定并以书面形式确认。解释为什么瀑布模型适合这个项目。

1. 1. 瀑布模型非常适合需求稳定固定的小型项目，正好符合本项目的描述。
2. 2. 与迭代模型相比，瀑布模型的管理开销极低，对于低预算的小型项目来说高效且划算。
3. 3. 需求确认后不会有变更，因此不需要迭代模型的灵活性。项目可以通过单次顺序流程快速完成。

> **考试提示:** 在CIE考试中，论证模型选择时一定要将模型的特性与具体场景关联起来，这样才能拿到满分。

## 迭代、增量与敏捷模型

迭代模型将开发拆分为重复循环，每个循环都会根据反馈优化产品。增量模型以小的功能块交付可运行软件，每个循环添加新功能。现代敏捷方法论（如Scrum）结合了这两种方法。

**敏捷软件开发** — 灵活的迭代软件开发方法，优先考虑可运行软件的快速交付、响应需求变更和持续收集客户反馈。

**例题:** 一家初创公司正在开发一款面向消费者的新型移动应用，需要每月发布新功能，以响应用户反馈和不断变化的市场趋势。论证为什么敏捷是这里的正确模型。

1. 1. 敏捷使用2-4周的短开发周期（冲刺），允许团队每月交付新的可运行功能，符合初创公司定期发布的要求。
2. 2. 敏捷专为适应需求变更设计，因此团队可以轻松将用户反馈和市场变化融入后续冲刺。
3. 3. 提前交付可运行软件让初创公司可以尽早用真实用户测试产品，降低开发出不符合市场需求产品的风险。

## 螺旋模型与RAD模型

CIE 9618考试中另外两个常考的常见模型是螺旋模型（适用于高风险项目）和快速应用开发（RAD，适用于快速、以用户为中心的开发）。螺旋模型结合了瀑布模型的结构和迭代开发，并高度重视风险管理。

**螺旋模型** — 风险驱动的迭代生命周期模型，要求每个新开发周期前都进行正式的风险评估和缓解步骤。

**例题:** 一家大型航空航天公司正在开发用于商用飞机的新型安全关键型飞行控制软件。哪个生命周期模型最合适，为什么？

1. 1. 螺旋模型是这个项目最合适的选择。
2. 2. 这是一个大型高风险项目：任何软件缺陷都可能造成灾难性后果，因此每个开发阶段前都需要严格的风险分析。
3. 3. 螺旋模型要求每个周期开始时都明确识别并缓解风险，符合本项目的安全要求。
4. 4. 每个螺旋周期中重复的原型设计和测试也降低了遗漏关键缺陷的概率，这对安全关键型系统至关重要。

## 常见错误

- **错误做法:** 声称敏捷开发不包含所有核心软件生命周期阶段
  - 原因: 敏捷开发中所有核心阶段仍然都会完成，只是在各次冲刺中增量重复进行，而非在项目开始时一次性完成
  - 正确做法: 应当说明核心阶段会在每个增量中重复，而非被完全省略
- **错误做法:** 声称瀑布模型在现代开发中已不再使用
  - 原因: 瀑布模型仍然适用于需求完全固定、需要低管理开销的小型项目
  - 正确做法: 对于不需要迭代、需求固定的小型场景，应当合理说明瀑布模型的适用性
- **错误做法:** 混淆增量开发和迭代开发
  - 原因: 即使现代模型结合了两者，这两个术语描述的仍是不同概念
  - 正确做法: 记住：增量 = 分块添加新功能，迭代 = 通过重复循环优化产品
- **错误做法:** 所有大型项目都选择敏捷开发
  - 原因: 敏捷开发缺乏受监管的安全关键型项目所需的严格文档和正式风险分析
  - 正确做法: 对于需求固定、受监管的安全关键型项目，选择螺旋模型或瀑布模型
- **错误做法:** 忘记将维护列为核心生命周期阶段
  - 原因: 大多数软件在部署后，其生命周期的大部分时间都处于维护阶段
  - 正确做法: 考试中列出生命周期阶段时，一定要包含维护（以及最终退役）

## 速查表

| 模型 | 适用场景 | 核心优势 | 核心劣势 |
| --- | --- | --- | --- |
| 瀑布模型 | 需求固定的小型低风险项目 | 简单、开销低、文档清晰 | 无法应对变更、测试时间晚 |
| 敏捷开发 | 需求动态变化的消费类产品 | 交付快、适应变更 | 开销更高、正式文档较少 |
| 螺旋模型 | 大型高风险安全关键型项目 | 明确的风险管理 | 耗时且成本高 |
| RAD | 快速开发、以用户为中心的项目 | 交付快、可提前获得用户反馈 | 对非功能性需求关注不足 |

## 下一步

理解软件生命周期模型是CIE 9618试卷1的基础考点，几乎每年都会在选择题和结构化问答题中进行考核。考试中经常会要求你针对给定场景选择模型并论证，因此练习将模型特性与场景特征匹配是拿到满分的关键。这些知识是所有后续软件开发主题的基础，后续你会在考试范围内更详细地研究各个生命周期阶段。

- [需求分析](https://www.owlsprep.com/zh/study/cie-9618-u12-requirement-analysis/)
- [软件设计方法](https://www.owlsprep.com/zh/study/cie-9618-u12-software-design-methods/)
- [测试](https://www.owlsprep.com/zh/study/cie-9618-u12-testing/)

---

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