.

System Development Life Cycle

This is also known as traditional system development method or function driven method or process driven
method. The method requires the analyst to follow a sequence of phases during the development and
implementation of an information system. This involves people and is described as information system
development project. The following are the system development cycle phases or stages:

1. Preliminary survey/study
2. Feasibility study
3. Facts finding and recording
4. Analysis
5. System design
6. System development
7. System implementation

3.1 Preliminary study

This stage involves determination of whether there is need to change the existing system or business
procedures. It may require management requests for a change of the existing system to give an organization
a competitive advantage or to improve the staff morale. The user department should be involved during the
definition of the problem. The problem to be solved should be very specific, clear and precise. It should not
be too broad to cause ambiguities in its solution.

Objectives of the preliminary study are:

 To understand organizational characteristics and its objectives
 To understand organizational structure
 To identify organizational mission and collect relevant data or document regarding organizational
information.
 To develop a brief and accurate problems statement usually known as system term of reference
(TOR).

Terms of reference
It is a documentation prepared by steering committee to act as a reference document throughout system
development stages. Its contents include:

 Project title
 Subject of study
 Purpose of study
 Personnel
 Departments
 Sections affected or involved during the system implementation
 Available resources and constraints, the analyst, the project leader should consider
 The projects estimated duration and schedule

The importance of terms of reference is:

i. Provides information about the proposed system

ii. It may act as a reference document throughout the system development process
iii. It acts as an authorization document to the project development team by the management
iv. It gives the scope and extent of the proposed system project, thus setting out systems limitation
and capability
v. It sets out the objectives of the proposed system

Steering committee
It is formed by two or three people to oversee the system development project from its initiation to its
completion. It comprises of the system analyst as the project leader and a representative of the user
department. They should understand all the processing objectives and procedures within the affected
department. A management representative and accountant or auditors may be incorporated to advise
initially on financial aspects on the project.

The functions of the steering committee are:

a) To study the current processing procedures that may require to be improved.

b) To prepare problem statement in form of terms of reference.
c) To coordinate system development activities throughout the development life cycle.
d) To interface the project development team with organizational management.
e) To resolve conflict that may arise during system development.
f) To direct, control and monitor the system development progress.

3.2 Feasibility study

This is a more detailed study carried out by a feasibility study team. Its purpose is to define the problem
and decide whether or not a new system to replace the existing one is viable or feasible. During the study,
the analyst should assess the magnitude of the problem and attempt to restrict or at least identify the scope
of the project. The analyst must list precisely the problems of the current system and also indicate what
would be required of the new system. He must identify alternative solutions to the problems and
recommend the most cost effective solution.

Feasibility study activities include:

 Identification of main characteristics of the existing system

 Determination of the main output requirements
 Considerations of alternative ways of meeting similar requirements.
 Preparation of gross estimates of developments, implementation and operation costs for each
probable alternative solution.
 Documentation of the study i.e. writing of feasibility study report.
 Preparation of gross estimates of possible direct and indirect benefits for each probable alternative.

The following are the areas of feasibility study:

a) Technical Feasibility
b) Social Feasibility
c) Economical Feasibility
d) Legal Feasibility

Technical Feasibility
Technical questions are those that deal with equipment and software e.g. determination of whether the new
system can be developed using the current computer facilities within the company. Technical feasibility is
thus aimed at evaluation of the following:

i. The hardware required for the new system

ii. The software required for the new system
iii. Determination of whether the current facilities are adequate or inadequate for the new system
after implementation.
iv. Evaluation of the current technology and how applicable it is to the new system
v. Determination of the need for telecommunication equipment in the new system to improve both
data capture and preparation activities.
vi. The inputs, outputs, files and procedures that the proposed system should have as compared to
the outputs, files and procedures for the current system.
vii. Determination of whether training is necessary for the employees before the new system is
implemented and the relevant skills required.
 viii. Suggesting a suitable method of developing the new system, methods of running it when it
becomes operational and ways of implementing it.

Social Feasibility
This is also known as operational feasibility. It mostly deals with the effect of the system on the current
society within the company. It is carried out on the following areas:

i. The reaction of individuals both inside and outside the company as a result of the new system.
ii. The effect of the system on the existing organizational structure.
iii. The effect of the system on the current working practices and management levels i.e. whether
there would be any change required and if so the cost of the change socially.
iv. Redundancy or retrenchment, implication to the company as a result of the new system.
v. Implication of the system on existing staff development programmes.

The social feasibility is carried out along with technical feasibility such that the social implications of every
alternative technical solution to the problem that emerges are evaluated. Areas to consider include:

 Group relationships
 Salary levels
 Job titles and job descriptions
 Social costs to be evaluated e.g. cost of user training, consultancy that may be engaged during
development of the new system, job improvements and salary changes.

Legal Feasibility
The new systems legal implications should be evaluated e.g. if it requires that the computer should be
insured or whether the stored data should be registered with the government registrar before use. The
copyright implication for restriction should be assessed before the new system is implemented. Generally
any legal aspects associated with the new system should be assessed, and adequate measures taken to
protect the interest of the user company.

Economic Feasibility
Economic feasibility is aimed at determination of whether or not to continue with the project, depending on
whether the project is economically viable. The systems benefits and estimated implementation cost should
be determined before any further resources can be spent on the project.
A cost benefit analysis (CBA) is carried out to determine whether the new system is economically viable.

Cost Benefit Analysis

Benefit Analysis: Is obtained through comparison of the new system and the existing system. Benefits of
the new system fall under two categories i.e. direct and indirect benefits as well as tangible and intangible
benefits.

i. Direct (Tangible)–fall under two categories: measurable benefits and direct savings.

Measurable benefits are those that can be quantified in monetary terms e.g. increase in working capital as
a result of purchasing of computer systems or reduction of delays in decision making which is obtained
through improved procedures e.g. invoicing procedures and credit control procedures.

Direct savings are those costs, reduced or eliminated as a result of introduction of computerized system.
They include reduction or elimination of clerical personnel and elimination of some specific costs e.g.
stationery costs. Like measurable benefits direct savings can be quantified in monetary terms.

ii. Intangible benefits – they are benefits that cannot be quantified in monetary terms or those that are
difficult or impossible to quantify in monetary terms.
They are clearly desirable but very difficult to evaluate in terms of money value e.g. improved customer
satisfaction, better information, improved organizational image, increased staff morale, a competitive
advantage to an organization etc.

Cost Analysis: Costs are expenses or expenditure which are incurred by a system. These may include
equipment cost, development cost, operation cost and software cost. During cost analysis one should
consider both the new and the existing system. The cost of retaining and operating the existing system
should be compared to the cost of introducing and running the computerized information system.

These costs fall under the following categories:

a) The cost of running the existing system. This is calculated from the past records. The items to consider
include:

i. Man power cost – which is extracted from the budgets and payroll reports
ii. Material cost – which includes consumables e.g. stationery, work in progress and current stock
iii. Operational cost e.g. the equipment cost expressed in terms of unit rate. Others to consider
include the duration the project takes to be completed and initial replacement cost.
iv. Overhead costs – which are direct expenses incurred by the company on behalf of all
departments e.g. rent, electricity, telephone bill etc. These can easily be extracted from
departments or centres to which they are allocated.
v. The intangible cost of existing system e.g. loss of sales or cost of sales as a result of inappropriate
stock levels or loss of interest in bank as a result of improper credit control system.

b) The cost of operating the proposed system – this is likely to include all the areas covered above i.e.
manpower, materials, overheads and the intangible costs. However there are additional costs associated
with computerized systems e.g. service contracts for the computer system, insurance of the computer
system, cost of data transmission, cost of consumables like printer cartridges, ribbons etc. All these costs
should be evaluated or estimated as accurately as possible.

c) The cost of new system development – Includes the cost incurred for any consultancy services that may
have been hired during development. Allowances given to the system development team members fall
under this category. Overall effects of the system development and implementation should be
determined and any cost associated established. These estimates are based on both time and activities
involved in the project. Staff training cost, recruitment costs and retrenchment costs should be
considered under system development cost.

Cost benefit analysis should be conducted on each alternative solution to the problem. This enables the
analyst to make recommendation on a suitable cost effective alternative solution to the problem.

Cost benefit analysis techniques

The techniques used in economical evaluation of a computer based information system are the same used
in investment appraisal in other areas of commercial world. These techniques tend to produce contradictory
results and none of them is universally accepted. These techniques are based on either marginal costing
methods or life cycle costing method. Marginal costing methods deal with snapshots of systems
performance at a given point in time. Life cycle costing methods deal with measuring system performance
over its working life.

These techniques include:

 The ARR (Accounting Rate of Return)
 Pay Back Period
 Discounted Cash flow – Net Present Value (NPV)
 Internal rate of Return (IRR)
Some of the limitations of CBA are:
 Difficult to consider all factors that might contribute costs or benefits
 Difficult to quantify some costs and benefits.

Feasibility study report

After the feasibility study and the cost benefit appraisal, a report is prepared that gives recommendations
on whether or not to commit any further resources on the project.
The contents of the feasibility study report include:
 Introduction – It gives general description of the existing system, the people contacted during the
study and purpose of the report.
 Description of the alternative proposed systems in terms of the inputs, outputs, file processed,
response time etc.
 Quantification to justify the cost of running the proposed system
 The recommendation by the analyst on the most cost effective alternative solution.
 The author of the report
 System analyst recommendations on the new system indicating whether to commit further
resources.
 If the decision is to continue with the project, its development plan should be given.

The report is submitted to the management for approval. After approval a more detailed survey is
conducted on the existing system mostly to establish its weaknesses and strengths. This is called fact-finding
or fact gathering.

3.3 Fact finding/investigation

This involves collection of information about the existing system on which to base analysis in order to
determine whether users current needs are being met. The following are some of the activities that are
looked at:

a) Functional requirement – the requirements should be established

b) Determination of the proposed system requirements – this is necessary as it may suggest a change
in the existing system requirement.
c) Establish any weaknesses or problems associated with the present system, working methods and
procedures.
d) Determination of organizational growth rate – this will assist in determination of the growth of the
volume of transactions to be processed.
e) Determination of the organization structure, objective and the cost associated with the present
system.

Fact-finding comprises of the following activities:

i. Fact-gathering
ii. Fact-recording
iii. Fact-evaluation

Fact-finding techniques
a) Use of questionnaires

A questionnaire is a special document that allows the analyst to ask a number of standard questions set to
be asked to a large number of people in order to gather information from them. It is used when:
- the system analyst is located at a considerably long distance from the respondent
- there is a large number of respondents such that interviewing them will be limited by time
- the questions to be asked are simple and straight forward and require direct answers
- limited information is required from a large number of people
 - it is used as a means to verify facts found using other methods.

Advantages of using questionnaires are:

 They provide a cheap means of gathering information/data from a large number of people.
 They encourage individuals to provide response without fear, intimidation or victimization.
 The respondents can complete the questionnaire at their own convenience with minimal or limited
interruption of their work.
 Questions are presented consistently to all without bias.

Disadvantages of using questionnaires are:

 Response is often too slow since the respondents complete and return the form at their own
convenience.
 They don’t provide an opportunity for respondents to obtain clarification of questions which may
appear vague or ambiguous.
 Does not provide an opportunity for the analyst to observe respondents’ reactions.
 The design of the questionnaire requires an expert who may charge expensively and may not be
economical when used for a small group of users.
 All forms may not be returned and also not all questions may be answered which leads to incomplete
data for analysis.

Requirements for preparing a questionnaire include:

 Questions should be simple and clear.
 The questions should be objectively oriented and one should avoid leading questions.
 The questions should be logically organized.
 The form should be neat.

b) Interviewing
This is a direct face-to-face conversation between the system analyst (the interviewer) and users
(interviewees). He obtains answers to questions he asks the interviewee. He gets the interviewee’s
suggestions and recommendations that may assist during the design of the proposed system.
Interviews serve the following purposes:
 Acts as a method of fact-finding to gather facts about the existing system.
 Used for verifying facts gathered through other methods.
 Used for clarifying facts gathered through other methods.
 Used to get the user involved in the development of the new system.

Interviews are used in the following circumstances:

 When the respondents are few e.g. corporate managers
 When the respondents are physically available and accessible
 When the main emphasis of the system investigation is people
 When the analyst wishes to seek direct answers, opinions, suggestions and detailed information
 When the analyst wishes to verify validity of facts collected through other techniques
 When immediate response is required

Interviews have the following advantages:

 The analyst can frame questions differently to individuals depending on their level of
understanding. Thus it allows detailed facts to be gathered.
 The analyst can observe non-verbal communication from the respondents or interviewees
 The response rate tends to be high
 Provides immediate response
 The analyst can get detailed facts from each respondent
Disadvantages of interviews are:
 Costly and time consuming when used on a large number of people
 Success highly depends on the analyst human relation skills, expertise and experience
  May not be practical due to location of respondent
 May make the respondents to feel that they are being summoned or grilled by analyst
 Interviews can fail due to:
o Ambiguous questions being asked
o Personal questions being asked
o Inadequate time allocation for the exercise
o Lack of earlier preparation by both parties
o When the analyst is biased on using technical jargon
c) Observation
Observation is the most effective fact-finding technique but requires the analyst to participate in performing
some activities carried out by the user. He may choose to watch them as they perform their activities and
gather the facts intended.

This method is best used in the following circumstances:

 When the validity of facts gathered through other methods is questionable
 When complexity of certain aspects of a system prevent a clear explanation by the respondents or
the user
 Used to confirm that the procedures specified in the manuals are being followed.
 When one needs to obtain first hand and reliable information

