A fairly common problem with system development is that there may be a very long delay from when the idea of a new system is first suggested to when development begins. This is especially the case with large complicated systems.
Moreover, some users may find it difficult to imagine the system from a proposed paper design. They would much prefer to see something real in front of them.
One practical way of overcoming these problems is the concept of 'prototyping'.
A prototype represents some aspect of the full system - for instance a mock-up of the graphical user interface.
Consider a prototype GUI, where users click on command buttons and see its effect. That button is not actually connected to a real system but is programmed by the developer to act as if it was. The command action is simulated with dummy data.
Now the user is beginning to see how the real system will work before the developer spends even more time on it.
So a prototype is NOT a fully working system but it does provide an opportunity for the user to give feedback and suggestions for improvements. This may happen again and again until the full details are agreed between developer and user. Therefore prototyping is an 'iterative' process.
Any changes required are fed back to the developer and the Requirements Document is also updated every time a change is needed.
It is much cheaper to build a prototype and iron out the problems rather than go straight into the development of the main system and then find out there are problems.
There are two main approaches to prototyping, namely:
- 'Evolutionary Prototyping' and
- 'Throw-away' prototyping.
Each has advantages and disadvantages which will be discussed in this mini-web
challenge see if you can find out one extra fact on this topic that we haven't already told you
Click on this link: Business Analyst