CHAPTER 1

INTRODUCTION

Daily booking service for traveling is aimed at reducing paper work for the industry and hence
improving its efficiency and speeding up of all processes.

The database can be accessed by the passengers from any computer terminal connected through
LAN to a server where the system has been installed. Hence, all the related information about a
passenger is available to Admin and Employees. Thus this software saves the entire passenger’s
long queue and hassle.

1.1Challenges of the current system

i. Congestion of passengers in booking office leading to registration office using

manual assigning of numbers which is a waste of time.
ii. Lack of immediate information storage –the information generated by various
transactions takes time and efforts to be stored at a right file.
iii. Lack of prompt updating- various changes to information like passenger details are
difficult to make as paper work is involved
iv. Inability to automatically schedule services, generate receipt and receive payments
from passengers.
v. Being unable to update the manual records.
vi. Preparation of accurate and prompt reports-this becomes a difficult task as
information is difficult to collect from various books.
vii. Inability to retain records as they are lost if they are kept on wrongly. e.g change of
office file storage.

1.2 Proposed solution

We have decided to take charge in designing a system that is friendly and will try to work out
solution in a way that favors the interests of every customer and workers, solve problems faster,
manage data, so that all the transactions become fast and there should not be any error in
transaction like calculation mistake and bill generation.

1.3 Objectives

The objective of “Daily booking service for traveling” is to easily track the information of all
customers, drivers and bus destination. The main goal of the software is to build a good
management tool for all customers. The main purpose of this software is to reduce the time taken
through manual system in order to maintain all the records.
1.4Justifications

The purposes of this system is to help easily capture the information of all patients and to reduce
the time taken through manual system in order to maintain all the records.

1.5 Scope

This system is helpful to reduce the time and complexity of maintaining the records. It also helps
in accurate maintenance of passengers and drivers.

-It can be used in any transport company for maintaining Passenger details.

1.6Methodology
Research method

Data collection tools

They include the following

1. Observation-I observed that their system is not efficient on keeping a passenger
registration details this give the passenger a hard time if one loses receipt issued.
2. Documentation review- all the documents used to record transactions and capturing of
information were available. These gave me views of what kind of data is involved in the
current system to enable me borrow from it.
Problems identified in the collected data:

1. Security: -data stored in database can be access by unauthorized person because of using
access database which is weak and it cannot prevent unauthorized people from access it.
This lead to information stored in their database being interfered and damaged.
2. The system is slow: - because its users keeping information manually in books which
can easily be overwrite.
 CHAPTER 2

LITERATURE REVIEW

This is an evaluation report of information found in the field related to the selected area of study.
It describes the kind of system that is to be developed. Unfortunately, I have no idea whether
there have been attempts to implement new and more efficient IT solutions for developing a
Daily booking service for traveling to be able to improve on the current systems being used in
transport industry.

Features

I. Employee registration and management.

II. Passenger registration and management.
III. Manage passenger bills.
IV. Booking passenger travelling dates.
V. Passenger reports handling.
VI. Passenger Luggage and store management.

The reason for developing this system was to come with a system that would be able to track
information of all passengers who comes to book a service. A system that will be able to register
passengers and give them a random number to prevent any data duplication. This system will
also be able to retain passenger details in the database.

Resources/requirements

1. Computer machine

2. External disk

3. Microsoft office 2007

4. Printer

5. Printing material

6. Visual basic 6.0

 CHAPTER3
SYSTEM REQUIREMENTS AND SPECIFICATION

3.0 INTRODUCTION
The below subsections is the Systems Requirements Specifications (SRS) document and it
provides an overview of the entire system.

3.1 Purpose

The System Requirements Specification (SRS) will provide a detailed description of the
requirements for the Bus Booking Management System (BBMS). This SRS will allow for a
complete understanding of what is needed for the hotel management system construction. The
clear understanding of the HMS and its’ functionality will allow for the correct software to be
developed for the end user and thus will be used for the development of the future stages of the
project. This SRS will also provide the foundation for the project. From this SRS, the BBMS can
be designed, constructed, and finally tested.
This SRS will be used by the software engineers constructing the BBMS and the Bus end users.
The software engineers will use the SRS so that to fully understand the expectations of this
BBMS to construct the appropriate software. The hotel end users will be able to use this SRS as
a “test” to see if the software engineers will be constructing the system to their expectations. If it
is not to their expectations then the end users can specify their choice and the software engineers
will change the SRS to fit the end users’ needs.