Guidelines when using the observation method include:

 There should be permission from concerned authorities before the exercise
 Gathered facts should be recorded
 Those to be observed should be notified and the purpose of the exercise explained
 The analyst should be objective and avoid personal opinion. He should have an open mind
 The analyst should also record ordinary events

Advantages of observation method include:

 Data gathered is highly reliable thus the method can be used to verify facts collected through other
methods
 The analyst can see what is being done clearly including the tasks which are difficult to explain
clearly in writing or in words
 Inaccuracy or inaccurately described tasks can easily be identified
 It allows the analyst to easily compare gathered facts through other methods and what actually
happened on the ground
 Relatively cheap compared to other methods

Disadvantages of observation are:

 People feel uncomfortable when being observed and behave abnormally thus influence the analyst’s
conclusions
 The exercise may take place at odd times thus inconveniencing those involved
  The analyst may observe exceptional activities, leaving some critical areas. His patience and expertise
play a great role
 The tasks being observed may be interrupted and the analyst may gather wrong facts

d) Record inspection/Document review

This method involves perusing through literature or documents to gain a better understanding about the
existing system. Examples of documents that are perused include sales orders, job descriptions, existing
systems documentation, management reports, procedure manuals, organized structure charts, trade
journals etc.
This method is best used when:
 The analyst needs to have a quick overview of the existing system
 The information required cannot be obtained through any other techniques

Advantages of this method are:

 It is comparatively cheap compared to other techniques
 It is a faster method of fact finding especially when documents to be considered are few
Disadvantages of this method are:
 Time consuming if the documents are many or if they are not within the same locality
 Unavailability of relevant documents makes this method unreliable
 Its success depends on the expertise of the analyst
 Most of the documents or information obtained may be outdated

e) Sampling

Sampling is the systematic selection of representative elements of a population. The selected elements are
examined closely and the results assumed to reveal useful information about the entire population.

This method is used when the target population:

 Is too large and it is impractical to study every element of the population
 Contains homogenous elements (elements with similar characteristics)

Advantages of sampling are:

 It reduces the cost e.g. by avoiding to examine every document or talking to everyone in the
organization to gather facts
 It speeds up fact finding process
 It improves effectiveness since one can concentrate on few people and fewer documents and get
adequate accurate information
 May reduce biasness, if a representative sample is taken. All the elements of the population stand a
chance of being selected.

Disadvantages include:
 The sample may not be representative enough which may lead to incorrect and bias conclusions
 The expertise of the analyst is required since sampling involves a lot of mathematical computation

3.4 Analysis
A system analysis involves evaluation of the current system using the gathered facts or information. One
should evaluate whether the current and projected user needs are being met. If not, he should give a
recommendation of what is to be done. Analysis involves detailed assessment of the components of the
existing system and the requirements of the system.
The objectives or aims of system analysis are:
 To determine information needs of an organization and the users of that information
 Determination of the current activities of the system i.e. functions involved in conversion of inputs
to outputs
 Determination of the intended systems output
 Determination of the resources required for the intended system
 Determine capabilities required in the system to meet information needs of the organization

System analysis activities are:

i) Analysis of the organization environment. The analyst should evaluate in details information
needs of the organization environment e.g. information needs of the consumers, suppliers,
competitors, government departments etc.
ii) Analysis of the present system. The analyst should study the current system and identify its
weaknesses and its strengths. He should establish the ability of current system in meeting the
stated information needs. This guides a decision to be made on whether the existing system
stands to be improved, changed or done away with altogether. Some aspects of the existing
system that are examined includes input transactions, outputs or results, existing controls, files,
user interaction, methods, procedures, functions and existing hardware and software.
iii) Requirement analysis – involves determination of user requirements e.g. task performed, output
expected, proposed system development cycle and user goals. The following are also
determined:

 Maximum, minimum and average levels of activities

 Duplicate procedures e.g. two people entering the same transaction at different times
 Labour intensive tasks – the tasks that are manual and can easily be computerized
 Activities or tasks that involve complex or repetitive computation
 Procedures that have become obsolete

Once all the facts are analysed and documented a formal report is written called statement of requirements.

The contents of statement of requirements are:

i) Description of the initial system goals and whether or not they are met and are still applicable
ii) Description of whether the existing system is cost effective
iii) Description of whether the output produced is adequate, timely and well controlled
iv) Description of whether files held are suitable for supporting current organization requirements
v) Description of current system inputs and whether or not they support current file maintenance
activities
vi) Description of the existing system workflow efficiency
vii) Description of any constraints within the system
viii) Description of any existing system equipment, procedures and controls that can be transferred to
the new system.

The importance of system analysis are:

 It helps the analyst or system developer to gain understanding of the existing system.
 It allows the analyst or system developer to record existing system information in a standard
form to aid design of a new system. It also facilitates understanding of the system by the user
staff.
 Enables the analyst or developer to define existing system procedure into a logical model
 Helps the analyst to write or produce statement of requirements, which guides the
development team throughout subsequent stages of the development life cycle.

3.5 System design

The objective system design is to put a logical structure of the real system in a form that can be interpreted
by other people apart from the designer. The analyst should derive a logical model of the way the existing
system works. There is an assumption that the existing system provides a good guide to what is required of
a new system. It should be different from how the new system is to achieve the given requirement.

Limitations of system design include:

 There could be some requirements of the new systems that are not currently being satisfied by the
current system. These requirements should not be taken into account.
 Inefficiency in the current system may be translated into a logical model and these will be transferred
to the new system. Ideally, the models should reveal the logic of an efficient system and should be
amended accordingly.
 It is likely that physical aspects of the existing system may be transferred to the logical analysis. The
analysts should guard against that.
The above limitations can be dealt thus:
 Treatment of the new requirement: The new requirement can be estimated through interviews with
management and users. It is important that the logical model be amended to reflect the new
requirements. They are likely to lead to new processes that are added to higher-level design.
 Treatment of inefficiencies: The model should be adjusted through the decomposition of top level
design tools e.g. DFDs. The lower level data flow diagram tend to be determined partly by what is
done in existing system to fulfil a function.
 Treatment of physical aspects: Certain physical considerations may have shifted into a logical model
e.g. a data store or file may contain extra information which may require amendment e.g. to
incorporate separate files.

There are two types of design: logical design and physical design.

Logical Design
A logical design produces specifications of major features of the new system, which meets the system’s
objectives. The delivered product of the logical design is a blueprint of the new system. It includes the
requirements of existing system components:
o Outputs (reports, displays, timings, frequencies etc)
o Inputs (dialogs, forms, screens etc)
o Storage (requirement for data to be stored in databases)
o Procedures (to collect, transform and output data)
o Controls (requirements for data integrity, security, data recovery procedures)
Note: Logical design of the system is viewed in terms of what process i.e. procedures, inputs, outputs,
storage and control the new system should have.

