软件开发生命周期与模型解析：选择合适的开发方法
需求的概念
在企业中需求通常被分为用户需求和软件需求
用户需求
用户需求往往就是一句话的描述，通常是没有经过合理性评估的。曾经有个段子：产品经理和开发人员起冲突了，起冲突的原因是产品经理要求开发一个根据手机颜色进行自适应的手机壳.......zhe种就是没有经过合理性评估的。
软件需求
软禁需求是开发人员和测试人员进行执行工作的依据。
开发模型
认识模型
物理意义上的模型 测试中的模型
软件的生命周期
软件的声明周期就是软件的开发模型
这其实是非常容易进行理解的，生命周期就是从生命的开始一直到生命的结束，对应的软件的生命周期就是从开发软件到运行维护软件。
举个例子
假如我想要建造⼀套房子（别问，问就是⼀个⼈造房子），房子的生命周期（流程）是什么样的？
| 步骤 | 总结 | 映射软件流程 |
|---|---|---|
| 为什么要建房子？商品房还是普通住宅？建造100层技术上是否可行？ | 明确合理的建房目标 | 需求分析 |
| 什么时候开发建房子？计划竣工时间？多久可以交房？ | 计划好时间 | 计划 |
| 建房前明确流程：先打地基，做基础框架，砌墙、粉刷、水电工程…… | 设计好具体的建房流程 | 设计 |
| 按照前面的流程和时间实施建房中…… | 施工中 | 编码 |
| 房屋建造完成，开发商验收成果，买家验收房子品质（房子是否牢固，是否漏水及其他偷工减料的地方，是否按照规定来建造的） | 检查房屋建造结果 | 测试 |
| 检查结束开始逐步入住，使用中出现了各种情况如房屋漏水、墙面掉皮、下水道堵塞等问题，一边使用一边找物业修理 | 使用并及时维护 | 运行维护 |
因此，我们就得到了软件（开发）的生命周期：
需求分析⸺计划⸺设计⸺编码⸺测试⸺运行维护
| 阶段 | 具体内容 | 产出 |
|---|---|---|
| 需求分析 | 分析用户需求是否合理，分别从市场需求、技术等方面进行分析。 | 输出需求文档等文档 |
| 计划 | 对成立的需求执行需求执行计划，多久时间内完成该需求，每段时间具体完成哪些功能。 | 输出计划文档等文档 |
| 设计 | 将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计、设计哪些接口、采用什么技术）。 | 输出技术文档等文档 |
| 编码 | 开发人员参考需求文档、设计文档、交互图等文件进行代码的编写。 | 代码文件等文档 |
| 测试 | 测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试。 | 测试用例、测试设计与计划、测试报告等文档 |
| 运行维护 | 项目测试结束之后，项目需要进行上线，并对产品进行线上维护。线上维护主要为三个方面：1. 修复性维护：对项目中未发现的问题进行修复；2. 完善性维护：对功能进行完善；3. 预防性维护：为了避免产品在上线后出现一些不可预料的问题，进行一些防护手段。 | 维护日志、修复记录、更新说明等维护相关文档 |
在设计阶段
不同的角色的工作是不同的，对于开发来说需要进行设计开发文档（使用了什么技术、用什么框架等等）；对于测试来说需要进行明确需求、设置测试用例、测试计划（明确本次测试工具、设计测试类型）
常见的开发模型
瀑布模型
瀑布模型的特点
线性开发流程，每个流程只能进行执行一次。
基于瀑布模型的特点，弊端也比较明显
- 测试后置：
前面各个阶段遗留的问题都要推迟到测试阶段才能够被发现，如果出现问题，真的是想死的心都有了呀，需要一层一层的向前进行返工。
并且还需要进行留有足够的空间给测试人员进行测试，否则导致测试不充分，会将缺陷直接暴露给用户（产品质量差）。
- 产品延迟：
只有将整个产品完全进行开发出现才能进行上线，可能会进行导致需求/功能过时。
举个例子，现在直播板块非常的火，当使用瀑布模型进行开发完成时可能需要一两年的时间，到时候直播模块有可能就过时了，没有用户进行使用了。
因此瀑布开发模型适合于有固定需求的小项目。
螺旋模型
将螺旋模型进行展开形成线性的结构如下图所示
螺旋模型的特点
螺旋模型的各个阶段都引入了风险分析+原型，适合于需求复杂，规模大、风险大的项目。
优点
- 强调全过程严格的风险管理
- 强调各开发阶段的质量
- 增加了风险分析和原型
缺点
- 由于引入了风险分析，还需要进行招聘风险分析人员，增加成本投入
- 采用这种模型进行开发各个阶段是否有问题进行遗留取决于风险分析人员的能力。
增量模型、迭代模型
增量模型是将大需求进行拆分成若干个小需求，每个小需求进行独立开发上线。迭代模型会进行上线一个基础版本，但是基础版本所有的功能都有只不过功能比较简陋，后期在进行优化。
迭代模型和增量模型现在一般都是配合着去使用，很少单独去使用。
敏捷模型
在软件工程发展的早期阶段，迭代瀑布模型曾被广泛应用于项目开发中。该模型强调阶段性的推进：需求分析、系统设计、实现、测试与维护，每个阶段相对独立。然而，随着项目复杂性的提升，尤其是在项目开发过程中频繁出现客户需求变更的现实，瀑布模型逐渐暴露出高成本、低灵活性、响应迟缓等问题。
为什么从瀑布转向敏捷？
传统瀑布模型面对变更请求时，需要花费大量时间和资源来重新设计和实施，导致交付周期延长、客户满意度下降。为了更好地应对这些挑战，敏捷软件开发模型（Agile Model）在1990年代中期应运而生。其核心理念是快速响应变化、增量交付价值，通过灵活的流程和团队协作来加快交付速度，提高软件质量。
敏捷模型的核心特性
敏捷开发强调“适应性”而非“预测性”，在流程设计上避免不必要的步骤，追求“轻流程、轻文档、重目标、重产出”。其基本开发方式如下：
需求拆分：将项目需求分解为多个小型功能模块（User Stories）。
迭代开发：每个模块在一个短周期（通常为2~4周）的迭代中完成。
持续反馈：在每次迭代后与客户沟通反馈，快速调整方向。
短期计划：没有冗长的长期计划，每次迭代计划、开发、交付一个最小可用产品（MVP）。
敏捷宣言（Agile Manifesto）
敏捷的哲学基础来自于2001年发布的《敏捷宣言》，其核心价值观通过对比的方式表达：
个体与交互 高于 过程与工具
可用的软件 高于 完备的文档
客户协作 高于 合同谈判
响应变化 高于 遵循计划
注：对比项中“右侧”仍有其价值，但敏捷开发更注重“左侧”的内容。
Scrum：敏捷开发的主流实践框架
在众多敏捷实践方法中，Scrum是最被广泛应用的一种，被称为“迭代式增量开发模型”。Scrum强调结构化管理和透明协作，主要由以下三个角色和五个关键会议组成：
三个核心角色：
Product Owner（产品负责人）：
管理产品待办事项（Product Backlog）
编写并排序用户故事（User Stories）
定义每个故事的商业价值
决定产品发布计划，对产品成功负责
Scrum Master（项目协调人）：
主持各类Scrum会议
移除团队开发障碍
促进Scrum流程执行与改进
Team（跨职能研发团队）：
包含开发、测试、设计等多领域成员
自组织完成每次迭代目标
保证按时交付可运行的产品增量
五个重要会议：
测试模型
V 模型
优点：
• 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系，有效提升测试的质量和效率。
• V模型指出：
◦ 单元和集成测试应检测程序的执⾏是否满⾜软件设计的要求；
◦ 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
◦ 验收测试确定软件的实现是否满足用户需要或合同的要求
缺点：
仅仅把测试作为在编码之后的⼀个阶段，未在需求阶段就介⼊测试。缺点同瀑布模型。
W模型（双V模型）
W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成，分别代 表测试与开发过程，图中明确表⽰出了测试与开发的并⾏关系。
特点：
测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的
优点：
• 有利于尽早地全⾯的发现问题。例如，需求分析完成后，测试⼈员就应该参与到对需求的验证和确 认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项⽬难度和测试⻛险， 及早制定应对措施，显著减少总体测试时间，加快项⽬进度。
缺点：
• 需求、设计、编码等活动被视为串⾏的；
• 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯ 作。
• 重流程，⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理 ⾯临着困惑