////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

SYSTEM DEVELOPMENT LIFE CYCLE

The stages of developing a system are called the System development life cycle (SDLC).
The main stages in system development include:
1. Problem definition
2. Feasibility study
3. Requirement specifications
4. Systems design
5. System development
6. System Implementation
7. System Maintenance
8. System Review
9. System maintenance

1) PROBLEM RECOGNITION AND DEFINITION

Problem recognition is done during the Preliminary investigation. A preliminary investigation
is carried to find out if really there is need for change.
During the problem recognition stage, the system analyst seeks to answer two questions:
 Is the proposed project worth looking at?
 Is the project worth pursuing?

After this, the system analyst then defines the scope of the project and tries to establish the
limitations (risks involved), the budget (i.e., cost, resources/manpower involved) & time involved.
Some of the most common limitations are:
 Lack of finance, and lack of appropriate technology (expertise) to develop the system.

Problem definition

Problem definition is the process of identifying & understanding the problem, and finding out any
limitations that may limit the solution.

At this stage, the system analyst is required to find out much about the existing system (whether
manual or computerized) in order to come up with a good & relevant proposal for the new system.

1
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

FEASIBILITY STUDY

A special study called a feasibility study is carried out. A Feasibility study is a study carried out
to establish the costs & benefits of the proposed new system.

Feasibility Study can be considered as preliminary investigation that helps the management to take
decision about whether study of system should be feasible for development or not.

The study tries to;

 Justify the new system in terms of the capital to be employed, equipment required, personnel,
and the procedures necessary for the new system.
 Determine whether the existing system, be it manual, mechanical or computerized, is
adequate, or it should be modified, updated or replaced
 It identifies the possibility of improving an existing system, developing a new system, and
produce refined estimates for further development of system
 It is used to obtain the outline of the problem and decide whether feasible or appropriate
solution exists or not
 The main objective of a feasibility study is to acquire problem scope instead of solving the
problem
 The output of a feasibility study is a formal system proposal act as decision document which
includes the complete nature and scope of the proposed system.

IMPORTANCE OF FEASIBILITY STUDY

 Improves project teams’ focus

 Identifies new opportunities
 Provides valuable information for a “go/no-go” decision
 Narrows the business alternatives
 Identifies a valid reason to undertake the project
 Enhances the success rate by evaluating multiple parameters
 Aids decision-making on the project
 Identifies reasons not to proceed

2
Steps Involved in Feasibility Analysis

The following steps are to be followed while performing feasibility analysis −

 Form a project team and appoint a project leader.

 Develop system flowcharts.
 Identify the deficiencies of current system and set goals.
 Enumerate the alternative solution or potential candidate system to meet goals.
 Determine the feasibility of each alternative such as technical feasibility, operational
feasibility, etc.
 Weight the performance and cost effectiveness of each candidate system.
 Rank the other alternatives and select the best candidate system.
 Prepare a system proposal of final project directive to management for approval.

TYPES OF FEASIBILITIES

a) Economic Feasibility

 It is evaluating the effectiveness of candidate system by using cost/benefit analysis method.

 It demonstrates the net benefit from the candidate system in terms of benefits and costs to
the organization.
 The main aim of Economic Feasibility Analysis (EFS) is to estimate the economic
requirements of candidate system before investments funds are committed to proposal.
 It prefers the alternative which will maximize the net worth of organization by earliest and
highest return of funds along with lowest level of risk involved in developing the candidate
system.

b) Technical Feasibility

 It investigates the technical feasibility of each implementation alternative.

3
  It analyzes and determines whether the solution can be supported by existing technology
or not.
 The analyst determines whether current technical resources be upgraded or added it that
fulfill the new requirements.
 It ensures that the candidate system provides appropriate responses to what extent it can
support the technical enhancement.

c) Operational Feasibility

 This assessment involves undertaking a study to analyze and determine whether—and how
well—the organization’s needs can be met by completing the project. Operational
feasibility studies also examine how a project plan satisfies the requirements identified in
the requirements analysis phase of system development.
 It determines whether the system is operating effectively once it is developed and
implemented.
 It ensures that the management should support the proposed system and its working
feasible in the current organizational environment.
 It analyzes whether the users will be affected and they accept the modified or new business
methods that affect the possible system benefits.
 It also ensures that the computer resources and network architecture of candidate system
are workable.

d) Behavioral Feasibility

 It evaluates and estimates the user attitude or behavior towards the development of new
system.
 It helps in determining if the system requires special effort to educate, retrain, transfer, and
changes in employee’s job status on new ways of conducting business.

e) Schedule Feasibility
 This assessment is the most important for project success; after all, a project will fail if not
completed on time. In scheduling feasibility, an organization estimates how much time the
project will take to complete
 It ensures that the project should be completed within given time constraint or schedule.
 It also verifies and validates whether the deadlines of project are reasonable or not.
f) Legal Feasibility
 This assessment investigates whether any aspect of the proposed project conflicts with
legal requirements like copyright laws, data protection acts or social media laws.

4
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

INFORMATION GATHERING TECHNIQUES

The main aim of fact finding techniques is to determine the information requirements of an
organization used by analysts to prepare a precise SRS understood by user.

Ideal SRS Document should

 Be complete, Unambiguous, and Jargon-free.

 specify operational, tactical, and strategic information requirements.
 solve possible disputes between users and analyst.
 use graphical aids which simplify understanding and design.

Objectives of fact-finding.
The main objectives of fact-finding are:
 To find out what the present system is attempting to do, its scope and objectives.
 To collect information about the input of the present system.
 To find out the volume of input. This directly affects the design of the new system.
 To find out about the files maintained by the present system.
 To find out about the processing carried out by the system.
 To find out how the files are updated & outputs produced.
 To find out what equipment are used.
 To find out about the accuracy checks performed during processing.
 To find about time limitations, if any.
 To find out about the organization structure of the departments and the sections presently
carrying out the processing tasks.
 To find out the problems & difficulties presently encountered as the system operates, with
special reference to the barriers, duplication, and weakness.
 To ascertain the cost of the present system.

THERE ARE VARIOUS INFORMATION GATHERING TECHNIQUES (FACT FINDING

TOOLS)

a) INTERVIEWING

Systems analyst collects information from individuals or groups by interviewing. The analyst can
be formal, legalistic, play politics, or be informal; as the success of an interview depends on the
skill of analyst as interviewer.

It can be done in two ways −

5
  Unstructured Interview − The system analyst conducts question-answer session to
acquire basic information of the system.
 Structured Interview − It has standard questions which user need to respond in either
close (objective) or open (descriptive) format.

Advantages of Interviewing

 This method is frequently the best source of gathering qualitative information.

 It is useful for them, who do not communicate effectively in writing or who may not have
the time to complete questionnaire.
 Information can easily be validated and cross checked immediately.
 It can handle the complex subjects.
 It is easy to discover key problem by seeking opinions.
 It bridges the gaps in the areas of misunderstandings and minimizes future problems.

b) QUESTIONNAIRES

This method is used by analyst to gather information about various issues of system from large
number of persons.

There are two types of questionnaires −

 Open-ended Questionnaires − It consists of questions that can be easily and correctly

interpreted. They can explore a problem and lead to a specific direction of answer.
 Closed-ended Questionnaires − It consists of questions that are used when the systems
analyst effectively lists all possible responses, which are mutually exclusive.

Advantages of questionnaires

 It is very effective in surveying interests, attitudes, feelings, and beliefs of users which are
not co-located.
 It is useful in situation to know what proportion of a given group approves or disapproves
of a particular feature of the proposed system.
 It is useful to determine the overall opinion before giving any specific direction to the
system project.
 It is more reliable and provides high confidentiality of honest responses.
 It is appropriate for electing factual information and for statistical data collection which
can be emailed and sent by post.

c) REVIEW OF RECORDS, PROCEDURES, AND FORMS

Review of existing records, procedures, and forms helps to seek insight into a system which
describes the current system capabilities, its operations, or activities.

Advantages

6
  It helps user to gain some knowledge about the organization or operations by themselves
before they impose upon others.
 It helps in documenting current operations within short span of time as the procedure
manuals and forms describe the format and functions of present system.
 It can provide a clear understanding about the transactions that are handled in the
organization, identifying input for processing, and evaluating performance.
 It can help an analyst to understand the system in terms of the operations that must be
supported.
 It describes the problem, its affected parts, and the proposed solution.

d) OBSERVATION

This is a method of gathering information by noticing and observing the people, events, and
objects. The analyst visits the organization to observe the working of current system and
understands the requirements of the system.

Advantages

 It is a direct method for gleaning information.

 It is useful in situation where authenticity of data collected is in question or when
complexity of certain aspects of system prevents clear explanation by end-users.
 It produces more accurate and reliable data.
 It produces all the aspect of documentation that are incomplete and outdated.

e) JOINT APPLICATION DEVELOPMENT (JAD)

It is a new technique developed by IBM which brings owners, users, analysts, designers, and
builders to define and design the system using organized and intensive workshops. JAD trained
analyst act as facilitator for workshop who has some specialized skills.

Advantages of JAD

 It saves time and cost by replacing months of traditional interviews and follow-up
meetings.
 It is useful in organizational culture which supports joint problem solving.
 Fosters formal relationships among multiple levels of employees.
 It can lead to development of design creatively.
 It Allows rapid development and improves ownership of information system.

