Bus Station Project

Kombolcha Bus Station Online Ticket Reservation System
Part one: Introduction

1.1Overview/ Background
Kombolcha town found in the north western parts of Addis Ababa at 376 kilometers
from the capital city of Ethiopia and 25km far apart from Dessie town. It is the main
industry center in Amhara region and has its own administration structure to organize,
control and manage the local communities. In addition to this, in the town there are
governmental and nongovernmental organizations which facilitate the development of the
town and provide services to the community. From those governmental institutions Bus
stations are one of the public centers which give transportation service for journeys. There is
only one bus station in kombolcha, and it was established in 2002 E.C for the purpose of
serving the local communities getting service in their own village. Before this bus station
established the local communities had to go to dessie bus station for journey, this results the
people to spend unwanted wastage of resource, money as well as time. This bus station is
second level bus station that have only medium bus (that have number of chairs between 24
to 44) minibuses (that have number of chairs between 7 to 23). The bus station starts their
work with small number of cars, now the station will have 104 minibus and 15 medium
bus, overall 119 buses. The station receives cars from 4 source places:
Harbu
Dessie
kemisie
Bati
And also the station has responsible for arranging cars to 13 destination places
Using manual distribution and ticketing system. The destination places are:
Dessie
Bati
Harbu
Kemisie
Mekoy
Karaqorie
Shewarobit
1|Page
Debrebirhan
Degan
Gerba
Ataye
Worsaye
Cheqorti
The last 2 destination place serves only for market days.
1.2 Statement of the problem

The bus station s system that are using currently is an internal system (applies manual)
and just used to sell the bus ticket at the counter. Customer has to go to the counter to buy
bus ticket. Due to this reason the following problems are observed currently.
Customers vulnerable to wastage of money and time when always went to the station
office to know the to get ticket.
Customersneed to queue up long time to get the bus ticket.
The station is vulnerable to high material resource wastage (written materials) and much
cost is must be spend for handling records.
File control mechanism is very tedious, Complicated and not secured.
1.3 Objective of the project

The general and specific objectives of the project are described below.
1.3.1 General objective

The general objective of this project is to develop Online Bus Ticket Reservation System for
Kombolcha Town bus station.
1.3.2 Specific Objectives
To achieve the general objectives of the project, we are able to know the following specific
objectives:
o design a database
o design user friendly interface
o Able to know how to test the system
o maintain our system
1.4 Scope and limitation of the project

2|Page
1.4.1 Scope of the project

The scope of the proposed system is the following:The online system is an easy-to-use self-service system which enables the customer buys
bus ticket online and pays the bus ticket from their balance through their account.
The system requires LAN.
Passengers view the schedule of bus station system.
The administrator able to make report of the database content
The system cannot arrange bus distribution itself, rather bus distribution schedule is from
the manual system input then distribution schedule is generated on web page for
customer viewing service.
The system is applicable on recording, deleting and updating and retrieving of customer
information.
Out of scope
The proposed system does not perform the following issues:
o It does not concern other stations to be online.
o It does not concern about the towns transportation system (taxis, cabs).
o The manual system is available for unregistered members.
1.4.2
Limitations
The following limitations are facing during development time:

Material such as reference books in library, and Internet access in computer laboratory
rooms.
Shortage of hours to use computer in the computer center
Time line for the final year project allocated
Shortage of information and documentations on the bus station.
1.5 Methodology
In developing online bus ticket reservation system, the following development methodologies
will be applied.
1.5.1 Data collection
Data collection was one of the important tasks to analyze how activities done in existing system
and developed the new system. Data for developing this system obtained from different
3|Page
sources. These data sources were system users (personnel of bus station), different forms and
documents used in the office, procedure manuals, and reports of the office.
Data collection methods

A) Interview: - was used to gather required data for the project by contacting different
employees of the bus station.
B) Observation:-was used to gather additional data by observing the actual work being done by
the staff and consolidated with what was obtained through Interview.
C) Document Analysis (Document & literature review):-consulted and analyzed written
materials that describe the operations conducted in the station to further strengthen and support
the information that applied the above technique.
1.5.2 System analysis and design
The methods of the system analysis and design can do through OOSAD (object-oriented system
analysis and development). we use the OOSAD modelling for our project because it is
considered OOSAD are easier to develop and maintain and also it is considered that the
transition Object oriented analysis to Object oriented design can be done easily.
1.5.2 System Development /Implementation
The implementation phase is described as those activities that begin when the system design has
been completed. These phases are producing software code according to plan, analysis and
system design that have been done. Coding and debugging is the act of creating the final
system. The requirements documentation should be referred to throughout the rest of the system
development process to ensure the developing project aligns with the needs and requirements or
scope. The system also is tested to evaluate its actual functionality in relation to expected or
intended functionality.
Development tools:
Database Tools :- XAMPP V 3.1.0

Drawing tool for Diagrams :- Rational Rose
Documentation :- Microsoft Word 2007
Programming Tools :- Adobe Dreamweaver CS 5.5 , Net Beans 7.2.1
Programming Languages: - HTML, PHP, JavaScript, Jquery, CSS.
Operating System: - Microsoft Windows XP, Windows 7.
4|Page
Interface Language: - Amharic, English.

1.6 Significance and Beneficiaries of the project
The Kombolcha town bus station system is not using computerized data processing System;
hence it is a serious problem in time management and to perform their work efficiently. So
making the system online will investigate the technological problems and to find ways and
means to enable the station computerized working system that could help to work efficiently.
The proposed system will have many advantages like:
The system will perform fast service and minimize stated problems.
It minimizes the workload of employees.
It minimizes loss of documents and data fragments.
It minimizes time to retrieve search and update files.
Benefits
These benefits are classified as tangible and intangible benefits Tangible benefits are usually
measured in terms of profits to the Bus station.
Time consuming activities(tasks) will be reduced
Reduce man power & material budget allocations
Avoid document missing and material wastage
Intangible benefits are benefits that cannot be measured in terms of money.
Avoid tiredness of customers because ticketing is online.
Avoid tiredness to separate the dead file from the no dead files.
1.7 Feasibility analysis
Feasibility study is used to investigate the proposed system in multiple dimensions. It used to
indicate whether the system feasible or not. Our system can be seen according to the following
literals.
5|Page
1.7.1 Operational feasibility

The new system can be easily operated and accessed by the users anywhere who interact to the
system. It contains user friendly commands which leads users interact to the system interfaces.
And have Amharic language interface to interact with users who cant read English language.
1.7.2 Technical feasibility
Technical feasibility is the measure of practicality of the specific technical solution and the
availability of technical resources and expertise. Our system can be easily maintained and
repaired without requiring high Experts or technical assistants.
1.7.3 Economical feasibility (Cost Benefit Analysis)
The project that we are going to develop is economically feasible than the manual system
that the bus station currently use. After finishing online bus ticket reservation system so many
resources are feasible. The manual system use large amount of document for ticket this implies
economically infeasible, our System changes this into computerized manner so no wastage of
resource for ticket booking.
1.7.3.1 Benefits of the Project
a) Tangible benefits
Since this project is going to be dynamic web site, there is reduction cost for material that used
for manual operation, save time and make comfortable working environment for the users.
b) Intangible benefits
The intangible benefits we have pointed out the system development are the following:
Easily access information.

Increased flexibility
Increase speed of activity
Improves the confidence of the employees.
6|Page
1.7.3.2 Cost of the Project
a)
Tangible costs
The tangible costs to be acquired in developing the system are:i.
ii.
iii.
i.
Hardware development cost

