Microsoft Solutions Framework

Visual Studio 2005 Team System acts as a powerful engine for managing your Software Development Lifecycle. This extremely flexible tool can be configured to support a variety of software development processes. This flexibility is essential, but it requires the team to make important choices about how they want to configure and use VSTS.

The Microsoft Solutions Framework (MSF) version 4.0 is a metamodel for describing SDLCs. This framework can be instantiated into one or more prescriptive methodologies that reflect the specific needs of organizations.

MSF is the product of an evolutionary process. First introduced in 1994 as a collection of best practices from Microsoft product-development efforts and Microsoft Consulting Services engagements, MSF has evolved based on lessons learned from successful, real-world experiences of Microsoft product groups, Microsoft Services, the Microsoft internal Operations and Technology Group (OTG), Microsoft 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. Teams within various Microsoft lines of business regularly create, find, and share best practices and tools internally. The knowledge gained from these internal project efforts are consolidated and distributed outside of Microsoft through MSF.

What's New in MSF 4.0

MSF 3.0 is a framework that describes best practices in terms of foundational principles, conceptual models, and disciplines. It provides a descriptive foundation from which specific methodologies can be derived. However, MSF 3.0 does not actually include any specific methodologies. As such it's not prescriptive in nature.

MSF 4.0 is also a descriptive framework. In fact, the MSF 4.0 framework is similar to MSF 3.0 in many respects, but here's the big difference: MSF 4.0 also includes two prescriptive methodologies. The two methodologies are MSF for Agile Software Development and MSF for Capability Maturity Model Integration (CMMI) Process Improvement. One way of looking at it is to consider these methodologies as instances of the framework. These prescriptive methodologies are implemented in Visual Studio 2005 Team System.

Descriptive vs Prescriptive

A descriptive SDLC model documents the process passively, from the point of view of an observer. Descriptive models are useful as the basis for understanding and improving software development processes. A prescriptive SDLC model, on the other hand, describes the process in terms of the players involved, the sequence of activities, and the end products. If software development is like baking a cake, the descriptive model is a narrative that contains useful guidelines for baking cakes in general, while the prescriptive model is the recipe for baking a particular cake. Put yet another way, a descriptive model can be translated into one or more prescriptive models, and each prescriptive model can be translated into action.

The MSF 3.0 framework and the MSF 4.0 metamodel are structurally similar. They both contain foundational principles, a team model, a process model, and disciplines. As might be expected, MSF 4.0 makes changes to these components based on the current state of the art, but these changes are incremental in nature. Because the notion of incremental improvement is built into MSF, it makes sense to apply that philosophy to MSF itself.

MSF 3.0 contains eight foundational principles:

Foster open communications.

Work toward a shared vision.

Empower team members.

Establish clear accountability and shared responsibility.

Focus on delivering business value.

Stay agile, and expect change.

Invest in quality.

Learn from all experiences.

MSF 4.0 includes all the foundational principles in MSF 3.0 and adds two more:

Partner with customers.

Always create shippable products.

The Team Models for both MSF 3.0 and MSF 4.0 describe a team of peers with shared responsibility, clear accountability, and open communications.

MSF 3.0 describes team member roles in terms of the following Role Clusters:

Product Management

Program Management

Development

Test

User Experience

Release Management

MSF 4.0 replaces the term Role Cluster with Advocacy Groups, where each Advocacy Group has a Constituency with representation on the team. The MSF 4.0 Advocacy Groups are identical to the MSF 3.0 Role Clusters except that MSF 4.0 adds another Advocacy Group: Architecture.

The MSF 3.0 Process Model is a hybrid of two well-known SDLC models: the waterfall and the spiral. It's basically an iterative development process like the spiral, where each iteration contains five waterfall-like phases with clearly defined milestones.

The MSF 4.0 Process Model builds on MSF 3.0. It includes the same iterative development process, but it adds a setup iteration at the beginning and a release iteration at the end of the project cycle. The MSF 4.0 Process Model is definitely an improvement because it more accurately reflects the complete life cycle of a development project.

MSF 3.0 includes three disciplines: Project Management, Risk Management, and Readiness Management. Disciplines tend to be prescriptive in nature, and they can also vary significantly from one methodology to the next. For this reason, the MSF designers chose to remove disciplines from the metamodel altogether and add them to the methodology process guidance instead. You can find the MSF 3.0 disciplines more or less intact in the process guidance for MSF for Agile Software Development, but the disciplines in the process guidance for MSF for CMMI Process Improvement will more closely reflect the Capability Maturity Model (CMM) Key Practice Areas for a Level 3 organization.

Figure 8-1

Process Model Comparison

MSF 4.0 Structure

MSF 4.0 contains both descriptive and prescriptive components. (See Figure 8-2.) The descriptive component is called the MSF 4.0 metamodel, which is a conceptual description of SDLC best practices. The metamodel is not tied to any specific methodology-it can be implemented in various ways.

Figure 8-2

MSF 4.0 structure

MSF 4.0 implements the metamodel as prescriptive methodologies that provide specific process guidance. VSTS comes with two MSF 4.0 methodologies: MSF for Agile Software Development and MSF for CMMI Process Improvement.

The MSF 4.0 Metamodel

