应用生命周期管理（ALM： Application Lifecycle Management）指的是从需求收集、编程、测试一直到发布全程的管理。 （请参考Forrester Research 在2006年发表的The Changing Face Of Application Life-Cycle Management。）现在谈全程管理的研发团队或许算是先进。但IT业进步神速，在可预见的若干年后，没有全程管理的团队可能将被视为异类。ALM 里的可追踪性（Traceability）指的是工作产物（artifacts），诸如需求、代码、测试用例以及相关的知识文档等，以多对多的关系相链接。当然，制作工作产物的人员也是非常重要的，所以对干系人的链接也是必要的。也就是说，具备高可追踪性的研发平台让我们知道什么人（Who）因为什么原因（Why）在什么时候（When）做了什么事（What）。

图表1功能点追踪矩阵

　　图表1显示了一个功能点和它相关的研发及测试任务的状态。为了实现功能？#25163；机短信通知？#65292；三个研发任务和三个测试任务被创建了。当我们深入挖掘，每个研发任务（或测试任务）又可追踪到与其相关的工作产物。为何这种关联那么重要呢？大家可看下列的真实故事。

　　一个早年的故事

　　在1996年当我在美国从事IT工作时，曾以签项目契约的方式加入一个研发团队。当时Jeff是我们的项目经理，所做的项目是用来给汽车厂维修汽车时，做报修估价用的。当时所谓的工具就是程序编译器、自动测试工具以及IDE（Integrated Development Environment），连缺陷管理工具都没有，更别提什么ALM管理平台。我第一次加入该团队工作了两年多，在产品发布后我离开了一段时间，后来为添加产品新功能又再次加入该团队。该团队人员因我早年参与了项目的设计，问了我一些跟产品历史有关的问题。我说：？#24403；年我们写的某设计文档可以回答这些问题，Tom应该有这文档。？#24403；我们去跟Tom要这文档时，他说，该文档被交接给John了。但John已离职，他的工作和文档全交给了Dianna。Dianna有些印象，但她和我们怎么找都找不到那文档了。一个重要的需求文档就这样消失了！

　　那需求文档里记录了许多当时设计系统的思想及商业逻辑。没有了它，我们添加新功能和修改代码都失去了依据。为了在限定的时间内完成任务，程序员往往胡乱找个可以快速实现的方法交差了事，这导致后期的代码写作风格和所依据的商业逻辑与早先的不一致。在这情况下，很多的代码写下后表面上是满足了需求，但实际上是在系统里埋下了地雷，爆发出来只是早晚的事！

　　不久后，我们将一个同时发生在5个模块的缺陷分配给一个资历较浅的程序员Eric做修改。由于Eric对整体设计思想不够清楚，该缺陷只在三处改了，而没改其它两处。改了后就测那三处，然后立即发布，客户发现未改的缺陷后愤怒不已，甚至要求我们赔偿他们因误操作所造成的实际和名誉损失。当我们检讨这问题时，Bill说某个测试用例里明显地指明了，这类的问题会同时发生在五个模块，并且模块名都列出来了。但文档太多，Eric不知道如何能搜索到那相关的测试用例，所以造成缺陷修改不全。我们的问题不是没有足够的工作产物，而是资料太多了，一搜几十个，让人无所是从。