Introduction

The concept of a system emerged from early psychologists who believed that the mind was a whole unit, rather than a collection of psychological parts as the belief was by that time. However, it was Ludwig von Bertalanff, a German biologist, who gave the name “general systems theory” to the discipline that devoted itself to coming up with principles that apply to all systems.

A system is a set of organised components which interact in a given environment and within a specified boundary to achieve collective goals and objectives that are emergent. Emergent characteristics are those that result from interaction of various components and may not exist in the individual component. Therefore, once the components come together, they become interrelated and generate new goals and objectives. For example, a bicycle system has all the components working together to provide motion when ridden. The individual components cannot provide these services to a rider when on their own!

 

Description of a system

A system can be described as being either soft or hard.

Soft systems

Human activity systems are said to be soft systems. They are described as soft because of three main reasons:

1. Their boundaries may be fluid or keep on changing.
2. Their goals and objectives usually conflict and may not be captured clearly at anyone time because they are based on human factors like attitudes and preferences.
3. It is difficult to precisely define exact measures of performance for them.

One example of a soft system is the political system. It is very difficult for instance to model a system that will predict the political mood in a country over a period of time. Another example is a sales tracking and prediction system in an organisation. Sales in an organisation depend on human factors like attitude in the market place.

Hard systems

Hard systems are systems whose goals and objectives are clearly defined and the outcomes from the systems processes are predictable and can be modeled accurately. Such systems are based on proven scientific laws like mathematical formulas or engineering solutions.

An example of a hard system would be a stock management system in a supermarket. It is possible to know exactly the stock levels, cost and sale price and to predict accurately the profit if all the stock is sold.

A good system incorporates both hard and soft aspects of a system. For example, a stock management system should be able to show when the demand for a certain item rises so that a decision can be made to stock more. New demand is driven by soft aspects in people’s lives like attitude and seasons!

Characteristics of systems

All systems have some common characteristics. Some of these characteristics are explained below.

Holistic thinking

In holistic thinking a system is considered as a whole. Aristotle, a Greek philosopher, once said that the whole is more than the sum of the parts. The various components that make up a system may be simple in nature and process but their combination creates a complex whole, whose overall goals are more sophisticated than those of the individual components. Hence, a system should be considered as a whole unit rather than considering its parts individually.

 

Subsystems

A system is made up of different components (subsystems). Therefore a system does not exist in solitude but it may be a component of larger a system. For example, the classroom system is part of a school system, which is part of the Ministry of Education. The Ministry of education is part of the Government which is part of the global system!

Boundary and environment

Each system has a space (boundary) within which the components operate. Any entity that falls outside the boundary but interacts with the system is part of the system environment. Such entities are called external entities. They provide the inputs and receive the outputs from the system. For example, the external entities to a school system may include the parents, various suppliers and the society at large.

Purpose

The purpose of each system is to perform a particular task or achieve a goal. The objectives that a system is supposed to achieve enable system developers to measure the performance of a system during its operation. One main objective for a school system for instance is to enable the students to excel in national examinations.

Process

A system usually will transform or process data from one state to another.

System entropy

The word entropy means decay. Systems “decay” naturally over time. This means that a system slowly becomes useless to the user either due to improvement in technology, new management

policies or change in user requirements. Therefore a system must be reviewed in order to improve it or to develop a new one.

Inputs and outputs

A system communicates with its environment by receiving inputs and giving outputs. For example, a manufacturing firm can be considered as a system that gets raw materials (inputs) from the environment and transforms them into finished products (outputs) released into the environment.

Open and closed systems

A system can be described as being open or closed. An open system receives input from and gives output to the environment while a closed system does not. Open systems normally adapt to changes in the environment.

Control

Control can be defined as the method by which a system adapts to changes in the environment in order to give the expected output or to perform to the expected level. Control is achieved through feedback which involves having outputs from the process of the system being fed back to the control mechanism. The control mechanism in turn adjusts control signals that are fed to the process which in turn makes sure that the output meets the set expectations. Fig. 4.1 depicts a typical system that has feedback to the control function. Imagine a motor vehicle manufacturing company that is producing several vehicles per day. Assuming that the demand rises, then feedback would show that the company is underperforming. Hence, control signals that would speed up movement of units on the assembly line can be issued to increase production.

 

Information system

