【IT168 技术文档】

    简介：了解应用程序生命周期的软肋

    几乎所有的公司都无可避免于这样的境遇：在业务用户（驱动对软件开发的竞争性需求）、IT 组织（负责创建软件）以及操作人员（管理应用程序的开发和维护）之间存在的沟通、协作和文化差异之中苦苦挣扎。本白皮书将解决如今公司在软件开发和实现方面面临的主要挑战。随后还将讨论如何变更进行应用程序生命周期管理（Application Life-Cycle Management，ALM）的方法，并展示 Microsoft 的 Visual Studio Team System 核心模块，这些模块通过更有效的软件开发和实现将业务推向成功。

    通常，IT 组织内部是彼此独立的，这就导致开发人员之间的交接很糟糕，实现核心项目生命周期各阶段和各种角色（架构师、项目经理、开发人员、测试人员等）的方法不一致。这会对设计、质量、代码管理和部署产生负面影响。这些挑战致使开销增加，对企业的底线造成了巨大冲击，原因就在于设计和质量差强人意、代码和项目管理效率低下，而且软件滞后也削弱了竞争的业务响应性。

    高端应用程序生命周期管理 (ALM) 套件产品解决了上述许多问题。然而，由于这些产品由不同产品组合而成，因此往往难以使用、实现的代价过高，且无法紧密集成。

    这意味着，在很大程度上，IT 部门和业务仍然不能使用有关开发团队进度、管理和质量的集中信息。随着成本不断攀升、竞争压力日益增大、业务需求更加复杂，21 世纪的组织需要直观、易用、集成的 ALM 产品。大多数公司极度受限于内部资源并用外包人员补充内部 IT 部门，这更促使迫切需要衡量 IT 成功与否的更好的优先级和度量。此外，监管合规立法也推动组织在生命周期管理方面向更加准确的方向发展。新涌现的开发范例（例如，面向服务体系结构 (SOA)）也需要新的、更灵活、更全面的进行生命周期管理的方法。

    地理位置分散的团队更需要生命周期各个阶段的可见性和协作。甚至协同工作的团队也深受不连贯沟通的困扰。如果开发团队工作时跨越了很大的地域和文化差异，而其成员来源（包括内部团队和外包或海外开发团队）混杂，则该问题更加严重。专业技能的过度集中也往往会加剧企业文化本质的差异，导致信息交流不畅。对 21 世纪的组织至关重要的一点是：能够对业务和需求的变化作出快速反应。然而，多数组织都不能适时地改变管理。在瞬息万变的市场中（如金融服务或电信）以及存在激烈兼并和收购活动的行业中（如银行业和保险业），公司必须迅速、适当地作出反应，否则就会减少收入、丧失竞争优势。

    了解各个阶段：创建切合于生命周期的管理以推动开发

    在考虑针对集成的 ALM 的新兴解决方案之前，有必要定义和了解主要的生命周期阶段 - 过程和项目管理、需求、建模、测试，以及软件变更和配置管理。

    每个生命周期阶段都有自己的优势，这些优势在彼此有效地集成和协作时会更加强大。然而，这些阶段和工具必须与 ALM 过程相关联，因为 ALM 过程也反映了 IT 组织和企业的文化。便于准确性、便于采用 ALM 工具的非常好的实践，以及与现有企业和 IT 文化共融的非常好的实践，它们都是成功的关键。这些实践（结合了任务安排和资源分配的强大的项目管理）为有效的软件开发奠定了坚实的基础，其原因在于它们为适当用途提供了一个框架，为行为更改提供了一个模板。如果组织不能以非常好的方式（在合适的时间使用合适的方式）使用工具，那么即使用世界上最好的技术，也不会成功。

    有效的过程还有助于促进各团队间更好的沟通。例如，相关的、通用的业务需求推动项目成功。行业调查表明，70% 到 80% 的项目失败是由拙劣的需求收集、管理和分析直接造成的。这里再次强调，过程扮演一个角色。由于业务用户与技术人员之间只进行一次沟通，从而导致在项目开始前需求就已过时。通过使用熟悉的业务工具（如 Microsoft Word 和 Excel）以及简化业务用户与 IT 人员之间的反馈往返次数，从而使用户能够与开发人员进行沟通，这是改善需求的质量和通用性的关键因素。随后，这些需求能够帮助促进建模。针对更严格的需求，辅助的高端工具提供了跟踪能力和强大的管理。

    合适的建模允许组织创建反映业务需求以及体系结构和系统要求的应用程序。迭代过程方法允许在业务用户、设计人员和实现代码的人员之间进行实时交互。通过这种方式，代码内容更有可能反映出当前的业务需求。设计人员本身扮演着不同的角色。通常，架构师和操作人员之间没有直接联系，这会对软件部署产生负面影响，并导致增加软件部署的成本。通过架构师、设计人员和操作人员之间的沟通来深入了解部署和基础结构方面的挑战，这样可以提前解决上述问题。能够使用跨组、跨生命周期可见性的广泛的设计工具也很重要。

    对开发人员而言，通过在所选的 IDE 和生命周期管理之间进行密切的协作来简化开发过程（包括测试、软件变更和配置管理以及版本控制）也很重要。

    在应用程序生命周期的早期发现错误可降低成本。行业调查表明，如果在应用程序生命周期后期找到问题，所增加的成本是在单元测试早期发现并改正问题所增加成本的 10 倍到 100 倍。除了损失事务性和为用户所提供系统的收入之外，日渐低迷的声誉所付出的代价也是无法计算的。首先要通过迭代单元测试支持进行及早的、频繁的测试。这意味着，为系统和系统集成测试后期阶段产生的代码，在用户接受并进行部署后将具有更高的质量。此外，了解已经过测试的代码，以及解决性能和负载测试、手动测试和测试过程管理的问题，也很重要。这使测试人员能够与开发保持协同，更好地组织和管理其测试方法。改善质量会降低业务的成本，提高 IT 部门的响应性，并且减轻操作和维护的事务。

    软件变更和配置管理以及版本控制是开发人员有效管理代码创建的关键因素。由于在代码更改的管理方面非常混乱，并且与测试的协调不足，因此一旦修改了软件，就有可能以各种方式导致失败并出现混乱的修订版本。这些更改本身可能会引入质量问题，而且需要对更改进行管理才能实现团队协作（而不会造成代码混乱）和一致的软件版本，这些都符合关键的业务需求。在这种情况下，更改请求的优先级也很重要。有关 IT 部门对更改请求的响应性的报告提供了另一种定量度量方式，从而满足了对 IT 资源（无论是内部资源，还是在国内进行离岸和/或外包开发的资源）有效性的分析和行政理解。

    总的说来，很明显必须对上述每个阶段进行良好的定义。然而，这些阶段与有效的自动化工具（紧密集成工具的，以及使用适当过程和项目管理部署的工具）配合将为业务带来显著的好处。这些好处包括：对竞争压力的适应、灵活的响应，以及削减了在部署阶段投入的用于代码创建、质量和部署的成本。由于人为因素对 ALM 演变的妨碍往往是最具挑战性的，因此促进采用易使用的、直观的产品以及信服的过程和项目管理就成为对成功至关重要的因素。

    以前的方法

    最初，适合需求、建模、SCM 或测试的应用程序生命周期产品没有与其他生命周期工具和阶段相集成，也没有与开发人员用来创建代码的集成开发环境相集成。过去五年间 (2000-2005)，这一市场不断在进行合并。较大的供应商收购了较小的供应商，将开发环境与传统的应用程序生命周期管理工具集成到集成套件中已成为不可抵挡的趋势。这些集成套件围绕着 IT 项目组合管理最近的变化，预示着我们所期待的产品将主导市场的发展。然而，因供应商获得了不同价格点的产品而导致存在套件内和跨套件集成上的挑战，较高的价格点和产品复杂性限制了 ALM 套件的广泛使用。

    Microsoft 的 Visual Studio Team System 为有效的应用程序生命周期管理奠定基础
    Microsoft 的 Visual Studio Team System (VSTS) 将跨越核心应用程序生命周期管理区域的直观功能合并在一起，以帮助解决业务驱动力和开发挑战中的问题。从最初的建模和设计一直到开发、变更管理、测试和部署，VSTS 使基本的功能和连接从其构建的那一刻起就能作为一个集成系统来工作。

    Visual Studio Team System 中的 Team Foundation Server 为软件开发和协作提供了一个切合实际的平台，这是因为它将过程管理、工作项跟踪、源代码管理、生成自动化、测试和团队控制与集中报表功能合并在一起。对开发工作的了解由开发过程中的角色（架构师、开发人员和测试人员）决定。所有工作项均位于一个数据库中，以允许更紧密的协作。

    来自 VSTS 的定量数据结合了来自质量控制、代码生成和周期时间的信息，以提供定性评估 IT 成功的度量。通过这种方式，组织能确定哪些资源能为开发项目提供更有效的支持。

    项目报表集成到 VSTS 中并可通过 Windows SharePoint Services (WSS) 查看，通过 Microsoft Excel 和 Microsoft Project 可以了解生命周期和开发过程的详细情况。使用这些功能，团队能够对资源选择、范围和策略决策作出适当的选择。

    这将有助于利用 Team Foundation Server 规划 VSTS 的整体框架，然后掌握与特定角色关联的核心功能，从而提供对 Microsoft 的应用程序生命周期管理方法的了解。