PROJECT REPORT

BUS PASS SYSTEM

Submitted by:-
Amit Bhardwaj (O-1205)
Kunal Bhardwaj (O-1220)
 CERTIFICATE
This is to certify that Software Engineering project on
" BUS PASS SYSTEM"
has been developed by

Amit Bhardwaj, Roll number: O-1205

and
Kunal Bhardwaj, Roll number: O-1220

of

B.Sc. (Honours) Computer Science

Acharya Narendra Dev College

..........................
Dr. Vibha Gaur
 ACKNOWLEDGEMENT
We sincerely express our gratitude to Dr. Vibha Gaur who guided us at
every step in understanding and preparing this project. It’s our privilege to
acknowledge our deepest sense of gratitude to her for her inspiration and
motivation which helped us immensely. The project could not have taken
its present form sans her endeavour and numerous suggestions. We are
extremely grateful for her unstinted support and encouragement in the
preparation of this project.
 CONTENTS
1 Analysis
1.1 Preliminary analysis
1.1.1 Problem definition
1.2 Detailed analysis
1.2.1 Requirement elicitation
1.2.2 Initiating process
1.2.3 FAST
1.2.4 Quality Function Deployment
1.2.5 Use cases
1.3 System requirement
1.3.1 Target operating system
1.3.2 Platform
1.3.3 Hardware specification
1.4 Use case
1.5 Feasibility study
1.5.1 Financial feasibility
1.5.2 Technical feasibility
1.5.3 Behavioural feasibility
1.6 Process modeling
1.7 Team structure
2 Modeling
2.1 Data dictionary
2.2 Entity- Attribute relation diagram
2.3 Data flow diagram
2.4 State transtion diagram
3 Design
3.1 Data design
3.2 Interface design
3.3 Architectural design
4 Measurement
5 Risk analysis
6 Project scheduling
7 Software quality assurance
8 Coding
9 Testing
9.1 White box testing
9.2 Black box testing
10 Bibliography
 1. Analysis
1.1 Preliminary analysis
Delhi Transport Corporation(DTC) provides concessional pass to students of various
schools and colleges. For this students have to get attested a DTC bus pass form from
college and they waste a lot of time for their concessional passes. DTC instead,
should provide anyone-anytime web based system. The system needs a computer as
end user interface. Anyone(here students only) can create his concessional bus pass
by submitting some of his detail online with a pin number which he/she has to buy
from any bus depot or any official outlet and get its print-out. It should allow balance
carry forward method during off season(1st May to 1st July)i.e. if any student
extends his pass, then his pass duration will continue even after the off-season.
This way the DTC will provide ease to students for getting there passes and avoiding
long queues in front of DTC office.

1.1.1 Problem description

The system will provide students with an interactive web based bus pass creation
facility which will simply require students' college name and roll number with a
confedential PIN which student has to buy from the DTC bus depot or college office.
The system will be used by any student and at any time. Regarding to creation of
concessional bus passes the system will actually cater only Delhi university having
various departments and the route type will be restricted to all-routes .

The system will allow user to create his own concessional bus pass as well as request
for reissue of pass if a student loses it(only if he/she knows his/her bus pass number).

For this Delhi University should provide their students' database to DTC with
student's name, roll number, age, department, course, father's name,photograph,
adderess and fee status.

Once the student take addmission in college and pay his full fees he becomes eligible
for concessional bus pass and he can get his pass from online bus pass system. If
student withdraws his name from college his data will automatically deleted from the
data base and will become inelligible for bus pass query.

For generating the bus pass, the student has to enter his details his department,
name, name roll number and confedential PIN only. The time period will depend on
the PIN card he has bought, the duration of validation of pass will be of one month,
two months and five months. After successfully checking validation of data (by
system), user may get the printout of his bus pass.

For reissue, student has to apply online by entering his department name, name, roll
number and previous bus pass number .The bus pass will be generated at the cost of
Rs.30 which will be adjusted in the students' bus pass validation period.
For the purpose of avoiding fake use of bus passes, beholder of pass must carry his
college i-card with him while travelling. Student must also take care while renewing
his pass that it would not add to current validation period if remaining.

