Visual Studio 2005 Team System: Microsoft Solutions Framework

 

Visual Studio Team System
Microsoft Corporation

May 2004

Applies to:

   Microsoft Visual Studio® 2005 Team System

Summary: Microsoft Solutions Framework (MSF) is an integrated system of process guidance that embraces both agile and formal methodologies and provides a framework to implement a customized solution for a wide variety of projects. (7 printed pages)

Note   This document was developed prior to the product's release to manufacturing, and as such, you may find inconsistencies with the details included here and those found in the shipping product. The information is based on the product at the time this document was created and should be used for planning purposes only. Information is subject to change at any time without prior notice. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Contents

Introduction
A Brief History of MSF
Traditional Approaches
Lessons Learned from Traditional Approaches
Our Solution: Using the Lessons Learned
Extensibility Possibilities
Conclusion

Introduction

Microsoft Solutions Framework (MSF) is a highly customizable, scalable, fully integrated set of software development processes, principles, and proven practices designed to deliver the type of guidance desired by the user when and where it is needed. MSF harvests proven guidance from inside and outside of Microsoft and provides a seamless experience with Visual Studio 2005 Team System for process automation and guidance within the software development life cycle (SDLC). This article introduces MSF 4.0, provides a brief history, discusses the issues that surround the traditional approach to process guidance as part of the SDLC, and contrasts that with the approach being taken in MSF, and presents some extensibility possibilities.

Aa302179.vsts-msf-fig01(en-us,MSDN.10).gif

Figure 1. How MSF and the Visual Studio 2005 Team System interact

MSF provides a customized and scalable set of software development guidelines for application development improvement. MSF incorporates both agile and formal approaches, and then allows the user to select the most suitable path. MSF's flexible framework can be adapted to meet the needs of any project, regardless of size or complexity. The MSF philosophy holds that there is no single structure or process that optimally applies to the requirements and environments for all projects. Yet it also recognizes the need for guidance exists. MSF provides this guidance without imposing prescriptive detail and allows the user to customize the content provided. MSF components can be applied individually or collectively to improve success rates for the many types of projects.

The MSF vision is to provide process guidance developed for software professionals by software professionals that is productive, integrated, and extensible.

  • Productive: One of the key visions of MSF is to make people more productive. Productivity is supported through MSF's streamlined and customized presentation of process guidance. Using checklists and guidelines instead of detailed content, the user can quickly determine the requirements to complete a task or activity.
  • Integrated: Solutions and guidance are presented within the tool, via seamless integration of entire toolsets and the integration of help and MSF content. All of these elements are easily updated within MSDN and across all aspects of the tool set. The content itself is organized for easy maintenance.
  • Extensible: Process guidance and help are fully customizable within MSF. Users chose an agile or formal approach, incorporate scenario-based development, and determine their own path through the content.

MSF guidance focuses on managing the "people and process." Because the needs and practices of software development teams are constantly evolving, the materials gathered into MSF are continually changing and expanding to keep pace. Additionally, MSF interacts with Microsoft Operations Framework (MOF) to provide a smooth transition to the operational environment, which is a requirement for long-term project success.

A Brief History of MSF

Elements of MSF are based on well-known industry best practices and incorporate more than 25 years of experience by Microsoft in the high-tech industry. These elements are designed to work together to help Microsoft consultants, partners, and customers address many of the significant challenges encountered throughout the technology life cycle.

MSF was first introduced in 1994 as a loose collection of best practices from Microsoft's product development efforts and from Microsoft Consulting Services engagements. MSF has been evolving since then, based on successful, real-world best practices from internal Microsoft sources such as Microsoft development teams, the Patterns & Practices group, Trustworthy Computing, Microsoft Operations Framework, and the Engineering Excellence group. External sources have played a significant role as Microsoft developed MSF. The MSF Partner Council's involvement has been critical in forming the direction of MSF. The MSF Partner Council is made up of global services integrators such as Accenture, Avanade, Capgemini, EDS, Fjuitsu, Infosys and Unisys. Other external sources have also influenced the future of MSF, including Borland, Merrill Lynch, The Agile Alliance, and The Software Engineering Institute.

