IT专业人士知道，应用生命周期管理（ALM）所面临的挑战之一是缺乏一个统计性、可衡量和可实施的基础目标。应用程序指标已经成为一种度量开发、测试项目进展的方法，而且ALM流中有越来越多的产品可用来收集数据和可视化数据。要在SOA ALM中使用应用程序指标，就必须建立一个应用程序或组件层次结构，测量ALM各阶段数据的准确性，并且在收集数据时要认真观察管理流程的变化。这三个需求是有相互联系的，但不是连续的，所以，正确地整合这些需求很重要。

　　应用程序指标越来越被人们所熟知，但总体而言，分为三个方面：

　　•满意度指标：测量应用程序的用户质量体验(QoE)

　　•效率指标：测量应用程序在真实环境中的执行情况

　　•项目指标：ALM周期本身达到目标和计划安排的方式

　　在SOA项目中，通过SOA应用组件的方式将这些指标整合在一起是复杂的。

　　用户满意度指标应包括“客观”和“主观”QoE，“客观”QoE代表应用程序响应时间，而“主观”QoE代表达到了工作人员支持的预期期望，并有时间进行调整和修正。因为这个满意度数据是从用户那里获取的，所以该数据与是否基于SOA的应用，还如何重用组件的都没有关系。

　　在SOA应用程序生命周期管理中，使用应用指标的关键是开发一个二维的解释空间。一个维度是“组件化”的应用，尤其是在多个应用程序重用组件中。必须记录下来与应用程序组件对立的满意信息，这样就可以指出多个应用程序中出现的特殊组件问题。另一个维度是，流程触发与流程详情。效率和满意度的改变可以改变流程本身，这意味着改变应用程序或组件功能，或改变项目流程——ALM决策和流。

　　SOA ALM管理的第三阶段是，测量ALM流程本身与其目标和计划的对比。大多数ALM用户会对其目标和计划进行对比测试，但这可能会忽略一个重要问题：这些目标和计划是否与真实的项目需求一致。项目计划阶段失败会导致这类偏差，传统目标分析将会漏掉这些内容，因为其目标本身就是错误的。项目中的收集的满意度指标可以检测这个目标问题，进而调整目标和计划以满足期望。

　　成功的用户通常会收集用户满意度信息，包括目标和计划在项目级别的一致性，同时收集应用程序性能和功能方面的工作人员质量体验。这需要与调查相结合（在大多数情况下，是与项目的发布时间相一致的），同时还要监测响应时间和其他指标。在这个阶段一个有用的数据元素会经常被忽略，那就是工作人员在屏幕前的工作时间；工作时间太长可能对数据的可行度造成影响。

　　满意度分析输出的是应用程序功能问题和项目管理问题。迅速解决这两个问题是重要的，这意味着即使用户不认同这两个问题导致ALM流程失败，应用程序功能问题也不应该在项目管理中出现。解决这个问题的最佳方法是，观察功能性问题如何产生（测试中如何被忽略的），并假定改变项目的目标和流程。修改后的项目目标和流程对满意度问题进行了回顾，特别是对ALM项目管理问题。

　　记住组件层次结构的诠释。SOA应用程序的问题通常是一系列特定组件所引起的问题，重用组件时会同样影响其他应用程序。重用功能有助于确定哪些组件出现的是（常见）错误，并预测未来使用中可能出现的问题（即使在应用程序适用这些组件时没有出现满意度问题）。

　　应用程序的功能和性能问题，不能追溯到应用程序共享的特定组件上，，编制流程或应用程序资源池可能会出现问题。大多数用户不认为应用程序指标分析有助于研究服务器和存储器的利用率或网络延迟，因为，该分析中指标太多、太模糊，以至于难以解释该数据的结构框架。如果通过指标将性能问题分离出来，或没有组件级故障出现时，深入数据资源和网络数据可能就是必要的。

　　要分析资源数据，首先将资源与组件结合在一起。大多数项目团队要清楚哪个应用程序的组件是最有可能成为重要的用户资源，否则，将会引发应用程序响应时间或功能性问题。通过测量这些资源，识别在员工满意度很低的情况下的潜在问题。我们总是先从满意度问题进行研究，接着研究相关组件识别，再看看组件级指标，然后追踪资源的使用情况。其他模式则形成了一个无序的分析过程，想要观察项目变更甚至是发现问题都是很困难的。

　　通过指标发现问题并提出解决方案，在重新部署过程中，加强解决方案的应用是目前应用程序生命周期管理的目标。在闭合回路中将应用程序指标分析，通过ALM项目流程反馈回用户满意度——这是开发组织的终极目标。