Software development cost
Miscellaneous Cost
Hardware development cost

Hardware
Performance
Price
Pentium 4
3.2 GHz
2 Gb RAM
1800 Mhz Bus
Speed
1 Computer
10,000 Birr
120 Gb Hard Disk
Standard Display
Standard mouse
Standard Key
Board
7|Page
Laser Ink Jet

1 Printer
8,000
A4 Size
256 Kb
Broad Band
Connection
Network Coverage
1,100 Birr Per

Year
Can Be Extended
24/7 Service
Table 1.1 Hardware development cost
And 1,100 ETB per year for network coverage
ii.
Software development cost

For this particular project we will be using different software but the software are provided by
the university.
Software costs
Software Description
Price
Microsoft windows XP Sp2
250 Birr
Microsoft office 2007
200 Birr
Microsoft SQL server 2008
200 Birr
Adobe Dreamweaver CS5.5
150 Birr
Net Beans 7.2.1
150 Birr
8|Page
Total
950 Birr
Table 1.2 Software cost

Salvage value = [(195/4yrs)*3monts]/12monts
= 12.1875Birr
Annual depreciation cost = 195-12.1875/4yrs
= 191.95Birr
Monthly depreciation cost= 191.95/12 Monts
= 15.99Birr
Soft development cost=15.99 *3 Monts
= 47.97 Birr
iii.
Miscellaneous Cost
The following table lists the different miscellaneous costs that we spent in the process of the
development of the system.
Miscellaneous Costs
Material
Amount
Price
Printing
Pen
Paper
Flash disk
Total
Minimum 100 pages

5
ONE DESTA
1
------------
200 Birr
10 Birr
60 Birr
200 Birr
470 Birr
Table1.3.Miscellaneous costs
b) Intangible costs
The intangible costs to be acquired in developing the system are:-
Human Knowledge
The Human knowledge that we spent to develop the system is defined in terms of money as
follows.
9|Page
Payment for 1 person/days = 50 birr

5 persons work on the project each 60 days
Therefore
Human Knowledge cost = 50br/hr * 5persons * 60 days = 15,000 Birr
1.5.3.3 Total cost
Total cost = tangible cost + intangible cost But
Tangible cost = Hard ware cost + Miscellaneous Cost + Software cost + software development
cost
Since the software and hardware costs are covered by the university, their cost is 0 Birr.
= 19,100 birr + 470 birr + 950 birr+ 47.97 birr
=20567 .97Birr
Intangible cost = human knowledge Cost
= 15,000Birr
Total Cost = 20567 .97 Birr + 15,000 Birr
= 35567.97Birr
1.7.4 Schedule Feasibility
Schedule feasibility is making sure whether the potential time frames and Completion date can
be met or not .The project team members expected the Project to be completed on time without
any delay. This represented by giant chart under project schedule, see giant chart1.
1.8Communication plan
10 | P a g e
Communication plan describes the schedule of group member or the time of communication
plan to develop project with the schedule described in the giant chart. The group member
communicates two days Tuesdays and Thursday for each week. While the member meets on
specified time at least communicate for 3 hours.
R.No
Name
ID
Role
1
2
3
4
5
6
AntehunTiruneh
H/eyesusTassew
Kiberetu H/mariam
MelakGezahegn
MerkebuYiteyaw
TadiyosHailu
010/02
024/02
030/02
036/02
038/02
049/02
Information Gatherer
Implementation
Proposal developer
System and Object designer
Business Area Analyst
Object Oriented Analyst
Table 1.4 Communication Plan

1.9 Task break down and deliverables
11 | P a g e
Project
schedule
Phases
Tasks
Starting
Time
Finishing
Time
Single
Time
Estimate
System
Proposal
Writing
February
March 19
24 Days
Proposal
25
Problem
March 20 March 27
7 Days
Definition
Candidate
Solution
March 28
April 4
7 Days
Identifica
System
tion
Analysis
Selection
Good
April 5
April 12
8 Days
Solution
Data
April 13
April 20
8 Days
Modeling
Tasks
February
March
April
DB
1
25 211 April
19 23 1 3 Days
20
April
Design
30
30
30
Input
April 24
April 26
3 Days
System
System
Design
Proposal
Output
Design
April 27
April 29
3 Days
System
Design
Analysis Interface April 30
May 2
3 Days
Design
System
Coding
April 30
May 23
24 Days
System
Design
Testing
May 24
May 26
3 Days
Implementa
System
Maintena
May 27
May 29
3 Days
tion
Implementati
nce
Whole
Time
Estimate
Table 1.5
Time
Schedule
24 Days
29 Days
1
30
May
15
12 Days
30 Days
on
Table1.6 Giant chart
Part Two: Business Area analysis

Definition
12 | P a g e
System Analysis is the detailed study of the various operations performed by the system and
their relationships within and outside the system. Analysis is the process of breaking something
into its parts so that the whole may be understood. System analysis is concerned with becoming
aware of the problem, identifying the relevant and most decisional variables, analyzing and
synthesizing the various factors and determining an optimal or at least a satisfactory solution.
During this a problem is identified, alternate system solutions are studied and recommendations
are made about committing the resources used to design the system.
2.1 Description of the existing system

The existing system refers the manual system that is available currently.
The existing system forces customers of the bus station to come over to the bus station
personally
To buy or get tickets
To know journey schedules
To get information about the bus station
And also the record keeping & the bus distribution handled manually.
Detailed Description of the existing system

As described later the current system use manual system. Customers come to the bus station
office in order to get ticket, after these customers are queuing up long time in front of the office.
Then ticket sale man hosts the customer one by one for large amount of time. The ticket sale
man record customer data on the ticket paper and on the agenda book. The ticket is given for
customer but the data recorded on the agenda is saved in the office for different purpose.
Bottlenecks of the existing system

Customers faced a problem of money & time wastage
Ticket sellers waste time & energy
The record keeping system wastes much resources
Records might not correctly handled
Records might lost
As mentioned on chapter 1 the existing system has many drawbacks that are why we
try to build an automated system.
But in this case we try to see the limitations of the existing system in terms of
Pieces framework.
13 | P a g e
The performance of the existing system can be evaluated by the time duration of
the items waiting to be purchased by the customers and the number of customers
served at a time, and this depend on the number of customers and the number of
employees who give the service. If the numbers of the customers are a lot
All the above statements are full filled if the employees can handle all the
customers effectively and quickly, but the existing system has a problem like:
The numbers of employees needed to handle the customers are limited.
It takes lot of time to calculate price of each items and serve many customer at
the same time.
Problems around Input
o The tickets are not secured
o The authenticity of the tickets are not assured
o Time wastage matters a lot
Problems around output
o In terms of getting remained information
Practices to be preserved from the existing system

Even though the existing system has many drawbacks it is also undeniable that it
have good features too. Like:
The way of attracting customers in a good approach
Controlling and registering ticket details
The reliability of the system because of appealing to administrative office in
case of errors
2.2 Alternative solutions

We (the members of our group) try to find solutions in many ways and get two options.
1. The first one is to try solving problems while using the existing (manual) system
by taking some measures like:
o Adding extra ticket seller on the counter to minimize the queue of the
customers
14 | P a g e
o To employee additional record keeper to increase the performance of the

record keeping part
o To post the daily journey schedules on public notice boards
Even though these measures can minimize the problem of the customers they have their own
problems like:
o Money wastage of the bus station for employing extra employees
o Time and resources of the station will be wasted for posting daily
schedules on public notice boards
2. The second option is to make the bus station web based and try not to affect the existing
system structure.
The second option (the newly proposed) system is much more appropriate solution for our
problem rather than the first one because:
o The proposed system dont cost like the first option
o The proposed system can work more efficiently than the first one
o Nowadays human being is become more attracted to technology
So, we choose the second option as an appropriate solution for our problem.
2.3 Requirement definition (Description of the new

system)
Description of the newly proposed system
The newly proposed system needs a web based system that customers can access
the webpage wherever they are by using WWW (Internet) to get (buy) tickets, to know
journey schedules & to get information about the bus station in detail and the has
enormous database to control the record keeping & to generate bus distribution schedule
(the schedule is entered from administrator input).
Advantages of the newly proposed system

Customers dont have to waste time & money because of they can access the
webpage wherever they are whatever they are doing
Ticket sellers exhaustive work will be reduced by the system
Resources that spent on the newly proposed systems are less costly & efficient
Records will be handled correctly because this task handled with computers
efficient system (software)
15 | P a g e
Loss of records is unimaginable unless the system crashes with some reasons
2.3.1 Functional Requirement
Membership registration
Bus owner registration
Validates data entry for correctness.
Updates itself when it gets new data.
Sell coupons to customers with account
Provide ticket
Display updated journeys schedule online
Display updated buses information
2.3.2 Essential use Case modeling (Description)

An essential use case (Constantine and Lockwood 1999), sometimes called a business use
case, is a simplified, abstract, generalized use case that captures the intentions of a user in a
technology and implementation independent manner. A fully documented essential use case is
a structured narrative, expressed in the language of the application domain and of users,
comprising a simplified, abstract, technology-free and implementation-independent
description of one task or interaction. An essential use case is complete, meaningful, and well
designed from the point-of-view of users in some role or roles in relation to a system and that
embodies the purpose or intentions underlying the interaction.
Actor:
1. Customer
2. System Administrator
16 | P a g e
Fig 2.1 Essential use case diagram
Essential Use case Description

Essential use case for Customer Registration
UC- name
Customer Registration
Use case number UC1
Actor
System Administrator
Description
New customer registration for membership of bus station

17 | P a g e
system service.
Basic course of
action
Actor Action
System Response
Step1: System Administrator
Step2: System displays
wants to register the new
customer registration form.
customer.
Step 5: System checks the
validity the filled information.
enters all required information
Step 6: the system accepts
for registration by via
customer data and stored in to
member registration form
DB
Customer pay cash for

coupon greater than
1000 Br while
registering.
Step4: SA submits the
information filled.
Step7: Customer gets the
coupon (having serial
number), user name and
Alternative
courses of action
Pre-condition
Post condition
password.
Step 5: if the information filled is not valid, then enter the
customer data again (Return step 2).
SAstarts the process of new customer membership registration
New customer registered successfully and data stored to the
database.
18 | P a g e
Table 2.1 essential use case documentation for customer registration
Essential use case for Bus owner Registration

UC- name
Bus owner Registration
Use case number UC2
Actor
Description
Bus ownership is registered without payment.
Basic course of
action
Actor Action
System Response
Step2: System displays bus
wants to register the bus
owner registration form.
owner.
Step 6: the system accepts bus
in bus owner registration
owner profile and stored in to
form.
DB

Alternative
information filled.
Step 5:if the information filled is not valid, then enter the bus
courses of action
Pre-condition
Post condition
owner data again (Return step 2).

SA starts the process of new bus owner registration
New bus owner profile registered successfully and store in to
the database.
Table2.2 essential use case documentation for bus owner registration
Essential use case for Generate Ticket

19 | P a g e
Use case name
Generate Ticket
Use case number UC3

Actor
Description
System Administrator generate tickets for different level of bus

for different destination
Actor Action
System Response
Step1: customer opens
Step2: System display
customer ticket request form
customer ticket request form.
Step3: customer fills there
Step 4: the system check the
request in customer ticket
validity and availability of
request form.
customer request.
Step5: customer sees the
request sent successfully.
Basic course of
action
Alternative
Step 4: the system identifies customer by checking the
courses of action database.
Pre-condition
Identifying customer request.
Post condition
Sending response for customer request
Table 2.3essential use case documentation for generate ticket
Essential use case for Amount confirmation

UC-name
Amount confirmation
Use case number UC4

Actor
Description
The System administrator confirms customer ticket request if

having enough balance for the required journey distance.
20 | P a g e
Basic course of
action
Actor Action
System Response
Step2: customer ticket request
wants to confirm customer
confirmation form displayed
ticket request.
Step 4: the system updates the
DB by the confirmed data.
confirms customer ticket

request if the remaining
balances enough required
journey distance.
Alternative
Step 3: if the customer balance in there account is not enough
courses of action for the required journey invalid message is sent to customer.
Pre-condition
Viewing customer ticket request
Post condition
Confirmation or unconfirmation customer ticket request
Table 2.4Essential use case documentation for amount confirmation
Essential use case for Ticket Request

Use case name
Ticket request
Use case number UC5

Actor(s)
Customer
Description
Only membered customer for bus station can ask online
Basic course of
ticketing.
Actor Action
action
Step1: customer wants ask
online ticket.
validity and current customer
System Response
21 | P a g e
request form.
balance with the cost of
Step5: customer waits until
required journey.
the response come.
Step6: the system generates

required ticket with detailed
Alternative
information.
Step4: if the information filled is not valid, then enter the data
courses of action
again (Return step 2).

If the customer hasnt enough balance for the required
journey the response is error message.

Pre-condition
Customer request wants to process to get ticket online.
Post condition
Viewing the required ticket.
Table 2.5 Essential use case documentation for ticket request
Essential use case for view ticket

Use case name
ViewTicket
Use case number UC6

Actor(s)
Customer
Description
First customer register as member for bus station then get

service online ticketing while sending request for get ticket
online the response view the ticket with detailed information on
the ticket.
22 | P a g e
Basic course of
action
Actor Action
System Response
Step1: customer opens ticket
Step2: the system checks the
request form and fills the data
privilege of customer to get
to get ticket.
online service.
Step 3: if request is true then

the system display ticket for
customer.
Alternative
.Step 2:the system checks customer whether they have
courses of action
privilege to get online ticketing service if not generate error
message and commands to be member first for this service.

Pre-condition
Customer must be member of bus station.
Post condition
Customer views the ticket online.
Table 2.6Essential use case documentation for View ticket
Essential use case for view journey schedule

Use case name view Journey Schedule
Use case
UC7
number
Actor(s)
Description
Customer
Every customer can view the schedule of bus station
without go to station office
23 | P a g e
Basic course
of action
Actor Action
System Response
Step1: customer knows
the website of station then
the webpage.
access the webpage.
Step4: the system displays
the schedule.
journey schedule since

free.
Pre-condition
Post condition
Customer must know the bus station website

Customers view journey schedule.
Table 2.7 Essential use case documentation view journey schedule
Essential use case for ViewBusInformation

Use case name
View BusInformation
Use case number UC8

Actor(s)
Customer
Description
Every customer can view bus information that the bus station
arranges.
24 | P a g e
Basic course of
action
Pre-condition
Post condition
Actor Action
System Response
Step1: customer knows the
Step2: System displays the
website of station then access
webpage.
the webpage.
Step4: the system displays bus
Step3: customer opens the
information with detailed
profile of bus information
information.

Customers view bus information this is used for customer select
the bus while registering.

Table 2.8essential use case documentation for view bus information
Essential use case documentation for Add manual Schedule

UC-name
Add manual Schedule
Use case number UC10

Actor
Description
The System administrator shows the manual schedule on the
Basic course of
web page.
Actor Action
action
Step2: Add manual order form
wants to show schedule.
displayed.
fills the form then click Save.
System Response
Step 5: the system save data

filled to DB, finally the
25 | P a g e
schedule is Shown for every

customer.
Alternative
Step 4: if the information filled is not valid, then enter data
courses of action
Pre-condition
Post condition

done manual schedule
Generate manual schedule on the webpage.
Table 2.9 essential use case for Add manual Schedule
2.3.3Essential user interface prototype

There are a number of forms and documents which are used in the existing system. The
first one is the ticket that sold by the sale man and bought by customer that assure the
customer to take the allocated journey.
Ticket Image
26 | P a g e
The other one is a registration form that used for the administrative office to make sure
how many tickets have been given to the sale man this form is useful for both the sale man
and administrative office for the case of auditing.
Registration form Image
27 | P a g e
2.3.4Domain modeling using CRC

Class Responsibility Collaborator (CRC) Modelling is a method to gather and define the
user requirements for an object-oriented application. The output of CRC Modelling is a CRC
Model which is a collection of CRC cards that represent the whole or part of an application
or problem domain.
Each CRC Card in the model represents a class in the solution. A class represents a
person, place, thing, event, concept, screen, or report that is relevant to the system at
hand. The name of the class appears across the top of the card. A responsibility is
anything that a class knows or does.
Class name
Responsibility
Collaborator
Table 2.10 structure of CRC card

Name
The name, located at the top of the card, describes the class that the CRC card
represents.
Responsibility
A responsibility is something that a class knows or does, represented along the left side
of the card.
Collaborators
Responsibilities will collaborate with one or more other classes to fulfill one or more
Scenarios. Collaborators are listed on the right hand side of the CRC card, next to the
responsibilities that they are helping to realize.
1. CRC card for System Administrator

System Administrator<<Actor>>
Maintain bus information
Update database
customer
Create customer Account
Change account
customer request
confirmation
28 | P a g e
Table 2.11 CRC card for System Administrator
2. CRCcard customer registration

Customer Registration<<UI>>
Fname
Lname
Uname
Ticket
Password
Email
Id no
telephone
Initial balance
Current balance
Table 2.13 CRC card customer registration
3. CRC card for bus owner registration

Bus owner<<UI>>
Ownername
Bus id
Address
Telephone
System
Id
administrator
Table 2.14 CRC card for busowner Registration
4. CRC card for bus registration

Bus owner<<UI>>
Bus type
Distance
Driver
Elapsed
Id
Level
Price
Rote
Seat number
Table 2.14 CRC card for bus Registration
System
Administrator
29 | P a g e
5. CRC card for order

order<<UI>>
Fname
Lname
Customer Id
Current amount
Route
Route id
Seat number
Seat reserve
uname
System
Administrator
Table 2.14 CRC card for order
6. CRC card for ticket

Bus owner<<UI>>
Date
Number of passenger
Route
User name
Table 2.14 CRC card for ticket
Customer
2.4 Non Functional Requirements

Error Handling Exception the system should be able to handle any exceptions(like
input mismatch exception)
Security the system should be secured from unauthorized access by any means(for
example from un authorized access)
Performance the system should give service with maximum performance
Accuracy the system should be accurate and error free
Reliability the system should be reliable all the time the users accesses the system
No redundancy the system should avoid repetition of data on the database
Availability all the data on the system should be available all the time
30 | P a g e
Efficiency the system must give service using minimum cost, memory storage, time
and human power as much as possible
User friendly interface the system should target the users need and user friendly
Part Three: Object Oriented Analysis

Introduction
Definition: -The use of modelling to define and analyse the requirements necessary for
success of a system. Object-oriented analysis is a process that groups items that interact with
one another, typically by class, data or behaviour, to create a model that accurately represents
the intended purpose of the system as a whole. Object-oriented analysis does not factor
implementation limitations into the model.
. Because the Object oriented system development approach gives easier and natural way to
break down problems into simple, small and manageable components so that it reduces the
vague appearance of the big problem. Moreover, it is predominately used and popular method in
present software development trend.
The major activities described in this chapter are Constructing a use case model ,Documenting
the use case course of events, constructing sequence and activity diagram analysis level class
diagram and user proto type about the proposed system.
3.1 System Use Cases

System use case describes the interaction between the user and system in a more
detailed way than an essential use case. While still trying to avoid referencing any UI specific
features when possible, usually certain aspects of the technology to be used can be
assumed. For instance, when writing a system use case, it is usually known whether the user
will interact with a telephonic system, an internet application, or a piece of manufacturing
equipment. Similarly, system use cases provide more detailed description of the steps that the
system will perform to fulfill the need of the user. In order to avoid committing to a specific
31 | P a g e
UI design, this detail should still be expressed in logical terms. However, it paints a clearer
picture of the requirements that the GUI must satisfy.
32 | P a g e
Figure 3.0System use case diagram
3.1.1 Use case documentation

1.Use case documentation for Login
Use case name
Login
Use case number UC1

Actor(s)
System administrator, Customer
Description
The authentication for authorized users in the system and
Basic course of
deliver them the right to visit their specified windows

Actors action
systems response
action
Step 1 User initiate to login
Step 2: The system displays
Step 2 : User enter user name
the login form.
and password
Step 4:
The system checks
the validity of the entry and

then verifies whether the user
is
authenticated
and
authorized.
Step 5:
If the user is
authenticated & authorized for
the tasks the system displays
the main page for further
action.
Alternate courses Step 3: If the users entry (user name and Password) is not
of action
validated and verified the system displays error message and

return to step 2.
33 | P a g e
Pre-condition
Post condition
The user should be registered.

User able to access the required main page.
Table 3.0 use case documentation for login
use case Documentation for Customer Registration

UC- name
Customer Registration
Use case number UC1

Actor
Description
New customer registration for membership of bus station
Basic course of
system service.
Actor Action
action
wants to register the new
customer registration form.
customer.
Step 6: the system accepts
for registration by via
customer data and stored in to
member registration form
DB
System Response
Customer pay cash for

coupon greater than 500
Br while registering.
information filled.
Step7: Customer gets the
coupon (having serial
number), user name and
password.
34 | P a g e
Alternative
Step 5: if the information filled is not valid, then enter the
courses of action
Pre-condition
Post condition
customer data again (Return step 2).

SA starts the process of new customer membership registration
New customer registered successfully and data stored to the
database.
Table 3.1 use case documentation for customer registration
use case Documentation forBus owner Registration

UC- name
Bus owner Registration
Use case number UC2

Actor
Description
Bus ownership is registered without payment.
Basic course of
action
Actor Action
System Response
Step2: System displays bus
wants to register the bus
owner registration form.
owner.
Step 6: the system accepts bus
in bus owner registration
owner profile and stored in to
form.
DB

Alternative
courses of action
Pre-condition
Post condition
information filled.
Step 5: if the information filled is not valid, then enter the bus
owner data again (Return step 2).
SA starts the process of new bus owner registration
New bus owner profile registered successfully and store in to
the database.
35 | P a g e
Table 3.2 use case documentation for bus owner registration
use case Documentation for generate ticket