An information system is an arrangement of people, data processes and information that work together to support and improve the day-to-day operations in a business and the decision making process. The main purposes of an information system in an organisation are:

1. Supporting information processing by enhancing tasks such as data collection, processing and communication.
2. Helping in decision making by collecting operational data, analyzing it and generating reports that can be used to support the decision making process. This process is referred to as on-line analytical processing.
3. Enable sharing of information. Perhaps, this is one of the greatest powers of information systems. For example, any departments in a given organisation can now share the same electronic information stored in a central database at the click of a mouse button.

 

Why develop new information systems?

The need for developing information systems is brought about by three circumstances:

1. New opportunities: A chance to improve quality of internal processes and service delivery in the organisation.
2. Problems: These are undesirable circumstances that prevent the organisation from meeting its goals.
3. Directives: These are new requirements imposed by the government, management or external influences.

Role of information system analyst

A system analyst is a person who is responsible for identifying an organisation’s needs and problems then designs and develops an information system to solve them. The system analyst does this by:

1. Reviewing the existing system and making recommendations on how to improve or implement an alternative system.
2. Working hand in hand with programmers to construct a computerized system.
3. Coordinating training of the new system users and owners. P

Project management

The system analyst is the overall project manager of the information system being implemented. His project management skills like assuring quality, keeping within schedule and budget determine whether the system will be successfully implemented or not. For example, a project that does not stick to its schedule will most likely overshoot its budgeted cost leading to unsuccessful completion.

 

Theories of system development

Several theories or methods are used in system development. The aim of all these theories and methods is to identify business requirements and to develop information systems that effectively meet them. This helps to support the day to day operations and decision making processes in an organisation.

Some of the most common system development theories include:

1. Traditional approach.
2. Rapid application development (RAD).
3. The structured approach.

At this level, we will concern ourselves mostly with the structured approach. However, we shall briefly discuss the other two methods of system development.

Traditional approach

Traditional approach relies mostly on the skills and experience of individual staff members carrying out the project. This means that there is no formal documented methodology to be followed by all system developers in the organisation. This obviously presents a chaotic scene in system development especially where more than one persons are involved in the development effort. In most cases, success depends on the heroic efforts of an individual. This means that all other projects heavily rely on a particular person for their success.

In this approach, the manual system is replaced with a computerised one without change in overall structure of the former system. Hence the weaknesses of the former system are not addressed and are carried forward to the new system. For example, in a banking hall, a manual system is characterised by long queues and poor controls. If the traditional approach is followed, each cashier will simply be given a computer. The long queues might remain and lack of controls increase because no value was added to the former information system. This method is not recommended for today’s business environment.

Rapid application development (RAD)

Rapid application development (RAD) model evolved from the theory that businesses today heavily rely on information technology. Many information’ systems that were manual in nature are now fully computerised. Therefore, development and implementation of information systems needs to be quick enough for the organisation to maintain a competitive advantage in the market place.

Recent developments in programming software have seen the release of fourth generation languages (4GL’s) which are user-friendly because of their graphical interfaces. Rapid application development makes it possible for system developers to quickly capture user requirements by designing system interfaces in the presence of the user. This rapid application development technique is known as prototyping, and assumes that the user knows what they want when they see it. A prototype is a smaller working model of a real world system. Other approaches used in rapid application development include small team with advanced tools (SWAT) and joint application development (JAD).

The main disadvantage of rapid application development is that the working system may have oversights and weaknesses due to the quick Development. For example, a system may be working well but lack the necessary inbuilt security mechanisms. This would be undesirable in today’s insecure operating environment.

The structured approach

Structured approach to system development defines a set of stages that should be followed when developing a system. Each stage is well documented and specifies the activities to be carried out by the system analyst and his team while developing a system.

Stages of system development

The main stages in system 4evelopment as depicted by the structured approach include:

1. Problem recognition and definition.
2. Information gathering.
3. Requirements specification.
4. System design.
5. System construction (coding).
6. System implementation.
7. System review and maintenance.

Figure 4.2 is a diagrammatic representation of the seven stages of the system development lifecycle (SDLC).

The stages of developing a system are also called the system development lifecycle. Each stage serves a role in the problem solving process. The lifecycle divides the life of an information system into two major parts namely:

1. The development stage.
2. The operation and support stage.

To demonstrate how to undertake each stage, we shall consider a case study.

