Please enable JavaScript.
Coggle requires JavaScript to display documents.
UNIT 7 - Coggle Diagram
UNIT 7
IMPLEMENTATION
Direct: With this method, the old system is stopped overnight, and the new system is introduced immediately
-
- This method can be disastrous when the new system fails since the old system is no longer available.
- the benefits are immediate
- less likelihood of malfunction since the new system has been successfully tested.
Parallel: With this system, the old and new system is run side by side for a time before the new system completely takes over.
- If the new system fails, the old system is still available for backup
- It is possible to gradually train staff
- It is more expensive than direct since extra staff is needed to run both system
- it is more time consuming because the data must be entered into both system
Pilot:The new system is used in one branch or office of the company and its performance is assess before being introduced to other parts of the company
- if the new system fails, only one part is affected while the remainder part is unaffected
- It is possible to train staff in one part, which is faster and less costly than parallel
- The cost is less than parallel because only one part of the new system is being used in pilot
Phased: A part of the new system is introduced to see if it works satisfactorily. If the system works satisfactorily the next part is introduced and so on until it takes over the old system.
- Failure is not disastrous
- More expensive than direct since each phase must be evaluated before moving on to the next stage
- very time consuming since each part must be thoroughly evaluated before making any further changes.
- It is possible to ensure the system works properly before expanding.
EVALUATION
Once a system is up and running it is necessary to do some evaluation and carry out any maintenance if necessary. The following is a list of some of the things considered when evaluating how well the new system has worked
- compare the final solution with the original task
- identify any limitations of the system
- identify any necessary improvements that need to be made - evaluate the user's responses to using the new system
- compare test results from the new system with results from the old system.
- compare performance of the new system with performance of the old system
- observe users performing set tasks (compare old with new).
- measure the time taken to complete tasks (compare old with new)
- interview users to gather responses about how well the new system works
- give out questionnaires to gather responses about the ease of use of the new system.
-
-
DEVELOPMENT & TESTING:
Software is often developed in modular form. This method allows the data to be broken down into smaller parts known as modules. The module is tested separately by a programmer to see if it functions correctly. Any problems resulting from the testing required to be modified and then tested again.
The system is then tested once the development of each module is complete. This is to see if there are any data clash or incompatibility, memory issue etc. when put together although each module work satisfactorily.
Types of data:
Normal data: data that is acceptable/reasonable and has a known outcome. For example, one of the fields in a database is the date in the form of dd/mm/yy. The month can be any whole number in the range 1 to 12
Extreme data: this is data at the limits of acceptability; for example, the values of the month can be either 1 or 12.
Live data: data with known outcomes. Live data is entered into the new system and results is compared with those produced from the existing system.
Abnormal data: this is data outside the limits of acceptability, or the wrong type of data should be rejected or cause an error message. For example:
-
-
-
-
DOCUMENTATION
Once the new system is fully developed, a considerable amount of documentation also needs to be produced for:
- the end-user
- people who may need to modify or develop the system further at some later stage
User documentation: it is designed to help users to learn how to use the software or system. This can consist of any of the following:
- how to load/install/run the software
- how to save files
- limitations of the system
- the purpose of the system/program/software package
- error handling/meaning of errors
Technical documentation: is designed to help programmers/analysts to make improvements to the system or to repair/maintain the system.
- program listing/coding
- programming language used
- program flowcharts/algorithms
- system flowcharts
- purpose of the system/program/software
- limitations of the system