Use case name
Generate Ticket
Use case number UC3

Actor
Description
System Administrator generate tickets for different level of bus

for different destination
Actor Action
System Response
customer ticket request form
validity and availability of
request form.
customer request.
Step5: customer sees the
request sent successfully.
Basic course of
action
Alternative
Step 4:the system identifies customer by checking the database.
courses of action
Pre-condition
Identifying customer request.
Post condition
Sending response for customer request
Table 3.3 use case documentation for generate ticket
use case Documentation forTicketRequest

Use case name
Ticket Request
Use case number UC4

Actor(s)
Customer
Description
Only membered customer for bus station can ask online
Basic course of
ticketing.
Actor Action
action
Step1: customer wants ask
System Response
36 | P a g e
online ticket.
validity and current customer
request form.
balance with the cost of
Step5: customer waits until
required journey.
the response come.
Step6: the system generates

required ticket with detailed
Alternative
information.
Step4: if the information filled is not valid, then enter the data
courses of action

If the customer hasnt enough balance for the required
journey the response is error message.

Pre-condition
Customer request wants to process to get ticket online.
Post condition
Viewing the required ticket.
Table 3.4 use case documentation for ticket request
UsecaseDocumentation forView Ticket

Use case name
View Ticket
Use case number UC5

Actor(s)
Customer
Description
First customer register as member for bus station then get

service online ticketing while sending request for get ticket
online the response view the ticket with detailed information on
the ticket.
37 | P a g e
Basic course of
action
Actor Action
System Response
Step1: customer opens ticket
Step2: the system checks the
request form and fills the data
privilege of customer to get
to get ticket.
online service.
Step 3: if request is true then

the system display ticket for
customer.
Alternative
.Step 2:the system checks customer whether they have
courses of action
privilege to get online ticketing service if not generate error
message and commands to be member first for this service.

Pre-condition
Customer must be member of bus station.
Post condition
Customer views the ticket online.
Table 3.5 use case documentation for view ticket
use case Documentation for view journey schedule

Use case name
View JourneySchedule
Use case number UC6

Actor(s)
Customer
Description
Every customer can view the schedule of bus station without go
Basic course of
to station office
Actor Action
action
webpage.
the webpage.
Step4: the system displays the
schedule.
System Response
journey schedule since free.
38 | P a g e
Pre-condition
Post condition
Customers view journey schedule.
Table 3.6 use case documentation for view journey schedule
use case Documentation for ViewBusInformation

Use case name
View Bus Information
Use case number UC7

Actor(s)
Customer
Description
Every customer can view bus information that the bus station
Basic course of
arranges.
Actor Action
action
webpage.
the webpage.
Step4: the system displays bus
Step3: customer opens the
information with detailed
profile of bus information
information.
Pre-condition
Post condition
System Response

Customers view bus information this is used for customer select
the bus while registering.
39 | P a g e
Table 3.7 use case documentation for view bus information
use case Documentation for Amount confirmation

UC-name
Amount confirmation
Use case number UC8

Actor
Description
The System administrator confirms customer ticket request if
Basic course of
having enough balance for the required journey distance.

Actor Action
System Response
action
Step2: customer ticket request
wants to confirm customer
confirmation form displayed
ticket request.
Step 4: the system updates the
DB by the confirmed data.
confirms customer ticket

request if the remaining
balances enough required
journey distance.
Alternative
Step 3:if the customer balance in there account is not enough
courses of action for the required journey invalid message is sent to customer.
Pre-condition
Viewing customer ticket request
Post condition
Confirmation or unconfirmation customer ticket request
Table 3.8 use case Documentation for Amount confirmation
Use case documentation for Add manual Schedule

UC-name
Add manual Schedule
Use case number UC10

Actor
40 | P a g e
Description
The System administrator shows the manual schedule on the
Basic course of
web page.
Actor Action
action
Step2: Add manual order form
wants to show schedule.
displayed.
fills the form then click Save.
System Response
Step 5: the system save data

filled to DB, finally the
schedule is Shown for every
Alternative
customer.
Step 4: if the information filled is not valid, then enter data
courses of action again (Return step 2).

Pre-condition
done manual schedule
Post condition
Generate manual schedule on the webpage.
Table 3.9 Use case documentation for Add manual Schedule
3.2 Sequence Diagrams

Definition
A sequence diagram is an interaction diagram that details how operations are carried out: what
messages are sent and when. Sequence diagrams are organized according to time. The time
progresses as you go down the page. The objects involved in the operation are listed from left to
right according to when they take part in the message sequence.
1. Sequence diagram for Login
41 | P a g e
Fig 3.1 Sequence diagram for login
42 | P a g e
2. Sequence diagram for customer registration
Fig 3.2 Sequence diagram for customer registration

43 | P a g e
3.Sequence diagram for bus owner registration
44 | P a g e
Fig 3.3 Sequence diagram for bus owner registration
45 | P a g e
4. Sequence diagram for generate ticket
Fig 3.4 Sequence diagram for generate ticket
46 | P a g e
5.Sequence diagram for ticket request
Fig3.5Sequence diagram for ticket request
47 | P a g e
6. Sequence diagram for view ticket
Fig 3.6Sequence diagram for view ticket
48 | P a g e
7. Sequence diagram for ViewSchedule
49 | P a g e
Fig 3.7sequence diagram for view schedule
50 | P a g e
8. Sequence diagram for ViewBusinformation
51 | P a g e
Fig 3.8 Sequence diagram for view bus information
9.Sequence diagram for Amount confirmation
Fig 3.9 sequence diagram for amount confirmation

52 | P a g e
10. Sequence diagram for Add manual Schedule
53 | P a g e
Fig 3.10 sequence diagram for Add manual schedule
54 | P a g e
3.3 Conceptual modeling using class diagram
Fig 3.11 conceptual modeling using class diagram
3.4 Activity diagram

Definition
55 | P a g e
Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity
diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be
described as an operation of the system. So the control flow is drawn from one operation to another. This flow
can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using
different elements like fork, join etc. In projects in which use cases are present, activity diagrams
can model a specific use case at a more detailed level.
1. Activity diagram for login
Fig 3.12 activity diagram for login
2. Activity diagram for customer registration

56 | P a g e
3.
Fig 3.13 Activity diagram for customer registration
57 | P a g e
3. Activity diagram for Bus owner registration
Fig 3.14 Activity diagram for Bus owner registration
58 | P a g e
4. Activity diagram for generate ticket
Fig 3.15 Activity diagram for Generate ticket
59 | P a g e
5. Activity diagram for customer ticket request
Fig 3.16 Activity diagram for ticket request
60 | P a g e
6. Activity diagram for View ticket
Fig 3.17 Activity diagram view ticket

61 | P a g e
7.Activity diagram for ViewSchedule
Fig 3.18 Activity diagram for view schedule

62 | P a g e
8. Activity diagram for View bus information
Fig 3.19 Activity diagram for view bus information
63 | P a g e
9. Activity diagram for amount confirmation
64 | P a g e
Fig 3.20 Activity diagram for amount confirmation
10. Activity diagram for Add manual Schedule

65 | P a g e
Fig 3.21 Activity diagram for Add manual Schedule
66 | P a g e
3.5User interface prototyping

The user interface prototype is built early, before the whole system is analyzed, designed and
implemented.
The main purpose of creating a user-interface prototype is to be able to expose and test both the
functionality and the usability of the system before the real design and development starts. This
way, you can ensure that you are building the right system, before you spend too much time and
resources on development.
User interface (UI) prototyping is an iterative analysis technique in which users are actively
involved in the mocking-up of the UI for a system. UI prototypes have several purposes:
As an analysis artifact that enables you to explore the problem space with your
stakeholders.
As a requirements artifact to initially envision the system.
As a design artifact that enables you to explore the solution space of your system.
A vehicle for you to communicate the possible UI design(s) of your system.
A potential foundation from which to continue developing the system (if you intend to
throw the prototype away and start over from scratch then you dont need to invest the
time writing quality code for your prototype).
The user inter face prototype is that shown below have used to explore an achievable and
suitable user inter face design. It helps us to test the user inter face design our system,
including before the development starts.
The following diagram describes the user interface prototyping of bus station .when
user use the system first the main page will be displayed the use what he/she require
based on their given privilege. If customers havent account only viewing information
displayed without login
67 | P a g e
Fig 3.22 user interface prototyping
3.6Supplementary specification
3.6.1 Business rules of the new system
Definition:
A business rule is a statement that describes a business policy or procedure. Business
rules are usually expressed at the atomic level -- that is, they cannot be broken down any
further.
A business rule is a statement that describes a business policy or procedure. Business
logic describes the sequence of operations that is associated with data in a database to
carry out the rule.
Kombolcha bus station have their own business rules that customer follow.
Every customer paying cash or store balance coming in to the office to get
service of online ticketing system.
68 | P a g e
When customer commands ticket for journey there balance is reduced by the
amount of journey cost.
If balance is finish trying online ticket does not get service rather adding
balance by going to station office.
Returning ticket is no fully got there balance.
3.5.2Constraints
Definition
Constraint is the element factor or a subsystem that works as a bottleneck. It restricts an
entity, project, or system (such as a manufacturing or decision making process) from
achieving its potential (or higher level of output) with reference to its goal.
Kombolcha bus stations have constraints while providing services for the customer.
The station gives service as second level.
There is no long distance journey.
The bus station arranges only minibus and medium bus.
There is no enough staffs for customer service
Shortage of civil servant for station.
3.5.3Change case
Definition
Change cases used to describe the potential requirements of our system. They are developed
during requirement gathering and also during analysis as well as design phases. It enables us
to document requirement and our system may need to full fill future changes
Kombolcha bus station established in 2002 E.C as mentioned earlier, a lot of change
or improvement is shown from day to day activities. Now peoples are satisfied based
on the station service. The following are the change case of the Bus station for the
feature that the station improves.
Additional destination countries results changing the system (adding features of
destination places).
If the bus station starts to give High level bus journey service there is obligated to
add this feature.
69 | P a g e
Part Four: System and Object design

4.1 Introductions
Systemdesign is to involve converting the description of the proposed system into logical and
then physical design specification. We expect one can understand our new system
implementation because it gives full description about whole system. Also one can understand
easily and enable to answer how the system developed and functioned in simplified manner.
The goal of system design according to the proposed project is to manage complexity by dividing
the system into smaller, manageable pieces and to increase the system: Efficiency: the system doing something well and thoroughly without waste of money and
time.
Flexibility : the system able to change to suite new condition or situation
Security: the system should be secured, i.e. not allow unauthorized users to access the
system.
Reliability: the system should be reliable.
This design system is to involve converting the description of the proposed system into logical
and then physical design specification. We expect one can understand our new system
implementation because it gives full description about whole system. Also one can understand
easily and enable to answer how the system developed and functioned in simplified manner.
70 | P a g e
4.2 Class type Architecture
Fig 4.1 class type Architecture
4.3 class modeling

71 | P a g e
The class diagram of UML is the central piece in a design or model. As

the name suggests, these diagrams describe the classes that are there inthe design. As the final
codes of an OO implementation are mostly classes, these diagrams have a very close
relationship with the final code.
There are many tools that translate the class diagrams to code skeletons, thereby avoiding errors
that might brief introduced if the class diagrams aremanuallytranslated to class definitions
byprogrammers (An_Integrated_Approach_to_Software_Engineering_By_Pankaj_Jalote).
Fig 4.2 class diagram
4.4 State Chart Modeling

State chart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime. It describes the flow of control from
one state to another state. States are defined as a condition in which an object exists and it
changes when some event is triggered.
72 | P a g e
Following are the main purposes of using State chart diagrams:

To model dynamic aspect of a system.
To model life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model states of an object.
1. State chart diagram for Login
73 | P a g e
Fig 4.3State chart diagram for Login
2. State chart diagram for Customer registration

74 | P a g e
Fig 4.4State chart diagram for Customer registration
75 | P a g e
3. State chart diagram for bus owner registration
76 | P a g e
Fig 4.5 State chart diagram for bus owner registration
4. State chart diagram for Add manual schedule
Fig 4.6 State chart diagram for Add manual schedule

77 | P a g e
5. State chart diagram for ticket request
78 | P a g e
Fig 4.7 State chart diagram for Ticket request
79 | P a g e
4.5 Component modeling

Component diagrams show how the physical components of a system are organized. And also
shows which component or objects will be accessed by whom and what type of security
infrastructures it is using. The diagram is simulated below
Database
Fig 4.8 component diagram
4.6 Deployment modeling

A UML Deployment diagrams are used to depict the relationship among runtime components
and hardware nodes. Components are Self-contained entities that provide services to other
components or actors (Object-Oriented Software Engineering, 2nd Edition).
80 | P a g e
Fig 4.9 Deployment diagram
4. 7 User interface design

The blueprint for a house (its architectural design) is not complete without representation of
doors, windows, and utility connections for water, electricity, and telephone (not to mention
81 | P a g e
cable TV). The doors, windows, and utility connections for computer software make up the
interfacedesign of a system.
Interface design focuses on three areas of concern: (1) the design of interfaces between software
components, (2) the design of interfaces between the software and other nonhuman producers
and consumers of information (i.e., other external entities), and (3) the design of the interface
between a human (i.e., the user) and the computer. In this chapter we focus exclusively on the
third interface design categoryuser interface design (Software Engineering Roger S.
Pressman, Ph.D.)
User Interface For Home Page
Fig 4.10 user interface for home page
82 | P a g e
User Interface ForUser Login Page
User Interface ForAdmin Login Page
83 | P a g e
User Interface ForAdminPage
Part Five: System Construction/Implementation

84 | P a g e
SYSTEM CONSTRACTION/IMPLEMENTATION
5.1Introduction
System implementation gives the physical coding of the system, the coding was done in
HTML, PHP, JavaScript, Jquery, and CSS language .the selection of those languages is
because we are developing the dynamic website.
In this chapter the sample coding for implementation and testing ways will be described.
5.2 Coding (coding as annex)
After other phases of the system development is completed coding takes next position. Coding
includes implementation of user interface, implementation of database and logical
implementation.
In the following interface implementation, database implementation and logicalimplementation
are discussed in context of the whole system.
Implementing Interface
In this part implementation of pages of each page is done. Pages are divided in to interface and
user interface. That is for security measurement. Rather than using same interface its better
using independent one is better.
Database Implementing
We have used MySQL Database. It supports different activities like deleting, updating,
retrieving, searching, displaying and other functionalities. The data base used for database
implementation is XAMPP V 3.1.0...
Sample code for implementation

coding for Main page
<?php
//Start session
session_start();
//Unset the variables stored in session
unset($_SESSION['SESS_MEMBER_ID']);
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
85 | P a g e
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

