One of the new buzz words in IT is “Software Factories”. Although this methodology is in its very early stage, I think it is important to understand the concepts behind this methodology. Because Software Factories is a “new concept” and the topic covers a lot of new stuff, introducing these concepts can be hard (at least for me). Therefore I am looking for a way to get familiar with Software Factories bit by bit. Maybe, mapping Software Factories to concepts that I am already using at this moment can help. At least it gives me a starting point from were I can think about Software Factories and explore the possibilities of this new methodology. Let me share some of my thoughts about the roadmap I think is best for me to get familiar with Software Factories and start working with it in the near future.

Software Factory

In short, a Software Factory can be best described as a fully configured development environment for developing a particular type of software. Based on the fact that currently software development isn’t as successful as we want it to be this new methodology is introduced. The methodology is build on experiences gathered from more successful and much more productive industries like for example the car industry. Within these industries it is very common to use highly standardized processes, predefined designs and reusable components to rapidly manufacture products. This results in a very productive manufacturing process with predictable quality of the manufactured products. Lessons learned from these industries are now used to create a new methodology, called Software Factories. Software Factories targets the software development industry and aims to provide the same kind of advantages achieved in other industries.

Although Software Factories are still evolving and the methodology isn’t fully supported by tools yet, I think it is possible to start using some of these concepts in software development. To explain what I think can be done today, let me try to map the concepts of Software Factories to concepts that are more common (for me) within software development. For this purpose, let’s assume we have a logical architecture defined within our organisation that we are using for software development. Let me explain what I mean by a logical architecture (I will not cover this in detail at this moment, just enough to make my point. This is just my imaginary architecture J).

Logical Architecture

A standardized logical architecture can help architects break down the requested business functionality to one of the different responsibility domains. Well defined responsibility domains provide guidance to IT project members during the design and implementation phase of a software development project. Some of the keys to success in this area are standardization, patterns and frameworks. Having these in place makes software development more manageable and can guarantee a constant quality. Most of the time there is some guidance available, very often in the form of a Word document or some standard components (framework) that can be used. Unfortunately the usage of these guidelines isn’t embedded in the whole development process and is not supported by development tools at all. Let’s have a look at how Software Factories can help solve this “problem”. To make things more clear let’s assume we have a logical architecture defined within our company. Within this architecture we make a distinction between different domains:

·         Presentation domain; this domain hosts all user interaction related features. It hosts features like dialog management, multi channel support, etc.

·         Process domain; this domain is responsible for controlling the actual business process. The business process can be best described as the way an organisation is handling its procedures, workflow, tasks and information. The business process coordinates the tasks and makes sure they get executed by either communicating with the end user (through the presentation domain) or the business information services.

·         Business information domain; this domain maintains all information within the organisation. Information can be grouped together in logical area resulting in one or more business information services. Business information services are autonomous services and deliver information, or perform a business action on behalf of the business process.

·         Infrastructure domain; this domain represents the infrastructure that will be used for the application. This includes the messaging infrastructure and other generic services providing the so called ‘cross-cutting concerns’ (e.g. security, logging, instrumentation, etc.). Services and features included in this domain are not application specific and can serve more applications at a time.

From logical architecture to Software Factory

So, now we have our logical architecture defined, what’s next? The reason we defined separate domains within our logical architecture is to group together services with similar responsibilities or capabilities. In the ideal world there should be guidelines available that helps architects and developers to implement services in one of the above described domains. These guidelines can be in the form of a simple word document but can also be represented by a framework or a set of patterns that must be used by the development team. This is exactly where I think Software Factories come in!

Software Factories aims to provide a fully described and configured development environment for a specific type of application (read: domain) Thinking a little further and having a look at our logical architecture I can define at least four Software Factories (one for every domain in the logical architecture). Although four fully implemented Software Factories should be sufficient for providing the necessary guidance for implementing services or components in each of the four domains, I think I am not there yet! I still need a standardized way for translating the business needs to components or services in one of our four domains. To solve this issue I can create another Software Factory that provides guidance in mapping the business requirements to one of the described domains in our logical architecture. This overall Software Factory can be my factory that targets web based distributed applications and is composed out of the other four Software Factories. The five Software Factories together cover all concerns for building web based distributed applications.

