Microsoft, TFS (Team Foundation Server), MSF 4.0 (Agile or CMMI), DSL (Domain Specific Languages), essUP (Essential Unified Process), Software Factory
It has been almost a year since I wrote this blog about the Essential Unified Process, and this one on DSLs.
I am currently looking at Team Foundation Server in the context of what it has to offer the development process. The one thing that still has me baffled is why Microsoft chose the two extremes for the implementation of MSF 4.0. Neither lend themselves well to tailoring a normal software development life cycle. What I mean by normal is the Unified Process with a little more or a little less ceremony than the baseline it offers. One thing to note about these processes is that they avoid UML. I find it hard to believe though, that Microsoft would go so far out of the way to avoid it. They do suggest it in some areas, like domain modeling. But there suggestion is to model in Visio, forward engineer the model to code and then open it up in their DSL class modeler. That is just plan dumb when tools like Enterprise Architect exist.
If we are going to use Team Foundation Server, we are going to have to implement a development process. It is doable but painful. They have no real tool support built for it. The ones that are out there are very painful to use. And I am including configuration management in the creation of our process repository. That will be the painful part. Where in the heck is the Essential Unified Process stuff they preached, and said they were working on? I was told before it would be available in the spring of 2006. This says the end of 2006 now. Hopefully that is the case.
Jack Greenfield wrote a pretty good article on Software Factories and VSTS here, called Measuring Success with Software Factories and Visual Studio Team System. The good news about Software Factories is that for the most part they use proven industry standards to accomplish there goals. The bad news about them is that they are basically a high ceremony product line engineering process, and Microsoft has ignored Product Line Engineering in there MSF 4.0. I do not get it. The article is excellent at showing the capabilities of VSTS and TFS as far as configuration for software factories goes, the problem is that it is not enough. It needs to go much, much further, or they need to start supplying out of the box resources for Product Line Engineering. Jack also mentioned Viewpoints. This is an excellent book on the subject.
I have finally come across a good candidate for the creation of a DSL. Jack also covers it to some degree in his article under feature configuration. This is an excellent book on PLE. The main problem with the book is that it uses the Orthogonal Variability Model to trace the variability in the project's artifacts, and there were no tools to support an Orthogonal Variability Model when the book was written. Since then a plug-in for Eclipse has been written. You can get it here. The problem is it kinda stinks. This is a perfect candidate for a VSTS DSL implementation. The problem is time to learn the VSTS DSL tools isn't worth it when I can continue to use the UML profile written for Product Line Engineering feature analysis.
We are still not sure if we will incur the overhead of TFS for our development environment. In some ways it seems like MS has done what a friend of mine pointed out IBM did a few years ago and made the mistake of making you use all their tools, or none of them. So far I don't think that is the case, but it could very easily end up that way and that would very bad. If it was reasonable to ignore MS I would just use Enterprise Architect for all our documentation and modeling needs, MS Project for planning, VSTS Developer Edition for the team members, plus one VSTS Tester for each team, SharePoint with a custom built process repository, and I'd flip a coin for VSS or Vault. But we cannot ignore them. Right now TFS has some definite rough edges, but it is a great start in the right direction for pulling together tools that if enhanced in the right direction could prove to be an excellent development process environment. Notice I did not mention VSTS Architect. Our company has phased out it's use completely. They did start with it, but soon realized it offered nothing for the Software Architect, only the System Architect. MS said that would change here, but it hasn't and we doubt it will.
We have made two decisions however that won't change in this evaluation. We will be using Enterprise Architect for all our documentation and modeling needs. MS has done nothing to provide an alternative for UML, and I doubt they will. Visio's UML tools are ancient, and the DSL class modeler isn't worth much either. We will also not be using the MSF 4.0 process implementations for anything. Which means we will start from scratch. We won't try to enhance or alter the MSF 4.0 CMMI or Agile implementations to a usable process. The only thing that may change this is if the essUP becomes available before we implement our own.
I am currently looking at Team Foundation Server in the context of what it has to offer the development process. The one thing that still has me baffled is why Microsoft chose the two extremes for the implementation of MSF 4.0. Neither lend themselves well to tailoring a normal software development life cycle. What I mean by normal is the Unified Process with a little more or a little less ceremony than the baseline it offers. One thing to note about these processes is that they avoid UML. I find it hard to believe though, that Microsoft would go so far out of the way to avoid it. They do suggest it in some areas, like domain modeling. But there suggestion is to model in Visio, forward engineer the model to code and then open it up in their DSL class modeler. That is just plan dumb when tools like Enterprise Architect exist.
If we are going to use Team Foundation Server, we are going to have to implement a development process. It is doable but painful. They have no real tool support built for it. The ones that are out there are very painful to use. And I am including configuration management in the creation of our process repository. That will be the painful part. Where in the heck is the Essential Unified Process stuff they preached, and said they were working on? I was told before it would be available in the spring of 2006. This says the end of 2006 now. Hopefully that is the case.
Jack Greenfield wrote a pretty good article on Software Factories and VSTS here, called Measuring Success with Software Factories and Visual Studio Team System. The good news about Software Factories is that for the most part they use proven industry standards to accomplish there goals. The bad news about them is that they are basically a high ceremony product line engineering process, and Microsoft has ignored Product Line Engineering in there MSF 4.0. I do not get it. The article is excellent at showing the capabilities of VSTS and TFS as far as configuration for software factories goes, the problem is that it is not enough. It needs to go much, much further, or they need to start supplying out of the box resources for Product Line Engineering. Jack also mentioned Viewpoints. This is an excellent book on the subject.
I have finally come across a good candidate for the creation of a DSL. Jack also covers it to some degree in his article under feature configuration. This is an excellent book on PLE. The main problem with the book is that it uses the Orthogonal Variability Model to trace the variability in the project's artifacts, and there were no tools to support an Orthogonal Variability Model when the book was written. Since then a plug-in for Eclipse has been written. You can get it here. The problem is it kinda stinks. This is a perfect candidate for a VSTS DSL implementation. The problem is time to learn the VSTS DSL tools isn't worth it when I can continue to use the UML profile written for Product Line Engineering feature analysis.
We are still not sure if we will incur the overhead of TFS for our development environment. In some ways it seems like MS has done what a friend of mine pointed out IBM did a few years ago and made the mistake of making you use all their tools, or none of them. So far I don't think that is the case, but it could very easily end up that way and that would very bad. If it was reasonable to ignore MS I would just use Enterprise Architect for all our documentation and modeling needs, MS Project for planning, VSTS Developer Edition for the team members, plus one VSTS Tester for each team, SharePoint with a custom built process repository, and I'd flip a coin for VSS or Vault. But we cannot ignore them. Right now TFS has some definite rough edges, but it is a great start in the right direction for pulling together tools that if enhanced in the right direction could prove to be an excellent development process environment. Notice I did not mention VSTS Architect. Our company has phased out it's use completely. They did start with it, but soon realized it offered nothing for the Software Architect, only the System Architect. MS said that would change here, but it hasn't and we doubt it will.
We have made two decisions however that won't change in this evaluation. We will be using Enterprise Architect for all our documentation and modeling needs. MS has done nothing to provide an alternative for UML, and I doubt they will. Visio's UML tools are ancient, and the DSL class modeler isn't worth much either. We will also not be using the MSF 4.0 process implementations for anything. Which means we will start from scratch. We won't try to enhance or alter the MSF 4.0 CMMI or Agile implementations to a usable process. The only thing that may change this is if the essUP becomes available before we implement our own.
posted by tadanderson at 6:06 PM
1 Comments:
You said
"This is an excellent book on PLE. The main problem with the book is that it uses the Orthogonal Variability Model to trace the variability in the project's artifacts, and there were no tools to support an Orthogonal Variability Model when the book was written."
I'm not sure it's the case that there were no tools to support the model or whether the authors missed pure::variants - which has been around since 2004. Probably the latter.
Mark Dalgarno
Software Acumen
Blogging at
The Variation Point
Post a Comment
<< Home