软件开发模型

一、简介

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

开发模型分为 11 种，分别有边做边改模型，瀑布模型，快速原型模型，增量模型，迭代模型，螺旋模型，敏捷开发，演化模型，喷泉模型，智能模型，混合模型。

二、常用模型

（一） 敏捷开发模型

1. 简介

敏捷开发（Agile Development）是一种以人为核心，迭代，循序渐进的开发方式。就是把一个大型项目分为多个可独立运行的小项目，并分别完成，在此过程中，软件处于可使用状态。

首先，我们要理解它不是一门技术，它是一种开发方法，也是一种软件开发流程，他会指导我们用规定的环节一步一步完成项目的开发；而这种开发方式的主要驱动核心是人。

2. 为什么要说是以人为核心？

瀑布开发模型，是以文档为驱动（因为在瀑布的整个开发过程中，要写大量文档，把需求文档写出来之后，开发人员都是根据文档进行开发，一切以文档为依据）而敏捷开发只写有必要的文档，或尽量少些文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

3. 敏捷开发的流程

以抖音为例，在需求分析阶段，先收集用户的需求：市场上目前缺少短视频的 APP，同时，有了今日头条的成功，能不能沿用它的设计思路，将展现形式由文字转变为短视频，通过标签推荐的算法，向用户推送他可能感兴趣的短视频呢？基于这样的需求，形成需求文档，接下来，产品经理拉着团队里开发、测试、设计一起做需求评审。

除了开发根据需求文档做开发计划之外，与此同时，测试人员由于更早的介入到软件项目当中，也可以根据需求文档开始编写测试计划了，形成测试计划之后，开始着手测试用例的设计与开发。

4. 敏捷开发核心思想

（1）强调面对面沟通，人和人相互交流胜任于任何流程工具；
（2）把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，强调了原型，模型等重要性；
（3）团队合作以及团队激励，合作胜于谈判，敏捷开发能将需求，开发，测试等全部团队成员融合成一个整体，大家团结协作；
（4）超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速。

5. 关于 Scrum 和 XP

前面说敏捷开发他是一种指导思想或者开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而 Scrum 和 XP 就是敏捷开发具体方式。Scrum偏重于过程，XP 偏重于实践，但实际中，两者是结合在一起使用的。

（1）什么是 Scrum？
Scrum 的英文意思是橄榄球运动的一个专业术语，表示“争球“的动作。把一个开发流程的名字取名为 Scrum，就好比团队在开发一个项目，大家像打橄榄球一样迅速，富有战斗的激情，你争我抢的完成。Scrum 就是这样的一个开发流程，运用这个流程，可以看到团队高效的工作。

（2）Scrum 敏捷开发三种角色
Product Owner（产品负责人，简称“po”）：产品老板，主要提需求的人。
Scrum Master（主管）：保证团队以 Scrum 形式开发，比如进入开发模式时，不让修改需求，召开管理每日会议。
Team（团队）：不分开发测试，大家一起完成。

（3）如何进行 Scrum 开发

①.我们要先确定一个 Product Backlog(按优先顺序的一个产品需求列表)，这个由产品负责人负责；
②.Scrum Team 根据 Product Backlog 列表，做工作量的预估和安排；
③.有了 Product Backlog 列表，我们需要通过 Sprint（冲刺）计划会议来从中挑选出一个需求作为本次迭代完成的目标，这个目标的时间周期是 1-4 周，然后把这个需求进行细化，形成一个 SprintBacklog（需求列表）；
④.Sprint Backlog 是由 Scrum Team 去完成，每个成员根据 Sprint Backlog再去细化成更小的任务；
⑤.在 Scrum Team 完成计划会议上选出的 Sprint Backlog 过程中，需要进行每日站立会议，每次会议在十五分钟左右，每个人发言，并且要向所有成员当面汇报昨天完成了什么，并且要讲出今天完成了什么，可以提出解决不了的问问题，每日更新自己的燃尽图；

• 蓝色：理想情况
• 红色：实际情况