f) SECONDARY RESEARCH OR BACKGROUND READING

This method is widely used for information gathering by accessing the gleaned information. It
includes any previously gathered information used by the marketer from any internal or external
source.

Advantages

7
  It is more openly accessed with the availability of internet.
 It provides valuable information with low cost and time.
 It acts as forerunner to primary research and aligns the focus of primary research.
 It is used by the researcher to conclude if the research is worth it as it is available with
procedures used and issues in collecting them.

g) 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.
Revision Questions.

 State and explain four methods that can be used to gather information during system
development.
 Identify three disadvantages of the observation method used in fact-finding.
 Outline three disadvantages of Questionnaires
 State two advantages and two disadvantages of the interview method when used for
information gathering.
 Explain the concept of proxemics in interviews.
 (a) Explain the importance of using automated methods in fact finding.
(b) Give one example of automated information gathering technique.
PREPARING AND PRESENTING THE FACT-FINDING REPORT:

After gathering the information/facts, the system analyst must come up with a requirements
definition report, which must contain the following details:

1. Cover letter addressed to the management and the IT task force written by the person who
gathered the facts.

2. Title page, which includes; the Name of the project, Name of the analyst, and the Date the
proposal is submitted.

3. Table of contents.

4. Executive summary, which includes recommendations of the system analyst of how the new
system is to be implemented. This is because; some people only read the summary to make
decisions.

8
5. Outline of the system study, which provides information about all the methods used in the
study, who and what was studied.

6. Detailed results of the study, which provides details of what the system analyst has found out
about the system, e.g., problems, limitations, and opportunities that call for an alternative.

7. Summary – a brief statement that reflects the contents of the report. It also stresses on the
importance of the project.

This report is then presented to the Management for evaluation and further guidance.

9
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
REQUIREMENTS SPECIFICATION
In requirements specification, the system analyst must come up with detailed requirements for the
new system.
The following requirements specifications are considered:
1. Output specification.
2. Input specification.
3. File/data structures.
4. Hardware & software requirements.

Output requirements.

In system development, the output requirements of the new system are considered first. This is
because; the main interest from a system is information (output), e.g., the main concern of a library
management system is whether the system can generate reports on overdue books, charges of late
return, inventory reports, etc.

The output is usually in the form of reports either in the form of hardcopy or softcopy.

The following factors should be considered when designing the output:

i). Target audience: - a user report may show only the transactions to be carried out, while the
management would require a summary of the overall performance in the organization.

ii). Frequency of report generation (i.e., the time at which the output is required): - some reports
are required daily, others weekly, monthly or annually.

iii). Quality and format of information to be generated.

iv). Cost of producing the output: - the output should be at reasonable cost.
v). Mode of output & devices used for output, e.g., softcopy mode of output is produced through
the screen.

After designing the output, it should be approved by the users, the management, and other staff
within the organization who are affected by the change.

10
Input specifications.

Once the system analyst has identified the output requirements for the new computerized system,
he/she then identifies the input needed to obtain the relevant information from the system.
The input to the system is necessary because the contents of input are used to maintain the master
files.
The system analyst should therefore decide on:
1. The contents & volume of input, and whether these contents can grow.
2. The mode of input, the devices of input selected and their suitability.
3. The format & sequence of input.
4. The nature of the system, which determines the frequency of input, e.g., for Batch processing,
the frequency would be periodical, and for Real-time systems, it would be on-demand.

After identifying all the inputs, the analyst designs the user interface by designing data entry forms
or screens.
When designing the user interface, the following guidelines should be observed:
a). Objects such as Textboxes, Labels, and Command buttons placed on the forms must be neatly
aligned & balanced on the form.
b). The size of the form should not be too small for the user to read or too big to fit on the screen.
c). The colour of the interface should not be too bright to avoid hurting the eye.

File requirements specification.

This involves identifying the files required to store data & information in the system.

The system analyst should:

a). Identify the number of files that will be needed by the system.
b). Determine the structure of each of the files, e.g., will the files allow direct access? Will they
be sequential files stored on a magnetic tape?
c). Identify the attributes of the records in a file.

An Attribute is a unique characteristic of a record for which a data value can be stored in the
system database.
Note. These attributes are used when designing tables in a database, and each attribute
becomes a field in the table.

11
 For example;

A Books table will have the following attributes/fields: Book ID, ISBN number, Title,
Author’s name, Year of publication, Date of issue and Date of return.

Book ID ISBN No. Title Author’s Name Year of Date issued Date of return
publication

Factors to consider when designing a good file.

1. Record key field: - this is usually an attribute that is unique for each record.

2. Data type for each field: - each field has a data type. In a database, the data type of book titles
can be stored as ‘Text’, while the Date of borrowing a book can be stored as ‘Date/Time’.

