Implementation |
Implementation is using appropriate software packages to create the system you have designed. Often students spend far too much time on the implementation. They naturally want to make their system look and operate in as professional a manner as possible. And of course the implementation is by far the most interesting part of the project. But it is a mistake to spend lots of time working on the implementation and neglect the other stages of the project. Remember in most cases the implementation is worth less than half of the marks for a project.
When implementing a system it makes sense to implement the most important parts first.
During the implementation you need to collect evidence to show how the information system was created. If you decide to make any changes from your design then you will need to explain why the changes have been made.
You will not need to do this for your coursework, but if your were producing a system for a real company the last part of the implementation would be to set up the system at their premises for them, manage the changeover from any existing older system to the new one and train staff to use it.
During the implementation stage you need to collect evidence of the work you have done. You need to show that you have used the software packages with a good degree of skill and understanding. You also need to demonstrate that you have solved the problem in an efficient way.
To do this you must obtain printouts of all of the different parts of the solution to the problem. You then need to annotate (write on) these printouts to explain what they mean. An unexplained printout is a waste of paper.
The sort of evidence that you need to obtain will depend upon the task you are working on. This table gives some ideas of what evidence it might be useful to include for a variety of different types of task :
| Type of Task | Useful Printouts |
| Database | Data collection forms. Lists of data entered into the database. Validation checks used. Example reports / queries. |
| Spreadsheet | Spreadsheet including test data. Spreadsheet showing formulae used. Macro sheet listings. |
| DTP / Word Processing / Graphics | Printouts of pages annotated to show where functions such as
centering,
tables,
fonts etc. have been used. Justification of choice of clipart etc. Data files used for mail merging. |
During the implementation stage you need to get printouts of your work at various levels of development. This will demonstrate how you have developed your information system. The evidence you produce during the testing stage should be sufficient to demonstrate that your final version has been implemented properly.
Never throw any printouts you obtain away. You may find later on that they would have provided useful evidence.
During the implementation you will probably find that you need to change your design :
There is nothing wrong with modifying your design part way through implementing the system. If you do this then :
If your were implementing a system for a real company then once you had created it you would need to install it at the company's premises. If your new system was replacing an older existing system you would need to decide how to carry out the changeover from the old to the new system. Data that was stored in the old system may need to be transferred onto the new system (possibly using a standard file format).
If the system you created carried out an essential task for a company then they may be reluctant to simply give up using their old system and replace it with a new one until they were convinced that the new system worked properly. One of four different changeover methods might be followed :
| Method | Description |
| Direct | The old system is scrapped immediately and completely replaced by the new system. This requires minimum effort, but if there are any problems with the new system the data in the old system will not be up-to-date so it will be hard to return to it. Return to the old system would be harder still if the hardware it used was removed. This changeover method is most frequently used on systems that are not essential to the running of a business. |
| Parallel | Until it is decided that the new system works correctly the new and old system are used together. Every time a transaction occurs (e.g. a sale) it is entered into both systems. This is very time consuming but if there are any problems with the new system they can be easily identified by comparing the output of the two systems. It is also easy to revert back to using the old system if the new system does not work as all the data in it will be up-to-date. |
| Phased | The new system is tried out on a small scale to see if it works. For example a supermarket might introduce a new stock control system at just its Bury branch. At the other branches the old system remains in use. When the supermarket is happy the new system works the old system will be gradually replaced at its other stores with the new system. Any problems that occur would only affect the store(s) that the new system was being tried at. |
| Pilot | The new system is run alongside the old system, but only processes some of the data. For example a supermarket might try out a new stock control system on one till in a store, with all sales at this till being recorded by both the old and new systems. Sales at this till may take longer, but the amount of effort required is less than that for a parallel changeover. The results produced by the two systems can be compared to see if the new system appears to work. As the new system is only being used with a small amount of data, problems that might result from processing a realistically large volume of data might not be noticed. |
For a new system to be effective, staff must be trained so that they know how to use it. Without training staff are likely to make mistakes on the new system and will not know how to exploit the new features it provides. Training can be provided to staff in many ways :
GCSE ICT Companion 04 - (C) P Meakin 2004