• Illustration: VS Team System Architecture
• Chart: Team System Components by Edition
• Illustration: Build Process Integration

With Visual Studio 2005 Team System (VSTS), Microsoft is moving beyond its traditional strength in the core development process (edit-compile-debug) to offer tools that it previously left to third parties. These tools will help with the earlier parts of the life cycle (design and architecture), as well as the later parts (testing and deployment). Its integration with the rest of Visual Studio (VS) makes VSTS worth a look for many IT organizations, but those already using competing products, such as those from Mercury or IBM/Rational, may find that competing products provide more comprehensive features.

This article provides an overview of how VSTS supports various roles in the software development process. Future articles will provide detailed coverage of features in each of the areas.

Four Roles

Many formalized methodologies attempt to apply structure to the software development process. In addition, many software development organizations employ home-grown methodologies based upon the specific skills and abilities of their staff or their historical experience. Examples of the roles commonly used in both formal and informal methodologies include the following:

Architect. An architect is concerned with overall project requirements, the high-level structure of the application, the key technologies on which it relies, and its relationship to other applications.

Developer. A developer primarily writes and debugs code. This has been the traditional focus of Microsoft’s developer tools.

Tester. A tester finds as many bugs as possible and ensures that the application meets the requirements initially set for it (including performance and scalability requirements).

Project manager. In some organizations, project management is done by a senior developer, while in others it is a distinct role. Whatever the structure, project management is concerned with measuring and communicating the status of the project as a whole and keeping it on schedule.

It is important to note that these roles do not necessarily correspond to distinct individuals. In a small project, the architect, developer, and project manager may be one and the same. Nevertheless, when acting as a project manager (looking at the bug count, for example) that individual does different tasks than when working as a developer (such as making changes to specific pieces of code).

VSTS aids individuals in all four roles. In addition, to hide options and user interface elements that are inappropriate for a given role, VSTS comes in three editions: Team Architect, Team Developer, and Team Test, with project management features integrated into Excel and Microsoft Project. (For a breakdown of the features included in each edition, see the chart "Team System Components by Edition".)

Foundation for Collaboration

At the heart of VSTS is a server application called Team Foundation, which is composed of a back-end SQL Server database and a middle tier built on ASP.NET and Windows SharePoint Services. Team Foundation provides the infrastructure for a group of architects, developers, testers, and project managers to collaborate and share information on the state of a software development project. (For an illustration of this architecture, see "VS Team System Architecture".)

Work Item Tracking

Work item tracking is a Team Foundation feature that touches every role in the software life cycle, from architects laying out the high-level structure of an application, to developers and testers tracking individual bugs, and to project managers monitoring overall status.

A work item is any task that requires action or input from multiple people on the project. Examples of work items tracked by Team Foundation include application requirements, bugs, test cases, and other issues that must be resolved. Every work item is assigned to an individual and has a particular state associated with it. A bug, for example, might be in an "active" state (meaning it is under investigation by a developer) or a "resolved" state (meaning that the problem has been found and fixed). Work items are automatically displayed within the VS integrated development environment (IDE), allowing developers and testers to quickly see and respond to items that have been assigned to them.

Each type of work item is also associated with a specific set of fields, forms, and rules. A software bug, for example, has fields that describe the steps required to reproduce the bug, a form for entering the appropriate data, and rules that describe what should happen to the bug after the developer says it has been fixed (in which case it is reassigned to the tester who found the bug for verification that it is, in fact, fixed).

Team Foundation’s work-item tracking system is customizable and extensible by end users and third-party ISVs: the standard set of work item types can be altered or entirely new types added.

Change Management

A reliable source-code control system is a critical element for any software development team. Source-code control systems allow developers to coordinate changes to the files that make up the source code for a project. They typically impose a "check-in/check-out" model, in which a developer making a change to a specific file must first "check out" the file from the central database. After making the changes, the developer "checks in" the file and the changes are incorporated into the database. Depending upon how the project manager has configured the system, files checked out to one developer may be locked and unavailable for change by other developers or may still be available for change, in which case the source-code control system must detect whether two sets of changes conflict and then notify the developer making the later change to correct the conflict.

Other important features of source-code control systems include the ability to label a particular snapshot of the code—for example, the state of the code at a beta release—so that a developer can later retrieve the state of any file at that moment in time (in order to fix a bug subsequently found in the beta release, for example).

