目录
1.瀑布模型（Waterfall Model）
定义：
瀑布模型是一种经典的软件开发过程模型，在软件工程中占有重要地位，是所有其他模型的基础框架。其基本思想是将软件开发过程划分为一系列相互依赖的阶段，按照线性顺序依次进行，每个阶段有特定的任务和产出物，每个阶段的输出作为下一个阶段的输入，每一个阶段都只执行一 次，一旦进入下一个阶段，很难回到前一个阶段。
主要阶段：
- 需求分析->需求文档。
- 计划->何时开始，何时结束。
- 设计->①技术设计文档（涉及哪些接口、库表、mq、定时任务...）；②UI视觉稿（将需求文档转化为一个个的图片）。
- 编码->写代码。
- 测试->执行测试用例，提交BUG，验收。
特点：
- 线性顺序：每个阶段按照顺序进行，前一个阶段的输出为后一个阶段的输入。
- 阶段划分明确：每个阶段有明确的任务和产出物，便于管理和控制项目进度。
优点：
- 易于理解和使用：瀑布模型简单清晰，易于理解和使用。
- 明确的阶段划分：每个阶段有明确的任务和输出物，有利于团队合作和责任划分。
缺点：
- 缺乏灵活性：瀑布模型要求每个阶段顺序进行，难以适应需求变化和调整。
- 测试压力大：测试被推迟到后期，可能导致时间紧迫和测试压力大的情况。
- 高风险：在前期完成需求分析和设计后才开始编码，如果需求变化或设计有问题，可能导致后续阶段需要较大改动，增加风险和成本。风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
适用项目：
- 明确的需求：适用于需求稳定、明确且变化较少的项目。
- 确定的技术和工具：适用于技术和工具成熟、稳定的项目。
- 高度规范化项目：适用于要求规范性和标准化较高的项目。
- 小型项目。
注意：
- 随着软件开发的变化和复杂性的增加，瀑布模型在实践中已经有所调整和改进，比如引入迭代和增量开发的概念，以更好地应对需求变化和风险控制。
- 随着软件开发的不断演进，敏捷开发等更加灵活的方法也被广泛应用，并在某些项目中替代了瀑布模型。在选择开发模型时，应根据项目特点和需求进行评估和选择。
2.螺旋模型（Spiral Model）
定义：
螺旋模型是一种软件开发过程模型，通过循环迭代的方式进行项目开发。它结合了瀑布模型的逐步演化和迭代增量的思想，强调风险管理，在每个迭代周期中进行需求分析、设计、开发和测试，同时进行风险评估和管理。
主要阶段：
- 需求识别：确定用户需求，明确系统的目标和功能。
- 风险评估：对已识别的风险进行评估，确定可能产生的问题和解决方案。
- 原型开发：基于需求和风险分析结果，创建一个原型用于验证关键功能、设计和解决方案。
- 工程开发：根据原型和设计文档，进行详细设计、编码和软件开发。
- 验证和测试：对开发的软件进行各种测试，包括单元测试、集成测试和系统测试。
- 完善和维护：根据测试结果和反馈意见，进一步完善系统，进行维护和优化。
特点：
- 强调风险管理：风险分析和管理贯穿整个开发过程，通过循环迭代降低风险对项目的影响。
- 循环迭代：通过多次迭代，逐步完善和扩展软件系统，每个迭代周期包含需求分析、设计、开发和测试等阶段。
优点：
- 风险管理：螺旋模型注重每个阶段都会进行风险分析和管理，能够及时发现和应对项目中的风险，避免线上一些问题发生。
- 适应性和灵活性：通过迭代周期性的开发和风险评估，能够适应需求变化和技术不确定性。
- 验证功能和解决方案：通过原型开发阶段，可以验证关键功能、设计和解决方案。
缺点：
- 复杂性：与瀑布模型相比，螺旋模型的管理和控制更为复杂，风险分析可能分析错，需要较高的项目管理和风险管理能力。
- 时间和成本：由于迭代和循环的特性，螺旋模型的开发时间和人力、财力成本通常较高。
适用项目：
- 大规模复杂项目：适用于需求不确定、技术挑战较大且风险管理至关重要的项目。
- 创新性项目：适用于需要验证新技术、新思路的项目。
- 需求变化频繁的项目：适用于需求变化较为频繁的项目，可以通过迭代周期进行灵活调整。
3.增量模型（Incremental Model）
定义：
增量模型是一种软件开发过程模型，通过将软件系统划分为多个增量进行开发。每个增量都包含完整的功能子集，可以独立进行开发、测试和部署。
主要阶段：
- 需求分析和规划：确定用户需求和系统功能，规划每个增量的开发内容。
- 增量开发和集成：按照计划逐个增量进行开发，每个增量包含一部分完整的功能，并进行集成测试。
- 验收测试和反馈：对每个增量进行验收测试，收集用户反馈和改进意见。
- 增量部署和维护：将每个增量的完整功能部署到生产环境中，并进行系统维护和优化。
特点：
- 渐进式开发：通过逐步增加功能和特性，逐渐完善整个系统。
- 独立的功能子集：每个增量都是一个独立的功能子集，可以单独开发、测试和部署。
- 循序渐进：根据需求和优先级，按照顺序逐个增量进行开发和集成。
优点：
- 快速交付和反馈：增量模型可以快速交付可用的部分系统，满足用户的紧急需求，并及时获取用户反馈进行调整。
- 风险控制：每个增量的开发和测试过程可帮助发现和解决问题，降低整体项目的风险。
- 灵活性和适应性：可以根据每个增量的反馈进行调整和优化，更好地满足客户需求。
缺点：
- 集成复杂性：随着增量的增加，集成不同增量的功能变得更加复杂，需要更多的集成和系统测试工作。
- 可能存在重复工作：如果某些功能在多个增量中存在重叠，可能会导致重复的开发和测试工作。
- 需要规划和管理：增量模型需要细致的规划和良好的管理，以确保每个增量的交付和集成正确。
适用项目：
- 需求变化频繁的项目：适用于需求变化频繁的项目，能够根据每个增量的反馈及时调整开发方向。
- 多个功能模块的项目：适用于包含多个独立功能模块的项目，可以逐个增量地开发和测试各个模块。
- 可演化的项目：适用于需要逐步改进和扩展的项目，每个增量可以增加系统的功能和特性。
4.迭代模型（Iterative Model）
定义：
迭代模型是一种软件开发过程模型，通过将软件系统的开发分为多个迭代周期进行。每个迭代周期都包含需求分析、设计、开发和测试等开发活动。
主要阶段：
- 需求收集和分析：收集用户需求并进行分析，确定每个迭代周期的目标和优先级。
- 设计和开发：根据需求分析的结果进行系统架构设计、模块设计和代码开发。
- 测试和验证：对每个迭代周期的功能进行测试、验证和质量保证。
- 客户评审和反馈：与客户进行迭代周期的评审，收集反馈并调整需求。
特点：
- 渐进性开发：通过逐步增加功能和特性，渐进地完善整个系统。
- 反复迭代：每个迭代周期包含完整的开发流程，从需求分析到测试验证。
- 高度灵活：可以根据每个迭代周期的评审和反馈来调整需求、设计和开发计划。
优点：
- 快速交付和反馈：迭代模型可以快速交付可用的部分系统，及时获取用户反馈并进行调整。
- 风险控制：通过每个迭代周期的评审和测试活动，及早发现和解决问题，降低整体项目的风险。
- 灵活性和增量性：可以根据需求的变化和优先级，逐步增加功能和特性，提高系统的灵活性和满意度。
缺点：
- 需求管理挑战：需求变动频繁时，需要更加细致的需求管理和变更控制，以避免影响开发进度和质量。
- 迭代成本：迭代模型通常需要多个迭代周期来达到完整系统，可能会增加开发成本和资源投入。
- 沟通和协作要求高：迭代模型要求团队成员之间的高效沟通和紧密协作，及时调整和反馈项目进展和变化。
适用项目：
- 需求不完全稳定的项目：适用于需求存在一定不确定性或变动频繁的项目，能够逐步调整和完善需求。
- 线上产品的快速迭代：适用于线上产品的持续改进和功能迭代，通过每个迭代周期快速响应用户需求。
- 复杂项目的风险控制：适用于复杂项目，通过每个迭代周期的评审、测试和调整来降低项目的风险。
PS：增量模型和迭代模型的区别
增量通常和迭代混为一谈，但是其实两者是有区别的。
- 增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
- 迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
比如：开发上课软件：登录、创建课程、上课
- 增量：登录开发完成->创建课程开发完成->上课开发完成【需要把一个模块开发完再去开发下一个模块】
- 迭代：登录开发一部分->创建课程开发一部分->上课开发一部分【局部开发，不需要把一个模块开发完再去开发下一个模块】
5.敏捷模型（Agile Model）
定义：
敏捷模型是一种软件开发项目管理方法，通过迭代和增量的方式进行开发，以应对需求频繁变化的情况。它强调团队合作、灵活性和持续交付。
PS：《敏捷宣言》
2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。 在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/）： 我们通过身体力行和帮助他人来 揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观。
- 个体与交互重于过程和工具【个体之间面对面沟通】
- 可用的软件重于完备的文档【文档：开发文档、需求文档...】
- 客户协作重于合同谈判
- 响应变化重于遵循计划
- 在每对比对中，后者并非全无价值，但我们更看重前者。
由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)。敏捷的主要贡献在于它更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。
PS：敏捷开发方式——scrum
敏捷开发有很多种方式，其中scrum是比较流行的一种。
①scrum里面的三大角色
- product owner(PO 产品经理)：其中product owner（产品经理）负责整理user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责。
- scrum master(SM 项目经理)：scrum master（项目经理）负责召开各种会议，协调项目，为研发团队服务。
- scrum team(ST 研发团队)：scrum team（研发团队）则由不同技能的成员组成（5-7人，后端开发、前端开发、测试、ui设计师...），通过紧密协同，完成每一次迭代的目标，交付产品。
②迭代开发
- 与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4 周。
- 参与的团队成员一般是5到9人。
- 每期迭代要完成的user story是固定的。
- 每次迭代会产生一定的交付。
③scrum的基本流程
- 产品负责人负责整理user story，形成左侧的product backlog。
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
- 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。
PS：敏捷中的测试
- 挑战1：轻文档
- 挑战2：快速迭代
- 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
- 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试。
- 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一 起研究Bug出现的原因。
主要阶段：
- 需求确定：和利益相关者共同明确项目需求和目标。
- 迭代规划：将项目工作划分为多个迭代周期，并确定每个迭代周期的工作内容。
- 迭代开发：每个迭代周期内，团队完成需求分析、设计、编码、测试和集成等工作。
- 迭代发布：每个迭代周期结束时，发布可工作的软件产品。
- 迭代回顾：评估每个迭代周期的工作，收集反馈并进行调整。
特点：
- 灵活性：能够快速响应需求的变化，支持灵活的项目调整和优先级管理。
- 迭代开发：使用短期迭代周期进行软件开发，逐步完善产品。
- 面向人员合作：强调团队成员之间的合作与沟通，提倡快速反馈和持续改进。
- 持续交付：可快速交付可用的软件产品或功能，以便及早获取用户反馈。
优点：
- 可适应变化：通过迭代和增量的方式应对需求的不断变化。
- 持续交付价值：快速交付可用的软件产品或功能，能够提前满足用户的需求。
- 提高团队协作效率：强调团队成员之间的合作与沟通，促进团队协作效率的提升。
缺点：
- 对团队要求高：需要团队成员具备高度的自律性、责任感和合作能力。
- 高度依赖客户参与：客户的积极参与对于敏捷开发的成功至关重要。
- 需要合适的项目规模和团队规模：适合中小规模的项目和小型开发团队。
适用项目：
- 对产品不断改进和快速交付有较高要求的项目。
- 需求不明确或需求经常变化的项目。
- 它在Web开发、移动应用开发以及其他需要快速迭代和反馈的软件开发领域得到广泛应用。
1353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
