项目管理之一软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等）

软件开发生命周期（Software Development Life Cycle，SDLC），又称为软件开发过程（Software Development Process），为软件的开发定义了一个框架，将自动化工具、软件开发方法和质量管理紧密结合在了一起，其各个阶段实现了软件的需求定义与分析、设计、实现、测试、交付和维护。软件开发过程是在开发与构建系统时应遵循的步骤，是软件开发的路线图。

上面这幅图是我在网上找到的（MBA智库），乍一看非常的复杂，甚至出现了哲学范畴的方法论。我个人感觉上图还是非常详细的。不过对于里面的细节并没有详细的介绍，后面我会介绍一下我的理解。

SDLC 在有的资料里面也称为系统开发生命周期（Systems Development Life Cycle, SDLC），且将它和软件开发生命周期等价。但是这两者其实是不一样的：系统 = 软件 + 硬件。不过他俩的内容基本是一致的。

软件开发生命周期（SDLC）同时也是一种具有创建高质量软件的清晰定义过程的方法论。这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。具体而言，SDLC 方法侧重于软件开发的以下阶段:

需要注意的是，我翻阅了大量介绍软件开发生命周期的文档，他们对于上面的阶段定义并不相同。如下是我在学习中找到的比较多的几种情况：

软件开发生命周期（SDLC）可被视作最早的形式化方法。SDLC 的主要想法是，在采用框架时应当“以审慎、结构化和方法化的方式开发信息系统。生命周期中的每个阶段，从概念提出到系统交付，都应当严格、依次地进行”。

在实际的开发过程中，开发者们不断的总结归纳，最终形成了一些比较统一开发模式。这些开发模式就是一个个被称为软件开发过程模型（Software Development Process Models）。其中最著名的就应该是瀑布模型了。如下是一些常用的模型：

更进一步，一些业内的大佬还为某些过程模型制定了相应的规范。后面我们将介绍一些常见的过程模型。

随着新的面向对象的设计方法和技术（包括后来的敏捷开发方法）的成熟，软件生命周期设计方法的指导意义正在逐步减少。但是，作为最早的开发方法，其为后续的软件开发影响深远（基本确立了软件开发的基本框架，说后续的方法基本都是对于 SDLC 的改进一点也不为过）。

软件开发生命周期 ≠ 项目的开发周期。企业项目中，软件开发生命周期仅仅是项目开发周期的一部分。至于一个项目的具体阶段，则不同的公司有不同的规定（一般都有自己的标准指导文档）。

软件开发方法论

软件开发方法论（Software Development Methodology, SDM）框架是在 20 世纪 60 年代开始出现的。软件开发方法历史中的重要事件（引用自维基百科）有：

我个人认为，软件开发生命周期（SDLC）可以分为宏观和微观两个维度。在宏观上，软件开发生命周期（SDLC）是指的软件开发的整个生命周期，其中包含各种方法论，工具等

在微观上，软件开发生命周期（SDLC）本身就是一种方法论，这是由于历史遗留的原因，当初提出这个概念的时候其就是作为一种软件开发方法。

其中，比较特殊的就是快速应用程序开发和敏捷软件开发。

快速应用程序开发

快速应用程序开发（Rapid Application Development，RAD）是 SDLC 的一个替代品，它结合原型模型,将应用程序开发和 CASE工具的实现相结合。RAD 的优点是速度快，降低了开发成本，并且使用户更积极地参与开发过程。

敏捷软件开发

敏捷软件开发（Agile software development），又称敏捷开发，是一种从1990 年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。“敏捷”（Agile）一词由 “敏捷软件开发宣言”（Manifesto for agile software development）中开始推广，“敏捷软件开发宣言” 定义了相关的价值和原则。

同样在微观上，敏捷开发也可以被认为是指导软件开发过程的一种方法（称为敏捷开发模型）。但是，由于敏捷开发的优势，其逐渐发展为了一种方法论，有了一些列的规范，组织机构等。宏观上的敏捷开发中，包含各种具体的方法。