The special performance issues which the system will have to take care will be less
response time w.r.t. generating output and managing many clients at the same time.

In this manner the system will take into account maximum requirements of students
and provide them easy way to get their bus pass avoiding queues.

1.2 Detailed analysis

1.2.1 Requirement elicitation

It is an approach that helps in overcoming the problem of scope, understanding
ability and volatility of the project by providing the guidelines for requirement
gathering activity in an organized manner.

1.2.2 Initiating process

1. The objective and requirements of the software were decided upon by group
discussions, interviews and meetings with the students.
2. This project aims at automating the database and functioning of DTC bus pass
system.
3. The software will benefit the organization in reducing the workforce and tasks
for validation of data.
4. The one time cost of the system will be high, but then the running cost of the
system would be much lower.
5. The system has to be developed within a time constraint(real time), as it would
be needed soon.

1.2.3 Facitilated application specification techniques

In the project like the one we are involved in, the FAST approach can really be very
beneficial as it can be used to identify the exact problem, proposed elements of the
solution, negotiating the different approaches with the customer, specify preliminary
set of solution requirements in an atmosphere that is conducive to the
accomplishment of the goal.
We have used FAST approach to list all the requirements of the system. Whereas to
add quality to the system QUALITY FUNCTION DEPLOYMENT is used.
1. List of Objects :-
1. Internet enabled computer with printing facility,
2. Bus pass,
3. Students,
4. College,
5. Bus Depot,
 6. PIN card.

2. List of Services :-
1. Creation of concessional bus pass,
2. Apply for reissue of pass,
3. printout of bus pass.

3. List of Constraints :-
11 Cost of development of project should be manageable.
11 Whosoever student wants to use this system has to buy the PIN card
from any official outlet.
11 The scope of system is restricted to Delhi University considering various
Departments instead of colleges.
11 Software will be accessed by many people at a time, may result in
decrease in response time during peak season(month of july and january).
11 Applicant must be student.
11 There should be data connectivity between Delhi University and DTC.
11 User will not get the passes delivered at home rather they have to be
printed. So, user must conform that a working printer is attached with it.

4. List of Validation criteria:-

1. No field should be left blank while filling online form for Bus pass.
2. Entries like Name, rollnumber, course and PIN should be eneterd correctly.
3. Name and Roll number should be correct according to department database.
4. While reissue process bus pass number must be entered correctly.

1.2.4 Quality Function Deployment

At the same time QFD is equally important as it is a quality management technique
that translates the needs of the customer into technical requirements for the software.
The following are the two types of requirements that apply to our project.

1. Normal Requirements :-
11 The system will take input from the user and allow him to create
concessional bus pass or apply for refund.
11 The system should provide facility to take printout of the bus pass and
the reciept for refund.
11 The system should update students' database as soon new admission take
place or student withdraws from college.

2. Expected Requirements :-
11 The system should be user friendly and interactive.
11 The system should be fast enough to verify the data provided as input as
soon as possible.
11 Eas of interaction.
 11 Should display details of the user after verification of data including
student's photograph.

1.3 System Requirement Specification

A System Requirements Specification (SRS) lists the requirements of a system that is
planned to be developed.

1.3.1 Targeted operating system:-

Linux Distros.

1.3.2 Platform required:-

Front end :- java.
Back end: :- Mysql.

1.3.3 Hardware Specification:-

The server should be able to store the data of students at university as well as at DTC
office.
DTC Server :- those who have pass.
Delhi University Server :- record of students currently studying.
Minimum 1000 gb of memory is required for storing data and its backup. and should
be extendable as the need arises.

1.4 Use case

Use cases describe the interaction between a primary actor(the initiator of the
interaction) and the system itself, represented as a sequence of simple steps. Actors
are something or someone which exist outside the system under study, and that take
part in a sequence of activities in a dialogue with the system to achieve some goal.
Actors may be end users, other systems, or hardware devices. Each use case is a
complete series of events, described from the point of view of the actor.

Use cases should not be confused with the features of the system under consideration.
A use case may be related to one or more features, and a feature may be related to one
or more use cases.
Use Case

