---

• 认识需求
• 了解常见的开发模型和测试模型

需求

在软件开发中，需求是一个核心概念，它描述了用户或客户对软件系统的期望和功能要求。需求是软件开发的起点，因此我们得了解一些有关需求的概念。需求可以分为多个层次，企业中最常见的是用户需求 和 软件需求。

• 用户需求是从用户角度描述系统的特性，通常以自然语言或用户故事的形式表达，它没有经过合理的评估，不涉及具体的技术实现。例如：“用户希望平台支持邮箱注册”。

• 软件需求是从开发者角度描述系统的特性，通常以技术文档的形式表达，它关注的是系统应该如何实现用户需求，是开发人员和测试人员的工作依据。例如“平台支持邮箱注册”的用户需求对应的软件需求规格说明书：
  

• 软件需求通常分为：

  1. 功能需求：描述系统应该提供的功能，“应该做什么”，直接满足用户需求
  2. 非功能需求：描述系统的性能、安全性、可用性等，“应该如何运行”，间接影响用户体验

---

维度	用户需求	软件需求
视角	用户	开发者
形式	自然语言、用户故事 非技术性	技术文档 技术性
层次	高层次，抽象	低层次，具体

针对用户需求，产品经理需要进行需求分析（技术可行性、市场可行性、成本投入与收益占比等）后才可转变为软件需求。

---

开发模型

广义的开发模型可以理解为：开发模型 + 测试模型；狭义的开发模型即开发模型，与测试模型独立存在。我们介绍常见的开发模型都是指狭义的。

tip：也不必太纠结于概念，这里是博主的强迫症行为。

模型是什么？

模型这个词语在各个领域的含义有所差别，比如艺术模型、物理模型、建筑模型等。但在软件开发领域，模型这个词指的是一种结构化的框架或方法论，用于指导和组织开发过程。

例如一种开发模型：迭代模型：

• 虽然我们现在没有学习过，但是不难看出这样的模型定义了阶段、展示了流程，能够有效的帮助开发团队规划、执行和管理项目。

模型的目的是为了简化复杂的开发过程，使之更加规范化和可预测，进而提高效率、降低风险，就像拼乐高积木时的说明书。

软件开发领域的各种模型都有其特定的适用场景和规范，开发团队需要根据项目需求选择合适的模型进行软件开发以及测试工作。

---

软件开发生命周期

软件开发生命周期（Software Development Life Cycle，SDLC）指的是软件开发从开始到结束的整个过程，它是一个全面、通用的框架，涵盖了软件开发过程中所有阶段和活动，从最初的需求分析到最终的软件运行维护。SDLC的目标是确保软件开发过程的高效、有序和高质量。

软件开发生命周期：

---

各个阶段的工作：

阶段	具体内容	产出
需求分析	分析用户需求是否合理，从技术可行性、市场可行性、成本和收益等方面进行分析	需求文档等
计划	对成立的需求制定一个全面的执行计划，包括时间以及时间内的活动、预算等	计划文档等
设计	细化需求为一个一个的小任务并分配，设计软件的架构和详细设计，包括系统架构、数据库设计、用户界面设计等	技术文档等
编码	开发人员根据设计文档等编写代码，实现软件功能	代码文件等
测试	测试人员介入到软件的测试中，参考测试用例对系统进行测试	测试用例、测试设计与计划、测试报告等
运行维护	项目测试结束后，进行部署上线运行，并对产品进行线上的维护。线上的维护主要分为： - 修复性维护：对项目中未发现的问题进行修复 - 完善性维护：对功能进行完善。有时为了产品能尽快上线，会只部署一个初版产品，后续进行功能完善或拓展 - 预防性维护：为了避免产品在线上出现一些不可预料的问题，居安思危，进行一些防护的手段	维护记录、更新日志、性能报告等

---

常见的开发模型

在介绍具体的开发模型前，我们先理解一下软件开发生命周期与具体的开发模型的关系，它们之间的关系可以理解为“框架”与“实现方式”的关系。SDLC是通用的框架，而具体的开发模型（广义）则是对SDLC的具体实现方式。

瀑布模型

瀑布模型是软件开发中最早出现且最经典的开发模型之一，是其他模型的基础框架。它是一种线性顺序的开发模型，强调开发的阶段性，每个阶段必须在下一个阶段开始前完成。