Because I defined five separate Software Factories (instead of one big one) each of the factories exactly targets a group of people in an ordinary IT project. The overall Factory for example, targets the business analyst and the architect who work together to gather the necessary information from the end user. This software factory describes the process how to translate and group together the requirements from the end user to services in one of our four domains. The Factory that targets the presentation services domain provides the web developers in the project with the necessary patterns, frameworks, and guidance to implement the user interface services and so on for the rest of the factories.

So, now I defined my Software Factories, what’s next on my to-do list?

Software Factory schema and template

One of the important things in Software Factories is a software factory schema. Basically this is a document that summarizes all artifacts we need to produce, to successfully develop a piece of software. This schema doesn’t only tell us what products we have to deliver and how they look like, it also tells us in what order we have to do this and what is the relation between the several products. The software factory schema contains both fixed and variable products which makes the software factory more flexible. Having a well defined software factory schema isn’t actually new (except for the name). Some other methodologies (like RUP) also summarize and describe the artifacts that must be created during a software development project. However, I think there are some differences between these methodologies and the Software Factories methodology. Within Software Factories the list of artifacts and the description of the artifacts are much more targeted at a specific type of software. Other methodologies tend to have a more general way of describing the artifacts, they don’t really target the specific domains in our logical architecture for example. I think the advantage of the software factory is that in the end it provides much more guidance!

Having the full list of artifacts (and their description) in place doesn’t do the job. To make it really useful we need the implementation of all these artifacts and more importantly we have to make them available to the development team. This is where the Software Factory template comes in. A Software Factory template is a collection of patterns, frameworks and a Domain Specific Language (DSL) that can be loaded into a tool (for example Visual Studio 2005 Team System). The combination of the software template and the tool helps us automating the software development process. One of the main purposes of the template is to configure the tool and “guide” the development team through the process of building a specific type of software (in our case, software that fits in one of our domains in the logical architecture).

So, where are we? If we think Software Factories is promising enough to invest in, I now have a possible approach to start implementing (or at least think about it) this methodology step by step within my daily work. I can simply pick one of the responsibility domains within the logical architecture and start describing the artifacts that we need to successfully deliver software within that domain. Although I think this still is a lot off work (and challenging), focussing on one responsibility domain can help to reduce the complexibility. By the time I defined and implemented the artifacts for the first responsibility domain, Microsoft might be ready to provide me with the (stable) tools that make it (better) possible to write my own Domain Specific Language’s and support our Software Factory from within our development environment (VSTS).

The above are my first steps in the world of Software Factories. If any of you have a better approach to get familiar with this, please let me know!

Team Foundation Server provides the core functionality for integrating all of the Visual Studio 2005 Team System parts/tools. One of the services available in Team Foundation Server is the “Source Code Control Service”. This service makes it possible to interact with the core source control features of Team Foundation Server.

A very cool feature of the Team Foundation Source Code Control is the check-in policy framework it provides. This framework makes it possible to set validation rules (policies) that must be satisfied before the developer is allowed to check-in his code. By using this feature you can make sure unit tests are available (and run) for the piece of code or that the code meets the FxCop rules. Also this framework provides us with some extension points that we can use to write our own policies.  

Unfortunately the policy can be overridden by the developer but in this case an e-mail is send to our good old project leader. This will give him the possibility to make sure the developer sticks to the policy the next time. The main purpose of the check-in policy framework is to support some sort of a process that ensures a certain level of quality of the code that is checked in by the developers.

Two important principles related to this checking policy feature are: policy definition and policy evaluation.

Policy definition; (for the control freaks among us) in this process it is decided which rules must be satisfied before the developer is allowed to check-in his code. Policy definition is very likely done by the architect or lead developer on the team.

Policy evaluation; this is the process that actually validates a check-in of the developer against the policies that are defined

Policy definition can be done from within Visual Studio Team System. Policies can be set on a project base by using the Team Explorer. Policies can be added, deleted or edited for a specific project.

