【IT168 技术文章】
注本文档于产品投入生产之前编写，因此您可能会发现这里所包含的细节与发布的产品有不一致的地方。文中的信息均依据撰写本文时的产品状况，仅供您在规划时参考。如有更改，恕不另行通知。Microsoft 拥有本文档中的主题所涉及的专利、专利应用程序、商标、版权或其他的知识产权。除非 Microsoft 以任何书面许可协议明确提供，向您提供本文档并没给予您使用这些专利、商标、版权或其他知识产权的任何许可证。
简介
您是在一个开发企业级应用程序的团队中工作吗？您是将您的应用程序部署到 Microsoft .NET 环境吗？如果这样，则您知道，设计、开发、交付和维护这些应用程序的复杂性要求您在整个产品开发周期内都要跟踪需求。Visual Studio 2005 Team System 是一个应对这些需求的软件开发生命周期 (SDLC) 工具。有关 Team System 的详细信息，请参见 Visual Studio 2005 Team System：概述。
Visual Studio 2005 Team System 是适用于软件架构师、开发人员、测试人员以及其他团队成员（例如，项目经理、支持人员和文档编写人员等）的整套软件开发工具。
简要讨论软件配置管理 (SCM)
软件配置管理 (SCM) 在软件开发生命周期 (SDLC) 中起着重要的作用。SCM 是企业用来完成以下工作的做法、策略和流程的集合：
. 控制对源文件的访问
. 创建和管理工作项
. 生成产品版本
. 管理产品版本
有效的 SCM 策略就像一只好的鞋子 — 它符合您的项目和团队随时间而变化的独特需求；不能简单地与其他公司共享；而且一旦就绪，就 很容易忘记，直到您缺少它无法进行工作为止。
有效的 SCM 策略使得您的团队可以：同时在多个版本的产品上工作，将更改从一个版本移植到另一个版本，同时在同一个文件中工作而不丢失数据，并且可以不费力气地将代码缺陷追踪回其根源及创建者。
简化这些更改管理任务的 SCM 工具分为三类：
. 源代码管理
. 工作项跟踪
. 审核和报告
SCM 工具
软件工具供应商为您的团队提供了可以用来实现更改管理策略的大量工具。这些工具可分为三类：独立的 SCM 应用程序、集成更改管理工具包，以及 SDLC 工具套件。
独立的 SCM 应用程序不与其他的 SCM 应用程序进行通信。为此，开发团队成员很难将分配给他们的配置项（包括源文件、工作项、版本、项目等）与其他类型的配置项相关联。该问题最常见的表现就是开发人员不能将工作项与源文件或 changeset 相关联。
另外，集成更改管理工具包使得团队成员能够将工作项与源代码管理的文件相关联。有些工具（例如，Visual Studio Team Foundation）使得开发人员能够在集成开发环境 (IDE) 中执行基本的更改管理任务，同时还为在外部工作或需要执行更多扩展更改管理任务的团队成员提供独立的接口。
最后，SDLC 工具套件使得团队成员能够将工作项与源代码管理的文件相关联。SDLC 工具套件代表的是一种软件配置管理的综合方法，并且常常会给开发生命周期的各个方面强加 SCM 规则。它们通常包括适用于软件开发团队各个功能区的专用工具和功能，从体系结构到开发到文档，以及诸如工作项跟踪和完成重大更改管理任务的源代码管理应用程序等工具。
SCM 的传统方法
传统上，团队被迫在 SDLC 和软件配置管理的两种方法中进行选择：即席方法与命令和控制 方法。
特殊方法
针对 SCM 采用特殊方法的团队通常以增量的方式进行，他们一边通过试错进行学习，一边填补他们的 SCM 策略中的漏洞。他们常常混合使用独立工具和开发环境插件（例如，Visual SourceSafe），这为 Visual Studio 开发环境提供了集成源代码管理服务。
特殊 SCM 的优点
. 初始成本低。
. 灵活性：参与人员并没感到过程或工具有太多的约束，因为两者都可以根据他们的偏好和需求进行调整。
特殊 SCM 的缺点
. 总拥有成本 (TCO) 高：工具和过程必须不断地简化、改进或替换。新员工要花很长时间来掌握工具或流程。
. 沟通困难：SCM 流程将中断工作流。开发人员事先或许不会就可能中断版本或测试用例的更改而与测试人员进行交流，因为进行更改时，他们的 SCM 工具不允许或不鼓励他们这样做。
. 缺乏可预见性：由于缺少准确的报告功能，项目经理发现要确定某版本在某一时间点的准确状态是很难的。
. 延迟发布和服务软件包：开发人员发现事先就潜在的中断更改与测试人员进行足够的交流是很困难的，因为进行更改时，他们的 SCM 工具不允许或不鼓励他们这样做。缺乏这种跨功能的交流会导致以后出现中断更改，这种更改会迫使延迟（落后）发布，或者在某些情况下，迫使
. 工作组放慢日程表并随后创建缺陷（错误）服务软件包，这些缺陷在发布之前进行修复也许更容易些。
. 缺乏可重复性：由于缺乏报告功能以及没有将缺陷跟踪和源代码管理系统进行集成，因此很难跟踪到错误的根源。
命令和控制方法
端到端的软件配置管理 SDLC 解决方案有助于（在某些情况下）强迫项目参与人员按照 SCM 规定或团队的特定规则来完成开发任务。端到端生命周期管理工具可在开发环境内或作为独立的应用程序使用。最重要的是，通过使参与人员能更轻松地将分配给他们的配置项目与其他配置项关联起来，SDLC 解决方案改善了参与人员之间的沟通。传统上，这类解决方案成本很高，这意味着它们通常由企业开发团队和 ISV 实现。
命令和控制 SCM 方法的优点
. 良好的跨功能沟通：例如，项目参与人员可以订阅和接收电子邮件通知，通告他们重要的更改。这使得他们能够更有效地合作并完成协作项目。
. 可预见性：利用健壮的报告、审核、事件通知和集成的更改管理工具，项目经理人可以确定某一版本在某一时间点的准确状态。因此，发布日期很容易预测，并且发布后不会频繁需要服务软件包。
. 可重复性：工作项跟踪和源代码管理系统之间的集成使得跟踪错误的根源更容易。反过来，团队可以更安心地在产品的两个或更多版本上并行工作，并知道当版本之间出现差异时可以很容易地识别出来并进行协调。
命令和控制 SCM 方法的缺点
个别参与人员常常会抵制命令和控制 SCM 解决方案。
. 复杂性和成本：新员工的学习时间较长。设置和维护 SDLC 工具包的成本较高。实现集成的 SCM 系统要花费多达一年的时间，还需要团队雇用专门的 SCM 顾问来保持系统平稳运行。
. 灵活性差：与特殊解决方案不同，常常很难修改 SDLC 工具包以适应团队的特定需求。即使有可能这样做，它也将如此复杂，或者需要详细的 SCM 软件知识，以致团队必须雇用 SCM 专家来做这项工作。
