Welcome!

.NET Authors: Liz McMillan, Mark O'Neill, Peter Silva, Yakov Werde, Matthew Pollicove

Related Topics: .NET

.NET: Article

DNDJ Feature — Understanding the Methodology Workbench of Microsoft Visual Studio Team System

Underlying Concepts and Architectures

PROCESS GUIDANCE PAGES: INTUITIVE PROCESS TRAINING
One of the difficult tasks in implementing a lifecycle methodology is training the team members on the methodology requirements and educating them about the processes to enable them to perform a certain activity. Traditionally, this training is done through a Website that contains documents about the methodology and its processes. But generally, team members don't use the available documentation as it is very hard to find the required information within a large number of the documents.

Without adequate information and training, team members do not perform certain activities in the required manner, thus not conforming to the chosen methodology. To reduce this problem, VSTS provides process guidance in a user-friendly manner.

Process guidance consists of a set of HTML pages that contains different artifacts of the methodology. You can browse through the pages based on different criteria: roles in a project, stages/phases of a project, activity to be performed, or specific project artifacts like tasks or bugs. All the pages are interconnected so the required information can be found quickly.

WSS SITE: DOCUMENT REPOSITORY AND TEAM COLLABORATION PORTAL
All the projects created in VSTS have a Windows SharePoint Services (WSS) based team site, which can be customized to suit the methodology of the project. This site can be pre-populated with all the documents specific to the methodology to provide team members with faster access to the required documents. Additionally, the site provides access to project reports and serves as the collaboration portal for the team with all the built-in features of WSS.

VSTS Implementation for Lifecycle Methodologies
This section describes the general architecture of the lifecycle methodologies in VSTS. When you are starting a software development project with a certain methodology, you need to create a "team project" in VSTS. (A VSTS team project is a logical grouping that contains all the artifacts and data of the project.)

You specify a methodology for a team project by selecting the "process template" for that methodology. This is done when you create the team project. VSTS implements its lifecycle methodologies using process templates. A process template is a set of XML files that provides the specification for different artifacts and processes for a methodology. VSTS provides out-of-the-box process templates for the following two methodologies:

  • MSF for Agile Software Development
  • MSF for CMMI Process Improvement
You can customize an out-of-the-box process template or create a new process template for any methodology. Once you create a new process template, you can upload it to the VSTS server, called Team Foundation Server (TFS), so that you can select it for creating new team projects. The exact process that is followed to create a project based on a particular lifecycle is as given below:
  1. Create a new process template (set of XML files) from scratch or by customizing the out-of-the-box templates. Note: Microsoft does not provide a modeling tool or UI designer to define the XML files. However, the following third party tools are available for this purpose:
    a. VSTS Customization Toolkit - open source
    (www.gotdotnet.com/Workspaces/Workspace.aspx? id=812a68af-5e74-48c6-9623-1a4469142a84)
    b. Osellus IRIS Process Author (not released)
    (www.osellus.com/products/iris_process_author/iris_process_author.html)
  2. Upload the process template into TFS using the tool "Process Template Manager" available in the Visual Studio Team Explorer.
  3. Start the creation of a new team project using the tool "Project Creation Wizard (PCW)" available in the Visual Studio Team Explorer.
  4. The PCW prompts you to choose the process template and a few other parameters of the team project that will be created. If you have uploaded your new process template in the TFS, the process template appears in the list of available templates. Choose the one you created and proceed with the creation of the project. Figure 2 shows the process template selection step of PCW.
  5. Once the team project is created, you can view its data as well as artifacts, by adding that project to your Team Explorer window.
PROCESS TEMPLATES
A VSTS process template, as mentioned earlier, is a set of XML files that define the data and configuration requirements for different areas of a team project. Each area is represented by a plug-in. The VSTS process templates use a plug-in architecture where the plug-ins are components that run when a new team project is created using the PCW. They set up the necessary files or configure data for their area in TFS as per their XML files. Out-of-the-box templates address six areas of a software methodology, which are configured using the six plug-ins described below:

1.  Classifications: VSTS provides two types of hierarchies: one for project iterations and the other for feature areas. Project artifacts such as tasks, bugs, issues, etc. can be classified according to these hierarchies. You can do that by associating each project artifact to a particular iteration and a particular feature area.

