Table Of Contents

CHAPTER 1 : INTRODUCTION

1.1 Existing System and Need for System

1.2 Scope of Work
1.3 Operating Environment – Hardware and Software

CHAPTER 2 : PROPOSED SYSTEM

2.1 Proposed System

2.2 Objectives of System
2.3 User Requirements
2.4 Feasibility Study

CHAPTER 3 : ANALYSIS & DESIGN

3.1 Analysis Phase

3.1.2 Class Diagram
3.1.3 Use Case Diagrams
3.2 Design Phase
3.2.1 Sequence Diagram
3.2.2 Collaboration Diagram
3.2.3 Activity Diagram
3.3 Module Specifications

CHAPTER 5 : FRONT END SPECIFICATION

5.1 Menu Tree

5.2 Menu Screens
5.3 Input Screens
CHAPTER 7 : IMPLEMENTATION AND TESTING

7.1 Component Diagram

7.2 Deployment Diagram
7.3 Test Plan
7.4 Test Cases

CHAPTER 8 : LIMITATIONS AND FUTURE ENHANCEMENTS

8.1 Limitations of the system

8.2 Proposed Enhancements
8.3 Conclusion & Future Scope.

2
CHAPTER 1: INTRODUCTION

1.1 Existing System:

In the existing system Colleges have to manually maintain information regarding College
busses and routes. Information relating to student passengers and bus passes have to be
maintained separately.

Need for System

 Provide a simpler method to store and access information related to buses and students.
 Provide a simple interface which will be easily used without much training.
 Reduce paperwork and make all related information accessible easily.

1.2 Scope of Work

The Bus Management System is being developed to provide a tool for the different
colleges to easily maintain the college bus information. The system will give an effective output
for the Java & Microsoft excel given as input to the system. The compiled java program given as
input to the system, after scanning the program will generate different reports.
At the start of the project setup, Microsoft Access provides an interactive part to store
information about buses; different routs of buses, student information, and bus pass etc.

3
 During the period of finalizing the idea of the system, the primary goal was to design the
system i.e those who don’t know how to handle the software. As designing work began and
things started taking shape, the system got developed to a stage where it would be used by entry
level

1.3 Operating Environment

Hardware:
 RAM 64 MB.
 Processor Pentium 4.
 Hard Disk Capacity 1GB.
 Monitor 15”

Software:

 Windows 98.xp and more versions

 Java.
 MS Access

4
CHAPTER 2: PROPOSED SYSTEM
2.1 Proposed System
The Bus Management System is a desktop system aimed at students, college administration to
maintain bus facility. The system takes student information as input source and attempts to
maintain the bus services. It allows flexibility during these processes.
The system generates exhaustive reports related to the Bus Management i.e. Fees paid,
dues, rout no. & bus stop. The reports highlight various bus services and features of the bus,
which can be subjected to improvements especially for the college administration to improve bus
transport system.
The system requires comparatively small amount of resources such as memory,
input/output devices and disk space.
The system overall keeps approach in highlighting key features of the bus services.

2.2 Objectives of System:

5
 Develop software such that everybody working in colleges bus management can handle
easily. Trainer can store & retrieve data easily. And hence, keeping these major target segments
in focus, the system was developed.
The economic factors were also worked out keeping the target segments into focus. The
objective of developing a tool for technical as well as non-technical user hence got achieved.

2.3 User Requirement:

 Needs to have basic computer knowledge.
 Needs a little orientation to be able to use the software efficiently.

2.4 Feasibility
Once the scope of the system is defined, we have to specify exactly how the system will
look like which, leads to an estimate of the computer storage requirements that form the basis for
the file design that is to be undertaken in the design phase of the project life cycle. Feasibility
study is the test of system proposal according to its workability, impact on the organization,
ability to meet user needs, effective use of resources.
There are three aspects involved in the feasibility study.

2.4.1 Technical feasibility

The technical feasibility study highlighted various differences in approaches and

implementations of the Java programming language environment. Total flexibility in bus
management makes easy to handle the information about student & bus.

2.4.2 Economical feasibility

