describe the purpose of system implementation;
evaluate different changeover methods: parallel, direct, pilot and phased;
describe the different types of documentation: user documentation and technical documentation, and explain how they are used;
explain what is meant by data conversion;
describe the purpose of system maintenance; and
evaluate different forms of maintenance: corrective, adaptive and perfective
Implementation is used to describe the process of creating a working computer system based on the previously produced system design documentation. Programmers will produce the code from the project requirements and specifications. While the design might include systems diagrams, the creation of interface designs and specification of verification and validation techniques to be applied to data as it is being input; the implementation process refers to the process of putting the design elements into practice.
Past Paper Question (2024)
In the waterfall model of systems development, the Systems Design stage is followed by the Implementation and Testing stages.
Describe the purpose of the implementation stage [4]
Programmers … produce the code … from the project requirements … and specifications
4 × [1]
Evaluating Changeover Methods
Following the design, implementation and testing of a new information system a changeover from the old to the new system must take place; this allows the information system to be tested in a real life scenario if necessary.
This process of changeover can be approached in a variety of ways depending on the size of the system and the nature of the data being processed.
The methods of changeover include:
Direct
Parallel
Phased
Pilot
In this instance the old and new system will operate side by side for a short period of time, until the new system is proven. Lowest risk strategy.
The results of the original system are available for comparison / Training Purposes.
Old system is available as backup in event of new system failure.
Duplication of resources such as hardware / personnel.
Increases workload for staff as all items must be processed in duplicate.
There is duplication of effort/cost/time.
This method involves discontinuing use of the old system and immediately replacing it with the new system. There is no overlap between the old and new system. Highest risk strategy.
The new system is up and running immediately, no additional costs associated with duplicate processing of data or dual systems operating.
No duplication of effort/cost/time.
No means of comparison of output between old and new system. (However, in some cases this may be the only option available during the changeover process).
No backup in event of failure of new system
In this instance some parts of the system will be replaced by the new system while the remainder of the system continues to operate using the old information system. In this way a part of the new system is used and when it has been proven, another part of the system is implemented and so on.
Supports gradual installation of new system and staff training (allows time for end user to become familiar with the new system).
Less risk than direct changeover since it allows for a ‘grace period’ when the old system can still be used if the new system has problems.
If system failure occurs in the transitioned phase no backup system is available to staff.
Similar in many ways to phased implementation, but only some data from the old system is processed by the new system. The new system will operate alongside the old system, but only processing part of the data. The new system may be tried by part of an organisation e.g. a single branch. If proven it is then introduced throughout the organisation. Medium risk strategy.
Data processed by the old and new system is available for comparison.
Staff involved in the operation of the pilot system can help with the dissemination of training to other staff members.
Cannot test the efficiency of the system with larger quantities of data.
It can be difficult to identify an appropriate section/department/partition of data for the pilot
There is duplication of resources/effort
User and Technical Documentation
All systems will be provided with a series of documents used to support the planning and development and maintenance of the system in addition to supporting the end user as they use the system. Some programmers may spend as much as 80% of their time writing documentation.
User Documentation is non-technical documentation written for the end user as a reference guide on how to use the software.
It is aimed at non-ICT specialists.
User documentation provides the user with all the information they need to support them in the successful use of a piece of hardware or software.
It may not include a lot of technical detail as the users tend to be non-technical.
Contents/Components of User Documentation:
User guide
Operating instructions
Installation guide
The minimum HW/SW requirements
Help/troubleshooting/FAQ support
Training materials/tutorials
User documentation can be disseminated (distributed) by the following methods:
As printed manuals.
As online documents.
As help files built into the system.
Technical documentation describes how the system works rather than what it actually does. While user documentation is written for the end user, technical documentation is written for the professional involved in the design, implementation, testing and eventual maintenance of the system. Technical documentation is vital; since understanding programs written in the past can be difficult even for the original programmer and even harder if they are not present to explain the code.
Contents/Components of Technical Documentation:
System specification/module specifications/user requirements
Design components – DFDs, ERDs, storyboards, flowcharts, pseudocode/data dictionaries/IO formats/menu structures
Database structures/tables/queries/reports
Program documentation/purpose/listings/code/restrictions/IO formats
Test plans/test schedule/test data/test results/test schedule
Hardware and software configuration/specification/ requirements
Data conversion is the process of converting or transferring data from the old system to the new system.
For some systems this could mean the input of data from paper based records to electronic format for storage on a database system.
In other cases it could mean the complete migration of an entire database from one application to another.
The process will normally involve both software and human intervention and great care is needed to ensure all necessary data is converted correctly in the process.
Past Paper Question (2023)
4 (a) Data conversion may have to be carried out during the implementation of a new system.
(i) Explain what is meant by data conversion.
Data conversion is the process of transferring data …
from the old system to the new system
2 × [1]
(ii) Explain how data conversion will be carried out when a manual information system is replaced by a computerised system.
Data is taken from existing documents
...such as forms/reports/invoices/orders
The data may need reorganising for new database structure, e.g. tables created/modified
The database structure is created on the system
Data is keyed in/transcribed
... and verified/validated
The database tables are populated with data
4 × [1]
Past Paper Question (2018)
3 (c) Explain why data conversion may be needed for a new information system. [2]
The way in which existing data is structured/stored does not match the way in which it will be stored in the new system Example: different data structures/different file formats/different tables/ different attributes/existing paper-based records
(2 × [1])
Systems maintenance forms an important part of the development process. System maintenance is the process of ensuring that the system continues to run smoothly following implementation. Maintenance is carried out regularly to ensure the system meets the changing requirements of the organisation.
Types of Maintenance
Addressing needs not previously identified, eg due to changes in circumstances
Errors/Bugs have been identified when the system is in use and these need to be corrected/fixed
The system must be retested
Additional/new functions must be added
The environment within which the system is used has changed/ the user’s requirements have changed ...
for internal reasons/new business requirements ...
for external reasons/ changes in legislation
Amendments to improve the performance of the system
Code can be made more efficient … to improve response times
More up-to-date hardware/software can be installed