<title>Home</title>
<link href="menu.css" rel="stylesheet" type="text/css" />
<link rel="stylesheet" type="text/css" href="xres/css/style.css" />
<link rel="icon" type="image/png" href="xres/images/favicon.png" />

<script type="text/javascript" src="xres/js/saslideshow.js"></script>
<script type="text/javascript" src="xres/js/slideshow.js"></script>
<script src="js/jquery-1.5.min.js" type="text/javascript" charset="utf-8"></script>
<script src="vallenato/vallenato.js" type="text/javascript" charset="utf-8"></script>
<link rel="stylesheet" href="vallenato/vallenato.css" type="text/css" media="screen" charset="utf8">
<script type="text/javascript">
$("#slideshow >div:gt(0)").hide();
setInterval(function() {
$('#slideshow >div:first')
.fadeOut(1000)
.next()
.fadeIn(1000)
.end()
.appendTo('#slideshow');
}, 3000);
</script>

<script type="text/javascript" src="js/datepicker.js"></script>
<link href="css/demo.css"
rel="stylesheet" type="text/css" />
<link href="css/datepicker.css" rel="stylesheet" type="text/css" />
<script type="text/javascript">
//<![CDATA[
functionmakeTwoChars(inp) {
return String(inp).length < 2 ? "0" + inp :inp;
}
functioninitialiseInputs() {
// Clear any old values from the inputs (that might be cached by the
browser after a page reload)
document.getElementById("sd").value = "";
document.getElementById("ed").value = "";
86 | P a g e
// Add the onchange event handler to the start date input

datePickerController.addEvent(document.getElementById("sd"),
"change", setReservationDates);
}
varinitAttempts = 0;
functionsetReservationDates(e) {
try {
varsd = datePickerController.getDatePicker("sd");
vared = datePickerController.getDatePicker("ed");
} catch (err) {
if(initAttempts++ < 10)
setTimeout("setReservationDates()", 50);
return;
}
vardt = datePickerController.dateFormat(this.value, sd.format.charAt(0)
== "m");
return
if(dt == 0) return;
varedv =
datePickerController.dateFormat(document.getElementById("ed").value, ed.format.charAt(0) ==
"m");
ed.setRangeLow(dt );
if(edv<dt) {
document.getElementById("ed").value = "";
}
}
functionremoveInputEvents() {
datePickerController.removeEvent(document.getElementById("sd"), "change",
setReservationDates);
}
datePickerController.addEvent(window, 'load', initialiseInputs);
datePickerController.addEvent(window, 'unload', removeInputEvents);
87 | P a g e
//]]>
</script>
</head>
<body>
<div id="wrapper">
<div id="header">
<h1><a href="index.php"><imgsrc="xres/images/lo.jpg" alt="James Buchanan Pub and Restaurant"
width="148" height="60" class="logo" /></a></h1>
<ul id="mainnav">
<li class="current"><a href="index.php">Home</a></li>
<li><a href="BusPro.php">Bus </a></li>
<li><a href="DestnPro.php">Destination </a></li>
<li><a href="OwnerPro.php">Owner </a></li>
<li><a href="Comment.php">Comment</a></li>
<li><a href="ContactUs.php">Contact Us</a></li>
</ul>
</div>
<ul id="nav">
<li><a classes ="hsubs" href="Home.php">About</a>
<ul class="subs">
<li><a href="Home.php">Vision</a></li>
<li><a href="Home.php">Mission</a></li>
<li><a href="Home.php">Aim Of The Web Page</a></li>
</ul>
</li>
</ul>
<div id="content">
<div id="rotator">
<ul>
<li class="show"><imgsrc="xres/images/jb2/lo.jpg" width="861" height="379" alt="" /></li>
<li><imgsrc="xres/images/jb2/Bus-Tours.jpg" width="861" height="379" alt="" /></li>
</ul>
<div id="logo" style="left: 600px; height: auto; top: 23px; width: 260px; position:
absolute; z-index:4;">
88 | P a g e
<h2 class="accordion-header" style="height: 18px; marginbottom: 15px; color: rgb(255, 255, 255); background: none repeat scroll 0px 0pxrgb(53, 48,
48);">User Sign IN</h2>
<div class="accordion-content" style="margin-bottom: 15px;">
<form action="CheckLog.php" method="post"
style="margin-bottom:none;">
<span style="margin-right: 11px;">User Name: <input
type="text" name="usernameu" style="width: 165px; margin-left: 15px; border: 3px double
#CCCCCC; padding:5px 10px;"/></span><br>
<span style="margin-right: 11px;">Password: <input
type="password" name="passwordu" style="width: 165px; margin-left: 15px; border: 3px double
#CCCCCC; padding:5px 10px;"/></span><br><br>
<input type="submit" id="submit" value="Sign In"
style="height: 34px; margin-left: 15px; width: 191px; padding: 5px; border: 3px double rgb(204, 204,
204);" />
</form>
</div>
<h2 class="accordion-header" style="height: 18px; marginbottom: 15px; color: rgb(255, 255, 255); background: none repeat scroll 0px 0pxrgb(53, 48,
48);">Admin Login</h2>
<div class="accordion-content" style="margin-bottom: 15px;">
<form action="login.php" method="post" style="marginbottom:none;">
<span style="margin-right: 11px;">Username: <input
type="text" name="username" style="width: 165px; margin-left: 15px; border: 3px double
#CCCCCC; padding:5px 10px;"/></span><br>
<span style="margin-right: 11px;">Password: <input
type="password" name="password" style="width: 165px; margin-left: 15px; border: 3px double
#CCCCCC; padding:5px 10px;"/></span><br><br>
<input type="submit" id="submit" class="medium gray
button" value="Login" style="height: 34px; margin-left: 15px; width: 191px; padding: 5px; border:
3px double rgb(204, 204, 204);" />
</form>
</div>
</div>
</div>
</div>
89 | P a g e
<div id="featured">
<div id="items">
<div class="item"><a href="main-course.php"><imgsrc="xres/images/01_featured.jpg" alt="" /></a>
<h3><a href="main-course.php">Specials Offers</a></h3>
<p><a href="#"><strong>Aircon Bus</strong><br />
Come in and experience<br />Our
new Bus Type<br /> specials today!</a></p>
</div>
<div class="item"><a href="lodging.php"><imgsrc="xres/images/02_featured.jpg" alt="" /></a>
<h3><a href="lodging.php">New Route</a></h3>
<p><a href="lodging.php"><strong>From Kombolcha to Kemise Vice versa</strong><br />
Spend a relaxing evening in our Brand New hotel, steeped in Hospitality.
</a></p>
</div>
<div class="item" style="width: 860px;">
</div>
</div>
</div>
<div id="footer">
<h4>Kombolcha Bus Station • <a href="contact-us.php">Developed ByWollo University
Computer Science Students </a></h4>
<p>Hours of Operation • Mon - Sun: 10:00 am - 12:00 am</p>
<a href="index.php"></a>
<p>© Copyright 2013 Kombolcha Bus Station | All Rights Reserved <br /></p>
</div>
</div>
</body>
</html>
5.3Algorithm Development
We have the following sample algorithm development to implement our system.
User Login Algorithm

Open home page
Go to the user login form
Insert username and password
If User name and password correct
Redirect to User page
Else
90 | P a g e
Message Display=Invalid User name or password;

Stay at home page
End if
Admin Login Algorithm

