项目管理 之一 软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等）
接受项目管理培训至今已经有三年时间了，一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头，从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验，希望可以帮助到从事项目管理的人！
由于本文中的大多数术语都是一些规范或者约定俗称的概念，因此，本文的大部分内容都是来自于互联网。例如，软件开发过程 的定义引用自维基百科。本文仅仅是整理记录一些学习重点。如果您发现其中内容有侵权，请随时点击博客右侧的小企鹅进行联系或者直接私信我，我将第一时间进行处理！
概念
软件开发生命周期（Software Development Life Cycle，SDLC），又称为软件开发过程（Software Development Process），为软件的开发定义了一个框架，将自动化工具、软件开发方法和质量管理紧密结合在了一起，其各个阶段实现了软件的需求定义与分析、设计、实现、测试、交付和维护。软件开发过程是在开发与构建系统时应遵循的步骤，是软件开发的路线图。
上面这幅图是我在网上找到的（MBA智库），乍一看非常的复杂，甚至出现了哲学范畴的方法论。我个人感觉上图还是非常详细的。不过对于里面的细节并没有详细的介绍，后面我会介绍一下我的理解。
SDLC 在有的资料里面也称为 系统开发生命周期（Systems Development Life Cycle, SDLC），且将它和软件开发生命周期等价。但是这两者其实是不一样的： 系统 = 软件 + 硬件 。不过他俩的内容基本是一致的。
软件开发生命周期（SDLC）同时也是一种具有创建高质量软件的清晰定义过程的方法论。 这种 按时间分程 的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。具体而言，SDLC 方法侧重于软件开发的以下阶段:
- 需求分析
- 规划
- 软件设计
- 软件开发
- 测试
- 部署
需要注意的是，我翻阅了大量介绍软件开发生命周期的文档，他们对于上面的阶段定义并不相同。如下是我在学习中找到的比较多的几种情况：
软件开发生命周期（SDLC）可被视作最早的形式化方法。SDLC 的主要想法是，在采用框架时应当“以审慎、结构化和方法化的方式开发信息系统。生命周期中的每个阶段，从概念提出到系统交付，都应当严格、依次地进行”。
在实际的开发过程中，开发者们不断的总结归纳，最终形成了一些比较统一开发模式。这些开发模式就是一个个被称为软件开发过程模型（Software Development Process Models）。其中最著名的就应该是瀑布模型了。如下是一些常用的模型：
更进一步，一些业内的大佬还为某些过程模型制定了相应的规范。后面我们将介绍一些常见的过程模型。
随着新的面向对象的设计方法和技术（包括后来的敏捷开发方法）的成熟，软件生命周期设计方法的指导意义正在逐步减少。但是，作为最早的开发方法，其为后续的软件开发影响深远（基本确立了软件开发的基本框架，说后续的方法基本都是对于 SDLC 的改进一点也不为过）。
软件开发生命周期 ≠\neq= 项目的开发周期 。企业项目中，软件开发生命周期 仅仅是项目开发周期的一部分。至于一个项目的具体阶段，则不同的公司有不同的规定（一般都有自己的标准指导文档）。
软件开发方法论
软件开发方法论（Software Development Methodology, SDM）框架是在 20 世纪 60 年代开始出现的。软件开发方法历史中的重要事件（引用自维基百科）有：
- 1969年，结构化编程
- 1980年，结构化系统分析与设计方法（Structured Systems Analysis and Design Method, SSADM）
- 面向对象程序设计，起步于1960年代，1990年代中期成为一种主流方法
- 1991年，快速应用程序开发
- 1995年，Scrum
- 1998年，团队软件过程
- 1998年，由 IBM 维护的统一软件开发过程
- 1999年，极限编程
- 2005年，敏捷统一过程（Agile Unified Process, AUP）
- 2010年代，基于大规模的敏捷框架（Scaled Agile Framework, SAFe）
- 2010年代，大规模 Scrum（Large-Scale Scrum, LeSS）
我个人认为，软件开发生命周期（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 模型的软件开发不是以直线的方式进行，其过程在源代码阶段之前逐步往下，而在源代码阶段之后逐步往上，形成了 V 字形。V 模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系。横轴表示时间或是项目的完成度，而纵轴表示抽象的程度（范围越大，越抽象的在越上方）。
V 模型的中心思想是研发人员和测试人员需要同时工作，在软件做需求分析的同时就会有测试用例的跟踪。 这样可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。V 模型的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。
- 据说这是 IBM 的测试模型
- V 模型在汽车行业的影响深刻
W 模型
W 模型是由 Evolutif 公司提出，相对于 V 模型，W 模型增加了软件开发各阶段中同步进行的验证和确认活动。W 模型由两个 V 字型模型组成，一个 V 是开发的生命同期，另一个 V 是测试的生命周期，其明确表示出了测试与开发的并行关系（如下图）。
W 模型与 V 模型有一个很大的不同，就是 W 模型是一个并行的模型，V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分更清楚，而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。W 模型具有以下特征：
- 测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试。测试的对象不仅是程序，需求、设计等同样要测试
- 测试与开发是并行的，从需求测试就应该开始介入
- 提出尽早测试的概念，这样可以降低缺陷修复成本
- 测试对象不仅仅是程序，还包括需求或其他的相关文档
W 模型仍然是以文档驱动的传统开发方式的一个变种
- 优点：
- 开发伴随着整个开发周期，需求和设计同样要测试
- 更早的介入测试，可以发现初期的缺陷，修复成本低
- 分阶段工作，方便项目整体管理。
- 缺点：
- 开发和测试依然是线性的关系，需求的变更和调整，依然不方便，样就无法支持迭代的开发模型
- 如果没有文档，根本无法执行 W 模型；对于项目组成员的技术要求更高！
快速原型模型
快速原型模型（Rapid Prototype Model）又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。下图显示了快速原型模型开发的基本步骤：
由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的。快速原型是利用原型辅助软件开发的一种新思想。 经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。
- 优点
- 原型系统已经通过与用户交互而得到验证，克服瀑布模型的缺点，据此产生的规格说明可以正确地描述用户的需求。因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
- 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎么不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
- 缺点
- 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下，因此不适合大型系统的开发（适合开发小型的、灵活性高的系统）。
- 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新
- 所选用的原型（开发技术和工具）不一定符合主流的发展
- 快速原型模型是不带反馈环的，软件产品的开发基本上是按线性顺序进行的。
现在很多互联网企业提供了各式各样的原型设计工具，例如：Mockplus、Balsamiq、Axure 等。
增量模型
增量模型（Incremental Model）融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。产品被分解为多个组件，每个组件都是单独设计和构建的。各个构件完成后逐渐并入已有的软件体系结构中。
当使用增量模型时，第 1 个增量往往是核心的产品，即第 1 个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示：
在增量模型中，每个迭代阶段都得到开发，因此每个阶段都将经历软件开发生命周期的要求、设计、编码，最后是测试模块。每个阶段开发的功能都将添加到以前开发的功能上，在软件完全开发之前，该功能将重复。在每个增量阶段，都会进行审查，根据审查，下一阶段的决定将作出。
增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
增量模型的特征：
- 系统被分解成许多小型开发项目。
- 部分系统是为了生成最终系统而构建的。
- 首先满足最高优先级要求。
- 一旦开发递增部分，部分的需求将被冻结。
增量模型的优缺点：
- 优点
- 采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。因此，增量能够有计划地管理技术风险。
- 每次迭代后，应执行回归测试。在此测试期间，可以快速识别软件的故障元素，因为在任何单个迭代中很少进行更改。
- 测试和调试比其他类型的软件开发方法更容易，因为每次迭代时所做的更改相对较小。这允许对整个产品中的每个元素进行更有针对性的、更严格的测试。
- 客户可以响应功能并查看产品，以了解任何需要或有用的更改。
- 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型
- 缺点
- 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
- 在开发过程中，需求的变化是不可避免的。很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
- 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
- 随着产品增加了其他功能，可能会出现与系统体系结构相关的问题，而早期原型中并不明显
- 由增量产生的成本可能会超过组织的成本。
增量理念也用于敏捷流程模型
螺旋模型
螺旋模型（Spiral Model）是巴利·玻姆（Barry Boehm）于 1988 年 5 月在他的文章《一种螺旋式的软件开发与强化模型》提出的。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。螺旋模型最大的特点在于 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。
螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段，由这 4 个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:
- 优点
- 通过原型的创建，使软件开发在每个迭代的最初明确方向；
- 通过风险分析，最大程度地降低软件彻底失败造成损失的可能性；
- 在每个迭代阶段植入软件测试，使每个阶段的质量得到保证；
- 整体过程具备很高的灵活性，在开发过程的任何阶段自由应对变化；
- 每个迭代阶段累计开发成本，使支出状况容易掌握；
- 通过对用户反馈的采集，与用户沟通，以保证用户需求的最大实现；
- 缺点
- 过分依赖风险分析经验与技术，一旦在风险分析过程中出现偏差将造成重大损失；
- 过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调；
- 由于只适用大型软件，过大的风险管理支出会影响客户的最终收益；
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
敏捷开发方法
见后续独立博文
参考
- https://wiki.mbalib.com/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B
- https://zhuanlan.zhihu.com/p/183798988
- https://blog.si-yee.com/2019/10/03/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E4%B9%8B%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B/
- https://zhuanlan.zhihu.com/p/29783716
- https://zhuanlan.zhihu.com/p/24417533
- https://zhuanlan.zhihu.com/p/150399191
- https://www.zhihu.com/question/20014400
- https://blog.csdn.net/qq_43725037/article/details/86213779
- https://www.cnblogs.com/zhuifeng-mayi/p/9853123.html
- https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/
- https://www.cnblogs.com/ITnoteforlsy/p/11938493.html
- https://www.guru99.com/v-model-software-testing.html
- https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm
- http://www.srcmini.com/35680.html
- https://zhuanlan.zhihu.com/p/56673435
- https://wiki.mbalib.com/wiki/%E5%A2%9E%E9%87%8F%E6%A8%A1%E5%9E%8B
- https://www.technotrice.com/incremental-model-in-software-engineering/
- https://melsatar.blog/2012/03/21/choosing-the-right-software-development-life-cycle-model/
- https://www.visual-paradigm.com/scrum/scrum-in-3-minutes/
- https://tech.gsa.gov/guides/popular_approaches/
- https://kknews.cc/tech/e8qgp9z.html
项目管理 之一 软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等）相关推荐
- 软件开发生命周期中的设计阶段_什么是软件生命周期模型？软件测试和软件开发的关系分析！...
软件生命周期这个词,对于大部分人应该比较陌生,但却不容忽视!正因为它的重要性,才有许多不同的软件开发生命周期模型,但是它们都有一个共同的特点,那就是在生命周期中的某一时刻,软件都会被测试.今天我就和大 ...
- 软件开发生命周期及开发模型
软件开发生命周期 软件开发生命周期又叫做SDLC(Software Development Life Cycle),它是集合了计划.开发.测试和部署过程的集合.如下图所示 : 需求分析 这是生命周期的 ...
- 软件测试（概念Ⅱ） · 开发模型 · 软件的生命周期 · 瀑布模型 · 螺旋模型 · 增量模型 · 迭代模型 · 敏捷模型 · scrum · 软件测试模型之 V 模型 W 模型
一.开发模型的由来 二.软件的生命周期 三.瀑布模型(Waterfall Model) 四.螺旋模型(Spiral Model) 五.增量模型(Incremental Model) 六.迭代模型(Ra ...
- 软件的生命周期及模型
软件的生命周期 软件的生命周期:软件从出生到死亡的整个过程,即软件的生命周期. 软件的生命周期模型 常见的软件生命周期模型有以下五大类: 一.瀑布模型 二.V模型 三.W模型 四.双V模型 五.敏捷开 ...
- 一文弄懂软件发布生命周期中各阶段名称及代表含义
什么是软件发布生命周期 软件发布生命周期是指开发.测试和发布软件产品的过程.不同阶段代表了不同的稳定级别(Stability levels). 软件发布生命周期的各个阶段名称及含义 Pre-alpha ...
- 软件工程导论概述----软件的生命周期
软件的生命周期 软件生命周期 软件生命周期 软件定义时期 软件开发时期 软件运行时期 软件生命周期 • 软件从开始计划到最后废弃不用整个阶段称为计算 机软件的生命周期. • 软件生命周期分为三个时期: ...
- 【中级软考】软件开发生命周期模型 瀑布模型、增量模型、原型模型、螺旋模型、喷泉模型、RUP（Rational Unified Process 统一软件开发过程）、敏捷开发（开发方法，不是周期模型）
文章目录 瀑布模型/改进的瀑布模型(Waterfall Model) 螺旋模型(Spiral Model) 增量和迭代模型(Incremental Model) 原型法(RAPId Prototype ...
- 软件开发生命周期模型 瀑布模型、增量模型、原型模型、螺旋模型、喷泉模型总结...
在校期间学习过这些模型,现在来复习一下. 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格 ...
- 软件开发生命周期模型选择方法指南
概述 本文介绍如何利用项目的特性指标来选择生命周期模型. 文档定义了11个项目的特性指标,在下面的描述中对每一个特性指标都有相关的描述来说明该指标的含义以及它对选择模型的影响和作用. 在2.1节中描述 ...
- 软件开发生命周期模型 瀑布模型、增量模型、原型模型、螺旋模型、喷泉模型总结
在校期间学习过这些模型,现在来复习一下. 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格 ...
最新文章
- 2020-10-28
- 数据库笔记01：SQL Server系统概述
- HP-Socket v5.4.4 发布，高性能跨平台网络通信框架
- 本周ASP.NET英文技术文章推荐[03/23 - 04/05]：C#、Visual Studio、MVC、死锁、Web 2.0 API、jQuery、IIS7、FileUpload...
- C 非标准库（conio.h）
- Metronik 案例分享：使用 Aspose.Words 快速生成模板。
- ubuntu 安装 网易云音乐
- 小米无线wifi代理服务器,小米路由器Mini无线中继（桥接）设置教程
- Premiere 关键帧缩放
- 为什么要进行网站流量分析？从6个方面告诉你答案
- 对android layout_wight属性和weight_sum属性的深入理解
- 定时跑视图往另外一张表添加数据_聊一聊数据库中的锁
- 所有iOS设备的屏幕分辨率
- 【洛谷】P5149 会议座位
- u盘启动 联想一体机_联想一体机如何进入bios设置u盘启动_联想一体机设置U盘启动步骤...
- 国产文件服务器十大品牌,国产服务器十大品牌
- 新特性：TabLayout动态添加条目
- 利用最小二乘法进行线性拟合
- HTML中设置图片或者文档路径,html怎么用background相对路径设置背景图片
- 成考本科计算机找工作有用吗,就是想问问成人高考的学历 到底有多大用，找工作好找么?...