Software factory for dummies

I haven’t written here for a while because I was involved in a job not related directly to ASP.NET development. In fact, I was consulting a small company to build up a software product line based on a standard software development process (i.e. MSF) and industry best practices. 

The job urged me to write something about how to build up a small software product line or how to work on a software project following standard guidelines. It may be hard to believe, but I personally have seen a lot of companies, in various sizes, that do not have any strategy for their configuration management, requirement management and so on. Especially, small businesses suffer from this issue a lot but most of them frequently change their developers because the manager believes that developers do not work well! Some other ones know about the importance of having a well defined software development process but believe that they can’t afford the cost of hiring consultants or purchasing the tools. This post will show you up that software development can be organized perfectly with minimum cost and a little effort. 


Begin with Standards

Whether you are going to launch a new project or you are maintaining an old application, you need some standards for coding conventions, database naming, coding principals, testing and so on. If you do not have any standards, the code your developers write will be very hard to understand and hard to maintain by other ones.  Naming standards also can help you develop some automation tools because you can assume that some conditions are always met. For example, you can always be sure that the primary key field of each table is named “ID”.  Standards should be granular, clear and short as much as possible. A very long and dense standard document is very hard to read, memorize and understand. For example, create some standard documents for the following subjects: 

  • C# (or other language that you use) naming conventions
  • Database objects naming conventions
  • UI standards
  • C# design and coding standards and guidelines
  • Database design standards and guidelines

It is very important you supervise that standards are always followed by team members. There are several tools that you can use to check if standards are correctly used. For instance,  StyleCop can integrate with Visual Studio and analyze source code for specific conditions. See  this link for more info: http:// 

It is highly recommended to create coding and other standards with cooperation of all team members. There are also several web resources about coding and design standards that you can refer to. Something that I personally did was to download and study some sample source code from Microsoft website and checked to see what kind of naming conventions have been used in them. 

Setup a domain for your office!

It is recommended to have a domain-based internal network for your office.  Without a domain you can not control the software or servers you setup. Big organizations often setup a domain, or a secondary domain, for their software development  section. 

Setup an internal mail server

The office I told you about, the one which I worked on the promoting their software development process, used to exchange their internal documents or messages thorough external email accounts (i.e. Gmail) . There is no point in sending internal valuable information included in internal documents out of the company! Therefore, it is much better to set up an internal email server, i.e. Microsoft Exchange Server, and use it for internal communications. If you don’t have money (!) , setup a free pop3 mail server like hMail , or even use Windows 2003 POP3 service for simply send/receive emails. 

Use Source Control

Never ever develop source codes in an uncontrolled environment. Even a single developer, should use a sort of soruce control program. For example, if I modify a .cs file and damage the code for some reason, with a source control program, like SubVersion, I can rollback the changes.  For small to medium projects or offices, I recommend to use SubVersion, which is a free source control program that supprots many important features like versioning and branching. If you have several product lines, projects and you have money! , I highly recommend you to install and use Team Foundation Server. TFS has great features for pushing a software development process, including a source control system. The default TFS client is Visual Studio (Team Explored) but there are other 3rd party clients so that if you are not using .NET , you don’t have to forget TFS. 

Apply a standard software development process

There are several software development processes that have their pros and cons. Overally  the value of each one is revealed due to the context of your projects, the size of your company, your budget and etc. If the size of the company, the size and number of projects and the number of people involved are too many, you are highly recommended to choose a SW development process that complies with CMMI, like RUP and MSF. CMMI is a kind of standard/framework for software development process and has five levels. If you manage to install and supervise a CMMI-matching process completely with constant improvements, you are likely to be a CMMI Level 3 ! 

I personally prefer MSF (Microsoft Solution Foundation) since despite RUP, which is extremely comprehensive and suites large organizations, MSF has different versions for Agile software development and CMMI improvement that takes you from CMMI Level 3 to Level 5 seamlessly. Also, Team Foundation Server works based on MSF-based processes so that you won’t need to think about a software to make the process running. 

MSF is actually a framework that let’s you design and customize your own MSF-based process. Therefore, you can create a process that best matches your needs, create custom process templates and build your project portal based on it.


Regardless of the process instance you chose for your company, you should be aware that you take the following subjects into account:

  1. Business Modelling: Begins from the first time a customer contacts you. The act of receiving the needs and requirements, analyse them and giving feedback in form of a Vision document is called Business Modelling.
  2. Requirement Management : It means how you get your customer’s and business analysts’ needs, discuss and filter them and send them to development team. This stage can be mixed with Business Modelling under circumstances in which time and budget are too tough.
  3. Analysis and Design: This stage is my favorite and (in my opinion) the most important part of a process. In this level requirements are received, analysed into details. Based on the output of the analysis software design is performed. In agile methods it is very common to omit the design part or blend the two. At a minimum level Use Case (or whatever they are called in your process) of important / major requirements must be modeled.
  4. Implementation: this step includes coding, unit testing etc. Before getting involved in implementation all your standars about checkin/check outs, change management, coding & testing & other standards etc must be cleared.
  5. Configuration & Change Management : How your source codes are maintained, how you grant or deny access to users, how you organize different branches of source code and …. For example if you release first version of a product, you label and call it “1”. Then until you release the 2nd version, you create a branch called “2” for service packs. New features are added to “1” but urgent changes and bug fixes are performed on “2”. When you are ready to release the 2nd version you merge “1” and “2”. Change management is responsible of receiving the change requests from the customer and manage them. Usually a team called CCB decides about which requirement should be implemented and when.
  6. Project Management : How you assign tasks, plan your project, keep the track of time, manage closings etc.
  7. Testing : What tests are performed, when and how? 
  8. Deployment :  Also called Release Management. Tells us how to prepare deployment environment, how to build deployment packages and etc.

If you are not going to have a software factory and there will be only a few projects to work on, you are invited to use more lightweight agile methods such as XP and SCRUM. Unfortunately in many cases being agile is intepreted as having no process and no standards. This ends to a product with no proper testing, no documentation and no versioning.

 Always put your customized document templates somewhere accessible to team members with sufficient privileges.


Launching a development team requires some concidetations, no matter your project or company is too small or too large. In this post I poited to some of them and told you how to do something urgent about them.


One thought on “Software factory for dummies

  1. very nice post man!
    It seems that you are sharing your previous experience..
    please do not hesitate to tell us more.

    Thanks a lot. Yes, Whatever I learn and what seems to be useful for others is shared by me. Please check back again 🙂

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s