（燃尽图：是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个 Y 轴（工作）和 X 轴（时间）。燃尽图是对于剩余时间的统计。管理层就可以通过这个图实时把握住开发的进度并作出正确的决策，而且还可以预计风险，同时随之调整计划。燃尽图，对于管理层是具有非常大的吸引力。）
⑥.做到每日集成。也就是每天都要有一个可以成功编译，并且可以演示的版本；
⑦.当一个需求完成，我们要进行演示会议，也是评审会议，每一个 Team成员都要演示自己完成的软件产品；
⑧.回顾会议，也称总结会议，每个人发言，总结讨论改进的地方，放入下一轮的 Sprint 产品需求中。

（4）什么是 XP？
Xp：极限编程。Xp 是一种轻量（敏捷），高效，低风险，可预测，科学的软件开发方式。
Xp 在更短的周期内，更早的提供具体，持续的反馈信息，在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后再项目开发过程中不断地发展它，它依赖于口头交流，测试和开发团队紧密协作。
Xp 由价值观，原则，实践和行为四个部分组成，他们相互依赖，关联，通过行为贯穿整个生命期。

• 四大价值观

  • 沟通：鼓励大家口头交流解决问题，提高效率；
  • 简单：提倡“够用就好”的思路，尽量的简单化；
  • 反馈：时时反馈代码问题以及进度；
  • 勇气 ：在 xp 中，会让你处于变化之中，需要勇气来面对快速开发，甚至面对重新开发。

• 五个原则

  • 快速反馈：对反馈价值观的补充；
  • 简单性假设：对简单价值观的补充；
  • 逐步修改：任何问题都应该通过能够带来差异的微笑改动来解决（就像开车打方向盘一样）；
  • 提倡更改：解决重要问题是保留选项多的答案，为下一次的修改做好准备；
  • 优质工作：贯彻“小步快走”的开发原则，工作质量要求相当的高。

• 两者区别

  • 迭代长度不同
    • Xp 的一个 Sprint（冲刺）迭代长度大致 1-2 周；
    • Scrum 的迭代长度为 2-4 周；
  • 是否允许修改需求
    • Xp 中，如果一个需求还没有实现，可以用另外的需求替换；
    • Scrum 一旦确定，任何需求都不允许加进来，有 Scrum Master 把关；
  • 需求是否按照优先级来实现
    • Xp 中务必遵守优先级；
    • Scrum 中可以不按照优先级；

（二）边做边改模型

1．简介

当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是边做边改模型。

这是一种类似作坊的开发方式，在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。

2．优点

这是一种类似作坊的开发方式，它的优点毫无疑问就是前期出成效快。

3．缺点

（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2）忽略需求环节，给软件开发带来很大的风险；
（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

4．适用场景

因为这种模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式非常有用。对于需求非常简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型。适用于并不太严谨的小程序，可以快速实现功能。

（三）迭代模型

1．简介

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3 周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

2．迭代与版本的区别

迭代一般指某版本的生产过程，包括从需求分析到测试完成；
版本一般指某阶段软件开发的结果，一个可交付使用的产品。

3．优点

（1）降低了在一个增量上开支的风险，如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费
（2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以今早解决而不至于在后期匆匆忙忙
（3）加快整个开发的工作进度，因为开发人员清楚问题的焦点所在，工作更有效率
（4）由于客户的需求并不能在一开始就做出完全的界定，需求是在后续阶段中不断细化。

4．适用条件及场景

（1）在项目开发早期需求可能有变化；
（2）分析设计人员对应用领域很熟悉；
（3）高风险项目；
（4）用户可以不同程度参与到整个项目的开发过程；
（5）使用面向对象的语言或统一建模语言（UML，是一种面向对象系统的产品进行说明，可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言（一种面向问题的语言，用于表达某一系统或构件的需求，设计，行为或者其他特性），是面向对象设计的建模工具，独立于任何具体程序设计语言）；
（6）使用 CASE(Computer Aided Software Enginnering，计算机入住软件工程)工具，如 Rose（一款非常受欢迎的物体软件开发工具）；
（7）具有高素质的项目管理者和软件研发团队。
适合于事先不能完整定义产品的所有需求，计划多期开发的项目。

三、其他模型

（一）瀑布模型

1．简介

瀑布模型是一种比较老旧的软件开发模型。1970 年温斯顿.罗伊斯提出著名的瀑布模型，直到 80 年代了，还一直被广泛采用。

