什么是软件开发生命周期 (SDLC)？
作者
Gita Jackson
Staff Writer
Matthew Kosinski
Staff Editor
IBM Think
Jim Holdsworth
Staff Writer
IBM Think
什么是软件开发生命周期 (SDLC)？
软件开发生命周期 (SDLC) 是开发团队用来构建、交付和维护高质量和经济高效的软件系统的结构化迭代方法。
SDLC 将软件开发分解为不同的、可重复的、相互依赖的阶段。SDLC 的每个阶段都有自己的目标和可交付成果，用于指导下一阶段。相互结合后，SDLC 的各个阶段形成了一个路线图，帮助开发团队创建满足利益相关者需求、项目要求和客户期望的软件。
SDLC 模型有多种，每种模型都以自己的方式处理 SDLC 的各个阶段。在某些模型（例如瀑布模型）中，阶段是按顺序完成的。在其他更迭代的流程中，例如敏捷模型，可以并行处理阶段。
详细了解瀑布式开发方法和敏捷开发方法之间的区别。
软件开发涉及许多因素的平衡，例如利益相关者的相互竞争的需求、资源可用性以及软件所处的更大 IT 环境。SDLC 为管理和协调这些因素提供了一个框架，从而促进了更简明的开发流程。
SDLC 可帮助利益相关者估算项目成本和时间范围、识别潜在挑战并在开发周期早期解决风险因素。此外，它还有助于衡量开发进度、增强文档记录和透明度，并使软件项目与组织目标更好地保持一致。
最新的 AI 新闻 + 洞察分析
在每周的 Think 时事通讯中，发现专家精选的有关 AI、云等的洞察分析和新闻。
立即订阅
SDLC 有哪 7 个阶段？
虽然不同的团队可能以不同的方式实施 SDLC 方法，但从业者普遍认为软件开发生命周期有七个关键阶段。
阶段
主要活动
可交付成果
1. 规划
确定项目范围、目标和需求
初始项目计划
2. 分析
收集和查看有关项目要求的数据
足够详细的需求文档
3. 设计
定义项目架构
软件设计文档 (SDD)
4. 编码
编写初始代码
功能性软件原型
5. 测试
审查代码并消除错误
精炼、优化的软件
6. 部署
将代码部署到生产环境
用户可使用的软件
7. 维护
持续修复和改进
更新并优化了代码
SDLC 的每个阶段都包含不同的任务和目标。总体而言，这些阶段提供了标准化的软件开发路线图。
1. 规划
项目规划阶段确定软件开发项目的目标和范围。
软件开发团队首先通过头脑风暴确定项目的高级细节。团队可能会专注于诸如软件将解决的问题或用例、谁将使用它以及软件如何与其他应用程序和系统交互等想法。
开发人员还可能会征求其他利益相关者的输入，包括业务分析师、业务线经理以及内外部客户。开发人员还可以使用生成式 AI 研究和编码工具来帮助识别需求或试验新的产品功能。
总体而言，规划阶段旨在明确项目目标并确定项目不需要的内容，从而避免项目规模过于臃肿。
规划阶段通常会产生初始软件需求规范 (SRS) 文档。SRS 详细说明了软件的功能、所需资源、可能的风险和项目时间表。
2. 分析
在分析阶段，开发团队收集并分析有关项目需求的信息。分析使团队能够推进他们在规划阶段开始的工作，从高层次的想法转变为实际的实施计划。
分析通常涉及收集用户需求、进行市场调研和可行性测试、评估原型和分配资源。利益相关者可能会分享组织绩效数据和客户数据、过去发展的洞察分析、企业合规性和网络安全要求以及可用的 IT 资源。
软件开发人员可以使用生成式 AI 来帮助处理所有这些信息。例如，生成式 AI 工具或许能够识别用户反馈中的趋势，或标记拟议功能中的潜在合规问题。
在分析阶段结束时，项目经理和开发团队可完全掌握项目的范围、功能与技术规范以及如何组织项目任务和工作流。
3. 设计
设计阶段包括定义项目的架构。核心步骤包括概述软件的导航、用户界面、数据库设计等。
软件工程师审查需求以确定构建所需软件的最佳方式。他们考虑软件如何融入组织现有的应用程序和服务的环境，包括上游和下游，以及它具有的任何其他依赖项。
开发团队还可能在设计阶段开始通过威胁建模练习来识别软件的潜在风险，从而解决网络安全问题。例如，如果身份盗窃被确定为重大风险，则团队知道在设计中纳入强有力的身份验证措施。
许多新的软件应用程序使用微服务架构，这是一种云原生方法，其中单个应用程序由许多较小、松散耦合且可独立部署的组件或服务组成
为了帮助组织开发流程，软件开发人员可能会使用模块化设计。软件模块是执行特定功能的独立代码单元。这些模块可以连接起来以创建更大的软件。模块化设计使开发人员能够重用现有模块并同时处理软件的多个部分，这可以减少瓶颈。
设计阶段的最终工作通常是创建一个早期原型或多个原型，可以将其展示给利益相关者和最终用户以征求反馈。生成式 AI 有可能帮助加速原型的创建。例如，开发人员可以将详细的功能设计和需求输入 AI 工具，并让其返回软件代码的初稿。
设计阶段的工作收集在软件设计文档 (SDD) 中，该文档作为路线图传递给开发人员，以便在编码时使用。
4. 编码
编码阶段或开发阶段是指团队开始根据先前阶段创建的 SDD、SRS 和其他指南编写代码和构建软件的阶段。
这些文档有助于指导软件开发人员选择正确的编程语言（例如 Java 或 C++），并帮助项目经理将项目划分为较小的独立编码任务。
此阶段还涉及构建软件正常运行所需的任何附加系统或接口，例如网页或应用程序编程接口 (API)。
根据遵循的 SDLC 模型，一些团队可能会在开发阶段执行代码审核和其他测试。这些测试可能有助于在软件开发生命周期的早期识别错误和其他漏洞。
现在，一些开发人员使用生成式 AI 来帮助编写代码，这可以缩短开发时间。例如，在“氛围编码”中，开发人员用纯文本描述他们希望软件执行的操作，然后 AI 工具会创建适当的代码片段。开发人员通常将此代码作为起点，并在此基础上进一步优化。
5. 测试
测试阶段在开发团队创建软件的功能片段后开始。在此阶段，团队寻找机会消除错误并增强最终产品。
质量保证团队可能会执行单元测试、集成测试、系统测试、验收测试和其他类型的测试，以确保软件的所有部分都按预期工作。这些测试有助于确保软件满足用户和业务需求，并能在组织更广泛的 IT 环境中运行。
测试人员还会对软件进行安全漏洞检测，确定漏洞出现的时间和方式，并记录检测结果。
开发人员使用测试结果来修复错误并实施改进，然后将软件发回再次测试。
软件开发团队通常同时使用手动和自动化软件测试方法。AI 工具可以简化大部分测试流程，例如，通过生成测试用例和分析测试失败中的模式来揭示根本原因。
许多 SDLC 模型都使用持续测试。这种方法意味着测试不限于 SDLC 的单个阶段。相反，代码会在整个软件开发过程中进行测试。
6. 部署
在部署阶段，经过精细调优的软件被部署到生产环境中，用户可以访问它。
此阶段的目标不仅仅是将软件交到用户手中。开发人员希望确保用户了解如何使用新软件，并且可以在最大限度地减少对用户体验或工作流的干扰的情况下进行部署。
开发人员可能会分阶段部署软件，例如 Beta 版本，此阶段有限的用户群会测试软件的早期版本，然后再向公众发布。这种方法使团队能够在软件达到普遍可用性 (GA) 之前了解软件在现实世界中的工作情况。软件团队还可能创建手册、举办培训课程或为用户提供现场支持。
7. 维护
SDLC 不会随软件的部署而结束。维护阶段包括软件团队为帮助确保软件的持续运营而开展的部署后工作：推送更新和优化、进行意外的更改、测试补丁、应对新用例以及消除用户发现的任何错误。
持续的维护和支持对于保障任何软件的使用寿命是必要的。这就像维护房屋一样：随着时间的推移，小的部件会被滥用或损坏。继而，它们将被取代，并有望得到改进。
在某些开发模型（例如 DevOps 模型）中，开发 (Dev) 与 IT 运营 (Ops) 团队会使用持续整合和持续部署 (CI/CD)。代码在编写过程中会不断添加到代码库中，且不断进行测试并自动部署到生产环境。在 DevOps 中，维护是一项持续性活动，而非一个独立阶段。
应用程序开发
开启旅程：云端企业应用程序开发
在本视频中，Peter Haumer 博士通过演示不同的组件和实践（包括 IBM Z Open Editor、IBM Wazi 和 Zowe），探讨了混合云环境中现代企业应用程序的开发现状。
深入了解云应用程序开发
常见的软件开发生命周期模型
软件开发有很多不同的模型。其中一些最流行的 SDLC 模型包括：
瀑布式V 模型灵活敏捷精益迭代螺旋大爆炸快速应用程序开发 (RAD)
基于多种因素选择正确的 SDLC 模型。项目需求是明确定义，还是在开发过程中可能会发生变化？项目有多复杂？开发团队的经验如何？回答这些问题可以帮助利益相关者为项目选择最合适的模型。
瀑布
瀑布模型是一种线性的软件顺序开发模型，其中一个阶段完成后才开始下一个阶段。它提供了一个结构化、可预测的过程，适用于定义明确、稳定的项目，利益相关者只希望在审核主要里程碑时参与其中。
这种模式不是很灵活，因为它需要在开始新阶段之前完成每个阶段。这可能会使之前阶段的工作在完成后进行纠正变得困难且耗时。
虽然瀑布模型如今不像过去那么常见，但它是许多后起 SDLC 模型的基础。
V 模型
V 模型或 V 形模型是瀑布模型的变体，有时称为“验证与确认”模型。在 V 模型中，SDLC 的每个阶段都有自己的伴随测试阶段。
频繁的测试有助于尽早消除错误，但线性结构使 V 模型（类似瀑布模型）不如其他方法灵活。但是，它很适合需要频繁测试的具有稳定需求的软件。
敏捷
敏捷模型基于持续改进和开发周期执行；这些周期常被称为“冲刺”（sprints），在此期间，开发人员会定期执行并发布小规模、渐进式的更改。该方法特别适合客户愿意且能够参与频繁讨论和进度评审的项目。
敏捷开发可以响应不断变化的请求或需求，使团队能够更轻松地在开发过程中识别问题。这种响应能力带来了敏捷软件开发的最大优势之一：开发团队可以在问题发展成更大的问题之前将之解决。
敏捷方法的变体（有时称为“框架”）定义了开发团队中的角色，以进一步简化流程。两个最常见的敏捷框架是 Scrum 和看板。（有关详细信息，请参阅“SDLC、敏捷和 Scrum”）。
精益
精益模型将制造原则和实践应用于软件开发，以在 SDLC 的每个阶段减少浪费。
精益的目标是在开发过程中持续改进业务流程。团队定期在开发的每一步都设定具有高标准的短期目标，以保证质量。
为了减少臃肿并加快流程，精益优先考虑迭代和更快的反馈循环。该模型消除了决策的官僚程序，并推迟了决策的实施，直到获得准确的数据。
迭代
在迭代模型中，软件的初始版本（或最简化可实施产品 (MVP)）会快速创建，然后通过后续版本快速改进。该模型侧重于从一个小目标开始，然后从那里向外构建软件。
螺旋
在螺旋模型中，四个阶段（分别为确定目标、资源与风险分析、开发与测试以及规划下一次迭代）会以循环方式重复进行，因此得名“螺旋”模型。
通过定期重复这四个阶段，有多种修正机会，使该模型非常适合预计需要频繁更改的高风险或复杂项目。
大爆炸
大爆炸是一种非正式且无结构的软件开发形式，缺乏通常与软件开发生命周期 (SDLC) 相关的严格模型定义。
就像宇宙大爆炸理论一样，这个模型从零开始，没有规划或需求分析。这被认为是高风险的，但是大爆炸模型可以很好地适应参数不言自明的小型项目，因此无需进行详细的规划和管理。相对的，在开发过程中，大爆炸模型依赖于测试人员和用户的反馈来进行专门的软件更新。
快速应用程序开发 (RAD)
正如模型名称所示，快速应用程序开发 (RAD) 依赖于快速原型设计和用户反馈，而不是漫长的规划期。这种结构使 RAD 团队能够快速适应新的用户需求和请求。
虽然与大爆炸软件开发类似，但 RAD 倾向于更有规律地跟踪进度，并为用户和客户提供定期输入的机会。这种额外的结构使 RAD 能够应用于更大规模和更复杂的项目。
DevOps 和 SDLC
DevOps 开发运维是一种软件开发方法，它结合了软件开发和 IT 运营团队的工作并使之自动化。DevOps 开发运维生命周期有自己的步骤，与 SDLC 的步骤类似。但 DevOps 开发运维重新配置了 SDLC 的步骤，创建了软件开发和改进的连续循环。
DevOps 开发运维方法的核心原则是协作、自动化以及持续整合和持续交付 (CI/CD)。由于 DevOps 开发运维涉及整个软件开发过程，因此它本身可以被视为软件开发生命周期。
但 DevOps 开发运维的意义远大于此，它涵盖了文化和组织向共同责任和协作的转变。关键在于，DevOps 开发运维并非单一模型，而是实践、工具与文化理念的结合。
DevOps 开发运维通过使软件开发过程的每个阶段在整个项目中连续进行来解决 SDLC 的僵化问题。规划、编码、测试、部署、维护和监控并不局限于离散的步骤，而是持续贯穿整个产品生命周期。结果是形成一个持续交付管道，通过频繁更新改进软件。
DevSecOps 和软件开发生命周期
DevSecOps，有时称为“安全开发运维”，将自动化安全测试和安全实践集成到 DevOps 开发运维模型中。传统软件开发将安全测试视为一个独立的阶段，而 DevSecOps 将安全考虑因素纳入 SDLC 的每个阶段。
通过将代码审查和渗透测试等安全测试贯穿于整个开发生命周期，团队可以避免由于在流程后期发现的漏洞等因素而导致的延迟。他们可以更早地解决风险管理问题，创建更安全的程序，加速漏洞修复并提供更具成本效益的软件。
SDLC、敏捷和 Scrum
敏捷模型是最受欢迎的 SDLC 模型之一，因为它强调协作、持续交付和客户反馈。这种迭代方法将大型项目分解为有时间限制的“冲刺”，即具有离散目标的较小任务，旨在在短时间内完成。该理念旨在确保团队在开发过程中始终以功能为导向，并使团队能够快速识别问题并响应不断变化的用户需求。
Scrum 是一种敏捷项目管理框架，某些开发团队会将其应用于软件开发流程。其名称源自橄榄球运动。在橄榄球比赛中，“并列争球”是一种在失去控球权后重新开赛的方法，需要球员之间齐心配合、明确沟通。在敏捷框架中，Scrum 要求团队成员作为一个内聚的整体，优先考虑团队合作和开放协作。
在 Scrum 框架中，开发团队分成较小的单元，每个单元都由“Scrum 负责人”领导。Scrum 负责人向产品负责人报告，产品负责人还充当 Scrum 团队之间的联系人。在每个冲刺中，每个小团队对其被分配的任务拥有全部所有权。这种所有权使 Scrum 团队具有适应和创造力，无需停下来等待其他利益相关者的反馈。
看板（在日语中意为“招牌”、“告示牌”）是另一种常见的敏捷框架。Scrum 在固定时间段内工作，而看板模型采用持续的工作流。所有必需的任务都直观地显示在看板上，所有团队成员都可以看到尚待完成的工作并确定后续步骤的优先顺序。该看板使团队成员能够更轻松地在每个任务交付后立即移动到后续步骤。
SDLC 的优势
SDLC 为开发团队提供标准化的结构和可重复的流程，从而更轻松地始终如一地创建高质量软件。SDLC 的优点包括：
更好的软件提升生产力最大限度降低风险提升项目透明度加强协作更高效的资源管理提高客户满意度
更好的软件
SDLC 提供了一个地图，可以帮助团队在预定的时间范围和估算的成本内完成复杂的软件开发项目。此外，它强调测试和质量保证作为流程的一部分，可提高整体产品和代码质量。
提高生产率
SDLC 的结构有助于简化项目并消除猜测。SDLC 可通过清晰的文档记录来指导各个阶段之间的进展，因而可能会缩短软件生产时间并提高开发效率。
最大限度降低风险
SDLC 可以帮助组织预测和管理项目风险。在某些 SDLC 模型中，在整个开发过程中持续进行风险评估。在小问题演变成更大的问题之前，开发团队可以在软件开发生命周期的早期识别并降低风险。
提升项目透明度
SDLC 通过标准化文档和开放的沟通渠道来提高透明度。
大多数 SDLC 模型都定义了流程，用于通知利益相关者已经完成的工作、需要完成的工作以及他们自己的个人责任。有了这些知识，利益相关者可以了解他们面前的工作并更有效地完成自己的任务。
加强协作
SDLC 的透明度也可能促进更密切的合作。利益相关者可能会就目标和痛点达成一致并公开交流。一些模型和方法鼓励团队成员组成小型、密切协作的小组，以找到开发问题的创造性解决方案。
更高效的资源管理
估算开发的总体成本是 SDLC 流程的重要组成部分。利益相关者在开发开始之前了解完成项目所需的资源。提前规划资源需求可能有助于减少膨胀，使项目保持在任务和预算范围内。
提高客户满意度
SDLC 充当严格规划、构建和测试软件的路线图。该路线图实现了更加集中的开发生命周期，有助于减少功能膨胀，使软件更易于使用，并有助于确保软件适合组织现有的 IT 环境。
经过彻底测试的软件在部署时也应该有更少的错误。
软件开发生命周期中的常见挑战
以下是一些可能使 SDLC 项目的成功完成变复杂甚至危及 SDLC 项目的挑战。
保持在项目范围之内需求定义不良确定最佳测试水平保护软件更新和维护
保持在项目范围内
范围蔓延（当项目的需求超出最初计划时）可能会导致软件开发团队耗尽预算并花费额外的精力，但几乎不会获得真正的收益。通常，这些附加要求并不能服务于软件的核心目的，甚至可能使工作偏离最佳开发方向。
不断追求完美也会扭曲项目的范围。某些高度敏感的软件应用程序可能需要近乎完美，但对于大多数软件开发生命周期而言，完美是良好的敌人。一个功能齐全（尽管可能不完美）的版本可以更快地推向市场，并且可以通过部署后的多次迭代维护进行优化。
需求定义不良
如果团队未能事预先全面分析和理解项目需求，则在发现软件的实际需求之前，可能会经历许多浪费的工作周期。这可能会大大推迟发布时间并推高项目成本。
确定最佳测试级别
软件测试几乎占系统开发成本的 33%。为了加快速度并削减成本，组织可能会限制测试，并在以后付出代价，因为未识别的错误和性能问题会给最终用户带来严重问题。
相反的情况也可能带来问题，即在发布之前对软件进行不必要的测试。为了消除所有错误，开发团队最终可能会执行多轮多余测试，导致软件推迟发布。
保护软件更新和维护流程
根据 IBM® X-Force Threat Intelligence Index，供应链攻击（网络罪犯战略性地针对第三方供应商以影响多个组织）正在上升。
软件供应商的一个常见攻击媒介是劫持软件更新过程来传播恶意软件（而非合法更新）。例如，在 2020 年，软件供应商 SolarWinds 遭到黑客攻击，而恶意行为者以软件更新为幌子向其客户分发恶意软件。该恶意软件允许通过使用 SolarWinds 的服务来访问美国各政府机构的敏感数据，包括财政部、司法部和国务院。
开发团队必须在部署后的维护与更新期间考虑应用程序安全措施。如果落入不法之徒手中，这些流程则可能会成为毁灭性武器。
SDLC 中的 AI
电气和电子工程师协会 (IEEE) 报告称，各行业 35% 的组织正在使用人工智能 (AI) 来辅助或加速软件开发。然而，将 AI 纳入 SDLC 也会带来一些挑战。
许多开发团队正在将生成式 AI 工具集成到 SDLC 的所有阶段，以实现超越简单自动化的性能。例如，生成式 AI 编码工具可以创建软件原型，生成可重复使用的代码片段，并帮助开发人员完善自己的代码。此外，它们还可帮助标记和解释代码中的错误，并分析测试数据以识别软件性能和故障的趋势和模式。
尽管 AI 工具充满了无限可能，但它们并非没有风险。AI 工具可能会犯错误，并编写出未经优化的代码。如果开发人员没有仔细检查 AI 工具生成的所有代码，这些工具可能会引入代价高昂的软件错误，直到生命周期的后期才会被发现。
平衡质量和速度也可能是一个问题。开发人员可以使用 AI 工具更快地编写代码，从而有可能加快 SDLC。然而，确保这些输出的质量可能需要大量的人工监督和验证，这可能会抵消这些节省的时间。这里的困境是在 AI 的速度和保持高标准的软件质量之间找到适当的平衡。