软件工程全攻略：模型与方法详解-CSDN博客

本文链接：https://blog.csdn.net/weixin_51333606/article/details/123081604

第十一章.软件工程

第一节.软件开发模型

🌳开发模型是软件工程中指导开发的一种开发思想和开发体系。
🌳不同的开发模型分成不同的阶段，具有不同的指导思想，做着不同的事情。
🌳开发模型多种多样，经过几十年的发展，产生了很多开发模型，各种开发模型各有特色。
在这里插入图片描述

1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。在全盛时期，大约90%的项目采用瀑布模型，包括美国的国防部都是指定使用瀑布模型进行开发。但是慢慢的瀑布模型就淡出了人们的实现，基本上属于被淘汰的行列，因为瀑布模型具有重大的缺陷。这种缺陷足以导致项目的失败，因为有研究机构进行过统计分析，发现使用瀑布模型做开发十有八九会失败，这种失败体现在要么延期，要么成本超支，要么根本就做不下去了。
那么为什么会有这样的现象诞生呢？请带着疑问往下看。

瀑布模型（SDLC）

在这里插入图片描述
图注
🌳瀑布模型的开发过程中，每一个步骤的末尾都会有软件的评审工作；评审上一个步骤是否合格，上一个步骤相应的产出物是否符合相关要求，这些标准都被评审的，而且瀑布模型更强调文档化标准化。
🌳瀑布模型是一个结构化方法中的模型，一般应用于结构化的开发。而且非常具有代表性，它把结构化特点表现的淋漓尽致。

讲到这里，似乎还没有看出有什么缺陷，做事情先有计划再分步骤进行，每个步骤完成后做评审，这似乎是一种很好的方式，而且改进后的瀑布模型还加了回溯的通道。
这样子看起来似乎还不错，为什么会导致那么严重的问题呢？
根本性原因是需求阶段难以把控。软件的需求往往是不明确的，往往是在项目的初期阶段。你要在软件需求的项目初期能明确几乎是不可能，这就导致了在需求不明确时就开始做，而我们开始做的时候认为这种需求就是用户所需要的东西，完成开发阶段之后交给客户去验收，很大概率会推翻你的所有工作，为什么呢？客户会告诉你这里不行，哪里不行，哪里需要改，这个思路跟我们想的不一样等等这些问题，所以需要回到需求分析重新开始。这样子会导致浪费大量的时间，最终导致软件项目的失败，就是因为这个原因使得瀑布模型很难完成项目的开发。

瀑布模型适用于什么样的场合呢？
需求明确或者是二次开发的情况下。当然我们也可以把瀑布模型用在这种场合下，用其它模型先把需求做明确，再按照瀑布模型完成开发阶段和维护阶段，这也是可以的。

总结
🌳瀑布模型是一个结构化方法中的模型，一般应用于结构化的开发。
🌳瀑布模型只适用于需求明确的项目，对于需求不明确的项目千万不要使用瀑布模型做开发。

瀑布模型是比较早的一种模型。在它出现之后，引起人们对模型的疯狂追逐，所以产生了很多其它的一些模型。当然，在产生其它模型的同时人们也注意到瀑布模型巨大的缺陷，所以试图避免瀑布模型的缺陷在其它模型中重新出现，避免重蹈覆辙。

其他经典模型

在这里插入图片描述

原型模型

原型模型和瀑布模型是一对互补的模型。瀑布模型失败是因为对需求变化无法进行灵活的应对，它无法把握需求从而导致后面开发产生一系列问题，所以原型模型从诞生开始就定位于需求不明确的情况下使用。

原型模型是怎么做的呢？
假设开发一个系统初期进行需求分析方面的工作时，无论你跟用户做如何详细地沟通，用户都很难把他的需求表达准确和全面。原因就是用户自己也不知道需要一个什么样的系统，而且用户和开发团队之间有一个隔阂——双方的知识领域不一样，这样就导致了沟通需求方面存在很多问题。那么原型模型就强调在项目开发的初期会构造一个简易系统。

