软件开发生命周期（SDLC）是规划，设计，开发，测试和部署高质量软件的过程，该过程以尽可能最低的成本，最好是在最短的时间内完成。为了实现此目标，软件工程团队必须选择正确的软件开发模型，以适合其组织的需求，利益相关者的期望和项目。
项目的详细信息，包括时间表和预算，应会影响您对模型的选择。目的是选择一个可以确保项目成功的软件开发模型。选择不正确的模型将导致制定时间表，超出预算，输出质量低下甚至导致项目失败。
软件开发模型
有无数的软件开发模型，每个模型都有各自的优缺点。模型对项目的质量，预算，时间表和利益相关者的最终满意度（或可能缺乏满意度）有很大的影响。
1.瀑布模型
Waterfall模型是软件开发的第一种方法。该过程包括按顺序进行线性开发阶段：分析，设计，开发，测试，部署和维护。每个阶段都有明确的定义，包括特定的可交付成果和里程碑。
Waterfall模型是顺序线性的，这意味着直到当前阶段完成，下一步才能开始。当达到目标并有人签署项目进展时，阶段就完成了。
此模型没有灵活性，不能跳过，回溯或重叠阶段。调整结果困难且昂贵。
无论何时发现错误，都必须在维护阶段才能修复。
缺乏灵活性使该模型比其他模型更昂贵，更耗时。如果需求不清楚或被误解，则此模型具有很大的风险。瀑布模型对于需要更大灵活性的长期，复杂或正在进行的项目也不理想。
尽管此模型的缺点非常明显，但由于其简单易用且可快速配置的优点，因此可用于小型的一次性项目，且需求少，时间表短。团队必须确保所有需求都定义明确，明确且固定。
但是，瀑布模型的缺点大于优点。因此，随着IT团队实践更加敏捷的软件开发，允许增加的灵活性，沟通和不断的改进，该模型已不再流行。
2. V型
V模型（或验证和验证模型）在Waterfall模型上进行了扩展，并增加了早期测试计划。V-Model不再向下移动到软件开发阶段，而是向下移动直到编码阶段，直到它旋转并开始向上上升以形成“ V”形。
每个开发阶段都有相应的测试活动。这使团队可以在项目开发的早期阶段检测需求规范，代码和体系结构中的错误。不幸的是，由于没有解决这些问题的明确途径，修复错误仍然是困难且昂贵的。
与瀑布模型相比，早期测试计划的加入使V模型获得成功的机会更大。但是，V模型仍然是线性的，使其不灵活。
与瀑布模型一样，团队只能在当前阶段完成后才开始下一个阶段。这使得调整困难，昂贵且费时。
因此，该模型最适合于具有固定，明确定义的，记录在案的需求的短期项目，但对于长期，复杂或正在进行的项目则不是理想的选择。
3.迭代（和增量）模型
就像模型名称所暗示的那样，这些重复的循环是迭代的（重复的）和增量的（在短时间内发生）。
软件开发过程从一小组需求开始，并且每个周期都伴随着一组新需求。该模型的迭代性质使软件能够继续发展和增长，因为可以在整个过程中进行较小的更改，因为最新的迭代是基于先前的迭代构建的。开发人员可以根据以前的周期进行更改。
由于在项目开始时并未概述所有需求，并且在此过程中进行了许多更改，因此可以快速开始工作。但是，由于该过程经常重复，因此资源可能会很快消耗掉，更不用说管理变得更加复杂了。
此外，尽管此模型允许一些更改请求，但它仍然由定义的过程组成，有时会导致灵活性不足。即使更改的成本低于瀑布模型和V模型，该模型也不适合在迭代过程中需求可能发生变化的项目。
迭代模型可能会带来更多风险，包括频繁更改，未知的成本和资源要求以及不确定的期限。
4.原型模型
原型模型的中心在于通过创建原型来提高开发团队对客户需求的理解。通过创建所需软件程序的有效小规模副本，可以在进行全面开发之前解决沟通不善或误解。
在开发人员开始开发最终产品之前，他们会创建他们认为客户想要的产品的原型。根据客户反馈对原型进行开发，测试和完善。一旦原型被接受，团队便开始开发最终产品。
由于客户的早期反馈，原型模型可以大大减少SDLC所需的迭代次数。这样可以节省时间并增加客户满意度的机会。
尽管节省了一些时间，但是您必须考虑开发人员花费在开发原型上的时间。如果客户需要进行很多更改，频繁地改变主意或提出无法满足的要求，则这次开发原型可以很快实现。因此，最好在必须接受原型之前对允许的迭代次数设置上限。
当最终的原型正在开发中时，就不能再对计划做出任何要求或更改。这是原型制作模型的重大缺陷。
5.螺旋模型
螺旋模型侧重于风险评估。因此，任何希望使用此模型的团队都必须拥有在该领域具有知识和技能的人员。
该模型分为四个阶段，将模型划分为多个象限：计划，风险分析，工程和评估。螺旋中的循环数取决于特定项目和项目经理的判断力。使用此模型平均需要6个月的软件开发时间。
它通过强调设计（包括原型设计）（在工程阶段）以及遵循与Waterfall模型中相似的阶段，结合了Waterfall模型和原型模型的功能。
连续不断的开发使开发人员可以在管理风险的同时进行更改和添加新功能。此外，开发是系统的，可简化流程。
让客户参与检查周期的每个阶段，如果客户行动缓慢或缺乏反馈，这可能会给开发过程带来麻烦。但是，在工程阶段不允许更改客户。
因为循环或迭代的数量是不确定的，所以存在超出预算且未达到期限的风险。获得最终产品通常是昂贵且费时的。
此外，该模型针对每个客户进行了高度定制，因此无法重复使用您的工作。
敏捷方法论——敏捷模型
通过专注于协作，沟通和不断变化，开发敏捷技术是为了比包括瀑布技术在内的以前的方法更有效地交付更好的软件。
敏捷的采用是迅速而持续，有几种敏捷软件开发模型。这些模型侧重于团队合作，跨职能协作，迭代开发和早期客户反馈。通过测试，反馈和调整，团队可以开发和交付最佳软件。
Scrum模型——轻量级流程框架
Scrum模型是最受欢迎的敏捷模型。它的软件开发迭代称为sprint。Scrum不是SDLC模型，它是轻量级流程框架，实现了增量迭代模型。
在这1-4周的冲刺中，团队评估先前的冲刺，添加新功能（经过编码和测试的功能）并计划下一个冲刺。定义sprint活动后，不允许进行更改。
在每个冲刺之后，添加新功能/项目以在下一个冲刺中进行编码和测试。这将一直发生，直到添加了所有功能，并且该项目被视为可以发布为止。
跨职能团队之间以及组织与客户之间增强的协作减少了由于沟通不足而造成的猜测和错误。此外，增量阶段减少了上市时间。
增强的通信减少了解决错误所花费的时间，并增加了最终用户对产品感到满意的可能性。但是，在此过程中，这种协作确实需要来自客户的更多投入和时间。如果请求和添加的功能过多，则团队可能会推迟截止日期。
看板模型
看板是敏捷模型，不属于SDLC模型，过程或框架。这是一种进化过程改进的方法，可以应用于不同的过程，也是我们今天将讨论的最终模型。
与其他模型不同，看板没有明显的迭代。如果团队确实计划迭代，那么它们的冲刺将非常短，有时甚至只有一天。
使用带有粘滞便笺的看板来直观地概述项目及其详细信息，包括项目所有者和进度状态。这种可视化使团队可以将精力集中在当前开发中最重要的功能上。
此外，看板还突出显示了剩余空间，以便不断完善功能。
尽管板上的便签方法有助于激励团队专注于完善手头的重要任务，但这是定义和维护时间表的一种糟糕方法。因此，计划长期项目非常困难。
由于没有设定的计划阶段，因此可以随时进行更改。看板的一个常见缺点是缺乏时间框架。如果不断进行更改，则会加剧此问题。
向敏捷的转变
创建每个模型都是为了改善软件开发和交付过程。如今，每种软件开发模型都适用于特定类型的项目。但是，较早的手动模型（例如Waterfall）已迅速成为历史。
IT团队和整个企业必须更快，更有效地行动，以交付软件，取悦最终用户并与竞争保持同步。自动化的基础是更快，可重复且更安全的软件开发过程。
许多模型都无法达到这种自动化程度和速度。结果，敏捷方法变得越来越流行。
所以，根据项目选择合适的软件开发模型非常有必要。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。