MSF uses this pool of real-world best practices, which have been proved both internally and externally, and simplifies, consolidates, and verifies them for easier understanding and adoption by partners and customers. Now a robust and mature framework, MSF is managed and developed by a dedicated product team within Microsoft, with guidance and review from an international advisory council of subject matter experts. MSF also continues to draw upon current Microsoft experience. Other teams within various Microsoft lines of business regularly create, find, and share best practices and tools internally. What the teams learn from these internal project efforts is consolidated and distributed outside of Microsoft through MSF.

Traditional Approaches

Two Philosophies and Two Approaches to Process

The approach to process in the software community has devolved into two basic philosophies in the past few years. Both approaches have relative merits as well as weaknesses. In addition, two separate approaches to processes have evolved in the greater business world, one independent of the software industry and one that attempts to create software-centric processes.

The Agile Process Model

The agile process model was created by a group of software professionals known as the Agile Alliance who rejected the notion that process is more important than people. The agile process model has achieved success but the main criticism of this approach is its achievements may have more to do with the talent of the individuals involved rather than the efficacy of the process model.

The Formal Process Model

The formal process model has been developed in the business world mostly outside the software development culture. The formal approach provides a proven framework but when applied to the SDLC it can become cumbersome and worse yet, may not ultimately result in quality software that is responsive to the market and delivered in a timely manner.

Two Approaches: Software Independent vs. Software Linked

In addition to the two process models above, two ways of developing processes for the SDLC have also evolved. One way develops processes independent of the software industry's demand and creates "one process fits all industries" guidance. This kind of process is disconnected from software development and relies heavily on published texts and methodology. The reaction of many software professionals has been to ask, "How does this apply to me and my project?"

Attempts to create processes linked to software development have also come to the fore. While existing packaged processes address the issue of relevancy to the SDLC, software professionals have found it often offers too much information to be readily understandable and adaptable to "real-world" software development.

For software professionals, the most important element of process guidance is the immediate availability of the right guidance provided at the right time combined with tool support integration. The focus of MSF is the enactment of process guidance that is seamlessly part of daily activities in the SDLC.

Lessons Learned from Traditional Approaches

A frequent complaint from project managers is that process training is expensive and methodology is a stumbling block. The current approach to incorporating process guidance into the SDLC using existing tools has resulted in guidance that is often disconnected from both the help and the tools themselves. In addition, the route maps through the content are not obvious to the user.

Overwhelming Content

The content provided in the existing solution can be inappropriate, out of date, and overwhelming. Currently such content takes a "landfill" approach. Voluminous amounts of content are provided, leaving it up to the user to sort through what is relevant to the particular project. Though the landfill approach tries to satisfy everyone, in the end it pleases no one because it is sometimes agile, sometimes heavy. Additionally, the existing packaged process guidance is not easy to update. This often results in a mismatch between tool help, templates, and guidance.

Customization Not Useful or Intuitive

Attempts at SDLC process customization have been unwieldy at best. Customization is required to get started using the guidance and the examples provided for customizing can be weak and of little practical use. This often resulted in guidance that was unrecognizable once customized.

In the existing packaged process guidance, the overall experience doesn't feel coherent from end to end for the user. Getting the customized process into a useful system often requires large amounts of effort by the user. The result is a static process that often does not change as the project technology and environment change. This static process quickly becomes outdated and therefore, not useful. Additionally, the customized process was little more than a set of Web pages. Integration with the chosen toolset took the form of a specific page devoted to using a software development tool or deployment environment in the context of the process. This rarely took into account all of the interactions between the process and the toolset. People using the tool had to switch to a browser and look for the appropriate topic. The result was a feeling of being disconnected.

