MSF for CMMI Process Improvement

MSF for CMMI Process Improvement (MSF CMMI) is a lightweight, agile approach to CMMI. It's designed for organizations looking to achieve and maintain a CMMI Level 3 status, as defined by the Capability Maturity Model (CMM) developed by the SEI (an organization we will discuss shortly).

The Capability Maturity Model Integration (CMMI) is not an SDLC model per se, but rather a process improvement framework. It was developed by the Software Engineering Institute (SEI), a federally funded research and development center sponsored by the U.S. Department of Defense. The foundation of the CMMI is the Capability Maturity Model (CMM), originally developed by SEI in the mid 1980s. The CMM was developed primarily as a tool for evaluating the software development capabilities of defense contractors, with the goal of avoiding the spectacular and costly failures that were all too common in those days. Using the CMM, the Department of Defense could objectively assess the "maturity" of a software development organization.

The CMM rates an organization's maturity on a five-tier scale. The various tiers are defined as follows:

Level 1-Initial.

There are few stable software processes in evidence, and performance can be predicted only on the capability of individuals rather than organizational capability.

Level 2-Repeatable.

Planning and tracking of software projects is stable and earlier successes can be repeated.

Level 3-Defined.

The organization uses a defined software process, and software quality is tracked.

Level 4-Managed.

The software development process is measured and operates within measurable limits.

Level 5-Optimizing.

The entire organization is focused on continuous process improvement.

Each maturity level is composed of a set of key practice areas (KPA). Each KPA is a group of related activities that achieve a set of goals deemed important for establishing process capability at that maturity level. For instance, the Level 2 KPAs are Requirements Management, Project Planning, Project Tracking, Configuration Management, and Quality Assurance. Get those right, and you're a Level 2 shop.

As it turns out, the CMM proved to be an excellent process improvement tool for large software engineering organizations. Once an organization knew its current maturity level, the CMM told it exactly which KPAs to work on to get to the next maturity level. In this way, the CMM provided prescriptive guidance for process improvement.

As experience with the CMM grew, the SEI found that it needed to specialize the CMM for various disciplines such as systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development. So it developed a CMM for each of these disciplines. That solved one problem but created another. Many organizations wanted to focus their improvement efforts across the disciplines. However, the differences among these discipline-specific models made this a difficult and costly proposition.

This is where the CMMI comes in. Its purpose is to combine several source models into a single improvement framework for use by organizations pursuing enterprise-wide process improvement. In the process of merging the models, the CMMI Product Team built a framework that accommodates multiple disciplines and is flexible enough to support two different representations: staged and continuous. Staged CMMI offers a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels. Continuous CMMI, on the other hand, allows an organization to select the order of improvement that best meets its business objectives and mitigates its areas of risk.

Implementing MSF 4.0 with Visual Studio 2005 Team System

Visual Studio 2005 Team System uses a mechanism called the process template that defines both the configuration and initial content of new team projects. In effect, the process template defines the methodology for a new project by rigging the project to facilitate the methodology.

VSTS supports multiple methodologies by containing multiple process templates. When creating a new team project, the user selects a methodology from the list displayed by the New Team Project Wizard and VSTS uses the corresponding process template to set up the new project. This turns out to be a simple and elegant way to incorporate methodology at the project level.

VSTS includes two process templates for MSF 4.0, one for each of the MSF implementations: MSF for Agile Software Development and MSF for CMMI Process Improvement. In this section, we'll walk through the structure of a VSTS process template to see exactly how it implements a methodology.

The process template consists of the following components: project structure, groups and permissions, work items, project portal, source control, and reports. It's important to remember that the process template configures the initial settings for a new project. Once the project is created, most of these settings can be modified by an authorized user.

Project structure.

VSTS manages project structure using the Classification Structure System (CSS). The process template defines the classification structure of a project. The classification structure for MSF Agile includes project hierarchy and iterations. Project classification also specifies the name of each iterative development cycle in the project. Examples of iteration name include Setup, Alpha, Beta 1, Beta 2, and Release.

Groups and permissions.

Visual Studio 2005 Team System implements project security using the Group Security Service. The project template specifies the security groups to add to a new project, as well as the permissions associated with each group.

Work items.

Visual Studio 2005 Team System implements work item tracking using its own internal system. The process template specifies the work item types, which are used to categorize work items. For MSF Agile, the work item types are Scenario, Quality of Service, Task, Bug, and Risk. The process template also specifies the initial set of work items to automatically add when the project is created. In this way, you can preload the work item database with typical work items that generally apply to all new projects.

Project portal.

Visual Studio 2005 Team System uses Windows SharePoint Services (WSS) to create a Web portal for each new project. The process template specifies the initial content to be automatically added to the project portal. The project portal is commonly used to store project documentation, including the process guidance associated with the process template. In addition, the project portal is used to display key team reports.

Source control.

Team Foundation Source Control (SCC) stores some of the work products, such as source code and text. The process template specifies the check-in policies and other miscellaneous settings for new projects.

Reports.

Visual Studio 2005 Team System uses SQL Server 2005 Reporting Services to produce reports from the work item database and metrics warehouse. The process template includes a complete definition of each report to add to a new project.

Extending Visual Studio 2005 Team System

A powerful component of VSTS allows developers, architects, testers, and project managers to customize the out-of-the-box features included in Visual Studio 2005 Team System. In addition, Microsoft's partners are preparing tools that plug and complement the basic Visual Studio 2005 Team System offering. For this reason, Visual Studio 2005 Team System has been built from the ground up to ensure that its fundamental architecture supports extension and customization.