1.1 Objectives

Software Engineering and Project Management BTCS504
1. Introduction
Online bus reservation system is a project which provides a portal for bus ticket reservation. This application allows users
to book bus tickets from anywhere and anytime. The user can easily book their tickets and cancel tickets. The user can
view all the details of the website, bus, and drive. The user can also view the details of the journey and the details of the
journey timings.
Online Bus Booking System cloud based online software. This system would help customers to book a seat for their
journey, book bus. This system would also help the owner to manage the coaches, employees, clients, services etc.
Bus Reservation System will increase the booking process faster, convenient, and comfortable. Customers can book their
desired seats. They cancel heck the availability of posts on a specific date. The customer can check availability, book
ticket, or cancel ticket 24X7. The online system is available to use any time.
User doesn’t require to visit any office. They just need internet and device to use our system. They can check route,
price, class etc.
They can pay fare using a credit card, debit card, internet banking, online wallet like Paytm and cash too. Managing
buses, employees, and salary would be very comfortable using this system.
This is a safe and secure way to expand the business. System decreases the human efforts and increases customer
satisfaction.
1.1 Objectives
The main purpose of this study is to automate the manual procedures of reserving a bus ticket for any journey
made through Imo Transport Company (ITC). This system is said to be an automatic system and customers can
select seats by themselves. Specifically, objectives of this project will consist of:
i) Providing a web-based bus ticket reservation function where a customer can

buy bus ticket through the online system without a need to queue up at the
counter to purchase a bus ticket.
ii) Enabling customers to check the availability and of busses online.

Customer can check the time departure for every ITC bus through the
system.
iii) Easing bus ticket payment by obtaining a bank pin after payments is made to
the various designated banks.
iv) Ability of customers to cancel their reservation.
v) Admin user privileges in updating and cancelling payment, route and vehicle
record
1.2 Identification of Need

The old manual system was suffering from a series of drawbacks. Since whole of the system was to be
maintained with hands the process of keeping, maintaining and retrieving the information was very tedious and
lengthy. The records were never used to be in a systematic order. there used to be lots of difficulties in
III YEAR/5th Sem 1
associating any particular transaction with a particular context. If any information was to be found it was
required to go through the different registers, documents there would never exist anything like report generation.
There would always be unnecessary consumption of time while entering records and retrieving records. One
more problem was that it was very difficult to find errors while entering the records. Once the records were
entered it was very difficult to update these records.
The reason behind it is that there is lot of information to be maintained and have to be kept in mind while
running the business. For this reason, we have provided features Present system is partially automated
(computerized), actually existing system is quite laborious as one has to enter same information at three
different places.
1.3 Preliminary Investigation

The first step in the system development life cycle is the preliminary investigation to determine the feasibility of
the system. The purpose of the preliminary investigation is to evaluate project requests. It is not a design study
nor does it include the collection of details to describe the business system in all respect. Rather, it is the
collecting of information that helps committee members to evaluate the merits of the project request and make
an informed judgment about the feasibility of the proposed project.
Analysts working on the preliminary investigation should accomplish the following objectives:
• Clarify and understand the project request

• Determine the size of the project.
• Assess costs and benefits of alternative approaches.
• Determine the technical and operational feasibility of alternative approaches.
• Report the findings to management, with recommendations outlining the
• acceptance or rejection of the proposal.
1.4 Problem Domain

Booking bus ticket physically is not that easy for most of the people because it takes lot of time as they have to
stand in line which consume lots of time so online bus ticket booking is quite easy because it saves their time.
In offline bus booking there is no discount and offer available as compare to online bus booking.
Some time you have to book your bus ticket via Agent which is most costly sometimes.
No options like bus ratings Available
1.5 Solution Domain

A bus reservation system is a mobile or web software solution designed to provide customers with a
personalized easy-to-utilize user experience for booking and purchasing tickets online. It stores customers'
personal data records, scheduled routes, frequent trips, drop points, and other information
III YEAR/5th Sem 2

1.6 Platform Specification

The platform specification defines a set of platforms that specify requirements for interoperability between
software and hardware
1.6.1 Hardware
1.6.2 Software
III YEAR/5th Sem 3

2. System Requirement Analysis

A bus reservation system is a web or mobile software solution that brings high automation and personalized
user experience to simplify the ticket booking and purchasing process for customers.
Easy Registration & Social Login
You need to keep track of your customers, analyze their behavior, personalize discounts and loyalty program
aspects, save their routes and schedules to provide the best user experience.
Clients often need help or feedback, which means that your customer service and 24/7 support (if any) should
know each user’s history of bookings, payment options, and other personal details to provide.
Destination, date/time, passengers
Once your users are registered or logged in, they most likely want to book a ticket for their trip. It means
that you should provide an easy-to-use and visually-appealing bus reservation system user experience
that will allow customers to choose:
• Departure and arrival points

• Date time for their outward and return (if any) journeys
• Number of travellers.
Trip choice and tour details
Once users enter the preferred departure/arrival points, date, and number of passengers, you need to show them
the available trips with time, price, and trip details. We recommend showing a list of trips with the following
aspects:
• Trip bus provider

• Departure/arrival time
• Journey time
• Trip price
Also, users should be able to see trip details by clicking on the desired journey option. Here you can show a
specific tour flow with all bus stops, transfers, exact timing from station to station, and the overall trip
duration.
Passenger’s information
After choosing the preferred journey that meets customers’ needs, users proceed to filling in the passenger
details:
• First and Last name