In contrast, the harmonious marriage of process and tools defines MSF's productive and integrated approach. In MSF every action is captured in process context. Metrics such as actual vs. planned work, test coverage vs. bugs fixed, and code churn vs. code stability are tracked automatically, without any extra work. Data is collected as part of the daily activity. Tasks required by process that have been laborious in the past are now invisible, painless, and simple with MSF.

Our Solution: Using the Lessons Learned

MSF has incorporated key findings from previous attempts to formalize the software development process and incorporate process guidance. The result is a conglomeration of Microsoft's best practices, external contributor's expertise and those key findings is a framework that delivers appropriate, useful guidance on demand. Some of the key lessons learned that have been incorporated into the MSF vision include content designed for maintenance, a clear metamodel, a clear plug-in model, and many navigation paths through the content.

Content Organized for Maintenance

MSF is designed with the ability to efficiently update content in mind. Content is easily updatable within MSDN and across all elements of the tool set. The ability to simultaneously update templates, guidance, and tool help ensures that all aspects of the process guidance match. This allows the user to be more productive when using the integrated package of guidance extensibly.

Clear Metamodel

MSF is governed by an overarching metamodel. This framework determines how the process guidance is presented to the user and ensures it is presented consistently. The metamodel allows the user to easily identify the type of guidance they need along with the level of complexity the project requires. Once the user has chosen a type of guidance and level of complexity, MSF quickly serves up the appropriate guidance in a timely way.

Clear Plug-in Model

MSF provides a clear way to customize and "plug-in" content. Once the user has selected the type and complexity of the process guidance, the content MSF provides may either be used as-is, or customized to suit the particular needs of the user and the project. In MSF, example content is strong and relevant, giving the user a solid foundation from which to build high quality process guidance.

Many Navigation Paths

MSF provides not just one navigational path through the process guidance but a variety of paths that change depending on the decisions of the user. Depending on the needs of the user, MSF can provide highly detailed 'out of the box' process guidance or more basic checklists that are customizable according to the needs of the project. Each time a user accesses the integrated tools available in the Visual Studio 2005 Team System, they can choose the level of detail and customization they desire in the process guidance.

By incorporating the lessons learned and by using Microsoft's internal and external resources, process integration in Visual Studio 2005 Team System delivers solutions to the software professional in an unprecedented way.

Extensibility Possibilities

With MSF, process is not just documentation. It also manifests itself as actual tool behavior changes. When you chose the process at project inception, you are also choosing the workflow and work products, which then drive how the system behaves. Support for the SDLC process is built-in, which makes for seamless workflow support. By integrating process into the tools team members use on a daily basis, MSF lowers the barrier to adopting process and enables the automatic collection of cross-functional project metrics without the overhead associated with manual reporting. The following elements of MSF are customizable:

  • Process Guidance
  • Iteration structure
  • Entry criteria and exit criteria views
  • Work item type definitions and rules (activities and work products)
  • Work item queries
  • Source check-in policies
  • Role clusters and security groups
  • Document templates (Excel and Word)
  • Microsoft Project templates
  • Reports
  • Project portal /SharePoint site template

MSF uses methodology templates to define the process that individual projects follow. There is no universal process that works for all organizations, or even all projects within an organization. To address this, MSF provides a flexible toolset that works with both agile and formal processes. Microsoft's Global Solution Integrator partners provide their own product consumable methodology templates; or, you can create your own. Process extensibility allows customization of work item types, check-in policies, custom reports and project management templates.

Conclusion

MSF provides better process guidance for software development by presenting the right process to the right person at the right time. Based on successful, real-world best practices from internal Microsoft sources and qualified external sources, MSF has avoided the pitfalls of previous attempts to formalize the software development process while incorporating the successful elements. The MSF solution provides a framework for productive, integrated, and extensible process guidance and a flexible toolset that works with both agile and formal processes.

For more information on the other members of Visual Studio 2005 Team System, see: