什么是SDLC？了解软件开发生命周期

在没有预设计划的情况下贸然进入软件开发领域，会导致预算过高、延误和代价高昂的失败。越来越多的公司开始转向SDLC策略，以使他们能够尽可能快速、安全和经济地交付高质量的软件，而不是急于进入一个项目。

本文介绍了一个公司采用基于SDLC的软件开发所需要知道的一切。我们解释了SDLC策略是如何工作的，深入探讨了产品生命周期的每个典型阶段，并介绍了市场上最可靠的SDLC方法论。

SDLC的含义（软件开发生命周期）

SDLC（软件开发生命周期）是对软件创建（计划、编码、测试、部署等）所涉及的所有步骤的一个大的细分。公司定义定制的SDLC，以创建一个可预测的、迭代的框架，指导团队完成所有主要的开发阶段。

一个SDLC的特点和确切的阶段数量在不同的企业和项目中有所不同。最常见的模式是以下步骤的变化:

• 需求分析
• 深度规划
• 产品设计
• 编码
• 测试
• 部署
• 生产后的维护

一个SDLC战略使企业能够为每一个与软件相关的项目建立一个久经考验的基础。团队以更快的速度和一致性开发高质量的产品，同时公司通过提高其能力来最大化其投资回报率。

• 遵守最后期限，并将项目控制在指定的IT预算内
• 保持高标准的代码质量
• 将错误和漏洞排除在生产之外
• 使产品功能与业务目标相一致
• 正确安排任务的优先次序
• 避免团队成员从事相同、冲突或低价值的工作
• 降低影响用户体验的事后修复的数量

SDLC模型是每个DevOps管道的基础。如果你正在考虑过渡到DevOps，在你引入激进的工作流程变化之前，确保团队对SDLC策略有一个坚定的把握。

SDLC如何工作

SDLC概述了软件开发的每个阶段，将过程分解成独立的阶段，这些阶段有各自的:

• 目标
• 任务
• 期望
• 过程指示
• 文件
• 交付物
• 联系人（通过姓名或职位指定）

步骤的确切数量和性质取决于企业和其产品目标。平均来说，大多数公司定义的SDLC有五到七个阶段，尽管更复杂的项目达到十个或更多阶段。

SDLC的每一步都会产生一个输出（文档、图表、工作软件等），作为下一步的必要输入。尽管有这种漏斗式的方法，现代SDLC策略并不是严格的线性的。团队经常在SDLC中回到一两步，进行修复或改进。

一个产品的SDLC必须是一个活的过程，团队定期更新（或至少是审查）。保持SDLC的更新需要业务分析员、开发人员、QA人员和利益相关者的共同努力。

SDLC策略自20世纪60年代以来一直存在，它的大多数核心概念随着时间的推移而不断发展。最重要的变化发生在测试阶段。传统上，测试是一个独立的SDLC阶段，而现在的团队更倾向于在整个生命周期中整合安全活动，以创建更可靠的软件，通过设计来保证安全。

SDLC的阶段

虽然每个SDLC都是独一无二的，但所有的生命周期都会经历类似的步骤。让我们仔细看看平均软件开发生命周期的每个典型阶段。

需求分析

任何SDLC的第一步是定义项目的需求。这个阶段的一些关键问题是:

• 新项目的目标是什么？
• 企业希望从产品中得到什么？
• 团队是要从头开始写代码，还是要升级一个现有的系统？
• 我们是否有任何硬性的截止日期？
• 我们内部是否有必要的知识，或者我们必须将项目的某些部分外包出去？

这个阶段需要业务分析、运营、领导、开发和安全团队的共同努力。在一些用例中，向终端用户征求意见也是一个有价值的信息来源。

在这个阶段收集到的所有数据都会进入软件需求规范（SRS）文件。一个SRS文件包括所有即将推出的产品的软件、硬件、安全和网络规格，但该文件也包含有关信息:

• 资源分配
• 能力规划
• 项目调度
• 成本估算
• 供应

这个步骤的输出。一份定义项目目标和范围的SRS文件，并提供产品要求和粗略的项目估计（预算、资源、期限等）。

可行性研究

高级商业分析员进行可行性研究，以确定软件的可行性。通常的做法是，主要关注这五个因素:

• 预算限制
• 法律影响
• 操作要求
• 可用的内部技能
• 所需的项目时间框架

分析师将这一阶段的发现添加到现有的SRS文件中，之后由决策者团队对报告进行审查，以批准:

• 项目计划和方向
• 估计的成本
• 预计的时间表
• 必要的资源

高层管理者要么签署项目，要么要求团队在SDLC中退回一步，提出新的建议。

这一步的产出。一个由高级管理层批准的扩展的SRS文件。