Case study

Computer-based library management system

Mutito high school library has 3000 text books. Each book is identified by its author, ISBN number, book ID and title. The books are arranged on the shelves using their book ID. Card catalogues are maintained for all the books. There are two types of catalogues, one arranged according to the author’s names while the other is arranged according to the titles of the books. Each member is issued with three borrower cards that have a registration number and name of the member. To locate a book for borrowing, a member checks in the card catalogue for its classification then moves to the shelve to retrieve it. The member surrenders a borrower’s card .at the issue counter where the staff gives out the book and stamps the date of return. A member is not allowed to borrow more than three books at anyone time. Members are charged for overdue books at a fixed rate multiplied by the number of days delayed.

We now look at each of the stages of system development in more detail with this case study in mind.

Problem recognition and definition

Problem recognition is done during the preliminary investigation. During the recognition phase, the system analyst seeks to answer two questions. The first is whether the proposed project is worth looking at while the second is if the project is worth pursuing. After this, the system analyst has to define the scope of the project and establish the constraints, budget and schedule. The most common constraints are usually lack of finance, lack of enough expertise and/or lack of appropriate technology to develop the system.

Problem definition, also called problem analysis is the process of identifying the problem, understanding the problem and finding out any constraints that may limit the solution. This stage requires the analyst to find out as much as possible about the current system in order to draw up a good and relevant proposal for the new system. Remember that there is always an existing system whether manual or computerised. After this, several alternative solutions are modeled.

The main question asked at this point is whether the proposed solution is the right one.

Looking at our case of the school library management system, the problem at hand is to replace the inefficient manual operations such as cataloguing with an efficient computerised system. The system analyst tries to answer the following questions.

1. What are the shortcomings of the current systems?
2. What types of records are used for books and students in the library?
3. What procedure is followed to borrow/lend books?
4. How are overdue books handled when returned?

In this first stage, a special study will be carried out to establish the costs and benefits of a new system. This study is called a feasibility study. A new system will only be developed if its benefits are more than its costs. The end of this stage is marked by presentation of a feasibility report to the management.

The feasibility of a system is assessed in four ways:

Operational feasibility: This establishes the extent to which the users are comfortable or happy with the proposed or new system.

Schedule feasibility: This establishes whether the development of the proposed system will be accomplished within the available time.

Technical feasibility: This establishes whether the technology available is sufficient or can be upgraded for the new system. It also seeks to find out whether the staff has relevant technical skills to develop and use the new system.

Economic feasibility: This establishes whether developing the new system is cost effective by analysing all the costs and benefits of the proposed system.

 

Information gathering

After the feasibility study report has been approved by the management, the system analyst can then proceed to the next stage referred to as information gathering or fact finding. Some of the methods used to collect or gather data include:

1. Study of available documents.
2. Automated methods.

 Studying available documentation

The available documentation describes the current system and all its procedures. It forms a rich source of information for the analyst. Examples of such documents are card catalogues, receipts, reports, technical manuals, organisational charts and archival or backup files.

 

Interviews

Interviews should be carried with the relevant stakeholders in order to get views about the current system and gather information about the requirements for the proposed system. The interview method is powerful because it enables the analyst to have face to face contact with the interviewee.

Therefore in executing an interview, the following guidelines should be followed:

1. The interviewee must be informed in good time and the topic of discussion communicated accordingly to allow for adequate preparation.
2. Avoid personal biases in your questions and perspectives.
3. Be careful about body language and Proxemics refers to things like sitting arrangement, body closeness and how people react when their private distance is violated.

Figure 4.3 shows a verbatim introduction of sample interview with the library manager.

INTERVIEW TITLE

BRIEF INTRODUCTION       Interviewer: ……………

Interviewee: … .

Interviewer: Hello…………

Interviewee: Hello. Welcome to my office.

Interviewer: Thank you. Please call me Pat. I would like to ask you a few questions about the system that we are developing

Interviewee: …………………………………………………

…………………………………………………

…………………………………………………

Fig. 4.3: Example of an interview

 

Advantages of interviews

1. Non-verbal communication like facial expressions can be used and observed.
2. Questions can be rephrased instantly for clarification and to probe the interviewee further.

 

Disadvantages of interviews

1. It is difficult to organise interviews and they are time consuming.
2. The interviewee may not fully open up on some issues that may be personal or sensitive.

 

