软件开发生命周期模型：选择完成工作的方式
已发表: 2021-10-05“计划你的工作，按你的计划工作”的理念在历史上已经多次证明了它的效率。 适当的计划定义了任何严肃计划的成功，包括软件开发。 软件开发行业提出了多种方法来满足业务需求。
软件开发生命周期或 SDLC 定义了产品的生命周期和维护方式。 它可以帮助您将创意和市场需求转化为产品功能和特性。
简而言之，软件开发生命周期模型是一种在开发产品并将其转变为业务方面完成工作的方法。
内容：
- SDLC模型
- 瀑布模型
- V字型
- 大爆炸模型
- 原型模型
- 迭代和增量模型
- 雷达模型
- 螺旋发展模式
- 敏捷模型
SDLC模型
根据您的市场、项目背景和业务需求，您可以选择已建立的软件开发生命周期模型或创建自己的模型。
瀑布模型
软件开发史上第一个 SDLC 模型，Waterfall 是最简单的。 在瀑布模型中，开发过程是线性的。 任务和阶段按照严格的顺序一一完成。 进度稳步向下，就像瀑布上的水。
瀑布模型中的传统阶段是：
- 需求收集
- 设计
- 执行
- 集成和测试
- 部署
- 维护
瀑布模型不允许回到先前的开发阶段来修复问题或实施更改。 这只能在下一个瀑布迭代中完成。
好处：
- 易于向客户解释，易于团队理解
- 具有明确定义的阶段和活动的明显结构
- 具有明确里程碑的轻松计划和安排
- 一次完成一个阶段
- 每个阶段的错误和不便都很容易验证
- 每个阶段都易于分析和评估
- 有据可查的流程
缺点：
- 仅适用于非灵活需求
- 无法返回已完成的阶段
- 难以调整
- 开发成本通常很高
- 出现错误和其他不便的风险很高
- 难以衡量阶段的进展
最适合以下项目：
- 稳定、明确的要求
- 产品的清晰定义和愿景
- 知名技术和稳定的技术栈
- 足够的资源用于实施和支持
- 很短的时间框架
V字型
V 形模型也称为V 模型或验证和验证模型，是 Waterfall SDLC 方法的扩展。 在 V-Model 中，进度不是直线移动，而是在实施和编码后向上上升。
早期测试计划是 V 模型 SDLC 项目的典型特征，这是与瀑布模型的主要区别。 每个开发阶段都有一个并行测试阶段，这有助于在进入下一步之前验证和验证每一步。
好处：
- 易于使用和解释
- 每个阶段都有明确的可交付成果，这意味着更严格的纪律
- 由于早期测试，结果比瀑布模型更好
- 每个阶段的明确验证和确认
- 平滑的缺陷跟踪，因为在早期阶段发现了错误
- 更容易跟踪进度，至少与瀑布模型相比
缺点：
- 灵活性差，不支持迭代
- 由于没有处理并行事件，进行调整的难度大且成本高
- 高业务和发展风险
- 没有可用的早期原型
- 测试过程中发现的问题没有明确的解决方案
V-Model 中的项目阶段与 Waterfall 中的相同，但通过测试对每个阶段进行验证和确认。 因此，V-Model 适用于与 Waterfall 类似的项目类型。
大爆炸模型
这种软件开发生命周期模型通常不遵循任何特定的流程或说明。
开发从目前可用的资源和努力开始，很少或根本没有计划。 结果，客户得到的产品甚至可能不符合要求。 功能是即时实现的。
Big Bang SDLC 模型的关键思想是将所有可用资源分配给产品本身的开发，主要是在编码方面，而不必为满足计划而烦恼。
好处：
- 极其简单的模型
- 几乎不需要计划
- 管理简单
- 不需要很多资源
- 灵活的开发团队
缺点：
- 高风险和不确定性； 整个项目可能需要从头开始
- 不适合复杂的、长期的或面向对象的项目
- 由于需求不确定，浪费资源的可能性很大
最适合：
- 小团队或单个开发人员
- 学术项目
- 没有特定要求或预期发布日期的项目
- 低风险重复和小项目
原型模型
原型 SDLC 方法是创建一个功能有限的软件产品的工作原型，然后快速将原型转变为完整的产品。 原型可能不包含成品的确切逻辑。
这种软件开发生命周期方法有利于让消费者可视化产品。 收集和分析客户的反馈有助于开发团队在开发的早期阶段更好地了解客户需求。
查看本文以了解为什么需求在软件工程中很重要。
原型设计也很有价值，因为它比传统的瀑布模型涉及更少的迭代。 这是因为测试是在原型上完成的（并对其进行更改），而不是完全开发的产品。
当然，创建有价值的原型需要对产品和市场需求有一些基本的了解，尤其是在用户界面方面。
使用原型模型，用户的反馈在规划进一步开发中起着决定性的作用。
原型设计允许用户评估开发人员对更多应用功能的建议，并在实施之前进行试用。
此 SDLC 模型中的每个原型通常在以下阶段实现：
- 确定要求
- 开发初始原型
- 审查
- 修订和加强
一旦最终原型完成，项目需求就被认为是不可改变的。
还有许多传统类型的原型设计：
一次性原型——团队开发了许多不同的原型，并丢弃了明显不可接受的原型。 每个原型的有用功能进入下一个开发阶段。
进化原型——团队向潜在用户的焦点群体展示原型，收集他们的反馈，并通过迭代实施更改，直到最终产品完成。
增量原型设计——团队创建各种原型并最终将它们合并为一个设计。
极端原型——团队创建了一个由三部分组成的原型：静态原型、功能模拟原型和已实现的服务原型。 这种类型的原型设计主要用于 Web 应用程序开发。
好处：
- 在产品实施之前增加用户参与度
- 减少开发时间和成本的机会（如果原型成功）
- 用户在参与开发过程时更好地理解功能
- 及早发现缺陷
- 快速反馈
- 简单而有价值的分析
缺点：
- 由于依赖原型而导致分析不完整的高风险
- 用户可能会将原型视为已完成的产品，但仍不满意
- 实施原型的高成本风险
- 开发多个原型可能需要太多的迭代，从而导致太多的时间
最适合：
- 与任何其他 SDLC 模型并行使用
- 具有大量用户交互的产品
- 早期应该得到用户认可的产品
迭代和增量模型
迭代和增量 SDLC 模型将迭代设计和工作流与增量构建模型结合在一起。 在这种情况下，团队循环开发产品，以进化的方式构建小部件。
开发过程从简单的、严格限制的产品需求集的实施开始。 然后，产品会得到增强并变成更完整的版本，直到它完成并准备好部署。 每次迭代都可能包含设计更新和新功能。
Iterative and Incremental 模型的一个有价值的特性是开发可以在不了解所有需求的情况下开始。 该模型包含来自其他 SDLC 模型的步骤——需求收集、设计、实施和测试——但在多次构建的过程中。 开发团队利用先前构建中取得的成果来改进下一个构建。
迭代和增量 SDLC 模型可能看起来像一组迷你瀑布或迷你 V 形模型。
好处：
- 尽早产生业务价值，因为每次增量都会交付工作产品
- 可以使用稀缺资源完成
- 提供灵活的空间
- 允许更多关注用户价值
- 适用于并行开发
- 在早期阶段发现问题
- 易于评估开发进度
- 使用大量客户反馈
缺点：
- 需要大量文档
- 遵循一组预定义的阶段
- 增量由功能和特征依赖项定义
- 与瀑布或其他线性 SDLC 相比，需要开发人员更多的用户参与
- 如果没有提前计划，可能很难在迭代之间集成功能
- 由于早期需求不完整，可能会出现架构或设计问题
- 管理复杂
- 难以预测项目的结束
最适合：
- 复杂的关键任务项目，如 ERP 系统
- 对最终产品有严格要求但有额外改进空间的项目
- 定义了主要需求但某些功能可能会发展或可能会增强的项目
- 所需技术是新技术且尚未掌握或仅计划用于产品的某些部分的项目
- 具有可能需要更改的高风险特性的产品
雷达模型
快速应用程序开发 (RAD) 模型基于原型设计和迭代开发，不涉及特定规划。 有了这个模型，规划就在快速原型设计中退居二线。
RAD 模型中必要的主要数据是通过研讨会、焦点小组和早期原型演示以及通过重用现有原型来收集的。
RAD 软件开发生命周期模型中的功能模块作为原型并行开发并集成以快速交付完整的产品。 开发的原型很可能是可重用的。
RAD 模型将分析、设计、构建和测试阶段分配到一系列短的迭代开发周期中。
RAD 模型的阶段：
业务建模——对信息流和各种业务渠道之间的信息分布进行建模。 这部分需要为业务找到重要信息，并定义如何获取信息、如何以及何时处理信息，以及哪些因素推动了信息的成功流动。
数据建模——处理上一阶段的数据，以形成具有已识别和已建立属性的必要数据集。
流程建模——将前一阶段的数据集转换为流程模型以实现业务目标，并给出添加、删除、检索或修改每个数据对象的流程描述。
应用程序生成——使用自动化工具构建系统并完成编码，以将流程和数据模型转换为实际原型。
测试和周转——大多数原型在每次迭代中都经过独立测试。 在此阶段，开发人员只测试数据流和所有组件之间的接口。
好处：
- 可以适应不断变化的需求
- 易于衡量进度
- 能够使用强大的 RAD 工具缩短迭代时间
- 与其他 SDLC 相比，参与的团队成员更少，生产力更高
- 更快的开发
- 更好的组件可重用性
- 较早的初步审查
- 获得客户反馈的更好机会
缺点：
- 需要强大的技术和设计团队
- 仅适用于可模块化的系统
- 大量依赖建模
- 建模和自动代码生成成本高
- 管理复杂
- 仅适用于基于组件和可扩展的系统
- 整个生命周期需要大量用户参与
最适合：
- 以增量方式交付的模块化系统
- 具有大量强大建模的基于设计的项目
- 具有自动代码生成功能的项目
- 需求动态变化的项目，需要每 2 到 3 个月进行一次小迭代
螺旋发展模式
螺旋 SDLC 模型是原型和瀑布方法的组合。 它与自然的软件开发过程很好地同步。 Spiral 模型具有与 Waterfall 相同的阶段（需求收集、设计、实施和测试），在每个步骤中通过规划、风险评估以及原型和模拟的构建将其分开。
好处：
- 由于早期发现重要问题，因此随着工作的进行，估计（预算、时间表等）变得更加现实
- 开发团队和用户的早期参与
- 每个阶段的风险管理质量更高
- 比线性模型更好的灵活性
- 原型的扩展使用
缺点：
- 获得成品需要更多的金钱和时间
- 由于对风险管理的需求更大，执行起来更复杂
- 由于高度定制化的开发螺旋结果，可重用性有限
- 需要大量文档
最适合：
- 具有许多小型内置功能的复杂项目
- 预算严格的项目（风险管理有助于省钱）
- 高风险项目
- 长期发展项目
- 前期没有明确需求或需求需要评估的项目
- 新产品线将分阶段发布
- 在开发过程中可能对产品进行重大更改的项目
敏捷模型
敏捷 SDLC 模型是迭代和增量方法的混合，专注于通过尽早交付可工作的软件来适应灵活的需求并满足用户和客户。
敏捷项目中的需求和解决方案可能会在开发过程中发生变化。
通过敏捷开发，产品被分成小的增量构建并以迭代方式交付。 所有任务都划分为小的时间范围，以便为每个构建准备工作功能。 最终产品构建包含所有必需的功能。
在敏捷中，现有的开发方法需要适应每个特定项目的需求。 阅读官方敏捷宣言网站以了解有关敏捷哲学的更多信息。
好处：
- 交付特定功能所需的时间更少
- 由于面对面的沟通和客户的持续输入，没有任何猜测的空间
- 在最快的时间内获得高质量的结果
- 可以快速交付和展示业务价值
- 需要最少的资源
- 高度适应不断变化的需求
缺点：
- 要求客户意识到以用户为中心的方法的重要性
- 文档的延迟交付导致更难将技术转移给新的团队成员
- 对范围、交付的功能和改进的及时性提出了严格的要求
- 不容易应对复杂的依赖
- 需要开发团队的很多软技能
最适合：
- 几乎任何类型的项目，但有很多来自客户的参与
- 环境经常变化的项目
- 需要快速完成某些功能的客户，例如在不到 3 周的时间内
为什么是敏捷？
根据年度敏捷状态报告，敏捷仍然是技术行业中使用最广泛的软件开发生命周期模型。 在Mind Studios ，我们主要使用敏捷 SDLC 模型为我们的客户开发软件产品。 这是为什么。
敏捷与其他 SDLC 模型的主要区别在于敏捷是自适应的，而其他模型是预测性的。 预测性开发模型密切依赖于适当的需求分析和规划。 正因为如此，很难在预测方法中实现变化——开发与计划非常紧密地结合在一起。 如果需要更改某些内容，它将面临控制管理和优先级排序的所有后果。
现代软件开发需要立即进行更改的能力。 自适应敏捷开发不像预测方法那样依赖详细的计划。 因此，如果需要更改某些内容，最迟可以在接下来的开发冲刺中更改。
功能驱动的开发团队可以动态地适应需求的变化。 此外，敏捷中的测试频率有助于最大程度地降低重大故障的风险。
阅读更多：如何管理软件开发中的风险。
当然，敏捷意味着大量的客户端和用户交互才能正常工作。 用户的需求，而不是客户，定义了最终的项目需求。
Scrum 和看板
敏捷软件开发生命周期有许多成熟的方法。 其中两个最受欢迎的是Scrum 和看板。
Scrum是一种工作流框架，用于在冲刺中交付软件，冲刺通常为两周。 Scrum 专注于如何在开发环境中管理任务并帮助改善团队动态。
由于 Scrum 的高适应性，没有一种万能的方式来执行 Scrum。 但总的来说，团队需要在某个项目中安排相关的角色、事件、工件和规则。
冲刺是一个两到四个星期的时间框架，在此期间团队创建一个可用的软件。 上一个冲刺完成后，新的冲刺立即开始。
这些是冲刺的典型元素：
冲刺计划，团队计划在给定冲刺中完成的工作量
每日 Scrum 会议团队的简短每日会议，讨论已完成的工作、他们今天计划做的事情以及自上次会议以来发生的问题
Sprint Review ，在 sprint 结束时的聚会，在此期间团队回顾已完成的工作并在必要时对产品待办事项进行更改
Sprint 回顾会在新的 sprint 开始之前发生。 在回顾中，Scrum 团队总结工作并根据过去 sprint 的经验为未来的 sprint 制定改进计划。
看板是敏捷 SDLC 模型中广泛使用的一种管理可视化方法。 它有助于在开发团队中提高和保持高水平的生产力。 看板以短迭代运行：如果 Scrum 大约是几周，那么看板大约是几个小时。 Scrum 旨在完成冲刺，而看板旨在完成任务。 看板是反多任务处理的。
看板的主要实践是：
- 可视化工作流程
- 限制进行中的任务
- 管理工作流
看板是使用一个看板来实现的，其中所有项目任务都可视化并分为诸如待办、进行中、暂停、已完成和审查中的列。
看板也适用于技术含量较低的活动，例如销售、营销和招聘。
开发运营
说到 SDLC 模型作为完成任务的方式，我们应该提到DevOps 方法。 DevOps 是工具、实践和方法的组合，有助于以更快的速度交付软件产品。 DevOps 是关于开发和运营环境的协作。
请注意，DevOps 不是 SDLC 模型，但它也可以帮助您完成工作。
大多数情况下，DevOps 是通过自动化基础架构和工作流并持续跟踪应用程序性能来执行的。 DevOps 方法允许您增加部署频率、记录代码并缩短部署新代码所需的时间。 这对于避免依赖错误非常有用。
DevOps 使用迭代来改进、衡量和监控日常运营中的代码。 其最终目标是拥有尽可能有效的生产环境，以提供更好的客户体验。
但是实施 DevOps 模型需要开发和运营团队具备特定的思维方式，并准备好更快地开发和掌握 DevOps 工具和技能。
好处：
- 更频繁的发布以更快地投放市场
- 更专注于改进产品和更快速地响应业务需求
- 团队成员之间更好的协作
- 更好的最终产品质量和更快乐的客户
缺点：
- DevOps 是新的，这意味着它没有被很好地研究
- 不适合关键任务项目
- 需要团队额外的努力来组织
- 开发初期出错的可能性高
- 需要在关注安全性还是开发速度之间做出选择
结论
软件开发业务不断快速变化。 它的变化速度比人们创建管理它的既定方法更快。 可能没有完全适合您的业务的特定 SDLC。 但是现有的软件开发生命周期模型至少可以引导您朝着正确的方向前进并帮助您协调业务流程。
如果您想更清楚地了解什么 SDLC 最适合您的项目——或者如果您需要一流的敏捷团队来开发您的应用程序或网络产品——请通过我们的联系页面给我们留言。