For my current assignment, which is related to integrating existing and developing new Software Factories in our software development process, I decided to have a look at project GlidePath. According to the GlidePath website this project will deliver guidance on how to build software for Vista. It delivers a web based repository of software factories that can loaded into the Visual Studio environment. One of the very interesting features of GlidePath is the possibility to update the Software Factories over an RSS feed. It’s actually this feature that made me investigate GlidePath to see if we can use this or a similar approach in our own development process.
Once installed, you can use the Glidepath guidance package to create a Visual Studio solution structure. Instead of generating a full blown solution structure, like for example Service Factory does, Glidepath provides you with a rather empty solution. At that moment the solution doesn’t reflect the actual product at all but rather provides you with the possibility to decide what factory to use in this solution structure (and thus what product to build?). In this release of Glidepath you can only select one factory (MicrosISV factory) but I assume this will change in the future. Once I had added the MicroISV factory to my Glidepath solution I was surprised to see a lot of viewpoints popup in my solution structure (at this moment represented as .txt files). From what I understood from Glidepath the idea behind these viewpoints is that you can select and configure them to specify how to build your product in the factory. Glidepath will create new projects or enable packages (factories) in your current solution based on the viewpoints you configure for your product. Currently, Glidepath populates the MicroISV factory with viewpoints like “DataAccess”, “Deployment “, “Blogging”, “Legal”, etc.
Figure 1. Glidepath solution structure
After playing with Glidepath for a while I suddenly realized that I didn’t had a clue what kind of product I was actually building in my factory. I could see that my solution was populated with a project for “blogging” and project for “CSharp-WinForms-UX” because I selected these viewpoints for this solution. However, from looking at the solution structure I wasn’t able to tell whether I was building a “blogging service”, a “blogging site” a “windows client for my blogging service” or whatever. Of course I understand this is related to this very early release of Glidepath and therefore lack of implemented packages, but I realized this was caused by the fact that the Glidepath factory doesn’t have any notice (yet) about the product itself and therefore couldn’t tell me either what product I was building.
I was interested by this and tried to understand what this would mean for me if I had to implement (build a guidance package) one of the viewpoints for MicroISV. How would I know about the underlying product my viewpoint will be used on? Is it even necessary to have knowledge about that or can we generalize viewpoint implementations so they can be used on all products we are building? To be honest, I don’t have the answers for that at this moment. My current thinking is that it would be helpful to have a formal description of the product I am implementing my viewpoint for but as said, I don’t have the answers yet.
A related question that interests me is: “what comes first?” Let’s say I was asked to build a factory for product X. Would I start with defining the viewpoints for my factory (security, deployment, etc.) or would I start by describing the basics of product X first? Or would I do this simultaneously?
Logically I would say, I first need a full picture of the product (product X) I am building the factory for. Ideally, I would describe this product at a conceptual level (product model) in a way that makes this knowledge easily accessible and understandable for other people. Once I know what I am talking about, and thus have understanding of the problem domain, I can decide what viewpoints are important, how to provide automated guidance for that, etc.
If we have captured the knowledge about the product we cannot only use this to author the factory but also to guide the factory user through the product at runtime. The factory can use the product model to communicate with the factory user in terms that make sense to the factory user and are related to the problem domain he is developing software for.
Currently Jezz and I are working on an experimental software factory authoring approach using a tool called the Factory Product Model (FPM). I will not explain this approach or tool in detail in this post but if you are interested in more details you can read this, this, this and this post.
In this experiment, we are trying to validate whether a formal description (model) of the product the factory is building is a valid starting point for defining the factory and what it builds.
As far as I understand now, viewpoints will definitely play an important part in factory authoring and usage but what I am trying to find out is what impact they have and how they possibly relate to something like FPM.
I think specifying viewpoints is all about (some of) the requirements of the product we are building in the factory and therefore impact the type of guidance that is needed in the factory.
After all a viewpoint is what you get when you associate a work product, to an assets and a set of activities. Therefore viewpoints and work products are tightly related. It is just a question of which one do you define first?
I would be very interested in any ideas about this topic. What do you think? Do we need a product first approach (an FPM)? How does this relate to the Glidepath viewpoints approach I described? Do we need both? Do we need them in a specific order?
Let me know!