The Microsoft Solutions Framework: An Integrated Approach to Agile or Formal Software Development Process
The Microsoft Solutions Framework: An Integrated Approach to Agile or Formal Software Development Process
Granville G. Miller, Program Manager, Visual Studio 2005 Team System
It would certainly be nice if there could be one way of building software. However, the truth is, there are many different types (e.g. embedded, packaged application, web service, three-tier client server, or web) of applications and so there must be just as many ways to build them. Compound this with the different software development cultures and the different types of competitive environments (hyper-competitive to regulated) and you can reach only a single conclusion. There can be no single software development process for all software development projects. This is the central philosophy behind the Microsoft Solutions Framework.
What every software veteran learns is that the way to adapt to all of the different project climates is to develop a set of good techniques for dealing with all of the different challenges that they might face. In an agile environment, these tools can be used at any time to meet these challenges. In a formal environment, the goal is to pick the correct set for the project and refine them over time. Each of these approaches has merits.
The trouble is that these techniques are divorced from the tooling that they use. The techniques are often shoe horned into a set of disparate tools that were never meant to support them. These tools do not share a common meta-model. Hence, information has to be manually moved from one tool to another. Worse, during the move, the semantic meaning of this information is lost.
The Problem with Process
Most people see the problem with software development processes being a constant struggle between productivity and repeatability. When project schedules get tight, and we rarely have room to spare in the schedule, the process goes “out the window”. But does it really? Even when we go “out-of-band” on our processes, we continue to use our configuration management system and our bug tracking systems so some elements of process remain. These elements are those that are ingrained in our culture and supported by necessary tooling.
When process is divorced from tooling, it creates an impedance mismatch. Ask yourself, when I make a change to the process, do I make a change to the tooling? No? Why not? This illustrates the impedance mismatch precisely. We expect our developers to translate our process on to our tooling. This translation requires unnecessary effort which is often seen as unnecessary when the project schedule gets tight.
The fact is, most processes are disconnected from the tooling that is used to enact them. Tooling is built to support multiple processes (because there can be no single software development process) but it is built to the least common denominator. In other words, it handles the things that all software development processes require but fails to handle the elements that provide the value in differentiating a process. The result is that we fall back to this least common denominator instead of holding on to the parts of the process that provide competitive advantage.
Introducing Microsoft Solutions Framework (MSF) version 4.0
Microsoft Solutions Framework (MSF) version 4.0 is a combination of a meta-model (or framework) on which processes are built, and two instantiations of that metamodel. One of the instantiations is an agile software development process and the other targets a more formal environment.
Both are scenario-driven, context-based software development processes for building and improving .NET and other object-oriented applications. Each directly incorporates practices for handling quality of service requirements such as performance and security. They use a context-based approach to guide the operation the project. This approach helps create an adaptive (agile) or refinement (formal) process that governs the overall project.
Both processes are highly customizable, scalable, and fully integrated with Visual Studio 2005 Team System. The tooling and processes work together to provide a more productive user experience than the process or tooling could provide alone. This is because both tooling and processes are built using the same meta-model. In other words, 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.
Figure 1: A Web View of MSF Agile
Figure 2: How MSF and the Visual Studio 2005 Team System interact
Visual Studio Team System provides a methodology template to enact the process. This methodology template contains work items (scenarios, quality of service requirements, development tasks, test tasks, risks, and bugs), security settings, process guidance, process reports, source check-in policies, Microsoft Project templates, document templates, and a project portal/Windows SharePoint Services site template configured to support the MSF processes. MSF provides integrated guidance to plan, build requirements, architect, design, develop, and test the project. This guidance is completely integrated so that it appears just like an integrated extension to the help system.
Customizing MSF and Visual Studio 2005 Team System
MSF can be used out the box or combined with the practices that provide competitive advantage to your project and your organization. You may add your process guidance to those pieces of the MSF process that you find appealing and remove those pieces of MSF that you feel do not apply to your project. You can even remove all of MSF and replace it with your existing process. The second way of deploying process to Visual Studio Team System is to map your process to the MSF metamodel. This is the framework approach to building a new enactment of a Visual Studio Team System process. The value in this approach is that it allows you to maximize the potential of your process and potentially utilize the integrated project environment to its maximum potential. Many of our partners are already in the process of doing this.
Once you have created the process that you wish to deploy, you can deploy a new methodology template complete with any changes to the Visual Studio Team System enactment (such as a new field in the bug work item or even a brand new work item) of this new process. The methodology will show when new portfolio projects (projects utilizing the Team Foundation Server capabilities) are created and you process will be centrally available to all members of the team.
This allows a uniform deployment of your fully integrated process. Work that is done on this project will utilize the work items (perhaps user stories and tasks) that your process feels provide maximum value. Best of all, it’s all available from inside the Visual Studio environment. There is no need for a disconnected or impedance mismatch between process and tooling.
Conclusion
Microsoft has been successfully delivering software for many years. In the process, we have developed some innovative techniques for delivering products. MSF v4 is Microsoft’s contribution to building more successful projects in whatever style (agile or formal) works best for you.
Visual Studio 2005 Team System provides a completely customizable project and software development environment for these innovative software development processes, whilst able to house any other process you desire. Combined, the Microsoft Solutions Framework and Visual Studio 2005 Team System provide a framework for productive, integrated, extensible process guidance and tools that work for both agile and formal processes.