社区编辑申请
注册/登录
软件开发生命周期(SDLC)完全指南 译文
开发 架构
本文和您讨论了SDLC的6个典型阶段、以及6个常用开发模型,并给出如何根据不同的项目特征,选择这些开发方法的建议。

译者 | 陈峻

审校 | 孙淑娟

软件开发生命周期(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

责任编辑:武晓燕 来源: 51CTO
相关推荐

2022-06-16 17:02:49

微软智能云混合云Azure

2022-05-27 10:00:06

C++游戏引擎

2022-06-15 11:51:14

Vue3开发避坑

2022-06-07 09:59:21

网络安全安全漏洞

2022-06-09 18:04:46

网络攻击网络安全

2022-06-22 09:19:55

HDC鸿蒙ADB命令

2022-06-28 10:58:35

勒索软件攻击事件

2022-06-27 15:25:08

架构模型治理

2022-06-01 17:47:24

运维监控系统

2022-06-27 17:46:53

PythonFlask

2022-06-27 23:44:37

云原生云存储云计算

2022-06-28 09:26:25

Python配置文件

2022-06-23 11:42:22

MySQL数据库

2022-05-11 15:08:52

驱动开发系统移植

2022-06-01 11:14:42

Java代码技巧

2022-06-09 10:12:01

网络安全人工智能威胁监测

2022-06-21 09:02:49

python技巧

2022-06-16 10:31:26

2022-05-19 11:33:32

数字化

2022-06-24 10:16:59

Python精选库

同话题下的热门内容

全链路压测:影子库与影子表之争应该知道的RPC内核细节(值得收藏)!!!架构自治服务:构建数据驱动的架构洞察什么是Pulsar函数流处理应用?五张图带你理解 RocketMQ 顺序消息实现机制实现基于 Grafana Loki 的日志报警使用 Loki 微服务模式部署生产集群淘宝iOS扫一扫架构升级 - 设计模式的应用

编辑推荐

终于有人把Elasticsearch原理讲透了!花了一个星期,我终于把RPC框架整明白了!拜托!面试不要再问我Spring Cloud底层原理陌陌基于K8s和Docker容器管理平台的架构实践收藏 | 第一次有人把“分布式事务”讲的这么简单明了
我收藏的内容
点赞
收藏

51CTO技术栈公众号