The MSF 4.0 metamodel offers a flexible and scalable framework for creating SDLC methodologies. It defines best practices that work for projects of any size or complexity. The metamodel consists of foundational principles, a team model, and a process model.

Foundational Principles in MSF 4.0

The MSF 4.0 Foundational Principles express values and standards that are common to all elements of the metamodel. These principles are common-sense observations that developers and managers generally recognize as valid and useful. Together, these principles express the MSF philosophy, forming the basis of a coherent approach to organizing people and processes. These principles are as follows:

Partner with customers.

The best solutions emerge when development teams engage with their customers, creating a collaborative relationship based on common goals. Customers should participate throughout the development process-validating the business value of the solution and providing feedback on the user experience.

Foster open communications.

To maximize members' individual effectiveness and optimize efficiencies in the work, information has to be readily available and actively shared.

Work toward a shared vision.

Having a generally long-term and unbounded vision inspires the team to rise above its fear of uncertainty and its preoccupation with the current state of things and to reach for a higher goal.

Empower team members.

In an effective team, all members are empowered to deliver on their own commitments and to feel confident that other team members will also do the same.

Establish clear accountability and shared responsibility.

Failure to establish clearly understood lines of accountability and responsibility on projects often results in duplicated efforts or missing deliverables.

Focus on delivering business value.

Although many technology projects focus on the delivery of technology, technology is not delivered for its own sake-solutions must provide tangible business value.

Stay agile; adapt to change.

The more an organization seeks to maximize the business impact of a technology investment, the more it ventures into new territories. This new ground is inherently uncertain and subject to change as exploration and experimentation results in new needs and methods. To pretend or demand certainty in the face of this uncertainty would, at the very least, be unrealistic and, at the most, dysfunctional.

Invest in quality.

An investment in quality therefore becomes an investment in people, as well as in processes and tools. Successful quality management programs recognize this and incorporate quality into the culture of the organization.

Learn from all experiences.

Taking time to learn while on tight deadlines with limited resources is difficult to do, and even tougher to justify, to both the team and the stakeholders. However, the failure to learn from all experiences is a guarantee that we will repeat them, as well as their associated project consequences.

Always create shippable products.

The team should be committed to creating the highest quality product when making changes. Each change should be done in the context of the belief that the product should be ready to ship at any time.

The MSF 4.0 Team Model

The MSF 4.0 Team Model describes Microsoft's approach to organizing people and activities for successful projects. The model is based on the following principles:

Team of peers.

Everyone on the team has shared responsibility for the outcome of the project. Each role is accountable for a specific share of the quality of the overall solution.

Advocacy.

The team uses a decision-making process in which each key constituency is represented equally. Each representative is expected to act as an advocate for his or her constituency.

Stretch to fit.

Constituencies can be combined into small teams or further refined as teams scale for larger projects.

Advocacy Groups

Central to the MSF 4.0 Team Model are advocacy groups. Advocacy groups consist of peers who represent all the constituencies involved in the production, use, and maintenance of the product. There is no hierarchy involved-no team member is more important than another. This approach produces a system of checks and balances that guides the team toward the right solution.

Each team member acts as an advocate on behalf of the constituency that he or she represents. This relationship is called the Advocacy Group. Let's examine each Advocacy Group in more detail:

Product Management.

This group advocates for the customer business. The product management group has to understand the customer business, communicate the customer's needs, and ensure that the customer requesting the solution view the project as a success.

Program Management.

This group advocates for solution delivery. The focus of program management is to meet the goal of delivering the solution within project constraints. This group ensures that the right solution is delivered at the right time and that all stakeholders' expectations are understood, managed, and met throughout the project.

Architecture.

This group advocates for systems in the large. The term "systems in the large" includes the services, technical considerations, and standards with which the solution will interoperate; the infrastructure in which it will be deployed; its place in the business or product family; and a roadmap of future versions. The architecture group has to ensure that the deployed solution will meet all qualities of service as well as the business objectives, and that the solution will be viable in the long term.

Development.

This group advocates for the technical solution. In addition to being the primary solution builders, the development group is responsible for thoughtful technical decisions, clean design, good bottom-up estimates, high-quality maintainable code, and unit tests.

Test

This group advocates for solution quality from the customer perspective. The test group anticipates, looks for, and reports on any issues that diminish the solution quality in the eyes of the users or customers.

User Experience.

This group advocates for the most effective solution from the perspective of the intended users. User experience must understand the user's context as a whole, appreciate any subtleties of user needs, and ensure that the whole team is conscious of usability from this perspective.

Release Operations.

This group advocates for the smooth delivery and deployment of the solution into the appropriate infrastructure. This group ensures timely readiness and compatibility of the infrastructure for the solution.

The MSF 4.0 Process Model

The MSF 4.0 Process Model (shown in Figure 8-3) consists of a series of short development cycles. Small iterations support continuous learning and refinement, reduce the margin of error in estimates, and enable incremental testing and delivery of the product.

Figure 8-3

The MSF 4.0 Process Model

Each iteration focuses on implementing specific features of the system, resulting in a stable, functional version of the product. Each incremental version of the product might be an unreleased alpha test version, released to the user community as a beta test version, or released as a functional incremental version that can begin delivering value immediately.