授课视频1/3在线视频

大家好，下面我们讨论软件的开发活动

也就是说我们要了解一下

软件一般的过程是什么样子的

这一点我们在本科时了解过

下面我们来回顾一下

首先我们来看一个幽默

这个幽默很有意思

这个程序员他自认为他的代码没有bug

我们每个人都这么认为，对吧

程序员嘛，我们写的代码谁敢说有问题？

没问题

软件测试发现了20个bug

这是我们保证软件产品质量的一个手段

这没问题，也没问题。你写代码，他们做测试

程序员说10个bug，我认，没问题

没问题，是我写的，写错了，我改

另外10个根本不是bug

是你们不会测

或者是你们的环境有问题

总之不赖我

然后呢，测试组根据程序员提交的修改

进行确认的时候发现

你不是改了10个么

这5个你根本就更差了

根本就没有办法进行测试，没有办法工作

同时发现了更多的bug

这也很正常，bug从理论上来说

不可能被完全发现的

于是程序员和测试人员

拉锯一样重复了这样的活动

发现问题，修改，修改完了再测

一有问题，再测，翻来覆去的这样做

程序员和测试员这样玩游戏可不行

我们的产品是有压力的

当初呢，我们产品承诺要在什么样的情况下

什么样的节点发布

我们要先于竞争对手

没办法，产品必须上市

结果可想而知

用户发现了更多的bug

我们知道，测试人员测试的时候

有的时候并不能完全模拟终端用户的这种无知的行为

可以这么说

大家回顾一下自己在使用计算机软件和硬件的时候

很少有人，这里面有个统计数字

有相当比例的人员

从来不看说明书

上来直接就用

当他发现问题的时候

用错的时候，他才想起来去看说明书

当然现在随着网络的发展

说明书也不用看了

直接上网搜索解决方案

搜完一圈之后发现

说明书当中解决了这个问题

也就是说呢，我们不能期望我们的用户

非常严谨的按照我们设定的流程去做

最后呢，很幽默的一段话

程序员跑了，知道我写的代码有问题

新项目组，老的程序员跑了

新的程序员，新的项目组继续修正

修正完了之后呢

发现了更多的bug

这是很幽默的一句话

程序员跑了之后呢，又刺激一下测试组

当初的死对头，现在你看我享受呢，你们苦哈哈的，对吧

最后我们的产品因为我们太多的bug

满足不了用户的需求

导致我们的公司被竞争对手恶意收购

收购的时候呢

软件中带着783个bug

新的CEO

新的程序员

新的程序员又写出他认为没有bug的代码

非常有意思

说它很幽默，它其实在实践的开发活动当中

还经常出现

下面我来看一看在整个软件开发过程当中

我们提到一个周期的概念

或者我们叫周期模型

软件和硬件不同

这里其实我想区分一下

软件的生存周期和软件的开发周期

很多资料上把生存周期和开发周期认为是一个周期

我个人认为这个开发周期

我们比较重点的关注软件开发过程

当然了，随着我们软件开发活动的延续

我们的维护阶段其实也涵盖在

我们这个软件生存周期的

但一般情况下，在实际的开发过程中

我们团队作战，作战完之后

用户验收之后，项目组解散

或者去做其他的项目

我们留一部分，一小部分人员

或者公司里面有专门的维护部门

他们接手对这个项目的后期维护

所以从现实意义上来说

我们说我们的开发活动就结束了

这个地方我们做一个小的区分

谈到了这种生存曲线

对硬件来说

硬件的生存曲线是一个经典的浴缸曲线，

你买了一个新的硬件

开始的时候老出问题

后面经过磨合磨合磨合之后

就像汽车一样，刚出厂的时候有个磨合期

后面零部件经过磨合之后

进入一个非常好的状况

后来随着寿命的临近结束

故障又多了，该换一个新的硬件了

这是我们说的典型的硬件的生存曲线

对于软件来说

第二个小图说的是理想的软件

这个软件开始的时候

它有很多故障，很多错误

随着不断的维护和修复

软件的故障越来越少

理想的软件期限是这样的，软件么，它不像硬件，它没有劳损的说法

但是实际上的软件生存曲线是这样的

也就是说呢，开始的时候

这个软件是故障多

慢慢的修复后少了

但是后面的每次修复可能带入新的问题

所以它不是一个理想的曲线

一直降低，还可能增加的

这个故障率随着修复引入新的故障

导致这个软件用着用着可能就成本太高了

最后考虑升级换代

开发新的产品

这是我们软件开发的周期和周期模型

对于模型我想说的是，软件开发的基本活动都一样

都是需求分析

系统分析与设计，编码，测试

这是几个主要的基本活动

无论你怎么开发

这几个基本活动都得有，对吧

只不过是这些活动的组织方式不一样

是按顺序来呢

还是迭代来呢

还是螺旋形的呢

所以我们在书上都会提到软件的开发周期模型

典型的软件开发周期模型

当然最经典的就是瀑布模型

这个瀑布模型，水啊，瀑布啊

从高处流下来

先流经需求分析

再流经系统分析设计，编码，测试

这是一个典型的瀑布

这个瀑布啊，或者说原始的瀑布模型它有个特点

就是水往低处流

这个水是不能再回来的

这是它的典型的一个特点

到了这个节点

前面的活动就终止了

就完事了，就完美了

进入下一个阶段

一直往前走，不回头

这是我们典型的瀑布

后来还有其他的像喷泉啊，螺旋啊

还有一个典型的迭代模型

一些主要的流程阶段经过n次迭代

通过这个图大家可以看得出来

第一次迭代的时候

需求是主要的活动，然后呢

后面就可以继续往下做

第二次迭代的时候呢

重点做计划

第三次迭代呢，就是逐步往前推进

你会发现随着迭代次数的增加

最后我整个项目重心

活动的重心

集中在了不同的活动当中去

我们可以说，软件开发的基本活动包括这几个方面

我们强调一下

可行性分析，需求分析，系统分析与设计

详细设计，编码，测试

部署和维护

这是一个相对完整的基本流程

相对于瀑布和其他的一些模型

我们近年来大家比较公认的

就是这种。我们想象一下啊

我们想象一下，瀑布是一个平铺的各个阶段

现在我把各个阶段首尾相接

形成一个圈

这个圈呢构成一个轮子

那么轴啊，就是变更

后面我们对这个模型还会有个详细的讨论

那么以变更管理为轴，滚动前进