3. Length of each field: - a field used to store names can be specified to be 30 characters long,
while a field used to store numbers/integers can be specified to be 10 characters long.

4. Backup and recovery strategies: - the updated copies of data & information files need to be
stored in a different place other than the location of the current system. This ensures that, if
the current file gets corrupted, the backed up data can be used to recover/reconstruct the
original file.

Hardware & software requirements.

The system analyst should specify all the hardware & software requirements for the new system.
The hardware & software used to develop the system mainly depends on Input, Output & File
requirements, e.g., if the system requires data in picture format, then an image capturing device
such as a Digital camera or a Scanner must be used.
Some of the factors to consider in hardware & software specification are:

1. Cost (price)
2. Method of acquisition.
3. Reliability & security features.
4. Upgradeability.
5. Compatibility with the existing resources.
6. User friendliness.

12
7. User requirements (user needs)
8. Portability, etc

Revision Questions.

1. Outline the four areas that are considered during the requirements specification stage.
2. Explain at least three factors that should be put into consideration during output design.
3. (a) State four factors that may be considered in order to design a good file.
(b) Define the term ‘Attribute’.
(c) Explain why it is important to consider the file backup and recovery strategies during file
design.
4. Outline the factors that should be considered when sourcing for hardware and software
resources required for a new system.

13
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SYSTEM CODING/ CONSTRUCTION
System construction refers to the coding, installation and testing of the modules and their
components such as outputs, inputs & files.
The purpose of the construction stage is to develop & test a functional system that fulfils the design
requirements of a particular organization. coding

System construction is done by programmers.

System construction languages
To construct a system, the programmer can use the following programming languages:
1). Use the high-level structured languages, e.g., Pascal, COBOL, etc
2). Use the 4th generation languages, e.g., Visual Basic, Visual COBOL, Delphi Pascal, etc
3). Customize & use a ready-made standard package such as a database software, financial
package or enterprise management system.

14
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SYSTEM DESIGN
In the design stage, the analyst must come up with ways of solving the problem.
The following are some of the tools used for designing an information system:
i). System flowcharts.
ii). Data flow diagrams.
iii). Entity relationship models.
iv). Structured charts.
v). User Case diagrams
vi). Data dictionary
vii). Decision tables
viii). Pseudocode
ix). Structured English
x). Hierarchical input process output (HIPO)

How they work

Circumstances where they can be applied
Advantages and disadvantages
************Notes and To be completed and shared in due course ****************

15
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

SYSTEM TESTING

Testing is the process or activity that checks the functionality and correctness of software
according to specified user requirements in order to improve the quality and reliability of system.
It is an expensive, time consuming, and critical approach in system development which requires
proper planning of overall testing process.

After constructing the system, it is tested by entering some test data to find out whether its outputs
are as expected.

A successful test is one that finds the errors. It executes the program with explicit intention of
finding error, i.e., making the program fail. It is a process of evaluating system with an intention
of creating a strong system and mainly focuses on the weak areas of the system or software.

When the system is newly developed, it can be first tested using dummy (assumed) data, while
real/live test data can be used for normal circumstances to find whether the system can detect &
report errors.
System testing is carried out in order to achieve the following aims:
 To test the programs further to detect any errors. This is because; after testing the programs,
some errors might have gone unnoticed.
 To find out whether the system meets all requirements specified.
 To establish whether the programs work interactively as a suite of programs.
 To find out whether there is a link between the clerical & computer procedures.

During system testing, the following details should be checked:

 Files maintained in connection to the information requirements of the system.
 Input to the system, for the maintenance of the existing files.
 Processing tasks.
 Reports generated by the system.
 Controls incorporated within the system.

Different testing techniques are used at different times while testing the system. It is conducted by
the developer for small projects and by independent testing groups for large projects.

16
STAGES OF SYSTEM TESTING

The following stages are involved in testing −

1) TEST STRATEGY

It is a statement that provides information about the various levels, methods, tools, and
techniques used for testing the system. It should satisfy all the needs of an organization.

2) TEST PLAN

It provides a plan for testing the system and verifies that the system under testing fulfils all the
design and functional specifications. The test plan provides the following information −

 Objectives of each test phase

 Approaches and tools used for testing
 Responsibilities and time required for each testing activity
 Availability of tools, facilities, and test libraries
 Procedures and standards required for planning and conducting the tests
 Factors responsible for successful completion of testing process

3) TEST CASE DESIGN

 Test cases are used to uncover as many errors as possible in the system.
 A number of test cases are identified for each module of the system to be tested.
 Each test case will specify how the implementation of a particular requirement or design
decision is to be tested and the criteria for the success of the test.
 The test cases along with the test plan are documented as a part of a system specification
