The document outlines a Bus Information Live Monitoring System designed to streamline bus route management for students and transportation staff. It highlights the limitations of the existing manual system, proposing an integrated software solution that enhances security, user interface, and data management through various modules, including administration and bus management. The system is structured to provide different user roles and functionalities while ensuring data protection and user satisfaction.

1. BUS INFORMATION LIVE MONITORING
SYSTEM

2. OBJECTIVE
Bus Information Live Monitoring System software is a globally deployable, integrated,
workflow based end-to-end system starting from searching bus routes to gathering
entering details of the BUS. This is a complete application for Students as well as
Transportation Staff. Vendors provide the information like, available routes, timings,
etc. Students will have facility to view all the BUS details under college transportation.
There is also scope to measure the user satisfaction regarding the BUS selection.

3. EXISTING SYSTEM
 Current system was analyzed to identify the potential drawbacks.
 The analysis was carried out in an environment where BUS details are going to be
added manually.
 This existing system is not providing secure registration and profile management of
all the users.
 This manual system gives us very less security for saving data and some data may be
lost due to mismanagement.
 The current system posed several challenges with respect to entering the BUS
details in the register and maintaining the BUS timings.
 When the number of BUS and their ROUTS increased it became extremely difficult
to maintain the registers as they were more prone to manual data entry errors.

4. PROPOSED SYSTEM
 The system provides different access rights and login for the users such as
administrator and registered members.
 The proposed system helps the Administrator to configure the basic settings details.
 The system also provides facility for entering the bus details such as bus type bus
model and adding new bus.
 User friendliness is provided in the application with various controls provided by
system rich user interface.
 System also tracks the Bus details from the database which can be visible to
students directly.

5. NUMBER OF MODULES
The system after careful analysis has been identified to be presented with the following modules:
 Administration Module
 Student Module
 Bus Management Module
 Security and Authentication module.
 Report module.

6. SYSTEM REQUIREMENTS

7. SOFTWARE REQUIREMENTS
 Operating System : Windows XP/2003 or Linux (Any OS)
 User Interface : HTML, CSS
 Client-side Scripting : JavaScript
 Programming Language : Java
 Web Applications : JDBC, Servlets, JSP
 IDE/Workbench : My Eclipse 8.6
 Database : Oracle 10g XE
 Server Deployment : Tomcat 6.0

8. HARDWARE REQUIREMENTS (MINIMUM)
 Processor : Pentium IV
 Hard Disk : 40GB or more
 RAM : 512MB or more

9. SYSTEM REQUIREMENT SPECIFICATION

10. OVERVIEW
Bus Monitoring and Tracking System software is a globally deployable, integrated,
workflow based end-to-end system starting from searching bus routes to gathering entering
details of the BUS. This is a complete application for Students as well as Transportation Staff.
Vendors provide the information like, available routes, timings, etc. Students will have facility to
view all the BUS details under college transportation. There is also scope to measure the user
satisfaction regarding the BUS selection.
STUDY OF THE SYSTEM
In the flexibility of uses the interface has been developed a graphics concepts in mind, associated
through a browser interface. The GUI’s at the top level has been categorized as follows
•Administrator Interface Design.
• User Interface.

11. •Security Authentication.
•Reports.
•General end-users.
The administrative user interface will maintain the different users details, the interface helps the
administration with all the transactional states like which users sending the mails, and which
users receiving whishing mails, users details information history. And the statistics of the system
in difference strategies.
NUMBER OF MODULES
The system after careful analysis has been identified to be presented with the following
modules:
Administration Module
Student Module
Bus Management Module
Security and Authentication module.
Report module.

12. MODULES DESCRIPTION:
Administration Module:
In this system administrator is one of the end user. he is a non restricted user in this
system. Administrator can add the bus details and also he can add services from where to where.
He can modify the bus details as well as services details also. He can take back up to provide the
security for user data.
Student Module:
In this module Student can view the BUS details, BUS Routes and BUS driver details.
Bus Management Module:
In this module admin can add the bus details and admin can update bus details also.
And administrator has a facility to delete bus details and as well as Services details also.
Security and Authentication Module:
The user details should be verified against the details in the user tables and if it is valid user,
they should be entered into the system. Once entered, based on the user type access to the
different modules to be enabled / disabled and
Individual user can change their default password or old password.