瀑布模型示意图：

---

瀑布模型线性顺序的特点带来了很多的缺陷，最明显的缺陷就是测试被后置了，只有前面所有的工作都完成后才会开展测试工作，此时如果发现前面某个阶段出现了错误，特别是需求出现了错误，则需要大面积的返工，大大延长了项目完工时间并增加了成本。

特点	缺陷
- 阶段划分清晰，每个阶段都有明确的任务和目标，便于执行 - 线性顺序，阶段之间不能重叠，必须等当前阶段完成才能进入下一个阶段 - 是其他模型的基础框架	- 测试后置 1. 前期阶段未发现的错误会推迟到测试阶段，导致大面积的返工 2. 必须预留足够多的时间给测试活动，否则可以因为特殊情况压缩测试时间，导致测试不充分，进而导致产品质量差，用户体验差 - 周期过长，各个阶段的任务不能并发推进，产品上线太晚，可能导致需求/功能过时

瀑虽然布模型存在严重的缺陷，但是还是存在适用场景的：需求固定的小项目

需求固定意味着不会因为需求变化而导致返工；小项目意味着潜在问题可能较少，即使存在也可能会及时发现而不需要等到测试

瀑布模型的阶段性开发思想是其他开发模型的基础。

---

迭代模型

迭代模型是一种将开发过程划分为多个小周期的开发方法，通过多次循环开发，逐步完善软件。每次迭代都包含需求分析、设计、编码和测试，最终生成一个可运行的版本。

示意图：

特点：

1. 分阶段开发：将项目分为多个迭代，每次迭代都包含完整的开发阶段，并最终生成一个可交付的版本。
2. 逐步完善：每次迭代在前一次基础上改进，逐步接近最终产品。
3. 灵活性高：需求可以在迭代过程中调整。
4. 早期交付：早期迭代即可交付部分功能，用户可提前使用。

注意理解迭代模型中的分阶段开发，即每次迭代都会产生一个完整的软件版本，但开始较为“粗糙”，经过多轮迭代不断完善和优化。迭代模型的思想经常被提及和采用，比如螺旋模型和敏捷模型实际上都结合了迭代开发。

---

优点	缺点
- 能够灵活应对需求变化 - 可以早期交付，用户可提前反馈，便于优化和改进 - 每次迭代都包含完整的开发阶段，使得风险分散，可提早发现问题	- 管理复杂，需要进行多次迭代规划 - 总成本和时间较大

适用场景：

• 需求不确定、需要频繁调整的项目
• 需要快速看到系统雏形的项目
• 复杂项目，需要逐步验证和调整

---

增量模型

增量模型将整个项目分为多个增量（模块），每个增量都是一个完整的功能模块，并且每个增量的开发都包含完整的开发阶段，按顺序开发并最终集成到系统中。

示意图：

特点：

1. 分模块开发：系统分为多个功能模块，每个增量开发一个模块。
2. 逐步集成：每次增量开发完成后，集成到系统中。
3. 顺序开发：增量按优先级顺序开发。
4. 早期交付：早期增量可交付部分功能，用户可提前使用。

注意理解增量模型的分模块开发，每个增量都是一个单独的功能模块，每个增量的开发最终都会生成一个可运行的系统，但是这个系统只包含完整项目的部分功能，最终所有的增量集成后便是完整的项目。

---

优点	缺点
- 开发顺序灵活，可以按照优先级开发 - 可以早期交付，用户可以提前使用 - 风险分散，便于发现问题	- 难以应对需求变化 - 集成复杂，需要多次集成测试 - 需要良好的模块化设计

适用场景：

• 需求明确且稳定的项目
• 系统可模块化，功能可独立开发的项目
• 需要早期交付部分功能的项目

---

【迭代模型和增量模型的区别】

特性	迭代模型	增量模型
开发方式	多次循环，逐步完善	分模块开发，逐步集成
需求变化	灵活应对	难以应对
交付方式	每次迭代生成可运行版本	每次增量交付一个功能模块

下图可以很好展示两者的区别：

---

螺旋模型