Team Foundation is a significant improvement over SourceSafe, Microsoft’s current source-code control system. Because it is based on SQL Server, Team Foundation should be able to handle much larger projects with greater reliability and scalability than SourceSafe. In addition, unlike SourceSafe, Team Foundation is integrated with the rest of the VS suite. (For an example of this integration, see the illustration "Build Process Integration".)

Nevertheless, Microsoft will continue to ship SourceSafe as an alternative source-code control system. The primary market for SourceSafe will be individual developers who don’t need the extensive collaboration features of Team Foundation but still require a source-code control system. (Source-code control systems are important even for solo developers because they allow them to recover a previous version of any file in case they discover that a given change had unwanted side effects.)

Managing Projects

One of the biggest challenges in software projects is effective communication between team members as the size of the team increases. Project management in VSTS is provided by several Team Foundation components.

SharePoint site. Whenever a new project is created, VSTS creates a corresponding Windows SharePoint Services site that allows members of the team to collaborate on documentation, such as specifications, and view key status information, such as the current bug count.

Excel, Project integration. In addition to the SharePoint site, project managers can view and update project information in Excel and can use Project to load-balance tasks among developers and identify the critical path for the project. (VSTS provides its own server and does not require Project Server.)

Reporting. Project managers can obtain reports on a wide range of project statistics via SQL Server Reporting Services. Examples include the number of lines of code that were modified over a period of time (an important metric in determining how much churn the source code is undergoing), incoming bug rates, and bug-fix rates. All of these statistics help project managers measure and communicate the status of the project.

Methodology templates. VSTS supports an extensible set of methodology templates that define and enforce the "rules of engagement" for a project. For example, a project manager could decide to require specifications to be completed and formally approved before a developer is allowed to begin coding.

Modeling and Deployment

Microsoft is a relatively new player in the application modeling space, having previously relied on third parties, notably Rational, to provide such tools. But since the Dec. 2002 acquisition of Rational by Microsoft rival IBM, the company feels that it must now provide application modeling and architecture tools itself.

The goal of application modeling is to reduce the complexity of the development process by allowing architects to build formal descriptions (akin to blueprints) of how an application (or component of an application) will function and to provide tools that automatically generate source code that implements the model. Although VSTS lacks the comprehensiveness of the Rational tools, it does provide tools to help architects with the following key tasks:

• Building a logical model of how the components of an application interact
• Building a logical model of the datacenter in which the application is intended to run
• Comparing the two models to determine whether the application can be successfully deployed.

From Models to Code and Back Again

To help architects and developers build reliable code more quickly, VSTS provides a Class Designer that allows them to graphically design a software component object. VSTS then automatically generates the code to implement that object.

The Class Designer supports two-way editing: changes to the model are automatically reflected in the source code and changes to the code update the model. This is an important capability: without it, models would quickly become out-of-date with respect to the code.

Many third parties provide tools with similar capabilities, often based on an industry standard known as Universal Modeling Language (UML). (In addition, Microsoft’s own Visio tools include UML templates.) The VSTS tools are not based on UML, although they produce diagrams that resemble those produced by UML tools. Microsoft believes that UML lacks the ability to adequately represent some programming constructs that are supported by the .NET Common Language Runtime, a point that advocates of UML (including IBM/Rational) find contentious. Microsoft hopes that by producing diagrams that are visually similar to UML but that are better suited to .NET, VSTS will appeal to developers and architects already familiar with UML but building applications for Microsoft’s platform.

Matching the Application to the Datacenter

In addition to providing application modeling, VSTS includes tools to help developers and IT administrators ensure that an application, once built, can be successfully deployed in a datacenter. For example, a developer might build an application that requires a specific set of ASP.NET security configurations or authentication options, but if those configurations don’t match the servers on which it is deployed, the application will not deploy successfully.

With VSTS, Microsoft is taking its first concrete steps toward solving this problem by allowing IT architects to produce a formal model of their datacenter. The Logical Datacenter Designer in VSTS allows IT administrators to build a formal description of their datacenter that can be shared with developers. The developers can then use a Deployment Designer to map specific components of their application to servers in the datacenter and VSTS will identify any configuration mismatches that will prevent the application from running. For example, VSTS would identify whether a Web application required Windows authentication but the ASP.NET server on which it was to be deployed was configured for Forms authentication only.

Limits of a Version 1 Product

Although VSTS demonstrates a newfound commitment to modeling on the part of Microsoft, the product has some limitations that IT organizations must consider before switching from competing products.

First, Microsoft has limited its modeling efforts to Web services and although Web services are an important up-and-coming technology, they are far from the only type of component used by IT organizations.