13. Report Module:
In this Module the User and Administrator can generate the different types of Reports
according to their access.
Functional Requirements:
1.A system/software requirement that specifies a function that a system/software component
must be capable of performing.
2.These are software requirements that define behavior of the system, that is, the fundamental
process or transformation software and hardware components of the system perform on inputs to
produce outputs.
3.User login name and password are functional requirements for login into the system.
4.User must give proper credentials while registering into this system.

14. Non Functional Requirements:
1.Software requirement that describes not what the software will do, but how the software will
do it, for example, software performance requirements, software external interface requirements,
software design constraints, and software quality attributes.
2.24x7 days available is one of the non functional requirements.
3.Performance - Response Time, Throughput, Utilization.
4.Scalability, reliability.

15. FEASIBILITY REPORT

16. TECHNICAL FEASIBILITY:
Evaluating the technical feasibility is the trickiest part of a feasibility study. This is because, at
this point in time, not too many detailed design of the system, making it difficult to access
issues like performance, costs on (on account of the kind of technology to be deployed) etc. A
number of issues have to be considered while doing a technical analysis.
1. Understand the different technologies involved in the proposed system
2. Find out whether the organization currently possesses the required technologies
OPERATIONAL FEASIBILITY:
Proposed projects are beneficial only if they can be turned into information systems that will
meet the organizations operating requirements. Simply stated, this test of feasibility asks if the
system will work when it is developed and installed.
ECONOMIC FEASIBILITY:
Economic feasibility attempts 2 weigh the costs of developing and implementing a new system,
against the benefits that would accrue from having the new system in place. This feasibility
study gives the top management the economic justification for the new system.

17. DATA FLOW DIAGRAMS

18. A graphical tool used to describe and analyze the moment of data through a system manual
or automated including the process, stores of data, and delays in the system. Data Flow
Diagrams are the central tool and the basis from which other components are developed.
The transformation of data from input to output, through processes, may be described
logically and independently of the physical components associated with the system. The
DFD is also know as a data flow graph or a bubble chart.
The Basic Notation used to create a DFD’s are as follows:
1. Dataflow: Data move in a specific direction from an origin to a destination.
2. Process: People, procedures, or devices that use or produce (Transform) Data. The
physical component is not identified.
3. Source: External sources or destination of data, which may be People, programs,
organizations or other entities.
4. Data Store: Here data are stored or referenced by a process in the System.

19. DATA FLOW DIAGRAM:

20. LEVEL-1:
ADMINISTOR:

21. LEVEL-2:
ADMINISTRATOR:
GUI Interface Add Route Data Base
Data Base View Routet GUI Interface
GUI Interface Add Bus Data Base
Data Base View Bus GUI Interface

22. GUI Interface AddPickUpP Data Base
Data Base ViewPickUpP GUI Interface
GUI Interface AddBusShed Data Base
Data Base ViewBusShed GUI Interface

23. LEVEL-1:
CUSTOMER

24. LEVEL-2:
AUTHENTICATION:
UI Interface Username,Password Authentication Server
Authentication Server Authentication UI Interface
NO

25. SDLC METHODOLOGIES

26. This document play a vital role in the development of life cycle (SDLC) as it describes
the complete requirement of the system. It means for use by developers and will be the basic
during testing phase. Any changes made to the requirements in the future will have to go through
formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss iterative
development, but it was the first model to explain why the iteration models.
The steps for Spiral Model can be generalized as follows:
The new system requirements are defined in as much details as possible. This usually involves
interviewing a number of users representing all the external or internal users and other aspects of
the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is usually a
scaled-down system, and represents an approximation of the characteristics of the final product.

27. A second prototype is evolved by a fourfold procedure:
1. Evaluating the first prototype in terms of its strengths, weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.
Risk factors might involved development cost overruns, operating-cost miscalculation, or any
other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous prototype, and if
necessary, another prototype is developed from it according to the fourfold procedure outlined
above.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents
the final product desired.
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried on a
continuing basis to prevent large scale failures and to minimize down time.

