摘自:
https://blog.csdn.net/qq_21168173/article/details/111402783
《软件设计师教程》247页
介绍
软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。
对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。
典型的软件过程模型
- 瀑布模型
- 增量模型
- 演化模型(原型模型、螺旋模型)
- 喷泉模型
- 基于构件的开发模型
- 形式化方法模型
模型对比
| 规模 | 需求明确 | 需求变化 | 复杂 | 面向对象 | 其他 | |
|---|---|---|---|---|---|---|
| 瀑布模型 | 小型 | 明确 | 少变化 | |||
| 瀑布模型-V模型 | 小型 | 明确 | 少变化 | |||
| 瀑布模型-增量模型 | 大型 | 明确 | 少变化 | 可尽快投入使用 | ||
| 演化模型-迭代模型 | 不明确 | 可尽快投入使用(快) | ||||
| 演化模型-原型模型 | 不很大 | 不明确 | 经常变化 | 不太复杂 | 可尽快投入使用(慢) | |
| 演化模型-螺旋模型 | 大型 | 不明确 | 经常变化 | 复杂 | 适合风险大 | |
| 喷泉模型 | 面向对象 | 迭代和无间隙 | ||||
| RUP统一过程模型 | ||||||
| 敏捷开发模型 |
瀑布模型(传统模式)
瀑布模型是将软件生存周期中的各个活动规定为依 线性顺序 连接的若干阶段的模型,包括:
- 需求分析
- 设计
- 编码
- 测试
- 运行与维护
规定了由前至后、相互衔接的固定次序,如同瀑布流水逐级下落
适用场景
面向过程、以文档为驱动、需求明确、低风险项目、适合小型项目
不适合用户需求经常变化
生命周期
优点
- 为项目提供了按阶段划分的检查点。
- 当前一阶段完成后,您只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点
- 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
- 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,或者发现错误,从而增加了开发风险。
- 瀑布模型的突出缺点是不适应用户需求的变化。
瀑布模型 - V模型
瀑布模型的变体,解决 瀑布模型的缺点
随着软件团队工作沿着V模型 左侧步骤 向下推进,基本问题需求逐步细化,形成问题及解决方案的技术描述。
编码结束,团队沿着V模型 右侧步骤 向上推进工作,其实际上是执行了一系列测试(质量保证活动),这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种 将验证确认活动应用于早期软件工程工作 中的方法。
测试贯穿始终
适用场景
适用于功能很明确的项目,先有测试案例,开发出的程序通过测试案例进行验证
生命周期(考)
优点
容易理解,管理成本低;强调开发的阶段性早期计划及需求调查和产品测试
缺点
- 客户必须能够完整、正确和清晰地表达他们的需要;
- 在开始的两个或 3个阶段中,很难评估真正的进度状态;
- 当接近项目结束时,出现了大量的集成和测试工作;
- 直到项目结束之前,都不能演示系统的能力
- 需求或设计中的错误往往只有到了项目后期才能够被发现
瀑布模型 - 增量模型
增量模型融合了 瀑布模型 的基本成分和 原型 实现的迭代特征
第1个增量往往是 核心产品。将需求分段为一系列增量产品,每一增量可以分别开发。
适用场景
大型项目、渐近开发、逐步完善、有效规避技术风险
生命周期
该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”,如下图
优点
具有瀑布模型的所有优点,还具备下面优点:
- 第一个可交付版本 所需要的成本和时间很少;
- 开发由增量表示的小系统所承担的风险不大;
- 由于很快发布了第一个版本,因此可以减少用户需求的变更;
- 运行增量投资,即在项目开始时,可以仅对一个或两个增量投资。
缺点
- 不利于模块划分,原本核心模块,在中后期可能就不是了
如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;
如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,重新发布;
管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
演化模型
演化模型是 迭代的过程模型,使得软件开发人员能够逐步开发出更完整的软件版本。
典型的演化模型有:
- 原型模型
- 螺旋模型
适合场景
适用于对 软件需求缺乏准确认识 的情况
演化模型 - 原型模型(快速原型模型)
在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。
适用场景
- 适合于用户 需求不清、需求经常变化 的情况
- 当系统 规模不是很大、不太复杂
生命周期
优点
克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。
缺点
所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
演化模型 - 螺旋模型
对于 复杂的大型软件,使用 原型模型 开发一个原型往往达不到要求。
螺旋模型将 瀑布模型 和 演化模型 结合起来,加入 风险分析。
适用场景
特别适用于 庞大、复杂 并且具有 高风险 的系统
优点
- 支持 用户需求变化
- 要求开发人员具有风险分析能力
- 适用于大规模、复杂的项目
- 需要多次迭代,导致 开发成本较高
生命周期
将开发过程分为几个螺旋周期,每个螺旋周期大致和 瀑布模型 相符合,如图所示。
每个螺旋周期分为如下4个工作步骤:
- 制订计划。确定软件的目标,选定实施方案,明确项目开发的限制条件。
- 风险分析。分析所选的方案,识别风险,消除风险。
- 实施工程。实施软件开发,验证阶段性产品。
- 用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
喷泉模型
以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。开发过程具有 迭代性 和 无间隙
迭代:模型中的开发活动常常需要重复多次,在迭代过程中不断地完善软件系统
无间隙:在开发活动(如分析、设计、编码)之间不存在明显的边界,而是允许各开发活动 交叉、迭代地进行
对比 瀑布模型
克服了 瀑布模型 不支持软件重用 和 多项开发活动集成的局限性。
适用场景
面向对象开发
生命周期
优点
该模型的各个阶段没有明显的界限,开发人员可以同步进行开发。可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程。
缺点
由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大
敏捷方法
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
优点
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
缺点
敏捷注重人员的沟通,忽略文档的重要性,若项目人员流动大太,又给维护带来不少难度,特别项目存在新手比较多时,老员工比较累
敏捷方法 - 极限编程
是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。
由下面4个部分组成,彼此相互依赖、关联,并通过行为贯穿于整个生存周期:
- 价值观
- 原则
- 实践
- 行为
4大价值观
- 沟通
- 简单性
- 反馈
- 勇气
5个原则
- 快速反馈
- 简单性假设
- 逐步修改
- 提倡更改
- 优质工作
12个最佳实践
- 计划游戏(快速制定计划、随着细节的不断变化而完善)
- 小型发布(系统的设计要能够尽可能早地交付)
- 隐喻(找到合适的比喻传达信息)
- 简单设计(只处理当前的需求,使设计保持简单)
- 测试先行(先写测试代码,然后再编写程序)
- 重构(重新审视需求和设计,重新明确地描述它们以符合新的和现有的需求)
- 结对编程:对代码的审查过程,解决代码质量低的问题,编码速度不能改变
- 集体代码所有制
- 持续集成(可以按日甚至按小时为客户提供可运行的版本)
- 每周工作40个小时
- 现场客户:系统最终用户代表应该全程配合XP团队
- 编码标准
敏捷方法 - 水晶法
水晶法认为每一个不同的项目都需要一套 不同的策略、约定和方法论,认为 人对软件质量有重要的影响,因此随着项目质量和开发人员素质的提高,项目和过程的质量也随之提高。通过更好地交流和经常性的交付,软件生产力得到提高。
敏捷方法 - 并列争求法(Scrum)
并列争求法使用 迭代 的方法,其中,把每30天一次的 迭代 称为一个 冲刺周期,并按需求的优先级别来实现产品。
多个自组织和自治的 小组 并行 地 递增实现产品
协调是通过简短的日常情况会议来进行,就像橄榄球中的“并列争球”。
敏捷方法 - 自适应软件开发(ASD)
核心是三个非线性的、重叠的开发阶段:
- 猜测
- 合作
- 学习
ASD有6个基本的原则:
- 有一个使命作为指导;
- 特征被视为客户价值的关键点;
- 过程中的等待是很重要的,因此“重做”与“做”同样关键;
- 变化不被视为改正,而是被视为对软件开发实际情况的调整;
- 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;
- 风险也包含其中
敏捷方法 - 敏捷统一过程(AUP)
采用 在大型上连续 以及在 在小型上迭代 的原理来构建软件系统。
采用经典的UP阶段性活动(初始、精化、构建和转换)
每个AUP迭代执行以下活动:
- 建模。建立对商业和问题域的模型表述,这些模型“足够好”即可,以便团队继续前进。
- 实现。将模型翻译成源代码。
- 测试。像XP一样,团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
- 部署。对软件增量的交付以及获取最终用户的反馈。
- 配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
- 环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。
RUP统一过程模型
又称为 统一过程,是 “用例和风险驱动,以架构为中心,迭代并且增量” 的开发过程
迭代:将整个软件开发项目划分为许多个小的“袖珍项目”,每个“袖珍项目”都包含正常软件项目的所有元素:
- 计划
- 分析
- 设计
- 构造
- 集成和测试
- 以及内部和外部发布
生命周期
分为四个连续的阶段:
- 初始阶段
- 细化阶段
- 构建阶段
- 交付阶段
优点
- RUP是建立在非常优秀的软件工程原则基础上的,基于结构化的过程开发。
- RUP提供了几个方法,这些方法提供了对开发过程的非常直观的管理。
缺点
- RUP仅仅包含了开发过程,它没有完全覆盖软件过程。
- RUP不支持组织内的多项目开发,导致组织内的大范围的重用无法实现。
- RUP缺少开发商的支持。
题
某企业拟开发一个企业信息管理系统,系统功能与多个部门的业务相关。现希望该系统能够尽快投入使用,系统功能可以在使用过程中不断改善。则最适宜采用的软件过程模型为()
A、瀑布模型
B、原型模型
C、演化(迭代)模型
D、螺旋模型
分析
题目指出要 尽快投入使用,在使用中不断完善
瀑布模型:要一次性做完,不符合要求,错
原型模型:适合需求不清晰,但题目中需求是明确的,不符合,错
螺旋模型:适合庞大、复杂、高风险的项目,不符合,错
答案
C
题
关于螺旋模型,下列陈述中不正确的是()()
A、将风险分析加入到瀑布模型中
B、将开发过程划分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符
C、适合于大规模、复杂且具有高风险的项目
D、可以快速的提供一个初始版本让用户测试
A、支持用户需求的动态变化
B、要求开发人员具有风险分析能力
C、基于该模型进行软件开发,开发成本低
D、过多的迭代次数可能会增加开发成本,进而延迟提交时间
分析
可以快速的提供一个初始版本让用户测试是原型模型的特点
答案
D
C
题
以下关于增量开发模型的叙述中,不正确的是()
A、不必等到整个系统开发完成就可以使用
B、可以使用较早的增量构件作为原型,从而获得稍后的增量构件需求
C、优先级最高的服务先交付,这样最重要的服务接受最多的测试
D、有利于进行好的模块划分
分析
不利于模块划分,原本核心模块,在中后期可能就不是了
答案
D
题
在敏捷过程的开发方法中,()使用了迭代的方法,其中,把每段时间(30天)一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。
A、极限编程XP
B、水晶法
C、并列争球法
D、自适应软件开发
答案
C
题
极限编程(XP)的十二个最佳实践不包括()
A、小的发布
B、结对编程
C、持续集成
D、精心设计
答案
D
参考:
https://blog.csdn.net/qq_21168173/article/details/111402783