Second, there is no automatic way to generate the infrastructure model from an existing datacenter or to maintain the model once it is created. Having servers and OSs automatically generate and maintain such information is a key part of Microsoft’s Dynamic Systems Initiative (DSI), but the reality won’t begin to match the vision until, at the earliest, the arrival of the next major upgrade to the Windows Server platform (code-named Longhorn Server and currently due in 2007).

In addition, the deployment modeling capabilities of VSTS do not address capacity, performance, or scalability planning. For example, although it will flag as an error an attempt to deploy a Web service that requires ASP.NET on a server without ASP.NET, VSTS cannot determine whether the specified server has enough available bandwidth or CPU capacity to host the component in question.

Development Tools Move Beyond Coding

With VSTS, Microsoft is moving beyond its traditional strength in compilers and debuggers to include tools that address other problems faced by developers. VSTS builds on the features included in the Professional Edition of VS and adds the following capabilities:

Source-code analysis. VSTS incorporates tools that analyze source code to help find defects. First, it includes a security analysis tool known as PREfix, which was used internally at Microsoft as part of its efforts to find and fix security bugs. It also includes PREfast, a smaller and faster scanner that lacks the extensive security checking of PREfix but that can be used to quickly catch the most common errors, as part of a nightly build process, for example.

In addition, VSTS incorporates FxCop, a source analysis tool that scans .NET applications to ensure compliance with coding guidelines developed by Microsoft to maximize the cross-language compatibility of .NET components.

Profiling. VSTS offers tools to help developers measure the performance of their applications, including the profiling system (known as IceCAP) used internally at Microsoft by the Windows and SQL Server teams and a lighter-weight profiling system used by some other Microsoft teams.

Code coverage. VSTS has tools to help determine how much of an application’s source code has been tested. Code-coverage tools are important because some sections of an application’s source code (such as error-handling) execute infrequently or only in certain rare circumstances, yet must be tested as rigorously as any other source code. With these tools, VSTS helps developers determine how much of their source code is covered by a given set of tests and identifies areas that are untested.

Integrating Testing into the Life Cycle

Software testing is an important and often neglected part of the software development process. VSTS’s testing capabilities represent a serious increase in Microsoft's support for software testing.

VSTS is not Microsoft’s first product to support testing: Visual Test, a stand-alone product for automating graphical user interface (GUI) application testing, was introduced in 1992 but sold to Rational in 1996. Since that time, Microsoft has relied exclusively on third parties to provide testing tools for its developers. With VSTS and VS 2005, Microsoft is reentering the market.

Test suites are managed in VS with the same tools used to manage source code. Tests are checked in to the source-code control system and can be assigned version numbers. In addition, tests can be logically grouped hierarchically into lists that appear inside the VS IDE.

Unit Testing

Unit testing refers to function-by-function testing of an application’s source code. VSTS can automatically generate a set of unit tests for a module of source code that make sure the module produces the correct outputs for a given set of inputs. The tests can then be incorporated into a nightly build process or as part of a set of tests that must be run prior to checking in any code changes.

Notably absent, however, is support for the kind of automated GUI testing provided by competitors such as Mercury. Developers using VSTS will either have to buy additional products or rely on manual GUI testing.

Load Testing

Load testing refers to the ability to ensure that an application works correctly when subjected to high levels of usage. VSTS supports load testing for Web applications and includes tools to simulate many thousands of simultaneous requests and to determine whether the application is functioning correctly under load.

VSTS does not, however, support load testing for client applications. Microsoft does provide tools for simulating low-memory conditions and other stress cases as part of the Windows SDK, but these tools are not integrated with VS and may be difficult for many corporate developers to use.

Pricing, Licensing Yet to Be Announced

Although details on pricing and licensing have yet to be announced, Microsoft has hinted that the additional capabilities of VSTS will come at an increased price. VS 2003 Enterprise Architect Edition (the highest level of the current VS product) carries an estimated price of US$2,499 and VSTS includes many more features and capabilities. Competitors have typically charged much higher prices—IBM’s Rational Software Architect is US$5,500. In addition, the introduction of a server-based component (built on SQL Server) opens the door for Client Access Licenses (CALs)—a complexity that developers have thus far avoided but which may be in their future.

Resources

For information on the core development features of Visual Studio Professional Edition, see "Visual Studio Renews Pitch for Developers" on page 21 of the Dec. 2004 Update.

For information on how Microsoft tracks its own bugs, see "A Bug’s Life" on page 19 of the Aug. 2003 Update.

The home page for Visual Studio Team System is http://lab.msdn.microsoft.com/vs2005/teamsystem/.