The classifications plug-in files define a team project's initial hierarchies. Out-of-the-box methodologies use these hierarchies for iterations and feature areas, but you can use these hierarchies for other artifacts such as phases and activities, modules and components, etc.

The plug-in files also define MS project mappings, which specify how different fields of work items (explained later in this section) are mapped when they are imported to the MS project.
2.  Groups and Permissions: A software lifecycle methodology also defines the roles required in a project, for example, project managers, project members, etc. These roles require different privileges depending on the project activities performed. The groups and permission plug-in files define a team project's initial security roles and their permissions.
3.  Work Item Tracking: One of the key concepts in VSTS is "work items." VSTS stores data like tasks, issues, risks, etc., as work items. Work items are units of work that can be assigned to the team members and which store complete information about that unit of work. Different types of work items such as task, bug, and scenario are based on the definition for their type, called a Work Item Type (WIT). Each WIT defines a set of fields and valid state transitions. Users can customize these WITs or can define new WITs.

In a team project, you can define work item queries such as "All Overdue Tasks," "All Unassigned Bugs," and "My Active Tasks" to quickly find the data based on the parameters you define in those queries. When you run these queries, it fetches all the work items that fulfill the criteria defined in the query. Figure 3 shows a query result page for "All Tasks" query.

As mentioned earlier, VSTS also provides integration with Microsoft Project and Microsoft Excel, which enables you to import the work items into these tools. You can also use the work item queries to select the data you need to import to Microsoft Project or Excel.

The work item tracking plug-in files define a team project's initial work item types, queries, and work item instances (actual work items).
4.  Version Control: VSTS also provides a new enterprise source control system (SCC), which implements security permissions and check-in policies defined in the configuration for Version Control. These plug-in files define a team project's initial version control security permissions and check-in policies.
5.  Windows SharePoint Services: This plug-in defines the project portal for the team based on a Windows SharePoint Services (WSS) site template. It also defines template files and process guidance pages. You can use this to pre- populate the created project portals with methodology specific documents.
6.  Reports: This plug-in defines a team project's initial reports. You can create report files (RDLs) for all the required metrics for a methodology and include them in the process template for that methodology. When a team project is created with that process template, it would have all those reports deployed in the report server based on SQL Server 2005 reporting services.

If the above out-of-the-box plug-ins do not represent all the artifacts required for your methodology, you can create your own plug-ins using the VSTS Extensibility API.

As process templates are a set of XML files, you can implement a new artifact either by modifying one of the existing XML files or by creating a new XML file. Describing the exact XML syntax for an artifact implementation is beyond the scope of this article. For more information on the exact XML syntax, see the process templates' documentation (http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx).

PROCESS TEMPLATES FOLDER STRUCTURE
This section describes the folder structure of a process template. The out-of-the-box process templates are not included in the TFS installation package. However, you can download a process template from a running instance of a TFS. To do that, launch the Process Template Manager (PTE) from Team Explorer > Team Foundation Server Settings. Download the process template you want to review. Go to the folder where you downloaded the template. The structure for this is shown in Table 1.

There are two files in the root folder. The "ProcessTemplate.xml" file is the main file that defines the name and the description of the methodology, for which the template is defined. It also defines the plug-ins and the sequence in which the PCW runs them while creating a project. If you are creating a custom process template, you can use this file to define the name and description of your methodology. The file, version.txt defines the version number of the process template.

Apart from these two files, there are six folders, one for each of the plug-ins. These folders, in turn, contain one main XML file (e.g. the "WorkItem Tracking" folder has "WorkItems.xml"). These main XML files control what a plug-in does when run by the PCW. This main XML file might also reference external files and sub-folders, in which case, you will also find those files and sub-folders along with this main XML file. For example, the "WorkItems.xml" file of "WorkItem Tracking" plug-in refers to a separate XML for each Work Item Type. You can find all the WITs defined in this file under "TypeDefinitions" sub-folders. You need to customize this main XML file or external files referred to by the XML file to customize a particular plug-in.