Physical Design
It takes the logical design blueprint and produces the program specification, physical files or database and
user interface for the selected or targeted hardware and software. Physical design is mostly concerned with
how the current system or future system works in terms of how the programs are written, files organized in
storage media and how tasks are carried out for user interface with the system.

System design objectives

The designed system should meet the following criteria:
  User needs are met as cost effectively as possible
 One that is within the constraints laid down in the terms of reference
 Produce correct outputs by processing data accurately and efficiently
 Simple to operate i.e. easy to use
 One with sufficient built in controls and provide feedback to its user
 Should be reliable
 Should be functional

System design constraints

 The budget: A well-designed system incurs greater expenses. The total system cost of meeting the
objectives must be considered in the light of the available budget.
 Time: Time taken to produce a very usable system would increase development cost and delay
system delivery.
 Integration with other existing system: Existing and planned system may limit option and available
features of the system.
 Skills: Limitation may arise from the range of skills and level of competence in both the design team
and the system users.
 Standards: Standards may drive the design tasks in a specified direction.

Input and output design

The input and output design of a new system starts by choice of input and output media.
Factors to consider include:
 Input and output contents
 Contents layout
 Nature of the system
Some factors are considered during output design although such other factors as the following are
considered:
o How the information will be used
o The timings and frequency of the output and
o The complexity of the information contained in the report

Printed output design

There are two types i.e. pre-printed forms and computer generated reports.
The pre-printed output design begins by drafting copies, which are then passed on to an expert graphic
designer to create necessary documents. They are then printed on a continuous basis.

Examples include: a purchase order, invoices and statements. A programmer then writes a program, which
controls a specific type of print and fills up the variable data on the document. The computer generated
report format is influenced by user organization standards. The user and the management should participate
in the original design draft and also approve the final printed reports or outputs. This may be done through
the use of a prototype.
Screen design
In order to produce an effective screen dialogue, several factors should be considered:
i) The hardware in which the interface will be implemented e.g. a VDU, mini computers etc. These
should include the hardware ability to use graphics, colour or touch sensitive panels.
ii) The software pre-loaded on hardware e.g. the pre-loaded operating system, whether it is DOS
based or window based.
iii) Memory capacity i.e. RAM and hard disk in order to determine the size of the application to be
developed

Interface techniques
It is important to consider the characteristics of the proposed system of input and output interface design.
Modern screen dialogue interface will always apply three types of combination i.e. form filling, menu
selection and WIMP interface.
Form filling
It is an effective form of interface where verification involves data capture. Some of the guidelines to form
filling include:
o Forms should be easy to fill
o Information should be logically organized or grouped e.g. headings identification, instructions,
body, totals and any comments
o Should be clear and attractive
o Should ensure accurate completion
Menu interface (selection)
It is designed to allow operator to select increasingly detailed options or choices with each menu screen
covering a different function. This is made clear by use of colour screen and WIMP interface. The bottom
option is usually reserved for the error message or for help facility.

WIMP (Windows Icon Mouse and Pull-down menu)

It is not created by the system team but it is an environment that allows computer users to manipulate the
operating system as well as application programs. WIMP tends to be used in PCs but can also be used in
multi-user system workstation. They have to allow users to generate screen dialogue by prototyping.
Prototyping is used to allow the user to see the interface on the screen and also simulate menu operations,
cursor movements and screen changes in form-filling techniques.
Program design
A program can also be referred to as a module, process, unit, routine, procedure, function, macro, segment
or fragment depending on its size and the scope of operation.

The following are some important aspects of a program:

 One function: A program should carry out only one task. If several interrelated programs are linked
together they form a system, which is easy to maintain for it comprises of several units.
 Size: A program should be small enough so that it is easy to maintain, can take less memory and
make optional use of the CPU.
 Cohesion: This measures the strength of relation within a program. This implies that what happens
in one sub-routine affects the other sub-routine or other programs. A program that performs more
than one function has a low cohesion. A high degree of cohesion within a program results in low
coupling between programs.
  Coupling: Is a measure of the strength of the bond between programs. Ideally, program should have
little dependencies on other programs in the system. This is so that any amendment to the program
should have little or no impact on other programs in the system. Programs should thus be developed
in modules.

Systems are broken down into modules because smaller programs (modules) are easier to specify, test and
modify than larger programs. Therefore errors of the impact of a change are confined within fewer lines of
code when modules are used. Programmers can also choose the area of the system that interests them to
code, which is motivating to them. A large number of small programs make rescheduling work easier i.e.
same programs can be assigned to someone else to write if the first programmer is taking longer than
estimated for a particular program.

For a system to be broken down into modules, a good system specification should be prepared.

System specification
It is a document prepared at the design stage of system development life cycle. It represents the conceptual
system or logical system. This is a system in paper form. Its contents are:
i) Introduction of existing system i.e. details of its objectives and a brief description of how these
objectives are met.
ii) Description of the proposed system i.e. details of its objectives and a description of how the
objectives are to be met.
iii) Justification of proposed system as a solution to the problem specified in terms of reference. Costs
and benefits justification for the proposed system should be shown.
iv) Comparison of both existing and proposed system in terms of inputs and outputs i.e.
specification of frequency, volume, timings etc.
v) Proposed system file descriptions: This should include file names, organization methods, access
methods, nature of the system, storage media, record structures and file activities.
vi) Proposed system control specifications i.e. error handling procedures, recovery procedures, in
built controls both hardware and software related.

3.6 System development

This involves programming, testing and documentation activities.

(a) Programming
This activity involves translation of system specification into program code. A programmer should integrate
user requirements into the computer system. Programming standards should be adhered to e.g. use of a
standard programming language. Decomposition of a program into smaller units or modules should be
implemented as per the design specifications. It is important that the programming team work in
cooperation to improve the quality of programs produced.

The contents of a good program specification are:

 Document details: This includes title, program identifier i.e. name, author, version number, reviewer
of the program etc.
 Introduction: contains a brief summary of what the program does in business application area
 Assumption and restriction: this lists any constraints on the program or information that affects the
logic of the problem.
 Attributes: this outlines the program environment e.g. hardware, operating system, programming
language etc
 Data: inputs and outputs of the program
 Functional description: the processing or tasks carried out to convert program input into meaningful
outputs
  Detailed processing requirement: indicates functional description i.e. low level detailed view of the
processing paths
 Operation consideration: Then describes how operations interact with the program in the normal
running and how he can recover to save state or restore the program if anything goes wrong
 Sub-routines: these are modules or segments used by the program as well as their input parameters.
 Messages: identifies message sent and received by the program and their purpose
 Print layout: Describes print or screen dialogue or layout of the program.

 (b) Testing
Generally all programs should be tested before system conversion. There are two major program-testing
techniques: white box and black box testing.

White box testing

It concentrates on internal construction of a program. It is carried out on the following:
i. Cyclomatic complexity - are measures of logical complexity of a program
ii. Graph matrix - are used for condition testing
iii. Data flow testing – commonly associated with SSADM. It is used to select paths of a program
according to location and definition of variables.
iv. The loop testing – it focuses on exclusive validity of loops within a program

