软件开发模型

瀑布模型

• 瀑布模型算是现代软件工程的起源
• 软件工程的发展，很大部分都是构建于瀑布模型的基础之上

1、六阶段

瀑布模型在提出后，因为其简单可行，切实有效，马上就在很多软件项目中应用起来，一直到 2000 年前后，都是最主流的软件开发模型，即使到现在，你也能在很多软件项目中看到它的影子

也是从那时开始，有了“软件生命周期”(Software Life Cycle,SLC) 的概念

软件生命周期是软件的产生直到报废或停止使用的生命周期。而像瀑布模型这样，通过把整个软件生命周期划分为若干阶段来管理软件开发过程的方法，叫软件生命周期模型

2、案例

我们拿盖房子的过程来看看瀑布模型:

• 客户想要盖一栋房子（初步的想法）
• 客户一开始可能没想清楚想要什么样子的房子。（客户对需求还不清楚）
• 施工方开始找客户确认：用途是什么，要几层房子，什么建筑风格，什么时间完工，预算多少（问题定义）
• 施工方根据客户提的需求，对比工期和预算，评估是不是值得做（可行性研究）
• 施工方评估后觉得可行，于是和客户签订合同，约定价钱和工期（立项，制定项目计划）
• 施工方开始跟客户沟通确认需求，例如每层户型如何，将来的装修风格等（需求分析）
• 确认完需求后，施工方开始出建筑施工图，还画了漂亮的建筑效果图（系统设计和 UI 设计）
• 施工方按照设计图开始施工（程序编码）
• 这期间如果客户去参观施工情况，客户只能看到毛胚，只有最后施工完成才能看到最终样子（客户只有最后能看到结果）
• 原定二层是两个卧室，在房子施工过程中，突然客户说两个卧室不够，要改成三个卧室。这意味着施工方要对施工图重新设计，很多已经建好的房间要拆掉重建。（瀑布模型是很难响应需求变更的，而且越到后期代价越大）
• 工程质量检查人员对施工结果进行质量检测，如果不满足质量要求，需要修改（测试）
• 最后验收通过后，客户入住（上线）

3、优缺点

快速原型模型

快速原型模型：

• 就是为了要解决客户的需求不明确和需求多变的问题
• 用于低成本、快速的确认需求，对于代码质量不做要求，快速做出来才是王道

1、案例

• 先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型
• 这就好比客户想要盖房子，但是他没想好要盖成什么样子，于是施工方就先搭了一栋彩钢房（就像工地里面搭的临时房子），让客户先用起来，然后再给反馈调整
• 因为彩钢房搭建简单快速，改起来也相对容易。等到客户确定好需求，再在已经搭好的彩钢房的基础上完善，或者直接重新按照确定好的需求造房子
• 不过，这样做也有一个问题，用彩钢房这种方式盖房子虽然快，但是 房子质量不会太好，住的不算舒服，想有点个性化的风格也难
• 同样的道理，也适用于软件项目。彩钢房就像是软件原型，重点是反映软件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但开发速度可以很快
• 原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求
• 但这种快速原型开发往往是以牺牲质量为代价的
• 在原型开发过程中，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略

2、抛弃策略

• 抛弃策略是将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃
• 实际开发时，将重新开发所有功能。类似于用彩钢房盖房子，确认完客户需求后，拆掉重新建

3、附加策略

• 附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求
• 最终将原型变成交付客户的软件。类似于用彩钢房盖房子，最后还要做一番精装修，交付客户

采用哪种策略来应用原型模型，还是要看项目特点，包括所采用原型开发工具和技术的成熟度
举例来说，如果客户对可靠性、性能要求高，那么就最好是抛弃策略，如果客户对质量要求不高，有简单功能就够了，那么可以试试附加策略

4、原型设计工具

• 原型制作并不一定要像传统代码一样进行设计编码，有很多原型工具，像 Axure、墨刀等
• 简单的拖拽就可以实现简单的界面和交互，同样可以达到确认需求的目的

增量模型

瀑布模型的很多问题，根源都是周期太长
周期长所以中间难以响应变更
周期长所以客户很久才能看到结果
周期太长所以风险不好控制
如果能将周期变短，那么很多问题就迎刃而解了
基于这种思路，产生了很多开发模型，比较典型的主要是：·增量模型 和 迭代模型·。