document or in a separate document called test specification or test description.

4) TEST PROCEDURES
 It consists of the steps that should be followed to execute each of the test cases. These
procedures are specified in a separate document called test procedure specification. This
document also specifies any special requirements and formats for reporting the result of
testing.
5) TEST RESULT DOCUMENTATION
 Test result file contains brief information about the total number of test cases executed, the
number of errors, and nature of errors. These results are then assessed against criteria in
the test specification to determine the overall outcome of the test.

TYPES OF TESTING
Testing can be of various types and different types of tests are conducted depending on the kind
of bugs one seeks to discover;

1) UNIT TESTING

17
Also known as Program Testing, it is a type of testing where the analyst tests or focuses on each
program or module independently. It is carried out with the intention of executing each statement
of the module at least once.

 In unit testing, accuracy of program cannot be assured and it is difficult to conduct testing
of various input combination in detail.
 It identifies maximum errors in a program as compared to other testing techniques.

2) INTEGRATION TESTING

In Integration Testing, the analyst tests multiple module working together. It is used to find
discrepancies between the system and its original objective, current specifications, and systems
documentation.

 Here the analysts are try to find areas where modules have been designed with different
specifications for data length, type, and data element name.
 It verifies that file sizes are adequate and that indices have been built properly.

3) FUNCTIONAL TESTING

Function testing determines whether the system is functioning correctly according to its
specifications and relevant standards documentation. Functional testing typically starts with the
implementation of the system, which is very critical for the success of the system.

Functional testing is divided into two categories −

 Positive Functional Testing − It involves testing the system with valid inputs to verify
that the outputs produced are correct.
 Negative Functional Testing − It involves testing the software with invalid inputs and
undesired operating conditions.

We have two types of testing a newly developed system to determine if it meets the specifications.
1) BLACK BOX TESTING
Black box testing is a software testing method in which the internal
structure/design/implementation of the item being tested is NOT known to the tester.
2) WHITE BOX TESTING
White box testing is a software testing method in which the internal
structure/design/implementation of the item being tested is known to the tester.
Different testing techniques are used at different times while testing the system. It is conducted by
the developer for small projects and by independent testing groups for large projects.

RULES FOR SYSTEM TESTING

To carry out system testing successfully, you need to follow the given rules;

18
  Testing should be based on the requirements of user.
 Before writing testing scripts, understand the business logic should be understood
thoroughly.
 Test plan should be done as soon as possible.
 Testing should be done by the third party.
 It should be performed on static software.
 Testing should be done for valid and invalid input conditions.
 Testing should be reviewed and examined to reduce the costs.
 Both static and dynamic testing should be conducted on the software.
 Documentation of test cases and test results should be done.

QUALITY ASSURANCE

It is the review of system or software products and its documentation for assurance that system
meets the requirements and specifications.

 Purpose of QA is to provide confidence to the customers by constant delivery of product

according to specification.
 Software quality Assurance (SQA) is a technique that includes procedures and tools
applied by the software professionals to ensure that software meet the specified standard
for its intended use and performance.
 The main aim of SQA is to provide proper and accurate visibility of software project and
its developed product to the administration.
 It reviews and audits the software product and its activities throughout the life cycle of
system development.

OBJECTIVES OF QUALITY ASSURANCE

The objectives of conducting quality assurance are as follows −

 To monitor the software development process and the final software developed.
 To ensure whether the software project is implementing the standards and procedures set
by the management.
 To notify groups and individuals about the SQA activities and results of these activities.
 To ensure that the issues, which are not solved within the software are addressed by the
upper management.
 To identify deficiencies in the product, process, or the standards, and fix them.

19
LEVELS OF QUALITY ASSURANCE

There are several levels of Quality Assurance and Testing that need to be performed in order to
certify a software product.

LEVEL 1 − CODE WALK-THROUGH

At this level, offline software is examined or checked for any violations of the official coding rules.
In general, the emphasis is placed on examination of the documentation and level of in-code
comments.

LEVEL 2 − COMPILATION AND LINKING

At this level, it is checked that the software can compile and link all official platforms and
operating systems.

LEVEL 3 − ROUTINE RUNNING

At this level, it is checked that the software can run properly under a variety of conditions such as
certain number of events and small and large event sizes etc.

LEVEL 4 − PERFORMANCE TEST

At this final level, it is checked that the performance of the software satisfies the previously
specified performance level.

QUESTIONS

1. Name three groups of people who are involved in system testing.

20
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

SYSTEM IMPLEMENTATION

Implementation allows the users to take over its operation for use and evaluation. It involves
training the users to handle the system and plan for a smooth conversion.

The key areas to be addressed during system implementation include:

1) File creation & conversion.