螺旋模型是一种渐进式的风险驱动的开发模型，结合了原型开发与风险分析，通过在每个迭代周期中进行风险评估和应对，使得软件开发过程能够更加灵活地适应变化。一般在软件开发初期阶段需求不明确时，就会采用渐进式的开发模型。

示意图：

---

迭代周期是螺旋模型的核心概念之一，整个开发过程通过多次迭代逐步完善软件，因此会存在多个迭代周期，每个迭代周期都包含了一系列特定的活动，旨在逐步推进项目向前发展，同时管理和降低风险。迭代周期的结构一般是：

• 目标设定：确定当前迭代的目标
• 风险评估：关键一步，是螺旋模型的核心理念
• 开发与测试：开发原型或软件的一部分，并进行测试验证
• 评估与计划：评估当前迭代的结果，计划下一个迭代周期

迭代周期的执行，使得螺旋模型能够在项目的整个生命周期中持续进行改进和优化，同时在每个迭代周期结束，客户都可以提出修改意见或者提出新的需求，收到反馈后，在下一个迭代周期就可以进行完善和修改。因此螺旋模型具有较好的灵活性，适用于需求可能发生变化的项目。

---

原型开发也是螺旋模型的一大特点。原型是指在软件开发过程中创建的初步版本的软件或系统。 它是一个简化的、不完整的版本，用于展示和测试特定功能或设计概念。通常是迭代周期的产物，在每个迭代周期中不断改进完善。原型可以是多种形式，如：功能原型、用户界面原型、架构原型。

原型的创建时机和数量都是根据项目的实际情况而定，在风险分析阶段和开发和测试阶段都可能会创建，但看图可知，原型的创建与风险分析密切相关，通常都会在风险分析后创建原型。

原型的目的和作用主要在于需求验证和降低风险，从而使得开发过程更加灵活，适应性更强。

---

螺旋模型并不要求每个迭代周期中的所有活动都必须在上一个周期完全结束后才能开始。相反，螺旋模型允许一定程度的重叠和迭代，这是区别于瀑布模型的一点。

---

关于螺旋模型可以由下图简单理解（在瀑布模型的基础上修改）：

• 注意：此图只是为了简单理解，突出了风险分析与原型开发，省略了迭代的过程。我们不必关心原型的数量，这些都是可变的。

---

优点	缺点
- 增加风险分析与原型开发，降低项目失败的风险 - 阶段重叠：迭代周期之间可以有一定的重叠，允许在迭代过程中进行反馈和迭代。 - 迭代开发：提高项目的适应性和灵活性，善于应对需求变化的场景 - 客户参与度高，可以在开发过程中提供反馈	- 项目可能存在的风险性与风险管理人员水平存在直接关系，因此需要经验丰富的管理者来引导风险分析和迭代过程 - 需要更多的人员、时间、资金投入，成本高

螺旋模型实际上结合了迭代模型的思想，其适用场景：

• 适用于大型、复杂、高风险的项目
• 适用于需求可能发生变化的项目

---

敏捷模型（Scrum）

敏捷模型是一种以迭代和增量开发为核心的软件开发方法，强调灵活性、协作和快速响应变化。其核心思想体现在《敏捷宣言》中，具体内容如下：

• 个体与交互重于过程和工具：团队成员的协作和沟通比僵化的流程和工具更重要。（轻流程，人比流程重要）
• 可用的软件重于完备的文档：交付可用的软件比编写大量文档更有价值。（轻文档，软件比文档重要）
• 客户协作重于合作谈判：与客户紧密合作比依赖合同条款更能确保项目成功。（合作比合同重要）
• 响应变化重于遵循计划：灵活应对变化比死板地遵循计划更重要。（变化比计划重要）

也就是说，敏捷模型的核心理念是 以人为本、快速响应变化、持续交付价值。

---

敏捷模型可以包含多种具体方法，其中Scrum就是典型的代表，Scrum是敏捷模型的一种具体实现框架，提供了明确的角色、事件和工件。

Scrum有三组核心组成部分：三个角色、五个会议（事件）、三个工件。

一、角色

1. 产品经理（Product Owner）
   • 负责整理 user stories，定义产品需求，形成 产品待办列表，并确定优先级
   • 代表客户利益，确保团队开发最有价值的功能