Black box testing

It focuses on functional requirements of software. It attempts to find errors in the following categories:

 Incorrect or missing functions

 Interface errors
 Data structure errors
 Performance errors
 Initialisation and termination errors

These methods are based on the input and output to and from a program. They do not emphasize on the
internal structure of a program.

Software testing is conducted on the following aspects or stages:

(i) Unit testing: testing of program segments that do specific functions. It emphasizes on the local data
structure, boundaries, interfaces etc.
(ii) Module testing: involves testing of interrelated units within a program, which perform a specific
task. It emphasizes on local data structure, error handling and independent program parts. A module
is a segment of an entire system that does a specific task. Debugging and correction of errors during
each individual program segment could be part of module testing.
(iii) Integration testing: Also known as verification or program construction testing. It involves moving
downwards through a control hierarchy i.e. from subordinate modules it can either be top-down
integration or bottom-up integration. Top-down integration verifies major control and decision
points early in the testing process. Bottom-up integration uses drivers to coordinate a test case.
(iv) System testing: involves linking all modules of a suite to test whether they are interfacing properly.
Its primary purpose is to fully test functionality of a computer based system. Integration testing is
testing of modules during the time they are being linked up or combined together into a suite.
(v) Alpha and Beta testing: Alpha testing is testing that is conducted at the software developer’s site by
both the developer and the user or customer. Beta testing is testing a system at the user’s or
customer’s site. It is conducted by the end user of the system.
(vi) Configuration review: It is conducted to ensure that each element of the software is properly
developed i.e. to ensure that each module’s configuration is proper.
(vii) Recovery testing: Is conducted to force software to fail in a number of ways and verify that recovery
is properly performed.
(viii) Security testing: It attempts to verify that protection mechanism built into the system works.
(ix) Stress testing: Designed to confront a program with abnormal structure and abnormal quantity of
resources e.g. a large volume of transaction inputs to see how the program can cope up with such
abnormally.
(x) Performance testing: Conducted to evaluate the software performance e.g. run time, response time,
quality of output etc.
(xi) Acceptance testing: This is carried out by software users and management representation for the
following reasons:
 To discover software errors not yet detected
 To discover the actual and exact demands of the system
 To discover if any major changes required by the system can be adopted.

Structured walkthrough (peer review)

It is a planned review of system by people not involved in its development effort. It is carried out to establish
areas where improvement can be made in the system or its development process. The review is done by
between 5-10 people as a software quality assurance measure. Types of walkthrough include:

(i) Requirement review – It is conducted to examine a proposed system as formulated by the system
analyst. If there are any inconsistencies between the requirements stated by the users and those that
the analyst is proposing, the walkthrough should be able to uncover such inconsistencies so that they
can be dealt with early enough.
(ii) Design review – Its purpose is to determine whether the proposed design will meet the requirements
of the system and user. If the review team finds any discrepancies between the design and the
requirement, they should give solutions to such discrepancies.
(iii) Program review – This is conducted to examine the program development along with its
documentation. The programs are compared with their specific design specifications to determine
whether the specifications are being satisfied. Any programming errors are detected and dealt with.
(iv) Testing review – It assists in development of test data that can be used to detect system design errors.
The system testing strategy is not to prove programmer correctness but to assess reliability and
suitability of the system through detecting critical system errors.

Walkthrough team members include:

i. Chairman – He controls the overall direction of a walkthrough and ensures that its agenda is adhered
to. He gives approval by formally signing the project milestones when users are satisfied at each
development stage.
ii. Author – He is the creator or designer of the system. He presents and explains the materials that are
being walked through.
iii. Recorder – Acts as the secretary of the team and ensures that all agreed actions pointed out are noted
and followed up.
iv. Reviewers – They get in advance the materials being walked through as a working model. They walk
through the proposed system and checks whether it falls short of required quality.
v. User representative – Approve their understanding and satisfaction of what they will do with the
system when it becomes operational. The representatives may be senior managers, auditors etc.

A structured walkthrough is important because:

 It identifies errors, omissions and inconsistencies in a system

 It focuses on quality of and good practices in system operation generally
 It involves the users and gives them an opportunity to give a feedback on critical appraisal of their
work.
 It avoids description about who is responsible for what thus encouraging team work
 It reduces user resistance since they are incorporated and recognized by the development team.

(c) Documentation
Software documentation is a description of software or system after its development. Software product
therefore comprises of code and documentation. Documentation includes a wide range of technical and non-
technical manuals, books, descriptions and diagrams relating to the use and operation of produced software.
It is vital for software engineering to allocate adequate time to the software engineering particularly
documentation throughout its development.

Documentation is produced for:

 System developer – who will depend on documentation from previous life cycle stages to guide
continued development and subsequent maintenance of software or system.
 Management – who use documentation from past projects to plan and understand current projects
 System users – who learn how to use software or system from its narrative description or
documentation.

Objectives of good documentation

The following factors should be considered when preparing a good documentation:
 Documentation should be complete – This implies that all known aspects or components of
documents should be included.
 Documentation should be consistent – Inconsistency will destroy the reader’s confidence in the
documentation. The biggest challenge is not consistency in the original documentation but
maintaining consistency through all the changes the software may undergo.
 Documentation should be targeted at the right levels – i.e. for its intended audience e.g. a training
manual demands as much from its readers as design documentation to the programmer.

There are two major reasons why software engineers dislike producing documentation:

(i) They do not see the need for it because it may indicate that one is new to the profession and has
not yet had time to appreciate the benefits of documentation. It may indicate also that one is so
wrapped up in pressure of the moment that long-range goals have become absurd.
(ii) They do not feel capable of doing it. Although sometimes the feeling of inadequacy derives from
inability to talk about technical subjects with non-technical people.

Importance of system documentation

(i) It guides the development team at various stages of the development life cycle
(ii) Can be used as a system backup copy to recover the system should something happen to its
implementation
(iii) It aids or assists during system maintenance since it guides in identification of system modules
to be changed
(iv) It can effectively provide a checklist of items to be covered during subsequent system audit or
system maintenance
(v) It guides against loss of system understanding particularly when the author leaves the company
or dies
(vi) It may act as a training guide or document to new programmers, analysts or users who may join
after system implementation

Contents of system documentation

(i) Table of contents – acts as a document index
(ii) Introduction – indicates the system capabilities and constraints or limitations
(iii) System specification – it specifies the conceptual system in terms of process, data structures,
files etc.
(iv) A list of files to be used by the system – used for reference should something go wrong when
the system is live
(v) Test data – shows the data used to evaluate system functionality
(vi) Recover procedures – guides the user on how to recover the system should something go
wrong when the system is running
(vii) Samples of input and output data – these helps the user to identify errors when they occur
during system live-running
(viii) Back-up procedures – it advices the reader on how to make security copies of files for use to
recover the system in case something goes wrong during system live-running
 (ix) Contacts – Address or phone number to be used by the operator to seek help if other options
