软件工程|敏捷模型与其他模型的比较

3年前发布

589

敏捷模型与其他模型的特征比较如下：

null

敏捷模型与瀑布模型：

敏捷模型	瀑布模型
敏捷模型是一个增量交付过程，其中每个增量交付的部分都是在每个时间段后通过迭代开发的。	瀑布模型是高度结构化的，系统化地以有计划的方式逐步完成需求收集、分析、SRS文档准备、设计、编码和测试。瀑布模型的这些阶段遵循顺序。
在使用敏捷模型时，进度是根据开发和交付的功能来衡量的。	在瀑布模型中，进度通常根据已完成和已审核的人工制品的数量来衡量，如需求规范、设计文档、测试计划、代码审核等，这些人工制品的审核已完成。
在敏捷模式下，即使一个项目中途被取消，它仍然会给客户留下一些有价值的代码，这些代码可能已经投入实际运行。	如果一个使用瀑布模型开发的项目在开发过程中中途被取消，那么除了几个文档之外，这个被放弃的项目没有什么可以展示的。
敏捷模型允许在开发过程开始后更改需求，因此更加灵活。	瀑布模型是刚性的，它不允许在开发过程开始后更改需求。
客户互动度很高。每次迭代之后，都会向客户部署一个增量版本。	客户互动非常少。产品在整体开发完成后交付给客户。
缺乏适当的正式文件会造成大量的范围混乱，在各个阶段做出的重要决策可能会在以后的阶段被误解。	在瀑布模型中，适当的文档是非常重要的，它给出了完成项目应该做什么的清晰想法，它还可以作为客户和开发团队之间的协议。
敏捷团队由较少的成员组成（5到9人），但他们与他人的协调和互动非常频繁。	在瀑布模型中，团队可能由更多的成员组成，但他们之间的互动是有限的。
敏捷模型不适用于小项目，因为与其他模型相比，使用敏捷模型开发小项目的成本更高。	该模型易于使用和理解，但不适合使用瀑布模型开发大型项目。

敏捷模型与探索性编程：

敏捷模型	探索性编程
敏捷模型是一个增量交付过程，其中每个增量交付的部分都是在每个时间段后通过迭代开发的。	探索性编程是一种以非结构化方式编写程序的方法。
然而，敏捷团队确实遵循定义和规范的流程，并进行系统的需求收集和严格的设计。	探索性编程不遵循软件工程的规则，非结构化编码已经完成并经过测试。
敏捷模型的核心思想是在每次迭代后频繁地向客户交付增量版本。	然而，在编码之后，软件会被测试，发现的错误会被修复。这个测试和错误修复的周期将持续下去，直到软件为客户满意地工作为止。

敏捷模式Vs RAD模式：

敏捷模型	RAD模型
敏捷模型不建议开发原型，但强调在每次迭代结束时系统地开发每个增量特性。	RAD的中心主题是设计快速而肮脏的原型，然后将其细化为生产质量代码。
敏捷项目在逻辑上将解决方案分解为增量开发和交付的功能。	使用RAD模型的开发人员专注于开发应用程序的所有功能，他们首先做得不好，然后随着时间的推移不断改进代码。
敏捷团队只在每次迭代后向客户展示已完成的工作。	尽管RAD团队向客户展示了屏幕模型和原型，但这可能是基于表格查找等简化，而不是实际计算。
敏捷模型不适用于小项目，因为很难将项目划分为可增量开发的小部分。	当公司还没有开发出几乎类似类型的项目时，就很难使用RAD模型，因为它无法重用现有的代码。

敏捷模式与增量开发模式：

敏捷模型	增量开发模式
敏捷模型是一个增量交付过程，其中每个增量交付的部分都是在每个时间段之后通过迭代开发的。敏捷模型的主要原则是通过消除浪费时间和精力的不必要活动来实现敏捷性。	软件的需求分为几个模块，这些模块可以增量开发和交付。首先开发核心功能，然后通过在后续版本中添加新功能来开发整个软件。
在敏捷模型中，迭代的结束日期是固定的，不能更改。开发团队可能必须决定减少交付的功能，以便按时完成该迭代。	在增量开发模型中，没有固定的时间来完成下一次迭代。

敏捷模式与螺旋模式：

敏捷模型	螺旋模型
敏捷模型的主要原则是通过消除浪费时间和精力的不必要活动来实现敏捷性。	螺旋模型的主要原理是风险处理。
敏捷模型侧重于在每个时间段之后向客户交付增量，因此客户交互更加频繁。	螺旋模型主要处理各种未预料到的风险，但客户互动较少。
敏捷模型适用于易于划分为小部分的大型项目，这些小部分可以在每次迭代中轻松地增量开发。	螺旋模型适用于那些容易发生各种风险的项目，这些风险在项目开始时很难预测。
敏捷模型不依赖文档。	螺旋模型需要适当的文件。

© 版权声明

文章版权归作者所有，未经允许请勿转载。

THE END

喜欢就支持一下吧

相关推荐