译者 | 陈峻
审校 | 孙淑娟
软件开发生命周期(Software Development Life Cycle，SDLC)包含了软件从开始到发布的不同阶段。它定义了一种用于提高待开发软件质量和效率的过程。因此，SDLC旨在通过最少的资源，交付出高质量的软件。为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为如下六个阶段：
- 需求收集
- 设计
- 软件开发
- 测试和质量保证
- 部署
- 维护
值得注意的是，这些阶段并非是静态的，它们可以进一步地被分解成多个子类别，以适应独特的开发需求与流程。
图 1 软件开发生命周期
需求收集
这是整个周期中其他阶段的基础。在此阶段，所有利益相关者(包括客户、产品负责人等)都会去收集与待开发软件相关的信息。对此，项目经理和相关方会频繁召开会议。尽管此过程可能比较耗时，但是我们不可急于求成，毕竟大家需要对将要开发的产品有个清晰的了解。
利益相关方需要将收集到的所有信息，记录到软件需求规范(Software Requirement Specification，SRS)文档中。在完成了需求收集后，开发团队需要进行可行性研究，以确定项目是否能够被完成。
设计
此阶段旨在模拟软件应用的工作方式，并设计出软件蓝图。负责软件高级设计的开发人员将组成设计团队，并通过由上个阶段产生的SRS文档，来指导设计过程，并最终完成满足要求的体系结构。此处的高级设计是指包括用户界面、用户流程、通信设计等方面在内的基础要素。
软件开发
在此阶段，具有不同专业知识(例如前端和后端)的开发人员或工程师，会通过处理设计的需求，来构建和实现软件。这既能够由一个人，也可以由一个大型团队来执行，具体取决于项目的规模。
后端开发人员负责构建数据库结构和其他必要组件。最后，由前端开发人员根据设计去构建用户界面，并按需与后端进行对接。
在配套文档方面，用户指南会被创建，源代码中也应适当地留下相应的注释。也就是说，为了保证良好的代码质量，适当的开发指南和政策也是必不可少的。
测试
专门的测试人员协同开发团队在此阶段开展测试工作。测试既可以与开发同时进行，也可以在开发阶段结束时再开展。通常，开发人员在开发软件时就会进行单元测试，以便检查每个源代码单元是否能够按照预期工作。同时，此阶段也包括如下其他测试：
- 系统测试--通过测试系统，以验证其是否满足所有指定的需求。
- 集成测试--将各个模块组合到一起进行测试。测试团队通过单击按钮，并执行滚动和滑动操作，来与软件交互。当然，他们并不需要了解后端的工作原理。
- 用户验收测试--是在启动软件之前，邀请潜在用户或客户进行的最终测试。此类测试可以验证目标软件，是否能够根据需求的规范，处理各种真实的场景。
测试对于软件开发生命周期是至关重要的。倘若无法以正确的方式开展，则会让软件项目团队反复在开发和测试阶段之间徘徊，进而影响到成本和时间。
部署
完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。无论是简单的流程，还是复杂的部署，都会涉及到创建诸如安装指南、系统用户指南等相关部署文档。
维护
作为开发周期的最后阶段，维护涉及到报告并修复在测试期间未能发现的错误。在修复方式上，我们既能够采取立即纠正错误的方式，也可以将其作为常规性的软件更新。
此外，软件项目团队还会在此阶段从用户处收集反馈，以协助软件的改进，并提高用户的软件使用体验。
SDLC方法
虽然SDLC通常都会遵从上述步骤，但是它们在实现方式上略有不同。下面，我将介绍排名靠前的6种SDLC方法：
- 瀑布
- 敏捷
- 精益
- 迭代
- 螺旋
- DevOps方法
瀑布方法
图 2 瀑布方法
作为最古老、也是最直接的SDLC方法，瀑布方法遵循的是线性执行顺序。如上图所示，从需求收集到维护，逐步依次推进，且不存在任何逆转或倒退的步骤。也就是说，只有当上一步完成后，才能继续下一步。
由于在设计阶段之后，该方法不存在任何变化或调整的余地，因此，我们需要在需求收集阶段，收集到有关项目的所有信息，即制作软件蓝图。可见，对于经验不足的开发团队而言，如果能够保证软件的需求从项目开始就精确且稳定的话，便可以采用瀑布方法。也就是说，瀑布模型的成功，在很大程度上取决于需求收集阶段的输出是否清晰。当然，它也比较适合那些耗时较长的项目。
瀑布的优势
- 需求在初始阶段就能够被精心设计。
- 具有容易理解的线性结构。
- 易于管理。
瀑布的缺点
- 既不灵活，又不支持变更。
- 任何阶段一旦出现延迟，都会导致项目无法推进。
- 由于较为死板，因此项目总体时间较长。
- 并不鼓励在初始阶段之后，利益相关者进行积极地沟通。
敏捷方法
图 3 敏捷方法生命周期
敏捷(Agile)即为快速轻松的移动能力。以沟通和灵活性为中心的敏捷原则与方法，提倡以更短的周期和增量式地进行部署与发布。
在敏捷开发的生命周期中，每个阶段都有一个“仪式(ceremony)”，以便从开发团队和参与项目的其他利益相关者处获取反馈。其中包括：冲刺(sprint)计划、每日scrum、冲刺评审、以及冲刺回顾。
总地说来，敏捷开发是在各个“冲刺”中进行的，每个冲刺通常持续大约2到4周。每个冲刺的目标不一定是构建MVP(最小可行产品，Minimum Viable Product)，而是构建可供客户使用的软件的一小部分。其交付出来的可能只是某个功能，而非具有完全功能的产品。也就是说，交付成果可能只是一个将来能够被慢慢增加的功能性服务，而不一定是MVP。
图 4 构建最小可行产品的示例
在每个冲刺结束后的冲刺审查阶段，如果利益相关者对开发的功能感到满意的话，方可开展下一轮冲刺。虽然新的功能是在冲刺中被开发的，但是整个项目期间的冲刺数量并不受限。它往往取决于项目和团队的规模。因此，敏捷方法最适用于那些从一开始就无法明确所有要求的项目。
敏捷的优势
- 适合不断变化的需求。
- 鼓励利益相关者之间的反馈和持续沟通。
- 由于采用了增量式方法，因此更易于管理各种潜在风险。
敏捷的缺点
- 最少量的文档。
- 需要具有高技能的资源。
- 如果沟通低效，则可能拖慢项目的速度。
- 如果过度依赖客户的互动，则可能会导致项目走向错误的方向。
精益方法
软件开发领域的精益方法源于精益制造的原则。这种方法旨在减少生产过程中的浪费和成本，从而实现利润的最大化。该方法虽与敏捷开发类似，但是侧重于效率、快速交付、以及迭代式开发。而区别在于，敏捷方法更专注于持续沟通和协作，以体现价值;而精益方法更专注于消除浪费，以创造客户价值。
精益方法的七个核心概念：
- 消除浪费--鼓励开发团队尽可能多地消除浪费。这种方法在某种程度上并不鼓励多任务处理。这意味着它只需要完成“份内”的处理工作，并通过节省构建所谓“锦上添花”的功能，来节省时间。同时在所有开发阶段都避免了不必要的文档和会议。
- 鼓励学习--通过鼓励创建一个有利于所有相关成员学习的环境，来促进团队对软件开发过程予以反馈。
- 推迟决定--在做出决定之前，应仔细考虑各种事实。
- 尽快交付--由于交付是基于时间的，因此它会专注于满足交付期限的增量式交付，而非大礼包式的发布。
- 团队授权--它避开了针对团队的微观管理，而是鼓励大家积极地参与到决策过程中，让彼此感到参与了重要的项目。它不但为团队成员提供了指导方向，而且为失败留出了足够的空间。
- 构建质量--由于在开发周期的所有阶段都关注客户价值，因此它会定期进行有关质量保证的各项测试。
- 整体优化--通过关注整个项目，而不是单独的项目模块，来有效地将组织战略与项目方案相结合。
精益方法的优势
- 由于团队参与到了决策之中，因此创造力得到了激发。
- 能够尽早地消除浪费，降低成本，并加快交付的速度。
精益方法的缺点
- 对于纪律性较差的团队而言，它不一定是最佳选择。
- 项目目标和重点可能会受到诸多灵活性的影响。
迭代方法
图 5 迭代开发模型
开发界引入迭代方法作为瀑布模型的替代方案。它通过添加迭代式重复性开发周期，来克隆瀑布方法的所有步骤。由于最终产品的各个部分在完成后，才在每次迭代结束时发布的，因此这种方法也属于增量式。具体而言，迭代方法的初始阶段是计划，而最后一个阶段是部署。介于两者之间的是：计划、设计、实施、测试和评估的循环过程。
迭代方法虽与敏捷方法类似，但是它涉及的客户参与度较少，并且具有预定义的增量范围。
迭代的优点
- 在早期阶段，它能够生成产品的可运行版本。
- 其变更的成本更低。
- 由于产品被分成较小的部分，因此更易于管理。
迭代的缺点
- 可能需要更多的资源。
- 有必要全面了解各项需求。
- 不适合小型项目。
螺旋方法
作为一种具有风险意识的软件开发方法，螺旋方法侧重于降低软件开发过程中的各项风险。它属于一种迭代的开发方法，在循环中不断推进。由于结合了瀑布模型和原型设计，因此螺旋方法是最灵活的SDLC方法，并具有如下四个主要阶段：
- 第一阶段--定义项目目标并收集需求。
- 第二阶段--该方法的核心是进行全面的风险分析和计划，消减已发现的风险。产品原型会在本阶段交付出来。
- 第三阶段--执行开发和测试。
- 第四阶段--涉及评估已开发的内容，并计划开展下一次迭代。
螺旋方法主要适用于高度定制化的软件开发。此外，用户对于原型的反馈可以在迭代后期(在开发阶段)扩展各项功能。
螺旋方法的优势
- 由于引入了广泛的风险分析，因此尽可能地避免了风险。
- 它适用于较大型的项目。
- 可以在迭代后期添加其他功能。
螺旋方法的缺点
- 它更关注成本收益。
- 它比其他SDLC方法更复杂。
- 它需要专家进行风险分析。
- 由于严重依赖风险分析，因此倘若风险分析不到位，则可能会使整个项目变得十分脆弱。
DevOps方法
图 6 DevOps方法
在传统的软件开发方法中，开发人员和运维人员之间几乎没有协作。特别是在运营过程中，开发人员往往被视为“构建者”的角色。这就造成了沟通和协作上的差距，以及在反馈过程中出现混淆。而软件开发的DevOps方法恰好弥合了两者之间的沟通鸿沟。其目标是通过将开发和运营团队有效地结合起来，以快速地开发出更可靠的优质软件。值得一提的是，DevOps也是一种将手动开发转换为自动化软件开发的方法。通常，DevOps方法会被划分为如下5个阶段：
- 持续开发--此阶段涉及到软件应用的规划和开发。
- 持续集成—此阶段会将新的功能性代码与现有的代码相集成。
- 持续测试--开发团队和QA测试人员会使用maven和TestNG等自动化工具开展测试，以确保在新的功能中扫清缺陷。自动化测试为各种测试用例的执行节省了大量时间。
- 持续部署--此阶段会使用类似puppet的配置管理工具、以及容器化工具，将代码部署到生产环境(即服务器上)。它们还将协助安排服务器上的更新，并保持配置的一致性。
- 持续监控—运营团队会在此阶段通过使用Nagios、Relix和Splunk等工具，主动监控用户活动中的错误、异常、不当的软件行为、以及软件的性能。所有在此阶段被发现的问题都会被传递给开发团队，以便在持续开发阶段进行修复，进而提高软件的质量。
DevOps的优势
- 促进了合作。
- 通过持续开发和部署，更快地向市场交付软件。
- 最大化地利用Relix。
DevOps的缺点
- 当各个团队使用不同的环境时，将无法保证软件的安全。
- 涉及到人工输入的过程时，可能会减慢整体运营的速度。
小结
综上所述，软件开发生命周期中的每一个阶段都是非常重要的。我们只有正确地执行了每个步骤，才能最大限度地利用现有资源，并交付出高质量、可靠的软件。
事实上，软件开发并没有所谓的“最佳”方法，它们往往各有利弊。因此在选择具体方法之前，您需要了解待选方法对手头项目的实用性。当然，为了尽可能地采用最适合现有流程的方法，许多公司会同时使用两种不同方法的组合，通过取长补短来实现有效的融合，并相辅相成地完成软件的交付任务。
译者介绍
陈峻 (Julian Chen)，51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式，分享前沿技术与新知;经常以线上、线下等方式，开展信息安全类培训与授课。
原文标题：The Complete Guide to SDLC，作者：Mario Olomu