1、案例

• 增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中
• 应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试
• 相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付
• 如果拿盖房子来比喻的话，就是先盖卫生间，然后盖厨房，再是卧室
• 盖卫生间的时候，也要先分析需求，然后设计，再实施，最后验收
• 有时候也可以多模块并行，例如同时盖卫生间和厨房
• 前提是模块之间不能有依赖关系，比如，你不可能先盖二楼再盖一楼
• 因为增量模型的根基是模块化，所以，如果系统不能模块化，那么将很难采用增量模型的模式来开发
• 另外，对模块的划分很抽象，这本身对于系统架构的水平是要求很高的

2、适用场景

• 增量模型主要适用于：
• 需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付

迭代模型

1、案例

• 迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能
• 每次设计和实现一个阶段叫做一个迭代
• 如果用迭代模型的方式盖房子
• 第一个迭代要先盖一个茅草屋，快速满足客户对房子的核心需求
• 第二个迭代再盖一个小木屋，比茅草房更大更舒适
• 第三个迭代再盖成一个豪华别墅，满足客户所有需求
• 你要注意，无论是造小木屋还是大别墅
• 整个过程都会像一个完整的项目一样，包括需求分析、设计、实现与测试验收
• 在迭代模型中，整个项目被拆分成一系列小的迭代
• 通常一个迭代的时间都是固定的，不会太长，例如 2-4 周
• 每次迭代只实现一部分功能，做能在这个周期内完成的功能
• 在一个迭代中都会包括·需求分析、设计、实现和测试，类似于一个小瀑布模型
• 迭代结束时要完成一个可以运行的交付版本

2、增量模型与迭代模型的差异

• 增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能
• 还是用盖房子来理解，增量模型则是先盖厨房，再是卧室，这样一个个模块来完成
• 而迭代模型则是先盖一个简单的茅草房，有简易的土灶和土床
• 然后再升级成小木屋，有更好的灶和更好的卧室，这样一步步迭代成最终的房子

敏捷开发

敏捷开发，基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度
在敏捷开发中，系统交付的周期称之为·冲刺（Sprint）
敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容
严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。有各种开发模型来实现敏捷开发，比如说·极限编程（Extreme Programming），看板（Kanban）和 Scrum

1、敏捷开发宣言

• 敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则
• 各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策

2、站立会议

• 敏捷开发中流行的站立会议，主要目的是为了保证团队成员充分的沟通，遇到困难可以及时寻求帮助
• 但是如果每天的站立会议流于形式，并不能起到有效的目的，则应该减少频度，甚至取消换成其他方式
• 要不要在你的项目开发中使用站立会议，判断的依据就在于这样做是不是符合敏捷的价值观和原则
• 也就是说，当你开发做决策的时候，遵守了敏捷开发的价值观和原则
• 不管你是不是用 Scrum 或者极限编程，那么都可以算是敏捷开发

3、如何敏捷

• 瀑布模型的典型问题就是周期长、发布烦、变更难，
• 敏捷开发就是快速迭代、持续集成、拥抱变化·

4、案例

• 客户想要盖一栋房子（初步的想法）
• 产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（用简单的用户故事代替繁重的需求文档）
• 施工人员根据用户故事和客户进一步沟通（客户合作高于合同谈判），然后对用户故事进行设计和实现
• 每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（大量采用自动化测试）
• 并且做好的用户故事可以随时被测试验收（随时发布，持续集成）
• 每个 Sprint 四个星期时间（时间盒子，迭代时间固定）
• 第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（每个 Sprint 会选择高优先级的用户故事），屋顶还在漏水（每个 Sprint 会定期发布，客户可以随时看到可用版本，即使还不完整）
• 第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（每个 Sprint 不仅完成用户故事，还会修复 Bug）
• 第三个 Sprint 升级成了小木屋，但是忘记加上窗户（敏捷推崇自动化测试，但可能会测试不完备）
• 第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（响应变化高于遵循计划）
• 第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（迭代过程中可能会导致质量不稳定）
• 第六个 Sprint，修复了下水道的问题，房子也装修好了（迭代中不断完善）
• 客户验收使用（上线）

