Natural Sequence of building Software System

Structured Approach, Object-Oriented Approach, Agile Approach, Waterfall Model, Spiral Model, SSADM, RUP, ...

There are so many different approaches, methodologies, models or whatever name you choose to call it. They are basically different approaches, adaption or implementation of the natural sequence to develop a software system.

Let's put aside the software hats that we have been wearing. When we start to build something, we would ask, "What am I going to build?" The something could be as clear as a map of your street or as vague as an idea in the cloud. No matter what, you need to know what do you want before you can build something. You may argue that I have absolutely no idea on what is the "something" looks like finally. But, you cannot deny that you must have some level of understanding of what you want before you can ever start. This thing is basically called "Requirement". For example, you may want to have something that can take you from place A to place B. So, your requirement is "Something is required to be capable of taking you from place A to place B".

Once you know what you want, you would want to work out how to realize what you want. In addition, there may be all sort of limitations and/or constraints. Finally, you work out an idea that can achieve what you want within the limitations and/or constraints. This is your "Design" or "Solution". For example, there may be an ocean between the places A and B. Therefore, you need something that can either fly or carry you across the ocean. Then, you decide to build a plane. Whether this is the best option or not is outside our discussion of this topic.

Now, you know it is a plane that you want to build and start throwing resources into building it. You start the "Development" activities. There are many important activities in building a plane. But, again, it is outside our topic in discussion.

Upon completion of the plane, you would want to "test" it out before you actually fly in it from place A to place B across the ocean.

When you have gain adequate confidence that the plane does what you want, you set to fly in your plane from place A to place B across the ocean. This is "Implementation".

From the above, we could see that the natural sequence of activities of building generically anything. That is,

1. Identify or define requirements;
2. Design a solution;
3. Construct the solution;
4. Test the solution build;
5. Put the solution in use.

This is what I call the natural sequence of building a system. A system is of no different to the "something". In fact, it is one of the many elements in the set of "something". Therefore, this natural sequence is applicable when we come to build a software system. If this natural sequence is correct, why would we have so many different models, methodologies, approaches, etc.? The answer lies in the limitations and constraints that we have in building the system. To name a few,

1. Availability of budget is limited;
2. Availability of experience people is limited or absent;
3. Availability of time is limited;
4. Rules from the regulators;

and the list goes on...

To resolve these limitations, different approaches of applying this natural sequence would be required. However, that does not affect the basic and natural sequence. Throughout our working live, we must have experienced at least some projects that try to skip some activities, especially requirements and/or design. Some failed miserably while others managed to meet required wants through remedial activities. None can actually bypass this sequence and succeed. Therefore, we could conclude that the natural sequence of developing a software system is:

1. Defining requirements (Requirements);
2. Design solution (Design);
3. Construct solution (Construction);
4. Test solution (Testing);
5. Implement solution (Implementation).

Sounds like the waterfall model. Yes, it does but its more fundamental.