• Phone number
• Email (optional).
III YEAR/5th Sem 4

This stage is crucial to identify passengers and assign specific bus seats to them. This screen shouldn’t include multiple
fields in order to keep your bus reservation system flow as simple and user-oriented as possible.
Confirmation and payment
Once filled in the required information, you can navigate customers to the checkout form where they confirm
booking and purchase tickets.
At this stage, we recommend providing customers with multiple payment options to increase sales and boost
customer’s experience.
Payment options are google pay
Routes & Schedules
A bus ticketing service is about well-thought-out routes and schedules which lead to win-win logistics for
both customers and your company.
It means that you should create a functionality dedicated to the creation and management of routes, pickups,
drop points, schedules, and other bus tour details.
For example, if customers leave their feedback desiring to add a new drop point at a specific bus stop, schedule
and route management features will allow you to add them with one-click ease.
System need to maintain quality record System need to keep

the record of booking System need to update and delete the
record System also needs a search area.
It also needs a security system to prevent data
III YEAR/5th Sem 5

2.1 Information Gathering

the process of collecting information about something. Allow plenty of time for information gathering as well as
for making necessary applications for financial support.
2.1.1 Functional Requirement
• Every online booking needs to be associated with an account

• One account cannot be associated with multiple users
• Search results should enable users to find the most recent and relevant booking options
• System should enable users to book / pay for their tickets only in a timeboxed manner after
tickets being added to the cart
• System should only allow users to move to payment only when mandatory fields such as date,
time, location has been mentioned
• System should consider timezone synchronisation when accepting bookings from different
timezones
• Booking confirmation should be sent to user to the specified contact details
2.1.2 Nonfunctional Requirement
• Use of captcha and encryption to avoid bots from booking tickets

• Search results should populate within acceptable time limits
• User should be helped appropriately to fill in the mandatory fields, incase of invalid input
• System should accept payments via different payment methods, like google pay .
• System should visually confirm as well as send booking confirmation to the
user's contact
2.2 System Feasibility
After doing the project Bus Ticket Booking System, study and analyzing all the existing or required
functionalities of the system, the next task is to do the feasibility study for the project. All project are feasible –
given unlimited resources and infinite time.
Feasibility study includes consideration of all the possible ways to provide a solution to the given problem. The
Proposed solution should satisfy all the user requirement and should be flexible enough so that future changes
can be easily done based on the future upcoming requirements.
2.2.1 Operational feasibility
No doubt the proposed system is fully GUI based that is very user friendly and all inputs to be taken all self-
explanatory even to a layman.
Besides, a proper training has been conducted to let know the essence of the system to the users so they feel
comfortable with new system.
III YEAR/5th Sem 6
2.2.2 Technical feasibility
This included the study of function, performance and constraints that may affect the ability to achieve an
acceptable system. For this feasibility study, we studied complete functionality to be provided in the system, as
described in the System requirement specification(SRS), and checked if everything was possible using
different type of frontend and backend platforms.
2.2.3 Economical feasibility
This is a very impotant aspect to be considered while developing a project. We decided the technology based on
minimum possible cost factor.
• All hardware and software cost has to be borne by the organization.

• Overall we have estimated that the benefits the organization is going to receive from the
proposed system will surely overcome the initial costs and the later on running cost for
system.
III YEAR/5th Sem 7

3. System Design
System design is the process of designing the elements of a system such as the architecture, modules and
components, the different interfaces of those components and the data that goes through that system.
System Analysis is the process that decomposes a system into its component pieces for the purpose of
defining how well those components interact to accomplish the set requirements.
The purpose of the System Design process is to provide sufficient detailed data and information about the
system and its system elements to enable the implementation consistent with architectural entities as defined
in models and views of the system architecture.
Elements of a System
• Architecture - This is the conceptual model that defines the structure, behavior and more views of
a system. We can use flowcharts to represent and illustrate the architecture.
• Modules - This are components that handle one specific tasks in a system. A combination of the
modules makes up the system.
• Components - This provides a particular function or group of related functions. They are made up
of modules.
• Interfaces - This is the shared boundary across which the components of a the system exchange
information and relate.
• Data - This the management of the information and data flow.
3.1 Use Case Diagram
A use case diagram is used to represent the dynamic behaviour of a system. It encapsulates the system's
functionality by incorporating use cases, actors, and their relationships. It models the tasks, services, and
functions required by a system/subsystem of an application. It depicts the high-level functionality of a
system and also tells how the user handles a system.
Purpose of Use Case Diagrams
The main purpose of a use case diagram is to portray the dynamic aspect of a system. It accumulates the
system's requirement, which includes both internal as well as external influences. It invokes persons, use cases,
and several things that invoke the actors and elements accountable for the implementation of use case
diagrams. It represents how an entity from the external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.

2. It depicts the external view of the system.
III YEAR/5th Sem 8

3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the act.
It is essential to analyze the whole system before starting with drawing a use case diagram, and then the
system's functionalities are found. And once every single functionality is identified, they are then transformed
into the use cases to be used in the use case diagram.Elon Musk to become Twitter CEO?
After that, we will enlist the actors that will interact with the system. The actors are the person or a thing that
invokes the functionality of a system. It may be a system or a private entity, such that it requires an entity to
be pertinent to the functionalities of the system to which it is going to interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/ system is inspected.
It identifies the no of times an actor communicates with the system. Basically, an actor can interact multiple
times with a use case or system at a particular instance of time.
III YEAR/5th Sem 9