System boundary 

Enters 
self
Needs pass
 details

Requests 
issue
Student or
re­issue

If details
Recieve
 entered
s pass

Checks  If valid 
validation

Generat
es pass

DTC  If request specified
Mana
ges  If correct Fulfils 
datab asks  request
request
ase
1.5 Feasibility study
The feasibility of the product is a question that confirms the reality to the ideas.
Feasibility test is critical .The dimensions that define the feasibility of project are:

1.5.1 Financial feasibility

The total cost of the project is the cost of developing the software plus maintaining it.
The cost of developing the software is less as compared to cost of maintaining it.
Maintenance cost is very high as the records to be maintained are of huge size and
therefore acquire more space. In addition to this, records are very critical as a result
of which it is necessary to maintain the backup and thus the maintenance cost on the
part of the customer is high.
The cost of creation of database is low as we can use the database servers used by
DTC in present system.

1.5.2 Technical feasibility

The technical feasibility is high as the software is coded in JAVA which is a platform
independent language so the software so developed could be easily applied on the
web .
The software will be framed in open source environmnt so it could easily be applied
on any operating system.

1.5.3 Behavioural feasibility

The customers need not be trained in using the software or have any past experience
of working in the software as it is very user friendly and easy to use.

1.6 Process model

For the development of the current software ,we will the Linear Sequential Model
as we found it to be most appropriate in the light of our project .

Reasons for choosing the model:

1. As student of Delhi university and use DTC bus pass we were known to the
problem and what the students require so we applied linear sequential model
in our project.
2. Also as there are 2 person in the group we can not go with any other model that
requires more people.

1.7 Team structure

We use DD (democratic decentralized) team structure as it suits the project
requirements.
Reason for choosing Team Structure:
1. In this software team there is no permanent leader as we two are the only
developers.
2. All decisions on probable approaches that can be followed are made by group
consensus i.e. in this case by discussion amongst ourselves.
3. Communication among the team members is lateral.
 2. Modeling
Analysis Model Objectives:
1. to describe what the customer requires,
2. to establish a basis of a software design, and
3. to define a set of requirements that can be validated once the software is built.

The structure of the analysis model

2.1 Data Dictionary

This is the core part of the model. Data dictionary is a repositary that contains
description of all data objects consumed or produced by the software.

The data dictionary is an organized listing of all data elements that are pertinent to
the system, with precise, rigorous definitions so that both user and system analyst will
have a common understanding of inputs, outputs, components to stores and even
intermediate calculations.

The data dictionary for the two of the data flow’s is as follows:
1. Name : Student Data
Alias : None
Where used/How Used : By DTC for validation(output)
By students for pass generation
(input)
 Description:
Student Data = Name + Course+ Roll Number
Name = First Name + Last Name
Course = Course Name + Course Year
Course Year = [ 1 | 2 | 3 ]
Roll Number = Enrollment Number + Admission Year
Enrollment Number = *A 5-digit number given to student at the time of
his admission*
Admission Year = *A 4-number string i.e. the year in which the student
enrolled.*
Course Name = *A string of maximum allowable length 20*
First Name = * any string of maximum allowable length 20*
Roll
Last Name =* any string
no. of maximum coallowable length 20*
Age ur of student*
na= *a 2-digit number for age
gender m = [M|F] se
e

2. Name e Students
: PIN card Information
Alias n: PIN
r
Where used/How Used : h Bu
PASS generation (Input)
ol ol ys
ls Pas d ser_
Description: no
val s
PIN = serial no
idit .
number+ code + validation period + price
Serial no. y= *Any unique 10 digit number specifying pin card no.*
co
Code = *Any unique 16 Busdigit number * de
Department
Validation period = [ 1 | 2 |5] PIN card
Price pass
= Currency Unit + Amount pri
Currency Unit ho = [ Rs. ] ce
ld
er
2.2 Entity-Attribute relation diagram (EARD)
The entity relationship diagram depictsge sethe data objects. The
relationships between
Co
ERD is the noation that is used to conduct lls
nerthe data modeling activity.
Entity-Attribute
nta relation diagram (EARD) ate
ins