The system product to be produced is a Daily booking service for traveling which will automate
the major Bus operations. The first subsystem is a Bus Reservation and as well as advance
Booking System to keep tracks of reservations and seats availability. The second subsystem is
the Tracking and Selling tickets System that charges the current journey. The third subsystem is a
General Management Services and Automated Tasks System which generates reports to audit all
bus operations and allows modification of subsystem information. These three subsystems’
functionality will be described in detail in section 2-Overall Description.

There are two accounts for the BBMS. The end users are the staff (customer service
representative) and administrator. Both user types can access the Reservation and Booking
System and the ticket Tracking and Selling System. The General Management System will be
restricted to management users.
The objective of this System is to provide a system that can manage a bus that has increased in
size to a total of 60 seats. Without automation the management of the bus has become an
unwieldy task. The end users’ day-to-day jobs of managing a bus will be simplified by a
considerable amount through the automated system. The system will be able to handle many
services to take care of all passengers in a quick manner. The system should be user appropriate,
easy to use, provide easy recovery of errors and have an overall end user high subjective
satisfaction.

3.3 Definition of The Acronyms and Abbreviations.

SRS –Systems Requirements Specification

BBMS – Bus Booking Management System
Subjective satisfaction – The overall satisfaction of the system
End users – The people who will be actually using the system
The SRS is organized into two main sections. The first is The Overall Description and the
second is the Specific Requirements. The Overall Description will describe the
requirements of the BBMS from a general high level perspective. The Specific
Requirements section will describe n detail the requirements of the system.

3.5 THE OVERALL DESCRIPTION

This covers the general description of factors that affect the product and its requirements. This
section does not state specific requirements. Instead it provides a background for those
requirements, which are defined in section 3, and makes them easier to understand.

3.5.1 The Perspective Of The Products

The BBMS is an independent stand–alone system.

3.6 Hardware Interface

The BBMS will be placed on PC’s throughout the company.

3.6.1 Software Interfaces

All databases for the Bus Booking management system will be configured using Access 2000-
2003. These databases include Bus seats and passenger information. These can be modified by
the end users. The bus database will include the bus number plates, seats and if they are vacant or
reserved. The passenger information database will contain all the information of the passenger
such as first name, Surname, ID Number, Gender and phone Number.

3.6.2 Product Functions

Reservations and Advance Booking System

Allows for typing in passenger

information Has a default seat number
When a passenger makes reservation, the seat will changed color from blue to
either yellow or pink.
Ability to modify a

reservation Records payment

3.6.3 Tracking and Selling Ticket System

Tracks all tickets purchased

Charges the current journey as necessary

3.6.4 General Management Services and Automated Tasks System

Creation of users and assigning passwords

3.7 User Characteristics

Educational level of BBMS computer software – Low

Experience of BBMS software – None
Technical Expertise – Little

3.8 Apportioning of Requirements

The audio and visual alerts will be deferred because of low importance at this time.

3.9 Assumptions and Dependencies

- The system is not required to save generated reports.

- Credit card payments are not included
3.10SPECIFIC REQUIREMENTS

This section contains all the software requirements in a more detailed manner, that when
combined with the system context diagram, use cases, and use case descriptions, is sufficient to
enable designers to design a system to satisfy those requirements, and testers to test that the
system satisfies all the requirements.

3.10.1 External Interfaces

The Bus Booking Management System will use the standard input/output devices for a personal
computer. This includes the following:

· Keyboard
· Mouse
· Monitor
· Printer

3.11 User Interfaces

The User Interface Screens are described in the table below.

Table 1: User Interface Screens

Screen Name Description

Login Log into the system as a CSR or Manager

Reservation Retrieve button, update/save reservation, cancel reservation,

modify reservation, change reservation, adjust seat number,
accept payment type

Travel Modify date to travel, place of destination, date to travel

Administer User Create, modify, and delete users; change password

Reports Select, view, add, save, and delete reports

3.12 Software Interfaces

The system shall interface with Access database.

3.13 Hardware Interfaces

The system shall run on a Microsoft Windows based system.

3.14Communication Interfaces

This system shall be a standalone product that does not require any communication interfaces in
whatsoever.

2.15 Functional Requirements

Functional requirements define the fundamental actions that system must perform.
The functional requirements for the system are divided into three main categories,
Reservation/Booking, travel, and Management. For further details, refer to the use cases.