The policies that are set for a project will be evaluated while the user is interacting with the Visual Studio IDE. This makes sure that every time a developer checks in a piece of code it validates against the set of rules/policies. Every policy (represented by a plug-in in the policy framework) receives the necessary information to determine if the code meets the policy. The policy plug-in can return information that can be used by the policy framework to display messages the user why the code doesn’t meet the policy. 

If you want more control, it is possible to write your own policies. These policies can be used by the policy framework. Basically all you have to do is implement a few interfaces and there you go. One of the things to remember is that the new policy plug-in has to be installed on all the client machines that must apply to this new policy. Team Foundation Server doesn’t provide a mechanism for distributing policies yet!

To create a new policy plug-in you can simply open a new Visual Studio project to create one or more classes that implement the necessary interfaces. To create a policy the following interfaces must be implemented:

IPolicyDefinition; this interface exposes some methods that are used in the policy defining process. The information provided by the methods of this interface is displayed in the user interface that helps defining a set of policies (within the Team Explorer) for a project.

IPolicyEvaluation; this interface exposes methods that are used to evaluate if the code that is checked in meets the policy. Methods in this interface accept the content of the actual check-in so this can be validated against the rules in the policy.

The policy framework makes sure that all classes that implement the IPolicyEvaluation interface receive the following information when a file (fileset) is checked in:

• The check-in comment
• The currently selected list of files
• The currently selected work items
• The release note information

The policy plug-in can use all of this information to decide if the infoset satisfies the policy.

Al assemblies that contain classes that implement the above interfaces will be picked up by the check-in policy framework. It is possible to have more that one policy plug-in in one assembly. Before the policy framework can pickup new policies it must know were to look for policy assemblies. Fur this purpose we have the good old registry, that helps Team Foundation Source Control service solve this problem. All we have to do is store a value (location) for the policy plug-in under a special registry key. At this moment the name of the key is “HKEY_LOCAL_MACHINE \Software\Microsoft\Hatteras\Checkin Policies”and HKEY_CURRENT_USER \Software\Microsoft\Hatteras\Checkin Policies. This will probably change because “Hatteras” is the codename Microsoft is using for the source control system!

If you are interested in the extensibility possibilities of the Team Foundation Source Control system (or any other Team Foundation Server services) go download the Visual Studio Team System Extensibility Kit and have a look!

Now I am busy with Visual Studio Team System for a while I suddenly realize that working in IT projects can become real different when working with new tool. This makes me wonder, will IT projects ever be the same?

When we have a look at an ordinary IT project there are a few things that often go wrong. First of all we have the project leader, according to the development team the project leader is most of the time a pain in the ass. He isn’t really involved in the development process and most of the time the he isn’t even aware of what the system really looks like. All he cares is his excel sheet (or ms project file) that indicates if the development team is working hard enough to meet the deadline. To gather the necessary information to update his excel sheets he drops by in the project room once ore twice a week to have a quick talk with the developers. When things go wrong all he does is blame the development team. When the project is delivered successfully it’s the project leader that gets all the credits.

To stay out of trouble, the development team informs the project leader during their weekly status meeting that development is right on schedule and everything goes as planned. “Just a few more weeks of development before we can start system testing” the lead developer says, just to make the project leader feel good. At the end of the status meeting the project leader reminds the development team about “their” motto: Work Harder!

After the project leader left the room, the developers thank the lead developer for not telling the project leader they are a bit behind on schedule. The lead developer says it is no problem but also indicates that starting from now on everybody (including himself of course) in the team has to work a little bit harder to keep the possibility to actually meet the planning. This means a little less playing darts, browsing the internet and writing blog entries during working hours. They all have a laugh while making some remarks that if they don’t meet the deadline they will do some development work during the system testing phase that is about to begin. So, no worries yet!

This is actually the moment that the eyes of the tester are opened! Till now the tester was just one of the guys in the team. While writing “his” test scripts using his own set of tools (like word, excel and some SQL scripts) he didn’t really bothered the developers so he was totally accepted. Every time the testers has a question about some functionality he is writing test scripts for, the developers told him this piece of functionality isn’t implemented yet (but, almost done!). Therefore the only option the tester has is to base his test scripts on the functional requirements that the functional designer of the team put in a special folder for him on the server.

