04 | 瀑布模型之外，还有哪些开发模型？
该思维导图由 AI 生成，仅供参考
快速开发快速改
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
软件开发过程模型是指在软件开发过程中，按照一定的规则和步骤进行软件开发的模式。本文介绍了瀑布模型、增量模型、迭代模型以及它们的衍生模型，分析了它们的适用场景和特点。瀑布模型适用于需求清晰、能模块化的软件系统，而增量模型和迭代模型则是将大瀑布拆成小瀑布，但拆分方式不同。文章还介绍了V模型、螺旋模型和统一软件开发过程（RUP）等模型，以及它们在不同项目场景下的应用。最后，强调了根据项目特点选择合适的开发模型的重要性，并提出了一些思考问题。总的来说，本文通过对不同软件开发过程模型的介绍和分析，为读者提供了选择合适开发模型的参考依据。
《软件工程之美》，新⼈⾸单¥59
全部留言(46)
- 最新
- 精选
纯洁的憎恶稳定、可靠、一步到位的瀑布模型，不太适用于违约风险大、需求不明确、快速见效的场景。 快速原型模型：不见兔子不撒鹰。期初不考虑质量、架构，用最快的速度见效，并向用户确认需求。经过几轮直观、快速的反馈，把需求确定下来。接下来，既可以抛弃原型用瀑布精密重构，也可以在模型基础上完善。优点是快速有效的确认需求。不足难以有效应对后续的需求变更。 增量模型：分而治之。将大系统横向拆分成相对独立的若干小模块，每个模块采用瀑布模式分批次交付。优点是较快见到成果，且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。 迭代模型：罗马不是一天建成。把软件项目纵向划分成若干阶段，从核心功能入手，逐渐深化、细化，直到满足用户的全部需求。每个阶段都是一个瀑布，都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要，并体会软件演进的快感。不足是需求演化具有不确定性，会导致代码冗余、系统重构风险、项目周期不可控。 我做甲方管过不少外包项目，大V模型再熟悉不过了。整个过程冗长繁琐，走流程比建软件更累心。而且等项目结束的时候，需求早就变得面目全非了。乙方只能硬着头皮做，不然连业绩都没有，真是血本无归。在增量或迭代模型的每次交付后都做一次风险评估，演进为螺旋模型，可以及时止损。 项目做成这样，更深远的原因是业务都是在摸着石头过河，需求不变更才怪呢。但每年几个亿的信息化预算还是非常诱人的，投标单位络绎不绝。RUB看起来不错，但需求快速演化会依然带来无法回避的系统重构压力，终归还要具体问题具体分析。作者回复: 总结的非常详细👍 你的这些分享相信对其他看这篇专栏的同学都非常有价值👍
2019-03-06384
库洛洛我是一个自由职业的freelancer，在我的开发历程中，最多的两个类型的客户，一种是山寨的直接拿了一个案例过来给你照着做，这种我会直接划分模块采用增量方法进行开发；还有一种是大致有一个想法，但没有明确需求，这种我会先出一个方案，将功能和客户的需求写下来，收取订金1，然后原型->修改->原型->修改的方法直至客户对他的想法有一个确认，对整个系统有一定了解，需求确认了我会再收取订金2，之后正式开发，选取框架，编码，测试，这样做有两个好处，一个是你的劳动可以分阶段收钱，一个是客户可以看到你的工作的付出，降低了客户和你的风险，双赢吧，如果到了某一阶段客户需要终止，也能即时止损了。作者回复: 赞，这样的做法确实不错，对客户来说可以不担心花了钱做不出来东西，对于你来说不担心做了收不到钱👍
2019-08-0422
KK_TTN快速原型模型和迭代模型感觉很像 都是先交付一个茅草屋 再根据反馈迭代 一步步迭代进化作者回复: 还是有些不一样，原型开发呢，基本上没什么设计，代码质量也不要求，甚至就是工具生成，就是为了怎么快确认需求怎么来。 而迭代模型则是控制需求范围，通过减少需求保证时间段速度快，不牺牲质量
2019-03-0215- 庄小P瀑布模型让我想起了我导师，经常和我们这样说，你想一下你十年后要成为什么人，然后倒退回来你现在研究生应该研究什么，再倒推回来需要补什么基础知识。
作者回复: 你们导师说的很有道理👍
2019-04-12214 - Felix在没听宝玉老师这篇文章之前，一直以为迭代模型就是敏捷(T﹏T)，期待下周二的文章
作者回复: 以前我也分不清楚：） 下周的敏捷开发文章会有针对两者的对比，希望能帮助你解惑
2019-03-0211 
AICC感觉迭代模型开发举的例子不是很贴切，显然从茅草屋到木屋到大别墅更像是快速模型中的抛弃模型，迭代模型我自己觉得更像是从一个毛坯房到室内装修再室外装修再加家具布置的精装过程哈哈哈哈作者回复: 确实，想通过类比的方式讲清楚确实有点难度。精装修的问题是，不是从头开发的，不涉及功能模块的开发，都是在修修补补：） 我们也不必过于纠结这些，毕竟例子只是辅助理解的，还有很多文字介绍，应该结合起来可以比较容易理解一点。从你的留言看明显是懂了的👍
2019-03-02210
javaadu如果已经有客户了，但是客户需求不明确，那么这种情况比较适合使用快速原型模型确定客户的需求，然后再根据抛弃策略或附加策略进入下一阶段的开发，由于后期需求可能会变化很大，在后续开发中适合使用迭代模型（企业内部的业务管理系统属于这种情况，例如滴滴打车系统、美团外卖系统等等）。 如果暂时没有客户，但是我对要解决的客户问题很熟悉（很多toB的公司属于这种情况），只是具体方案没想好（后期需求会变），可以直接上迭代模型，同时需要在每个迭代间做风险评估。作者回复: 💯 迭代模型的时候，一定要注意先上优先级高的需求、核心的需求。
2019-03-029
小先生快速原型模型：使用原型图即可，用于确认需求。 增量模型：按模块划分，进行开发。 迭代模型：所有功能都做，但是做得比较简陋，下一个版本再进行迭代升级。作者回复: 👍都总结在点上。 我再补充一点文章中可能没交代清楚的： 迭代模型在迭代时，不是简单什么功能都做，而是在每个迭代选择当前优先级最高的功能，最核心的功能。
2019-03-038
一路向北目前我们自己的项目基本上以迭代模型开发为主，几乎每周都会有一个升级的版本，主要是增加一些新的功能和修复前面版本的BUG。 对于一个需求不明确的项目，比较合适的步骤是： 第一，先做原型，和客户确认基本需求，来回几次之后基本上也就清楚客户6-7十的需求了。 第二，项目开发采用迭代模型，先给客户一个比较基础的版本，实现部分核心功能，给客户先用，客户在此基础上提出需求。 第三，迭代版本到一定的程度，如果软件的架构或者采用的技术不太合适，可以做一个重构，这时可以采用一个瀑布模式去做。 这里的关键是每个迭代周期需要设定实现的目标，实际过程中很难控制这个过程，因为即使做了一个短周期的迭代目标，客户的需求也会改变，这里是否有更好的方法？作者回复: 👍你的答案整理的很好。 如果没有直接客户，产品直接面向最终用户，这种可以跳过原型步骤。 有些大的重构和迭代可以并行做，重构的完了再把现有数据迁移过去 在一个迭代里面，正常情况下，是不会轻易接受需求变更的，会放到下一个迭代。如果必须要变，那就需要重新调整迭代目标了，但这样的情况不能出现太多，不然就失去迭代的意义了。
2019-03-027- alva_xu修改一下。对于第二点，系统架构要尽量避免或减少修改次数，但在需求不是很清晰的情况下，系统架构肯定会随着需求的迭代而迭代。为了减少系统架构修改而带来的大范围的系统变更，应该尽量采用稳定的可伸缩的可插拔的分层的充分解耦的系统架构。老师你看这样表述是不是更合适些？
作者回复: 表述没问题的。 我觉得关于架构设计可以看看这篇文章：《从0开始学架构-08 | 架构设计三原则》合适原则、简单原则、演化原则https://time.geekbang.org/column/article/7071 跟你总结的比较类似，非常有道理。
2019-03-025