3.15.1 Reservation/Booking
1.1. The system shall record reservations.
1.2. The system shall record the passenger’s first name.
1.3. The system shall record the passenger’s Surname name.
1.4. The system shall record the number of passenger.
1.5. The system shall record the seat number.
1.6. The system shall record the passenger’s phone number.
1.7. The system shall generate a unique confirmation number for each reservation.
1.8. The system shall record the expected travel date and time.
1.9. The system shall record the expected destination date and time.
1.9.1. The system shall record that the seat is empty.
1.9.2. The system shall record the payment.
1.9.3. The system shall record the payment type.
3.15.2 Nonfunctional Requirements

Functional requirements define the needs in terms of performance, logical database

requirements, design constraints, standards compliance, reliability, availability, security,
maintainability, and as well as portability.

3.15.3 Performance Requirements

Performance requirements define the acceptable response times for system functionality.

· The load time for user interface screens shall take no longer than two seconds.
· The log in information shall be verified within five seconds.
· Queries shall return results within five seconds.

3.16 Logical Database Requirements

The logical database requirements include the retention of the following data elements. The list
below is not complete but only designed as a starting point for development.

3.16.1 Booking/Reservation System

· Passenger first name

· Passenger Surname
· Passenger ID Number
· Passenger phone number
· Assigned seat
· Expected travel date
· Expected travel time
· Expected destination date
· Expected destination time
· Payment received
· Payment type
· Total Bill
3.16.2 Design Constraints

The Booking Management System shall be a stand-alone system running in a Windows

environment. This system shall be developed using visual basic 6.0 and an Access 2000-2003.

3.16.3 Standards Compliance

There shall be consistency in variable names within the system. The graphical user
interface is designed to have consistent look and feel.

3.16.4 Reliability

This specifies the factors required to establish the required reliability of the software system at
time of delivery.

3.16.5 Availability

This system shall be available only during normal Bus operating hours.

3.16.6 Security
Passenger Service Representatives and Managers will be able to log in to the Bus Booking
Management System. Passenger Service Representatives will have access to the
Reservation/Booking subsystems. Managers will have access to the Management subsystem as
well as the Reservation/Booking subsystems. Access to the various subsystems will be protected
by a user log in screen that requires a user name and password.

3.16.7 Maintainability

The Booking Management System is being developed in Visual Basic 6.0. VB6.0 is an object
oriented programming language and shall be easy to maintain.

3.16.8 Portability

The Bus Booking Management System shall run in any Microsoft Windows environment that
contains visual basic 6.0 and the Microsoft Access database.
3.17 Change Management Process

Changes to this document may be made after approval from the project manager and the client
approval officer.

3.18 Supporting Information

A system context diagram as well as use cases and use case descriptions have been developed in
separate documents.
 CHAPTER 4

System Design overview

4.1 INTRODUCTION

Software design is the process of implementing software solutions to one or more set of
problems. The software design (SDS) document contains a statement of the design of inventory
management system. The design contains an explanation of a way to carry out each of the
product specification written in the Software Requirement Specification (SRS).The design will
serve as a guide to the developer. The SDS also shows how the program is separated into
modules, how the modules interact with each other, and how users see the program.

a) Purpose
This document is designed to be a reference for any person wishing to implement, or any persons
interested in the design architecture of the Horizon coach Management system. This document
describes each application’s architecture and its associated interfaces and database design. This
design will detail the implementation of the requirements as defined in the BBMS system
specification design.

b) System overview
This document includes but is not limited to the following information for the Horizon Coach
Booking management system; system overview, design consideration, architectural strategies,
system architecture, policies and tactics, database schemas, detailed system design.

c) Intended users
This document should be read by an individual with a technical background and has experience
reading data flow diagrams DFDs, control flow diagrams CFDs, interface design and
development experience in event driven programming or as describe in the BBMS System
Requirement Specification 1.2.

21
 4.2 SYSTEM SCOPE

a) Main Inputs:
i. Passenger name
ii. Driver ID/Passenger ID
iii. Passenger address, phone number, Gender
iv. Travel date and time for passenger

b) Outputs
i. Make Reservation screen
ii. Add new Bus screen
iii. Add new driver/Delete driver screen
iv. Add new user

Software will be designed to allow users perform following functions

i. Log on either as System administrator or as a System user.

ii. Add a passenger into system.
iii. Update or delete record information depending on the user authorization level.

The system will accept a number of user inputs when a user:

i. Log on to the system either as an System administrator or as a system user.

