web

软件生命周期与过程模型概览

第 2 章 · 软件工程

先看两个团队。 A 团队接了一个大项目：先把需求文档写满一百页，再花三个月做设计、三个月开发、两个月测试，最后一次性上线。结果上线前客户说「我们想法变了」，改需求要动架构，成本暴增。B 团队接的是同类项目，但每两周交付一小块可用功能：先做「登录 + 一个核心流程」，给客户看、收集反馈，再接着做下一块。需求在变，他们也在变，最后交付时和客户预期高度一致。差别不在谁更努力，而在选的过程模型不同——前者像「瀑布」，一泻到底才见水；后者像「敏捷」，小步快跑、边做边调。本章带你看清从需求到退役的全生命周期，再认识瀑布、迭代、增量、螺旋等传统模型，以及敏捷与精益为何兴起；最后说说如何根据项目特点选对过程。

一、从需求到退役：全生命周期

软件从「有一个想法」到「没人再用了」会经历一系列阶段，合起来叫软件生命周期。不同模型会对这些阶段做不同的排列与重复，但阶段本身大致包括：需求、设计、实现、测试、部署、运维、退役。

全生命周期：需求 → 设计 → 实现 → 测试 → 部署 → 运维 → 退役（实际中常有迭代与回溯）

不同过程模型的区别，就在于：这些阶段是严格顺序走一遍（瀑布），还是分多轮重复（迭代），还是按块交付、每块都走一遍（增量），或是按风险驱动、每轮评估再决定下一步（螺旋）；以及后来兴起的敏捷 / 精益，把周期压短、强调反馈与适应。下面逐一概览。

二、传统过程模型：瀑布、迭代、增量、螺旋

1. 瀑布模型（Waterfall）

瀑布模型把生命周期排成严格顺序：先做完需求，再进入设计；设计全部完成后再实现；实现完成后再测试；测试通过后再部署。像水从高处一阶一阶流下来，不能倒流（理论上）。

瀑布模型：阶段依次进行，一般不回溯（实际中常有返工）

优点：阶段清晰、文档完整、适合需求稳定、合同按阶段验收的项目。缺点：需求变更成本高、用户要到很晚才能看到成品、风险往往在后期才暴露。适合需求明确、变更少的项目（如军工、航天、部分政府系统）。

2. 迭代模型（Iterative）

不要求「一次把需求全做完再设计再实现」，而是多轮迭代：每一轮都包含分析、设计、实现、测试，但每轮只针对一部分需求或一个版本目标。每轮结束会有一个可运行的结果，用于演示或内部验证，再根据反馈决定下一轮做什么。

迭代模型：每轮都经历「需求→设计→实现→测试」，多轮逼近完整产品

优点：早出可运行版本、风险分散、能根据反馈调整。缺点：若每轮范围控制不好，可能重复劳动或架构漂移。适合需求会逐步明晰、希望尽早看到成果的项目。

3. 增量模型（Incremental）

把产品拆成多个增量，每个增量都是「从需求到交付」走完一遍，但每次只交付一部分功能。用户先拿到增量 1（例如只有登录和首页），再拿到增量 2（加订单），再拿到增量 3（加支付）…… 和迭代的区别在于：迭代可能每轮都改同一块、不断精修；增量更强调「一块一块往上叠」，每块相对完整、可单独交付。

增量模型：按块交付，每块都经历完整生命周期，逐步叠加功能

优点：用户能尽早用上部分功能、价值分批释放、单次交付范围可控。缺点：若架构设计不当，后期增量可能牵一发动全身。适合可以自然拆成「模块/功能块」的产品。

4. 螺旋模型（Spiral）

螺旋模型把开发看成一圈一圈向外扩的螺旋，每一圈包含四类活动：确定目标与方案、风险分析、开发与验证、计划下一轮。特别强调风险：每轮先评估技术风险、需求风险，再决定本轮做多少、怎么验证。适合大型、高风险、需求与技术都不完全确定的项目。

