迭代模型,增量模型和敏捷模型之间有什么区别?


回答 1:

在开发的迭代模型中,我们迭代想法,并在迭代各种版本时不断对其进行改进。 如

您从一个版本转到另一个版本,您(根据反馈)决定在新版本中需要什么作为更好的选择以及将哪些东西扔掉。

在增量模型中,您可以部分构建整体解决方案,但在每个阶段或部分结束时您都没有

任何可以审查或提供反馈的东西。 您需要等到最后阶段,才能进行增量过程以交付最终产品。

下面是一个直观的示例(来自Internet),很好地描述了这一点(顶部是增量,底部是迭代):


回答 2:

增量方法是一种软件开发方法,其中,模型的设计,实现和测试是逐步进行的(每次都会添加一些),直到产品完成为止。 它涉及开发和维护。 满足所有要求的产品定义为成品

迭代设计是一种基于对产品或过程进行原型设计,测试,分析和改进的循环过程的设计方法。 根据测试设计的最新迭代的结果,可以进行更改和完善。 此过程旨在最终改善设计的质量和功能。 在迭代设计中,随着设计的连续版本或迭代,与设计的系统进行交互被用作通知和发展项目的研究形式。

软件以递增,快速的周期开发。 每个版本都经过全面测试,以确保维持软件质量。 极限编程(XP)是当前最著名的敏捷开发生命周期模型之一。 敏捷测试涉及从客户角度进行测试。

要了解更多免费视频,请访问:软件测试教程


回答 3:

“常规”工程和软件工程之间通常存在关键的区别。 由于常规工程产品在开始使用前需要完成一些工作,因此规格通常必须早于施工开始。 但是可以测试许多完整的组件。 “现实世界”中的另一个细节是,如果不将不同组件集成到完整设备的模型中,则很难测试它们。 确实有时候您必须打开Gizmo并观察会发生什么。 对于非常复杂的系统,要等到第一次迭代(大部分)完成后才能真正开始测试。

显然,许多软件系统并非如此。 当伪造大部分系统非常困难,并且在压力下的行为实际上很难或不可能实现时,尤其如此。 因此,我们需要理顺开发过程,以使完成的概念几乎不可见。 简化大型系统(例如税收或国家飞机的飞行控制)通常是不可能的,因为极端需求的时刻既难以模拟,而且异常复杂。

可以将软件开发的演变轻松地看作是对开发方法的一系列尝试,这些方法既可以完成定义明确的任务,又可以在意料之外的重负载下做到这一点。 验证架构以成功地从各种输入混合中成功生成适当的输出可能是NP完整的情况,在这种情况下,正确性是可能的,但是由于标准的组合爆炸,测试阶段的寿命超过了整个宇宙。

因此,我们已经看到了对开发流程蓝图的一系列修订,这些蓝图试图创建涵盖工作的一小部分的规范,自己进行测试,然后在集成到最终系统的较大部分时对其进行测试。 在过去的50年中,组件的相对尺寸以及系统测试的程度不断增加。

提出的问题涉及缩小平均组件大小和复杂性并增加测试过程的简便性的技术。 为开发过程的连续方式命名可以提供一种有用的方式来引用它们,但是将过程的名称转移到过程的不同且更复杂的部分非常容易。 通常,新名称在解决问题上不会走得太远,这些问题由于使用了新名称及其技术而变得显而易见。

我认为最好查看一种(较新的)技术,并查看其应用程序提供了什么。 采取敏捷。 日常的混乱,很少有个人的承诺,即使没有落在轨道上,也至少会使项目保持靠近。 认真地进行回归测试(任何时候发现的任何错误都会成为测试套件中的另一个项目,并且每天都会重新运行)是令人沮丧,昂贵且绝对必要的。 交付是增量的,其顺序由对用户的有用性而不是开发过程的逻辑确定。

这些考虑因素通过将不可避免的未来成本转移到现在而增加了项目成本。 钱用得其所。

每种常见的开发技术都为不断发展和改进的过程做出了一点点的贡献。 但是没有一套技术可以保证成功。

在考虑所涉及的挫败感时,我发现牢记海军建筑很有用。 例如,对于潜水艇来说,大多数设备无法通过前门安装,可能需要将潜水艇从水里捞出来,开一个大孔并安装新的齿轮,才能进行更改。 然后,您需要将孔焊接好,并确保新修补的表面不会泄漏


回答 4:

迭代模型是首先创建具有很少功能的简单原型的模型。 之后,在每个开发周期中都会向其中添加功能。 在使用增量模型的情况下,您将能够以向前移动的方式从项目的概念化,设计,开发等阶段进入开发阶段。最后,敏捷开发中包括了不同的开发模型,并且遵循迭代方法本身。 如果您想进一步了解开发方法,可以查阅本文。