用敏捷开发的方式：
不再像瀑布模型那样有严格的阶段划分，会在迭代中不断完善
不再写很多文档，而是和客户一起紧密合作
不再抵制需求变更，而是即时响应变更
不再等到测试阶段才发布，而是随时发布，客户随时可以看到东西
当然，采用敏捷开发的模式也存在一些问题
例如全程需要客户参与，由于测试相对少一些 ，问题也会相应多一些

5、敏捷开发和瀑布模型的差异

这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践
Scrum 主要用来管理·项目过程
极限编程重点在工程实践
而看板将工作流可视化
基于Scrum 和极限编程的实践，来对比一下敏捷开发模型和瀑布模型的差异

敏捷开发是怎么做需求分析的？

瀑布模型的一个重要阶段就是需求分析，要有严谨的需求分析，产生详尽的需求分析文档
而敏捷开发的需求，主要是来源于一个个小的用户故事，用户故事通常是写在卡片上的一句话
在 Sprint 的开发中，再去确认需求的细节
比如一个用户登录网站的需求，在用户故事里面就是一句话：
作为用户，我想登录网站，这样可以方便浏览
好处是减少了大量需求文档的撰写，可以早些进入开发
但这个对开发人员在需求理解和沟通的能力上要求更高了

敏捷开发是怎么做架构设计的？

瀑布模型在需求分析完了以后，就需要根据需求做架构设计
而在敏捷开发中，并不是基于完整的用户需求开发，每个 Sprint 只做一部分需求
所以是一种渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计
这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象
产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构

敏捷开发怎么保证项目质量的？

瀑布模型在编码完成后，会有专门的阶段进行测试，以保证质量
在敏捷开发的 Sprint 中，并没有专门的测试阶段，这就依赖于开发功能的同时
要编写单元测试和集成测试代码，用自动化的方式辅助完成测试
相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的
微软的 Windows 就是个很好的例子，在 Windows 10 之前，Windows 的开发模式是传统的类瀑布模型
有很长一段测试的时间，质量有很好的保障，Windows 10 开始，采用的是敏捷开发的模式
每月发布更新，稳定性要稍微差一些

敏捷开发是怎么发布部署的？

瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境，测试验收通过后，发布部署到生产环境
在敏捷开发中，这种持续构建、持续发布的概念叫持续集成
因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作
脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境
持续集成是一个非常好的实践，极大的缩短和简化了部署的流程
而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求

敏捷开发的 Sprint 和迭代模型的迭代有什么区别？

我们假设有两个团队，都要实现一个简单的用户系统，
一个团队用迭代模型，一个团队用敏捷开发（Scrum），一个迭代 /Sprint 的时间周期都是 2 周（10 个工作日）
迭代模型所在的团队，产品经理会先花 2 天时间去分析需求，写成需求分析文档，架构师会花 3 天时间来做设计
程序员会花 3 天时间编码，测试再花 2 天时间去测试，最后上线用户系统
再看敏捷开发的团队，Product Owner（类似于产品经理）会把需求拆分成了几个简单的用户故事：
用户登录、用户注册、找回密码、修改资料，然后放到当前 Sprint 的 Backlog（任务清单）
Team（开发团队）成员开始从 Backlog 选择用户故事
程序员 A 选了“用户登录”这个用户故事，他会去找 Product Owner 确认需求细节，之后动手实现这个用户故事
功能完成后，同时程序员 A 还写了单元测试代码和集成测试代码，对登录的功能写了自动化测试
完成后，通过持续集成工具测试和部署到测试环境。部署完成后，用户登录功能就可以进行使用了
这个过程，程序员 A 可能花了 4 天时间，做完“用户登录”这个用户故事之后
他又开始继续选取“找回密码”的用户故事来做，4 天时间也完成了
其他程序员也和程序员 A 一样，他们也会从 Backlog 选择一些用户故事来做
当团队中第 1 个用户故事部署完之后，测试人员就开始帮助测试，发现的 Bug 都提交到了 Backlog
程序员们在完成用户故事后，开始着手修复这些 Bug，正好在最后 2 天都修复完成
从上面的例子，你可以看出，迭代模型本质上是一个小瀑布模型，所以在一个迭代里面
需要完整的经历从需求分析，到设计、编码、测试这几个完整的阶段
所以像瀑布模型一样，刚开始测试的时候是不稳定的，到测试后期才逐步稳定下来
一般迭代前期也会相对轻松一点，而后期测试阶段可能会时间很紧张
敏捷开发的 Sprint 中，没有严格的阶段划分，每个 Sprint 周期里面会完成多个用户故事
在用户故事的开发时，会针对用户故事有编码、自动化测试编码
当一个用户故事开发完成，即可通过持续集成自动发布到测试环境
相对来收，敏捷开发中，整个 Sprint 的节奏是比较恒定，产品也是相对稳定的
即使用户故事没有完成，也不影响版本的发布
因此，敏捷开发更注重软件开发中人的作用，需要团队成员以及客户之间的紧密协作