3.2 Class Diagram
The class diagram depicts a static view of an application. It represents the types of objects residing
in the system and the relationships between them. A class consists of its objects, and also it may
inherit from other classes. A class diagram is used to visualize, describe, document various different
aspects of the system, and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that helps in
software development. Since it is a collection of classes, interfaces, associations, collaborations, and
constraints, it is termed as a structural diagram.
1.1 VITAL COMPONENTS OF A CLASS DIAGRAM

The class diagram is made up of three sections:
Upper Section: The upper section encompasses the name of the class. A class is a representation of similar
objects that shares the same relationships, attributes, operations, and semantics.
Some of the following rules that should be taken into account while representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the centre of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format
Middle Section: The middle section constitutes the attributes, which describe the quality of the class. The attributes
have the following characteristics:
e. The attributes are written along with its visibility factors, which are public (+), private (-),
protected (#), and package (~).
f. The accessibility of an attribute class is illustrated by the visibility factors.
g. A meaningful name should be assigned to the attribute, which will explain its usage inside the
class.
Relationships
In UML, relationships are of three types:
o Dependency: A dependency is a semantic relationship between two or more classes where a change
in one class cause changes in another class. It forms a weaker relationship.
o Generalization: A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
o Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is not
specified, one is considered as a default multiplicity.
III YEAR/5th Sem 10

o Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more

specific than association. It defines a part-whole or part-of relationship. In this kind of relationship, the
child class can exist independently of its parent class
o Composition: The composition is a subset of aggregation. It portrays the dependency between the
parent and its child, which means if one part is deleted, then the other part also gets discarded. It
represents a whole-part relationship
3.3 Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed as an event diagram.
It helps in envisioning several dynamic scenarios. It portrays the communication between any two lifelines
as a time-ordered sequence of events, such that these lifelines took part at the run time. In UML, the lifeline
is represented by a vertical bar, whereas the message flow is represented by a vertical dotted line that
extends across the bottom of the page. It incorporates the iterations as well as branching.
Purpose of a Sequence Diagram
1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either model’s generic interactions or some certain instances of interaction.
III YEAR/5th Sem 11

NOTATIONS OF A SEQUENCE DIAGRAM
Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top of the
diagram
Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope of the
system. It represents the role, which involves human users and external hardware or subjects. An actor may or
may not represent a physical entity, but it purely depicts the role of an entity. Several distinct roles can be
played by an actor or vice versa
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation is
performed by an element, such that the top and the bottom of the rectangle is associated with the initiation and
the completion time, each respectively.
Messages
The messages depict the interaction between the objects and are represented by arrows. They are in the
sequential order on the lifeline. The core of the sequence diagram is formed by messages.
III YEAR/5th Sem 12

3.4 Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently. Instead
of showing the flow of messages, it depicts the architecture of the object residing in the system as
it is based on object-oriented programming. An object consists of several features. Multiple objects
present in the system are connected to each other. The collaboration diagram, which is also known
as a communication diagram, is used to portray the object's architecture in the system.
Notations of a Collaboration Diagram
Following are the components of a component diagram that are enlisted below:
1. Objects: The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
• The object is represented by specifying their name and class.

• It is not mandatory for every class to appear.
• A class may constitute more than one object.
• In the collaboration diagram, firstly, the object is created, and then its class is specified.
• To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each
actor has its respective role and name. In this, one actor initiates the use case.
3. Links: The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a solid line.
The link helps an object to connect with or navigate to another object, such that the message flows are
attached to links.
4. Messages: It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labeled arrow, which is placed near
a link. The messages are sent from the sender to the receiver, and the direction must be navigable in
that particular direction. The receiver must understand the message.
III YEAR/5th Sem 13

3.5 Activity Diagram

In UML, the activity diagram is used to demonstrate the flow of control within the system rather than the
implementation. It models the concurrent and sequential activities.
The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis on the
condition of flow and the order in which it occurs. The flow can be sequential, branched, or concurrent, and
to deal with such kinds of flows, the activity diagram has come up with a fork, join, etc.
It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or

operations that are applied to model the behavioural diagram
Components of an Activity Diagram
Following are the component of an activity diagram:
Activities: The categorization of behavior into one or more actions is termed as an activity. In other words, it
can be said that an activity is a network of nodes that are connected by edges. The edges depict the flow of
execution. It may contain action nodes, control nodes, or object nodes.
Forks: Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one
inward edge and several outward edges. It is the same as that of various decision parameters. Whenever a data
is received at an inward edge, it gets copied and split crossways various outward edges. It split a single inward
flow into multiple parallel flows.
Join Nodes: Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the
inward edges as it synchronizes the flow of input across one single output (outward) edge.
Pins: It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that precisely represents one
input to or output from the action.
NOTATION OF AN ACTIVITY DIAGRAM
Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.
III YEAR/5th Sem 14

3.6 Data Flow Diagram
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is represented by
DFD. It also gives insight into the inputs and outputs of each entity and the process itself. DFD does not
have control flow and no loops or decision rules are present. Specific operations depending on the type of
data can be explained by a flowchart. Data Flow Diagram can be represented in several ways. The DFD
belongs to structured-analysis modeling tools. Data Flow diagrams are very popular because they help us to
visualize the major steps and data involved in software-system processes.
The Data Flow Diagram has 4 components:

• Process
Input to output transformation in a system takes place because of process function. The
symbols of a process are rectangular with rounded corners, oval, rectangle or a circle. The
process is named a short sentence, in one word or a phrase to express its essence
• Data Flow
Data flow describes the information transferring between different parts of the systems. The
arrow symbol is the symbol of data flow. A relatable name should be given to the flow to
determine the information which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems that are not merely
informative. A given flow should only transfer a single type of information. The direction of
flow is represented by the arrow which can also be bi-directional.
III YEAR/5th Sem 15
• Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the symbol of
the store. The warehouse is simply not restricted to being a data file rather it can be anything
like a folder with documents, an optical disc, a filing cabinet. The data warehouse can be
viewed independent of its implementation. When the data flow from the warehouse it is
considered as data reading and when data flows to the warehouse it is called data entry or data
updation.
• Terminator
The Terminator is an external entity that stands outside of the system and communicates with
the system. It can be, for example, organizations like banks, groups of people like customers or
different departments of the same organization, which is not a part of the model system and is
an external entity. Modeled systems also communicate with terminator.
0 level DFD
III YEAR/5th Sem 16

1 level DFD
4 Design
In this phase, a logical system is built which fulfils the given requirements. Design phase of software
development deals with transforming the clients 's requirements into a logically working system. Normally,
design is performed in the following in the following two steps:
1. Primary Design Phase:
In this phase, the system is designed at block level. The blocks are created on the basis of analysis done in
the problem identification phase. Different blocks are created for different functions emphasis is put on
minimizing the information flow between blocks. Thus, all activities which require more interaction are kept
in one block.
2. Secondary Design Phase:
In the secondary phase the detailed design of every block is performed.
III YEAR/5th Sem 17

The general tasks involved in the design process are the following:
1. Design various blocks for overall system processes.

2. Design smaller, compact and workable modules in each block
3. Design various database structures.
4. Specify details of programs to achieve desired functionality
5. Design the form of inputs, and outputs of the system.
6. Perform documentation of the design.
7. System reviews.
User Interface Design
User Interface Design is concerned with the dialogue between a user and the computer. It is concerned with
everything from starting the system or logging into the system to the eventually presentation of desired
inputs and outputs. The overall flow of screens and messages is called a dialogue.
The following steps are various guidelines for User Interface Design:
1. The system user should always be aware of what to do next.

2. The screen should be formatted so that various types of information, instructions and messages
always appear in the same general display area.
3. Message, instructions or information should be displayed long enough to allow the system user to
read them
4. Use display attributes sparingly.
5. Default values for fields and answers to be entered by the user should be specified.
6. A user should not be allowed to proceed without correcting an error.
7. The system user should never get an operating system message or fatal error.
4.1 Data Design

Data design is the first design activity, which results in less complex, modular and efficient program structure.
The information domain model developed during analysis phase is transformed into data structures needed for
implementing the software. The data objects, attributes, and relationships depicted in entity relationship
diagrams and the information stored in data dictionary provide a base for data design activity. During the data
design process, data types are specified along with the integrity rules required for the data. For specifying and
designing efficient data structures, some principles should be followed. These principles are listed below.
4.1.1 ER Diagram
o ER model stands for an Entity-Relationship model. It is a high-level data model. This model is used to
define the data elements and relationship for a specified system.
o It develops a conceptual design for the database. It also develops a very simple and easy to design view
of data.
o In ER modelling, the database structure is portrayed as a diagram called an entity-relationship diagram.
III YEAR/5th Sem 18

Component of ER Diagram
1 Entity: An entity may be any object, class, person or place. In the ER diagram, an entity can be represented
as rectangles.
Consider an organization as an example- manager, product, employee, department etc. can be taken as an
entity.
Weak Entity: An entity that depends on another entity called a weak entity. The weak entity doesn't contain
any key attribute of its own. The weak entity is represented by a double rectangle.
2. Attribute: The attribute is used to describe the property of an entity. Eclipse is used to represent an attribute.
a. Key Attribute: The key attribute is used to represent the main characteristics of an entity. It represents a
primary key. The key attribute is represented by an ellipse with the text underlined.
b. Composite AttributeAn attribute that composed of many other attributes is known as a composite attribute.
The composite attribute is represented by an ellipse, and those ellipses are connected with an ellipse.
III YEAR/5th Sem 19

c. Multivalued Attribute: An attribute can have more than one value. These attributes are known as a
multivalued attribute. The double oval is used to represent multivalued attribute.
d. Derived Attribute: An attribute that can be derived from other attribute is known as a derived attribute. It
can be represented by a dashed ellipse.
3. Relationship: A relationship is used to describe the relation between entities. Diamond or rhombus is used
to represent the relationship.
a. One-to-One Relationship: When only one instance of an entity is associated with the relationship, then it
is known as one-to-one relationship.
b. One-to-many relationship: When only one instance of the entity on the left, and more than one instance
of an entity on the right associates with the relationship then this is known as a one-to-many relationship.
c. Many-to-one relationship: When more than one instance of the entity on the left, and only one instance of
an entity on the right associates with the relationship then it is known as a many-to-one relationship.
d. Many-to-many relationship: When more than one instance of the entity on the left, and more than one
instance of an entity on the right associates with the relationship then it is known as a many-to-many
relationship.
III YEAR/5th Sem 20

4.2 System Architecture
A system architecture is a representation of a system in which there is a mapping of functionality onto hardware
and software components, a mapping of the software architecture onto the hardware architecture, and human
interaction with these components.
Project Category
Relational Database Management System (RDBMS): This is an RDBMS based project which is currently
using MySQL for all the transaction statements. MySQL is an opensource RDBMS System.
III YEAR/5th Sem 21

4.2.1 Structure Chart
Structure Chart represent hierarchical structure of modules. It breaks down the entire system into lowest
functional modules, describe functions and sub-functions of each module of a system to a greater detail.
Structure Chart partitions the system into black boxes (functionality of the system is known to the users but
inner details are unknown). Inputs are given to the black boxes and appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from top to bottom and left to ri ght.
When a module calls another, it views the called module as black box, passing required parameters and
receiving results.
III YEAR/5th Sem 22

5 Implementation
We have used Angular, NodeJs, Api techniques in our project.

Angular follows the component design pattern where the entire app can be divided into multiple
modules and each module can be divided into reusable components. With this approach, we can lazy
load the modules which can increase the app's performance significant and reuse the components.
Prerequisites
• Install Nodejs
• Install Angular cli
• Install Typescript globally
• Basic understanding of typescript/javascript
• Basic knowledge about Angular
• once you install nodejs and we need to install Angular cli and typescript globally with the following
commands
• npm install -g @angular/clinpm install -g typescript
• Angular cli makes it easy to start the working angular project right out of the box and it follows all the
best practices of the Angular.
• // it will create the working project.ng new todoApp// cd to todoApp
cd todoApp// start the project and app runs on 4200
npm start
• creating todoApp with angular cli
III YEAR/5th Sem 23

• starting your project with npm command
5.1 Implementation of Modules
Understand the Basic structure of the app

Once the Basic/default app is running, we can just take a moment and take a look at the project
structure that Angular CLI created for us.
III YEAR/5th Sem 24

All the automation tests go into this folder.
node_modules: This folder includes all the dependencies.

src: all the app source code will be in this folder. it has all index.html, environments, unit tests, assets etc.
.editorconfig: Editor configuration
.gitignore: This contains all the info that we don’t want to check into git
angular.json: This json file contains all the info about the project like how to build, configure, environment,
e2e etc..
package.json: This is the package manager which contains all the scripts and dependencies of the project.
tsconfig.json: Since angular is written in typescript, this file has all the typescript configuration.
tslint.json: This is linting file has all the rules which maintain the same standards across all the files.
Understand the Starting Point of the app

If you open the src folder and we can see a lot of files But, we need to understand these following files
• main.ts
• app.module.ts
• app.component.ts
• app.component.html
• index.html
III YEAR/5th Sem 25

main.ts
This is the main file which bootstraps the Angular. AppModule is the first module it invokes at line 11.
III YEAR/5th Sem 26

app.module.ts
Angular follows the component design pattern in which App is divided into modules and each module is divided into components.
So, This is the starting Module of the App which imports other modules and we need to declare the components that we use in this
module. Since we are using AppComponent
app.component.ts
In Angular, Each component has styleUrl, template, and selector. A template is the html file and styleurl is the
CSS file to be applied for this component.
III YEAR/5th Sem 27

app.component.html
If we look at the above app.component.ts file it uses this html file as the template. This is the html file that we see when app loads in
the browser.
index.html
This is the index.html which loads in the browser first. If we look at line number 12, we are using <app-
root></app-root> selector which is declared in the app.component.ts above.
III YEAR/5th Sem 28

5.2 Results
• This is a home Screen of our Bus Booking System
• In this popup the passengers enter there detail of book a bus
III YEAR/5th Sem 29

• In this popup the passengers confirm ticket and make and see the seat available and the cost of one seat
and make a payment of bus serviceses
6 Testing
Testing is vital for the success of any software. no system design is ever perfect. Testing is also carried in
two phases. first phase is during the software engineering that is during the module creation. second phase is
after the completion of software. this is system testing which verifies that the whole set of programs hanged
together.
6.1 Testing Objectives
The first step in the test planning process is to document the high-level test objectives. The test objectives
provide a prioritized list of verification or validation objectives for the project. We use this list of objectives
to measure testing progress, and verify that testing activity is consistent with project objectives.
Test objectives can typically be grouped into the following categories:
• Functional correctness- Validation that the application correctly supports required business processes
and transactions. List all the business processes that the application is required to support. Also list
any standards for which there is required compliance.
III YEAR/5th Sem 30

• Authorization- Verification that actions and data are available only to those users with correct
authorization. List any key authorization requirements that must be satisfied, including access to
functionality and data.
• Service level- Verification that the system will support the required service levels of the business.
This includes system availability, load, and responsiveness. List any key performance indicators
(KPIs) for service level, and the level of operational effort required to meet KPIs.
• Usability- Validation that the application meets required levels of usability. List the required training
level and user KPIs required.
The testing team, development team, and the business unit agree upon the list of test objectives and their
priority.
A test case covers one or more test objective, and has the specific steps that testers follow to verify or validate
the stated objectives.
6.2 Testing Scope
The scope of a test defines what areas of a customer's product are supposed to get tested, what
functionalities to focus on, what bug types the customer is interested in, and what areas or features should
not be tested by any means.
If something is in scope, please test it; if something is out of scope, it should not be tested. Understanding
the scope of a test is crucial to be a successful tester on our platform.
Information that makes up the scope of test-
• Test environment
First things first – The URL given in the Access section at the top of the test overview page defines
what website or app should be tested. Any other websites or apps are not under test (unless stated
differently in the test description). For more information, see Testing Environment.
• Features
Each test contains at least one of what we call features. A feature can describe an area of a product,
e.g. a landing page, product overview page or product detail page of a webshop, it can describe a
process like the checkout process of a website or an app, or it can even be a particular functionality
that should be tested.
When a customer sets up a new test, so-called standard features will be added by default. Customers
can use these standard features and modify them if they want or add completely new features.
You can only submit bugs if a corresponding feature exists in the test. For example, if none of the
given features covers the checkout process, you cannot submit bugs related to it.
III YEAR/5th Sem 31

• Bug types and severities

Customers are usually only interested in certain bug types and/or severities, not in all of them at
once (Functional, Content, Visual, Usability). You can see which bug types and severities are in
scope by checking out the payout table in the right sidebar on the test overview page:
• Test instructions
Test instructions are displayed below the Access section and they consist of three sections:
➢ Goal of this test: This section usually covers a general purpose of the test. It often names
what to focus on, e.g. new feature that is about to be released.
➢ Out of scope: What is not supposed to get tested is specifically stated here. On live websites,
you may oftentimes not complete orders at the end of a checkout process, or some areas of
a website or an app might not be ready yet. Make sure to stick to this information –
disregarding them can have big consequences.
➢ Additional requirements: If there is anything else to point out, information will be given in
this section. This might be information concerning the whole test, credentials for user
accounts, dummy payment information, etc.
• Attachments
In rare cases, one or more attachments might be provided. Those are usually Microsoft Excel
spreadsheets or PDF files given by the customer directly.
• Requested devices
You will usually be invited to the cycle to use a specific device of yours. This device is displayed
in the right sidebar on the test overview page. For ideal device coverage, our distribution algorithm
invites testers for different devices. You may only use the requested devices that were assigned to
you. When testing websites, you must not only use the correct device but also one of the available
browsersonthelist.
If the seats for the requested device are taken, you may be able to join the test with a different
device if there are other slots opened. On the 'Submit a Bug' page you can check with which device
you are in the test.
6.3 Testing Principles

There are seven principles in software testing:
1. Testing shows the presence of defects: The goal of software testing is to make the software fail.
Software testing reduces the presence of defects. Software testing talks about the presence of defects
and does not talk about the absence of defects. Software testing can ensure that defects are present but
III YEAR/5th Sem 32

it cannot prove that software is defect-free. Even multiple testing can never ensure that software is
100% bug-free. Testing can reduce the number of defects but not remove all defects.
2. Exhaustive testing is not possible: It is the process of testing the functionality of the software in all
possible inputs (valid or invalid) and pre-conditions is known as exhaustive testing. Exhaustive testing
is impossible means the software can never test at every test case. It can test only some test cases and
assume that the software is correct and it will produce the correct output in every test case. If the
software will test every test case, then it will take more cost, effort, etc., which is impractical.
3. Early Testing: To find the defect in the software, early test activity shall be started. The defect detected
in the early phases of SDLC will be very less expensive. For better performance of software, software
testing will start at the initial phase i.e. testing will perform at the requirement analysis phase.
4. Defect clustering: In a project, a small number of modules can contain most of the defects. Pareto
Principle to software testing state that 80% of software defect comes from 20% of modules.
5. Pesticide paradox: Repeating the same test cases, again and again, will not find new bugs. So, it is
necessary to review the test cases and add or update test cases to find new bugs.
6. Testing is context-dependent: The testing approach depends on the context of the software developed.
Different types of software need to perform different types of testing. For example, the testing of the
e-commerce site is different from the testing of the Android application.
7. Absence of errors fallacy: If a built software is 99% bug-free but it does not follow the user requirement
then it is unusable. It is not only necessary that software is 99% bug-free but it is also mandatory to
fulfill all the customer requirements
6.4 Testing Method Used
There are 2 types of testing-

1. Functional Testing-
Functional testing involves testing the application against the business requirements. It incorporates
all test types designed to guarantee each part of a piece of software behaves as expected by using uses
cases provided by the design team or business analyst. These testing methods are usually conducted
in order and include:
• Unit Testing-
Unit testing is the first level of testing and is often performed by the developers themselves. It
is the process of ensuring individual components of a piece of software at the code level are
functional and work as they were designed to. Developers in a test-driven environment will
typically write and run the tests prior to the software or feature being passed over to the test
team. Unit testing can be conducted manually, but automating the process will speed up
delivery cycles and expand test coverage. Unit testing will also make debugging easier because
finding issues earlier means they take less time to fix than if they were discovered later in the
III YEAR/5th Sem 33
testing process. Test Left is a tool that allows advanced testers and developers to shift left with
the fastest test automation tool embedded in any IDE.
• Integration Testing-
After each unit is thoroughly tested, it is integrated with other units to create modules or
components that are designed to perform specific tasks or activities. These are then tested as
group through integration testing to ensure whole segments of an application behave as
expected (i.e, the interactions between units are seamless). These tests are often framed by user
scenarios, such as logging into an application or opening files. Integrated tests can be
conducted by either developers or independent testers and are usually comprised of a
combination of automated functional and manual tests.
• System Testing-
System testing is a black box testing method used to evaluate the completed and integrated
system to ensure it meets specified requirements. The functionality of the software is tested
from end-to-end and is typically conducted by a separate testing team than the development
team before the product is pushed into production.
• Acceptance Testing-
Acceptance testing is the last phase of functional testing and is used to assess whether the final
piece of software is ready for delivery. It involves ensuring that the product is following all of
the original business criteria and that it meets the end user’s needs. This requires the product
be tested both internally and externally, meaning you’ll need to get it into the hands of your
end users for beta testing along with those of your QA team. Beta testing is key to getting real
feedback from potential customers and can address any final usability concerns.
2. Non-Functional Testing-
Non-functional testing methods incorporate all test types focused on the operational aspects of a piece
of software. These include:
• Performance Testing-
Performance testing is a non-functional testing technique used to determine how an application
will behave under various conditions. The goal is to test its responsiveness and stability in real
user situations. Performance testing can be broken down into four types:
➢ Load testing, is the process of putting increasing amounts of simulated demand on your
software, application, or website to verify whether it can handle what it is designed to handle.
➢ Stress testing, takes this a step further and is used to gauge how your software will respond
at or beyond its peak load. The goal of stress testing is to overload the application on purpose
III YEAR/5th Sem 34

until it breaks by applying both realistic and unrealistic load scenarios. With stress testing,
you’ll be able to find the failure point of your piece of software.
➢ Endurance testing, also known as soak testing, is used to analyze the behavior of an
application under a specific amount of simulated load over longer amounts of time. The goal
is to understand how your system will behave under sustained use, making it a longer process
than load or stress testing (which are designed to end after a few hours). A critical piece of
endurance testing is that it helps uncover memory leaks.
➢ Spike testing, is a type of load test used to determine how your software will respond to
substantially larger bursts of concurrent user or system activity over varying amounts of
time. Ideally, this will help you understand what will happen when the load is suddenly and
drastically increased.
• Security Testing-
With the rise of cloud-based testing platforms and cyber attacks, there is a growing concern
and need for the security of data being used and stored in software. Security testing is a non-
functional software testing technique used to determine if the information and data in a system
is protected. The goal is to purposefully find loopholes and security risks in the system that
could result in unauthorized access to or the loss of information by probing
the application for weaknesses. There are multiple types of this testing method, each of which
aimed at verifying six basic principles of security:
➢ Integrity
➢ Confidentiality
➢ Authentication
➢ Authorization
➢ Availability
➢ Non-repudiation
• Usability Testing-
Usability testing is a testing method that measures an application’s ease-of-use from the end-
user perspective and is often performed during the system or acceptance testing stages. The
goal is to determine whether the visible design and aesthetics of an application meet the
intended workflow for various processes, such as logging into an application. Usability testing
is a great way for teams to review separate functions, or the system, is intuitive to use.
• Compatibility Testing-
III YEAR/5th Sem 35

Compatibility testing is used to gauge how an application or piece of software will work in
different environments. It is used to check that your product is compatible with multiple
operating systems, platforms, browsers, or resolution configurations. The goal is to ensure that
your software’s functionality is consistently supported across any environment you expect
your end users to be using.
6.5 Test Cases

• Verify that users can search for bus by date, for checking their status and timings.
• Verify that search results have bus details, timings and availability.
• Verify that clicking the search results open complete details for bus.
• Verify that the user should see real-time bus status of availability of seats.
• Verify user is able to see available seats in bus.
• Verify User is able to select single or more than one seat.
• Verify when user select seat, enters passenger details and then does the payment then the selected
seat should get booked.
• Verify once the user has booked the ticket then he can download the ticket.
• Verify status of the seat gets change to booked after the user has booked the ticket.
• Verify user should receive SMS or mail after successfully booking of ticket.
• Verify user is able to book one ticket per document.
• Verify when user cancels the ticket then his amount should get refunded.
• Verify when user should not be able to cancel the ticket after the train has left the station.
• Verify when user tries to cancel the ticket on the day of travelling then he should not get full amount
as refund.
• Verify by trying payment from different types of payment mode.
• Verify once the user has cancelled the ticket then ticket status should get change to available.
• Verify error message is displayed when user enters special character in from and to field.
• Verify error message is displayed when user leaves all the field blank and click on search bus.
• Verify error message should be displayed when user leaves passenger details form blank and click on
submit.
• Verify payment should get rejected when user enter wrong credentials during payment process.
• Verify user should not be able to purchase ticket if he is not login to application.
• Verify ticket price mentioned on the user ticket , that amount is only debited from customer account.
• Verify user details are mentioned properly on the ticket which user has downloaded.
• Verify user amount is refunded if his account is debited but ticket is not booked due to network issue.
• Verify user is not able to purchase ticket for past date.
III YEAR/5th Sem 36
• Verify user is getting ticket on his what's app if he has selected the option of share ticket on what's
app.
• Verify after successful booking of ticket user should be able to see his ticket booking history.
• Verify if user has entered special character in name field during ticket booking process then error
message should be displayed.
• Verify when user clicks on edit passenger details button then Edit Traveller section should get open.
• Verify user is able to delete the passenger detail by clicking on remove button.
• Verify user is able to change his boarding point during ticket booking process.
6.6 Sample Test Data and Results
Validation Testing:
• When we did not give designation so it show us validation us error
=>Please Enter the city!!
• When we give any special letter or number in input field so it show us error:
=>Inalid City Name!!
III YEAR/5th Sem 37

• When We didn’t give any information to input field so it give us error:
=>Required Field!!
7 Limitation
Limitation of Proiect on Bus Ticket Booking System
Although I have put my best efforts to make the software flexible, easy to operate but limitations cannot be
ruled out even by me. Though the software presents a broad range of options to its users some intricate
options could not be covered into it; partly because of logistic and partly due to lack of sophistication.
Paucity of time was also major constraint, thus it was not possible to make the software foolproof and
dynamic. Lack of time also compelled me to ignore some part such as storing old result of the candidate etc.
Considerable efforts have made the software easy to operate even for the people not related to the field of
computers but it is acknowledged that a layman may find it a bit problematic at the first instance. The user is
provided help at each step for his convenience in working with the software.
List of limitations which is available in the Bus Ticket Booking Svstem:
• Excel export has not been developed for Bus, Ticket due to some criticality
• The transactions are executed in off-line mode, hence on-line data for Booking, Customer capture and
modification is not possible.
• Off-line reports of Bus, Bus Route, Booking cannot be generated due to batch mode execution.
III YEAR/5th Sem 38

8 Future Scope
Future Scope of the Project:
In a nutshell, it can be summarized that the future scope of the project circles around maintaining
information regarding:
We can add printer in future.

We can give more advance software for Bus Ticket Booking System including more facilities
We will host the platform on online servers to make it accessible worldwide Integrate multiple load
balancers to distribute the loads of the system
Create the master and slave database structure to reduce the overload of the database queries
Implement the backup mechanism for taking backup of codebase and database on regular basis on different
servers
The above mentioned points are the enhancements which can be done to increase the applicability and usage
of this project. Here we can maintain the records of Bus and Ticket. Also, as it can be seen that now-a-days
the players are versatile, i.e. so there is a scope for introducing a method to maintain the Bus Ticket Booking
System. Enhancements can be done to maintain all the Bus, Ticket, Booking, Customer, Bus Route.
We have left all the options open so that if there is any other future requirement in the system by the user for
the enhancement of the system then it is possible to implement them.ln the last we would like to thanks all
the persons involved in the development of the system directly or indirectly. We hope that the project will
serve its purpose for which it is develop there by underlining success of process.
9 Conclusion
Conclusion of the Project Bus Ticket Bookinq System:
Our project is only a humble venture to satisfy the needs to manage their project work. Several user friendly
coding have also adopted. This package shall prove to be a powerful package in satisfying all the
requirements of the school. The objective of software planning is to provide a frame work that enables the
manger to make reasonable estimates made within a limited time frame at the beginning of the software
project and should be updated regularly as the project progresses.
At the end it is concluded that we have made effort on followinq points...
• A description of the background and context of the project and its relation to nark already done in the
area.
III YEAR/5th Sem 39

• Made statement of the aims and objectives of the project.
• The description of Purpose, Scope, and applicability.
• We define the problem on which we are working in the project.
• We describe the requirement Specifications of the system and the actions that can be done on these
things.
• We understand the problem domain and produce a model of the system, which
• describes operations that can be performed on the system.
• We included features and operations in detail, including screen layouts.
• We designed user interface and security issues related to system.
• Finally the system is implemented and tested according to test cases.
10 Bibliography and References

• Angular.io
• YouTube
• Wikipedia
• Javatpoint
• GeeksforGeeks
• Angular.material
III YEAR/5th Sem 40

1.1 Objectives

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.1 Objectives

Uploaded by

Copyright:

Available Formats

Software Engineering and Project Management BTCS504

i) Providing a web-based bus ticket reservation function where a customer can