Having heard the developers say that they will use “his” testing time to continue developing makes the tester pissed. From that moment on he realizes he isn’t a full member of the team anymore and swears to himself that he will do everything necessary to find a lot of bugs. That will force the developers to work harder to keep the all mighty project leader happy.

In the meantime, in his constant battle to keep the users happy, the functional designer is working hard on his own set of the functional specifications. Just some weeks before the deadline he sends the final version of the specs to the development team. Of course without notifying that poor tester working hard to create all kind of test cases that will definitely fail during the system test phase that is about to start. When the lead developer reads the new updated specs he starts complaining about the functional specifications include new functionality that is not part of the initial planning. Of course it is possible to include this in the release but this will affect the available testing time. After a small talk with the project leader it is decided not to change the deadline. The project leader learned never to leave his project plan so he thinks changing the deadline is evil! Feeling the pressure of the project leader and the functional designer the lead developers decides to implement the new functionality within this release. Because there is little time left he doesn’t change the class diagrams and all other related models and documentation that were initially created by the architect on the project. There will be plenty of time for this when the project is finished!

When the new functionality is finally included in the system, there is almost no time left for system testing. Some quick tests show that there are some bugs in the system but because the lack of time they are all marked as “low priority” so they can be fixed in the next release (of course this frustrated the tester even more). While some of the developers are helping the tester testing the software, others are building the install packages. When the packages are finally ready they are handed over to the operations department.

During the installation of the software all kind of problems occur. The architect decided to use some cool new framework and technology that, strange enough isn’t installed on the production environment yet. After some discussion with the operations department and some minor changes in the code the software can be successfully installed.

The very proud project leaders informs the user that the software is successfully, and of course, according to the planning, installed. This is the moment the users has his first look at the system. Because of the small delay in the development phase there was no time left for user acceptance testing. Luckily the project leader and the functional designer convinced the user (based on the functional design and some models from the architect) that the team is building exactly what the user wants. After playing a few hours with the system however the users realizes that this software isn’t what he wants. The system doesn't corresponds with his day to day job at all. One of the good things about this is that because the system isn’t very useful for the user, he will not find the bugs in the system and the project leader gets is changes to solve these issues in the next release of this beautiful piece of software.

So, what will Visual Studio Team System change in all of the above?

Unfortunately VSTS cannot change anything about the project leader. The good thing is however that VSTS brings us a totally integrated environment. This will dramatically improve communication between the different types of team members. The new set of tools will help improving the overall quality of the software.  

First of all the architect can use the different modellers available in Visual Studio Team Architect to model his applications. Together with the models provided by the operations department he can test the deployment of his applications in a very early stage of the project, which of course saves a lot of time in the end of the project.

After that the architect can use the class designer to model his classes. These models can be used by the developers to generate the code from. If the developers make changes in the structure of the classes VSTS immediately updates the models, initially created by the architect. So now the models and software are always in sink, saving a lot of time updating the models at the end of the project.

When using the MSF agile methodology within Visual Studio, all tasks are related to work items, which can be assigned to team members. The Team Foundation Server gives the project leader a way to monitor progress on work items. Also very nice report can be generated from this data giving the project leader the possibility to impress his users even more. Fortunately Microsoft will provide a separate tool for “project leaders”so they don’t need to use Visual Studio for that. This saves them from becoming a real team member.

The next good thing from MSF agile is that is provides a more flexible methodology which leaves some space for making changes during the project, for example to react on changes requests of users.

The new integrated test facilities and some support for Test Driven Development try to enforce that there is always a “working version” of the software. Maybe only a small piece of functionality is available but it works (because it is tested!). This gives the user the possibility to drop by in the project room any moment and ask for a quick demo of the software. Because the user sees what the system actually looks like in an early stage it is much easier to monitor if this is what he really wants.