DTC

co
nt
University
ac
 ts

User input

User commands and

input
2.3 Data flow diagram (DFD)
Data Flow Diagram provides an indication of how data are transformed as they move
through the system. Also depicts the function that transforms the data flow.

Context Level DFD BUS

Context level diagram shows the interaction between the system and outside entities.
PASS
The DFD is designed to show how a system is divided into smaller portions and to
SYSTEM
highlight the flow of data between those parts. This context-level data-flow diagram
is then "exploded" to show more detail of the system being modeled.

Display Prints pass

information

Monitor displays
Student
information
Level 1 DFD

Key board

User command
Interact and input
with
user

Student
data

Valid data
Student Pass
information proces
sing

Provide Provide
output output
OUT
PUT

display print

Display
student
information
Level 2 DFD (refines PASS PROCESSING):-

Student
detail Valid
data
Reissue and
pass no.
Query request
Issue and type
PIN request
Perivous
PIN PASS
process number
processin
g

Valid pin Valid

number pass
number

output

Display
Pass print

student Display
information
2.4 State Transition Diagram(STD)
The state transition diagram indicates how the system behaves as a consequence of
external events.

Invalid query
Invoke user 
interaction
Input student details
Read input
Process 
details
Invalid input
Invoke  Intract 
with user

Input pass/ 
PIN no.
validation
Process 
input
Valid and no 
query
Request query
Input query
Valid data
Invoke  output 
device
Pass generation
Display  action 
status
Invoke user intraction
2.5 PSPEC
PSPEC specifies the work of each process i.e. the description of each function
presented in DFD.

1.PSPEC: STUDENT DATA

The pocess "Student data " performs all student detail validation for BUS
PASS SYSTEM. Student detail receives, Name of the student,roll number,
course / department name, and college name. If any field is left blank by
the user then a message will be displayed. If all the details given are valid
then details will be transferred to the pass processing.

2. PSPEC: PIN REQUEST AND ISSUE

PIN REQUEST AND ISSUE perform all validation for PIN validation for
BUS PASS SYSTEM. PIN is compared to all the valid PIN (those exists).
If PIN is valid the process returns PIN value(i.e. value, time period) to the
system and deletes its record from database.

3. PSPEC: PASS No. REQUEST AND REISSUE

This process request for pervious pass number(lost pass) and check for its
validation. If pass number is valid and matches the details of student then
process after calculating the remaining time period of the pass displays the
information and stdebt can take its print out.
 3. Design
Design is the meaningful engineering representation of the thing that is to be built. It
can be traced to customer requirements and at same time assessed for quality against
a set of predefined criteria for “GOOD DESIGN”. It focuses on four areas of
concern-: DATA, ARCHITECTURE, INTERFACE AND COMPONENTS.

Guidelines for good design:

1. The design should exhibit an architectural structure: -
11 It should be created using recognizable design patterns.
11 It should be composed of a component that has good design characteristics.
11 It should help in implementation and testing.
2. A design should be modular –logically partitioned into elements that perform
specific functions and sub functions.
3. A design should lead to data structure that are appropriate for objects to be
implemented.
4. A design should have an interface that reduces complexity.

3.1 Data design

Table: Student detail
name: stud_info

Field name Data type Width Description

roll_no chars 9 Roll number of student
first_name chars 15 First name of student
last_name chars 15 Last name of student
course chars 20 Course in which student is
admitted
course_year int 1 Can be 1 or 2 or 3
addr chars 50 Address of student
p_graph jpeg Photograph of student
age int 2 Age of student
gender char 1 Can be M/F, gender of student
Table: PIN details
name: pin_info
Field name Data type width Description
ser_no Unsigned long 20 Serial number of pin card
number
code Unsigned long 16 Pin code
price int 2 Price of tha coupon
period int 1 Can be 1/2/5 period pin is
valid once used
valid date 8 Pin valid, if unused

Table: pass detail

