软件生命周期与过程模型

🏗️ 写程序和建大楼——有什么区别？

你写一个”计算器”程序——一个人花两天就写完了，中间没计划、不测试、改了几次界面，最后也跑起来了。

但如果要开发一个”校园教务管理系统”——几百个功能、几十个开发者、要跑十年不崩溃——还能这样干吗？

这就是软件开发中过程（Process） 的意义。就像盖楼不能不做设计就开工，开发大型软件也需要一套规范化的流程来保证质量、控制进度、管理变化。

🏪 类比：盖房子 vs 做小吃

做小吃（小项目）：你去摆摊卖煎饼——没有设计图、没有计划表、不需要测试。今天卖完收摊，明天再说。

盖大楼（大项目）：要建一座教学楼——先做地质勘探（需求分析）、画设计图（系统设计）、打地基（架构）、砌墙（编码）、验收（测试）……每一步都有规范文档。

软件工程就是”盖大楼”的方法论——让大型软件开发变得可预测、可管理、可控制。

---

📋 软件生命周期（SDLC）

软件生命周期（Software Development Life Cycle, SDLC） 是软件从”出生”到”退役”的完整过程。

通常分为六个阶段：

┌─────────┐    ┌────────┐    ┌────────┐    ┌────────┐    ┌────────┐    ┌────────┐
│ 需求分析  │──→│ 系统设计 │──→│ 编码实现 │──→│ 软件测试 │──→│ 部署上线 │──→│ 运行维护 │
│ (要做什么) │   │ (怎么做) │   │ (写代码) │   │ (验证)  │   │ (发布)  │   │ (修+改) │
└─────────┘    └────────┘    └────────┘    └────────┘    └────────┘    └────────┘
                                                                          │
                                                                          ↓
                                                                      退役

阶段	核心问题	产出物
需求分析	系统要做什么？	需求文档、原型图
系统设计	系统怎么做？	架构图、数据库设计
编码实现	写代码	可运行的软件
测试	做得对吗？	测试报告、缺陷列表
部署	怎么上线？	运行中的系统
维护	出问题怎么办？	补丁、新版本

---

🏛️ 过程模型——不同的”做事方式”

① 瀑布模型（Waterfall）——最传统的模式

思想：阶段严格按顺序推进，每个阶段完成后才能进入下一阶段——就像瀑布一样只向下流。

需求 → 设计 → 编码 → 测试 → 部署 → 维护
                                        ↑
     只能向前，不能回头（或很难回头）

# 瀑布模型的典型场景
# 1月：完成需求文档
# 3月：完成设计文档
# 6月：完成编码
# 8月：完成测试
# 9月：上线
# → 如果9月发现需求错了——前面8个月白干了

适用场景：

• 需求非常明确、几乎不会变化（如航天控制软件、银行核心系统）
• 项目规模大但技术成熟

问题：反馈周期太长——用户直到最后才能看到成果，如果需求错了代价巨大。

② V 模型（V-Model）——测试驱动的瀑布

思想：每个开发阶段都有对应的测试阶段——设计和测试对应。

需求分析 ──────── 验收测试
   │                  │
系统设计 ──────── 系统测试
   │                  │
详细设计 ──────── 集成测试
   │                  │
  编码 ────────── 单元测试

核心思想：测试不是最后才做的——开发的同时就在计划测试。

③ 敏捷开发（Agile）——当前最主流的方式

思想：不追求一次性把所有需求做完，而是小步快跑、迭代交付——每 2-4 周交付一个可用的版本。

迭代 1：登录功能 + 用户主页         → 第 2 周交付
迭代 2：搜索功能 + 商品列表         → 第 4 周交付
迭代 3：下单功能 + 支付流程         → 第 6 周交付
...

每个迭代都是"迷你瀑布"：设计→编码→测试→演示

敏捷和瀑布的关键区别：

瀑布：一次性做完所有 → 最后给用户看
敏捷：每次做一小部分 → 每两周给用户看 → 根据反馈调整

对比总结

维度	瀑布	敏捷
需求变化	尽量避免变化	拥抱变化
交付节奏	一次性交付	持续交付
用户参与	开始和结束才参与	全程参与
文档	详尽文档	”刚够用”的文档
风险	后期发现问题代价大	早期发现问题
适用	需求稳定、安全关键系统	需求变化快、互联网产品

💡 现实不是非此即彼：很多团队采用”混合模式”——需求稳定的部分用瀑布式规划，需求变化快的功能用敏捷迭代。找到适合自己团队的节奏比”选一个流派”更重要。

---

📝 小结

概念	一句话
SDLC（软件生命周期）	需求→设计→编码→测试→部署→维护
瀑布模型	阶段严格按顺序推进——像盖楼
V 模型	每个开发阶段有对应的测试阶段
敏捷开发	迭代增量、小步快跑——像做小吃逐步升级到餐厅
关键区别	瀑布一次性交付，敏捷持续交付和反馈

🎯 思考题：你写课程项目（比如一个学生选课系统）时，适合用瀑布还是敏捷？为什么？如果团队只有 2 个人、工期 3 个月呢？

为什么先学这个？ 了解了流程的整体框架后，深入学习目前最主流的开发方法——敏捷开发与 Scrum。