REA..with the traditional way and its flaw

The above model is how IT world works for many years, which have proven working for many organisations, including REA.

I am not going to talk about how it works but will talk about how it does not work instead. It is actually not the flaw of the Waterfall model, but the way REA adapting the model.

This is the phase that is normally being taken short cut or even skipped. This caused a lot of problems found later in the development phase that is expensive to fix.

The way the design was done was writing Technical Overviews. TO provides a good guideline on how to implement the system but this does not look at the entire system from a broader view or architectural level.

Without good design, design is normally based on TOs which are derived from functional requirements.

This way of implementation will be able to meet users requirements, however, does not mean that the system will be easily maintainable, portable, extendable, secure, etc.

Thus, budget and time normally overflow in this phase.

Due to project deadline and overflow from implementation, verification is normally the most painful phase.

In order to rush products into market, buggy features are taken out instead of being fixed properly, short cuts are being taken, etc. All these pretty obvious are not good practice in software development.

Maintenance is normally quite expensive if new features are to be changed or added due to poor design.

As a summary, the old way REA was working was quite painful to work in. Quality and quantity of products produced were also not much of a happy case…..