6
 The economical feasibility of the system was given due attention as well, considering the
emerging global market .The system, primarily aimed at academic and entry level personnel,
works out to be a good prospective system, if positioned properly into the IT market. The system
has been kept very compact initially in the college only and depending on the targeted market
segment response additional GUI features could be added. The system hence, at present is
economically feasible.
Operational feasibility means whether the new system performs its work efficiently and
asks for the user needs. What are the facilities provided? What is the impact on the user?
We guaranteed that after developing the system it is 100% operationally feasible and very
easy to operate. Also on-demand reports will give the users; the exact information that itself
proves that the system is working perfectly.

Chapter 3: ANALYSIS & DESIGN

3.1Analysis Phase

3.1.1 Class Diagram.

7
Class Diagram

8
3.1.2 Use Case Diagram

A use-case instance is a sequence of actions a system performs that yields an observable result
of value to a particular actor. The sequence referred to in the definition is really a specific flow
of events through the system, or an instance. A use case defines a set of use-case instances. An
actor communicates with a use-case instance of the system. The functionality of a system is
defined by different use cases, each of which represents a specific flow of events. The
description of a use case defines what happens in the system when the use case is performed.

Enter Username

User

Enter Password

Use case diagram for Login

9
 DataEntry Enter Data

User
Data Retrieval Enter ReceiptNo

Bus schedule Enter RouteNo

Use case diagram for Data Entry, Data Retrieval, Bus Scheduling

10
 Exit

User

Use case diagram for exit button

3.2 Design phase:

3.2.1 Sequence Diagram

11
 Sequence Diagram

3.2.2 Collaboration Diagram

12
 Login BussPa Receipt
ss
4:
8: 1:
6: 3:

9: 2:
DataRetr Options DataEntr
ival y
7: 5:
11:

12: 10:

Bus
Scheduling

Collaboration Diagram

3.2.3 Activity Diagram

13
 Enter the password and
username

invalid passwords/username valid pasword /username

Prompt for select Major

Reentry function

select Option

if option is data entry if option is Data Retrival Search

information
Enter the Data
if option is schedule
Bus schedule

view
click on button view bus information
click on add button
schedule
Bus Pass Bus Receipt

click on exit

View for end Exit the Fuction

Activity Diagram

3.2.4 Entity Relationship Diagram

14
 USERNNAME PASSWORD

LOGIN

Enter into
Database

Schedule

Bus Time
RouteNo Bus Stop

3.3 Module Specification:

15
  Login Screen
 Options
 Data Entry
 Bus Pass
 Receipt
 Data Retrieval
 Bus Scheduling

CHAPTER 5: FRONT END SPECIFICATION

16
5.1 Login Screen

5.2 Option Form

5.3 Data Entry Form

17
5.4 Bus Receipt Form

5.5 Bus Pass Form

18
5.6 Data Retrieval Form

19
20
5.6 Bus Scheduling Form

21
22
23
CHAPTER 7 : IMPLEMENTATION AND TESTING

7.1 Component Diagram

College Bus
Management

DataEntr Schedule
y1.mdb .mdb

7.2 Implementation Details

7.2.1 Technological Implementation details

Platform: WIN XP.

Software: JDK 1.5.0, Edit Plus, Microsoft Office 2003, Rational Rose

Hardware: Pentium IV processor, 512 MB RAM, 80 GB HDD

24
7.2.2 Frame details

This project is being developed comprising of several frames. The names of the frames
under the scope of this project are revealed as under:

 Login Screen
 Options
 Data Entry
 Bus Pass
 Receipt
 Data Retrieval
 Bus Scheduling

7.2.3 Database details

We have used two tables as databases that have been established in Microsoft Access.
We have accessed this database from JAVA using JDBC connections and thus have arranged to
make changes to the database without directly opening the file, through the front end, i.e. JAVA
frames.

7.2.4 Interface details

This addresses to the GUI design issues associated with the project. The project involves
building an interface with good GUI and which is user friendly. The interface basically
incorporates the menu including the functionalities viz open, save, print, close.