Questionnaires

A questionnaire is a special purpose document that allows a person to collect information and opinions from the people who receive and respond to it. The main advantage of using this method is that the questionnaires give the respondents privacy when filling them and they can do so at their own pleasure. This may enhance the sincerity of the information given.

Figure 4.4 below shows an extract of a questionnaire used to gather data from library attendants.

QUESTIONNAIRE

BRIEF INTRODUCTION                 Date: …,………….

.

………………………………………………………………………

QUESTIONS

1. How long have you worked as a library attendant: 1 yr.  over 2 yrs.
2. How long does it take to rearrange books on the shelves?

days         weeks         months

Fig. 4.4: An example of a questionnaire

 

Advantages of questionnaires 

1. Since they are filled and returned in privacy, more sincere responses are possible.
2. The respondent can fill the questionnaire at their own pace.

 

Disadvantages of questionnaires

1. Good questionnaires are difficult to prepare.
2. The respondent may not fully understand the questions because of ambiguity of language hence give erroneous responses.

 

Observation

Observation requires the observer to participate or watch closely as a person performs activities in order to learn about the system. This method gives the analyst first hand experience about the problems and exposes him/her to the system requirements. The main advantage of observation is that concepts that are too difficult for non-technical staff to explain can be observed. However, this method has some drawbacks too. These include:

1. The person being observed might alter behaviour leading to wrong equirements being observed.
2. The need to be on-site consumes a lot of time.

 

Automated methods

Automated data collection is mostly used when actual data is required but difficult to get through interviews, observation or questionnaires. Such data may be collected using devices that automatically capture data from the source such as video cameras, tape recorders etc.

 

Preparing and presenting the fact finding report

At the end of the information gathering stage, the analyst must come up with a requirements definition report that has the following details:

1. Cover letter addressed to the management and IT task force written, by the person who gathered the facts.
2. Title page which includes the name of the project, name of analyst and the date the proposal is submitted.
3. Table of contents.
4. Executive summary which provides a snapshot of how the new system is to be implemented. It also includes recommendations of the system analyst because some people will only have to read the summary to make decisions.
5. Outlines of the system study which provides information about all the methods used in the study and who and what was studied.
6. Detailed results of the study which provide details of what the system analyst has found out about the system such as problems, constraints and opportunities that call for an alternative.
7. Summary which is a brief statement that mirrors the contents of the report? It also stresses the project’s importance.

This report is then presented to the management for evaluation and further guidance. fig 4.5 shows a sample general outline of the fact finding report presented to the management of the school library and the head of the I

 

Library management information system 

Fact finding report

1.0 Table of contents.

• Executive summary.
• Objectives: The new computerised system is intended to improve efficiency in the library by:
  • Keeping an inventory of all the books in the library and automatically updating the stock hence eliminating the tedious physical counting process.
  • Reducing the time needed to seek for a book by 60%. (c) Tracking overdue and lost books.
• Recommendation:

This system could result in efficient processing of library transactions. It will replace the tedious manual system.

• Methods used to study the system
• Interviews: Used when seeking facts from management.
• Questionnaires: Circulated to user staff.
• Observation: Observed book search and issue.
• Detailed results
• Problems: Duplication of records, delays and book loss.
• Opportunities: Efficiency, stock management etc.
• Alternatives: Enforce controls in current system, more staff etc.

5.0 Summary.

The new system is highly recommended because the other alternative of enforcing controls and employing more staff will add operating costs with little additional value.

Fig. 4.5: A sample outline of a fact finding report

NB: The sample report is simplified for purposes of instruction at this level and should not be taken as a complete report. A complete report lay comprise of several bound pages.

 

Requirements specification

Requirement specification, the system analyst must come up with the detailed requirements for the new system. Remember that in the long run the hardware and software used to develop the system mainly depends on input, output and file requirements. For example, if one of the input requirements is that the system would require data in picture format then one input device that cannot be avoided is an image capturing device such as a digital camera or a scanner. At this stage the following requirements specifications are considered:

1. Output specification.
2. input specification
3. File/data stores.
4. Hardware and software requirements.

 

Output specifications

As opposed to data processing cycle where we follow the input-process-output model in system development, consideration is given to the output requirements of the new system first. This is because; the main interest from a system is information (output). For example the management of the library in our case study is interested in whether the system can generate reports on overdue books, charges on late return, inventory etc.

