In many ways, the software development process resembles manufacturing. Regardless of whether the product is widget or code, typically, one part of the organization identifies the need, then different departments get involved in scoping functions or features, identifying end markets, design, manufacture, delivery, and post-sales support. The problem is that the process tends to be disconnected, with each group throwing the fruits of its labors over the wall to the next.
In manufacturing and software development alike, there have been numerous efforts to integrate the life cycle. The reality is that turf battles and the fact that each group requires different kinds of tools to do their job has hindered the goal of a seamless life cycle.
For instance, in manufacturing, design engineers produce bills of materials focused around technical specifications. Yet, in the back office, manufacturing bills of material contend with parameters such as grades and quantities. Although there is some common data, you wouldn’t use the same tool to design engineering and inventory-focused bills.
The same goes with software development. A developer who writes code may perform a few perfunctory tests before throwing it over the wall to QA, which tests the app more thoroughly. Consequently, both groups require tools carrying different levels of detail or functionality for testing.
In a nutshell, that’s been a large part of the problem deterring vendors from building tools that integrate the software development life cycle, from requirements gathering to use case analysis, modeling, version control, construction, testing and debugging, final deployment, and operation. Back in the 1980s, IBM’s AD Cycle failed because it tried enforcing a data architect’s view on software development. Although Rational was a bit more successful when it acquired the products that became Rational Suite, the product suffered from neglect as the company failed to update the suite with common technology that would have provided a better alternative to file transfer-based integration.
Now Microsoft has upped the ante with Visual Studio Team System (VSTS), a framework that taps web services and a meta data store (they insist it’s not a repository!). It will provide a degree of integration on managing development akin to what it accomplished with the common front end integration of Visual Studio. On the bright side, Team Studio relieves providers of life cycle tools, such as Compuware, Serena, Borland, and dozens of niche providers from having to write their own interfaces, repositories, or frameworks.
The challenge, of course, is that Microsoft is best known for developer tools, and has little outside experience with tools serving other constituencies, such as testers. Rational had that problem as many veteran UML modelers were put off by the developer-oriented XDE successor to Rational ROSE. Will Microsoft fare any better this time?
Our answer is a qualified yes. OK, the product won’t be out until next year, and it’s not a solution if you develop Java or on other platforms (and that’s a major limitation). But the combination of Microsoft’s critical mass presence in the developer community, the hunger of niche tool vendors to get their wares accepted by wider audiences, and the emergence of standards such as web services which will be used for communications between the functional parts dictate that Microsoft’s approach to unify the life cycle will be treated more seriously than most of its predecessors.