28. THE FOLLOWING DIAGRAM SHOWS HOW A SPIRAL MODELACTS LIKE:

29. ADVANTAGES OF SPIRAL MODEL:
Estimates(i.e. budget, schedule etc .) become more realistic as work progresses, because important
issues discovered earlier.
It is more able to cope with the changes that are software development generally entails.
Software engineers can get their hands in and start working on the core of a project earlier.

30. E-R DIAGRAM

32. UML DIAGRAMS

33. UNIFIED MODELING LANGUAGE DIAGRAMS
The unified modeling language allows the software engineer to express an analysis model using
the modeling notation that is governed by a set of syntactic semantic and pragmatic rules.
USER MODEL VIEW
This view represents the system from the users perspective.
The analysis representation describes a usage scenario from the end-users perspective.
STRUCTURAL MODEL VIEW
In this model the data and functionality are arrived from inside the system.
This model view models the static structures.
BEHAVIORAL MODEL VIEW
It represents the dynamic of behavioral as parts of the system, depicting the interactions of
collection between various structural elements described in the user model and structural model
view.
IMPLEMENTATION MODEL VIEW
In this the structural and behavioral as parts of the system are represented as they are to be built.
ENVIRONMENTAL MODEL VIEW
In this the structural and behavioral aspects of the environment in which the system is to be
implemented are represented.

34. CLASS DIAGRAMS

35. CLASS DIAGRAM
JSP: Implicit Objects

36. CLASS COLLABORATION DIAGRAMS

39. SecurityDAO
~con: Connection
-desc: String
-flag: boolean
<<create>>+SecurityDAO()
+loginCheck(regbean: Profile): String
+loginaudit(loginid: String)
+changePassword(regbean: Profile): boolean
+changeQuestion(regbean: Profile): boolean
+recoverPasswordByQuestion(regbean: Profile): String
+checkUser(userName: String): String
ProfileDAO
+con: Connection
-flag: boolean
<<create>>+ProfileDAO()
+registration(regbean: Profile): boolean
+getProfile(loginname: String, path: String): Profile
+modifyProfile(regbean: Profile): boolean
+getReportFromTo(sdate: String, edate: String): CoreHash
+getReportPresent(): CoreHash
+changeAccountStatus(loginid: String, status: int): boolean
CheckDAO
~con: Connection
~del: int
~stmt: Statement
~pstmt: PreparedStatement
~rs: ResultSet
+getBus(cb: CheckBean): Vector
SheduleDAO
~con: Connection
~pstmt: PreparedStatement
~stmt: Statement
~rs: ResultSet
+addBusShedule(sb: SheduleBean): int
+selectBusShedule(): Vector
+deleteShedule(sb: SheduleBean): int
+updateShedule(rb: SheduleBean): int
AbstractDataAccessObject
-mCon: Connection
-mProps: Properties
+getProperties(): Properties
+setProperties(aProps: Properties)
+getConnection(): Connection
+getSequenceID(tableName: String, pkid: String): int

40. USE CASE DIAGRAMS

41. SYSTEM USE CASE DIAGRAM
System
Bus Information Live Monitoring System
Admin
User

42. ADMINISTRATOR USE CASE DIAGRAM

43. STUDENT USE CASE DIAGRAM

44. SEQUENCE DIAGRAMS

45. ADMIN SEQUENCE DIAGRAM

46. STUDENT SEQUENCE DIAGRAM

47. ACTIVITY DIAGRAMS

48. SERVLET CONTAINER

49. ADMINISTRATOR ACTIVITY DIAGRAM
Admin
Login
AdminHome
AddBusDetails ViewBusDetails StudentInfo UpDateBusInfo ChangePassword
Logout
yes
loginfail

50. CUSTOMER ACTIVITY DIAGRAM
User
Login
UserHome
ViewBus SearchBus
viewProfile ChangePassword
Logout
yes
loginfail

51. COMPONENT DIAGRAM
&
DEPLOYMENT DIAGRAM

52. COMPONENT DIAGRAM:

53. DEPLOYMENT DIAGRAM:

54. OUTPUT SCREENS

55. Home

60. Admin

67. User

69. THANK YOU