The quality of system output depends on how well management and user requirements were identified. The Output is usually in the form of reports either in hardcopy or softcopy form.

The following factors should be put into consideration when designing the output

1. The target audience. For example, top management would require a summary of overall performance in the organisation while a user report may show only the transactions carried out or transactions at hand
2. The frequency of report generation. Some reports are required daily, others weekly, monthly or annually. However, some are required in an ad hoc manner i.e. at random.
3. Quality and format: The quality and format of information to be generated should be put into consideration.

For our case study outlined earlier, the following outputs are needed from the library management system:

1. A report about all the overdue books showing charges against each borrower.
2. A search report for a particular book showing its classification and whether its on the shelve or not.
3. A search report about a particular member showing which books he/she is currently holding. Table 4.1 below shows a sample report expected to be generated from the computerised library system showing all the overdue books.

Input specifications

Once the system analyst has identified the information (output) requirement of the new computerised system, he/she goes ahead to identify the input needed to obtain the relevant information from the system. In our case of the library, the following inputs can be deduced from the output specification:

1. The type of data needed to add a book to the books file or database in the library. For example in the library database the following data items may be entered:
   • Title of the book.
   • Names of the author(s) of the books.
   • The ISBN number of the book.
   • Book ID
2. Determine data that is needed for someone who wishes to borrow a book.

After identifying all the inputs, the analyst designs the user interface by designing data entry forms or screens. An example of an input form is the new member registration form as shown in Figure 4.6.

The user interface is an important determinant of whether the system will be happily accepted by the users or not. Hence, it must be designed with a lot of care. The following guidelines should be observed:

1. Objects placed on forms like text boxes, labels and command buttons must be neatly aligned and balanced on the form.
2. The size of the form must not be too small for user legibility or too big to fit on the screen 3. The colour for the interface must be chosen carefully to avoid hurting the eye. Avoid colours that are too bright.

 

File/data stores

File requirements specification involves making an informed decision on files required to store data and information in the system. The system analyst should identify the number of files that will be needed by the system and determine the structure of each of the files. For example, will the files allow direct access? Will the files be sequential files stored on a magnetic tape? The attributes of the records in a file should also be identified. An attribute is a unique characteristic of a record for which a data value can be stored in the system database. If it is a student, one attribute can be the name and the other is the student’s registration number. For a book record, the attributes that can be identified include: Book ID, international serial book number (ISBN), the title, publisher, year of publication, date of issue and date of return.

However, only those attributes that are of importance to the system will be picked and used to store data for each record. In our case study for instance, we only need the Book ID, title, author, ISBN number, date of .issue and return.

These attributes will form the basis for table design in the database. Each attribute will become a field in the table. For example, there will be a Books table that will have fields for each record.

 

Factors to consider when designing a file

In order to design a good file, you need to consider the following aspects:

1. The key attribute or field: This is usually an attribute that is unique for each record.
2. The type of data: Each field has a data type. Book titles can be stored as data of type “text” while the date of borrowing a book as of the type “date” in the database.
3. The length of each field: This is important because the longer the field, the slower the system takes to process transactions. A name field can be specified to be 30 characters long while the integer field can be 10 characters long. However, these vary depending on the system developer’s perception of how the system should store the data.
4. Back up and recovery strategies: The updated copies of data and information files need to be stored in a different place other than the location of the current system. This makes sure that even if the current file gets corrupted or crashes, the backed up data can be used to recover or reconstruct the original file.

 

Hardware and software requirements

The system analyst should specify all hardware and software requirements for the new system.

Some of the factors to consider in hardware and software specification are:

1. Economic factors such as price and acquisition method.
2. Operational factors e.g. reliability, upgradeability and compatibility with the existing resources.
3. User-friendliness.

 

System design

There are several tools for designing an information system. Examples of such tools are flowcharts, data flow diagrams, entity relationship models and structured charts. In this book, we shall concentrate on the use of the system flowcharts as the primary tool for system design. A system flowchart is a tool for analysing processes. It allows one to break process down into individual events or activities and to display these in shorthand form showing the sequential or logical relationships between them.

After drawing the system flowchart, other algorithm design tools like pseudo codes and program flowcharts can be used to extract the processing logic for each module in the system before system construction.

 

