软件设计中常用的开发模型

简介: 软件设计中常用的开发模型

瀑布模型

该模型是由上至下一次性完成整个项目的开发方式。该模型一共分为6个阶段,如图所示:

在瀑布模型的开发过程中需要严格的按照这条线执行,只有完成当前阶段之后才能够进行下一阶段的开发任务。

优点
  • 该模型划分出了每个阶段的检查点,当一个阶段开发完成之后,开发人员的精力可以全部的投入下个阶段,有利于提高开发效率,便于项目的管理。
  • 比较适用于前期的软件开发与小型软件系统的开发中。
缺点
  • 无法评估项目进度。因为不知道哪个阶段会造成项目的延期
  • 无法适应用户的需求变更,只能等到项目完成后,用户才能够看到项目结果

快速原型模型

快速原型模型与瀑布模型相反,项目初期根据用户的需求快速构建一个可以运行的系统原型,之后向用户展示,由用户进行审核,提出意见,然后逐步丰富项目需求。当需求真正确定后,才正式进行项目开发。模型如图所示:

优点
  • 解决需求不明确带来的风险,适用于不能提前确定项目需求的项目
缺点
  • 不利于开发人员对产品进行扩展

迭代模型

迭代模型又被称作为增量模型或演化模型,它将一个完整的软件拆分成不同的组件,之后对每个组件进行逐步的开发测试,每当完成一个组件就会向客户进行展示,让客户确认该组件功能与性能是否达到要求,最终确定无误,将组件集成到软件体系结构中。整个开发工作被分为为一系列短期、简单的小项目,称为一系列迭代,每一个迭代都需要经过需求分析、软件设计、编码、测试这几项过程,其开发过程如图所示:

优点
  • 第一个可交付版本的软件所需的成本与时间较小
  • 能够适应客户的需求变更,当需求变化时,只需要修改某一个组件即可。
缺点
  • 如果对用户需求的变更没有整体的规划,可能会变化为"边做边开发"的模式。
  • 最终集成各个组件时,可能会出现集成失败的风险。

喷泉模型

该模型主要采用面向对象技术。当客户需求基本类似时,在开发过程中可以采用面向对象的开发方式,将相同的模块全部封装起来,以便于下次功能开发时使用。模型如图所示:

优点
  • 支持软件重用,并且开发过程无间隙性,分析、设计编码无明显边界,可交叉迭代进行。使软件在无法排除重大风险时有机会停止,以减小损失。
缺点
  • 由于喷泉模型在各个阶段是重叠的,即每个对象都有分析、设计和编码阶段,所以需要大量开发人员。
  • 大量开发人员不利于项目的管理。
  • 该模型需要严格管理文档,会增加审核的难度增大。

螺旋模型

螺旋模型融合了瀑布模型,快速原型模型,该模型最大的特点就是引入了其他模型所没有的风险分析。

螺旋模型将开发过程都分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,在每个周期开始之前都会进行风险分析。在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。模型如图所示:

该模型共有四个象限,每个象限的含义如下:

  • 制订计划:确定软件目标,制订实施方案,并且列出项目开发的限制条件。
  • 风险分析:评价所制订的实施方案,识别风险并消除风险。
  • 实施工程:开发产品并进行验证。
  • 客户评估:客户对产品进行审核评估,提出修正建议,制订下一步计划。
优点
  • 螺旋模型强调风险分析,对每个演化层出现的风险都所了解,继而做出应有反应。因此特别适合用于庞大、复杂并且具有高风险的系统。螺旋模型支持用户需求的动态变化有助于提高产品的适应能力。
缺点
  • 过多的迭代次数会增加开发成本,延迟提交时间。

敏捷模型

在现代社会的开发中,由于业务会经常快速的变化,因此会导致在软件开发之前经常是无法得到详细完整的开发需求,没有完整的开发需求,传统的软件开发模型也就无法适用。