这个简易系统是什么呢？
它可以是一套界面，展示我们这个系统开发之后，是一个什么样子的情况，在哪里显示什么按钮，点击按钮会产生什么样的现象。也可以做一个初步的系统出来，让用户来看一看用一用。

原型模型强调构建一个简易系统的好处：就是可以让用户知道开发出来的东西是什么样子从而知道一些细节需求。但是原型模型往往只用于开发过程中的需求分析阶段。

演化模型

如果说咱们把最初的原型通过很多步的演化调整，最终变成了给用户使用的软件产品，我们称这种模型为演化模型。

增量模型

由原型模型的思想和瀑布模型的思想结合得到增量模型。
在这里插入图片描述
增量模型是一种怎样的思路呢？我们知道用户有多种多样的需求，其中核心是哪一块呢？
我们做系统的时候先把核心的部分做出来，这个周期可能有原来做项目的20%的时间，做好核心的几个模块，就把做好的核心模块拿去给用户使用，用的过程中发现问题就修正问题，下一个月又开发另外两个模块，就这样子一部分一部分进行，就这样软件越变越大，到最终完成所有的内容，这就是增量模型。

好处：核心模块比较早的和用户进行了接触，在每一轮交给用户去看相关效果的时候，都相当于对核心模块进行再一次的审视，所以这种项目做下来风险会小很多，这是不会出现最后用户提出来核心功能不行需要修改的情况，要修改的内容在整个流程中就已经改完了。

总结
🌳这就是原型模型和瀑布模型与其它模型的一些区别和联系。
🌳原型强调构造一个简易的系统，而且它是针对需求不明确的情况。

螺旋模型

在这里插入图片描述
🌳螺旋模型基本形状犹如螺线形状，从中间一圈一圈地循环出来，所以称之为螺旋模型。
🌳螺旋模型也是从最初的原型发展而来的。在这种模型中，融合了多种模型的特征，比如说有原型，演化、瀑布模型等一系列模型。

🍀特征①：从上方图中可以看出，螺旋模型的步骤中具有最初的原型和分阶段的瀑布模型的过程。由多个模型组成，所以多个模型的特点它都具备。
🍀特点②：引入了风险分析。因为它是成螺线圈的形状一圈一圈循环出来的这个过程中有风险分析，这个风险分析是之前一系列模型中都没有的特征，所以风险分析就成了螺旋模型中最显著的特征之一。

V模型

V模型以形状而得名，整个流程形成一个V字型。
在这里插入图片描述
从这样的阶段划分可以看出跟瀑布模型非常地接近。

特点①：测试起到了更重要的地位。因为V模式的测试被细化到了单元测试、集成测试、系统测试、验收测试，而不是像瀑布模型中只有一个软件测试。
特点②：阶段画成V字型其实是有他的用意的，其实就是各个阶段的对应关系。如：需求分析跟验收测试和系统测试有着对应关系。
需求分析阶段会去写验收测试和系统测试的测试计划。
为什么要这么早去写测试计划呢？就是希望提早能够发现问题，因为在瀑布模型中我们把软件测试压到最尾端，这种方式的缺点是当你发现问题时，反过来想要去修正代码就不太好改了，如果你要想要修改的话相当于是从需求分析来写起，消耗的成本过高，如果说我们在需求分析阶段就写验收测试的测试计划，那么写测试计划时候就会从测试的眼光看待问题，那么在这个过程中必然就能够发现一些需求所产生的问题。
概要设计阶段会去写集成测试的测试计划。
因为概要设计主要是进行模块的划分，而集成测试测得就是模块之间的衔接。如果说你在进行模块划分的时候就考虑到了我要去测试这些模块之间的衔接是否正常，也就能够发现一些模块划分的问题。
当然，详细测试阶段会去写单元测试的测试计划。这就是V模型。
V模型是一个强调测试的模型，强调要及早地进行测试，强调测试要贯穿于开发的始终，而不是压到最尾端，否则会出现很多问题。
这就好比我们建设房子，砌墙是基本功，如果说你想把一面墙给砌平砌直有两种方式，一种方式就是先砌然后拉水泥线和铅垂线来从水平维度和垂直维度来分析，看看墙面是否平直；另外一种方式是先拉好线然后卡着线砌上去；毋庸置疑，肯定是是先拉线然后再砌上去比较好，卡着线砌上去是不容易出问题的。而瀑布模型实际上是选择第一种方式，先做然后再进行验证，这其实就是验证能够找出问题来，但是修正成本过高，就好比建了一扇墙，一侧发现不平不直，接下来怎么办呢？你就头疼了，你需要把墙敲掉再重新来，这样成本就太高了，所以V模型就是通过这样一种手段能够起到这样一种效果。