name: pass_info
DELHI TRANSPORT 
Field name Data type Width Description
ser_no CORPORATION
Unsigned long 16 Serial number of
pass
roll_no chars 9 Roll number of
FIRST  holder
NAME
holder_name chars 20 First name of holder
LAST 
h_course chars 20 Holder's course
NAMEaddr chars 50 Address of holder
valid_date
ROLL  date 8 Valid period of pass
p_graph jpeg Photograph of
NUMBER student
COURSE
3.2 Interface design
Enter “N” to issue new pass and “R” to Re­issue
INPUT design shows simple interface, allows user to enter his/her details. To
issue/re-issue bus pass user must enter appropriate choice and then he/she can
generate pass by clicking on command button(generate pass).
OUTPUT design is just an view of bus pass and information of bus pass for the pass
which student will get.
Enter 16 digit PIN Enter old pass number
Input and output interace for project are:
Input interface:

Generate pass
Output interface:

DELHI TRANSPORT  Photograph

CORPORATION

NAME

VALIDITY

PASS 
NUMBER
COURSE

SEX
AGE

ADDRESS

NOTE: Student must carry his/her college i­card while 
 travelling.
3.3 Architectural Design
In this phase large systems are generally decomposed to smaller sub systems that
account for functionality of the complete software system.

This process of identifying the sub systems and establishing a framework for
subsystem control and communication is called architectural design.
1. Principle subsystems that are functionally independent were identified and
distinguished.
2. A general model of control relationships between system parts was established.
3. Each subsystem was further decomposed into their sub-functions.

BUS PASS SYSTEM

DETAILS 
ENTER  GENERATE 
PASS

ISSUE RE­ISSUE

ENTER 
ENTER PIN  BUS 
CARD PASS
 NUMBER  NUMBER
 4. Measurement
Project metrics
1. used to project workflow and technical activities.
2. Used to avoid development schedule delays, to metigate potential risks, and to
assess product quality on an on-going basis.

Function oriented matrics

1. Function oriented matrics are based on the functionality offered by the
software. Function oriented matrics uses function point as normalization value.
Function point(F.P) is calculated using emphirical relationship based on the
countable measures of the software's information domain and assesment of the
software complexity.

Weighting factor
Measurement parameters Count Simple Average complex Total

Number of user input 5 3 4 6 15

Number of user output 8 5 6 4 48
Number of inquiries 2 4 6 2 12
Number of files 3 3 5 4 15
Number of external interface 5 2 4 3 15
Count total ⵉfi 105

Number of user inputs : Each user input that provides distinct application-oriented
data to the software is counted.

Number of user outputs : Each user output that provides distinct application-
oriented data to the software is counted.

Number of user inquiries : An inquiry is defiend as an online input that results in the
generation of some immediate software response in the form of an on-line output.

Number of files : Each logical master file (i.e., a logical grouping of data that may be
one part of a large database or a separate file) is counted.

Number of external interfaces : All machine readable interfaces that are used to
transmit information to another system are counted.

Questions Grade value

Does the system require reliable backup and recovery? 5

Are data communications required? 3

Are there distributed processing functions? 4

Is performance critical? 5

Will the system run in an existing, heavily utilized operational 4

environment?
Does the system require online data entry? 5

Does the on 0-line data entry require the input transaction to be built 2
over multiple screens or operations?

Are the master files updated online? 5

Are the inputs, outputs, inquiries complex? 2

Is the internal processing complex? 5

Is the code designed to be reusable? 0

Are conversion and installation included in the design? 0

Is the system designed for multiple installations in different 0

organizations?
Is the application designed to facilitate change and ease of use by the 3
user?

∑F= 43

Function point (FP) = Total count * (0.65 + 0.01 * (∑ Fi ) )

= 105 * [0.65 + 0.01 * 43]
= 113
 5. Risk Analysis
Risk analysis is a technique to identify and assess factors that may jeopardize the
success of a project or achieving a goal.

This technique also helps to define preventive measures to reduce the probability of
these factors from occurring and identify countermeasures to successfully deal with
these constraints when they develop to avert possible negative effects on the
competitiveness of the project.

Assesing Overall Project Risk

End users are moderately committed to use the project
1. Requirements are fully understood
2. End users have realistic expectations
3. The project scope is stable
4. Project Requirements are fully stable
5. The project team is inexperienced with the technology to be
implemented
6. All customer constituencies do not agree on the importance of the
project to be built.

