传统软件开发VS敏捷软件开发

在上世纪60年代,由于计算机的计算能力显著提升,人们需要处理问题的复杂程度也得到提升,导致了一系列问题比如项目运行超过预算、项目运行超过时间、软件十分低效、软件质量很低、软件无法满足需求、项目缺乏管理,代码难以维护、软件难以交付,称为软件危机。人们意识到,软件开发不仅仅是让程序员编写程序那么简单,而是一项工程,需要科学的开发方法,从而人们提出了软件工程的概念,采用工程化的方法对软件开发进行管理。而在当今,软件工程中软件开发方法主要分为传统软件开发和敏捷软件开发。本文主要介绍这两种软件开发方法以及他们各自的优缺点。

一、  传统软件开发

传统的软件开发过程是一个由文档进行驱动的过程,它将开软件开发过程分为可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护七个阶段,每个阶段的输出是下一个阶段的输入。在每一个阶段,开发人员必须要完成这个阶段的任务,并编写文档,然后才能进入下一个阶段。

瀑布式模型就是一个典型的传统软件开发过程。它是一个线性的开发模型,自上而下,如同瀑布一般紧密连接,环环相扣,每个阶段的交流都是以文档的形式来进行的。

 

瀑布模型软件开发流程图

瀑布模型分为定义阶段、开发阶段、维护阶段三个阶段。在定义阶段,开发人员需要完成对软件的定义,设计出软件的基本框架结构,还要完成对软件的需求分析。开发阶段,开发人员需要根据利益相关者的需求进行分析后,构建出设计蓝图,包括UML图 、数据库表、API接口等等。值得注意的是,在开发阶段,架构师可以做出一些有预见性的假设,除了客户的需求以外,还要对客户可能有的需求进行假设,在设计时留有一定的余地,因为客户的需求在软件开发的过程中可能出现变化,导致需要修改程序,所以要规划好大量的功能需求和非功能需求,以避免重构从软件框架带来的损失。在维护阶段,开发人员根据用户使用软件的反馈,以及客户对软件的新增需求对软件进行维护,以满足客户的要求。

在瀑布模型的每个阶段结束时,需要进行严格的检查,以确保该阶段不会出现问题。当发现问题是,就顺藤摸瓜似的不断向上一层查找问题,直到查找到了问题的所在,解决了问题以后再一步步向下进行。

瀑布模型有一定的优点:

  1. 瀑布模型按照软件开发的工序,将大的过程分解成一个个小的过程,便于项目组的开发人员进行协同工作
  2. 瀑布模型为每个阶段都提供了检查点,在每个阶段结束时都要进行严格的检查,在检查通过进入下一阶段以后,开发人员就只需要关注下一阶段。

但同时瀑布模型具有巨大的缺陷:

  1. 由于开发过程是线性的,开发过程一般不能逆转,否则代价太大。
  2. 实际的项目开发很难严格按该模型进行。
  3. 客户往往很难清楚地给出所有的需求,而该模型却要求如此。 
  4. 软件的实际情况必须到项目开发的后期客户才能看到,这要求客户有足够的耐心。
  5. 瀑布模型必须编写大量的冗余文档,而缺乏人与人之间的交流,拉低了工作效率。

因为种种缺点,瀑布模型有很大的局限性,只适用于那些需求明确,并且极少变动的软件。所以瀑布模型在现在已经很少被使用,而在瀑布模型线性开发过程的基础上,又产生了其他的一些软件开发方法,例如增量模型实际上就是分段的线性模型,螺旋模型则是连接的弯曲了的线性模型,在其他很多模型中也能找到线性模型的影子。这些不同的软件开发方法使用与不同软件的开发。

快速原型模型:不要求需求预先完备定义,支持用户参与,支持需求的渐进式完善和确认,能够适应用户需求的变化,适用于需求复杂、难以确定、动态变化的软件系统。

增量模型:软件产品是被增量式地一块块开发的,允许开发活动并行和重叠,适用于技术风险较大、用户需求较为稳定的软件系统。

迭代模型:不要求一次性地开发出完整的软件系统,将软件开发视为一个逐步获取用广需求、完善软件产品的过程,适用于需求难以确定、不断变更的软件系统。

螺旋模型:结合瀑布模型、快速原型模型和迭代模型的思想,并引进了风险分析活动,适用于需求难以获取和确定、软件开发风险较大的软件系统。

二、  敏捷软件开发

虽然传统软件开发在一定程度上解决了软件危机,但是其冗长复杂的开发流程却饱受开发人员的诟病,因此人们又提出了一种快速、灵巧、轻量级的开发方法,即敏捷软件开发。

2001年,由17位软件开发专家组成的敏捷联盟签署了敏捷软件开发声明,他们认为:个人和个人之间的交流胜过开发工具和过程、可运行的软件胜过宽泛发文档、客户合作胜过合同谈判、对变更的良好响应胜过按部就班地遵循计划。

在敏捷软件开发的过程中,要求团队能够有效地响应变化,同时它鼓励团队沟通,强调软件的交付而不是中间产品,将客户也作为团队中的一员。

敏捷软件开发的拥护者们强调“人的因素”,根据特定人员和团队来塑造过程。它对团队成员有以下要求:基本能力、共同目标、精诚合作、决策能力、模糊问题解决能力、、相互信任和尊重、自组织。

在敏捷开发的过程中,使用最广泛的一个方法就是极限编程。它更加看重开发团队和客户之间的口头交流而不是大量的文档。

为了简洁和能够有效地响应变化,极限编程要求开发人员只需要对即时需求做出设计,而不考虑长远需求,从而使得代码简单并且当需求变化时能够实现重构。

 

极限编程过程

极限编程使用面向对象方法作为开发范型,包含了策划、设计、编码、测试4个框架活动的规则和实践。

策划活动是团队技术成员理解软件的商业背景和客户需求的阶段,在这个阶段,开发者倾听一系列“用户故事”,描述需要的功能,并对其分配相应的优先级。

在设计活动中,开发人员遵循保持简洁原则,不鼓励额外的设计。并使用CRC卡来确定与当前软件增量相关的面向对象类。

在编码活动中,开发人员首先开发本次编码所需要的测试单元,编码人员则以实现功能已通过测试单元为目标,而不需要其他的任何东西。

在测试阶段,根据客户所规定的技术条件,向客户展示软件的功能。

除了极限编程以外,还有许多其他的敏捷编程模型,比如自适应软件开发、Scrum、动态系统开发方法、Crystal、特征驱动开发、精益软件开发、敏捷建模、敏捷统一过程,本文在此不一一介绍了。

与传统软件开发方法相比,敏捷软件开发有着一些很明显的优点。它以人为本,更加注重人与人之间的交流而不是生硬的文档。客户也作为团队的一员参加到软件开发过程中来,这样可以与客户进行更好的沟通交流,以便更好地响应需求的变化。但是,敏捷软件开发也有一些缺陷,它是一种轻量级的开发方法,它的快速是牺牲问题分析和方案设计来实现的,因此只适用于小规模的软件工程,在面对大规模的工程是就有可能出现混乱。

参考资料

  1. 智库百科:瀑布模型
  2. CSDN博客:敏捷软件开发与传统软件工程的比较
  3. 《软件工程实践者的研究方法》
  4. 爱编程博客:传统软件开发VS.敏捷软件开发

转载于:https://www.cnblogs.com/zhanzh/p/5989746.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值