Because within VSTS testing is fully integrated within the Visual Studio environment, communication between developers and tester (and all other team members) will improve. The tester might even have some .NET experience to validate or write the unit test for the software. Further, VSTS provides tools to force Unit tests to be available before it is possible to store the code in the version control system. The tester can use these unit tests to immediately start testing the software (and not wait till the end of the project).

The fully integrated version control system allows the team members to store all project related documents, code, etc. in the “project repository” which might help different team members using different versions of specifications.

So where are we?

All of these and a lot of other features of VSTS help us improve the overall quality of IT projects we are participating in the very near future. I haven’t yet real experience with this tool but I think is has enough potential.

For all the people every worked with me on a project:

Of course all of the above isn’t based on my own experiences. This is just what I heard from colleagues! I do like project leaders! For me Visual Studio doesn’t actually change anything in the projects I am participating in. The only difference is that when using Visual Studio Team System I have a totally new and cool tool to deliver these very successful projects to our clients!

To help developers (projects) deliver robust, industrial strength code, Microsoft's created her "defence in depth" strategy. This strategy aims to test for bugs at every stage in a project, aiming to catch them as early as possible. Microsoft thinks this can be done by:

•Unit testing, to test the basic functionality of every method

•Code reviews, to analyse code for coding errors prior to checking it in

•Frequent builds, to make sure that no changes have broken the application

The good thing about Visual Studio (Team System) 2005 is that it helps projects delivering quality code by providing a new set of tools.

 Let us look a little bit more to the new testing features of Visual Studio Team System:

Unit testing

Visual Studio 2005 not only includes a set of tools that better supports testing; it also supports the Test Driven Development (TDD) methodology. This methodology lets tests drive the production of code, ensuring that tests reflect what the code is supposed to do and that all methods in the public interface are tested.

Some of the essentials of TTD are:

• tests reflects the specifications and are written before any code that implements the requirements
• The aim is to pass the test
• Once all the tests are passes, the code is complete

One of the good things about unit tests is that it provides the possibility to execute regression tests during the life cycle of the project. This makes it fairly easy to ensure a change to one piece of code didn’t break any other piece of code. Another advantage of writing unit test (before the actual code!) is that this improves the overall design of the software. When using TDD, tests are always written before the code itself. The first time only a stub is created just to satisfy the compiler for the test. After that the body (implementation) is written of the code that is tested just until the test passes.

After the unit test passes, there is time for any refactoring of the code (if necessary) to improve the design.

TDD aims to create tests during development and not at the end of the project (if there is time left)

To make writing unit tests easier and more common, Visual Studio 2005 provides a unit testing framework out of the box. For those of you working with NUnit in the past, this framework will look very familiar. (Of course this is purely based on coincidence and has nothing to do with the inventor of NUnit now working for Microsoft.)

This unit testing framework is available in both the Team Developer and Team Tester of Visual Studio so unit test created by developers can be executed by the testers in the team. The testing framework and testing tools are fully integrated within the Visual Studio IDE so testing can be done without leaving Visual Studio.

When using Team Foundation Server (TFS), all gets even better. TSF integrates activities of the developers and testers; testers are notified when a developer checks in a piece of code (of course with the necessary unit tests!) and developers will be notified when the testers encounter a bug in the code. Without using TFS it is not possible to check in unit tests and test results cannot be stored in the projects repository.

When using the unit test framework within Visual Studio all test classes are stored in a separate assembly (at least this was what I found in the December CTP of VSTS). Personally I like the “strategy” of Enterprise Library a little better. Within Enterprise Library all test classes are provided within the implementation assembly. All in a separate folder within the project called “.Tests”. Maybe there is a very obvious reason to store the unit tests in a separate assembly but I haven’t found one yet.

The good thing is that there is a Test Explorer available within Visual Studio that makes it very easy to run a set of tests. This tool makes it even possible to only execute one or more categories of tests.

Another new and very useful feature of Visual Studio Team System is the integrated code coverage. This makes it very easy to validate if the unit tests for a piece of code cover all code paths. The actual Code coverage can be displayed in a percentage or within the code editor itself.

Knowing that Team System makes it possible to reject code that isn’t covered by unit tests for at least ‘x’ percent, it becomes more and more difficult to produce poor code!