软件生命周期模型软件过程模型构建-修复模型(太原始, 不能算模型)描述特征瀑布模型(⽂档驱动)描述特征增量迭代模型(需求驱动)描述特征演化模型(需求驱动)描述特点原型模型(需求驱动)描述特点螺旋模型(风险驱动)描述特点软件工程知识体系的知识域
软件生命周期模型
解释与比较不同过程模型(要求, 特征描述, 优缺点)
对给定的场景, 判定适用的开发过程模型
软件工程知识体系的知识域
软件生命周期模型
界定了软件开发的不同阶段, 以及阶段之间的顺序关系
为了从宏观上清晰地描述软件开发活动, 人们将软件从生产到报废的生命周期分割为不同阶段.
每个阶段都有明确的典型输入/输出, 主要活动及其执行人, 各个阶段组成明确, 连续的顺序过程.
这些阶段划分就被称为软件生命周期模型.
- 需求工程 → 建立能够妥善解决用户问题的软件系统解决方案, 即定义软件系统要完成哪些功能
- 软件设计 → 使用各种抽象软件实体建立系统的结构, 搭建系统的实现框架, 即定义系统要如何完成功能
- 软件实现 → 完成软件构造任务(编程, 集成, 测试, 调试)
- 软件测试 → 保障软件产品质量(单元测试, 集成测试, 系统测试)
- 软件交付 → 将软件产品交付给用户, 主要任务包括安装与部署, 用户培训, 文档支持等
- 软件维护 → 保障用户从接收产品到软件生命终结之间的正常使用, 包括完善性维护, 适应性维护, 修正性维护和预防性维护
软件过程模型
进一步详细说明各个阶段的任务, 活动, 对象及其组织, 控制过程
构建-修复模型(太原始, 不能算模型)
最早最自然产生的软件开发模型.
不能算是一个软件过程模型, 对软件开发活动没有任何组织和规划, 完全依靠开发人员个人能力
描述
开始生产软件时, 依靠个人分析和理解直接构建软件的第一个版本, 并提交给用户使用. 没有质量保证, 修复发现的所有缺陷后才算完成有效交付, 进入维护阶段.
特征
全是缺点:
- 没有对开发过程进⾏规范和组织, 因此⼀旦开发过程超出个⼈控制能⼒, 就会导致开发过程⽆法有效进⾏⽽失败
- 没有对需求的真实性进⾏分析
- 没有考虑软件结构的质量, 导致结构在修改中越来越糟, 直⾄⽆法修改
- 没有考虑测试和程序的可维护性, 也没有任何⽂档, 导致难以维护
适⽤:
- 软件规模很⼩, 只需要⼏百⾏程序, 其开发复杂度是个⼈能⼒能够胜任的;
- 软件对质量的要求不⾼, 即使出错也⽆所谓;
- 只关注开发活动, 对后期维护的要求不⾼, 甚⾄不需要进⾏维护.
瀑布模型(⽂档驱动)
将软件开发活动划分为不同的阶段, 并且保障每一个阶段工作的正确性和有效性, 尤其重视分析和设计阶段.
描述
按照软件生命周期模型将软件开发活动组织为需求开发, 软件设计, 软件实现, 软件测试, 软件交付和软件维护等基本活动, 规定它们自上而下, 相互衔接的次序, 按照”从一个阶段到另一个阶段的有序的转换序列”的方式来组织开发活动.
瀑布模型允许活动出现反复和迭代, 真正的重点在于每个活动的结果需要验证, 并且只有在经过验证之后才能作为后续开发活动的基础.
可执行代码产生之前, 模型与文档是唯一能用来验证的东西, 所以瀑布模型特别重视文档和模型, 故瀑布模型是文档驱动的, 按照文档的划分, 产生和验证来规划, 组织和控制开发活动.
特征
特点:
- 对于软件开发活动有明确阶段划分
- 每个阶段的结果都必须验证, 使得该模型是“⽂档驱动”
优点:
- 清晰的阶段划分有利于开发者以关注点分离的⽅式更好的进⾏复杂软件项⽬的开发.
缺点:
- 对⽂档期望过⾼(过于依赖文档效果);
- 对开发活动的线性顺序假设(希望把上一步做好再开始下一步, 但实际上常常需要一定的后续工作才能验证当前工作, 例如完成体系结构原型关键代码才能验证体系结构设计的有效性);
- 客户、⽤户参与度不够(需求被限制为一个阶段, 导致客户和用户的参与被限制在⼀个时间段, 无法从始至终参与)
- ⾥程碑粒度过粗(软件复杂使得每个阶段时间过长, ⽆法尽早发现缺陷, 丧失了早发现早修复的初衷). 所有开发完成之后客户和用户才能看到软件产品, 具有极高的风险.
适用:
- 需求⾮常成熟、稳定, 没有不确定的内容, 也不会发⽣变化(确保要做的都是对的);
- 所需的技术成熟、可靠, 没有不确定的技术难点, 也没有开发⼈员不熟悉的技术问题(每个阶段可估计);
- 复杂度适中, 不⾄于产⽣太⼤的⽂档负担和过粗的⾥程碑.
增量迭代模型(需求驱动)
与演化模型互为补充
瀑布模型对于开发活动的线性顺序假设具有局限性, 实际开发中绝大多数复杂系统都是需要迭代完成的(迭代性).
周期过长和渐进交付, 时间压力和并行开发等问题也促使了增量迭代模型的产生和普及.
描述
增量迭代模型在项目开始时, 通过系统需求开发和核心体系结构设计活动完成项目对前景和范围的界定, 然后再将后续开发活动组织为多个迭代, 每个迭代为并行的瀑布式开发活动.
需要在项目早期就确定项目的目标和范围, 因此项目需求要比较成熟和稳定, 不能出现数量太多的不确定性和影响太大的需求变更.
每个迭代的增量需求相对独立, 可以被开发为产品的独立部分交付给用户. 不同的增量迭代形成渐进交付和并行开发的效果. 第一个迭代完成的往往是产品的核心部分, 满足基本需求, 但是很多附带特性还需要后续迭代完成(举例: iOS18随小版本更新逐步上线某某附加功能).
增量需求是增量迭代模型进行迭代规划, 开发活动组织和控制的重要依据, 因此它是需求驱动的.
特征
特征:
- 项⽬开始时, 通过系统需求开发和核⼼体系结构设计活动完成项⽬的前景和范围的界定
- 将后续开发活动组织为多个迭代、并⾏的瀑布式开发活动.
- 第⼀个迭代完成的往往是核⼼⼯作, 满⾜基本需求, 后续迭代完成附带特性.
优点:
- 更符合软件开发实践
- 并⾏开发可以缩短产品开发时间
- 渐进交付可以加强⽤户反馈, 降低开发风险.
缺点:
- 软件需要有开放式的体系结构, 加入构件必须不破坏已构造好的系统结构.
- 增量迭代模型需要一个完备, 清晰的项目前景和范围以进行并行开发规划, 但是不确定性太多, 难以在项⽬开始就确定前景和范围
适⽤:
- ⽐较成熟和稳定的领域
演化模型(需求驱动)
与增量迭代模型相比, 都是用迭代式组织开发活动, 都适合大规模软件开发, 但增量迭代模型适用于比较成熟稳定的领域, 而演化模型主要用在需求变更比较频繁或不确定性较多的领域.
描述
- 将软件开发活动组织为多个迭代、并⾏的瀑布式开发活动.
- 在初始开发迭代中, 主要任务是澄清和明确系统的核⼼需求, 建⽴和交付核⼼系统.
- 得到核⼼系统后, ⽤户在使⽤中发现变更需求、澄清不确定需求, 并反馈给开发⼈员.
- 软件开发⼈员根据⽤户反馈规划后续迭代, 精化和增强系统.
因此演化模型每次迭代的需求不是独立的, 设计和实现工作也是在前一次迭代基础上进行修改和扩展.
演化模型的多个迭代联合起来可以实现渐进交付和并行开发的结果.
对需求的反馈是演化模型进行迭代规划, 开发活动组织和控制的主要依据, 因此它是需求驱动的(总需求分解为一个核心需求和多个并行的增量需求).
特点
优点:
- 适⽤于需求变更频繁或者不确定性多的系统的开发
- 并⾏开发可以缩短开发时间
- 渐进交付可以加强⽤户反馈, 降低开发风险
缺点:
- ⽆法在项⽬早期确定项⽬范围, 所以整体计划, 进度调度, 商务协商事宜无法准确把握
- 后续迭代活动以前导迭代为基础, 容易使后续迭代忽略分析与设计工作, 退化为构建－修复⽅式.
适⽤:
- 不稳定领域的⼤规模软件系统
原型模型(需求驱动)
原型定义: 原型是⼀个系统, 它内化了⼀个更迟系统的本质特征. 原型系统通常被构造为不完整的系统, 以在将来进⾏改进、补充或者替代.
人话: 还没造出来的东西的小样, 用于展示/推敲其核心功能.
- 演化式原型: 被扩展之后成为真正的产品, 必须具有很好的质量. 在迭代式开发中, 通常会在第⼀个迭代中构建⼀个核⼼的体系结构演化式原型, 并在后续迭代中不断扩充, 最终成为真正的软件产品.
- 抛弃式原型: 模拟真正产品但不会出现在真正产品中, ⽽在真正产品中出现的是⽐原型质量更好的改进和替代. 存在的目的是模拟未来的产品, 进行推敲, 以解决不确定性. 因为构建原型时⾯临不确定性, 那么在澄清的过程中就难免会调整和修改原型, 最终使得原型的质量⽆法保障. 所以这⼀类原型通常不出现在真正的产品中, 需要抛弃后另⾏开发质量更好的改进或替代.
原型模型的基本特征是注重使用抛弃式原型, 适用于不确定性较多情况下的开发.
原型模型主要在需求开发阶段使用原型解决需求的不确定性.
描述
为了解决不确定性, 原型模型将需求开发活动展开为抛弃式原型开发的迭代, 充分利⽤抛弃式原型解决新颖领域的需求不确定问题.
在抛弃式原型的帮助下, 解决了不确定性之后, 可以得到清晰需求, 这时再按照瀑布模型⽅式安排后续开发活动.
在整体开发活动组织上, 可以通过多次原型开发迭代得到所有的清晰需求, 这样后续的瀑布式开发活动就可以按线性顺序安排.
也可以安排整体迭代, 每次整体迭代中通过原型开发得到部分清晰需求, 并采⽤瀑布式完成后续开发.
在整体安排迭代的情况下, 原型模型就是强调 “抛弃式原型⽅法”的演化模型.
驱动原型模型的可以是需求(按照需求的重要性进⾏迭代规划、开发活动组织和控制)也可以是风险(按照⻛险程度, 即因为不确定性⽽可能造成的损害程度进⾏迭代规划、开发活动组织和控制).
特点
具有演化模型的特点, 所以也具有演化模型的优缺点.
特点:
- ⼤量使⽤抛弃式原型, 通过模拟“未来”的产品, 将“未来”的知识置于“现在”进⾏推敲, 解决不确定性
优点:
- 加强与客户、⽤户的交流, 更好的产品满意度
- 适⽤于不确定性⼤的新颖领域
缺点:
- 能够解决风险, 也会带来新的风险 → 原型开发成本较⾼, 有耗尽时间和费⽤的风险
- 有⼈不舍得抛弃“抛弃式原型”, 使得较差代码进⼊产品, 降低质量
适⽤:
- 有着⼤量不确定性的新颖领域
螺旋模型(风险驱动)
基本思想: 尽早解决⽐较⾼的⻛险, 如果有些问题实在⽆法解决, 那么早发现⽐项⽬结束时再发现要好, ⾄少损失要⼩得多.
描述
螺旋模型是⻛险驱动(risk-driven)的, 完全按照⻛险解决的⽅式组织软件开发活动.
风险解决的基本思路:
- 确定⽬标、解决⽅案和约束
- 评估⽅案, 发现⻛险
- 寻找⻛险解决⽅法
- 落实⻛险解决⽅案
围绕这个思路, 螺旋模型将软件开发活动组织为风险解决的迭代, 即反复以上四个过程.
⻛险是因为不确定性⽽可能带来的损失, 所以原型⾃然是解决⻛险的有效⼿段, 螺旋模型就是充分利⽤原型⽅法解决⻛险的.
在原型⽅法的使⽤上, 原型模型主要使用原型解决需求的不确定性, 重点在于软件需求开发阶段. 螺旋模型则使⽤原型解决项⽬开发中常⻅的各类型技术⻛险, 包括系统需求开发、软件需求开发、软件体系结构设计、详细设计等各个阶段.
螺旋模型对原型的使用贯穿开发的各个阶段, 因为每个阶段都有对应的风险.
⾃内向外, 螺旋模型有4次风险解决迭代(即4圈螺旋), 分别解决软件开发中风险较⾼的⼏个阶段:
- 第1次迭代解决系统需求开发中的风险, 尤其是产品概念设计风险, 得到⼀个确定的产品前景和范围(产品操作概念与规格);
- 第2次迭代解决软件需求开发中的风险, 得到清晰的软件需求;
- 第3次迭代解决软件体系结构设计中的技术风险, 构建⾼质量的核⼼体系结构原型;
- 第4次迭代解决详细设计和实现中的关键技术风险, 建⽴⼀个可实现的⾼质量软件结构.
- 如果需要增量迭代, 那么螺旋模型还可以在第4次迭代之外再增加第5次迭代, 以与第4次迭代相似的⽅式组织增量需求的后续开发活动(详细设计和实现的风险解决及实际开发).
螺旋模型的4次迭代与第4次迭代右下象限的活动⼀起, 构成了软件开发的瀑布模型, 所以螺旋模型是风险解决迭代与瀑布模型的综合.
特点
特点:
- 基本思想是尽早解决⽐较⾼的风险, 如果有些问题实在⽆法解决, 那么早发现⽐项⽬结束时再发现要好, ⾄少损失要⼩得多.
- 风险是指因为不确定性(对未来知识了解有限)⽽可能给项⽬带来损失的情况
- 原型能够澄清不确定性, 所以原型能够解决风险.
- 迭代与瀑布的结合: 开发阶段是瀑布式的, 风险分析是迭代的.
优点:
- 降低风险, 减少因风险造成的损失
缺点:
- 使⽤原型⽅法, 为⾃⾝带来风险(与原型模型相同)
- 模型过于复杂, 不便于管理开发活动.
适⽤性:
- ⾼风险的⼤规模软件系统开发
Gemini: 我们来详细介绍一下螺旋模型(Spiral Model), 并在必要时加入非形式化的解释.
什么是螺旋模型?
螺旋模型是一种风险驱动的软件开发生命周期模型. 它由 Barry Boehm 于 1986 年提出. 它的最大特点是将瀑布模型(强调顺序、阶段性) 的阶段性、原型模型(强调快速反馈) 的迭代性以及风险分析结合起来.
想象一下, 它不像一条直线(瀑布), 也不像一个简单的圈(迭代). 它更像一个螺旋上升的弹簧.
- 螺旋(Spiral): 意味着项目会像螺旋一样, 一圈一圈地向前推进. 每完成一圈, 项目就更进一步, 产品的功能更完善, 对需求的理解更深入, 同时风险也得到了更好的控制.
- 模型(Model): 指的是一种指导软件开发过程的方法论.
非形式化解释:
你可以把螺旋模型想象成一个探险队在迷雾森林里找宝藏.
- 目标不完全明确: 宝藏具体在哪, 路上有什么危险, 一开始都不知道.
- 每走一段路, 就停下来:
- 看看地图(风险分析): 分析下一步可能遇到的危险, 比如有没有沼泽、有没有猛兽.
- 做个小尝试(原型/开发): 比如先派个侦察兵去前面探路, 或者搭个简易的木桥过河.
- 总结经验(评估): 侦察兵带回了什么情报?木桥牢不牢固?
- 规划下一步(计划): 根据这次的经验和发现, 规划下一段路怎么走, 要带什么装备.
- 循环往复, 直到找到宝藏: 每次前进一小段, 都更加明确了方向, 规避了风险, 也更接近最终目标. 这个“一小段”就是螺旋模型中的“一个迭代圈”.
螺旋模型的四个象限/活动
螺旋模型的每一圈通常包含以下四个主要的活动象限:
- 目标设定与替代方案识别(Objective Setting and Identification of Alternatives):
- 做什么? 确定当前迭代(或这一圈)的目标、限制条件(如预算、时间、性能要求).
- 有什么选择? 识别实现这些目标的替代方案.
- 非形式化解释: 就像探险队坐下来讨论: “我们这周要向东走, 目标是找到那条河. 有没有别的路可以走?是划船去还是走陆路?”
- 风险评估与化解(Risk Assessment and Reduction):
- 有什么危险? 对上一个象限识别出的各种方案进行风险评估, 分析可能存在的风险(如技术风险、需求不确定性、预算超支、时间延误等).
- 怎么避免/解决? 制定策略来降低这些风险, 这可能包括进行原型开发、模拟、基准测试、用户调查等.
- 非形式化解释: 探险队发现: “向东走可能遇到沼泽!那我们就先派无人机去探探路(原型开发), 或者找个当地向导问问(用户调查), 看看有没有旱路. ”这是螺旋模型最核心、最重要的部分.
- 开发与验证(Development and Validation):
- 动手做! 根据风险分析的结果和规划, 选择最佳方案, 进行实际的软件开发、编码、测试. 这部分可能包含瀑布模型的各个阶段(需求、设计、编码、测试).
- 检查成果! 对开发出来的产品进行验证, 确保它满足需求并符合质量标准.
- 非形式化解释: “好了, 无人机探完路了, 发现有条小径!那就按照这个方案, 大家开始行动, 修路、搭建营地, 然后检查一下, 看看搭的营地牢不牢固. ”
- 评审与计划(Planning the Next Phase / Review):
- 做得怎么样? 对当前迭代的结果进行评审, 包括产品是否达到目标、风险是否得到有效控制.
- 下一步怎么走? 根据评审结果和新的认识, 为下一个迭代制定详细的计划. 确定下一次迭代的范围、目标和风险关注点.
- 非形式化解释: “我们完成了这周的任务, 修好了路, 也安顿好了. 现在大家总结一下, 哪些做得好?哪些地方还危险?然后我们商量下周的目标是去哪里, 大概要准备什么. ”
螺旋模型的优点:
- 风险驱动: 这是最核心的优势. 它将风险管理贯穿于整个开发过程, 能及早发现并处理潜在问题, 降低项目失败的概率.
- 适应性强: 能够很好地适应需求不确定性高、需求不断变化的项目.
- 灵活性高: 结合了瀑布和原型的优点, 允许在不同阶段采用不同的开发策略.
- 增量式开发: 每次迭代都产生一个更完善的软件版本, 用户可以尽早看到部分功能并提供反馈.
螺旋模型的缺点:
- 风险管理复杂: 需要经验丰富的风险管理专家, 如果风险识别和处理不当, 项目容易失控.
- 成本高: 每次迭代都需要进行完整的风险评估和计划, 可能导致文档和管理开销较大.
- 周期长: 对于小型或需求明确的项目, 可能显得过于繁琐, 导致开发周期变长.
- 起步阶段不明确: 如何启动第一个螺旋圈, 以及如何确定第一次迭代的规模, 对于没有经验的团队来说可能比较困难.
适用场景:
螺旋模型最适合用于:
- 大型、复杂且风险高的软件项目.
- 需求不明确或需求可能频繁变化的项目.
- 需要严格风险管理的项目.
通过以上解释, 希望能帮助你更清晰地理解螺旋模型. 它不仅仅是一个开发流程, 更是一种以风险为核心, 通过不断迭代和学习来逐步完善产品的思维方式.
软件工程知识体系的知识域
- 软件需求
- 软件设计
- 软件构造
- 软件测试
- 软件维护
- 软件配置管理
- 软件⼯程管理
- 软件⼯程过程
- 软件⼯程⼯具和⽅法
- 软件质量
补充:
- 软件工程职业实践
- 工程经济学基础
- 计算基础
- 数学基础
- 工程基础
