The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Visual Studio Team System
By taking a role-based approach, Visual Studio Team System claims to give you all you need to manage the software development lifecycle. Matt Nicholson finds out what it has to offer the project manager, the architect, the developer and the software tester.
Author: Matt Nicholson
Last updated: Nov 2005
Visual Studio Team System (VSTS) is designed to provide a complete development environment, not just for the individual developer but for everyone involved in the project. It is therefore, as our diagram makes apparent, a complicated creature made up of many parts, resident both on the server and on the client.
For the purposes of VSTS, Microsoft has defined four roles within the development team, and three have specific versions of VSTS dedicated to them. Built on Visual Studio 2005 Professional Edition, these comprise Visual Studio Team Edition for Software Architects, Software Developers and Software Testers.
The fourth role is that of project manager or team leader, and here Microsoft has taken a different approach. Project managers tend not to spend much time within a development tool such as Visual Studio, but are more usually found working with documents and spreadsheets. Microsoft has therefore developed Office Integration add-ins that turn Microsoft Excel and Project into Foundation Server clients. Furthermore, these add-ins support offline working so you can work on the project while on a train or plane, and upload your updates once you regain connectivity.
To provide more ubiquitous access to the project, VSTS makes use of Windows SharePoint Services to create a customisable Project Site that can be viewed through a Web browser. Then there is the Team Explorer, a standalone client that can be used not only by project managers but also by team members who are not using one of the Visual Studio Team Editions. They won’t get the same functionality, but this does mean that developers using older versions of Visual Studio, or even non-Microsoft development environments, can interact with Foundation Server.
Third-party clients are also expected, and indeed SourceGear has already announced a client for Foundation Server that will run under Linux, Solaris and MacOS.
Methodology support
At the heart of VSTS is the Microsoft Solutions Framework (MSF), which was first introduced in 1994 as a loose collection of best practices. MSF has now reached version 4.0 which supports two process models, namely MSF for Agile Software Development and MSF for CMMI Process Improvement (formerly known as MSF Formal).
Traditional process models are often felt to be too cumbersome and time consuming for the modern software industry. Agile processes are more lightweight, promoting the use of small teams delivering working builds on a cycle measured in days rather than months.
Other characteristics include constant testing, ensuring that business people and developers work together on a daily basis throughout the project, encouraging face-to-face discussion and regular meetings to consider ways to make the team more effective. The whole process is more fluid – there is no formal specification stage in an Agile process, for example. However, critics claim that Agile methods are too dependent on the skills of those in the team, rather than the strength of the process itself.
The MSF for Agile process model is based on the work of the Agile Alliance, which brings together a number of Agile methodologies. MSF for CMMI extends MSF Agile to provide a more formal methodology that facilitates the process of obtaining CMMI certification, at least to Level 3, and has been described as “an Agile approach to CMMI” (see ‘Understanding CMMI’).
Process methodologies are implemented in VSTS through the Process Template, which is created when a project is initiated. The process template contains all the document templates, workflow definitions, reports, security groups, check-in policies, milestones and even help files needed to support the methodology. VSTS comes with process templates for the two MSF methodologies described above. Project managers can choose between these, edit them to create their own, or install templates created by third parties. Conchango, for example, has already created a process template that supports the Scrum methodology.
Work items and policies
The collaboration capabilities of VSTS centre around ‘work items’. A work item is a unit of work that can be assigned to a team member and tracked through a specific workflow. For example, a Bug work item would typically have a workflow of ‘Active’, ‘Pending’, ‘Resolved’ and ‘Closed’. By default MSF Agile defines Bug, Risk, Requirement, Scenario, Feature and Task work items, but you can create your own work item types, and define your own workflows, as the project progresses.
Foundation Server maintains a database of work items which can be queried from within any of the Visual Studio Team Editions. Developers, for example, can bring up a list of all the Bug work items that have been assigned to them without leaving their development environment, and further filter them by status or date created.
Work items can be associated with other artefacts such as files, documents or other work items. When a developer has fixed a bug, for example, they can associate the new code with the appropriate Bug work item and report the bug fixed, without having to use another tool to update the status of the bug. Particularly useful here is the support for ‘changesets’, which allows you to group a set of files together for the purpose of source code control. A changeset can be checked in and out of Foundation Server, and associated with a work item, as a single entity.
Furthermore, work items can be extended by third parties. Identify, for example, has a product called AppSight that acts as a ‘black box’ for software applications. It has integrated it with VSTS so that testers can attach recordings made by the AppSight Black Box to work items. When the work item is opened from within the Developers edition of VSTS, the developer is presented with all the tools necessary to play back the recording and so gain a complete picture of what happened.
VSTS integrates with Windows Active Directory so that project managers can assign permissions and allocate users to defined roles. The two process templates that come with VSTS establish groups for the defined roles, with appropriate permissions applied. However the project manager can change these and set up new roles as required.
You can create policies that come into force when code is checked in to Foundation Server, which is an important tool for establishing a process methodology within VSTS. Project managers can set policies stating that code must compile without errors before check-in; must pass certain tests (a static analysis test or a particular unit test, for example); or must be associated with a work item. If the developer is unable to comply – perhaps because they’re late for a meeting – then he or she does have the option to override the policy, but the override is logged.
Integration with SQL Server 2005 Reporting Services means that project managers can track the state of the project through a wide range of reports covering work items, check-ins and so forth. Reports can be viewed through the Project Site or the Team Explorer, from where they can be further manipulated using Microsoft Excel.
Predefined report templates come as part of the process template. These include the Code Quality report, showing the number of bugs, test failures and ‘code churn’ over time; the Schedule Progress report, looking at the status of tasks; the Plan Stability report which covers requirement changes and schedule ‘churn’ over time; and the Test Effectiveness report that looks at the details of test runs. All of these can of course be customised and new report templates added as necessary.
Architecture and deployment
It may seem odd to be covering software architecture and deployment in the same section, however VSTS is about designing solutions that can be deployed. As such, it centres around Microsoft’s Dynamic Systems Initiative (DSI) which, like IBM’s self configuration and management vision (sometimes called ‘autonomic computing’), aims to make it easier to define, deploy and manage large-scale distributed computing systems.
Underlying DSI is the Systems Definition Model (SDM) which captures information about a system’s requirements and characteristics in a standard XML-based format. Over time, SDM will be supported by Windows Server itself and management tools such as Microsoft Operations Manager (MOM).
VSTS supports SDM through the four Distributed System Designers (DSDs) that come with Visual Studio Team Edition for Software Architects, namely the Application Designer, the System Designer, the Logical Datacenter Designer and the Deployment Designer. These are all examples of graphic-based Domain Specific Languages (DSLs), in other words visual languages that are targeted at specific problem domains. UML (Unified Modelling Language), for example, could be described as a graphic-based DSL that targets object-oriented software design.
With VSTS the design process starts with the Application Designer. This is intended primarily for the design of distributed SOA (Service Oriented Architecture) solutions. A solution is assumed to be made up of several linked applications which can include Windows Forms applications, ASP.NET applications, Office applications, Web services and external databases.
Once the design is complete, the tool will generate skeleton code in the language selected for each application. Subsequent changes to the code implementing Windows Forms and ASP.NET applications will be reflected directly back to the model itself, so ensuring that the model and the code remain synchronised.
The next step is to group the various applications into deployable systems, which is done in the System Designer. You might, for example, group a Web service with its associated database and management tool to create a single system. Although you will only have one application design per project, you can create as many systems as you want, and use one system as a component in another.
Meanwhile, your IT personnel are using the Logical Datacenter Designer to create a model that represents the network and the servers onto which the systems are to be deployed. This model is built out of predefined components such as IISWebServer, DatabaseServer and WindowsClient, linked by network connections. Servers can be grouped into zones that can represent organisational boundaries or groups of servers that share the same security constraints. In the long term, the DSI will enable this model to be generated automatically by the servers themselves, but in the meantime it must be done by hand.
One obvious omission is a stand-alone version of the Logical Datacenter Designer. Like project managers, IT personnel don’t tend to ‘live’ inside Visual Studio. Until the process becomes fully automated, a stand-alone tool seems more appropriate for such personnel than a full-blown VSTS edition.
Finally, it is in the Deployment Designer that you find out whether the various systems created in the System Designer can actually be deployed to the representation created in the Logical Datacenter Designer. This is done by dragging the various applications that make up each system on to the target server. If there is a conflict, for example an ASP.NET Web application being deployed to an IIS Web server that doesn’t have the security settings specified, then this will be highlighted.
Once a successful deployment design has been created, the Deployment Designer will generate a Deployment Report describing how the application is to be deployed. When the DSI has been fully realised, VSTS will be able to integrate with MOM and SMS to automate the deployment process. Until then it remains a manual process, but hopefully less fraught thanks to the Deployment Report.
The Class Designer
Although not one of the DSDs – and not exclusive to VSTS as it is actually part of Visual Studio 2005 Professional Edition – the Class Designer is an important graphic DSL that is available to all members of the project team. Here you can define .NET classes and interfaces, and link classes to indicate inheritance and association relationships. As you do so, the code required to implement the classes is generated and edited automatically.
It is important to realise that this is not round-trip engineering. The Class Designer is another way of editing the source code – what you see in the Designer is simply a visual rendition of the underlying code.
Few can have failed to notice that we have yet to mention a UML design tool. However all three VSTS editions do come with Visio for Enterprise Architects. This is the same tool that came with Visual Studio .NET 2003 Enterprise Architect (VSEA) and it supports the creation of diagrams to the UML 1.3 standard.
That said, UML has been noticeably sidelined in VSTS. There is no round-trip engineering, for example – you can generate code from your UML diagram, but subsequent code changes are not reflected back to the diagram. Microsoft’s position on UML is that it is best used for brainstorming, whiteboarding and ‘napkin’ sketches rather than the direct generation of code.
Nevertheless we can expect to see UML support from third parties. Indeed Borland has already announced a version of its Together product for Visual Studio 2005 which will support UML 2.0.
Writing the code
There is not space here to cover the many enhancements introduced by Visual Studio 2005 – we suggest you check out our extensive articles on DNJ Online for that. What the Developer edition adds to the mix are facilities for checking code in and out of Foundation Server, and a range of testing tools that bring quality control into the development stage of the process.
Central to these is the ability to generate unit tests. A unit test is a separate program that is specifically designed to test a particular method within your code. In VSTS, generating a unit test is an option on the menu that pops up when you right-click a method within your code window. Select this and a test project is created, along with skeleton code for the unit test which you can then edit. Once created, unit tests can be checked into Foundation Server, linked to work items and run at any time to ensure the code is working as expected.
An important companion to unit testing is the code coverage tool. With code coverage enabled, code that was executed by the test are highlighted in green, while lines that weren’t are highlighted in red.
The Developer edition includes two tools for static code analysis, both based on utilities originally developed by Microsoft for internal use. The first is based on FxCop and is intended for use on managed code. The second is based on PREfast which was developed for analysing native C++ code. Both are driven by rules that specify coding policies covering design, security, naming, reliability and so forth. VSTS comes with a whole set of rules ready defined, and others can be added as required.
The final tool is the code profiler which analyses how your code executes and where the majority of time is spent during execution. Once you’ve highlighted bottlenecks in your code you can start looking at ways to make it more efficient.
The VSTS code profiler supports two profiling methods, namely ‘sampling’ and ‘instrumentation’. The sampling technique involves interrupting the execution at regular intervals and checking what function is being executed and how it was called. Instrumentation involves inserting new code that reports back the state of the application as it executes. As such it is much more intrusive, but instrumentation profiling does illicit more information than sampling.
Testing time
While the tools supplied with the Developers edition of VSTS are concerned with testing the code on which the developer is working, the Testers edition is about testing the application as a whole. Indeed VSTS introduces a new project type called the ‘test project’ which acts as a container for the tests associated with a particular solution. One of the benefits of this approach is that test code is stored in the Foundation Server and can be checked in and out just like any other code.
The Testers edition includes the unit testing and code coverage tools that come with the Developers edition. In addition the tester gets tools for Web testing and load testing, both intended for testing Web applications.
A Web test is an automated run through a Web site. Its starting point is a record of the HTTP requests generated as the user navigates the application, and the simplest way of generating this is through the Web Test Recorder which runs inside Internet Explorer. Once a Web test is recorded it can be further edited so that, for example, different search strings are entered into a search dialog each time the test is run. Testers can also add validation rules, perhaps stating that a response should be received within a certain time, or contain a certain string.
A Web test becomes more realistic when used to drive a load test, simulating the presence of multiple users accessing the site at the same time. You can specify the number of users you want to simulate, how many simultaneous connects to manage and how often to add new users. You can even specify ‘user think time’ to more realistically mimic human behaviour.
The Testers edition also supports ‘generic’ testing and manual testing. Generic testing allows you to use third party tools simply by specifying an executable and any parameters to pass. With manual testing you can integrate Microsoft Word documents into your test project that detail the test instructions.
As with all the VSTS editions, there is plenty of scope for third parties to integrate their products into the Testers edition. Compuware, for example, will be integrating its DevPartner and TestPartner tools into VSTS.
Once a problem is found using any of the tools integrated with the Testers edition, the tester can create the appropriate work item with the test results attached. The developer can then start work on the bug, with all the information they need to hand and without having to leave the development environment.
Click here for Ian Murphy's in-depth reviews of Visual Studio Team Edition for Software Architects, for Software Developers, for Software Testers and Foundation Server.
What about Visual SourceSafe?
Microsoft has said it will continue to support Visual SourceSafe for those looking for a lightweight file-based source code management system, and indeed is releasing Visual SourceSafe 2005 alongside Visual Studio 2005. Amongst other things this supports remote Web access over HTTP.
Alternatively, Microsoft is providing a converter tool that allows you to move the information in a Visual SourceSafe database into Foundation Server.
Understanding CMMI
A Capability Maturity Model provides a model for measuring the maturity of the practices and processes in place within an organisation. CMMI is an attempt to integrate CMMs from various disciplines, including the software industry, into a single improvement programme. It was launched by the Software Engineering Institute (SEI) at Carnegie Mellon University in 2001 and was primarily funded by the US Department of Defense.
CMMI defines five levels of maturity, starting at Level 1 which is essentially characterised by the lack of any controlled processes at all. Most organisations aim for Level 3 where processes are fully managed and defined across the whole organisation, and not just within individual projects. Level 3 accreditation requires inspection by an SEI approved assessor.
Microsoft has been working with the SEI to ensure that VSTS will deliver the evidence needed for an organisation to pass inspection at CMMI Level 3. See www.sei.cmu.edu/cmmi/ for more details.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
Extending Visual Studio Team System What's new in Visual Studio 2005