设计计划

一旦有了批准的项目方向，团队就开始创建一个设计计划，解释新产品的所有主要方面，包括它:

• 架构（编程语言、数据库、界面、操作系统、预制模板、API等）
• 功能列表
• 基础设施要求
• UI设计
• 必要的安全措施（例如，SSL加密、密码保护、推荐的数据库迁移等）

团队将这些信息收集到设计文件规范（DDS）中。一个利益相关者审查DDS，并根据以下因素批准一个方向:

• 设计的模块化
• 风险评估
• 产品的稳健性
• 时间限制

一些公司决定在这个SDLC阶段创建一个原型。虽然很耗时，但原型设计比在开发阶段后进行大刀阔斧的修改要便宜得多。

这个步骤的产出。一个详细的DDS，其中列出了开发人员为产品编码所需的所有信息。

软件开发

开发团队熟悉DDS并开始编写代码。通常情况下，这一步是SDLC中最耗时的阶段，所以我们建议使用敏捷方法来加快编码速度。

这个阶段的结果是满足SRS和DDS中列出的所有要求的运行软件。当代码仍在等待高级测试时，团队应该已经把产品通过基本测试（如静态代码分析和多种设备类型的代码审查）。

这个步骤的输出。一个可测试的、功能齐全的软件的源代码。

深入的软件测试

从上一个SDLC阶段出来的软件现在要经过广泛的测试。公司有各种各样的测试方法来评估新产品，如：

• 代码质量测试
• 单元测试（功能测试）
• 集成测试
• 性能测试
• 安全测试
• 验收测试
• 非功能测试

大多数团队依靠自动测试来加速这一阶段，但一些人工检查也是有价值的（渗透测试就是一个很好的例子）。

如果团队发现了一个缺陷，代码就会在其生命周期中倒退一步，开发人员就会创建一个新的、没有缺陷的软件版本。当产品稳定，没有缺陷，并达到前面阶段定义的质量标准时，测试阶段结束。

这个步骤的产出。一个经过全面测试的产品版本，可以在生产环境中使用。

软件部署

产品离开测试阶段，准备投入生产。有些项目要求团队在软件提供给终端用户之前编写用户手册或制作指导视频。

理想情况下，部署阶段会自动发生（通常作为CI/CD的一部分）。成熟度较低的公司或一些高度管制的行业可能需要在这个SDLC阶段进行人工审批。

大多数公司将新的软件部署给一小部分用户（10-15%），然后慢慢地将其逐步引入其他客户群。逐步引入意味着你限制了对用户体验的影响，如果产品有一个被忽视的问题。

这个步骤的产出。一个功能齐全、经过测试的产品，可供终端用户使用。

产品维护和改进

每一个已交付的软件都需要根据用户的反馈进行定期审查和更新。在这个阶段最常见的活动是。

• 修复错误
• 设置持续监控
• 将应用程序升级到更新的版本
• 为软件添加新的功能

每当用户报告一个错误或团队发现一个新的缺陷，产品就会根据需要在SDLC中往回走几步。一些严重的缺陷需要在设计阶段进行更新，而大多数问题会使应用程序回到开发阶段。

这个步骤的产出。一个完全受监控的产品，不断看到改进。

SDLC方法论

不同的SDLC方法论（或模型）优先考虑产品创建的不同方面，并以独特的方式衡量成功。让我们来看看你的公司可以采用的最流行的SDLC方法论。

瀑布式

瀑布式是市场上最古老和最直接的SDLC模型。这种策略（也被称为线性顺序模型）使产品通过一个单向的漏斗，其步骤如下:

• 需求收集和分析
• 系统设计
• 编码
• 测试
• 产品部署
• 软件维护

瀑布模型的各个阶段是按顺序进行的，每个阶段都直接取决于前一个阶段的结果（也就是说，每个步骤都 "瀑布式 "地进入下一个阶段）。在一个真正的瀑布模型中，团队在完成一个阶段后不会再返回一步，所以这个模型的成功取决于团队避免错误的能力。

这种模式的优点:

• 一种久经考验的方法论，其步骤的逻辑性很强，适合简单的产品
• 该模型在每个阶段都分析了可行性，这有助于消除瓶颈和数据孤岛
• 每个阶段结束时都有一个有形的产出
• 一个简单的SDLC，公司的每个人都容易理解

这种模式的缺点:

• 高度僵化，不适合现代DevOps团队，他们需要更多的灵活性和每一步后的代码修改
• 在短时间内进行项目工作时不是一个好的选择，因为没有办法跳过任何步骤
• 一旦一个步骤结束，几乎没有改变的空间（至少不会影响成本和交付时间）
• 对于需求不确定或不断变化的项目来说，并不理想
• 构建周期长