2) Staff training.
3) Changeover strategies.

1) TRAINING

The personnel in the system must know in detail what their roles will be, how they can use the
system, and what the system will or will not do. The success or failure of well-designed and
technically elegant systems can depend on the way they are operated and used.

Training also involves familiarization with run procedures, which involves working through the
sequence of activities needed to use a new system.

User Training

 End-user training is an important part of the computer-based information system

development, which must be provided to employees to enable them to do their own
problem solving.
 User training involves how to operate the equipment, troubleshooting the system problem,
determining whether a problem that arose is caused by the equipment or software.
 Most user training deals with the operation of the system itself. The training courses must
be designed to help the user with fast mobilization for the organization.

Training Guidelines

 Establishing measurable objectives

 Using appropriate training methods
 Selecting suitable training sites
 Employing understandable training materials

21
TRAINING METHODS

i). INSTRUCTOR-LED TRAINING

It involves both trainers and trainees, who have to meet at the same time, but not necessarily at the
same place. The training session could be one-on-one or collaborative. It is of two types −

a) Virtual Classroom

In this training, trainers must meet the trainees at the same time, but are not required to be at
the same place. The primary tools used here are: video conferencing, text based Internet relay
chat tools, or virtual reality packages, etc.

b) Normal Classroom

The trainers must meet the trainees at the same time and at the same place. They primary tools
used here are blackboard, overhead projectors, LCD projector, etc.

ii). SELF-PACED TRAINING

It involves both trainers and trainees, who do not need to meet at the same place or at the same
time. The trainees learn the skills themselves by accessing the courses at their own convenience.
It is of two types −

a) Multimedia Training

In this training, courses are presented in multimedia format and stored on CD-ROM. It minimizes
the cost in developing an in-house training course without assistance from external programmers.

b) Web-based Training

In this training, courses are often presented in hyper media format and developed to support
internet and intranet. It provides just–in-time training for end users and allow organization to
tailor training requirements.

2) CONVERSION METHODS/CHANGE OVER STRATEGIES

It is a process of migrating from the old system to the new one. It provides understandable and
structured approach to improve the communication between management and project team.

The four methods of conversion are

Changeover strategies:
Changeover is simply how to move from the old system and start using the new system.

22
The changeover should be planned & effected at the most suitable time for a smooth transition to
the new system.

The following are some of the common methods/ways of system changeover:

i). Direct (straight) changeover.
ii). Parallel running.
iii). Phased changeover.
iv). Pilot running.

i). DIRECT (STRAIGHT) CHANGEOVER:

Straight changeover is a complete replacement of the old system with the new system in one bold
move.
In this approach, the old system is stopped & abandoned and the new system starts operating
immediately.
This sudden change from old to new can be very inconveniencing in case the new system fails,
faces problems, or in a situation where the users have not gained enough confidence to run the new
system.
Direct changeover is likely to be used in situations where:
 The users have a very high level of confidence with the system.
 The new system bears little resemblance to the old.
 The system is relatively small.
 Personal resources are unavailable for any other method.

Advantage of Direct changeover.

 It is usually cheap because; two systems are not run in parallel.

ii). PARALLEL RUNNING:

Both the old & the new systems are run side by side (parallel) to each other for some time until
users have gained confidence in the new system.
Data is processed on systems in order to compare their performance, and the results are cross-
checked. The old system is only abandoned if the new system proves to be satisfactory.

Advantages of parallel running.

 It promotes user confidence since it allows the results of the old & new system to be
compiled side-by-side.

23
  It is reliable because it enables thorough testing.
 The users are given time to familiarize themselves with the new system.
Disadvantages of parallel running.
 The cost of operating & maintaining the two systems would be high.
 Resources are duplicated over the two systems, i.e., extra resources have to be engaged to
run the two systems in parallel.
 It is difficult for the staff to carry out clerical operations for two systems during the time
available, which is just enough for one system.

iii). PHASED CHANGEOVER:

In phased changeover, the new system is implemented in stages, e.g., one department after the
other, while the other departments are still being processed by the old system. When each new
phase is proved satisfactory, another one is brought in.
For example;
Changing of the education system from the old curriculum to the new curriculum. Each year, at
least one class level changes over to the new syllabus.
Advantage of phased changeover.
 It ensures slow but sure changeover, and also tends to prolong the implementation period.
In this case, users/analysts are able to learn from their mistakes.
Disadvantage of phased changeover.
 The various elements (i.e., hardware & software) of the same system may be incompatible.

iv). PILOT RUNNING:

In pilot running, the overall system is put into use bit-by-bit, e.g., on department basis.
Usually, data from a previous period is first run on the old system and then on the new system.
The results from the new system are then compared with the results from the old. When the new
system is considered as correct, a double sequence in one processing run may be tried to convert
the pilot run into a parallel run.
Advantage of pilot running.
 Pilot running offers gradual change to the overall new system. During this time, the staff