Identifying potential risks and developing a plan to mitigate, monitor and manage
risks is of paramount importance. Risk analysis enables to build a risk table by
providing detail guidelines in identification and analysis of risk. This is achieved by
1. Risk avoidance
2. Risk monitoring
3. Risk management and contingency plan

For our project the risk table is as follows:

Impact values Category

1. Catastrophic PS :-Product size
2. Critical BI :- Business Impact
3. Marginal DE :- Development Environment
4. Negligible SR :- Support risk
 Category Probability Impact RMMM
Risks
Size estimate may be PS 40% 2 Ensure that
significantly low requirements are clearly
understood
Choose appropriate
sizing technique to
determine the software
size
Customer will change PS 30% 1 Update the server
requirements regularly about the
status and working
assumptions
Get Customers’
feedback periodically
Lack of database DE 60% 3 Server should be
management maintained cautiously
Conduct audits to see if
server is working
properly.
Chances of internet SR 60% 3 Give training to staff
hacking and
malfunctioning.
End user may resist the BI 10% 1 Involve the end users in
system development of the
system.
Develop techniques to
evoke favorable
responses from the
users.
 6. Project Scheduling
The project schedule and project plan is tracked and monitored on a continuing basis.
A task set selector is applied on the overall project to determine the degree of rigor
with which the software process should be applied.

Computation of task set selector:

Adaptation criteria Grade Weight New Product

development
Size of project 3 1.2 1 3.6

Number of users 5 1.1 1 5.5

Business criticality 4 1.1 1 4.4

Longevity 5 0.9 1 4.5

3 1.2 1 3.6
Stability of requirements
Ease of communication 4 0.9 1 3.6

Maturity of technology 3 0.9 1 3.6

Performance constraints 3 0.8 1 2.4

Project staffing 1 1 1 1

Interoperability 2 1.1 1 2.2

Task set selector 2.99

(TSS)

Interpreting the TSS value and selecting the task set:

TSS = 2.99.
It lies in the category of 2.99 > 2.4

Therefore the task set selector value recommends a strict degree of rigor to be
followed in scheduling the processes.
 7. Software Quality Assurance
Software quality assurance claims to focus on quality tools that audit the source code
to determine compliance with language standards. It is an umbrella activity, applied
at each step in the software process.

It identifies
1. Evaluations to be made
2. Audit and reviews to be performed
3. Standards to be maintained
4. Error reporting and tracking
5. Measurement of changes made
6. Amount of feedback
 8. Coding
This software is developed using Java Applets and back end is queried by MySQL.
JAVA applets has wide boom in netorking software and is platform independent(i.e. it
works on every operating system.).
 9. Software Testing
Testing is a process of executing a program with the intent of finding an error. A good
test case is one that has a high probability of finding an as-yet-undiscovered error. A
successful test is one that uncovers an as-yet-undiscovered error.
In this project since no coding has been done, we describe testing in brief.

9.1 White-Box Testing

White-box testing also called glass-box testing, is a test case design method that uses
the control structure of the procedural design to derive test cases. Using white-box
testing methods, the software engineer can test cases that
1. Guarantee that all independent paths within in a module have been exercised at
least once
2. Exercise all logical decisions on their true and false sides
3. Execute all loops at their boundaries and within their operational bounds
4. Exercise internal data structures to ensure their validity

The various white-box testing techniques are:

11 Basis path Testing
11 Control Structure Testing

9.2 Black-Box Testing

It is also called behavioral testing, focuses on the functional requirements of the
software. It enables the software engineer to derive sets of input conditions that will
fully exercise all functional requirements for a program.
Black Box testing is not an alternative to white box testing rather; it is a
complementary approach that is likely to uncover a different class of errors than
white box methods.

The various black-box testing techniques are:

1. Graph-based Testing
2. Equivalence Partitioning
3. BV Analysis
4. Comparison testing
5. Orthogonal array Testing
 10. Bibliography
11 Software Engineering : A Practitioner' s Approach by Roger S. Pressman
11 World Wide Web