目录
一、The Waterfall Model （瀑布模型）
1.1 介绍
又称为线性顺序模型，它提出了一种系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。
1.2 优点
容易理解和计划；
适用于充分了解的小型项目；
分析和测试是顺序线性的。
1.3 缺点
不能很好地适应变化；
测试在过程的后期进行；
客户确认在最后阶段。
二、The Incremental Model（增量模型）
2.1 介绍
开发过程被划分为多个小的增量或部分，每个增量都包含部分功能。
新功能可以在后续增量中添加，允许更灵活的需求管理。
每个增量都经历类似的阶段，例如需求、设计、实施和测试。
2.2 优点
客户可以在早期阶段看到一部分功能；
开发顺序灵活，可以按照组件优先级实现。逐渐扩展，便于用户在开发过程中需求渐渐明朗，有效适应用户需求的变更；
组件化，减少软件开发风险，一个开发周期的错误不会影响到整个软件系统
2.3 缺点
需要仔细协调多个增量的开发和测试；
需求管理挑战；
需要精细的需求管理来确保每个增量都满足客户期望。
三、Prototyping Model（原型模型）
3.1 介绍
快速创建一个原型，以帮助客户和团队更好地理解需求。
原型用于收集用户反馈，进一步改进需求。
适用于项目初期需求不明确或复杂的情况。
3.2 优点
变更需求对后续设计影响较小；
客户很早并频繁地参加其中；
对小型项目来说效果好；
产品失败的可能性降低。
3.3 缺点
客户的参与可能会导致进度延迟；
提交一个原型，可能造成初步完成的假象；
原型被抛弃导致工作白干；
很难计划和管理。
四、The Spiral Model（螺旋模型）
4.1 介绍
开发过程按照螺旋状路径，每个循环包含沟通、策划、建模、构建和部署。
强调风险分析和管理，每个循环都包括评估和处理风险。
每个迭代结束时都有一个部分可交付成果。
4.2 优点
有持续不断的客户参加；
开发风险得到控制；
适用于大型复杂项目；
适用于可扩展的产品。
4.3 缺点
风险分析失效可能导致项目失败；
项目可能难于管理；
需要一个专家开发团队。
五、UP（统一过程模型）
5.1 介绍
强调基于用例的需求分析和建模。
包括沟通、策划、建模、构建、部署和软件增量阶段，分为起始、细化、构建、转换和发布生产等步骤。
重视文档化，包括用例规格、设计文档等。
5.2 优点
重视质量文档；
有持续不断的客户参与；
适合需求变更的情况；
对维护项目非常有效。
5.3 缺点
用例并不总是准确的；
具有复杂的软件增量集成；
阶段的重叠可能会带来问题；需要一个专家开发团队。
六、Scrum
6.1 介绍
将开发工作划分为固定长度的迭代周期（冲刺）。
团队自行管理工作和任务。
强调团队合作和持续反馈。有冲刺规划会议、每日Scrum会议、冲刺评审会议、冲刺回顾等会议。
6.2 优点
产品负责人设置优先级；
团队拥有决策权；
文档是轻量级的；
支持频繁更新。
6.3 缺点
很难控制变更的成本；
可能不适用于大型的团队；
需要专家团队成员。
七、XP（极限编程）
7.1 介绍
分为策划、设计、编码和测试四个框架活动。
策划：倾听用户故事以及系统功能，在每个迭代周期开始前，制定冲刺计划，对计划中的任务进行优先级排序。
设计：强调简单、可维护的设计。整个团队分享对代码的所有权，鼓励相互改进代码。
开发时进行代码重构，以改善代码质量。
编码：先编写测试用例，后编写代码来通过测试。编写代码时人员成对工作。
测试：强调自动化测试，包括单元测试、集成测试和验收测试。
7.2 优点
强调客户参与；
建立合理的计划和时间表；
开发人员对项目的高度投入；
产品失败的可能性低。
7.3 缺点
会受到“交付”原型的诱惑；
需要经常开会，导致成本上涨；
可能允许过多的变更；
对高度熟练的团队成员具有依赖性。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
