7.1.2 软件的基本生存周期
本课核心知识点整理
生命周期不是死顺序，而是基本活动集合
软件生存周期描述软件从提出、开发、交付、运行维护到退役的完整过程。逻辑上它可以按阶段向下推进，但具体项目中也可能多轮迭代，例如“分析 -> 设计 -> 编码 -> 再分析 -> 再设计 -> 再编码”；测试驱动开发甚至会先写测试再写实现。
所以学习生命周期，要抓两层含义：
| 层次 | 含义 |
|---|---|
| 基本活动 | 立项、计划、需求、设计、编码、测试、维护等活动通常都会出现 |
| 组织方式 | 瀑布、增量、敏捷等模型会改变这些活动的顺序、粒度和迭代方式 |
从立项到退役的完整链条
各阶段真正做什么
| 阶段 | 课堂里的关键含义 | 常见产物 |
|---|---|---|
| 立项/可行性研究 | 先判断项目值不值得做、能不能做、允不允许做 | 可行性研究报告 |
| 项目开发计划 | 在做事之前先规划后续怎么推进 | 项目开发计划 |
| 需求工程/需求分析 | 与用户沟通，把用户表达转换为结构化需求 | 需求规格说明书 |
| 概要设计 | 把系统划分为子系统和模块，分配功能，设计模块间关系 | 概要设计说明书 |
| 详细设计 | 进入模块内部，设计算法、数据结构、内部逻辑和接口细节 | 详细设计说明书 |
| 编码/实现 | 把设计转换为源代码 | 源程序 |
| 测试 | 验证软件功能是否正确实现需求 | 测试计划、测试用例、测试报告 |
| 运行维护 | 在用户环境中运行、更新、打补丁、适应变化 | 维护记录、补丁、版本 |
| 退役/消亡 | 系统不再维护或被新系统替代 | 退役方案、迁移方案 |
需求、概要设计、详细设计的边界
| 问题 | 所属阶段 | 解释 |
|---|---|---|
| 用户到底需要系统完成什么？ | 需求分析 | 关注功能、约束和业务目标 |
| 系统分成哪些子系统和模块？ | 概要设计 | 关注整体结构和职责分配 |
| 某个模块内部算法和数据结构怎么设计？ | 详细设计 | 关注模块内部实现逻辑 |
这条边界是后面系统设计、模块设计和测试题的基础。
可行性研究不只是技术可行
课堂提到可行性时列了多种维度：成本是否承担得起，社会、法律、文化是否允许，技术是否能实现。
| 维度 | 典型问题 |
|---|---|
| 技术可行性 | 当前技术、团队能力和平台条件能否实现 |
| 经济可行性 | 成本、收益、预算、投入产出是否合理 |
| 法律可行性 | 是否符合法律法规、合同和知识产权要求 |
| 社会/操作可行性 | 用户、组织、文化和流程是否能接受 |
例题
形成需求规格说明书的阶段通常是：
将系统划分为子系统和模块，并分配功能，属于：
项目立项前的可行性研究通常需要考虑：
自查要点
- 为什么生命周期不是所有项目都必须线性执行？
- 可行性研究至少应考虑哪些维度？
- 需求分析、概要设计、详细设计分别回答什么问题？
- 运行维护阶段包括哪些工作？
- 测试驱动开发为什么说明阶段顺序可以变化？