Go to Home page
Go to Admin Login form
Insert username and password
If User name and password correct
Redirect to Admin page
Else
Message Display=Invalid User name or password;
Stay at home page
End if
5.4 Flow charting

A flowchart is a diagrammatic representation that illustrates the sequence of operations to be
performed to get the solution of a problem.
A flowchart is a common type of chart that represents an algorithm or process showing the steps
as boxes of various kinds, and their order by connecting these with the arrows. Flowcharts are
used in designing or documenting a process or program in various fields Flow chart is a
diagram that depicted or explaining the logic flow of single process or method.
91 | P a g e
Home page
Choose
User Login Form
Go to Admin Form
Sign In
<<Button>>
Sign In
<<Button>>
Ticket booking form

Choose
Action
<<Link>>
Fill form
Customer
Registration page
Bus owner
Registration page
Bus owner
Registration page
Save
Fill form
92 | P a g e
If Customer have sufficient Account Balance And

The Bus Ordered is Not Full
Save
False
Error Message Displayed
True
Ticket Viewer page
5.5Hardware and Software acquisitions

We need hardware and software to implement the application software i.e. client-server web
based application ofOnline Bus Ticket Reservation System for Kombolcha Town.
The hardware and software we used for developing this project are listed below.
To do this project the team use different hardware and software parts like that of:
Hardware
Desktop computer for doing all activity ,implementing the software
Different reference
Printer for printing all document part
Flash to transfer data from one computer to other.
Software
Edraw max for the drawing of some diagrams like use case diagram
PHP (XAMPP) server and MYSQL to develop our data base system.
Microsoft word for any requirements like that of writing our documentation.
Macro Dreamweaver to develop the static web page of our project and to done dynamic
page
5.6.Data preparation and installation

5.6.1 Data preparation
Data Preparation involves checking or logging the data, checking the data for accuracy, entering
the data into the computer, transforming the data and developing and documenting a database
structure that integrates the various measures.
93 | P a g e
5.6.2 Installation
Because our project is a web based application installation of the system is not needed .the
way to use the website is hosting on the web server by giving a public IP address.
5.7. Testing strategies

Developing software is a complex business. No matter how hard we try, we wont be able to
eliminate all faults simply by going through the phases of requirements, analysis, design,
specification, and implementation .however through good practice we can make sure that the
most series fault does not occur in the first place. In addition we need a separate testing phase,
with the goal of elimination all remaining faults before release.
Testing a code and other artefacts as we go along the development of the system help us to
acquire the following advantage:
It improves the quality of the software
It reduces the cost of the testing phases
It shows the programmers that they are making real progress
It reduces the number of faults that are linked to the program during the
testing phase.
It helps programmers to reorganize their code, for style performance
reasons, without breaking anything that has already written.
94 | P a g e
To simplify the testing process the project team followed the different types of tests that break
the testing process up into the distinct levels. These types testing are unit testing integration
testing and system testing.
Unit test: Each module is tested alone in attempt to discover any error in its code but since
modules exist and work with other modules in programs and system they must be tested in
longer groups.
Integration test: The process of bringing together all of the modules that a program
comprises for testing purposes. Modules are typically integrated in top won incremental
fashion.
System testing: a test performed on an entire system ensures that application programs
written and tested in isolation work properly when integrated into the total system.
5.8. Start up strategy.

After the website is launched on the internet user with an internet connection can access the
website by its keyword and can use the online services provided by the website. There are two
type of user:
1. Membered customer: this customer must go to the station office in order to be a member.
2. Un-membered customer: Customer that is not registered as member of the bus station can
view information about bus station, bus profile, and schedule.
Part Six: Conclusion and Recommendation

6.1.Conclusions
It is known that developing a system for an organization is not easy. But the team have tried its
best and developed interesting system of online bus ticket reservation for kombolcha town. It is
flexible, accurate and attractive with easy GUI approach. Generally, the team confidently can
say that the software is completed successfully with negligible errors. Finally the team expects
the software will change the general business atmosphere of the Organization and market it
more profitable than the previous manual system.
95 | P a g e
6.2. Recommendation
According to scope of our project the team develops web application .Because of the time
constraint we cannot do beyond to our scopes, but in the future the team believes that this
system can be fully operational by having enough time and fully information.
Finally the team would recommend that further work should done on the system in order to
make the system perform better for interested customers who would like to use online ticketing
system, for those who would like to work online bus ticket reservation system its recommended
to do more work on the functionalities such as: Alert expired date of product
Alert if products are short
Integrating visa card with the system
Appendix
Appendix A: List of references
1. An_Integrated_Approach_to_Software_Engineering_By_Pankaj_
Jalote
2. JEDI Slides-2.1 Object-oriented Concepts
3. Object-Oriented Software Engineering, 2nd Edition
4. Constantine and Lockwood 1999
Appendix B: Internet Site

www.google.com
www.yahoo.com
www.codeproject.com
www.htmldrive.net
www.stackoverflow.com
96 | P a g e
www.w3schools.com
www.filehorse.com
www.easycodephp.net
97 | P a g e

Bus Station Project

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bus Station Project

Diunggah oleh

Hak Cipta:

Format Tersedia

Kombolcha Bus Station Online Ticket Reservation System

Part one: Introduction

Kombolcha Bus Station Online Ticket Reservation System

1.2 Statement of the problem

1.3 Objective of the project

1.3.1 General objective

1.4 Scope and limitation of the project

Kombolcha Bus Station Online Ticket Reservation System

1.4.1 Scope of the project

The following limitations are facing during development time:

Kombolcha Bus Station Online Ticket Reservation System

Data collection methods

Database Tools :- XAMPP V 3.1.0

Kombolcha Bus Station Online Ticket Reservation System

Interface Language: - Amharic, English.

Kombolcha Bus Station Online Ticket Reservation System

1.7.1 Operational feasibility

Easily access information.

Kombolcha Bus Station Online Ticket Reservation System

1.7.3.2 Cost of the Project

Hardware development cost

Hardware development cost

Kombolcha Bus Station Online Ticket Reservation System

Laser Ink Jet

1,100 Birr Per

Software development cost

Microsoft office 2007

Microsoft SQL server 2008

Adobe Dreamweaver CS5.5

Net Beans 7.2.1

Kombolcha Bus Station Online Ticket Reservation System

Table 1.2 Software cost

Minimum 100 pages

Kombolcha Bus Station Online Ticket Reservation System

Payment for 1 person/days = 50 birr

Kombolcha Bus Station Online Ticket Reservation System

Table 1.4 Communication Plan

Kombolcha Bus Station Online Ticket Reservation System

Part Two: Business Area analysis

Kombolcha Bus Station Online Ticket Reservation System

2.1 Description of the existing system

Detailed Description of the existing system

Bottlenecks of the existing system

Kombolcha Bus Station Online Ticket Reservation System

Practices to be preserved from the existing system

2.2 Alternative solutions

Kombolcha Bus Station Online Ticket Reservation System

o To employee additional record keeper to increase the performance of the

2.3 Requirement definition (Description of the new

Advantages of the newly proposed system

Kombolcha Bus Station Online Ticket Reservation System

2.3.1 Functional Requirement

2.3.2 Essential use Case modeling (Description)

Kombolcha Bus Station Online Ticket Reservation System

Fig 2.1 Essential use case diagram

Essential Use case Description

New customer registration for membership of bus station

Kombolcha Bus Station Online Ticket Reservation System

Step1: System Administrator

Step2: System displays

wants to register the new

customer registration form.

Step 5: System checks the

Step3: System Administrator