软件工程方法论对我们经软件开发有多大用处?谈谈你的看法。

    生产一个大型的软件都要很多人,很多团队配合。即使一个人能力非常强,能全部搞定,也不是一瞬间搞定,要一段时间做需求分析,一段时间coding,一段时间测试。这就衍生出了流程。
    不同的行业铸就了不同的软件类型,有复杂、有简单、有侧重数据、有侧重算法,开发不同的软件就需要不同的方法。
    如同切菜需要用菜刀,砍木头需要用斧子,菜刀当然也可以用于砍木头,斧子当然也可以用于切菜,但不是最好的方式,强行应用反而会降低效率。
    而软件工程方法论就是根据待开发的软件特点设计相应的开发流程,就是把一个大事情,拆分成一个一个的小事情,再把这些小事情串起来组成一个大事情。经过前人实践,效果非常好的开发流程就固定了下来,形成了“过程模型”。
    针对不同的软件情况使用不同的“过程模型”,将会大大提高我们开发软件的效率。
    我们将“过程模型”分为了以下几类:
    ## 瀑布模形
    作为在软件工程中应用得最广泛的过程模型。瀑布模型是一个经典的软件生命周期模型,一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。
    通常划分为以下六个流程:

    计划 → 需求分析 → 设计 → 编码 → 测试 → 运行维护

具有以下三个特点:
• 阶段间具有顺序性和依赖性
• 推迟实现
• 质量保证
优点:
• 可强迫开发人员采用规范的方法;
• 严格地规定了每个阶段必须提交的文档;
• 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点:
• 传统的瀑布模型过于理想化,人们在工作过程不可能不犯错误,所以实际的开发模型带有“反馈环”,早期的的错误可能要等到开发后期阶段才能发现。
.• 用户只能通过文档来了解产品,不能真正满足用户的需求。
• 由于开发模型是线性的,增加了开发的风险。
## 快速原型模型
快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。
快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。
优点:
• 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。
• 这种模型适合预先不能确切定义需求的软件系统的开发。
缺点:
• 所选用的开发技术和工具不一定符合主流的发展;
• 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
• 使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。
## 增量模型
增量模型融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。
当使用增量模型时,第1个增量往往是核心的产品,即第1个增量实现了基本的需求,但很多补充的特征还没有发布。
客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。在这里插入图片描述
特点
• 增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。
优点
• 增量模型的优点采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。
• 如果核心产品很受欢迎,则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户,对客户起到镇静剂的作用。
• 此外,增量能够有计划地管理技术风险。
缺点
• 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
• 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
• 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
## 螺旋模型
螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。
螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。
同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

在这里插入图片描述
特点:
螺旋模型是将快速原型和瀑布模型结合起来。强调了其他模型忽略的风险分析。
每次螺旋包括4个步骤:制定计划:风险分析、实施工程、客户评估。
缺点:
• 很难让用户确信这种演化方法的结果是可以控制的。
• 建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。
## 喷泉模型
喷泉模型主要用于采用对象技术的软件开发项目。
该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。
软件的某个部分常常被重复工作多次,相关对象在每次迭代中随之加入渐进的软件成分。
无间隙指在各项活动之间无明显边界,如分析和设计活动之间没有明显的界限,由于对象概念的引入,表达分析、设计、实现等活动只用对象类和关系,从而可以较为容易地实现活动的迭代和无间隙,使其开发自然地包括复用。
优点
1、喷泉模型的优点喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动。
2、该模型的各个阶段没有明显的界限,开发人员可以同步进行开发。其优点是可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程。
缺点
1、由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理。
2、此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况。
## Rational统一过程
tional Unified Process(RUP)主要适用于大型的需求不断变化的复杂软件系统项目。
统一软件过程也就是RUP:不仅仅是一个简单的软件过程,而是一个通用的过程框架,可用于不同类型的应用系统、各种不同的应用领域、各种不同类型的组织、各种不同功能和规模的项目。
它是基于构件(Component-based)的,即所构造的软件系统是由软件构件通过明确定义的接口相互链接所建造起来的。并且它使用统一建模语言(Unified Modeling Language,UML)来制定系统的所有蓝图。
统一软件过程是在软件生命周期过程中以用例为驱动、构架为中心来进行一次一次的增量式的迭代,每次迭代都是以上一次迭代为基础并生成包括构件的源代码体、需求说明、测试用例等的制品。
每次的迭代又具体分为四个阶段:初始、细化、提交和转移,而在每个阶段又分为五个工作流:需求、分析、设计、实现和测试。
统一软件开发过程是基于面向对象方法和UML统一建模语言的,用这种方法论来指导软件开发主要可以解决两个问题:
1.软件复用问题;
2.需求变化问题。
优点
1、提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。
2、它建立了简洁和清晰的过程结构,为开发过程提供较大的通用性。
缺点
1、RUP只是一个开发过程,并没有涵盖软件过程的全部内容,例如它缺少关于软件运行和支持等方面的内容;
2、此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端,但并不完美,在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。
## 敏捷过程
敏捷过程需要遵守的四项价值观:
以人为本:个体和交互胜过过程和工具
目标导向:可工作的软件胜过面面俱到的文档
客户为先:客户合作胜过合同谈判
拥抱改变:响应变化胜过遵循变化
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
优点:
1、短周期开发。
2、增量开发。
3、由程序员和测试人员编写的自动化测试来监控开发进度。
4、通过口头沟通、测试和源代码来交流系统的结构和意图。
5、编写代码之前先写测试代码,也叫测试先行。
缺点
1、团队组件较难,人员素质要求较高。
2、对测试人员要求完全掌握各种脚本语言编程,会单元测试。
总之,软件工程方法论对我们软件开发具有极大的作用,需要灵活应用。
做小型软件的使用瀑布模型,做大型软件的采用快速原型模型,做高风险软件的采用螺旋模型,做互联网软件的采用渐增模型,等等等等。采用一种开发模型,就是采用一种生产管理的方法。
任何一种标准的管理方法都无法直接适用于一个企业。完全套用标准方法只会让效率降低。最好的管理总是因实际情况而异。比如某项目规模很大,想用快速原型模型开发,但是项目的产品经理能力非常强,客户也很有经验,不需要把原型做出来,用PPT就让客户明白了绝大部分功能,也就不需要再把原型做出来让客户试用了,直接做正式版就是了。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

「已注销」

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值