fail

System Documentation: Fact Recording tools and techniques

(1) Flowcharts
A flowchart is a diagrammatic representation that illustrates the sequence of operations performed to get to
the solution of a problem. Flowcharts facilitate communication between system analysts, system designers
and programmers.
Guidelines for drawing a flowchart
Flowcharts are usually drawn using some standard symbols. Some standard symbols used in drawing
flowcharts are:

Start or end of the program - terminator

Process - Computational steps or program processing

Alternate process

Decision making and branching

Data - Input or
output operation

Connector or joining of two parts of program

Magnetic
tape

Magnetic disk

Flow lines

Display

Document

Multiple documents

Stored data
The following are some guidelines in flowcharting:
 In drawing a proper flowchart, all necessary requirements should be listed out in logical order
 The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity in
understanding the flowchart
 The usual direction of the flow of a procedure or system is from left to right or top to bottom
 Only one flow line should come out from a process symbol

Or

 Only one flow line should enter a decision symbol, but two or three flow lines, one for each possible
answer, should leave the decision symbol

>0 <0

=0
 Only one flow line is used in conjunction with the termination symbol

 Write within the standard symbols briefly. As necessary, you can use the annotation symbol to describe
data or computational steps more clearly.

---------- - This is top-secret data

 If the flowchart becomes complex, it is better to use connector symbols to reduce the number of flow
lines. Avoid the intersection of flow lines if you want to make it more effective and better way of
communication.
 Ensure that the flowchart has a logical start and finish
 It is useful to test the validity of the flowchart by passing through it with simple test data.

TYPES OF FLOWCHARTS
Flowcharts are of three types:
 System flowcharts
 Run flowcharts
 Program flowcharts

System Flowcharts
System flowchart describes the data flow for a data processing system. It provides a logical diagram of how
the system operates. It represents the flow of documents, the operations performed in data processing
system. It also reflects the relationship between inputs, processing and outputs. Following are the features
of system flowcharts:
 The sources from which data is generated and device used for this purpose
 Various processing steps involved
 The intermediate and final output prepared and the devices used for their storage
The figure below is a sample of system flowchart for the following algorithm (step by step instructions on
how to perform a certain task):
 Prompt the user for the centigrade temperature.
 Store the value in C
 Set F to 32+(9C/5)
 Print the value of C, F
 Stop

System Flowchart

Run Flowcharts
Run flowcharts are used to represent the logical relationship of computer routines along with inputs, master
files transaction files and outputs.
The figure below illustrates a run flowchart.
Run Flowchart

Program Flowcharts
A program flowchart represents, in detail, the various steps to be performed within the system for
transforming the input into output. The various steps are logical/ arithmetic operations, algorithms, etc. It
serves as the basis for discussions and communication between the system analysts and the programmers.
Program flowcharts are quite helpful to programmers in organizing their programming efforts. These
flowcharts constitute an important component of documentation for an application.
The figure represents a program flowchart for finding the sum of first five natural numbers (i.e. 1,2,3,4,5).

Program Flowchart

Advantages of using flowcharts

 Communication: Flowcharts are better ways of communicating the logic of a system to all concerned.
 Effective analysis: With the help of flowchart, problem can be analysed in more effective way.
  Proper documentation: Program flowcharts serve as a good program documentation, which is
needed for various purposes
 Efficient coding: The flowcharts act as a guide or blueprint during the systems analysis and program
development phase.
 Proper debugging: The flowchart helps in the debugging process.
 Efficient program maintenance: The maintenance of operating program becomes easy with the help
of flowchart. It helps the programmer to put efforts more efficiently on that part.

Limitations of using flowcharts

 Complex logic: Sometimes, the program logic is quite complicated. In that case, flowchart becomes
complex and clumsy.
 Alterations and modifications: If alterations are required the flowchart may require redrawing
completely.
 The essentials of what is done can easily be lost in the technical details of how it is done.
(2) Data flow diagram
Data Flow Diagram (DFD) is a graphical representation of a system’s data and how the processes transform
the data. Unlike, flowcharts, DFDs do not give detailed descriptions of modules but graphically describe a
system’s data and how the data interact with the system.
Components of DFD
DFDs are constructed using four major components
 External entities
 Data stores
 Processes and
 Data flows
(i) External Entities
External entities represent the source of data as input to the system. They are also the destination of system
data. External entities can be called data stores out side the system. These are represented by squares.
(ii) Data Stores
Data stores represent stores of data within the system. Examples, computer files or databases. An open-
ended box represents a data/store – data at rest or a temporary repository of data.
(iii) Process
Process represents activities in which data is manipulated by being stored or retrieved or transferred in some
way. In other words we can say that process transforms the input data into output data. Circles stand for a
process that converts data into information.
(iv) Data Flows
Data flow represents the movement of data from one component to the other. An arrow identifies data flow
– data in motion. It is a pipeline through which information flows. Data flows are generally shown as one-
way only. Data flows between external entities are shown as dotted lines.
Physical and Logical DFD
A logical DFD of any information system is one that models what occurs without showing how it occurs.
An example is illustrated below.

It is clear from the figure that orders are placed, orders are received, the location of ordered parts is
determined and delivery notes are dispatched along with the order. It does not however tell us how these
things are done or who does them. Are they done by computers or manually and if manually who does
them?
A physical DFD shows, how the various functions are performed? Who does them? An example is
illustrated below:

The figure is opposite to that of the logical DFD, it shows the actual devices that perform the functions. Thus
there is an "order processing clerk", an "entry into computer file" process and a "run locate program" process
to locate the parts ordered. DFD(s) that shows how things happen, or the physical components are called
physical DFD(s).
Typical processes that appear in physical DFDs are methods of data entry, specific data transfer or
processing methods.
Difference between Flowcharts and DFD
The program flowchart describes boxes that describe computations, decisions, interactions and loops. It is
important to keep in mind that data flow diagrams are not program flowcharts and should not include
control elements. A good DFD should:
 Have no data flows that split up into a number of other data flows
 Have no crossing lines
 Not include flowchart loops of control elements
 Not include data flows that act as signals to activate processes.

(3) Decision Tables

This is a matrix representation of the logic of a decision. It specifies the possible conditions and the resulting
actions. It is best used for complicated decision logic. It consists of the following parts:

 Condition stubs
o Lists condition relevant to decision
 Action stubs
o Actions that result from a given set of conditions
 Rules
o Specify which actions are to be followed for a given set of conditions
An indifferent condition is a condition whose value does not affect which action is taken for two or more
rules.
The Condition stub contains a list of all the necessary tests in a decision table. In the lower left-hand corner
of the decision table we find the action stub where one may note all the processes desired in a given module.
Thus Action Stub contains a list of all the processes involved in a decision table.
The upper right corner provides the space for the condition entry - all possible permutations of yes and no
responses related to the condition stub. The yes and no possibilities are arranged as a vertical column called
rules. Rules are numbered 1,2,3 and so on. We can determine the rules in a decision table by the formula:

