课件
软件过程模型
前面提到,软件过程是为了获得高质量软件,所需要完成的一系列任务。它定义了完成各项任务的工作步骤,把任务、人员和工具密切地结合在一起。
软件过程模型就是对软件过程的一个抽象描述,常见的软件过程模型,包括瀑布模型、原型化模型、迭代式开发和可转换模型。
- 瀑布模型:瀑布模型将软件开发的基本活动看成是一系列相互独立的阶段,这些活动以线性的方式顺序执行;
- 原型化模型:主要是解决需求不确定问题,原型是一个部分开发的产品,通过原型实现对系统的理解,有助于明确需求和选择可行的设计策略;
- 迭代式开发:把描述、开发和验证等不同活动交织在一起,通过在开发过程中建立一系列版本,将系统进行逐步的交付和演化,从而实现软件的快速交付;
- 可转换模型:利用自动化的手段,通过一系列的转换,把需求规格说明转化为一个可交付使用的系统;
瀑布模型
瀑布模型于 1970 年提出,直到 20 世纪 80 年代早期它一直是唯一被广泛采用的软件开发模型,它把软件的生命周期划分为需求定义与分析、软件设计、软件构造、软件测试和运行维护等若干基本活动,并且规定了这些活动自上而下相互衔接的固定次序,如同瀑布流水一般。
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果再进行验证,如果验证通过,就把这个结果作为下一项活动的输入,从而继续进行下一项活动,否则返回修改。
瀑布模型强调软件文档的作用,要求每个阶段都要仔细地进行验证。
由于软件的行为只有在运行过程中才能显现出来,因此瀑布模型只有到测试阶段才能真正地验证和确认软件的功能和性能,但这时所有的代码都已经开发完成,很难返回去纠正需求的问题和设计的缺陷。显然这种模型虽然对各个阶段进行严格控制,但是却缺少了对变化的适应。
瀑布模型看似美丽却不现实,目前已经很少在业界使用。它的主要问题在于:
- 各个阶段的划分完全固定,阶段之间产生大量的文档,增加了开发工作量。
- 由于开发过程是线性的,用户只有在整个过程结束时才能看到开发成果,开发过程中间很难响应用户的变更要求,早期的错误也要等到开发后期的测试阶段才能发现,这样会产生严重的后果。
因此,瀑布模型仅适用于软件需求在开发初期就可以被完整地确定的软件项目,而且用户使用的环境也要很稳定。显然这样的要求是不现实的。
软件开发作为一个问题求解过程,应当具备什么特点?
一般来说,软件需要解决以前从未解决的问题,或者当前的解决方案需要不断更新,以适应业务环境的不断变化,因此软件开发具有迭代性,需要不断的反复尝试,通过比较和选择不同的设计,最终确定令人满意的问题解决方案。
从瀑布模型的起源来看,它借鉴了硬件领域的做法,是从制造业的角度看待软件开发。制造业是重复生产某一特定的产品,但是软件开发并不是这样。随着人们对问题的逐步理解,以及对可选方案的评估,软件在不断地演化。因此软件开发是一个创造的过程,而不是一个制造的过程。
原型化模型
在实际的软件开发过程中,最常见的问题是需求的不确定性。用户往往可以很清楚地描述现实中遇到的问题,但是由于所开发的软件在现实中并不存在,因此用户也说不清楚到底需要什么样的功能才能解决当前的问题。这种情况下,应该怎么办呢?
如果用户能够看到软件的操作界面并且实际操作的话,他马上就会明白这些功能是不是自己需要的,另外设计的原型化也可以帮助开发人员评价和分析不同方案的实现效果,最终决定更为合适的设计策略。在上述情况下,我们都实现了产品的一部分,这个部分的产品就称为原型。
原型化模型需要迅速建造一个可运行的软件原型,使用户和开发人员对系统的相关方面进行检查,以决定是否合适和恰当。原型化开发指很多种方法,既可以是可操作的软件界面,也可以是纸上原型。
纸上原型即在纸张和卡片上手绘或打印界面的元素,再把他们组合拼接,粘贴到一个背景板上,构造成模拟真实产品界面的原型。
相比于可操作的软件界面来说,纸上原型可以构建得更快,修改更灵活。
迭代式开发
今天的商业环境要求软件企业更快速地推出新产品,再加上用户需求存在不确定性和持续变化的特点,传统的瀑布模型无法适应实际需要,必须使用新的过程模型来缩短软件项目的开发周期。
迭代式的开发使得软件系统能够逐步地进行交付,开发人员在完成一部分功能之后形成一个产品版本,然后将其发布给用户使用。当用户使用第一个版本的时候,开发人员继续开发下一个版本,如此迭代循环。这样不仅可以缩短产品的开发周期,还可以更好地获得用户对产品的反馈。
增量模型和迭代模型是迭代式开发的两种形式:
- 在增量模型中,首先定义一个小的功能系统,然后在每一个新的发布中逐步增加功能,直到构造出全部的功能;
- 在迭代模型中,一开始就提交一个完整的系统,但每个功能并不完善,在后续的发布中再对各子系统功能补充、完善;
上面这幅图很形象地说明了增量模型和迭代模型的区别。第一种方式是每次完成整个画的一小部分,然后逐步增加新的部分,直到整个画完成,这就是增量的工作方式。第二种方式是先画出整个画的整体轮廓,然后多次涂色,逐渐形成最终产品的完整效果,这就是迭代的工作方式。
可转换模型
犯错是人的天性,往往是由于人为的错误造成了软件的缺陷,因此可转换模型是采用形式化的数学方法描述系统,并利用自动化手段,通过一系列转换,将形式化的需求规格说明变为可交付使用的系统。
由于数学方法具有严密性和准确性,形式化方法所交付的系统具有较少的缺陷和较高的安全性。这种模型特别适合于那些对安全性、可靠性和保密性要求极高的软件系统,这些系统需要在投入运行前进行严格的验证。
当然建立形式化的数学描述是一个比较困难的工作,目前这种方法主要还是应用于有限状态的嵌入式系统中。
案例分析
前面介绍的过程模型各自特点不同,适用的场合也不同,对于实际的软件开发项目来说,应该根据软件系统的特点,选择合适的软件过程模型。
这里分析两个软件系统的例子,为其选择出适合的开发过程。
第一个例子是汽车制动防抱系统,也称 ABS,它是一种具有防滑、防锁死等优点的汽车安全控制系统,在雨天或雪天开车时路面非常湿滑,这时突然踩刹车会造成车轮抱死,使车辆侧滑出现危险。ABS 系统的作用是在汽车制动时,自动地控制制动器的制动力大小,使车轮不被抱死,从而保证车轮和地面的附着力在最大值。
这种系统的开发具有什么特点呢?这是一个嵌入式控制系统,对安全性和可靠性要求极高,必须在投入运行前进行质量验证。显然,可转换模型是最合适的。
第二个例子是大规模在线公开课程网站,网站上可以开设大量的课程,教师可以把课程录像、课件和参考资料等公布在上面,学生可以进行自主地学习。这是一种新型的网络教育模式,将教育、娱乐和社交网络有机地结合在一起。
那么这种系统的开发具有什么特点呢?这种系统的需求会经常发生变化,业务模式也存在不确定性,而且系统应该易于维护和修改。在这种情况下,显然迭代式开发是最合适的。
总结
软件过程模型的发展体现了软件工程理论的发展,从早期完全无序的状态,到严格阶段控制的瀑布模型,以及现在流行的应对变化的迭代模型,其目的都是要提高软件开发效率和产品质量,更有效地解决软件开发面临的问题。