您是否曾经停下脚步，想知道为什么我们需要如此频繁地更新软件？ 例如，考虑一下普通的智能手机。 您会在这款手机中找到一些常见的应用程序，例如Facebook，Twitter，Instagram，也许还有其他一些可能会在日常生活中帮助用户的应用程序，但接下来让我们专注于前三个。 它们全部（几乎）每周更新一次。 添加其他应用程序，再加上操作系统安全补丁，更新和错误修复，您的手机几乎每天都在更新某些内容。
用户可能不知道这一点，但是这些应用程序总是在更改，无论他们是否可以看到更改。 这就是我们谈论软件开发生命周期时所指的内容：开发一件软件所需的多个步骤。 这些步骤通常是一个永无止境的周期的一部分，这解释了为什么会有如此多的更新。
SDLC的一些常见阶段包括计划，分析，设计，构建，测试，部署和维护。 乍一看，似乎只经历了一系列步骤，但是最后一步，即维护，通常意味着必须重新开始才能使程序更好。 请注意，我经常但不总是说，我们稍后再讲。
拥有“生命周期”的全部目的是能够发现软件中的错误，故障或错误，以免它们造成麻烦，甚至更糟的是，导致最终用户产生负面反馈（这是“真的那么糟糕，因为最终的负面反馈仍然是一种反馈形式，您可以使用它来改善，但仍然可以）。 为了您的利益而使用SDLC通常可以节省时间，金钱，最重要的是可以提高产品的整体质量。
SDLC中最受欢迎的两种方法是“敏捷”和“瀑布”。 它们之间的主要区别在于敏捷是周期性的，而瀑布不是周期性的。 尽管似乎敏捷总是在击败瀑布，但在某些情况下，瀑布占了上风。
敏捷
敏捷模型虽然相对较新，但由于其迭代方法而广受欢迎，这使我们可以在每次迭代中使我们的软件更好。 如今，许多软件组织都对敏捷的处事方式发誓，因为它们使我们能够适应不断变化的客户需求，他们经常希望每次迭代都提供更多功能，并且与其他软件相比具有一定的灵活性型号，同时仍允许快速交付。
敏捷的项目处理方式与我们在分而治之算法中看到的方式有些相似，在分而治之算法中，我们将一个大项目分为几个更短，更易于管理的部分，从而缩短了期限并简化了开发。 这些较短的期限也使我们能够专注于所谓的“冲刺”，这基本上意味着完全专注于解决手头的任务以更快地完成任务。
瀑布
与敏捷相比，瀑布要古老得多。 它甚至可能是用于管理软件项目的最古老的模型。 因此，这使它成为最简单的方法（有人甚至可以将其称为蛮力方法）。 通过这种方法，尽管我们仍需要几个阶段来开发软件，但我们一次只专注于一个阶段，这意味着您无法完全进入下一个阶段，除非您完全确定上一个阶段已成功完成。
瀑布式的一步一步方法注定了它。 它一如既往的严格，如果您搞砸了，则不允许您返回到先前的阶段，从而导致项目开发后期浪费大量时间，导致工程师浪费更多的时间来解决问题，而不仅仅是回头并修改方法。
但是，正如我之前提到的，循环方法并不总是解决方案。 在从一开始就需要完成的项目中，瀑布仍然被证明是有用的。 例如，考虑一下火箭发射。 您无法继续思考“好吧，如果失败，我们将进行另一次迭代并使其正确……最终。”。从一开始就需要完美解决方案的项目可能会受益于诸如瀑布，即使这意味着必须花费更多的时间来使事情完美运行。