The system flowchart has many similarities to the program flowchart covered earlier in the book. However, it has its own set of symbols and it seeks to depict the whole system rather than the individual program modules. Figure 4.8 shows some common system flowchart symbols.

Other symbols that are of great importance at this level are as follows:

Rectangle with rounded corners: represents an event which occurs automatically and usually triggers a chain of other events. For example, the book lending process is triggered by a student request!

Kite: represents the sort operation.

Designing a system flowchart

Designing system flowcharts gives a concise picture of the way particular processes are done within the business organisation. After this has been achieved, the next logical step of making changes to the processes for the better can be handled easily.

Although there is no formal approach for designing a system flowchart, the following guidelines are important:

1. Start by writing the title of the flowchart. For our case study, the title “Library Books Management Information System” could be sufficient.
2. If possible, start drawing the flowchart with the trigger event. In this case, our trigger would be a student request to borrow a book or to return an overdue book.
3. Note down the successive actions taken in their logical order until the event or process is concluded. Use few words to describe the actions.
4. When there are many alternatives at the decision stage, follow the most important and continue with it. Other significant but less important alternatives can be drawn elsewhere and reference made to them by using the on/or off page connectors. Figure 4.9 shows the system flowchart for the proposed computerised library management system for the school.

Explanation

From the system flowchart, we observe that:

1. A member e.g. a student requests for a particular book.
2. The system checks for the students record in the system. If the student has more than three books, a message to this effect is displayed and cannot borrow an extra book.
3. If the student has less than three books, then the book can be given out to him/her.

From the system flowchart, a program flowchart for a particular task can be extracted. Figure 4.10 illustrates the book lending process extracted from the library management system flowchart.

 

System construction

System construction refers to the coding, installation and testing of the modules and their components such as outputs, inputs and files.

The purpose of the construction phase is to develop and test a functional system that fulfils the business and design requirements. Indeed, programmers come in at this stage and are briefed on the system requirements as illustrated using various design tools in order for them to construct a computerised working model of the same.

System construction methods

There are a number of programming techniques that can be used to construct a designed system. These include:

1. Using the high-level structured language such as Pascal, COBOL etc
2. Using fourth generation languages (4GL) – These are easy to use programming languages. Some of the fourth generation languages are Visual Basic, Visual COBOL, Delphi Pascal etc.
3. Customising the standard packages – This involves the use of a ready made software package mostly a database software, financial package or enterprise management system. Due to the varied approach to system construction available, Chapter 5 in this book introduces you to Visual Basic programming while Appendix I explains how a database package can be customised to construct a system. Figure 4.11 shows a data entry form constructed to enable entering a new book record into the library information database.

Testing the system

After construction, the system is tested by entering some test data to find out whether its outputs are as expected. The system is tested using the requirements specifications and the design specifications to find out whether it meets all requirements specified.

For example, if one of the requirements of the computerised library management system is to ensure that no member is allowed to borrow more than three books at the same time, it must do that without fail. Figure 4.12 shows a message box to this effect.

 

System implementation

System implementation is the process of delivering the system for use in day to day operating environment for the users to start using it. The areas to be addressed during system implementation include file conversion, staff training, and changeover strategies. File conversion

Every time a new system is implemented, the format of data files might require modification or change. This process is referred to as file conversion. A new system may require a change in file format e.g. from manual to computerised. The factors to consider at this point are:

1. Whether the new system requires a new operating system and hardware. The best practice today is to develop systems that do not need hardware change unless it is very necessary.
2. Whether you need to install new application software. For example if you have developed a new system by Customising a database application software, you need to install that software if it is not installed.
3. Whether you need to create new database files for the new system. For example, where files are manual, electronic ones will have to be made. However, remember that we strive to develop systems that are data independent That means that the systems can be changed without affecting the organisational data structures in the databases.

Staff training

Availability of appropriate documentation like user manuals goes a long way to make staff training easy, quick and effective. System implementation can fail if the staff are not trained properly leading to great loss of company resources.

Changeover strategies

Changeover simply means how to move from the old system and start using the new. Most businesses especially those that are driven by information technology need as smooth a changeover as possible. Some of the system changeover strategies are:

Straight changeover

