首先给大家介绍第一个出现的软件生存周期模型 那么软件生存周期模型是由
Royce 在 1970 年提出来的,但这个模型的雏形是
五十年代提出来,也就是说人们在做事情的时候总是要来说,我到底做什么 以及我怎么做。
但人们发现这样的一个划分有点太宽泛了,于是随着软件这种
应用领域的不断扩展以及软件应用系统的这种复杂性的增加,人们发现说这么简单的来认知
这个进行软件的开发的这个阶段
有点太简单了,不足以能够这个什么,应对 应用系统的复杂性。
于是进一步把它又细化成如图这个所示 系统的需求,软件的需求,需求的分析、
设计、 编码、 测试和运行 那么随着人们应用这样的瀑模型发现很多情况下,我们实际上
前一阶段做的工作,实际上做的需要有变更,对吧,那我在进行新的一个阶段的时候发现
我需要对前一阶段的结果进行相应的修改,或者前一阶段 做的事情,我需要重新进行规划
于是又增加了相当于一个反馈的这样的一个机制,也就是说允许
从后一阶段返回到前一阶段,进行适当的什么?对前一阶段进行适当的修改
所以大家来看啊,经典的瀑模型是将软件
生存周期的各项活动是规定为若干顺序连接的 这样的一个若干阶段的工作。
那么,规定了每一阶段的输入 以及这一阶段的工作成果,这一阶段的工作成果实际上是作为输出来
传入下一阶段,作为下一阶段的什么?输入。
所以这样一环套一环,这是经典的瀑模型 而且这样的一个瀑模型它反映了一个归纳逻辑
对吗?如果 P 为真,Q 为真,那么 P 与
Q 就为真,说明一个什么?如果我上一阶段做的这样的一个事情是正确的
那我这一阶段做的这个事情也是正确的,那我上一阶段和这一
阶段叠加在一起,最终形成了这样的一个所做的事情的结果,就应该是正确的
所以它保证了说,如果我每一阶段做的事情能保证它的有效
性,那我最终,从最开始的头到最后的这个结尾,我就能够 应用瀑模型就应该能保证它的这种有效性
那么瀑布模型实际上它为我们项目的开发呀,规定了需求、 设计、
编码、 单元测试 集成维护这样的一个基本的路径,也就是说这是瀑模型是我应用的这样的一个基本路径
那么第二点呢就是说通过每一阶段提交的 都要提交以下的产品,比如说软件需求规约
是相当于软件需求分析阶段之后形成的制品 那么设计文档是在设计阶段形成的这样的一个制品
实际的编码,测试的用例,最终的产品,所以工作产品呢它也是要以一个什么?
沿着我们第一阶段给出来的这样的一个基本路径正向的流下去
实际上前一阶段的结果是作为下一阶段的一个输入,也就是说需求分析的
结果是软件需求规约,它同时作为软件设计阶段的一个什么?输入
所以大家看这就是一环套一环的这样的一个瀑布流水的瀑模型的内涵
第三点就是反向步骤流,表示对前一个
可提交产品的重复变更,有的时候我们又称为返工啊
为什么会出现返工呢?实际上是人们在实际项目的开发中发现
由于所有开发活动的非确定性 我们认为说,哎呀,这不就是进行需求分析吗?但是
需求本身是有一定的变化性的,对吧?就像老师说的
不变的只是说我在某一时刻冻结了这样一个需求陈述,在这样的一个基础上我再进行需求-
分析而已 所以,在这里面,就有它的这种变化性,以及
你所选择的开发模型适不适合 这一类型的应用系统的开发。
所以这样的一些特点就使得 有的时候需要在下一阶段或更后的阶段呢相当于去重复
变更前一阶段的东西,认识到犯了错误,所以要重新修改前一阶段的 这个结果。
那么瀑模型,我们来看一看它的优点是什么
那么瀑模型它是最古老的软件开发模型或者软件生存周期模型
那么很多人都认为说它已经过时了,因为大家都 知道,后面我们还会涉及到喷泉模型,对吧,演化模型等等
一些相当于被现在大型的应用系统所应用的一些这个开发 模型,那么是否瀑模型它就已经真正的过时了呢?
我们先来看一下它的优点,再来说它到底过不过时,也就是说
在决定系统怎么做之前存在一个需求阶段,那么
瀑模型实际上鼓励对系统做什么进行规约
为什么?也就是说,我这个系统做什么 之前进行,进行规约,实际上是我设计这个阶段是要
怎么做,对吧?怎么做这件事,那也就是说在怎么做这件事之前我一定要先 规约我到底要做什么,所以它形成了一个良好的一个什么?
一个需求的这样的一个确定,这样的一个入口,也就是说这样的一个基础为我后续的开发
能够奠定一个坚实的基础。
那么在建造 构建之前呢,存在一个设计阶段,它也鼓励 规划系统结构,为什么?
也就是说我在编码之前,我一定要先经过设计 在我第一讲的时候,我已经跟大家反复强调了说,软件
的开发实际上更多的是在什么?创造性的设计,对吧?
软件是设计出来,而不是一个制造出来的,所以这与 传统的制造业不同的地方,所以在这里面,我们就要
更多的去关注设计,也就是说到底它应该怎么做,这是一个
软件架构师以及软件开发人员,他们的 智慧的结晶。
那么第三点呢就是在每个阶段结束的时候应该进行 复审,允许获取方和用户的参与
因为它让获取方和用户的这样参与,参与这个复审的过程就有效的控制了这个 系统的一些质量的问题。
那么还有一点,前一工作产品可作为下一步可被认可的
文档化的基线,所以在这里面呢它允许基线和配置呢早期的接受控制,这是它的优点
那么瀑模型本身也存在着不足,对吧?大家可以看到,就像我刚才说的,它不可以
越层的这样的一个返回,那也就是说,首先,客户必须能完整、 正确、
清晰的表达 他们的需求,开发人员一开始就必须理解需求
这是瀑模型成功的最致命的一点 那么第二点就是说缺乏灵活性,一旦软件需求存在着偏差
它就会导致开发出来的软件产品不能满足用户的实际的需求,所以大家知道
如果我最开始的目标就没有确定好,那么我按照这样的目标开发出来的产品 一定会跟我最开始的目标是有偏差的,对吧?
第三个就是说,在一个项目的早期阶段,由于过分的强调了基线和里程碑处的文档
可能要花费更多的时间建立一些用处不大的文档 所以在这里面,它由于瀑模型强调了各个阶段的制品
所以呢,那么你可能有的时候把这个阶段划分的很细致的这样的一个瀑模型
它的文档过多,那么这样的话有一些文档可能是不重要的 但是花费了软件开发人员大量的时间,所以这是一个
耗时耗力,但是不为,这个相当于软件开发人员或者用户能看好的一种行为
第四点就是说直到项目结束之前都不能演示系统的能力 增加了项目的风险。
那么第二个 模型,增量模型,增量模型是在瀑模型
这个出来之后啊,相当于人们认识到瀑模型存在的致命的弱点的基础上
进一步想了说,奥,如果说需求不能够一下子 能够就完全确定,对吧。
没有办法完全,我能不能确定出一个最核心的需求
对吧,我先开发出来一版本,紧接着相当于我再跟用户交流,相当于再去确定一些它的
第二版本的这样的一个需求,也就是说把这个需求我可以划分成什么?增量式的
这样的,这样的一个递进的方式来进行开发。
所以,增量模型的特点就是说
假设需求可以分段,并且呢每一阶段呢都可以分别的开发,形成
一系列的这样的一个可增量的产品的结果,最终所有的
增量开发的产品集合在一起就是客户想要的那个什么?系统的需求产品
如果这样的一种方式,我们是不是就控制了它的需求的可变性呢?
所以,这样的一种理念就导致了增量模型的这样的一个出现 首先要进行增量规约,也就是把这个增量
的需求进行什么?进行规约,进行规范化的描述,叫规约 那么紧接着要进行增量设计以及增量实现。
实现之后对 这里面的错误进行相应的分析,进行纠错性的分析,最终相当于再返回去
那么再进行增量的这样的一个修补,一直到相当于这样的一个增量实现被用户所接受
那么在这个过程中呢,辅之一些管理的活动
大家看每一个增量都是要经过增量规约,增量设计,增量实现,以及纠错性的分析这样几个步骤
以及中间贯穿着管理的活动,那么增量模型的优点是什么?
我们来看一下,它作为瀑布模型的第一个变体
具有瀑布模型的所有优点,此外呢它还有相应的 自己的优点。
第一个可交付版本,所需要的成本和时间是很少的
大家看啊,因为我已经把最核心的东西,对吧,相当于划分一个增量最核心的,这是第一版啊
那也就是说它的这个成本和时间,占用的总的时间和成本
比重是很小的,以及马上我就能看到它的结果,对吧
那么第二个就是说开发由增量表示的小系统所承担的风险也是不大的,我们大家知道的,这个- 大事化小,小事 化了,对吧。
这个过程实际上就是一个分而治之的这样的一个过程 那么第三就是说,由于很快发布了第一个版本,因此减少用户需求的变更
不要变了,对吧,为什么?因为我第一版本已经出现,你已经认可了,你已经签字画押了
OK,我们增量一这个版本实现,用户已经认可的情况下,我可以进行增量二,所以
增量一的这个需求你是不可以再变的,对吧,所以这里面也形成了对用户
需求变更的一个制约,那么还有就是说允许增量投资
即在项目开始的时候仅对一个或两个增量进行投资,那么缺点
增量模型不适于某些项目,到底不适于哪一些项目呢?我们来看一下
如果没有对用户的变更要求进行规划,那么产生的初始增量可能造成后来增量的不稳定
第二点就是需求不像早期思考的那样稳定和完整,那么增量 呢可能需要重新开发,重新发布,所以这一点暗示了
用增量模型就一定是最初的 有一部分的需求是可确定的,对吧。
如果你没有任何可确定的需求 你想用增量模型,能不能用?不能
原因是什么,原因是增量一一定是对一个确定的需求来开发的这样的一个 过程。
所以,每一个增量的开发都相当于,内部都相当于一个什么,瀑布模型,对吧。
那么还有一个 管理发生的成本、 进度和配置的复杂性可能超出一些组织的能力
因为为什么?我不断的增量,对吧 把一个大的需求,我可能划分成几个增量,都有需求分析
设计,编码,测字,维护,到这个相当于版本的这样的一个最终相当于交付使用
所以这样的一个过程实际上也无形中增加了管理团队对每一增量的什么? 管理的这样的一个投入,前面我们讲到了说
瀑布模型是需求,最开始很明确,对吧。
那么 我们为了应对说最开始需求,有一部分需求不明确 找一个折中的增量模型,把先去什么?对那些明确的需求的
这样的一个需求级进行相应的开发,形成第一增量,再往 上相当于逐步的,随着需求的逐步的明确再去增加新的增量
但是有没有一种可能就是说我最开始用户也是一个相当于这个
叫做表述不清的人,我这个系统的这样的分析人员,开发人员也没有办法去理解 它到底想要什么。
也就是说我在一个需求不明确的情况下 要进行一个软件的开发,大家说瀑布模型还能用吗?肯定不能用了
对吧?增量模型也不能用了。
因为增量模型一定是在第一个 第一版本的需求是在确定情况下才可以应用的
开始推出来了演化模型,也就是说
他希望的时候允许你去探求你的需求,最开始你需求不明确
没有关系,我可以相当于去 允许你有这样一个迭代的过程逐步让你的需求去能够明确,他是怎么来做的呢?
大家来看,也就是说演化模型它是一种弹性的过程模式,它由一些小的开发部来组成
每一步都经过需求分析,设计实现和验证 产生软件产品的一个增量,经过
这些迭代最终完成软件产品的开发,逐看起来感觉有点像哈 但是大家可以看到在这里面
需求设计编码测试集成 出来第一版本要用户进行反馈,用户的反馈
回来的结果直接影响到我对需求的一个什么 修改还是不修改,所以大家来看
整个的这样的一个迭代,不是一个增量式的迭代,是一个全新的,对吧
也就是说,我的这个开发的这个结果只是为了获得用户的反馈,经过了 N
次的迭代 那么也就是说最后这个的时候所反馈用户说,这个就是我想要的,于是
相当于你的这个需求设计编码测试集成,最终返出来的这个产品才是用户
最终可以交付给用户使用的那样的一个软件产品,所以它的特点就是
针对事先不能完整定义需求的软件进行开发。
第二个呢 是针对用户的核心需求开发核心系统
以及第三点根据用户的反馈呢,实施活动的这样的一个迭代 那么下面我们来看一下喷泉模型,喷泉模型呢
它是一个迭代无缝的这样的一个过程
那么这样的两点,大家说什么叫迭代?迭代,对吧,相当于就是
一个循环在下一个循环,对吧,这样的 不断的相当于去往前推进,对吧,逼近的推进。
那么无缝是一个 你中有我,我中有你的这样的一个过程,对吧,所以这一点 是喷泉的一个特点。
大家想没想到说喷泉,对吧
喷泉相当于是从地上开始往上来喷,喷的这个过程,碰上去之后那个水又下来,对吧
与往上喷的这个水,相当于两者之间又进行相应的融合,所以你已经分不出来到底
哪一个水是往上的,哪一个水是往下来落的这一过程,所以这是喷泉的
很形象的表达出来它的一个当软件开发阶段之间存在着
无缝的这个特点是指这两个阶段没有严格的一个划分,没有严格的一个界定
比如说面向对象的这个需求分析,和面向对象的设计
两者之间实际上就没有一个严格的说,到底哪一个阶段
就是严格的这个需求分析,哪一个阶段是设计,两者之间实际上是 有很多相融合的地方。
那么面向对象的这个分析里面 是在做一些什么?系统的静态的这样的组织结构的这样的一个确定
同时,相当于,那么设计实际上也是在做一些 这样的一些类似的这样的一个事情,但是会根据你的系统的
运行环境,开发语言等等一些制约条件
对于比如说你前期需求分析的那样 的一个模型进一步的增加它的什么?比如说
人机交互部分的设计,以及数据管理部分的设计 等等,这样的一些东西。
所以两者之间还是有一些融合的东西啊,就是说有一些相互包含的东西 所以这个喷泉的这样的一个特点,大家可以
看到就是说先分析设计实现确认维护演化 那么这样一个特点实际上它想暗含一种什么含义呢?
软件开发阶段的划分,或者是说软件开发活动之间
可能是一个不断地什么?迭代 而且可以不断的两者之间相互融合的这样的一个
特征