Implementing Visual Studio Team System Situation

Published: August 2006

To deliver high-quality software products on time, on schedule, and within budget, all large software development organizations must meet the same management and administrative challenges. They must plan, schedule, and manage the activities of the software development team, and they must do so efficiently, allowing the members of the development team to focus their efforts on developing software without becoming sidetracked on administrative tasks.

Until recently, project management, software and database design, software coding, testing, and packaging have usually been handled separately. Most development organizations accomplished these management and administrative tasks by using repetitious data entry into isolated documents and spreadsheets. These documents and spreadsheets were then distributed as e-mail attachments. Where automation was introduced into these tasks, the systems were narrowly focused on one activity. Integrating and coordinating these systems required ad hoc, manual programming, which then required customized maintenance and support.

Microsoft Visual Studio 2005 Team System was designed and constructed to address the beginning-to-end needs of large software development teams. Its components work together to form an integrated software development environment, from requirements gathering through design, coding, testing, packaging, and delivery of the software product.

This technical case study describes how Microsoft OEM IT implemented Visual Studio 2005 Team System. This paper can serve as a model for an organization that intends to implement Visual Studio 2005 Team System. It is intended for chief information officers, IT directors, software development executives and managers, solution architects, and technical decision makers.

Situation

OEM IT is a global IT engineering organization that delivers enterprise business solutions to the Microsoft OEM Division and several other businesses within Microsoft; specifically, OEM operations, OEM sales, Microsoft Xbox® operations, System Builder channel operations, and Microsoft MapPoint® operations. OEM IT consists of approximately 200 people, including Microsoft employees and personnel from global vendor partners. It has offices in Redmond, Washington; Reno, Nevada; Dublin, Ireland; Beijing, China; and Hyderabad, India. It serves internal Microsoft business customers at their locations around the world.

The OEM IT development team maintains about 2.2 million lines of code, which consists of about half SQL code and half Web code. It delivers 40 line-of-business applications to its customers. OEM IT plans for four, quarterly software releases a year, scheduled to coincide with updates to the Microsoft implementation of SAP (the corporate enterprise resource planning system). Each quarterly release consists of multiple projects and contains from 65,000 to 220,000 lines of new or changed code. At any one time, OEM IT is typically working on three quarterly releases: one in the conception/envisioning stage, one in the design/build phase, and one in the stabilization phase (testing). When required, though, the group has simultaneously worked on four or five releases.

Before the implementation of Microsoft Visual Studio 2005 Team System, OEM IT was in the situation of many software development organizations. It used a set of separate, internally developed tools for work item tracking, version tracking, defect tracking, test case management, and build management. It also used a stand-alone product for source control. These tools operated on separate servers, were not highly integrated, and were difficult to manage. The disparate architectures and infrastructures made integrating these systems difficult.

The project teams had to deal with separate support teams for each tool. There was often some confusion about which support team was responsible for which problem. The project teams also had to manually manage their own build systems. They had to manage five different build configurations, including all of the dependencies of those configurations.

For code source control, the OEM IT development team used Microsoft Visual SourceSafe®. It worked well for its specific purpose, but it was not integrated with the manual build system or the build reporting system. Code branching strategy was complex and difficult to manage, and many problems existed with consolidating deliverable packages.

The internally developed defect tracking tool presented several problems. Project status reporting—determining the actual testing work done versus the testing work planned to that date—was time consuming, largely manual, and subject to errors. Data was manually entered into Microsoft Office Project and Microsoft Office Excel® spreadsheets. The project status information was difficult to determine on a daily basis and was impossible to generate in real time. The test team also found it very time consuming to plan test cases and import the test cases between releases by using manual systems.

Project managers accomplished reporting by running static report queries on a relational data store. They were unable to look at historical data or analyze trends. Adapting the system to support new metrics or processes required tedious SQL coding and report formatting. Also, it was difficult and expensive to comply with statutory reporting requirements, such as Sarbanes-Oxley, which requires proof of "an adequate internal control structure."

For a process methodology, the OEM IT development projects use Personal Software Process (PSP) and Team Software Process (TSP) from the Carnegie Mellon Software Engineering Institute. Engineers who use the PSP to develop software follow defined processes and collect detailed metrics on the time expended, the defects created and removed at various stages in development, and the size of the finished product. OEM IT engineers manually collected and analyzed the PSP/TSP metrics.

Solution

Components of Visual Studio Team System

Visual Studio Team Editions and Team Explorer

• 
  Team Edition for Software Architects
  
• 
  Team Edition for Software Developers
  
• 
  Team Edition for Software Testers
  

• 
  Team Edition for Database Professionals
  

• 
  Visual Studio Team Suite
  

• 
  Visual Studio Team Explorer
  

Custom Clients

Visual Studio Team Foundation Server

Team Foundation Server provides source control management, work item tracking, integrated analysis and reporting, and an integrated collaborative project Web site. It can also provide build and test rig management. In addition, Team Foundation Server can integrate with Office Project 2003 and Office Excel 2003 to extend reporting and tracking abilities. Team Foundation Server consists of two tiers (an application tier and a data tier), plus a team portal and team reports.

