敏捷软件开发VS.传统软件工程

Posted 2020-08-15 血月丶

 

敏捷软件开发 VS. 传统软件工程

本文主要介绍敏捷软件开发与传统软件工程分别是什么，并讨论二者各自的优缺点。

一、传统软件工程

　1、传统软件工程的由来

　　进入上个世纪60年代，人们开始逐渐认识到了确实存在着“软件危机” 这样一个事实。例如：
　　　　·软件生产不能满足日益增长的需要
　　　　·软件开发成本和开发进度估计往往不准确
　　　　·软件开发人员和用户之间信息交流不充分，用户对完成的软件满意度很低
　　　　·软件价格昂贵，软件成本在整个计算机系统中所占的比例急剧上升，软件已成为许多计算机系统中花钱最多的项。
　　　　·软件质量难以保证。
　　　　·软件可维护性差，程序中的错误很难改正，适应性或完善性维护都极其困难。
　　导致危机问题的一个重要原因，是由于软件研制和维护本身是工程性的任务，但软件人员采取的方式却未能工程化。
　　为克服软件危机，人们开始考虑采用工程化方法和工程途径来研制和维护软件。

　2、常见的传统软件工程模型

　　（1）瀑布模型

 

　　1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 　　

　　在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 　　瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： 　　

　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； 　　

　　（2）  由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； 　　

　　（3）  早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 　　

　　我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子

 

　　（2）螺旋模型（Spiral Model）

　　1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： 　　

　　（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 　　

　　（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； 　　

　　（3） 实施工程：实施软件开发和验证； 　　

　　（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。 　　

 

　　螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下： 　　

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

　　（2）  如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。 　　

　　（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 　　一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

 

---

 

二、敏捷软件开发

1、什么是敏捷开发

　　敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

 

敏捷软件开发宣言

 

　　我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

 

　　个体和互动 高于 流程和工具

 

　　工作的软件 高于 详尽的文档

 

　　客户合作 高于 合同谈判

 

　　响应变化 高于 遵循计划

 

　　也就是说，尽管右项有其价值，我们更重视左项的价值。

 

敏捷开发有如下十二个原则：

1. 不断地尽早交付有价值的软件来使客户满足。
2. 欢迎需求的变化，即使在开发的后期。
3. 频繁地交付能够工作的软件，几个星期一次而不是几个月一次。
4. 业务人员和开发人员每天密切合作。
5. 项目是由有动力的，值得信任的人员开发的。
6. 面对面的交流是最好的交流方式。
7. 可以工作的软件是进度的主要度量标准。
8. 可持续的开发，能够保持稳定的进展。
9. 持续注意卓越的技术以及好的设计。
10. 简化-使不需要做的工作最大化的艺术-至关重要。
11. 最好的架构，需求和设计源于自我组织的队伍。
12. 团队要定期总结如何变得更加高效，并相应地调整。

　　个人认为，敏捷软件开发最大的特点就是一种时刻与客户交流的思想，它强调了开发团队与客户的沟通和反馈，敏捷开发最好的开发状态就是开发人员能够和客户一起开发，这样可以即时获得客户的意见，并且针对客户的意见对项目进行修改，所以敏捷开发不像传统软件工程一样，要在项目之初就把软件的整体框架设计完成，而是在项目的过程中时刻根据客户需求而调整，他能够欣然面对客户需求变化。就像他们的宣言一样，个体和互动 高于 流程和工具、工作的软件 高于 详尽的文档、客户合作 高于 合同谈判、响应变化 高于 遵循计划，他们强调与客户的互动，有很高的工作迭代效率。

 

---

 

三、敏捷开发与传统软件工程的优缺点分析

　　我认为，传统软件工程与敏捷软件开发两者并没有孰优孰劣的区别，只是两者所适合的项目会有所不同。

　　传统软件工程的特点是每一步都很稳扎稳打，所以它更适合那种打从一开始就需求明确，不会时不时就更改客户需求的的大规模软件。以瀑布模型为例，它设置好了严格的开发流程，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，整个开发过程的初期就设计好整个软件的框架，以此指导之后进程的逐步推进。每次进行到下一个阶段之前都要经过严格的审查，若发现不符合文档的要求就要返回上个阶段检查并修正，这样精准的要求保证了能够准确的完成用户给出的各种需求。但是，传统软件工程每一步的精确也有他的弊端，那就是无法适应经常变动的用户需求，尤其是现在这个世代节奏很快，对于那些规模不是十分大的软件，很多用户想一出是一出，时不时就有新的用户要求。而对于传统软件工程，软件的框架一旦定下来就很难再改变了，若是需求发生变化可能会导致前功尽弃，之前的代码变为无用的废物。敏捷开发的诞生则弥补了传统软件工程的这些弊端。

　　敏捷开发注重开发人员、管理人员和产品负责人员之间的沟通，通过不断地迭代，及时响应用户需求的变动。他们不像传统软件工程，早早的设计完成整个软件框架，而是以一种灵活多变的姿态，不断与客户交流，获得客户的及时反馈，从而不断完善自己的设计，这样的开发思想能够比传统软件工程更加快速的获得一个可用的产品，但是也同样需要一定的时间将这个可用的产品进行完善。但敏捷开发也有他的缺点，敏捷开发并不注重文档，所以要求对于代码要有比较靠谱的注释，而这就要求了开发人员自身的能力比较强，对于一个新手就不是很又好了，这样可能会降低效率。

　　敏捷开发强调的产品的适应性，而传统软件工程则是在工程开始之初就要仔细考虑好所有可能的风险和需要的设计，所以传统软件工程更适合一些规模庞大，且需求比较固定的项目，而在当下这个快节奏的时代，可能灵活多变的敏捷开发更加适合很多多变的用户需求。

 

参考文献

【1】软件工程：实践者的研究方法（原书第7版） [美] 普雷斯曼 著；郑人杰 等 译

【2】瀑布模型，百度百科，http://baike.baidu.com/view/551037.htm

【3】螺旋模型，百度百科，http://baike.baidu.com/view/551040.htm

【4】敏捷开发，百度百科，http://baike.baidu.com/view/309926.htm