软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6731 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

04 | 瀑布模型之外,还有哪些开发模型?

宝玉 2019-03-02
你好,我是宝玉,我今天分享的主题是:瀑布模型的衍生模型都有哪些,你该如何选择?
在上一篇文章中,我重点介绍了瀑布模型。你现在知道了,瀑布模型简单易行,对于软件质量是有比较高保障的。但是瀑布模型对于前期需求不明确的项目,很难开展需求分析,后续如果有需求变更,瀑布模型便很难响应。
而且,每个软件项目的情况各不相同,都有自己的特点。比如说:
有的项目风险很高,客户可能随时不给你钱了,得要做好准备,随时止损;
有的项目客户自己没想清楚要想的是什么,做出来后再提各种修改意见,必须得想办法降低变更成本;
有的项目客户希望能很快就能上线。
如果选用瀑布模型做这些项目,就会导致成本过高或者周期过长等问题出现。所以,并不是所有的项目都适合使用瀑布开发模型,你需要针对不同的情况做一些调整。
实际上,为了应对瀑布模型的不足,已经衍生出了很多其他的开发模型。今天,我将为你分享一些有代表性的瀑布模型的衍生模型,你可以了解到这些衍生模型的本质,在接手不同类型的项目时,可以灵活地进行选择。

快速开发快速改