On the click event of optimize the system provides the user with the optimized code as
output on the screen.

The exit option the system enables to exit from the application.

25
7.3 Test Plan

1. Introduction
This Test Plan provides the strategy for testing the project “College Bus
Management System”. This section of the Test Plan document describes the following.
 Purpose
 Objectives

a. Document Purpose
This Test Plan reviews:

i. Existing project information,

ii. Business requirements and critical transactions to be tested,
iii. Testing types and strategies to be implemented and
iv. A proposed testing schedule

b. Objectives
This document provides the platform for testing the project “College
Bus Management System”. The objective of testing is to see if the project meets the
Software Requirement Specifications. This document will provide - (1) the
guidelines for the testing team to test the functionalities embedded in the project
and (2) help for evaluating the Software Quality of the project.

2. Project Scope
This section of the Test Plan document describes the (1) Scope of the project
“College Bus Management System” and (2) Out of Scope of the project “College Bus
Management System”.

a. Scope of the Project

“College Bus Mangement System” will be tested for its functionality on
the following parameters (1) Unit testing, (2) Integration testing, (3) System testing
and (4) Customer Acceptance Testing (CAT). Each test is scheduled to take one
week with the Customer Acceptance test on 30-03-2012.

The testing includes testing for several functions like

 Login feature

26
  Data Entry
 Bus Scheduling
 Data Retrieval

b. Out of Scope of the Project

Performance of the project “College Bus Management System” for
operation on a number of computers is out of scope of this project at this point of
time.

3. Project Resources
Table below describes the Roles, Responsibilities and Resource Name for the
testing of the Project “College Bus Management System”.

Role Responsibilities Resource Name(s)

 Plan testing activities

Testers  Execute Test Cases
 Find, report and track defects
 Measure test effort
 Analyze results

Developers  Deliver complete builds of the application

 Provide Testers with feedback regarding
changes, new functionality
 Provide expertise and knowledge of the
application-under-test
 Eliminate agreed upon defects
Business Analysts  Interview Users
 Create Business Requirements
 Create Test Scenarios, Test Cases
Users  Describe and review Business Requirements
 Describe and review user profiles
 Perform Customer Acceptance Testing (CAT)
Desktop  Installation of software
Administrators  Troubleshooting of hardware/software
 Information regarding standard desktop

27
 Table 1 - Project Roles and Responsibilities

4. Test Strategies/Techniques
This section of the document describes – (1) Test design and (2) Test Data for the
project “College Bus Management System”.

a. Test Design
Considering the scope of the project and the time limitations, we will be
performing following tests.
a) Unit Test –
This test verifies the program logic and is based on the knowledge
of the program structure.
b) Integration Test –
This test verifies the entire system’s functionality according to the
design specification.
c) Business Requirements –
This test verifies whether specific requirements of the
customer are met.
d) Acceptance Testing –
This test verifies whether the system needs to meet the
initial objectives and customer’s expectations.

For performing the above mentioned tests, we will create test cases as shown in
table below.

Use Case ID Description Test Case

UC-1 Use Case Login TC-1

UC-2 Use Case Data Entry TC-2

UC-3 Use Case Bus Scheduling TC-3

UC-4 Use Case Data Retrieval TC-4

Use cases and Test Cases

28
 Table below describes the description of each test case mentioned in table 2 and the
results expected from a corresponding test case.

Use Test Description Expected Result

Case Case ID

ID

UC-1 TC-1 User enters a valid User is granted the access to the
username and password system

UC-1 TC-2 User enters correct User denied access and “Incorrect
username with wrong Username or Password”displayed
password

UC-1 TC-3 User enters incorrect User denied access and “Incorrect
username Username or Password”displayed

UC-2 TC-1 If Name entered contains Display error message

special characters

UC-2 TC-2 If fees paid is negative, Display error message “Incorrect

alphabet or special Data”
character

UC-2 TC-3 If dues is negative, Display error message “Incorrect

alphabet or special Data”
character

UC-2 TC-4 Check if new record Store new record successfully

stored successfully if no
errors in from.

UC-3 TC-1 Input route no If bus no is negative,alphabet or

