Adrian Jakeman | 15 April 2008
Visual Studio Team System comprises a series of tools that enable project stakeholders to take an active part throughout the software development lifecycle. These are application lifecycle management (ALM) tools that support the development of quality software, allow project transparency and provide mechanisms for team collaboration.
But, you can't buy a copy of Visual Studio Team System - it's not a single product available off the shelf. Instead, it's made up of a series of client applications and server products that work together to provide the tools necessary for different members of the project team. Of course, if you're not working in a Microsoft shop, you might be wondering how these tools can work for you. Don't worry, clients exist for organisations using Eclipse, Mac OS X and Linux.
Visual Studio Team System components
The key component within VS Team System that supports ALM tools is Team Foundation Server (TFS). As its name suggests, this is a single server product that is tightly integrated into the whole software development process. Amongst the many responsibilities of TFS are project planning, management & reporting, software change & configuration management and project transparency.
Most importantly, TFS ensures that organisations define and use a software development process - the tool itself enforces the definition and use of a process before the beginning of each new project. And, of course, this process can be a complex or as simple as required by different organisations and/or projects. It can also be modified as the project develops - after all, who gets everything right first time?!
ALM is supported by the use of process in Visual Studio Team System - process itself is defined using an easily editable XML process template. This template describes how the various components of Team Foundation Server are going to work together in each individual project.
For example, the template defines the work item tracking capabilities of TFS - the types of work items that can be used to describe activities in the project, their states and how they can transition from state to state. It also defines how the project portal, exposed via Windows SharePoint Services, is going to be configured. It provides details of security roles and settings for the project, defines document templates and describes how reporting features of TFS, exposed via SQL Server Reporting Services and/or Excel are going to be configured for the project.
If we think back to our original definition of ALM - "the coordination of development lifecycle activities, including requirements, modelling, development, build, and testing, through enforcement of processes, management of relationships and reporting on progress" - we can agree that the starting point within ALM is precisely the process enactment that is provided by TFS. In addition, TFS provides us with the project traceability and reporting features that are also so important within the ideas of ALM.
In my next few blogs, I'm going to expand on the ALM features provided to different members of the project team within Visual Studio Team System. I'll be looking at this from the perspective of business analysts, system architects, project managers, developers, testers, database professionals.