V形模型

V型模式（也被称为验证和确认模式）要求团队并行地进行编码和测试任务。

每个验证阶段都有一个指定的验证阶段，这使得模型的图显示为字母V（V的底部是编码阶段）。验证阶段由以下步骤组成。

• 需求分析
• 系统设计
• 高层设计（模块的结构和功能）
• 低层设计（单个组件的结构和功能）

验证阶段有以下步骤:

• 单元测试（与低层次设计阶段平行）
• 集成测试（与高层设计阶段平行）
• 系统测试（与系统设计阶段平行）
• 验收测试（与需求分析阶段平行）

真正的V型模型没有专门的测试阶段，因为每个开发阶段都有自己的QA顺序。

这种模式的优点:

• 对软件测试的重视
• 一个简单和容易理解的SDLC方法
• 瀑布式方法的延伸，具有卓越的缺陷检测能力
• 非常适用于小型项目，有明确的需求，不随时间变化

这种模式的缺点:

• 与瀑布式方法类似的不灵活问题
• 该模型不能处理正在进行的软件项目，因为没有内置的维护阶段
• 后来对需求的改变往往导致成本的激增

原型模式

原型模式要求团队在传统的设计阶段创建一个工作产品原型。与最终结果的软件相比，原型有以下特点:

• 有限的（"假的"）功能
• 低效的性能

公司选择这种模式是为了从客户那里获得宝贵的早期反馈。用户对原型提供意见，开发人员实施所要求的修改，然后团队创造一个更好的原型版本。

这个过程一直持续到客户没有更多的负面反馈，之后团队得到客户驱动的需求分析并开始开发最终产品。

这种模式的优点:

• 确保早期的概念证明，验证对产品的真正需求
• 尽量减少进入SDLC后期阶段的缺陷数量
• 可靠地发现缺失的特征或功能
• 容易调整以适应需求的变化

这种模式的缺点:

• 只作为SDLC的设置，而不是整个生命周期
• 比其他SDLC方法论更耗时
• 对于先进的应用程序和产品来说是昂贵的（对于某些产品来说甚至是不可能的）

螺旋模型

螺旋模型是一种风险驱动的SDLC策略。这个模型强调其四个核心阶段的重复性:

• 确定目标
• 识别和解决风险
• 开发和测试（通常涉及某种形式的原型设计）
• 评估结果并计划下一次迭代

我们的想法是反复经历这些阶段，同时在每个阶段逐步改进。团队不断分析需求并制作原型，同时经历同样的四步循环。

该模型的优点:

• 在出现错误的情况下，团队很容易在循环中退回一步
• 深入的风险分析使这种SDLC成为合规性强的行业的企业的首选模式
• 非常适合有难以界定的要求和范围的大型项目
• 使得团队能够快速适应用户的期望
• 对用户体验产生负面影响的风险很小

该模式的缺点:

• 如果团队经历了太多的迭代，成本往往会失去控制
• 需要一个熟练的团队来评估何时结束迭代并进入下一个SDLC阶段
• 对于依赖性小、需求简单的小型项目来说，是一种 "矫枉过正"

迭代增量模型

迭代增量模型要求团队在每个开发周期结束时快速部署一个不完整的软件版本。

第一个迭代是一个远非完美的产品，满足一小部分的软件需求，随后部署的每一个版本都会扩展产品的功能。每个迭代都要经历以下几个阶段:


每个迭代都要经过验证，需要用户或利益相关者的反馈。最后一个迭代部署的产品版本经过严格的测试，并满足DDS中规定的所有要求。

• 起始阶段（分析项目的需求、目标和范围）
• 阐述阶段（设计一个功能性的产品架构）
• 建设阶段（对架构进行编码，并创建一个可部署的产品）
• 过渡阶段（将产品发布到生产环境中）

与螺旋式SDLC方法（在概念上类似）不同，迭代增量模型将每个软件版本部署到生产中。

这种模式的优点:

• 容易处理产品需求中的小到中等的变化
• 在每个迭代中收集用户和利益相关者的反馈
• 定期进行风险分析，确保产品在设计上是安全的，并在SDLC的早期发现缺陷
• 将项目分成小块，使管理产品和分析进展更容易

这种模式的缺点:

• 需要在部署第一个迭代之前对产品需求有一个坚实的理解
• 这种模式通过要求持续的反馈给用户和利益相关者带来了负担
• 如果不加控制，会迅速耗尽资源

敏捷模式

敏捷方法依赖于持续的发布周期，对上一版本进行小的、渐进的修改。随着团队在每次部署时增加新的功能和改进，构建会不断发展。