2. 项目经理（Scrum Master）
   • 负责协调团队遵循 Scrum流程，并移除障碍
   • 是团队的教练和服务型领导，而不是管理者
3. 开发团队（Development Team）
   • 自组织的跨职能团队，负责交付可用的软件 增量
   • 由开发人员、测试人员、设计师等组成

二、事件

1. Sprint
   • 一个固定长度的迭代周期（较短，通常为2~4周），整个项目要经过多个 Sprint，团队在此期间完成任务，在每个 Sprint 结束时交付可用的增量
2. Sprint计划会议（Sprint Planning）
   • 在每个 Sprint 开始时，由 Scrum Master 组织并引导会议流程，会议中团队选择要完成的任务并制定计划。
3. 每日站会（Daily Scrum）
   • 每天15分钟左右的简短会议，因为会议较短，所以通常站立开会，会议期间团队成员交代昨天做了什么，今天计划做什么，有什么问题，即同步进展、计划和问题。
4. Sprint评审会议（Sprint Review）
   • 在 Sprint 结束时，团队展示交付的成果，并收集反馈。
5. Sprint回顾会议（Sprint Retrospective）
   • 整个Scrum团队都要参加，对本次 Sprint 进行总结，发现不足，并制定改进计划。

三、工件

1. 产品待办列表（Product Backlog）
   • 所有需求、功能和任务的列表，由产品经理（Product Owner）维护和排序
2. Sprint待办列表（Sprint Backlog）
   • 当前 Sprint 中要完成的任务列表，由开发团队选择
3. 增量（Increment）
   • 每个 Sprint 结束时交付的可用的软件增量

---

示意图：

梳理一下整个Scrum流程：

• 整个项目要经过多个 Sprint，每个 Sprint 进行如下流程：

  1. 产品经理负责整理用户故事（需求），产出或更新产品待办列表
  2. Scrum Master主持召开Sprint计划会议，并由团队生成Sprint待办列表
  3. 团队完成任务，每天召开每日站会
  4. Sprint结束时，召开Sprint评审会议，交付软件增量并收集反馈
  5. 召开Sprint回顾会议，Scrum团队对本次Sprint总结，并为下一个Sprint制定改进计划

---

分析Scrum：

优点：

1. 灵活应对变化
   • 通过短周期迭代以及持续反馈，能够快速响应需求变化
2. 持续交付价值
   • 每个 Sprint 都会交付可用的软件增量，确保客户能够尽早获得价值并反馈
3. 透明性和可见性
   • 通过每日站会、Sprint评审和回顾会议，确保项目进展以及问题透明（发现并反馈问题，团队可以协作解决）
4. 团队自组织和协作
   • 强调团队的自组织和跨职能协作，充分发挥每个成员的创造力和主动性

除此之外，每个Sprint迭代过程都会持续改进，确保了产品质量，并降低了风险。

---

局限性：

1. 对团队协作、自组织能力和用户参与度要求较高。
2. 不适合大型或者复杂度较高的项目。对于技术复杂度极高或需要长期规划的项目，Scrum的短周期迭代可能无法满足需求。
3. 文档较少可能影响长期维护。Scrum是敏捷模型的具体实现，轻文档。

因此，敏捷模型的适用场景：

• 需求不明确或变化频繁的项目
• 需要并具备较高团队协作能力的项目
• 产品开发或创新项目（有助于快速验证产品概念）

---

【螺旋模型和敏捷模型的对比】

由于都存在多个迭代周期，并且都有产出（螺旋模型的原型、敏捷模型的增量），我们可能会有些搞混，但是实际两者的差别还是很大的。

下表列举了一些明显的区别：

特性	螺旋模型	敏捷模型
核心理念	风险管理	快速交付价值
迭代周期	较长，侧重于风险分析与规划	较短，侧重于快速交付和持续改进
迭代产出	原型或部分功能，主要用于团队进行测试和验证，客户不直接使用交付物	可用的软件增量，客户可以直接使用
角色	项目经理、风险分析师、开发团队	产品经理、Scrum Master、开发团队
适用场景	高风险、高复杂、需求相对明确	需求不确定、变化频繁

除此之外，两者具体的开发流程也是不一样的，这一点很明确：