special character display error
“INCORRECT ROUTE NO”

UC-3 TC-2 Check Stop validity in Set Display correct stop names for
bus schedule selected bus route

UC-3 TC-3 Bus Scheduling:Check Display correct time slots for

Time validity in Set bus

29
 schedule selected bus route

UC-3 TC-4 Bus Scheduling: Check if New route should be saved in the
new Bus Schedule is database with the correct
saved correctly to the parameters like Stops and Timings
Database under the
correct Route Number

UC-4 TC-1 If Receipt No. entered is Display error message “Incorrect

alphabet, special character Receipt No.”
or negative

UC-4 TC-2 Retrieve correct details Display Receipt Details for the
according to receipt no. input Receipt No.
entered

Table 3 – Description and the Expected Results of each Test Case

b. Database
A Head maintains Database that contains the login names and passwords of all the
users.

30
5. Project Tasks/Schedule
Table 4 describes the schedule for the Test Plan of the project “College Bus
Management System

Task Artifacts Projected Completion

Test Plan Completed Test Plan Version 1.0 15-2-2012

Test Environment Hardware and software 15-2-2012

Prepared

Test Cases Recorded College Bus, Test Plan 18-2-2012

and Executed Document version 1.0, Test
Results Document

Defects submitted Unit Test Results Document 1-3-2012

and tracked

Integration test Test Plan Document Version 21-03-2012

1.0

Customer Test Plan Document Version 31-3-2012

Acceptance Test 1.0

Project Schedule

6. Defect Responsibility/Resolution

Possible defects identified through manual testing will be discussed with

development team members to verify that the observed behavior constitutes a defect.
Defects found will be tried to be resolved. If not possible, they will be delivered with the
deliverables as “Known Bugs”. Defect register will be maintained to keep a track of all
the defects found in the software.

31
 7. Exit Criteria

Testing can proceed to the next stage of the process when a sufficient proportion
of the current stage has been completed All exit criteria should be satisfied by the end of
the project.

8) Goals and Deliverables

Goals and deliverables of the test plan of the “College Bus Management System” are as
follows –

a) Goals:

 To accomplish all tasks described in this test plan.

 To install a measurable, improvable, repeatable, and manageable test
process.
 To verify the functionality and content of the current version of the
application.
 To reduce the frequency of error associated with manual testing.
 To find and successfully track 100% of defects present along the user path
defined in this plan.

b) Deliverables:
 Test Planning Stage
 Test Execution and Defect Tracking Stage
 Evaluation and Improvement – this include
 Test Cycle Evaluation
 Project Summary / Evaluation

32
 7.4 Test Case for Bus Scheduling

Test Case

Use Test Step Description Expected Actual Result Successf Environm Log
Case Result ul/Faile ent No. (if Number
Cas (if different from
No. d failed) (if
e expected)
failed)

UC- TC-1 Bus Scheduling: If bus no is “INCORRECT Successf - -

3 input route no negative,alphab ROUTE NO” ul
et or special displayed when
character negative no,alphabet
display error or special character
“INCORRECT entered.
ROUTE NO”

UC- TC-2 Bus Display correct Correct Bus stops to Successf - -

3 Scheduling:Check stop names for be displayed from ul
Stop validity in Set selected bus database
bus schedule route

UC- TC-3 Bus Display correct Valid timings to be Successf - -

3 Scheduling:Check time slots for retrieved from ul
Time validity in selected bus database
Set bus schedule route

UC- TC-4 Bus Scheduling: New route Routes are correctly Successf - -
3 Check if new Bus should be saved saved in the ul
Schedule is saved in the database Database and are
correctly to the with the correct available in the Data
Database under the parameters like Entry Form.
correct Route Stops and
Number Timings

Test Case Status Successf

ul

33
8. Limitations and Future Enhancement

8.1 Limitations
 Testing on platforms like Linux and Mac has not been performed
 Standalone system with no internet support.

8.2 Future Enhancement

In Future we try to develop the following:

 The system can be made to allow access from multiple systems with a central system as
the Server for databases.
.

34