The systems lifecycle can be approached in many different ways. All of the methods use the same basic ideas of requirements, design, implementation and testing. For this course you need to understand just one of them and that is the waterfall model.

The above diagram shows the waterfall model. It is so called for its distinctive steps and the idea that water can flow down the steps which represents the process of going from one phase to another. Basically each step is done then we move onto the next. What is not so obvious is that we can actually move backwards to any previously visited phase at any time.

At the end of each phase the deliverables of that phase are tested. If the results do not meet requirements or if any problems are found with the deliverable then the project must stop and go back to where the problem can be solved. If testing is not done at the end of each phase then a problem may persist all the way to the maintenance phase. At this point the cost and time required to solve a problem is much greater than lower down the model. This is why we can go back in the waterfall model.

Consider an example. Joe owns a company which makes springs. He has asked for a new system which can sort and package his springs automatically. Unfortunately he forgot to mention that the springs could be made of different materials which mean that the same type of spring could be different weights. This problem was not spotted until the system went live. Joe then asked for it to be fixed and he was told that they would have to redesign a huge part of the system and would cost at least 40% more than planned. Joe does not have the extra money and as such is stuck with a system which he can not use but cost him a huge amount of money to make.

We may not be that sympathetic to Joe. However, his situation is a common one but one which can be avoided. By going over each phase to ensure they are correct before moving forward this sort of problem could have been avoided. We do have a testing phase but that does not mean that is the only place we do testing. How can we know there is a fault with our design if we do not do some testing on it?