喷泉模型

最大的特点：该模型是一个面向对象的模型。因为在老一代的这种模型中，瀑布模型、原型模型、V模型、增量模型都是结构化方法底下的，所以喷泉模型提出来的时候是面向对象的，故称为它最大的特点。
因为它是面向对象模型，所以就会有面向对象模型的共性在其中，即它的特点当中具有迭代和无间隙。
瀑布模型属于结构化的典型代表，而喷泉模型是属于比较早的面向对象的模型。

快速开发模型（RAD）

快速开发模型属于由瀑布模型（SDLC）和构建组装模型（CBSD）形成的一种模型。

如果说用VB等可视化的工具做开发，那就已经运用到RAD模型了。为什么这么讲呢？
我们可以看到如果像瀑布模型做相应的一些开发，按照流程来走会有很多部件形成了组件化，这就已经符合快速开发的特点了。因为这个名词是很多年前就已经提出来了，以前做开发时你要使用C语言做个界面出来，那么你需要花费很多时间来绘制这个界面，然后才能形成漂亮的图像化界面。但可视化工具的诞生就改变了这一切，通过拖动的方式就能够达到目的。空间、按钮、连接数据库、显示报表信息等等这些已经有了非常标准的构件，还有很多人为第三方提供了相应的第三方的构件库。所以RAD就结合瀑布模型和构建组装模型的特点形成了自己的风格。
在这里插入图片描述
用RAD开发的过程依次为业务建模、数据建模、过程建模、应用生成、测试与交付。
这种模型最大的特点就是能够快速的构建应用系统，所以这些技术出现之后就能够得到广泛的应用，很多信息系统都是用到来做相应的开发。

构件组装模型（CBSD）

这种模型的基本思路是什么呢？
把软件开发当中的各个模块考虑成为标准的构件，做成标准构件之后，通过一定的方式进行组装就得到了我们最终需要的软件。

那么这种思路为什么能够得到广泛的认可呢？
其中一个最重要的原因就是极大的提高了软件开发的复用性，一旦提高了复用性就可以使得软件的总时长极大的减小，可以使软件的成本降低，同时还可以使软件的可靠性增加，缩短时间减少成本。

为什么能够提高可靠性呢？
因为在CBSD这种开发模型当中会建立一个构件库，这个构件库中的构件如果说在新的系统中用得上，就可以直接提取出来应用它。构件库中有着以前很多的构件，这些构件以前运用到其它系统中的构件，这些构件的可靠性已经经过了很长时间的验证，如果说有问题，在以前的系统中就已经发现并修正了，所以在应用到新的系统中，出错的效率就远远小于新开发的构件，正是因为有着这样的新特色，CBSD也就是有着非常强的竞争力。很多的软件开发模型都应用到了这种思想，如RAD。
在这里插入图片描述