该不该选择敏捷开发？

这些年，软件工程中一些好的实践，像持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发
可以肯定，敏捷开发是一种非常好的软件开发模式
但在应用上，也确实需要满足一些条件才能用好，例如：
团队要小，人数超过一定规模就要分拆
团队成员之间要紧密协作，客户也要自始至终深度配合
领导们得支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性
写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境
所以在选择敏捷开发这个问题上，你先要参考上面这些条件
因为敏捷开发对项目成员综合素质要求更高，做计划要相对难一些
如果团队大、客户不配合、领导不支持，再好的敏捷方法也很难有效实践起来
如果你要实践敏捷开发，建议先找个小项目进行试点，能证明可行了，再进一步推广
有条件的话，可以和一些顾问公司合作，请人做专门的培训和指导
如果不具备条件，应该考虑先把其中一些好的实践用起来，比如说持续集成、每日站会、自动化测试等

如何选择模型

除了上面提到的这几种模型，还有很多其他开发模型，要记住所有的开发模型很难
你搞透了瀑布模型，搞清楚了其阶段划分，结合一些应用场景，你就可以举一反三，了解绝大部分衍生模型
我在这里给你列举几个常见的项目场景，我们可以一起来分析下，看看用什么模型适合

场景一：外包项目，需要阶段验收

• 假如你现在是一家外包公司，你可以采用瀑布模型开发
• 但是甲方需要对你项目的每个阶段进行验收测试，以确认你是不是达到要求
• 针对从需求定义一直到编码阶段，每个阶段都有对应的测试验收
• 如果画成图，就是下面这个样子的
  
• 这个模型就是V模型，本质上它还是瀑布模型
• 只不过它是更重视对每个阶段验收测试的过程模型

场景二：项目风险高，随时可能会中断

• 如果你现在要做一个风险很高的项目，客户可能随时不给你钱了
• 这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了
• 这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险
• 你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损
• 这种强调风险，以风险驱动的方式完善项目的开发模型就是螺旋模型

场景三：山寨一款软件产品，希望能快速上线发布

• 其实软件行业山寨的案例不少，山寨项目的特点是，项目需求是明确的，不会有什么变化
• 这时候就可以选择增量模型，划分好模块，先实现核心模块
• 发布可运行版本，再增量发布其他模块。多模块可以同步开发

场景四：客户都没想清楚想要什么，但是个大单子

• 很多项目，客户一开始都没想清楚想要的是什么，需要花很长时间去分析定义需求
• 但是单子很大，值得认真去做好。那么这样的项目，你可以考虑拆分成四个阶段：

1.初始阶段

• 主要是确定需求边界和主要风险，几乎没有什么开发工作

2.细化阶段

• 这个阶段主要是确定需求，可以采用快速原型模型开发，和客户对需求反复确认，需要辅助一定量的开发和测试工作
• 对代码质量可以要求比较低，重点是确认需求。可能需要一个或多个版本迭代

3.构造阶段

• 在需求确认清楚后，现在可以使用迭代模型来开发，逐步交付产品
• 这个阶段的重点是开发和测试。如果迭代中，有新的需求加入或者需求变更，也可以在新的迭代中加入

4.交付阶段

• 在开发和测试完成后，产品可以交付客户，根据线上运行情况还需要修复一些 Bug
• 这个阶段重点是测试和部署。也会有多个迭代

整个过程看起来就像下图这样

上面这种开发方式来源自统一软件开发过程（Rational Unified Process，RUP），适用于复杂和需求不明确的软件系统。

场景五：我的产品已经上线，但是需要持续更新维护

• 很多产品在上线后，还在保持不停的更新维护，修复 Bug、增加新功能，每个月甚至每周更新
• 在这种情况下，迭代模型是比较合适的
• 固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布
• 另外还可以尝试敏捷开发，也是基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度