• 螺旋模型：四个阶段循环迭代（规划、风险分析、开发、评估）
• 敏捷模型（Scrum）：短周期迭代，包含计划、站会、评审、回顾

---

测试模型

测试模型（如V模型、W模型、H模型）是SDLC中测试阶段的具体实现方式。测试模型强调了测试的工作，并通过结构化的方式将测试活动与开发活动结合起来，确保软件质量。

V模型

V模型是瀑布模型的扩展，它将开发阶段与测试阶段一一对应，形成一个“V”字形。V模型的核心特点是测试活动的规划从需求分析阶段开始，但实际的测试执行是在开发阶段完成后才进行的。

示意图：

• V模型的左侧是开发阶段，右侧是对应的测试阶段：
  1. 需求分析 → 验收测试
     • 需求分析阶段定义用户需求，验收测试验证软件是否满足这些要求。
  2. 系统设计 → 系统测试
     • 系统设计阶段定义系统架构，系统测试验证整个系统是否符合设计。
  3. 概要设计 → 集成测试
     • 概要设计阶段定义模块接口，集成测试验证模块之间的交互。
  4. 详细设计 → 单元测试
     • 详细设计阶段定义模块内部逻辑，单元测试验证每个模块的功能。

---

尽管左侧开发和右侧测试一一对应，但不意味着左侧某个阶段完成右侧对应的测试活动就要开始执行，这明显是错误的，因为测试活动需要基于开发完成的软件或代码，因此测试阶段实际上只能在开发阶段完成后进行：

• 单元测试在编码完成后执行
• 集成测试在模块开发完成后执行
• 系统测试在系统开发完成后执行
• 验收测试在所有开发活动完成后执行

虽然左侧某个阶段完成后右侧对应阶段并不实际开展，但是这样的一一对应关系实际上是有意义的：

1. 明确测试活动的范围和目标，避免测试遗漏。
2. 建立开发与测试的关联，确保测试活动有据可依。（每个测试活动的依据是对应的开发文档，如需求文档、设计文档）
3. 分阶段验证开发成果，降低项目风险。
4. 提高测试活动的可管理性，确保测试工作有序进行。（虽然测试活动不能立即执行，但是测试活动的规划可以在对应左侧阶段完成后执行）

---

由于V模型是瀑布模型的变种，也是线性的，所以V模型的优缺点与瀑布模型类似：

优点	缺点
- 阶段划分以及顺序清晰便于执行	- 对需求变化的适应能力较差，不适合需求频繁变更的项目 - 测试后置。测试活动集中在开发后期，可能导致大面积返工或测试不充分

V模型的适用场景：需求稳定、开发流程规范的项目

---

W模型

W模型是V模型的扩展，将测试活动进一步提前，并增加了对需求和设计的验证活动。它强调测试活动贯穿整个开发生命周期，形成一个“W”字形。W模型将V模型的测试后置的问题解决了。

示意图：

• W模型又称为双V模型，左侧的“V”代表开发，右侧的“V”代表测试，中间是需求和设计的验证活动，图中可以观察到开发与测试的并行关系。当用户需求完成后，测试会根据用户需求得到的需求文档进行验证和确认，从而找出缺陷所在，因此相对于V模型，测试后置的问题被解决了。
• 测试的对象不仅是程序，需求和设计同样需要测试。

---

严格意义上，开发和需求并不是并行的，它们之间还是一个线性关系，例如用户需求验证活动（测试V的左侧）还是得在开发流程的用户需求后执行。同时，整体的需求、设计、编码还是保持串行。

优点	缺点
- 早期验证，测试前置，避免了大面积返工 - 测试活动贯穿全程，减少了项目风险	- 项目中增加了需求和设计的验证活动，复杂度较高，管理困难 - 测试与开发还是存在线性的关系 - 重流程、重文档，无法支持敏捷开发模式 - 难以应对需求变化 - 资源需求较大，成本较大

W模型的适用场景：需求明确、复杂度高、对质量和风险控制要求较高的项目

---

【V模型和W模型的对比】

V模型和W模型的区别主要体现在测试活动的分布：

• V模型：测试活动在开发后执行，测试活动集中在测试阶段
• W模型：增加了早期的验证活动，测试活动贯穿全程

---

完