Consider the ubiquitous traffic light system. It is one system that most people take for granted. It is always expected to turn green, amber, red, green, amber, red, etc. By observing this simple rule of green to go, amber to get ready to stop and red to stop, traffic flows smoothly. But, when the system fails, chaos prevails.
Order at the traffic light junction comes about because of one reason: Drivers obey the rules - green to go, amber to get ready to stop and red to stop. When traffic lights go out of order, this rule becomes invalid; the intersection should be treated as an all way stop. Each driver is left on his/her own to decide when it is their turn and safe to cross the junction. The situation at the junction becomes informal and difficult, resulting in chaos.
Software systems development is very much like the situation at a traffic light junction. Many people of differing skill-sets and interests are involved in the process. Without set rules, each developer imposes his/her own interest on the project. When problems occur, they become difficult to resolve.
The rigor of a software development project is achieved by setting rules into the process. Every person involved in the project has to observe the rules. With rigor, a project can carry on smoothly without hindrances. However, when projects are lacking in rigor, they are doomed to run into problems and fail, resulting in unreliable products, high costs, and time overrun.
There are various degrees of rigor. The highest level of rigor is formality – a situation where software systems can be verified by mathematical laws. Automated testing and error removals are possible. Much research has gone into applying formality in software development. A branch of Software Engineering research known as Formal Methods has been well debated and discussed in numerous Software Engineering conferences. However, practical application of formal methods has been limited.
