用，最重要的命令和功能显示出来，把一些不常用的就隐藏或集中起来，版面就显得非常简洁。而在修改

方面，你可以一次性地将目录所有需要修改的地方找出来更改，节省你许多时间，再也无须繁复地修改，

在指令部分也可以让你设定独特的颜色显示，而执行速度也比

HotDog 快很多。

Visual Studio 2005

今天，企业要获得成功，就必须正视构建和维护日益复杂的信息技术

 (IT) 解决方案的需求。此外，

他们还要借助于新技术来拓展业务功能并开发全新的业务机会。自

 IT 部门接受了技术支持任务的那一

刻起，他们便成为绝大部分业务策略中的关键角色。

 

　　企业当然希望能从他们在

 IT 项目的投资中获得最大利润，这就意味着 IT 部门需要在越来越大的

压力下多快好省地完成工作。对更高成本效益的追求使得

 IT 项目的预见性需求日渐增加。然而，这样做

通常造成繁琐的过程和对成本消耗的监控，这只不过是将费用转嫁到不同的问题。付出的代价是开发机

会的时间投入以及膨胀的

 IT 预算。

　　复杂的应用程序需要多支训练有素的开发团队来实现。对于开发团队作出的任何主要承诺来说，信

息交流都是成功的一个基本元素。新的

 Visual Studio Team System 扩展了 Microsoft 的优秀功能，

即，通过提供与业务紧密集成的、可扩展的、能够增加成功几率的生命周期工具，从而为用户提供高效

的工具。能否成功主要取决于，为了降低交付解决方案的复杂性，团队间是否进行了充分的交流。

　　构建

 IT 解决方案的挑战

　　尽管许多

 IT 解决方案项目的工作产品是软件，但生成软件并不是项目的目标。相反，软件是实现

目标的手段

 — 驱动不同的业务价值。要应对风险并增加成功的可预见性，大多数 IT 部门转而采用各

种各样的工具和过程来支持

 SDLC。大部分旨在提高软件开发效率的尝试均不尽如人意。这些尝试要么

在实现时过于繁琐，并未达到预期的目标，要么根本无法切中团队开发中令人感到苦恼的要害问题。

 

　　信息交流：重要的大型应用程序由团队构建，这其中有大量可能从未编写过代码的参与者，包括：

业务发起人、项目管理者、架构师以及测试人员。更甚之，团队本身已演变为地理上分布更广且更专业化

角色的差异导致许多问题无从解决，或者无意识地对计划产生了分歧。为了使团队有效地运转，就必须

理顺信息交流流程，而且必须让它与成员的日常工作行为相吻合。

 

　　工具捆绑：近些年来，在

 SDLC 工具领域中已经大量使用了捆绑手法。但是，仅仅是捆绑工具集

合并不能实现工具集成。这只是建立工具包。由于角色限制，非集成工具（无法支持工具间的自动数据

流）之间就产生了矛盾。集成性的匮乏就必须通过手工乾预进行弥补，而由此可能产生其他一些问题。

在数据层进行集成，能够使数据流自动化跨工具和常规报告实现。

 

　　不合适的过程：使过程采纳变得复杂的原因是存在一个矛盾，即开发人员在许多生命周期过程中

既是最关键的一环，又是最薄弱的一环。不适合团队成员（特别是整个开发团体）工作风格的过程，将

遭遇到明显地阻力。面临的挑战就是平衡可预见、可重复过程的生产效率和创新。当未形成这种平衡时，

每一个人都挣扎于成本消耗与实现任务目标的矛盾之中。多数过程都以文档为中心。在这种情况下，他

们需要额外付出超出维护日常活动的正常流之外的努力。无论团队使用特定的、灵活的或者常规的过程，

每一支团队都可以受益于自动且集成的软件开发过程。

 

另人失望的投资回报

 (ROI)：站在 CIO 的角度看，痛苦的抉择在于，在开发活动和工具方面不

断投入的、天文数字的

 IT 预算换来的却是另人失望的投资回报。大多数采纳过程和 SDLC 工具的尝试

之所以困难重重，原因在于其陡峭的学习曲线、缺乏工具集成、高额的前期投入费用、持续的维护、特殊

技能需求以及对专门的管理员的需求。结果，包含

 SDLC 工具的总拥有成本是难以负担的。因此，CIO 

面临一个难题

 — 证明既然费用支出不会再涉及任意可估计到的因素，那么他们的费用支出就是合理的。