gains enough experience & confidence.

Disadvantage of pilot running.

 It is difficult for the staff to carry out clerical operations for two systems.

24
3) FILE CREATION/FILE CONVERSION

It is a process of converting one file format into another. For example, file in WordPerfect format
can be converted into Microsoft Word.

For successful conversion, a conversion plan is required, which includes −

 Knowledge of the target system and understanding of the present system

 Teamwork
 Automated methods, testing and parallel operations
 Continuous support for correcting problems
 Updating systems/user documentation, etc

Many popular applications support opening and saving to other file formats of the same type. For
example, Microsoft Word can open and save files in many other word processing formats.

25
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

SYSTEM MAINTENANCE/ ENHANCEMENT

Once the system becomes operational, it should be maintained throughout its life.
System maintenance is the process of adjusting & enhancing of requirements, or correcting of
errors that may be detected after the system has been implemented in order to keep the system
functioning at an acceptable level.

Maintenance means restoring something to its original conditions. Enhancement means adding,
modifying the code to support the changes in the user specification. System maintenance conforms
the system to its original requirements and enhancement adds to system capability by incorporating
new requirements.

Thus, maintenance changes the existing system, enhancement adds features to the existing system,
and development replaces the existing system. It is an important part of system development that
includes the activities which corrects errors in system design and implementation, updates the
documents, and tests the data.

Maintenance functions mainly involve: -

 Correcting errors due to program bugs.
 Changing the procedures & algorithms used to develop the original programs.
 Adding new routines & removing the obsolete routines.
 Hardware & software maintenance.
 Adjusting the existing routines so that the system may adapt to enhanced functional
environments.

REASONS FOR SYSTEM MAINTENANCE.

System maintenance is carried out to ensure that: -

 System efficiency is maintained for the changing functional environment &
requirements.
 User expectations are satisfied.
 The system caters for growth in application requirements.
 The system adapts to new changes in the company’s organization.
 System operation is based on the facilities of the current technological development.
 External influences beyond the organization’s control are adhered to by the system, e.g.,
Government policies on taxation, allowances, etc.

NB: System maintenance runs parallel to the maintenance of the system documentation, i.e., any
time maintenance is carried out on the system, the documentation should also be updated to convey
the right image of the system.

26
TYPES OF SYSTEM MAINTENANCE

System maintenance can be classified into three types

1) Corrective Maintenance − Enables user to carry out the repairing and correcting leftover
problems.
2) Adaptive Maintenance − Enables user to replace the functions of the programs.
3) Perfective Maintenance − Enables user to modify or enhance the programs according to
the users’ requirements and changing needs.

27
////////////////////////////////////////////////////////////////////////////////////////////////////

SYSTEM REVIEW/ POST-IMPLEMENTATION EVALUATION REVIEW (PIER)

System review is a formal process of going through the specifications, and testing the system after
implementation to find out (establish) whether the system meets the original objectives, or whether
it performs as predicted in the designed framework.
If the system does not meet/achieve the stated objectives, system development might start all over
again.
System review is conducted by the Data processing team of users & auditors. After the review, a
post implementation review report is produced, which contains recommendations on how to
overcome the problems identified during the review.

Post-Implementation Evaluation Review (PIER)

PIER is a tool or standard approach for evaluating the outcome of the project and determine
whether the project is producing the expected benefits to the processes, products or services. It
enables the user to verify that the project or system has achieved its desired outcome within
specified time period and planned cost.

PIER ensures that the project has met its goals by evaluating the development and management
processes of the project.

Objectives of PIER

The objectives of having a PIER are as follows −

 To determine the success of a project against the projected costs, benefits, and timelines.
 To identify the opportunities to add additional value to the project.
 To determine strengths and weaknesses of the project for future reference and appropriate
action.
 To make recommendations on the future of the project by refining cost estimating
techniques.

The following staff members should be included in the review process −

 Project team and Management

 User staff
 Strategic Management Staff
 External users

28
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SYSTEM DOCUMENTATION
Documentation is a process of recording the information for any reference or operational purpose.
It helps users, managers, and IT staff, who require it. It is important that prepared document must
be updated on regular basis to trace the progress of the system easily.
Documentation is the process of describing all what the analyst was doing during the system
development stages. Documentation is done by the analyst who developed the system, and is used
as a means of communication between the system analyst & the end-users of the system.