ii. Add a customer to inventory management system.
iii. Update or delete existing driver information

User input will result into the following output:

i. A splash screen if the user runs the program.

ii. Access to main forms and subsequent forms.

22
 c) Design Map
The system design will take the following mapping when ready.

Splash Form

Main Form

Login

ADMIN USER

ADD/DELET
MAKE ADD/DELETE CHECK SEATS MAKE E CHECK SEATS
RESERVATION DRIVER AVAILABLE RESERATION DRIVER AVAILABLE

ADD NEW ADD NEW

ADD NEW BUS SEARCH BUS SEARCH
USER

23
4.3 DESIGN CONSIDERATIONS
This section describes many of the issues that are needed to be able to addressed or resolved
before embarking on a complete design solution.

a) Assumptions
This BBMS design makes several assumptions about the software and hardware requirements as
is in the SRS. All the environmental operating requirements of both the user interface and the
database can be found in the BBMS requirements.

Both the database and the user application make the following assumptions about the operating
environment.

The system can be described by the operating requirements associated with this document and in
the SRS. The system application in execution will have the necessary resources availed as
required. This entails sufficient memory and permanent storage space and the adequate CPU for
the application. The user application makes the following assumptions about its operating
environment. The user machine will have Microsoft access database components installed, as
they are required for the system implementation. The machine will also have necessary database
setup.

b) Goals and guide lines

The major goal of the Bus Booking Management System is to help automate the current manual
process of Horizon Coach making it extremely simple and easy to use. The system is meant for
the firm’s employees some of whom are not technically advanced. It is very important that the
prompts for the user be clear and concise since this will be the highest level of interaction
between the system and the user.

It is also important the series of prompts and responses be tested with the users before being
deployed.
24
The user should get a response in a timely fashion since users tend to lose interest if they have to
wait too long for the system to respond.

In this design, a minimum of data is transferred between the user and the database so as to
retrieve the necessary information and return the requested data to the user.

Other goals of BBMS include;

· To minimize the time spent on manual recording

· To minimize the amount of paper work required.
· To provide searchable database of all Passengers.
· To reduce complexity.
This system attempts to keep the user interface and application as independent as possible. All
the prompts and responses on the user are completely driven.

4.4 SYSTEM ENVIRONMENT

System scalability and security are the requirements for the system architecture of the Bus
Booking management system. The system will accommodate scalability allowing flexibility
within the system to expand, modify or downsize easily to meet the evolving business and
technology change.

a) Development tools
This part of the SDS specifies the tools that will be used to develop the system. They include:
Application programming visual basic 6.0 and MS access for database. Other tools to be used
will include forms which will act as screens for input and out, tables that will be for input and
data entry.

b) Design methodology
In designing the BBMS for Horizon Coach, the following approach will be used:

Water fall model will be used as the best language for this kind of system. This is because water
fall model is suitable for visualizing, specifying, constructing and documenting the features of

25
the system. The design will take the following approach: designing the database, creating
relationships, designing the user interfaces and the system processes.

c) Database design
Database design refers to a process of modeling the information so as to meet the user
requirements. The process will be accomplished in three stages.

d) Conceptual design
Conceptual design refers to a process of constructing an abstract model of data to be included in
a database.

In creating the conceptual design for Horizon Coach, the following activities will be involved.

Identification of the entities: the various entities included in the BBMS are;

· TRAVELL DETAILS
· RESERVATION DETAILS
· LOG IN
· HOMEPAGE

e) Identification of relationships
This refers to an association between the entities.

For Horizon Coach, a passenger makes reservation as wishes. The Management therefore records
all details of the passenger and as well as those of the driver who will be on duty.
f) Logical design
This part of the database design will entail selection of database model which is a collection of
concepts and rules for the description of the structures of the database. A relational database
model will be used for this case as it defines a database as a collection of tables containing all
data and their related properties.

f) Data normalization
This is a process of removing redundant data from the tables in order to improve storage
efficiency, data integrity and data scalability.

g) Physical data design

The system will include the tables show below containing the attributes in them.
i. Users table

This table stores user’s username and password which they use to log in to the system.

ii. Service Information Table

To record place of departure and destination of a passenger.

iii. Seat Reservation Table

To reserve passenger seats
 iv. Passenger information Table

To record passenger information

v. Driver Information Table

To record driver information.

vi. Bus Table

To store bus information
4.5 DATABASE IMPLEMENTATION

