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.
Advertisements
This entry was posted in Computers and Internet. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s