Enter your email address:

feedburner count

Team System Brings Project Management to Visual Studio

New features of Visual Studio 2005 Team System (VSTS) will help project managers in two ways: a set of built-in reports will allow project managers to quickly see project status and a set of extensible methodologies will provide specific guidance on how to organize and track a software development project. The reporting tools are useful for any development project that uses VSTS’s source-code control and work-item tracking systems. The methodologies, however, will require organizations to either adopt a specific way of managing their projects or modify the provided methodologies to suit their specific needs.

For background information on VSTS, including its architecture, see "Visual Studio Team System Targets Multiple Roles" on page 20 of the Feb. 2005 Update.

Tools for Project Managers

Many software project managers spend a great deal of time collecting status information from individual developers and testers and trying to collate that information into a useful report. Development teams using the VSTS source-code control system and work-item tracking databases will find that much of that data collection is performed automatically, allowing project managers to perform higher-level tasks such as analyzing trends or transferring work from one developer to another to equalize work loads.

VSTS can create reports from multiple data sources, including its automated code testing, source-code control, and work-item tracking systems, giving project managers a more complete view of their project. Some of the statistics that VSTS can generate include the following:

Bug find and fix rates show the number of bugs found each day compared with the number fixed. The net number of bugs fixed each day is an important tool in helping project managers estimate when a project will reach its quality goals.

Code churn measures the number of lines of code in the project that are being added, deleted, or changed. Since any change to the source code of a project introduces the possibility of a bug, reducing code churn is important to stabilizing a project in preparation for release.

Bugs per developer allows project managers to see which developers are overloaded with bugs to fix and which have time available, helping managers balance the work load.

Number of test cases passing and failing is an important measure of the overall health of a project.

Code coverage shows what percentage of the application’s source code is being exercised by automated test suites and helps managers analyze the effectiveness of their tests. If large portions of the source code are not covered by any automated test, then a manager knows that the number of test cases passing will not provide a complete view of the quality of the application.

Reports Available in Many Formats

Project managers can view and update project information in several ways.

Excel. Excel provides few project management features, but many software project managers rely on it, including those on Microsoft’s own product teams. What Excel excels at is creating, maintaining, and sorting lists of information and generating charts. VSTS allows project managers to view lists of work items within Excel spreadsheets. An Excel add-in can automatically update spreadsheets with the latest data and can update VSTS with any changes made to the spreadsheet.

Project. Although Project is Microsoft’s product for general-purpose project management, it is rarely used for software project management. Nonetheless, Project has some capabilities that make it useful—most notably its support for visually displaying a project’s timeline as either a Gantt or a Pert chart. VSTS can automatically generate a Project file for a project schedule and includes a plug-in so that any schedule changes made within Project are reflected in VSTS.

Web site. Because the middle tier of VSTS is built on top of Windows SharePoint Services (WSS), every software project automatically has an associated SharePoint site that allows developers, testers, and project managers to view and update project data.

SQL Reporting. The data tier of VSTS uses SQL Server, so project managers will be able to use SQL Reporting Services to automatically generate and distribute reports, such as daily or weekly bug status.

Methodologies Provide Process Guidance

In addition to providing reporting tools that are broadly useful to teams, VSTS provides mechanisms for enforcing specific development methodologies. Webster defines methodology as "a body of methods, rules, and postulates employed by a discipline." A software development methodology, such as Extreme Programming, is a set of methods and rules that define how a software project is designed and created. Extreme Programming, for example, stresses the need for frequent, small releases of the project and the creation of software tests before the writing of code.

The final version of VSTS will support two Microsoft-developed methodologies—one for a highly formalized software development process, and one for a less formalized, more iterative, process. Organizations can use or customize one of the methodologies supported by VSTS, use a methodology developed by themselves or by third parties, or use no methodology at all.

In addition, Microsoft hopes to create a market for third parties to sell other popular methodologies, such as Extreme Programming.

Agile Framework Defines Roles, Workstreams

Beta 2 of Visual Studio 2005 (which will be the first beta of VSTS) will include one Microsoft methodology, Microsoft Solutions Framework (MSF) for Agile Software Development (previously known as MSF Agile). The Agile methodology defines a software development process that incorporates several rounds, or iterations, of product planning, coding, testing, and feedback. Although Agile can be used by any development team, it was designed with a typical IT enterprise development team in mind.

The Agile methodology defines several roles, with each member of the team taking on one or more roles:

Architect—responsible for designing the technical foundations of the application, including its usability, reliability, maintainability, performance, and security.

Business analyst—responsible for defining the business needs the application fulfills and working with customers to understand the scenarios and quality of service requirements.

Project manager—responsible for delivering the application on time and within budget.

Developer—responsible for implementing the application within the agreed schedule.

Tester—responsible for assessing and communicating the state of the application, including any problems.

Release manager—responsible for the rollout of the application, coordinating the project with other operations, and certifying any releases for shipment or deployment.

In addition to defining roles, the Agile methodology defines a set of activities performed by each role. For example, the "Fix a Bug" activity is associated with the developer role. These activities are then grouped into workstreams that span roles. The "Fix a Bug" activity, for example, is part of a larger workstream that includes the following steps:

  • Open a bug (tester)
  • Triage bugs (project manager)
  • Fix a bug (developer)
  • Verify a fix (tester)
  • Close a bug (tester)

VSTS supports this methodology by automatically updating a work item, assigning it from one person to the next as it moves through a workstream. In the case of a bug, once a bug is entered by a tester, a work item is automatically created for the project manager to triage the bug. Similarly, once a bug is fixed, the work item is assigned to the tester for verification.

CMMI Coming Later

In addition to the Agile framework, future versions of VSTS will also provide the Microsoft Solutions Framework for CMMI Process Improvement—a more formal methodology that is compliant with the Capability Maturity Model Integration (CMMI), a set of process management guidelines developed by Carnegie Mellon University’s Software Engineering Institute. Although seldom used by corporate IT departments and broad-market commercial software developers, some government organizations require that their vendors adhere to CMMI guidelines.

CMMI defines five maturity levels, ranging from Level 1 (ad hoc) to Level 5 (optimizing). Microsoft hopes to have a methodology for Visual Studio (VS) 2005 that meets the requirement for CMMI Level 3, which requires that "the standard process for developing and maintaining software across the organization is documented, including both software engineering and management processes, and these processes are integrated into a coherent whole."

Microsoft has yet to provide details on the CMMI framework, but has said that support will not be included in Beta 2 of VS 2005, expected in Apr. 2005.

You Can Go Your Own Way

Adopting a methodology, whether defined by Microsoft or by a third party, is a significant undertaking. Every development team has some "rules of the road"—they may not be formalized or even written down, but they exist nonetheless, and managers will need to understand their team’s current processes before adopting new, more complex, ones.

In addition, the methodologies used by VSTS are defined by a complex XML schema and modifying them (or creating new methodologies) not only requires specific knowledge of VSTS but of XML as well. Most organizations will want to rely on outside consultants or trainers to do this work.


The VSTS source-code control system is outlined in "VS 2005 Checks in New Source Control" on page 24 of the Feb. 2005 Update.

VS 2005 features for individual developers are described in "Visual Studio Renews Pitch for Developers" on page 21 of the Dec. 2004 Update.

The Visual Studio Team System home page is lab.msdn.microsoft.com/teamsystem/default.aspx.

For more information on CMMI, see www.sei.cmu.edu/cmmi.