Implementing a Custom Methodology
With all this information, you are ready to implement a custom lifecycle methodology. To implement a particular methodology in VSTS, the only thing you need to do is create a process template for that methodology. Other activities such as configuring projects with methodology data, enforcing processes during project execution and monitoring and reporting project performance are done automatically by various tools provided in the VSTS.

Limitations
Although VSTS is a compelling solution with many benefits, it also has a few limitations. As VSTS has a long list of features and functionalities, the scope for improvements or limitations covering all those features is outside the scope of this article. So, only those limitations that are important from the software development lifecycle methodologies perspective are described below.

NO AGGREGATION ACROSS TEAM PROJECTS
Most of the artifacts in VSTS (work items, reports, documents, etc.) are available in the context of individual team projects. There is no out-of-the-box feature to relate or compare data between the two projects. Generally, organizations need the drill-up and drill-down reports where data is aggregated from multiple projects into a business unit or practice.

VSTS does not provide such aggregated reports, but you can create them yourself by leveraging the extensibility features of the VSTS reporting subsystem.

NON VISUAL STUDIO PROJECTS
Although VSTS can be used for non Visual Studio projects, you lose many of the benefits (e.g. source control policies, build process, etc.). In any case, you would need to install the Visual Studio based client, "Team Explorer."

LIMITATIONS ON RESTORE AND BACKUP AT THE PROJECT LEVEL
You cannot individually back up or restore data associated with individual team projects in a VSTS environment. You need to back up or restore the whole database containing all the team projects.

Summary
With its long list of benefits, VSTS provides a compelling solution for organizations to use it as their application lifecycle management tool. VSTS process templates are highly customizable and allow organizations to implement their own established software lifecycle processes in VSTS. This enables them to get the benefits of VSTS without changing their existing processes.

Although VSTS has a few limitations in its current version, organizations can weigh their requirements and the size of deployment against the features and scalability provided by VSTS before committin.

More Stories By Sanjay Narang

Sanjay Narang is a Senior Technology Consultant at Global Delivery India Center (GDIC) of Hewlett-Packard. He is based in Bangalore, India and has around 8 years of IT experience. Sanjay has done Post Graduate Diploma in IT (PGDIT) and holds MCSD for .Net Framework and SCJP certifications. He has been involved in designing and developing solutions based on Microsoft technologies for a long time. Apart from software process automation and VSTS, he is working on SOA related projects around Microsoft technologies and their interoperability with other technologies. He has published papers around IPv6, VSTS, SOA, and Web Services and writes extensively about VSTS in his blog: http://sanjaynarang.wordpress.com/ He can be contacted at sanjay.narang@yahoo.com.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Kamal Ahluwalia 12/22/06 07:04:03 PM EST

Osellus offers two different solutions for customers who would like to develop custom processes or would like to enact available methodologies (with or without tailoring them) in VSTS.

Using IRIS Process Author, a methodology-agnostic standards based process authoring tool, process engineers can define-tailor-publish software development processes in a collaborative team based environment. This is made possible by the sophisticated server side support for extending and reusing process content, including best practices and patterns, being developed across an enterprise. These processes can then be exported as VSTS process templates to instantiate new team projects in VSTS.

For those teams who would not like to spend the time in coming up with their own processes but use available processes such as those from RUP, Osellus offers the VSTS ContentBridge. The VSTS ContentBridge allows project managers to transform RUP processes into VSTS Process Templates allowing flexible mapping to user defined work item types and attributes, as well as work item form layout. This transformation is lossless preserving the content defined in RUP. In many cases this would include content that has been used from one or more method plug-ins (for example the different RUP plug-ins). These VSTS Process Templates can be used to instantiate and enact new VSTS Team Projects.
After getting the right-process content at the right-time for the right-practioner, the IRIS Plugin for VSTS (to be release 1Q07) would use our second-generation enactment technology to offer advanced workflow execution, including triggering work product state machine based pre/post conditions. It would also offer a sophisticated process-rich web interface to TFS that would include linked work-items. This plugin would then make use of the advanced reporting capabilities built in VSTS to offer reports on enactment, including metrics and process compliance that would be extremely useful to our customers implementing CMMI and other quality initiatives.
I hope you find this information useful. For more information you can go to www.osellus.com or send us an email at info@osellus.com.

Kamal Ahluwalia
Osellus Inc