In straight changeover, the old system is stopped and discarded and the new system started immediately. This sudden change of old to new means that the project faces higher risks in case the new system faces problems. This is because the old system would not be there to fall back to. The advantage of this method is that it is cheaper because you do not have to run the two systems in parallel. Figure 4.13 shows the straight changeover strategy diagramatically. At a time t, a switch is made from the old to new system.

Parallel changeover

In parallel changeover, both the old and new system are run parallel to each other for some time until users have confidence in the new system then the old system is phased out. This method is a bit costly because extra resources have to be engaged to run the two systems in parallel. However, its lower risk to business operations and thorough testing of the new system are some of its advantages. This method is not suitable for large systems because of the high operational costs during changeover. Figure 4.14 depicts a parallel changeover process.

Phased changeover

In phased changeover, a new system is implemented in phases or stages. A good example is the way the education system is changed from the old to the new curriculum. Each year at least one class level changes over to the new syllabus.

Sometimes, one phase may run a new system for testing before it is implemented into all the other phases. This is called piloting. The main”, disadvantage of phased changeover is the danger of incompatibility between various elements i.e. hardware or software of the same system. However, its advantage is that it ensures slow but sure changeover.

 

Security control measures

Information and data security have become some of the most important aspects of information systems. A lot of careful planning has to be done in order to have what is called inbuilt security in the system. This is because information is under constant threat of being illegally accessed or disclosed to unauthorised parties. Therefore, the system implementers must make sure that the security features built in the system are properly configured during the implementation stage.

System maintenance and review

System maintenance is the adjustment and enhancement of requirements or correction of errors after the system has been implemented. Regardless of how well the system is constructed and tested, errors may be detected when the system is in use.

System review is a formal process of going through the specifications and testing the system after implementation to find out whether it still meets the original objectives. This act is sometimes called review and audit. If the system does not meet the stated objectives, system development might start all over again.

System documentation

System documentation is a life long process in the system development lifecycle. After a system has been implemented, any maintenance work must be documented in order to update the existing documentation. In this chapter, we have constantly provided sample documentation in every stage of system development using the school library management system case study. Generally comprehensive system documentation consists of the following:

1. Report on fact finding
2. Requirement specification
3. System and module flowcharts
4. Table/file structures description
5. Sample test data and expected output
6. Output reports

Reports on fact finding

At the end of fact finding stage, the system analyst should prepare a well detailed report that mainly outlines:

1. The methods used to collect data.
2. Weaknesses of the current system as evidenced by the collected data.
3. Recommendations: Why there is a need to replace or upgrade the current system.

Figure 4.5 on page 104 shows a sample fact finding report for the school library system.

Requirement specification

The report on requirement specification outlines mainly the:

1. Output requirements for the new system such as reports.
2. Input requirements.
3. Hardware and software required to develop the new system.

Table 4.1 on page 106 gives a sample report expected from a computerised library system, while Figure 4.6 on page 107 gives a simple illustration of an input form for new library members.

System flowchart

The system flowchart shows the overall functionality of the proposed information system.

Therefore at the end of the designed phase, the system analyst should write a report that contains: 1. The system flowchart or data flow diagrams that shows the processing logic of the information system.

Any module flowchart that may help programmers in construction of the required subsystem or modules. a sample module flowchart.

Table file structures description

Depending on approach used in system construction, the report should contain file or table structure definitions. For example, if you opt to construct a system using customisation approach, details on table structures should be well documented (see Appendix I). Figure 4.15 shows a sample table structure of the Books table in a library system.

Sample test data

To test whether the new computerised information system is working as expected, you need to use test data for every module (subsystem). For example, in our library case study, we need to test sample data for books entry, book borrowing etc. Table 4.2 shows a sample test data that can be entered in the database whenever a book is borrowed. Table 4.2

Output reports

To prove that the system is working and giving the desired result, you should provide a number of sample output from various system modules. Figure 4.16 shows a sample report showing a list of members who have borrowed books.

 User manual

User manuals are supposed to help a person to use the system with as little guidance as possible.

Therefore, the manual must contain information such as:

1. How to install, start and run the system.
2. How the system appears when running (interface).
3. How to carry out various tasks e.g. in our case study, this would include new books entry, lending/borrowing, data entry etc.
4. Error correction and how to get help when faced by exceptions. This would be in a troubleshooting guide.

Figure 4.17 shows a sample main menu screen switchboard from which the user can access other modules.