敏捷开发更强调人的主观能动性，其价值观是：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。其核心主要在于能够充分了解用户的痛点，将用户痛点分级，每次版本都只解决用户当前最大的痛点，然后通过快速开发的版本迭代满足用户需求从而占领市场，这也是 MVP（最小可用产品）的核心思维。

敏捷式开发不仅仅是项目上的一种开发方式，同时也能指点我们在生活中采用 2/8 法则，抓住重点，用最小的力度来实现价值最大化。

敏捷式开发的特性是能够持续性的对软件本体进行不断改造以及处理客户对软件开发过程中的不断介入。敏捷开发的主要优点在于其灵活性。经过一次次例行的开发迭代期（iterations）后，在每一次迭代期的开始时小组便会考虑向软件引入新的特性和改变，也就不会特别跟随原有的开发要求。

敏捷开发是现代软件开发中被广泛使用的范式。敏捷软件开发的框架不断的发展，两个最广泛被使用的是 Scrum 与 Kanban。敏捷软件开发是一个开发软件的管理新模式，用来替代以文档驱动开发的传统开发模式。

总结一下就是，敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

每隔一段时间， Digital.ai 就会发布一次关于敏捷开发的调查 STATE OF AGILE 并发布相应的 STATE OF AGILE 报告，并在 https://stateofagile.com/# 上进行公布。我们可以下载到对应的 PDF 文档。下面是最新的第 14 调查报告中的敏捷开发方法使用情况：

该报告中有详细的记载关于敏捷开发的地域使用情况，行业使用情况等。

敏捷软件开发宣言

在 2001 年，十七名软件开发人员在犹他州的瓦萨奇山雪鸟滑雪胜地会面，讨论一些轻量级的开发方法，并由 Jeff Sutherland，Ken Schwaber 和 Alistair Cockburn 发起，一同发布了 “敏捷软件开发宣言”（Manifesto for Agile Software Development）。

参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶方法、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站（ http://www.agilemanifesto.org/）首页的《敏捷软件开发宣言》，他们称自己为“敏捷联盟”。

官网提供了各种语言版本的敏捷软件开发宣言。有兴趣的可以直接去官网查看。

敏捷联盟

敏捷联盟（Agile Alliance）是一个全球性的非盈利性成员组织，致力于支持那些探索和应用敏捷价值、原则和实践的人们，使构建软件解决方案更有效、更人性化、更可持续。官方网址： https://www.agilealliance.org/

结构化方法

结构化编程（Structured programming），一种编程典范。它采用子程序、块结构、for 循环以及 while 循环等结构，来取代传统的 goto。希望借此来改善计算机程序的明晰性、质量以及开发时间，并且避免写出面条式代码。

面向对象方法

面向对象方法（Object-Oriented Method）是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO （Object-Oriented）方法，是建立在“对象”概念基础上的方法学。

过程模型

过程模型就是指导软件开发过程的方法论。过程模型由五个基本的框架活动组成：沟通、计划、建模、构建和部署。他们之间的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）关系会产生不同的模型。常见的过程模型包括：瀑布模型、V 模型、原型模型、增量模型、螺旋模型等。常见的软件测试模型包括 V 模型、W 模型、H 模型、X 模型和前置模型。

过程模型（Process Models）意图解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动（activities）有效地组织了起来。

瀑布模型

瀑布模型（Waterfall Model）是最早出现的软件开发模型，是传统软件开发方法的代表。在软件工程中占有重要的地位，它提供了软件开发的基本框架。1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。其严格强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。

优点：

缺点：

虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目，不管采用什么开发模式，有四种活动是必不可少的，那就是需求、设计、编码和测试。而这四项活动，都是起源自瀑布模型，也是瀑布模型中核心的部分。管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。

V 模型

1978 年 Kevin Forsberg & Harold Mooz 提出了 V 模型（也被称为验证和验证模型）。V 模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。V 模型反映了开发过程和测试过程的关系，在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应。

需求分析要分析用户的需要，整理出系统的需求（功能需求），会和用户面谈，建立用户需求文档（user requirements document）；概要设计是系统设计师根据用户需求文档，分析并理解要开发系统的业务流程的阶段，会产生软件规格文档（software specification document），软件规格文档是开发阶段的蓝图；详细设计也称为低阶设计，会将设计的系统拆解为较小的单元或是模组，说明每一部分的内容，让程式设计者可以直接写程式。