In this system, the database will be implemented using MS Access. It functions as storage to
keep track of the entire Organization.

a) Database file management security

There will be Backup and recovery policies and procedures to protect data stored in BBMS to
protect this data from damage or loss. If by any chance something happens and the integrity is
compromised BBMS will have the ability to restore and recover lost or damaged data.

File Security is defined by personal or sensitive data that is stored in files on the database. It is a
vital part of every data storage system. The administrative team will handle this for the BBMS
project by defining user groups and assigning permissions. This is a requirement of the system
because the staff will be using/sharing applications and files.

The User groups will be defined and consist of system administrators, managers, and staff.
Basically three levels of access. These levels will allow certain privileges and be controlled by
the rank in group permissions. Permissions will stem between read, write, and execute broken
down into access and ability to perform file/application manipulation. The categories are as
follows.

· Read a file - read file contents only

· Write a file - store files change file contents
· Execute a file - run available programs
The system will of through a series of steps when accessing
4.6 ARCHITECTURAL AND COMPONENT LEVEL DESIGN

a. Flow Chart Symbols

The following symbols are associated with logical process.

Terminator-Marks the start or end of a process

Process-Represent a step in the process

Decision -Indicate a point where the outcome of a decision indicates the next step.

Flow line -Used to show direction of data or information.

Input or output operation-Shows input and output from a process

Database-A step that results in information being stored

Data flow for searching record

Validate
User username & Search record Display the
password requested record
a. Context Diagram
The first level of DFD shows the main process within the system that generalizes the function of
the entire system in relation to external entities.

When a passenger makes reservation, which he receives by an entry staff/employee, who

checks/locates the available seats and reserves them.

This may be represented showing the Passenger reservation process, where the passenger is an
external entity in the context diagram.

4.7 USER INTERFACE DESIGN

User interface will consist following main screens, login screen which will consist of a user
dialogue box text boxes and three labels for data input. The login screen will be used to
authenticate the user to the system.

The sample user interface forms and screens that the user will interact with include:

1. Login Form
2. Bus Form
3. Driver Form
4. Reservation Form
5. Passenger information Form
6. Service Information Form
7. Main Menu Form
 CHAPTER 5
TESTS PLAN

5.1Introduction
This is aimed at identifying and correcting errors. The major objective of this activity is to ensure
that the processing done by the application is correct and meets the objectives of the
organization. Test plan aids in effective and systematic testing of the system and it aims at
checking the errors of omission and commission that hinders the realization of the objectives. It
takes the bottom up testing approach.

5.2Importance of testing

1. Testing is used to find program errors on the system.

2. It is used to find undercover errors in a program through the use of defect testing.

3. Testing is also used to uncover new types of errors associated with new inventions and
technology

4. Testing aims at assuring quality by enforcing consistency and reliability.

5. It is used for both validation and verification to develop a product that meets user
requirement.

6. It is used to identify the best component combination for effective error identification.

5.3Test Plan Strategies

The importance of the test plan is to show how the system is to be tested and also gives precise
procedures to be followed during the test plan. The test date is identified, what is being tested
and the expected output as well as the actual input. Test plan is one of the standard documents
that should be produced in most software engineering projects. If the project does not have any
test plan this means that the software produced is of low quality. This may not be acceptable to
the user since it will not satisfy their needs. The test plan should be written as soon as you have
identified the requirements.
The system will be tested with sample data to see how it would handle input and output functions
as well as extreme data or conditions to determine the system behavior in overloaded situation
which will directly slow the system that behaves in failure or extreme situations.

51
The types of testing that will be conducted upon include:

· Unit testing

· Module testing

· System testing

· Integration testing.

5.3.1Unit testing
In this type of testing, the smallest testable parts of the system I.e. units are individually tested
and independently examined for correct functionality. This type of testing involves both the
positive testing and negative testing. This is important so as to make sure that the system
functions properly when used both correctly and incorrectly. In this case, the forms in visual
basic as well as the tables for the database will be tested individually to ensure that they are
compatible. This also applies to the operating system and the software applications.

5.3.2Integration testing
This is where two or more related programs are tested. The test will involve two types of
approaches i.e. the bottom-up approach that begins with the simplest task to the most complex
part .e.g. from passenger information table to the database and top-down approach that tests the
system from the complex task to the simplest unit of all.

We seek to verify that all the hardware function together without conflicting.

All the forms linked to the database should be connected well without any issue.

