应用生命周期是指应用程序进程从创建到消亡的整个过程。起源于20世纪60年代。

比如软件开发从需求分析开始，历经项目规划、项目实施、配置管理、测试管理等阶段，直至最终被交付或发布的全过程。

LCA研究起源于20世纪60年代的能源危机，在70年代初期，该研究主要集中在包装废物问题上，如美国中西部研究所（Midwest Research Institute，简称MRI）对可口可乐公司的饮料包装瓶进行的，从原材料采掘到废弃物最终处置的全程跟踪与定量研究。20世纪70年代中期，全生命周期评价的研究焦点是能源问题和固体废弃物方面。1990年8月，国际环境毒理学和化学学会（SETAC）在有关生命周期评价的国际研讨会上，首次提出了“生命周期评价”的概念，并成立了LCA顾问组，负责LCA方法论和应用方面的研究。与此同时，欧洲一些国家先后制定了一系列促进LCA的政策和法规，如“生态标志计划”、“生态管理与审计法规”、“包装及包装废物管理准则”等，LCA开始在全球教育、交流、公共政策、科学研究和方法学研究等各方面获得大量应用。

国际标准化组织ISO1993年6月成立了负责环境管理的技术委员会TC207，负责制订生命周期评价标准。继1997年发布了第一个生命周期评价国际标准ISO14040《环境管理生命周期评价原则与框架》后，先后发布了ISO14041《环境管理生命周期评价目的与规范的确定和清单分析》、ISO14042《环境管理生命周期影响评价》、ISO14043《生命周期评价中的生命周期解释》、ISO/TR14047《ISO14042应用示例》和ISO/TR14049《ISO14041应用示例》等文件。

应用生命周期管理（ALM: Application Lifecycle Management）指的是一个应用程序从需求收集、编程、测试一直到发布全程的管理。(请参考Forrester Research 在2006年发表的The Changing Face Of Application Life-Cycle Management)。ALM使IT团队能够管理应用生命周期，并且从项目建议到运营全过程中贯穿应用交付。能够帮助IT团队快速交付应用以响应不断变化的业务需求，从而推动创新。

可追溯性

在ALM领域里要关注的系统特性至少有三个：可追踪性、自动化以及项目的可视性。可追踪性有如系统里的血管，它有如一个网贯穿了整体。没有了它，这系统就是死的。在与关注软件项目管理的人的沟通中，我们得知可追踪性被大多数有远见的人视为研发管理平台必备的条件。

ALM里的可追踪性（Traceability）指的是工作产物（artifacts）,诸如需求、代码、测试用例以及相关的知识文档等，以多对多的关系相链接。当然，制作工作产物的人员也是非常重要的，所以对干系人的链接也是必要的。也就是说，具备高可追踪性的研发平台让我们知道什么人（Who）因为什么原因（Why）在什么时候（When）做了什么事（What）。

推动整个应用生命周期的管理必是业内的一个趋势。欧美公司使用测试和代码管理工具较中国公司早，但改进步调缓慢。

知识管理

◆ TechExcel KnowledgeWise (TechExcel)

需求管理

◆ DOORS Telelogic (IBM)

◆ TechExcel DevSpec (TechExcel)

缺陷跟踪

◆ Rational ClearQuest (IBM)

◆ TechExcel DevTrack (TechExcel)

◆TeamTrack (Serena)

◆StarTeam (Borland)

项目规划和项目管理

◆ MS Project (Microsoft)

◆ Visual Studio Team System (Microsoft)

◆ TechExcel DevPlan (TechExcel)

测试管理

◆TechExcel DevTest (TechExcel)

配置管理

◆ Rational ClearCase (IBM)

◆ TechExcel VersionLink (TechExcel)

◆ Firefly (Hansky)

整合的系统（Integrated System）–现今针对软件应用生命周期中各个阶段的工作管理，虽然可选的管理工具颇多，但它们多半是由不同的公司开发出来，且是各自独立的。这至少造成了以下两个问题。第一，各阶段的数据不能被共享。举例来说，同样的需求会在需求管理工具中记录，又同时需要出现在缺陷跟踪工具里。若要把这些数据要从一个工具拷贝到另一个工具，不但在时间上有延迟，同时在费用上也会增加，而且发生错误的可能性也变大。第二，项目执行的流程无法被固化。由于工具是各自独立的，工具间的流程自然是没法被固化的。如果我们能够找到一套整合的系统，这些问题势必迎刃而解。不但解决了软件应用生命周期中各个阶段工作的管理，而且也解决了阶段性数 据的共享。

项目的透明度（Visibility）要高 –由于项目包含了庞大的数据，参与者往往都在雾里。对于关键的数据，看似存在，却无从提取。就如项目经理，他无法对项目的成本、所需人力以及时间等等进行合理的估算。由于缺乏真实的数据支撑，公司决策层对项目的投资报酬率不清楚，对整体策略步履蹒跚。其他如缺陷修复现状、缺陷率、任务完成时间估算和任务现状等都是项目里提高透明度的一些指标。这些年被敏捷团队所津津乐道的任务时间估算方式是以Burndown Chart来实现的。Burndown Chart通常以时间为横轴,以未完成的工作为纵轴。它显示随时间推移,项目中还剩下多少工作未完成。从而帮助项目管理层掌控项目的执行进展。

可追溯性（Traceability）要高 –理想上，项目成员在生命周期管理系统中，可将相关的文档（包括需求及参考资料等）、测试用例及代码等建立链接，并有办法从其中的任意一个节点，追溯到其他的相关条目。如果生命周期管理系统的各个子系统不是整合的，那这种追溯事实上是不可能完善的。如果把重要的设计文档丢失了，就是因为只是单纯的将文档放在服务器上，而没有保存到管理系统中管理，造成无法追溯。在实际的项目执行中，最常发生的例子可能是，研发人员要修复某个缺陷，他常常需要找出原本的设计文档及其他相关缺陷的修复状况。知道了来龙去脉后，他便可以很准确地完成他 的工作。

自动化（Automation）程度要高 –在项目的执行过程中，很多机械性的工作是可以经由软件系统自动触发的。最常见的例子是，当经理在工作流程中把某研发任务交给某个研发工程师时，一个电子邮件（或短信）就应该自动地邮寄到该工程师信箱（或手机）里。另一个例子是，某个项目要由10个委员在2周内评估完。在2周截止日前3天，系统也可以发个电子邮件通知