单元测试主要发现编程和详细设计阶段的错误，测试计划在详细设计阶段制定，在编码阶段完成；集成测试主要发现设计阶段产生的错误，测试计划在概要设计阶段制定，在详细设计阶段完成；系统测试计划在需求分析阶段制定，在概要设计阶段完成；验收测试（User Acceptance Test）计划会在需求分析阶段就订定，测试计划是由企业用户来进行。

与瀑布模型一样，V 模式是一种传统软件开发模型，在当前互联网软件开发中，局限性还是比较大的！

优点：

缺点：

V 模型的软件开发不是以直线的方式进行，其过程在源代码阶段之前逐步往下，而在源代码阶段之后逐步往上，形成了 V 字形。V 模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系。横轴表示时间或是项目的完成度，而纵轴表示抽象的程度（范围越大，越抽象的在越上方）。

V 模型的中心思想是研发人员和测试人员需要同时工作，在软件做需求分析的同时就会有测试用例的跟踪。这样可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。V 模型的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。

据说这是 IBM 的测试模型
V 模型在汽车行业的影响深刻

W 模型

W 模型是由 Evolutif 公司提出，相对于 V 模型，W 模型增加了软件开发各阶段中同步进行的验证和确认活动。W 模型由两个 V 字型模型组成，一个 V 是开发的生命同期，另一个 V 是测试的生命周期，其明确表示出了测试与开发的并行关系（如下图）。

W 模型与 V 模型有一个很大的不同，就是 W 模型是一个并行的模型，V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分更清楚，而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。W 模型具有以下特征：

W 模型仍然是以文档驱动的传统开发方式的一个变种

优点：

缺点：

快速原型模型

快速原型模型（Rapid Prototype Model）又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。下图显示了快速原型模型开发的基本步骤：

由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的。快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

优点

缺点

现在很多互联网企业提供了各式各样的原型设计工具，例如：Mockplus、Balsamiq、Axure 等。

增量模型

增量模型（Incremental Model）融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。产品被分解为多个组件，每个组件都是单独设计和构建的。各个构件完成后逐渐并入已有的软件体系结构中。

当使用增量模型时，第 1 个增量往往是核心的产品，即第 1 个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示：

在增量模型中，每个迭代阶段都得到开发，因此每个阶段都将经历软件开发生命周期的要求、设计、编码，最后是测试模块。每个阶段开发的功能都将添加到以前开发的功能上，在软件完全开发之前，该功能将重复。在每个增量阶段，都会进行审查，根据审查，下一阶段的决定将作出。

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。

增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

螺旋模型

螺旋模型（Spiral Model）是巴利·玻姆（Barry Boehm）于 1988 年 5 月在他的文章《一种螺旋式的软件开发与强化模型》提出的。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段，由这 4 个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:

优点

缺点

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。

敏捷开发方法

见后续独立博文

参考

SaaS点评-老余：敏捷开发项目管理工具对比，jira、gitee、Ones、coding、禅道哪个好

都有哪些较好用的项目管理软件?

V模型_注册一个试试的博客-CSDN博客_v模型

8、V模型、W模型、H模型 - 追风的小蚂蚁 - 博客园

Software Engineering | SDLC V-Model - GeeksforGeeks

V模型 - 永不停转 - 博客园

https://www.guru99.com/v-model-software-testing.html

SDLC - V-Model

什么是V模型？详细解释 - 软件工程 - srcmini

川石信息：软件测试模型之 W 模型

增量模型 - MBA智库百科

https://www.technotrice.com/incremental-model-in-software-engineering/

Choosing the right Software development life cycle model - Mohamed Sami

Scrum in 3 Minutes

Popular Approaches to Agile Adoption

kknews.cc used Cloudflare to restrict access

————————————————

内容分享自网络，如有侵权请联系删除！
原文链接：项目管理之一软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等）

发布于 2022-01-04 10:01

项目管理

管理学

敏捷开发