用CBSD做开发时会分成这些步骤，这跟一般的普通的瀑布流开发没有太大差别。
其中的一个差别就是软件架构设计。 架构设计在瀑布模型中是没有提到的，那么做架构方面的设计其实类似于建房子，搭起一个基本的框架；然后是构件库的建立，就是看以前有什么构件能够使用到，能直接用上的就直接使用上，如果说不能够用上的，就修修改改再使用，实在不行，就新做，做完之后放入到构件库中，完成一系列的构件之后，咱们就把这一系列的构件组装起来，最后就是进行测试与发布。
构件标准目前有三大标准。
第一个标准CORBA是对象管理组织（OMG）提出来的
第二个标准组COM/DCOM/COM+ 是属于微软家族的
第三个标准EJB是在java体系中能够使用到的，这就是构件组装模型。

敏捷开发方法

从所有开发方法来看，敏捷开发方法属于比较年轻的一类开发方法。
发展历程
最初咱们是没有模型没有方法的，这样子发现产出的软件产品质量很难控制，所以发展出了软件工程，随之发展出了一系列开发方法开发模型，在开发模型和方法一步一步增加的时候，规范程度越来越高的时候，人们就发现在开发过程中真正按一些重量型模型去做开发往往是得不到很好的效果的，因为重量级的开发模型非常地关注流程和文档，通过这些方式来规范你的开发，那么这样一来，我们会发现开发人员的负担会越来越重，而你产生的这些文档也不见得你真正用得上，所以花了那么多的时间做出来的东西不见得是那么的好，所以有人提出来要为开发人员减负，如何减负呢？把不必要的流程砍掉，把不必要的文档减去，这样就形成了敏捷开发的思想。

了解敏捷方法的思想与理念
在这里插入图片描述
上图一些概念的说明

敏捷开发并不是一个模型，而是一组模型，像自适应开发、特征驱动开发等等都是属于敏捷开发模型，这些模型有着共同的价值观，有着共同的处置原则，甚至于很多最佳实践都是保持一致的。
基本原则部分分析
短平快的会议：对于大型机构往往会议会比较多而会议又比较耗时，这样其实就消耗了项目组大量的资源。因为对于软件项目开发来说，最重要的就是人力资源，如果你把人力资源都用来开很多无意义的会议上往往会有造成浪费。实现这一原则的做法：首先把不必要的会议砍掉，如：传达某种意见或意思的会议可以通过其它形式替代；把现有的会议缩短甚至是站立式的会议，这样子就形成控制时长和高效快捷的会议。
小型版本发布：因为你做再多的文档最终运行的还是软件产品，得到用户认可的也是软件产品，所以做一些小型的版本让用户在整个开发流程中能够使用这些版本，能够及时发现一些问题并按照用户的需求进行修改。这一点跟原型思路有点接近，原型是构造一个简易的系统。
4大价值观
沟通（对内对外都非常重要）
简单（不要过度设计，能够满足基本需求就可以了）
反馈（随时跟客户反馈相关情况，这样子有问题就能够及时调整）、
勇气（同时强调大家要有勇气去面对变更，因为很多人面对变更是很头痛的。对于开发人员来说变更不是啥好事，但是也不可避免，既然如此迟变不如早变，早变反而有更大的主动性，成本就会更低一些）。
最有代表性几个的最佳实践
计划游戏：强调设计一个游戏可以让用户能够直接参与进来，而非制作原来的一些墨守成规的文档化的一些东西。
隐喻：要善于用比喻的方式跟用户表述一些问题。
测试先行：编写代码前把测试提前想出来。
结对编程：两个人一组，一个人编码另外一个人检查代码，看上去是两个人在做一个人的事情，效率降低了，但事实上两个人都用心在做事情，往往效果不会降低，反而会变得更高。为什么呢？因为两个人的思考会变得更全面，同时开发不会很耗时，调试会很耗时。两个人进行商量往往更快的找出问题所在，缩短调试的时间。
集体代码所