ii) Enabling customers to check the availability and of busses online.

iv) Ability of customers to cancel their reservation.

1.2 Identification of Need

1.3 Preliminary Investigation

• Clarify and understand the project request

1.4 Problem Domain

1.5 Solution Domain

III YEAR/5th Sem 2

1.6 Platform Specification

III YEAR/5th Sem 3

2. System Requirement Analysis

Easy Registration & Social Login

Destination, date/time, passengers

• Departure and arrival points

Trip choice and tour details

• Trip bus provider

• First and Last name

III YEAR/5th Sem 4

Confirmation and payment

Routes & Schedules

System need to maintain quality record System need to keep

III YEAR/5th Sem 5

2.1 Information Gathering

2.1.1 Functional Requirement

• Every online booking needs to be associated with an account

2.1.2 Nonfunctional Requirement

• Use of captcha and encryption to avoid bots from booking tickets

2.2 System Feasibility

2.2.1 Operational feasibility

2.2.2 Technical feasibility

2.2.3 Economical feasibility

• All hardware and software cost has to be borne by the organization.

III YEAR/5th Sem 7

3.1 Use Case Diagram

Purpose of Use Case Diagrams

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

III YEAR/5th Sem 8

III YEAR/5th Sem 9

3.2 Class Diagram

1.1 VITAL COMPONENTS OF A CLASS DIAGRAM

In UML, relationships are of three types:

III YEAR/5th Sem 10

o Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more

3.3 Sequence Diagram

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

III YEAR/5th Sem 11

NOTATIONS OF A SEQUENCE DIAGRAM

III YEAR/5th Sem 12

3.4 Collaboration Diagram

Notations of a Collaboration Diagram

• The object is represented by specifying their name and class.

III YEAR/5th Sem 13

3.5 Activity Diagram

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or

Components of an Activity Diagram

Following are the component of an activity diagram:

NOTATION OF AN ACTIVITY DIAGRAM

Activity diagram constitutes following notations: