共用方式為

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.

Click here to read more...

Comments