我对SDLC的理解意味着它包括计划，设计，代码，构建，部署和维护应用程序的阶段。反过来，每个子阶段包括代码管理或配置管理，发布管理等子阶段。尤其是在敏捷方法中。因此，所有这些阶段和子阶段构成了应用程序开发的最佳实践手册。
最近（ITIL的初学者和新手），在阅读ITIL实践，特别是其生命周期时，除了重复单词＆＃34; service＆＃34;之外，我无法获得ITIL优于SDLC的任何优势。在ITIL很多次。
ITService是什么意思，因为它在ITIL中得到了很大的重视？那个定义单词＆＃34; service＆＃34;使ITIL优于SDLC？在使用Google进行搜索时，我发现了这样的定义：“通过促进客户希望实现的结果为客户提供价值的方法，而无需特定成本和风险的所有权”。但我仍然无法理解它的优势。如果他们的阶段之间没有差异，那么两种模型的存在有什么用。
当然，上面的解释是我理解的方式，因为无法理解差异和服务＆＃34;。我要求任何人就上述主题提供一些启示。
答案 0 :(得分：3)
在我的组织中，我们不使用ITIL标准来指导软件开发项目或任务。相反，我们使用ITIL来管理面向客户（和面向内部）的服务运营模型。
例如，我们的故障单系统利用ITIL命名法和原则对软件进行分类，分类和跟踪问题。当用户通过提交票证报告问题时，我们遵循ITIL服务标准，建议为了提供最好的服务，我们应该做任何我们需要做的事情来解决事件 - 即使这意味着建立一个变通方法。这为客户提供了良好的服务，因为它可以最大限度地减少客户停机时间。
恢复操作后（通过变通方法或快速错误修复），将为后续编程工作创建长期问题，缺陷或增强项。正是在这个阶段，我们建立SDLC流程，优先考虑开发和发布（业务理由，变更董事会批准，需求收集，编程，QAT，UAT，发布等......）。
因此，总而言之，我们主要将ITIL用于面向客户的服务运营流程。 SDLC在内部用于实际跟踪和管理软件开发的后勤工作直至完成。
答案 1 :(得分：2)
在这个问题上最无知，以下是关于这个问题的2美分（我也试图找到答案）：据我所知，如果我们能够解释这个问题就很容易了解通常计划实施后支持的方式。在理想情况下，部署后服务计划应在应用程序设计阶段正确开始，同时分析功能和非功能需求。那是因为在这个时候，我们应该开始吸引那些支持PRODUCTION应用程序的运营人员，因此负责为服务台做好准备，为已知的设计缺陷开发变通方法，对已知错误数据库进行更改，更新配置管理数据库，设置访问管理工作流程等（ITIL所讨论的所有内容）
因此，ITIL与SDLC重叠，但提供了有关如何在应用程序部署（SDLC的维护阶段）之后管理服务的更详细指南。从我所看到的情况来看，几乎所有SDLC框架都对SDLC的这一阶段提供了非常有限的指导，这也是ITIL填补这一空白的原因。从本质上讲，组织需要集成这两个流程以获得最大的收益（事实上，除非IT治理的其他框架+质量管理+安全管理也被集成，否则图片将不会完整）。 最重要的是：没有一个框架能够管理整个IT生命周期，你必须做很多混合和放大。匹配以达到适当的深度和水平您组织的广泛流程。
最后，就应用程序与服务的混淆而言，正如他们在营销中所说的那样，您很少拥有纯粹的产品或服务。它通常是一个集成的产品，两者互为补充，构成了整个客户体验。不过，我认为产品和产品之间的界限。服务提供商比服务消费者更重要。话虽如此，ITIL似乎更专注于为产品/应用程序提供高质量的服务（无论产品有多好或多糟糕）。
答案 2 :(得分：2)
到目前为止，我已经看到了这两个，当我有一个为我的客户提供价值的系统时，我使用ITSM方法通过始终如一地满足客户的期望来确保该服务发挥最大潜力。在管理我的IT服务时，我们发现了变革的机会，我利用SDLC来创建和交付通过我的ITSM实践确定的变更。这两个市场之间肯定存在重叠的活动，但它们基本上互为服务。 SDLC以产品为重点，ITSM专注于客户服务。
答案 3 :(得分：0)
简单的问题很难回答:) 当使用维基百科时，可能会遇到这种＆＃34;服务＆＃34;定义：
（雄性动物）的服务与（雌性动物）交配。 ＆＃34;一只狗可能在一天内为几只母狗提供服务＆＃34;
所以我更愿意看看领导者的意见......
IT怀疑论者（Rob England）在框架领域是众所周知的专业人士。在这里他的2个版本and thoughts：
当您查看该文章中的讨论时，您可以轻松找到其他代表性和参考：