NB: System documentation takes place throughout the system development life cycle. After a
system has been implemented, any maintenance work must be documented & the analyst modifies
or updates the system documents (manuals) so as to reflect the current image of the system.
After the implementation of system if the system is working improperly, then documentation helps
the administrator to understand the flow of data in the system to correct the flaws and get the
system working.
Programmers or systems analysts usually create program and system documentation. Systems
analysts usually are responsible for preparing documentation to help users learn the system. In
large companies, a technical support team that includes technical writers might assist in the
preparation of user documentation and training materials.
Documentation can either be; Internal or External.

 Internal documentation is the writing of non-executable lines (comments) in the source

program that help other programmers to understand the code statements.

 External documentation refers to reference materials such as user manuals printed as

booklets
Advantages Documentation/Functions
 It can reduce system downtime, cut costs, and speed up maintenance tasks.
 It provides the clear description of formal flow of present system and helps to understand
the type of input data and how the output can be produced.
 It provides effective and efficient way of communication between technical and
nontechnical users about system.
 It facilitates the training of new user so that he can easily understand the flow of system.
 It helps the user to solve the problems such as troubleshooting and helps the manager to
take better final decisions of the organization system.
 It provides better control to the internal or external working of the system.

29
TYPES OF DOCUMENTATIONS
When it comes to System Design, there are following four main documentations −
1) Program documentation
2) System documentation
3) Operations documentation
4) User documentation
1) PROGRAM DOCUMENTATION
 This is a detailed documentation written for skilled programmers. It provides the necessary
technical information to help in future modification of the program.
 It describes inputs, outputs, and processing logic for all the program modules.
 The program documentation process starts in the system analysis phase and continues
during implementation.
 This documentation guides programmers, who construct modules that are well supported
by internal and external comments and descriptions that can be understood and maintained
easily.
2) OPERATIONS DOCUMENTATION
This is meant for computer operators such as the technical staff. It is used to help them install &
maintain the program.
Operations documentation contains all the information needed for processing and distributing
online and printed output. Operations documentation should be clear, concise, and available online
if possible.
It includes the following information
 Program, systems analyst, programmer, and system identification.
 Scheduling information for printed output, such as report, execution frequency, and
deadlines.
 Input files, their source, output files, and their destinations.
 E-mail and report distribution lists.
 Special forms required, including online forms.
 Error and informational messages to operators and restart procedures.
 Special instructions, such as security requirements.
3) USER DOCUMENTATION
This enables the user to learn how to use the program as quickly as possible, and with little help
from the program developer.
It includes instructions and information to the users who will interact with the system. For example,
user manuals, help guides, and tutorials. User documentation is valuable in training users and for
reference purpose. It must be clear, understandable, and readily accessible to users at all levels.
The users, system owners, analysts, and programmers, all put combined efforts to develop a user’s
guide.

30
A user documentation should include
User manual

User manuals are used to help a person use the system with little or no guidance.
The manual must contain information such as:
 How to install, start and run the system.
 How the system appears when running (interface)
 How to carry out various tasks, e.g., how to include a new entry, data entry, how to modify
a record, etc
 A troubleshooting guide, which describes error correction & how to get help when faced
with problems.
 A system overview that clearly describes all major system features, capabilities, and
limitations.
 Frequently asked questions.
 Explanation of how to get help and procedures for updating the user manual.
4) SYSTEM DOCUMENTATION
System documentation serves as the technical specifications for the IS and how the objectives of
the IS are accomplished. Users, managers and IS owners need never reference system
documentation. System documentation provides the basis for understanding the technical aspects
of the IS when modifications are made.
 It describes each program within the IS and the entire IS itself.
 It describes the system’s functions, the way they are implemented, each program's purpose
within the entire
 IS with respect to the order of execution, information passed to and from programs, and
overall system flow.
 It includes data dictionary entries, data flow diagrams, object models, screen layouts,
source documents, and the systems request that initiated the project.
 Most of the system documentation is prepared during the system analysis and system
design phases.
 During systems implementation, an analyst must review system documentation to verify
that it is complete, accurate, and up-to-date, and including any changes made during the
implementation process.

31
Documents used in program documentation.
(1). User guide/ manual.
This is a manual provided for an end-user to enable him/her use or operate the program with
minimal or no guidance.
A User guide is used in user-oriented documentation.
(2). Reference guide.
It is used by someone who already knows how to use the program but needs to be reminded
about a particular point or obtain more detailed information about a particular feature.
(3). Quick Reference guide.
This could be a single sheet or card small enough to fit into a pocket. It is used by the user to
get help for the common tasks carried out within the program.
(4). Technical manuals.
They are intended for System analysts & Programmers. They assist in maintaining &
modifying the program design and code.
A comprehensive system documentation consists of the following:
a) Report on fact-finding.
b) Requirement specification.
c) System flowchart and module flowcharts.
d) Table/file structures description.
e) Sample test data & expected output.
f) Output reports.

32