快速原型模型
我刚毕业时参加了一个项目的开发,项目经理跟我说,这个项目怎么快就怎么写,不要在意代码质量、架构、性能这些,当时我表示很不能理解,哪有这样做项目的?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(33)

  • 纯洁的憎恶
    稳定、可靠、一步到位的瀑布模型,不太适用于违约风险大、需求不明确、快速见效的场景。

    快速原型模型:不见兔子不撒鹰。期初不考虑质量、架构,用最快的速度见效,并向用户确认需求。经过几轮直观、快速的反馈,把需求确定下来。接下来,既可以抛弃原型用瀑布精密重构,也可以在模型基础上完善。优点是快速有效的确认需求。不足难以有效应对后续的需求变更。

    增量模型:分而治之。将大系统横向拆分成相对独立的若干小模块,每个模块采用瀑布模式分批次交付。优点是较快见到成果,且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。

    迭代模型:罗马不是一天建成。把软件项目纵向划分成若干阶段,从核心功能入手,逐渐深化、细化,直到满足用户的全部需求。每个阶段都是一个瀑布,都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要,并体会软件演进的快感。不足是需求演化具有不确定性,会导致代码冗余、系统重构风险、项目周期不可控。

    我做甲方管过不少外包项目,大V模型再熟悉不过了。整个过程冗长繁琐,走流程比建软件更累心。而且等项目结束的时候,需求早就变得面目全非了。乙方只能硬着头皮做,不然连业绩都没有,真是血本无归。在增量或迭代模型的每次交付后都做一次风险评估,演进为螺旋模型,可以及时止损。

    项目做成这样,更深远的原因是业务都是在摸着石头过河,需求不变更才怪呢。但每年几个亿的信息化预算还是非常诱人的,投标单位络绎不绝。RUB看起来不错,但需求快速演化会依然带来无法回避的系统重构压力,终归还要具体问题具体分析。

    作者回复: 总结的非常详细👍

    你的这些分享相信对其他看这篇专栏的同学都非常有价值👍

    2019-03-06
    1
    36
  • Felix
    在没听宝玉老师这篇文章之前,一直以为迭代模型就是敏捷(T﹏T),期待下周二的文章

    作者回复: 以前我也分不清楚:)
    下周的敏捷开发文章会有针对两者的对比,希望能帮助你解惑

    2019-03-02
    8
  • tangkangkai
    快速原型模型和迭代模型感觉很像 都是先交付一个茅草屋 再根据反馈迭代 一步步迭代进化

    作者回复: 还是有些不一样,原型开发呢,基本上没什么设计,代码质量也不要求,甚至就是工具生成,就是为了怎么快确认需求怎么来。

    而迭代模型则是控制需求范围,通过减少需求保证时间段速度快,不牺牲质量

    2019-03-02
    8
  • AICC
    感觉迭代模型开发举的例子不是很贴切,显然从茅草屋到木屋到大别墅更像是快速模型中的抛弃模型,迭代模型我自己觉得更像是从一个毛坯房到室内装修再室外装修再加家具布置的精装过程哈哈哈哈

    作者回复: 确实,想通过类比的方式讲清楚确实有点难度。精装修的问题是,不是从头开发的,不涉及功能模块的开发,都是在修修补补:)

    我们也不必过于纠结这些,毕竟例子只是辅助理解的,还有很多文字介绍,应该结合起来可以比较容易理解一点。从你的留言看明显是懂了的👍

    2019-03-02
    7
  • 小先生
    快速原型模型:使用原型图即可,用于确认需求。
    增量模型:按模块划分,进行开发。
    迭代模型:所有功能都做,但是做得比较简陋,下一个版本再进行迭代升级。

    作者回复: 👍都总结在点上。

    我再补充一点文章中可能没交代清楚的:
    迭代模型在迭代时,不是简单什么功能都做,而是在每个迭代选择当前优先级最高的功能,最核心的功能。

    2019-03-03
    4
  • alva_xu
    修改一下。对于第二点,系统架构要尽量避免或减少修改次数,但在需求不是很清晰的情况下,系统架构肯定会随着需求的迭代而迭代。为了减少系统架构修改而带来的大范围的系统变更,应该尽量采用稳定的可伸缩的可插拔的分层的充分解耦的系统架构。老师你看这样表述是不是更合适些?

    作者回复: 表述没问题的。
    我觉得关于架构设计可以看看这篇文章:《从0开始学架构-08 | 架构设计三原则》合适原则、简单原则、演化原则https://time.geekbang.org/column/article/7071

    跟你总结的比较类似,非常有道理。

    2019-03-02
    4
  • 一路向北
    目前我们自己的项目基本上以迭代模型开发为主,几乎每周都会有一个升级的版本,主要是增加一些新的功能和修复前面版本的BUG。
    对于一个需求不明确的项目,比较合适的步骤是:
    第一,先做原型,和客户确认基本需求,来回几次之后基本上也就清楚客户6-7十的需求了。
    第二,项目开发采用迭代模型,先给客户一个比较基础的版本,实现部分核心功能,给客户先用,客户在此基础上提出需求。
    第三,迭代版本到一定的程度,如果软件的架构或者采用的技术不太合适,可以做一个重构,这时可以采用一个瀑布模式去做。

    这里的关键是每个迭代周期需要设定实现的目标,实际过程中很难控制这个过程,因为即使做了一个短周期的迭代目标,客户的需求也会改变,这里是否有更好的方法?

    作者回复: 👍你的答案整理的很好。

    如果没有直接客户,产品直接面向最终用户,这种可以跳过原型步骤。

    有些大的重构和迭代可以并行做,重构的完了再把现有数据迁移过去

    在一个迭代里面,正常情况下,是不会轻易接受需求变更的,会放到下一个迭代。如果必须要变,那就需要重新调整迭代目标了,但这样的情况不能出现太多,不然就失去迭代的意义了。

    2019-03-02
    4
  • 林云
    文中提出可以借鉴软件开发模型中的特点,这一点并不是普通软件开发成员可以使用的。任何一个软件开发模式都有对应的主要问题。就像你把飞机的引擎放在拖拉机上一样。需要对模型进行总体考虑。而且不同的软件开发模式都有对交付团队有能力的要求。举个不恰当的例子,组合软件开发模式的特点就像让一个摩托车驾驶员开着安装了飞机引擎的拖拉机。这并不是软件工程想达到的结果。希望作者对组合研发模式的前提和应用过程进行描述以减少软件工程方法使用的随意性。

    作者回复: 🤝谢谢指正,结合最近波音747Max的案例,确实不能乱用,不能说飞机的软件也用敏捷这种快速上线快速迭代的模式。

    我觉得组合研发模式的前提还是质量,软件工程的目标就是要构建和维护高质量的软件,无论怎么组合开发模式,都不能牺牲质量。

    这里我也列一些我觉得好的实践:
    1. 瀑布模型可以参考敏捷开发,引入持续集成、自动化测试,提升效率
    2. 敏捷开发可以参考瀑布模型,开发前多设计,开发后多测试,尤其是要辅助人工测试

    2019-03-13
    3
  • 老张
    需求不明确是经常发生的,要根据项目情况分析迭代还是增量模型。
           一般来说,功能相对独立的项目更适合增量,比如管理信息系统,而单目标的系统更适合迭代,比如游戏、功能性软件(专家系统)。
            其实这两种模式是经常混用的,因为项目中常常在分别有这两种情况出现。
            另外,前后端分离式的开发模式其实也应该算一种开发模式,也就是前端工程师设计了全部交互,后端大部分代码自动化生成,核心架构才由后端工程师负责。

    作者回复: 👍是的,要根据实际情况选择。

    至于前后端分离,算一种开发模式也说的过去。我个人觉得也算增量的一种,按模块划分,类似的还有按服务划分。

    2019-03-08
    3
  • javaadu
    如果已经有客户了,但是客户需求不明确,那么这种情况比较适合使用快速原型模型确定客户的需求,然后再根据抛弃策略或附加策略进入下一阶段的开发,由于后期需求可能会变化很大,在后续开发中适合使用迭代模型(企业内部的业务管理系统属于这种情况,例如滴滴打车系统、美团外卖系统等等)。

    如果暂时没有客户,但是我对要解决的客户问题很熟悉(很多toB的公司属于这种情况),只是具体方案没想好(后期需求会变),可以直接上迭代模型,同时需要在每个迭代间做风险评估。

    作者回复: 💯

    迭代模型的时候,一定要注意先上优先级高的需求、核心的需求。

    2019-03-02
    3
  • 西西弗与卡夫卡
    当前不够明确、后期可能有较大变化的需求,准确说首先要考虑的不是用哪种开发方法,而是最好避免一开始就投入开发资源。开发的代价非常高,推倒重新开发的代价更高。最好是先想别的办法,验证需求是否真实存在之后再动手写代码

    作者回复: 👍是的,需求不明确导致的返工会造成很大浪费。

    建议还可以思考下:如何验证?是全都验证还是先验证一部分?

    2019-03-02
    3
  • fei
    宝玉老师,我想了想我最近做的一个系统,是对数据进行分析处理,计算每个任务阶段消耗的时间,整个业务流程共6大块,每块又分为5-15的小阶段,每个小阶段可能又有0-20个更小的粒度,
    第一期先完成先对数据清洗处理后,计算6大块任务阶段每部分的耗时,将数据给经理展示看看能不能定位出每个任务主要耗时的任务阶段,如果效果能达到预期,进行第二期
    第二期就是第二层粒度的数据,将任务耗时更加精细化
    第三阶段考虑汇总所有数据、看看能不能找到一些规律,用一些折线图,饼状图等展示出来,提高指导产品的用户体验
    我想了想,我每期提供一个可运行的版本、并且版本没有扔,每个版本有设计,文档,编码,测试流程,所以是典型的迭代融合瀑布模型吧。

    作者回复: 👍是的,应该就是迭代模型,整个项目变成了若干小的周期,每个项目周期就是一个瀑布模型。

    另外不用纠结于是哪种模型,更多的是去看看这些模型哪些是有你可以借鉴的地方,看有什么是可以帮助你改进优化项目流程的。

    比如说迭代模型,它的发布周期通常是固定的,一个周期到了,小瀑布要走完要发布小版本,这样可以避免延期,倒逼着你优先选取核心的功能。

    2019-09-09
    2
  • 库洛洛
    我是一个自由职业的freelancer,在我的开发历程中,最多的两个类型的客户,一种是山寨的直接拿了一个案例过来给你照着做,这种我会直接划分模块采用增量方法进行开发;还有一种是大致有一个想法,但没有明确需求,这种我会先出一个方案,将功能和客户的需求写下来,收取订金1,然后原型->修改->原型->修改的方法直至客户对他的想法有一个确认,对整个系统有一定了解,需求确认了我会再收取订金2,之后正式开发,选取框架,编码,测试,这样做有两个好处,一个是你的劳动可以分阶段收钱,一个是客户可以看到你的工作的付出,降低了客户和你的风险,双赢吧,如果到了某一阶段客户需要终止,也能即时止损了。

    作者回复: 赞,这样的做法确实不错,对客户来说可以不担心花了钱做不出来东西,对于你来说不担心做了收不到钱👍

    2019-08-04
    2
  • dave
    老师讲的非常好,请问老师的图是用什么工具画的?谢谢

    作者回复: Keynote画的,另外还有OmniGraffle

    2019-04-25
    1
    2
  • 庄小P
    瀑布模型让我想起了我导师,经常和我们这样说,你想一下你十年后要成为什么人,然后倒退回来你现在研究生应该研究什么,再倒推回来需要补什么基础知识。

    作者回复: 你们导师说的很有道理👍

    2019-04-12
    2
  • Joey
    老师,您好!

        认认真真看了之前每一篇文章以及所有留言讨论,
        发现每个公司\团队的情况不尽相同,所以对于这些开发模型,没有哪个是最好的,只有选择最适合自己的就是最好的。
        
        另外,我们公司是比较大的国企(多个业务部门对一个开发部门),对质量要求较高,现在业务条线也比较多,业务部门基本都嫌我们开发部门效率低,
        对于我们研发部门,组织架构还是按照瀑布模型设计的,开发模型基本是迭代+增量,

        如果想推行敏捷,肯定需要调整组织架构,一旦调整,就会触发一些利益关系,
        请教老师,在在这种背景下,有没有什么好的招数,既可以提高研发效率,又可以保证质量?谢谢老师解答

    作者回复: 如果你想推行敏捷,可以先找个小项目,组个小团队试点,成了可以作为一个参考,领导可以去邀功,以后可以更大规模尝试;失败了也损失不大,领导也不用担责任。

    不管用不用敏捷开发,你都可以学习其中好的实践,例如持续集成用起来,帮助你高效的集成部署;自动化测试代码写起来,帮助你提高项目质量;迭代快起来,以前3个月变成1个月,以前1个月的变2周。有些事情即使只是程序员都是可控范围内的,做着做着其实你就“敏捷”起来了。

    2019-03-03
    2
  • alva_xu
    对于增量或迭代开发,大型企业需要考虑这些不适应点:
    (1)大型官僚机构的办事程序和敏捷过程不匹配
    比如开发想敏捷,但财务采购等都不敏捷。代码敏捷了,基础环境不敏捷等
    (2)伴随增量的添加,系统结构会逐渐退化。
    特别是对于大型系统,其系统结构的建设,就需要提前制定计划,而不是增量开发
    (3)与开发方的合同问题,需要新形式的合同
    旧形式的合同是固定合同,做多少事拿多少钱都在合同时谈好了,不适应工作量的变更。

    作者回复: 👍是的,要敏捷起来,组织架构、流程制度也必须要跟着调整,光喊口号做样子是没用的。

    2019-03-02
    2
  • 一步
    那么最小可行性产品MVP应该就是迭代开发了?

    作者回复: MVP更多的是需求定义上的概念,和开发模型并没有关系。

    但是你使用迭代开发或者敏捷开发,必然要优先选择最核心最重要的功能需求先开发。

    所以通常MVP的方式选择核心需求,用迭代模型或敏捷开发开发需求。

    2019-03-02
    2
  • 一年
    按照这个道理,开发一款测试市场反应的产品,也应该使用快速原型模型是不是好点呢老师

    作者回复: 恐怕不行,因为快速原型模型是牺牲质量的。质量差的软件,去测试市场,你不知道是因为质量问题不行还是需求没抓住不行:)

    这种情况,可以考虑用迭代模型,先开发核心需求,然后再逐步迭代。

    2019-03-02
    2
  • 小伟
    我们组正在做系统的重构,属于平台系统,功能需求相对很明确,架构师从业务模型上给拆分成三个子系统,规定好系统间的协议后,同时对三个子系统重构设计开发,我理解这个属于增量开发模型吧?

    作者回复: 👍对,增量模型就是需求很明确,可以划分成几个模块,然后按照模块分别应用瀑布模型开发,而且多个模块可以并行开发。

    2019-03-02
    2
收起评论
33
返回
顶部