Number of rules = 2^N = 2N where N represents the number of condition and ^ means exponentiation.
Thus a decision table with four conditions has 16=(24 =2  2  2  2 = 16) rules. One with six conditions has
64 rules and eight conditions yield 256 rules.
The Condition entry contains a list of all the yes/no permutations in a decision table. The lower right corner
holds the action entry. X’s or dots indicate whether an action should occur as a consequence of the yes/no
entries under condition entry. X’s indicate action; dots indicate no action.
Thus Action entry indicates via dot or X whether something should happen in a decision table
The standard procedure for creating decision tables involves:
(i) Name the condition and each values each condition can assume
(ii) Name all possible actions that can occur
(iii) List all the rules
(iv) Define the actions for each rule
(v) Simplify the table
Example: Complete decision table for payroll system

Conditions / Rules
Courses of action 1 2 3 4 5 6

Condition S H S H S H
Stubs Employee Type
Hours Worked <40 <40 40 40 >40 >40

Action Stubs Pay Base Salary X X X

Calculate Hourly X X X
wage
Calculate Overtime X
Produce Absence X
Report

(4) Decision Trees

This is a graphical representation of a decision situation. Decision situation points are connected together
by arcs and terminate in ovals. The two main components are:
 Decision points represented by nodes
 Action represented by ovals
The decision tree defines the conditions as a sequence of left to right tests. A decision tree helps to show the
paths that are possible in a design following an action or decision by the user. Decision tree turns a decision
table into a diagram. This tool is read from left to right, decision results in a fork, and all branches end with
an outcome. Each node corresponds to a numbered choice on the legend. All possible actions are listed on
the far right.
 Yes
Pay Base
1 Salary

No
Yes Pay Hourly
Wage;
2
Absence

No
Yes
Pay Hourly
Legend
Wage
1) Salaried? 3
2) Hours Worked < 40?
3) Hours Worked = 40?
No

Pay Hourly
Wage; Pay
Overtime

(1) Structured English

This is a modified form of English used to specify the logic of information processes. It uses a subset of
English.
 Action verbs
 Noun phrases
 No adjective or adverbs
There are no specific standards and is similar to programming languages.
 If conditions
 CASE statements

. 3.7 System implementation

This phase involves the following activities:

a) Hardware selection, acquisition and installation
b) User training
c) File conversion/creation
d) Changeover

Hardware and software acquisition

A user may acquire the hardware and software directly from a manufacturer and developer respectively.
He may also purchase them from an intermediate supplier. Whichever way, carefully controlled purchasing
procedures should be followed. The procedures should include invitation to tender and comparative
analysis to determine the appropriate supplier of the required hardware and software.

Invitation to tender (ITT)

It is issued to a range of suppliers. ITT sets out specifications for the required equipment and software and
should explore how the hardware will be used and the time scale for implementation. It sets the performance
criteria required for the new system.
Contents of ITT
ITT includes background information about the companies together with an indication of the purpose of the
system. This includes:

(i) The volume of data to be processed by the system. Complexity of the processing requirements
and system interfaces should be stated.
(ii) The number of individuals who will want to access the computer system after installation and
whether access needs to be instant or not
(iii) The speed of processing required or expected
(iv) Input and output desired
(v) The type of processing methods preferred
(vi) Estimated life of the system
(vii) Possible upgrades or expansion anticipated
(viii) Other general consideration include:

 Contact person in the company

 Overall financial constraints
 The form that submission is to take
 Closing date for submission of tender
 The address to which the tender is to be sent
 The reference person to which tender is to be addressed

While all the above features are necessary, it is important to decide on the financing methods. These may
include:

a) Purchasing – where the buyer acquires ownership of item after payment of an agreed amount
b) Leasing – involves formation of an agreement between lessee and lessor detailing the use of
equipment, the length of time to use the equipment and the periodical payment
c) Renting – involves a single agreement where one party agrees to use another party’s resources at
certain periodical payments. The agreement is not as binding as that of a lease agreement.

Evaluation of a vendor proposal

(1) Benchmark tests – tests how long it takes for a machine to run through a particular set of
programs. It is carried out to compare performance of software/hardware against present criteria
such as performance speed, response times and user friendliness of the equipment.

(2) Simulation tests – it uses synthetic program written specifically for testing purposes. They are
programs incorporated with routines designed to test a variety of situations. Other features or
factors include:

i. Supplier’s reliability – both financial stability and track record

ii. Cost – equipment cost, installation cost and training costs
iii. Utility software supported and preloaded in the hardware
iv. The warrant period, units and maintenance commitments
v. Software support upgrades and maintenance
vi. Training requirements which includes timings, number of personnel etc

Choosing hardware and software

Software factors

Factors influencing choice of software includes:

 (i) User requirements: the selected software or package should fit user requirement as closely as
possible
(ii) Processing time: these involves the response time e.g. if the response time is slow the user might
consider the software or package as unsuccessful
(iii) Documentation: the software should be accompanied by manual, which is easy to understand by
non-technical person. The manual should not contain technical jargon.
(iv) User friendliness: the package should be easier to use with clear on screen prompts, menu driven
and extensive on screen help facility
(v) Controls: the software should have in-built controls which may include password options,
validation checks, audit trails or trace facilities etc
(vi) Up-to-date: the software should be up-to-date e.g. should have changes or corrections in line with
business procedures
(vii) Modification: one should consider whether the user could freely change the software without
violating copyright.
(viii) Success in the market: one should consider how many users are using the software and how long
it has been in the market
(ix) Compatibility of the software: how the software integrates with other software particularly the
operating system and the user programs
(x) Portability: one should consider how the software runs on the user computer and whether there
will be need for the user to upgrade his hardware
(xi) Cost: the user company should consider its financial position to establish whether it can afford the
software required for efficient operations rather than the least cost package software available.

Software contracts
Software contracts include the costs, purpose and capacity of the software. The following are covered in
software contracts:
 Warrant terms
 Support available
 Arrangement for upgrades
 Maintenance arrangements
 Delivery period/time especially for written software
 Performance criteria
 Ownership

Software licensing
Software licensing covers the following:
 Number of users that can install and use the software legally
 Whether the software can be copied without infringing copyrights
 Whether it can be altered without the developers consent
 Circumstances under which the licensing can be terminated
 Limitation of liability e.g. if the user commits fraud using the software
 Obligation to correct errors or bugs if they exist in the software

Hardware factors
Custom-built hardware is a rare necessity. Most hardware is standard, compatible, off-the-shelf
components. It is cheaper, easy to maintain, and ensures compatibility with equipment in your organization
and your partners and clients.

The system analysis and design should have precisely determined what sort of hardware is needed - down
to the make and model.