瀑布模型将软件的生命周期划分为：制定计划，需求分析，软件设计，程序编写，软件测试和运行维护六个基本活动。规定他们自上而下，相互衔接的固定次序，就像瀑布流水一样，逐及下落,好比流水线。

2．优点

严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。
（1）为项目提供了按阶段分的检查点
（2）当完成一个阶段后，只需要去关注后续阶段
（3）可在迭代模型中应用瀑布模型

3．缺点

缺乏灵活性，太过线性理想化，不适合现代软件开发
（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
（4）各个软件生命周期衔接花费时间较长，团队人员交流成本大。
（5）瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

4．适用场景

瀑布适合简单明确的产品，敏捷适合复杂多变的产品，那么复杂而较为稳定的 B 端产品适合使用敏捷吗？

C 端产品用户面广、市场多变未知、竞争激烈，需要尽早入局、速战速决，在一场场战役中不断提升产品价值，C 端产品在基因里就和敏捷高度匹配。

而 B 端产品相对来说用户面较小，若非政策和业务模式变动，通常都较为稳定；B 端一般分为服务于大量客户的普适性产品和服务于少量客户的个性化定制产品，对于普适性产品需要伴随不同行业不同规模的企业成长，情况复杂难以预测，则比较适合使用敏捷开发；对于个性化定制产品需要考虑产品的体量规模，若规模小、易预测、实现周期短，则适合使用瀑布法，若规模较大、难预测、实现周期长，则适合使用敏捷开发。

（二）快速原型模型

1．简介

快速原型模型需要建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发的软件需求。通过逐步调整原型使其满足客户要求，开发人员可以确定客户的真正需求；之后在第一步的基础上开发客户满意的软件产品。

快速原型模式可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，有着显著的效果。快速原型模式关键在于**尽可能快速的建造出软件原型，确定了客户的真正需求，所建造的原型将被丢弃。**因此原型系统的内部构造并不重要，重要的是迅速建立原型，随之迅速修改原型，以反映客户的需求。

快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。

2．优点

（1）生命周期短；
（2）整合边做边改和瀑布模型优点；
（3）减少软件需求不明确带来的开发风险；
（4）适用于小型，交互型的系统，大型系统的某些部分。

3．缺点

可能导致系统设计差，效率低，难维护。

（三）增量模型

1．简介

在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

2．优点

（1）人员分配灵活，一开始不需要投入大量的人力；
（2）先推出核心产品，在后续继续增加相应功能；
（3）最初产品（实现核心需求的产品）交付快，成本低；
（4）适用于需求经常改变的软件开发过程。

3．缺点

（1）由于各个软件是逐渐并入己有的软件体系结构中，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放的体系结构；

（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但是容易退化为边做边改模型，从而是软件过程的控制失去整体性。

（四）螺旋模型

1. 简介

1988 年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

2. 螺旋模型的四象限

螺旋模型沿着螺旋线进行若干次迭代，图中的四个象限代表了：
（1）功能计划：确定软件功能，清理限制条件，制定研发方案；
（2）风险分析：评估研发方案，考虑如何识别和消除风险；
（3）项目生产：软件开发，测试和部署；
（4）客户反馈：工作复盘。提出修正建议，制定下一步计划。

3. 限制条件

（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，螺旋模型适应于内部的大规模软件开发

（2）如果执行风险分析大于项目利润，那么风险分析毫无意义，所以螺旋模型只适用于大规模软件项目

（3）软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则会带来更大的风险

（五）演化模型

1. 简介

主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。

在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。

“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。

（六）喷泉模型

1. 简介

以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

2. 优点

可以提高软件项目开发效率，节省开发时间，适用于面向对象的软件开发过程。

3. 缺点

（1）由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量
的开发人员，不利于项目的管理；

（2）这个模型要求严格管理文档，使得审核难度加大，尤其是面对随时加
入各种需求。

（七）智能模型

1. 简介

智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言（4GL）的支持。4GL 不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL 还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的 4GL（如 Foxpro 等）都不同程度地具有上述特征。但 4GL 目前主要限于事务信息系统的中、小型应用程序的开发。

（八）混合模型

1. 简介

过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。