敏捷开发模型的提出就是为了解决该问题。该模型以客户的需求为核心,采用迭代,循序渐进的方法进行开发。

软件项目在构建初期会被拆分为多个相互联系而又独立运行的子项目,然后迭代完成各个子项目。开发过程中,各个子项目都要经过开发测试。当客户有需求变更时,敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中,软件一直处于可使用状态。

该模型更重视人在软件开发中的作用。软件开发过程中,各个部门需要紧密的合作沟通,为适应软件需求的频繁改变,客户可以全程参与到开发过程中。

敏捷开发模型的价值与原则
  • 个体和交互重于过程和工具
  • 可用软件重于完备文档
  • 客户协作重于合同谈判
  • 响应变化重于遵循计划
优点
  • 用户很快可以看到一个基线架构版的产品
  • 敏捷注重市场快速反应能力,客户前期满意度高。
缺点
  • 注重人员的沟通
  • 忽略文档的重要性
  • 如果项目人员流动大太,会增加项目维护难度
  • 软件之前版本的可重现性、可回溯性较低
  • 对于较大的项目,人员越多,面对面的有效沟通越困难。因此,该模型适用于小型项目的开发。
相关文章
|
6月前
|
Devops 测试技术 项目管理
软件体系结构 - 需求工程
【4月更文挑战第3天】软件体系结构 - 需求工程
72 11
|
6月前
|
存储 测试技术 BI
软件体系结构 - 系统分析与设计(2.面向对象方法)
【4月更文挑战第6天】软件体系结构 - 系统分析与设计(2)
98 0
|
设计模式 算法 uml
软件设计
软件设计是软件工程中的一个重要阶段,它是在需求分析的基础上,根据用户需求和系统架构,制定软件的具体设计方案,包括软件的模块划分、接口设计、数据结构设计、算法设计、界面设计等。
82 0
|
消息中间件 架构师 安全
重新认识架构 — 不只是软件设计
通常情况下,人们对架构的认知仅限于在软件工程中的定义:架构主要指软件系统的结构设计,比如常见的 SOLID 准则、DDD 架构。一个良好的软件架构可以帮助团队更有效地进行软件开发,降低维护成本,提高系统的可扩展性和可维护性。这里的架构定义有更多元化的理解:架构不仅是对软件开发设计和流程规范的定义,也包含了参与架构设计的人员、以及项目过程中和架构有关的活动,都可以称为架构。 从广义角度来理解架构,意味着更全面的思考和新的融合。
49 0
|
4月前
|
算法 安全 测试技术
|
6月前
|
敏捷开发 设计模式 Devops
深入理解软件测试中的自动化框架设计原则
【5月更文挑战第26天】 在现代软件开发周期中,自动化测试已成为确保产品质量和加快交付速度的关键因素。本文将探讨自动化测试框架的设计原则,旨在为读者提供如何构建一个高效、可靠且易于维护的自动化测试框架的洞见。通过对框架设计模式的深入分析,以及实际案例研究,我们阐述了如何优化测试脚本的重用性、可扩展性和灵活性。文章还讨论了持续集成环境中自动化框架的最佳实践,帮助团队有效地实施自动化策略,并最终实现更快的反馈循环和更高的产品质量。
|
6月前
|
敏捷开发 监控 算法
软件开发方法
软件开发方法
|
数据可视化
52【软件设计】软件设计方法归纳总结
软件设计方法有:**结构化设计**(数据流图为依据)、**面向对象设计**(面向对象概念为依据);
193 0
|
消息中间件 架构师 安全
重新认识架构—不只是软件设计
结合自身经历阐述架构师定位、架构活动如何保障企业、组织实现商业价值。
重新认识架构—不只是软件设计
|
设计模式 消息中间件 JSON
软件设计到底是什么?
软件设计是什么: 就是讨论要用什么技术实现功能? 就是要考虑选择哪些框架和中间件? 设计就是设计模式?
205 0