• 
  Can analyze large amounts of data in a short time.
  
• 
  Enables users to create summarized fields from detailed data or explore the details that contributed to creating a summarized field.
  
• 
  Enables users to explore the data in new ways, to identify a trend or a problem area that would otherwise be overlooked.
  

Microsoft Team Foundation Service

Architecture of Visual Studio Team System

In Figure 2:

• 
  Visual Studio Team Editions represents all of the Visual Studio Team System client products: Team Editions, Team Suite, and Team Explorer.
  
• 
  Office System represents the integrations of Excel 2003 and Project 2003 to work as Visual Studio Team System clients. (Team Foundation Server includes templates for integrating Excel 2003 and Project 2003.)
  
• 
  Microsoft Windows Internet Explorer® represents the users' Web access to the team portal.
  
• 
  Team Foundation Server object model is the communication layer between the clients and the application tier.
  
• 
  Team Foundation Server application tier includes the Web services. Also on the application tier are team reports (SQL Server Reporting Services functionality) and the team portal Web site (Windows SharePoint Services).
  
• 
  Team Foundation Server data tier includes the SQL Server operational databases and the data warehouse.
  

Implementing Visual Studio Team System in OEM IT

The timing of the Visual Studio Team System product release matched well with the beginning of a major release from OEM IT to its business customers. The OEM IT management team presented the new product, its functionality, and its capabilities to OEM IT personnel, and found great enthusiasm for deploying it. The personnel immediately saw how the product would eliminate a lot of administrative work and enable them to focus more on their substantive work.

T
“When talking to our business partners, Visual Studio Team System sold itself. The longest it took for acceptance was 15 minutes."

Al Buckingham

Director

OEM IT

Setting Up the System

In the Team Foundation Server project management model, OEM IT set up work items, including work item type definitions (such as Defect, Task, and Issue), queries, and instance templates. Instance templates contain a predetermined set of tasks that must occur for every project, such as gathering requirements or writing a vision document. OEM IT was able to keep the same workflow and type definitions that they had been using in previous systems.

OEM IT used the reports that are prepackaged with Team Foundation Server, with slight modifications, and added a few custom reports. The development team also created a series of custom reports based on data read from the OLAP data warehouse into Excel PivotTable™ dynamic views for presentation and analysis. The custom reports enable the system to deliver to each person the information that he or she needs, in the form in which he or she needs it. These reports thus free each person from sorting through irrelevant information.

Then, starting with the SharePoint portal packaged with Team Foundation Server, OEM IT modified the portal according to its preferred themes. The development team also created a report dashboard for each OEM IT project. A dashboard is a graphic visual display of multiple information items that are essential for tracking a project.

OEM IT ported its defect tracking process into Team Foundation Server and enhanced it. OEM IT maintained the names and definitions that were familiar to the OEM IT team members.

The development team paid special attention to the build process. It customized the team build process so that the process could be automated and integrated with Team Foundation Server. The development team automated the packaging of files for delivery to user acceptance testing and to production.

Best Practices

Maintain the Processes and Definitions from Previous Systems

The organization should begin refining processes and definitions after its personnel have mastered the new system.

Carefully Plan the Implementation of Visual Studio Team System to Testing Teams

When planning a deployment of Visual Studio Team System, an organization should make sure that the testing teams and the end users involved in user acceptance testing are adequately trained and ready to use the system under real working pressures.

Carefully Design the Test Case Management Processes and Plan for Training

For OEM IT, implementing the test case management required special attention. The regular testing team consists of software test professionals who can learn to use a sophisticated test case management system in a relatively short period of time. However, the end users involved in user acceptance testing are professionals in their own fields and not necessarily highly technical.

When an organization is designing its test case management system in Team Foundation Server, it should keep in mind that relatively nontechnical people will use it. When planning training, the organization should pay special attention to the needs of nontechnical end users of the application.

Carefully Design the Software Release Processes

Benefits

• 
  It automates numerous administrative tasks to save time and money in software development projects.
  

• 
  It provides powerful yet flexible project reporting capabilities.
  

• 
  It simplifies support.
  

• 
  It automates the processes of build production and build reporting.
  

• 
  It provides a team portal for comprehensive, efficient team communications.
  

• 
  It has improved the job satisfaction of team members.
  

At the Microsoft corporate level, adoption of the Visual Studio Team System provides these benefits:

• 
  It helps standardize project methodologies and taxonomies.
  

• 
  It enables coordinated, consistent, standardized, cross-project reporting.
  

• 
  It lowers support costs.
  

Measurable Savings

Conclusion

The Microsoft Team Foundation service provides support for all components of Team Foundation Server—work item tracking, source control, version tracking, defect tracking, test case management, and build management. If OEM IT has a support issue, it has one support organization to deal with, not multiple support organizations that support multiple tools.

By implementing Visual Studio Team System in its development organization, the Microsoft OEM Division's IT Center of Excellence has greatly improved communications in development projects, improved the job satisfaction of its personnel, enabled project managers and senior management to better monitor and troubleshoot the projects, and produced substantial and measurable savings.

For More Information

© 2006 Microsoft Corporation. All rights reserved.