This week I’ve been working on a paper that we’ll publish in Software Development magazine that explains, at least very briefly, how Visual Studio Team System (VSTS) will support the first step forward for our concept of software factories. As soon as it’s ready for publication, I’ll post the link here. We’ve started to collect some material on the software factory concept on a website http://softwarefactories.com but due to my severely limited html skills, this website is still under development. I hope soon to have a real website developer improve it considerably J.
Software factories are more than just a strategy for modeling tools and DSLs. IMO, they are a necessary step if the software development industry is to respond to rising technological complexity and expectations of users. Here’s a brief excerpt from the paper I just mentioned:
A software factory is a product line that configures extensible development tools like Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:
· Think of the software factory schema as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and frameworks of which it is comprised.
· The software factory template is like a bag of groceries containing the ingredients listed in the recipe. It provides the patterns, guidance, templates, frameworks, samples, custom tools such as DSL visual editing tools, scripts, XSDs, style sheets, and other ingredients used to build the product.
· An extensible development environment such as VSTS is like the kitchen where the meal is cooked. When configured with the software factory template, VSTS becomes a software factory for the product family.
To press this analogy further, the products are like meals served by a restaurant. Software factory stakeholders are like customers who order meals from the menu. A product specification is like a specific meal order. The product developers are like cooks who prepare the meals described by the orders, and who may modify meal definitions, or prepare meals outside the menu. The product line developers are like chefs who decide what will appear on the menu, and what ingredients, processes, and kitchen equipment will be used to prepare them.
The paper will give some more concrete examples, but hopefully you’ll see that this is the start of a way to think about software development using pre-defined content such as frameworks and software components, patterns – both design and architectural, development processes and tools. When VSTS is first released, this “recipe” bundling will be non-automated, or possibly only partially fleshed out, but as time goes by, more of the process of defining “recipes” can be automated, and the software factory vision filled out. The Whitehorse tools, of course, being an implementation of a few key developer-oriented DSLs, are part of this vision, and will be part of VSTS as I’ve described elsewhere.