螺旋模型：风险驱动，每轮都做目标设定、风险分析、开发验证与下一轮计划

下面用一张总览卡帮你快速对比四种传统模型：

瀑布
阶段严格顺序，一次到底；适合需求稳定、变更少。
迭代
多轮「需求→设计→实现→测试」，每轮产出可运行版本。
增量
按块交付，每块完整走生命周期，功能逐步叠加。
螺旋
风险驱动，每轮：目标→风险分析→开发验证→计划。
四种传统过程模型对比

三、敏捷与精益的兴起

传统模型（尤其瀑布）在需求多变、市场节奏快的环境下暴露出问题：交付太晚、变更成本高、反馈滞后。2001 年《敏捷宣言》提出「个体与互动高于流程与工具」「可工作的软件高于详尽的文档」「客户协作高于合同谈判」「响应变化高于遵循计划」，并衍生出 Scrum、Kanban、XP 等实践。核心思想可以概括为：短周期、小步交付、持续反馈、拥抱变化。

传统（如瀑布）
  • 长周期、阶段分明
  • 前期重文档、后期才见软件
  • 变更成本高、计划驱动
敏捷 / 精益
  • 短周期（Sprint/迭代）、小步交付
  • 可工作软件优先、文档够用即可
  • 拥抱变化、反馈驱动

精益（Lean）源自制造业：消除浪费、缩短周期、持续改进。应用到软件里就是：减少半成品（未上线代码）、减少等待与返工、让价值流顺畅。看板（Kanban）就是典型的精益实践：可视化工作流、限制在制品（WIP）、按节奏拉动。敏捷和精益常一起用：敏捷偏「怎么迭代、怎么协作」，精益偏「怎么流动、怎么少浪费」。

敏捷典型节奏：Sprint 内「计划 → 开发 → 评审 → 回顾」，周而复始

四、如何根据项目特点选择过程

没有一种模型适合所有项目。选型时可以看：需求是否稳定、团队规模与分布、合同与验收方式、风险与不确定性、是否强合规等。下面给一个简表，帮助你在心里有个谱（实际中往往是混合或裁剪）。

项目特点 更合适的倾向
需求明确、变更少、合同按阶段验收 瀑布或近似瀑布（阶段清晰、文档完整）
需求会逐步明晰、希望早见成果 迭代、增量或敏捷
高风险、技术或需求不确定 螺旋（强调风险分析）或敏捷（小步试错）
市场节奏快、要快速试错与上线 敏捷、精益、短周期交付
强合规、审计要求高（如金融、医疗） 保留阶段与文档，再结合迭代或增量
分布式团队、多外包协作 接口与契约清晰；敏捷需配套沟通与工具
根据项目特点选择过程（实际中常需混合或裁剪）

一句话： 过程模型没有银弹。需求稳、重文档与合规可偏瀑布或阶段式；需求变、要快反馈可偏迭代、增量或敏捷；风险大、不确定高可引入螺旋或敏捷的小步验证。很多团队实际用的是「混合」：例如阶段上保留需求与设计评审，实现与测试用短迭代或 Scrum。

小贴士： 学完本章，可以对照你手头的项目（或假想项目）问一句：我们更接近哪种模型？需求变多还是变少？若改成两周一交付、每次只做一小块功能，可行吗？这样能很快把「概念」和「现实」对上号。

五、小结

软件全生命周期包括需求、设计、实现、测试、部署、运维、退役。传统过程模型中：瀑布阶段严格顺序；迭代多轮「需求→设计→实现→测试」；增量按块交付、功能叠加；螺旋风险驱动、每轮含目标与风险分析。敏捷与精益强调短周期、小步交付、持续反馈与拥抱变化。选过程时要看需求稳定性、团队与合同、风险与合规，实践中常需混合或裁剪。下一章我们会讲从个人编程到工程化思维——个人开发与团队交付的差异，以及可读性、可测试性、可维护性和协作习惯。