概述
应用程序生命周期管理（ALM）是对软件应用程序从初始规划到退役的监督。它还指如何记录和跟踪应用程序的更改。
http://s3.nutanixworkshops.com/calm/alm/image1.png
定义应用程序生命周期管理（ALM）并不容易。不同的人（和不同的供应商）有着截然不同的观点。尽管如此，ALM是一个重要的主题，因此了解它包含的内容也很重要。
将ALM等同于软件开发生命周期（SDLC）是很常见的。然而，这种简单的方法过于局限；ALM不仅仅是SDLC。事实上，应用程序的生命周期包括组织在该资产上花钱的整个时间，从最初的想法到应用程序生命周期的结束。应用程序生命周期管理（ALM）是对软件应用程序从初始规划到退役的监督。它还指如何记录和跟踪应用程序的更改。
http://s3.nutanixworkshops.com/calm/alm/image9.png
应用程序组合管理
应用程序组合管理（APM）是一个用于管理企业IT软件应用程序和基于软件的服务的框架。APM为管理人员提供了公司软件应用程序的清单和衡量标准，以说明每个应用程序的业务优势。
应用程序组合管理是IT治理的重要组成部分。它使组织能够以高度透明的方式清点和管理其所有应用程序。
应用程序组合管理是一种管理整个企业的IT软件应用程序和基于软件的服务的方法。根据一组常见的战略投资驱动因素映射软件应用程序，可以让您就维护、投资、退役或整合哪些应用程序做出关键决策。我们的APM方法以成本、性能和与业务需求的战略一致性为中心。
APM系统使用评分算法来生成关于每个应用程序的价值和整个IT基础设施的健康状况的报告。通过收集应用程序的使用年限、使用频率、维护成本及其与其他应用程序的相互关系等指标，管理者可以不仅仅通过有根据的猜测来决定是否应该保留(kept)、更新（update)、退役(retire)或更换（replace)特定的应用程序。
应用程序生命周期管理
ALM是一个非常宽泛的术语，反映了对软件开发态度的变化，也在术语DevOps中表达。DevOps融合了公司应用程序开发和系统运营团队执行的任务。在过去，开发团队可能使用瀑布式开发模型独立工作，并将完成的软件应用程序交给运营团队进行部署和维护。如今，开发人员更有可能使用敏捷模型，并在部署后继续参与应用程序，与业务所有者和运营部门合作，根据需要进行增量更改。
ALM可以分为三个不同的领域：治理、开发和运营。下图说明了这一点，在自己的水平线上显示了这三个方面中的每一个。
就像人类生活一样，应用程序的生命周期是由重大事件划分的。它以一个想法开始：“我们为什么不构建这样的东西呢？”一旦创建了应用程序，下一个重大事件就是部署，当应用程序进入生产时。最后，当它不再具有业务价值时，应用程序将终止使用并停止服务。
- 治理：它包括该应用程序的所有决策和项目管理，并在整个时间内扩展。
- 开发：实际创建应用程序的过程，首先发生在构思和部署之间。对于大多数应用程序，在应用程序的生命周期中，无论是升级还是全新版本，开发过程都会再次出现好几次。
- 运营：运行和管理应用程序所需的工作，通常在部署前不久开始，然后持续运行，直到应用程序从服务中删除。这三个领域中的每一个都很重要，因此每一个领域都值得更详细地研究。
治理
在ALM中，治理的目的是确保应用程序始终提供业务所需的内容。下图提供了ALM治理的特写视图，提供了更多关于其内容的细节。
http://s3.nutanixworkshops.com/calm/alm/image11.png
ALM治理的第一步是业务案例开发。如上图所示，此分析发生在开发过程开始之前。一旦业务案例获得批准，应用程序开发就开始了，现在通过项目组合管理来实现治理。在一些组织中，这很简单：项目经理可能隶属于开发团队，或者团队中的一名技术人员可能会担任这个角色。其他组织使用更正式的方法，依靠集中的项目管理办公室（PMO）来执行既定的程序。一旦完成的应用程序被部署，它就成为组织应用程序组合的一部分。应用程序和其他应用程序一样是一种资产，因此组织需要不断了解其收益和成本。应用程序组合管理（APM）提供了这一点，提供了一种避免跨不同应用程序重复功能的方法。APM还为已部署的应用程序提供管理，解决诸如何时更新和更大的修订具有业务意义之类的问题。事实上，更详细地检查Governance行的APM部分会发现，它包含了针对development行中显示的应用程序的每个修订的业务案例开发和项目组合管理。
治理是贯穿整个ALM时间跨度的唯一内容。从很多方面来说，这是ALM最重要的方面。如果弄错了，你就无法实现应用程序的业务价值最大化。
开发
虽然将ALM等同于软件开发过程并不准确，但开发无疑是每个自定义应用程序生命周期的基本组成部分。下图详细介绍了ALM的这一方面。
http://s3.nutanixworkshops.com/calm/alm/image12.png
一旦业务案例获得批准，软件开发生命周期就开始了。如果我们扩展图中所示开发线的SDLC部分，那么现代流程可能会将软件开发显示为一系列迭代。每个迭代都包含一些需求定义、一些设计、一些开发和一些测试。这种迭代式的开发风格并不总是合适的——有些项目仍然可以使用更传统的方法来完成——但它正在成为许多领域的规范。
一旦应用程序版本1的SDLC过程完成，应用程序就会部署。然而，对于大多数应用程序来说，部署并不意味着开发的结束。相反，应用程序需要定期更新，如上图所示，并且可能需要一个或多个完整的SDLC来创建新版本，如本例所示。对于一些应用程序来说，花在这些更新和新版本上的钱可能会大大超过原始开发的成本。
再次注意SDLC在整个ALM流程中的作用。正如上图所示，这一方面当然很重要，但还远远不是全部。将ALM视为SDLC的同义词是错误的——这会导致人们误解在这一领域取得成功真正需要什么。
运营
必须监视和管理每个部署的应用程序。下图显示了此操作过程中的一些重要部分。
http://s3.nutanixworkshops.com/calm/alm/image13.png
与治理一样，运营线与开发线紧密相连。例如，部署计划可能在应用程序完成前不久就开始了，而部署行为本身是操作的基本部分。一旦部署了应用程序，就必须在其整个生命周期中对其进行监控。类似地，应用程序的每次更新都必须在完成后进行部署，如图所示。
应用程序发布管理
发布管理是软件工程中一个相对较新但发展迅速的学科。随着软件系统、软件开发过程和资源变得更加分散，它们必然变得更加专业化和复杂。此外，软件产品（尤其是web应用程序）通常处于开发、测试和发布的持续循环中，通常在不断发展的平台上运行，复杂性不断增加。这样的系统需要专门的资源来监督开发、测试、部署和支持的集成和流程。
在使用IT服务管理范式（特别是ITIL框架）管理IT运营的组织中，发布管理将以ITIL概念和原则为指导。有几个正式的ITIL流程与发布管理有关，主要是发布和部署管理流程，该流程“旨在计划、安排和控制发布到测试和实际环境的移动”。以及变更管理流程在ITIL组织中，发布的频率往往低于敏捷开发环境。发布流程由IT运营团队使用IT服务管理票务系统进行管理，较少关注发布流程的自动化。
构建/发布
构建是一个软件应用程序，它由一组功能和一些错误修复组成，并经过测试，直到它变得稳定。所以基本上，简单来说，它是一个不断增长的应用程序，第一个版本将有一些要求和功能。比方说，10%的软件是开发出来的。下一个版本将修复错误（即第一个版本中的错误已修复），并添加了一些新功能。比方说，它现在20%的软件都是开发出来的。
这个过程一直持续到100%，即直到构建稳定。。意味着没有错误或只有很少的错误，并且所有功能都已开发完成。这意味着它是一个完整的软件，可以随时使用。这个最终构建称为软件应用程序。
当客户同意他们现在只需要该软件的基本功能时，这被称为发布，因为他们不能等到所有功能都开发出来，开发软件的公司可以在第一次发布后开发接下来的几个功能（具有基本功能的软件/客户的要求已经得到满足）
持续交付
采用敏捷软件开发的组织看到了更高数量的发布[需要引用]。随着敏捷开发的日益普及，一种被称为“持续交付”的软件发布新方法开始影响软件从开发到发布的过渡。持续交付和DevOps的一个目标是更快、更频繁地发布更可靠的应用程序。应用程序从不同环境中的“构建”移动到作为“发布”的生产，是连续交付管道的一部分。发布经理们开始利用应用程序发布自动化和持续集成工具等工具来帮助推进持续交付流程，并通过自动化任务来融入DevOps文化，以便更快、更可靠、更可重复地完成任务。越来越多的软件发布导致越来越依赖发布管理和自动化工具来执行这些复杂的应用程序发布过程。
软件QA
QA往往专注于测量和检查质量，并通过流程改进来改进软件，从而指导向客户发布。尽管测试活动通常在这个组织中进行，但QA的主要关注点是软件开发活动如何进行的过程和程序。
QA更侧重于管理产品生命周期，并验证软件是否符合定义的质量标准或客户协议。QA与其说是破坏软件并发现问题，不如说是验证软件是否有可能在给定的条件下工作。
软件测试
另一方面，测试可能会关注流程并经常拥有它们，但更关心的是找到破坏软件的方法。测试人员要观察软件的功能，并报告质量水平以及他们遇到的任何严重问题。
软件测试过程：
- 单元测试：一次检查产品系统的最小单元或模块，通常是自动化的，并在每次构建后重复。
- 集成测试：检查两个或多个组合单元/模块是否以正确的方式运行。
- 根据定义的要求检查整个系统行为的功能测试。
测试人员必须在存在更多错误的假设下进行操作，并且他们必须找到它们。他们的运作方式是希望发现问题，而不仅仅是验证一切都有可能正常工作。一个好的测试人员是一个不断思考尚未尝试过的事情的人，并且被期望锻炼软件中可能较弱或交互不好的部分。对软件进行这种非常关键的审视的全部目的是尽可能快地发现错误并修复正确的错误。总会有更多的错误，但如果不知道它们是什么，就无法有意识地决定软件满足客户需求的能力。
测试组织可能会被糟糕的软件淹没，如果他们没有正确地处理自己的过程，就会被错误淹没。当测试组织变得过于被动，只捕捉错误而不是主动预防错误时，就会发生这种情况。最重要的是，可能需要单独的测试人员来发现更多的bug。然而，这种专注于增加错误数量而不是提高软件质量的做法可能会导致许多组织的消亡。
一个鼓励颠覆最终目标的系统——制造满足客户需求的软件产品——是不可取的。在一个有问题的系统中，鼓励测试人员在错误成为代码库的一部分后发现错误——当它很容易量化，但纠正成本比在早期发现更高时。奖励满足中介目标的个人的系统的问题是，人们会实现这个目标，而不是最终目标。
任何软件开发工作的最终目标都是在一定的时间段和一定的预算内交付高质量的产品。让个人去发现大量的bug似乎是在朝着制造高质量软件的目标前进，但事实并非如此。它实际上鼓励人们在软件的后期发现问题，并集中精力寻找症状，而不是寻找许多症状的核心来源。
尽管许多测试人员永远不会利用一个构建糟糕的系统，但它仍然不应该以这种方式设置，因为它不会奖励那些做了管理层真正想要的事情的人。如果不能做到这一点，最终将导致一个组织失去那些通过奖励制度的关键成员，留下一个按照管理层的一套奖励行事的组织。
没有与软件团队的其他成员（开发和项目经理）进行有效沟通的测试组织将不会意识到拟议的更改，也无法在流程的早期介入以防止出现问题，这会导致大量错误在周期的后期再次出现在测试人员身上，最终可能会耗费公司的时间和金钱。测试需要评估过程以及破坏软件。
应用程序性能管理
应用程序性能管理在很大程度上是一个行业或供应商创建的术语，用于管理或监控代码性能、应用程序依赖关系、事务时间和整体用户体验。
http://s3.nutanixworkshops.com/calm/alm/image7.png
由于应用程序性能管理是一个普遍存在的术语，用于表示任何与性能相关的东西，因此一些供应商使用该术语来表示完全不同的东西，并且可以跨越几种不同类型的供应商解决方案。
基于应用程序度量——一些工具使用各种服务器和应用程序度量，并称之为APM。他们最多可以告诉你你的应用程序收到了多少请求，以及哪些URL可能会很慢。由于他们不进行代码级评测，所以他们无法告诉你原因。
代码级性能–Stackiy Retrace、New Relic、AppDynamics和Dynatrace是基于代码分析和事务跟踪的典型APM产品类型。
基于网络的–Extrahop使用术语APM来衡量其基于网络流量的应用程序性能的能力。有一个完整的产品类别称为NPM，专注于这类解决方案。
总结
ALM不仅仅是编写代码。治理、开发和运营这三个方面都很重要。想想一个项目，它最初的治理方面是错误的，例如，可能是因为不了解业务需求或未能让正确的利益相关者参与进来。无论组织的开发和运营做得多么好，这个项目都不会提供太多的商业价值。类似地，使用一流的开发流程来解决正确问题的项目可能会忽略操作问题，例如提供足够的资源来可靠地运行应用程序。再一次，这项投资提供的业务价值不会像它应该提供的那样大。广泛了解ALM可以帮助组织避免此类问题。
最大化我们创建的应用程序的价值意味着要做好ALM的所有三个方面。实现这一目标并不容易，尤其是当当今的ALM工具没有得到应有的集成时。然而，这是没有办法的：对ALM有一个广泛、全面的看法对于改进这一关键业务流程至关重要。
- 登录 发表评论