The decision of hardware choice must consider many factors:

 Future needs - can the equipment be expanded or added to?
 Availability (is it only available overseas?)
  Capacity (e.g. is the hard disk big enough to hold all your data? Is it fast enough?)
 Reliability - can it be depended on?
 Cost - initial cost, running costs, upgrade costs, repair costs, training costs
 Compatibility - with your other equipment, and that of your partners and clients
 Warranty and support - in case of failure or problems
 Ease of use and installation
 Compliance with local conditions (e.g. power supplies must be 240V or compliant with
telecommunication systems)
Choosing a supplier
After choosing the hardware equipment and the equipment makers (manufacturers), one must choose a
supplier or reseller (in other words, once you know what you want to buy, what shop will you choose?)

Factors to consider:
 Reputation for support (e.g. phone support, onsite visits, website help)
 Reputation for reliability, honesty, permanence (very important!)
 Knowledge of the equipment
 Geographic location - can you get to them easily if you need to?
 Ability to offer onsite support or repair
 Prices – cheap, affordable
Installation
Software and hardware installation is done by supplier’s technicians or the user organization appointed
person to avoid the risks associated with improper installation of the equipment. The system analyst and
other development team members may be called to assist where appropriate.

User training
It is important that the system users be trained to familiarize themselves with the hardware and the system
before the actual changeover.
The aims of user training are:

a) To reduce errors arising from learning through trial and error

b) To make the system to be more acceptable to the users
c) To improve security by reducing accidental destruction of data
d) To improve quality of operation and services to the users
e) To reduce the cost of maintenance by minimizing accidental destruction of data or hardware
f) To ensure efficiency in system operation when it goes live

The persons to be trained include system operators, senior managers, middle managers and all those
affected by the system directly or indirectly. Training should cover current staff and recruited personnel.

Timing of user’s training

 Before the feasibility study when the users are given a general explanation of computer systems,
their relevance in function application and reason for desire to introduce a computer in the specific
functions
 Before investigation where users are explained about the impact of the new system and importance
of their involvement in development. This may help gain user confidence and facilitate their
acceptance of the system
 During fact finding so that they can cooperate and provide useful information to guide the system
developer during the analysis stage of SDLC
 Before programming so that they can prepare themselves for specific roles at implementation stage.
These may include testing activities or roles.
 Before implementation to enable the users to cooperate and play their roles as assigned to them
 After implementation in order to assist in evaluation of system performance
File conversion
This involves changing of existing form of files into a form suitable for the new system when it becomes
operational. It may require that the analyst create the file from scratch if no computer-based files exist. In an
event that computer-based files exist they should be converted to a form relevant or sensible to the new
system.

File conversion procedures

(i) Record manually the existing data i.e. the old master files
(ii) Transfer the recorded data to special form required by the new system
(iii) Insert any new data into the file i.e. update the file already in the new form (form should include
data contents and their corresponding formats and layouts)
(iv) Transcribe the completed form into a medium or storage relevant for the new system
(v) Validate the file contents to ensure that they are error free before they can be used in the new system

Problems associated with file creation or file conversion are:

 Records may be stored or located at different places or locations, thus may be difficult to gather them all
 Some records may require updating which may slow down the change over plan
 Records may be too numerous i.e. too large in volume which may slow down the change over plan since
transcription will take long
 Some records may not exist at all e.g. a customer who makes an order through a phone call

File conversion methods include:

 Straight file conversion/creation
 Dummy file conversion/creation
 Phased file conversion/creation

Straight file conversion

The method requires that the new system files be created moments before the planned change over. It is
important to note that it is only suitable for small size files. Otherwise it may delay system implementation
plan. The actual data or real data would be used instead of dummy data. This implies that once created, files
are already in the form suitable for the new system.

Dummy file conversion

It requires that files be created long before the planned changeover. Dummy records are used which are
replaced with the actual records immediately before change over. The method is ideal when dealing with
large volumes of transaction files or master files. It enables file creation activities to be spread over a long
period.

Phased file conversion

It requires that the files be converted by bit-by-bit phases. This implies that instead of changing, for example,
a whole department file, the file is changed on section-by-section basis. It may suitably be applicable on
phased change over method.

System change-over
Involves changing or switching from existing system to the new developed system. The following methods
may be used:

(i) Direct change-over

(ii) Parallel change-over
(iii) Phased change-over
(iv) Pilot change-over
Direct changeover
The old system ceases its operation and the new system commences operation the next day. The old system
is made redundant in all its aspects. The method is applicable in the following circumstances:

 When the new system is small and simple

 When both the new and old system are substantially different
 When extra staff to oversee or undertake parallel running of both systems are unavailable
 When the management has complete confidence that the new system will work

The advantages of a direct changeover are:

 Relatively cheap
 Prevents the weaknesses of the old system from being passed over to the new system
 Reduces system implementation duration

Its disadvantages are:

 It is very risky especially if the new system fails. The cost of switching back to the old system will be
high
 If not properly planned, it may interrupt user organization operations and bring confusion amongst
staff members

Parallel changeover
This is a method where new and old systems are allowed to run side by side or simultaneously until it is
proved beyond reasonable doubt that the new system is working and all the benefits are realized. It is
suitable when the new system is sophisticated and a very careful changeover is required or when the
development team has little confidence in the new system and where there are more staff to cope with the
operations of both system running in parallel.

Its advantages are:

 Users become familiar with the new system prior to the actual changeover which may enhance their
efficiency
 The organization is exposed to less risks in case the new system fails
 There would be less interruption and inconveniences in the organization operations during the
changeover period.

The disadvantages of this method are:

 It is an expensive method
 It might delay system implementation schedule or period

Phased changeover
The method involves implementation of a system on step-by-step approach. This implies that only a portion
of the system is implemented initially. Other portions are implemented in phases. For example if it has
modules for finance, production and human resource management, then the finance module is implemented
first, then the production and lastly the human resource management module.

Pilot changeover
It involves installation of new system but using it only in one part of the organization on an experimental
basis. E.g. a bank wishing to computerize its operations may install a computerized system on one branch
on experimental basis. When the system is proved to be successful, it is transferred to another branch and
after some time to another etc until the entire bank is computerized. Any refinement that ought to be done
on the system should be done before it is installed in the next branch.

NB: The whole system is implemented on a section of the organization.

Both phased and pilot changeover methods have the following advantages and disadvantages.

Advantages are:
  Allows a new system to be implemented quickly with minimum costs
 Allow training of personnel on the new system during implementation
 They cause minimum interruption to company operations during system’s implementation
 The peak demands are lighter on the end user and the operational environment
 They are less costly
 The risks associated with errors and system failure are minimized

The disadvantages include:

 Interfacing both the old and new system may usually bring problems
 There may be additional costs associated with running both systems at the same time

The change over plan should include the following:

(i) Time limit for the parallel run
(ii) Instructions on error handling procedures
(iii) Instruction on how to cope with major problems in the new system