104. 软件工程的开发过程几种模型（瀑布模型、快速原型开发模型、增量模型、迭代模型、螺旋模型）

文章目录

• • 1.前言
  • 2.瀑布模型–按阶段严格完成
  • • （1）瀑布模型把整个项目过程分成了六个主要阶段：
    • （2）举个例子来理解瀑布模型
    • （3）优缺点
    • （4）解决的重要问题
  • 3.快速原型模型–低成本快速的确认需求
  • • （1）类比介绍
    • （2）抛弃策略
    • （3）附加策略
    • （4）原型设计工具
  • 4.增量模型–按模块分批次交付
  • • （1）类比介绍
    • （2）适用场景
  • 5.迭代模型——每次迭代都有一个可用的版本
  • 6.增量模型与迭代模型的区分
  • 7.我该选择什么过程模型/li>
  • • 场景一：外包项目，需要阶段验收
    • 场景二：项目风险高，随时可能会中断—螺旋模型
    • 场景三：山寨一款软件产品，希望能快速上线发布
    • 场景四：客户都没想清楚想要什么，但是个大单子
    • 场景五：我的产品已经上线，但是需要持续更新维护
  • 8.总结

1.前言

我们说；
那么本节内容就聊一聊,即软件从无到有的一个过程，它有很多种方法，这些方法被称为一个又一个模型。这些常见模型有：，还有，由于篇幅较长，下一篇笔记再总结。

2.瀑布模型–按阶段严格完成

• 可以这么说：。软件工程的很多内容，都是源自瀑布模型的衍生，或者其中某个阶段的细分。

（1）瀑布模型把整个项目过程分成了六个主要阶段：

（4）解决的重要问题

瀑布模型的出现，也解决了软件项目开发中的几个重要问题。

• 让软件开发过程有序可控。瀑布模型的每个阶段都有明确的任务，每个阶段都有明确的交付产物，都有相应的里程碑。这些让整个过程更可控，而且能及早发现问题。
• 让分工协作变成可能。瀑布模型的六个阶段，也让软件开发产生相应的基础分工：。
• 质量有保障。瀑布模型每个阶段都需要交付相应的文档，而文档的撰写和评审，可以帮助在动手之前把问题沟通清楚，想清楚。瀑布模型在编码结束后，会有严密的测试，只有测试验收通过后，才能上线发布。这些措施都让软件的质量更有保障。

3.快速原型模型–低成本快速的确认需求

（1）类比介绍

• 快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题。用于低成本快速的确认需求,没必要花太长时间在代码质量上，赶紧做出来才是王道

• 先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫。

• 这就好比客户想要盖房子，但是他没想好要盖成什么样子，于是施工方就先搭了一栋彩钢房（就像工地里面搭的临时房子），让客户先用起来，然后再给反馈调整。

• 因为彩钢房搭建简单快速，改起来也相对容易。等到客户确定好需求，再在已经搭好的彩钢房的基础上完善，或者直接重新按照确定好的需求造房子。

• 不过，这样做也有一个问题，，住的不算舒服，想有点个性化的风格也难。

• 同样的道理，也适用于软件项目。彩钢房就像是软件原型，重点是反映软件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但开发速度可以很快。

• 原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求。

• 但这种。

• 在原型开发过程中，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：。

（2）抛弃策略

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

（3）附加策略

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

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

（4）原型设计工具

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

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

4.增量模型–按模块分批次交付

（1）类比介绍

• 增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是。

• 盖卫生间的时候，也要先分析。有时候也可以多模块并行，例如同时盖卫生间和厨房，前提是模块之间不能有依赖关系，比如，你不可能先盖二楼再盖一楼。

• 在迭代模型中，整个项目被拆分成一系列小的迭代。通常一个迭代的时间都是固定的，不会太长，例如 2-4 周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。

• 在一个迭代中都会包括·，类似于一个小瀑布模型。迭代结束时要完成一个可以运行的交付版本。
  

  

  这个模型就是，只不过它是更重视对每个阶段验收测试的过程模型。

  场景二：项目风险高，随时可能会中断—螺旋模型

  如果你现在要做一个风险很高的项目，客户可能随时不给你钱了。这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了！

  这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险。你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。

  
  上面这种开发方式来源自

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

• 很多产品在上线后，还在保持不停的更新维护，修复 Bug、增加新功能，每个月甚至每周更新。

• 在这种情况下，·是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布。

• 另外还可以尝试，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度。

8.总结

• 现在的软件项目，各种类型都有，根据项目特点，选择好合适的开发模型，可以让你事半功倍，降低项目风险，提高项目开发效率，控制项目成本。比如说：

• 一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；

• 一个高风险的项目，则可以采用，出现问题及时止损；

• 一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。

• 同时，你也不必拘泥于这几种开发模型，还可以借鉴其他模型做的好的地方，甚至创造自己的开发模型，比如说你觉得敏捷的“站立会议”适合你的项目，那也可以借鉴过来。

参考：极客时间–软件工程之美

来源：BitHachi