敏捷模式要求团队以冲刺的方式工作，持续2到4周，每个冲刺都有独特的要求和目标。在一个冲刺结束时，产品负责人会验证代码，并为其部署到用户那里开绿灯。然后，团队收集反馈，开始准备下一个冲刺。

与迭代增量模型不同，敏捷SDLC并不催促团队将产品部署给客户。相反，重点是在质量和速度之间找到平衡。

敏捷方法要求团队在每个冲刺结束时进行测试，以确保没有潜在的漏洞最终出现在生产中。

这种模式的优点:

• 希望跟上快速变化的市场的公司的首选模式
• 与DevOps原则相吻合
• 从SDLC的一开始就强调代码质量（与迭代增量或原型模型不同）
• 在问题演变成重大问题之前就能发现并解决它们
• 使得从利益相关者和终端用户那里获得有意义的反馈变得容易
• 对定期测试的强烈强调促进了网络安全

这种模式的缺点:

• 需要一个有经验和高技能的团队
• 在快节奏的敏捷SDLC中维护文档是一个挑战
• 紧张的冲刺阶段会使团队长期疲惫

大爆炸模式

大爆炸模式是一种高风险的SDLC类型，它将大部分资源投向开发，而不要求在周期开始时进行深入分析。

大爆炸从很少的计划开始，很快就进入了编码阶段。在许多情况下，开发人员是唯一负责弄清需求、编写代码和检查成品有效性的人。

这种模式的优点:

• 一种高风险-高回报的SDLC策略，不需要在项目中投入太多的时间和金钱
• 需要非常少的计划
• 对于简单的、低价值的、不与客户互动的产品是一个很好的选择
• 对于小团队和没有严格正式流程的公司来说，是一个自然的选择
• 给予开发者自由，以他们自己的方式来开发产品

这种模式的缺点:

• 由于缺乏前期规划，大爆炸极易出错
• 不包括任何内置的测试阶段
• 对于大型、持续或复杂的项目来说，不是一个好的选择

请记住，你不必只选择上面讨论的一种模式--许多公司从结合两种或更多的SDLC方法学中受益，形成适合他们特定使用情况的独特的混合模式。

SDLC的好处

一个适合业务需求的、定义明确的软件开发生命周期会带来各种好处，包括:

• 降低开发成本
• 提高软件产品的质量
• 对开发团队的活动有更多的了解
• 由于更好的组织，更多的透明度和更少的事后修复，更快进入市场的时间
• 更精确的项目规划、预算估计和时间安排
• 改善不同团队和高层管理之间的沟通
• 由于更少的bug和错误进入生产，用户体验得到改善
• 降低网络攻击的成功机会
• 减少项目失败的机会
• 提高文件的质量和精确性
• 对客户和业务需求的深入理解
• 为利益相关者提供更多的机会对项目提出意见（在产品开发的早期阶段尤其关键）
• 更好地了解团队目前的能力和可能改进的领域
• 提高员工的保留率，因为开发人员通常喜欢在运行良好、基于SDLC的项目上工作
• 减少遭受数据损坏或破坏其完整性的机会
• 一种强调知识共享和持续学习的团队文化
• 提高服务的可用性，减少计划外停机的机会
• 更好地规划了备份和灾难恢复（BDR）

SDLC最佳实践

以下是你在公司采用SDCL时应该考虑的一些最佳实践:

• 早期阶段的安全强调：在SDLC的早期考虑安全问题，最好是在设计阶段之前。记住，即使在最初的分析阶段也可以进行威胁建模。
• 使代码审查过程标准化：定期的代码审查可以确保团队遵守编码准则，并防止bug拖累后期的SDLC阶段。
• 保持数据卫生：在整个SDLC中保持所有数据的安全和清洁。无论你是在处理客户、工程或市场数据，团队必须保持卫生以保持信息的安全和可靠。
• 依靠源码控制：使用源码控制可以确保团队将所有的代码保存在一个地方，这可以提高安全性，防止代价高昂的挫折。
• 跟上当前的威胁：确保你的SDLC战略能跟上最新的安全危险和最佳实践。公司必须清楚地了解当前的威胁状况，并保持最新的风险分析。
• 依靠自动测试：自动化是确保测试定期运行的最佳方式，并且团队永远不会因为权宜之计而跳过这些测试。
• 理解文档的价值：SDLC文档是开发人员、QA专家和分析人员的信息来源。这些文件是SDLC的跳动的心脏，所以要确保它们是准确和最新的。
• 组织研讨会：通过定期组织内部知识共享研讨会，教育你的团队了解最佳编码实践、SDCL工具和框架。这些活动也是理想的头脑风暴会议，分析团队如何改进当前的SDLC。