Ensure that all the programs work well to avoid interruption and there is no issue whatsoever
affecting database update.

5.3.3System testing
I this type of testing we shall test the entire system for functionality to ensure that the system can
process and handle large volumes of data quickly and efficiently. The test will be done with a

52
sample of some users who will use the system under test in its actual capability environment.
Possible problems are corrected before really conversion.

5.3.4Acceptance testing
This test will complete the formal testing process where all the users and the administrator will
use the system so as they get familiar with it. The users test the system before it is rolled out to
be fully used.

i. Beta testing-Carried out at bus company premise. This involve delivering the system to
number of potential clients to use the system and report back to developer key
malfunctions with an understanding that the product is still being tested.

ii. Alpha testing-It takes place at the developer site. It is the final testing before the
software is about to be released to the hospital for use.

It has two phases

a. First phase

b. Second phase

a).First phase-The software is tested by in house of developers. They use either debugger
software or hardware assisted debuggers.

b).Second phase-The software is handed over to a different bus company for additional testing
in an environment that is similar to intended use.

5.3.5Recovery testing

Recovery testing will force the system to fail in various ways and try to verify that the recover is
efficiently done or performed. It is vital that all the data is recovered after the system failure and
no corruption of data.
5.4Test plan

Type of test Test data Tested area Expected output Result

Unit testing Interface How the System Easy to use and To increase the
and logical is interactive effective interface by level of
testing system users. usability hence
increases level
of accuracy.
Numerical fields Should accept Should perform
numbers only. as expected.
Text fields Should accept only Should perform
text characters. as expected.
Login Should accept correct Should perform
password. as expected.
Username and Security Connect to database Should perform
password for verification access as expected.
is denied if wrong
password is given.
Module testing The MDI Navigation of Sub menu to open The system
FORM system should be
accessed from
the level to the
lowest level.
System testing CODE System The system should Ensure the
implementation have no errors when system
running functions as
required without
problem.
Command Should perform as The files should
buttons for file expected be manipulated
operation easily by use of
commands.

54
5.5Conclusion

All testing was done carefully and each test was up to the required standards of the users’ .error
tests may be suggested but the above mentioned are just sufficient to test. Testing is an essential
phase in system development and therefore it should be taken with a lot of interest.
CHAPTER 6

IMPLEMENTATION PHASE

6.1Introductions

The system has been developed using visual basic 6.0 and ms access database.

6.2Purpose

The document contains overviews of system, description of the major tasks that are required to
be done before the system is put into use.

6.3System description

This system will manage all bus booking activities, it will cover all passenger details and
maintaining all record about the drivers. This will be facilitated in the database which will
preserve their record for future reference. The system will processes data into useful information.

6.4System organization

In this section it provides a brief description of system components necessary to the

implementation of the system. The system will be installed in all causality offices head quarters
where all passengers can get access to the system.

The main functions that will be carried out by the application will be

1. Registering passengers

2. Booking and reservation of travelling tickets

3. Assigning passenger the available seats

4. Paying for services

5. Keeping booking record

6. Generating reports

7. Generating number which will be used for passenger identification

6.5 Implementation strategy

Direct conversion
This the best method of implementing the system by direct conversion .This was done because
the travelling company does not have a stable system at the moment as they still run their things
manually.

Justification

I. The system will be implemented immediately after testing is done in team work.

II. Currently there is no system that is used so there is no much cost that will be lost in
replacing the old system.

6.6Installations

A 150 GB

Core i3 and above processor

2 GB or 4 GB ram

Printer e.g. laser

Window exp or window 7

Microsoft access

6.7 Data migration

All data from the manual system was migrated to the new system to measure up the performance

of the new system depending on the kind of data that will be put on the system once is put in use.

6.8Review

The system developer and the users will analyze and compare the two systems and will come up
with changeover method used.
6.9Maintenance plan

The maintenance plan include all those thing that will be need for the project output once the
management has accepted them and how they will be achieved.
 Identification of computer system

Hardware and other peripherals

Technical and all manuals including the proposal.

6.10Implementation schedule

Activity Duration Objective Contact person

System installation 4days Setting all the System developer

preparation requirement in place

Installation 2days Installing the System maintainer or

software System developer

Reviewing and 3days Measuring the System developer

verification system performance

Training 4days Training all the users System developer

of the new system

6.11Conclusions

The implementation of this system will help in handling daily operation efficiently and good
performance of the travelling agencies. It will improve record storage as all data will be stored in
the database.