School Bus Routing Management System: As A Part of The Curriculum of

SHYAMA PRASAD MUKHERJI COLLEGE (FOR WOMEN)
UNIVERSITY OF DELHI
As a part of the curriculum of
B.Sc. (H) COMPUTER SCIENCE
PRESENTING
SOFTWARE ENGINEERING PROJECT REPORT (CSHP-410)
SCHOOL BUS ROUTING MANAGEMENT SYSTEM

By:
AYUSHI GOYAL (14075270009)
K.S DIVYA KUMARI (14075270019)
SHIKHA MAHAUR (14075270039)

UNDER THE GUIDANCE OF
DR. BALJEET KAUR
SHYAMA PRASAD MUKHERJI COLLEGE (FOR WOMEN),

PUNJABI BAGH (WEST), NEW DELHI - 110026
1
ACKNOWLEDGEMENT
______________________________________________
We place on record and warmly acknowledge the continuous encouragement,

invaluable supervision, timely suggestions and inspired guidance offered by our
teacher Dr. Baljeet Kaur, Assistant Professor, Department of Computer Science
at Shyama Prasad Mukherji College(for women), University of Delhi, in bringing
this project to a successful completion.
We are grateful to Dr. Pooja Vashisth, Head of the Department of Computer

Science for permitting us to make use of the facilities available in the department
to carry out the project successfully.
We would like to dedicate special thanks to our lab staff, Mr. Sarbjeet and Mr.
Uday for their support and for providing amenities throughout the completion of
our project.
Last but not the least, with a sense of gratitude, we acknowledge the efforts of
entire hosts of well-wishers who have in some way or other contributed in their
own special ways to the success and completion of this software engineering
project on “School Bus Routing Management System”.
AYUSHI GOYAL ______________
K.S DIVYA KUMARI ______________
SHIKHA MAHAUR ______________
2
CERTIFICATE
______________________________________________
This is to certify that Ayushi Goyal (14075270009), K.S Divya Kumari

(140752700019) and Shikha Mahaur (140752700039), students of B.Sc. (H)
Computer Science IInd year 4th semester have completed Software Engineering
project entitled “SCHOOL BUS ROUTING MANAGEMENT SYSTEM”
during the academic session 2014-2017 under my guidance and supervision. I
approve the project submission in the partial fulfillment of the requirements for
the award of Bachelor of Science and submitted to the Department of Computer
Science of Shyama Prasad Mukherji College (For Women), University of Delhi.
This matter presented in this project has not been submitted to any other
university/college for the award of any other Degree.
Guided & Approved by:
Dr. Baljeet Kaur

Assistant Professor,
Department of Computer Science
3
TABLE OF CONTENT
______________________________________________
1. PROBLEM STATEMENT……………………………………………………… 8 – 9
2. SOFTWARE PROCESS MODEL ………………………………………………. 10
3. SOFTWARE REQUIREMENT SPECIFICATION…………………………….. 11 - 25

1. Introduction………………………………………………………………….. 11 - 14
1.1 Purpose……………………………………………………………………11
1.2 Scope……………………………………………………………………...11 -
12
1.2.1 Objective………………………………………………………… 11
1.2.2 Goal………………………………………………………………12
1.3 Definitions and Abbreviations…………………………………………...12 -

13
1.3.1 Definitions………………………………………………………..12
1.3.2 Abbreviations…………………………………………………….13
1.4 References……………………………………………………………….13
1.5 Overview………………………………………………………………...13 - 14
2. The Overall Description……………………………………………………..14 - 20
2.1 Product Perspective……………………………………………………....14
2.1.1 System Interface………………………………………………….15
2.1.2 User Interface…………………………………………………….15 - 16
2.1.3 Hardware Interface……………………………………………….16 - 17
4
2.1.4 Software Interface…………………………………………………..17
2.1.5 Communication Interface………………………………………......17
2.1.6 Memory Constraints………………………………………………..17
2.1.7 Operation……………………………………………………………17 - 18
2.1.8 Site Adaption Requirements………………………………………..18
2.2 Product Functions…………………………………………………………..18 -

19
2.3 User Characteristics…………………………………………………............19
2.4 Constraints………………………………………………………………......19
2.5 Assumptions and Dependencies…………………………………………...19 -

20
3. Specific Requirement…………………………………………………………20-25
3.1 External Interfaces…………………………………………………….…20
3.2 Functions…………………………………………………………………20
3.3 Performance Requirements……………………………………………….21
3.4 Logical Database Requirements…………………………………….…….21
3.5 Design Constraints………………………………………………………..21
3.6 Software System Attributes………………………………………………21 -

25
3.6.1 Reliability……………………………………………….………..21 - 22
3.6.2 Availability……………………………………………………….22
3.6.3 Security………………………………………………….………..22
3.6.4 Maintainability……………………………………………………23
5
3.6.5 Portability…………………………………………………………23
3.6.6 Flexibility…………………………………………………………23
3.6.7 Reusability………………………………………………………...23
3.6.8 Usability………………………………………………………..... 23
3.7 Organizing the Specific-Requirements…………………………………...23
3.7.1 System Mode……………………………………………….…….23 - 24
3.7.2 User Class…………………………………………………………24
3.7.3 Features……………………………………………………………24
3.7.4 Stimulus…………………………………………………………...24
3.7.5 Response…………………………………………………….….....25
4. Data Flow Diagram……………………………………………………………26 - 33
4.1 Context Level Diagram……………………………………………………26
4.2 Level - 1 Data Flow Diagram………………………………………………27
4.3 Level - 2 Data Flow Diagram………………………………………………28
4.4 Data Dictionary…………………………………………………………….29 -

32
4.5 Entity Relationship Diagram……………………………………………….33
5. Use Case Diagram…………………………………………………………… 34 - 45
5.1 Use Case Description……………………………………………………..35

45
6
6. White Box Testing …………………………………………………………..46 - 50
6.1 Flow Graph……………………………………………………………..48
6.2 Flow Chart ……………………………………………………………..49
6.3 Cyclomatic Complexity ……………………………………………….50
7. Screens ……………………………………………………………………….51 – 65
8. Project Metrics ………………………………………………………………66 - 68
9. Effort Estimation using Cocomo Model ……………………………………69 - 71
10. Project Scheduling ……………………………………………………….72 - 76
10.1 Time-Line chart ……………………………………………………..72 - 73
10.2 Task table …………………………………………………………..74 - 76
11. Risk Management ……………………………………………………….. 77
7
SCHOOL BUS ROUTING MANAGEMENT SYSTEM
PROBLEM STATEMENT
1.1 INTRODUCTION
The Problem definition for the system is to develop software for “School Bus Routing
Management System” for Hope Hall Foundation School, based on feature - GIS (Geographic
Information System) Technique, in which School buses can be tracked on the way and software
also maintains database of Staff and students. Guardian can login to software using student’s id
and password.
1.2 WHAT WILL THE SOFTWARE DO?

School Bus Routing for School will ease the problem of scheduling and Routing School buses
that deals with the significant question of how to transport students to and from School.
Software keeps the real time record of each bus on the route.
User will be provided with the details of STUDENT(Student name, Father’s/Guardian’s name,
Residential address, Pick-up location and time, drop-off location and time, Student id, class, Bus
no.) ; DRIVER’S INFORMATION (Driver’s Name, Driver’s id, Residential address, Contact no.,
Bus no.), : CONDUCTOR INFORMATION(Conductor’s Name, Conductor’s ID, Residential
address, Contact number, Bus no.)TEACHER INFORMATION (Teacher’s Name, Class,
Teacher’s ID, Contact no., Bus no.). The Software allows Student to register to acquire facility
of School bus and Parents’ Login feature is also provided.
It should be designed to provide functionalities as follows:
• REGISTRATION:
Registration to the system will be provided by the software to the students. In this
step, Students have to register with their First name, Last name, Username,
Student ID, class, Parents’ name, contact no., Security question, Residential
address and password.
• LOGIN
Login Screen is the second Screen which will be shown to the user after creating
their profile. In this step, user (Admin/student’s parents) have to login with their
username and password to access the offline information or to track the bus. For
security reasons, students should have unique user id and password. In case of
student/Guardian forgetting their password, he/she can choose the “Forgot
Password” option. In this, user has to answer the security question in order to
change the password.
8
• TRACK
Software provides a feature called “TRACK” with the aid of GIS system. ‘Track’
will maintain the real time details like Traffic status, route followed by school
buses, distance covered, location and time.
Parents and school staff can access the location of student which helps the school officials to
maintain safety guidelines.
Transportation is one of the prime applications of GIS. GIS can be very helpful in making
school routes and in other school transportation services. “The greatest use of software
packages with an element, or component, of GIS technology is at an operational level e.g.
routing, scheduling, tracking, tracing or navigation.”[Forster 2000]
1.3 ADVANTAGES:
The existing fleet of buses and mini buses are currently managed manually. To improve the
existing fleet management system as well as decrease the maintenance costs, the software is
build supported by a GIS system.
a) Real time track of school bus.
b) Traffic status known beforehand.
c) Information of road construction and thus provides alternate route of
the destination.
d) Enables the pre-estimation of transportation time.
e) Economical and reliable.
In addition school transport management system may improve the transportation security as
guardian of student as well as school staff can track the school buses.
9
2: SOFTWARE PROCESS MODEL
WATERFALL MODEL:
School Bus Routing relies upon the WATERFALL MODEL and on the needs and requirements
of the user which were taken from initial module. The Waterfall Model will describe and
explain all the components which will assemble the Software.
The Model is applied because:
• Requirements are well-defined, clear and fixed.
• The phase’s proceeds in a systematic and sequential approach that begins at the
system level and proceed through analysis, design, coding, testing and support.
• Each phase has a review process.
• Each phase has well understood milestones.
• A working version of the software will not be available until late in the project
time-span which matches the needs of the client.
Once the Waterfall Model is designed and GIS data is gathered, the software is ready to
develop. Design focuses on a representation of those aspects of the software that will be visible
10
to end User. At the end of each phase, a review takes place to determine if the project is on the
right path and whether or not to continue or discard the project.
3: SOFTWARE REQUIREMENT SPECIFICATION
1. INTRODUCTION
This document aims at defining the overall Software Requirements for “SCHOOL BUS
ROUTING”. Efforts have been made to define the requirements accurately. The final product
will be having only features mentioned in this document and assumptions for any additional
feature should not be made by any of the parties involved in developing /testing /Implementing
using this product. In case it is required to have some additional features, a formal change
request will need to be raised and subsequently a new release of this document and/or product
will be produced.
1.1 PURPOSE
The purpose of the document is to collect and analyze all assorted ideas that have come up to
define the system, its requirements with respect to consumers. Also, we shall predict and sort
out how we hope this product will be used in order to gain a better understanding of the project,
outline concepts that may be developed later, and document ideas that are being considered, but
may be discarded as the product develops.
In short, the purpose of this SRS document is to provide a detailed overview of our software
product, its parameters and goals. This document describes the project's target audience and its
user interface, hardware and software requirements. It defines how our client, team and audience
see the product and its functionality. Nonetheless, it helps any designer and developer to assist
in software delivery lifecycle (SDLC) processes.
1.2 SCOPE
The Software Product- “SCHOOL BUS ROUTING” maintains student records and to make
them easily accessible.
1.2.1 OBJECTIVE:
11
The objective of this thesis is to create a GIS based School Transport Management System.
The GIS based school transport management system will include the following facilities.
• Bus stop allocation

• Fastest and Shortest route for the buses
• Automatic Vehicle Location
In addition this thesis aims to investigate how a school transport management system may
improve the security, efficient and reliable transportation for the students and to provide
optimal routes to save time or money for those involved.
1.2.2 GOAL:
Necessitating to provide accurate school transportation models to increase efficiency,

economic concern, time issues and route efficacy, road condition. The Software allows the
feature of Parents Login using Student’s Information-Student’s ID and Password.
1.3 DEFINITIONS AND ABBREVIATIONS
1.3.1 DEFINITIONS:
• GIS - Geographic Information System
Geographic Information System (GIS) is a computer system for capturing, storing, checking
and displaying data related to positions on Earth’s surface. It can show many different kinds of
data on one map. It also enables to easily see, analyze, and understand patterns and
relationships.
• GPS - Global Positioning System
GPS, which stands for Global Positioning System, is a radio navigation system that allows land,
sea, and airborne users to determine their exact location, velocity, and time 24 hours a day, in all
weather conditions, anywhere in the world.
• AVL - Automatic vehicle location
12
Automatic vehicle location is a means for automatically determining and transmitting the
geographic location of a vehicle. This data, from one or more vehicles, may then be collected by
a vehicle tracking system for a picture of vehicle travel.
• ROUTING-
Routing is the process of selecting best paths in a network. In the past, the term routing also
meant forwarding network traffic among networks. However, that latter function is better
described as forwarding.
• SCHEDULING-
Scheduling is the process of arranging, controlling and optimizing work and workloads in a
production process or manufacturing process. Scheduling is used to allocate plant and
machinery resources, plan human resources, plan production processes and purchase materials.
• TRACKING-
Tracking combines the use of automatic vehicle location in individual vehicles

with software that collects these fleet data for a comprehensive picture of vehicle locations.
• NAVIGATION-
The process or activity of accurately ascertaining one's position and planning and following a
route.
1.3.2 ABBREVIATIONS:
GIS – Geographic Information System
GPS – Global Positioning System
AVL - Automatic vehicle location
SMS- Short Message Service
1.4 REFERENCES
• IEEE Recommended Practice for Software Requirements Specification- IEEE Std 2003.
• Software Engineering - A Practitioner’s Approach by Roger S. Pressman (7th Edition).
• Software Engineering (Third Edition) by K.K. Aggarwal and Yogesh Singh.
13
1.5 OVERVIEW
This reading guide is included to give the brief overview of the thesis and to give an
understanding for how the work was structured.
• Introduction- The thesis is structured in the following manner. It presents an overview

of the study. It outlines the need of school bus routing and scheduling, the problem
context, and the objectives and presents a hypothesis on which the project is based.
• Study Area - The background of the present study area (Delhi city) is explained. School
bus routing and scheduling and importance of GIS in School bus routing and scheduling
is explained.
• GIS & GPS/AVL in School Routing - Role of GIS is School transportation. Importance
of Global Positioning System (GPS) and Automatic Vehicle Location (AVL) for vehicle
location system is described.
• System Design and Implementation – It presents the methodology of sequential life

cycle process model, which is followed to develop the application for School bus
routing and scheduling model. It also discusses the system requirements and the
overview of the steps and methods followed in collecting and processing data.
• Interface Design - Description of the interface design and development process of

School Routing and Scheduling is discussed in this part of the study. Various functions
and the operating procedures that facilitate the user in the application are explained.
• Results, Discussion & Conclusion – This thesis concludes with the results, discussion
on the research work, limitations associated with this software and also the possible
maintenance of the application in future.
14
2. THE OVERALL DESCRIPTION
“SCHOOL BUS ROUTING” system is an application of GIS. The Software resolves the issue of
concerning the child’s safety. Core application of software is to enable the parents’ login view to
keep track of School Bus. It also helps in Routing, Scheduling, Tracing and navigation.
2.1 PRODUCT PERSPECTIVE
The bus tracking system is made up of the following seven components:
• A server that hosts bus route information, current bus locations, and historical bus
location data.
• A GPS-enabled system located on each bus that will send bus location information to
the bus information server.
• A reporting system that allows transit management to investigate bus delays, and bus
usage patterns.
• A console onboard each bus that receives data from the bus information server and
displays notices to drivers.
• A web based trip planning system.
• And a set of kiosks at bus stops that allow potential passengers access the trip planning
system.
2.1.1 SYSTEM INTERFACE
This project presents an application based on GIS. The data obtained from GIS receiver is
processed by the microcontroller to extract its latitude and longitude values. The System has
15
Google Maps as a subsystem. Google Maps subsystem has their own web-based interface which
is a map consisting of roads and locations in a desired area.
2.1.2 USER INTERFACE
The Application will have an interactive and instant access interface.
Following Screens will be provided:
I. Home Screen- Displays Introduction of Software. CONTINUE button to

proceed further.
• Login Screen: User can access their respective account by

entering their User name and Password.
II. Registration Screen : User can create their account by providing details such
as First name, Last name, Username, Student ID, class, Parents’ name,
contact no., Security question, Residential address and password
III. Option Screen – for user and admin
• Update account
• Track
IV. My account Screen – for user
• Change address
• Change contact no.
V. Update Database Screen- for Admin.
Menu Driven screen will be displayed with the following options:
16
• Student Details
• Driver Information
• Conductor Information
• Teacher Information
• Add/Delete Bus
• Add/Delete Route
 If Admin opts for STUDENT DETAILS, following Screens will be displayed.
VI. Class and Section Screen-
• Class
• Section
VII. Delete Student account: admin can delete student account.
• student id
VIII. Bus-wise Detail Screen-
• Driver’s Information
• Conductor’s Information
• Teacher Incharge
• Student Name
• Class
• Parent’s Contact
17
• Address
• Bus Stop(Pick-up and drop-off Location)
IX. Track Screen- will Display the current Location of the Bus using Google
Maps Subsystem.
 Screens have been designed to provide Instant Access to system users.
2.1.3 HARDWARE INTERFACES
 The screen resolution of at least 1024 X 768 required for proper and complete
viewing of screens. Higher resolution would not be a problem.
 Each bus will contain the following hardware interfaces:
• a GPS unit
• a Touch screen
 Each kiosk will contain the following hardware interfaces:
• a Touch screen
• a Networked computer
 PROCESSOR – P-1V(2.80 GHZ)
 RAM – 512GB
 STORAGE CAPACITY – 80GB
18
 DRIVERS – 52 X 24 X 52 XCD
2.1.4 SOFTWARE INTERFACES
I. OPERATING SYSTEM - Windows XP
II. MS ACCESS as the DBMS database.
III. VISUAL BASIC 6.0 ( for coding/ developing the software)
2.1.5 COMMUNICATION INTERFACES
• All communication between busses, head office, and kiosks will be performed over the
internet.
• The system shall send an automatic verification code via SMS to the student who wants
to register to the system.
2.1.6 MEMORY CONSTRAINTS
At least 64MB RAM and 2 GB space on hard disk will be required for running the
Software product.
2.1.7 OPERATION
• REGISTRATION-
Students opting for bus services must create an account first through the registration
process.
• LOGIN-
Students who have already registered can access their account by logging in, using the
student ID and Password.
19
• BACKUP AND RECOVERY OPTION-
 Case 1:
If a student forgets his/her Student ID and/or Password, user is required to

answer a security question.
 Case 2:
While using the software if the internet connection is lost and the user wants
to continue to access the product then he/she will be required to enter the
student id and password again.
• TRACKING OPTION –
School bus location can be tracked over the internet access.
2.1.8 SITE ADAPTION REQUIREMENT
The terminals will have to support the hardware and software interfaces specifies in the above
sections.
2.2 PRODUCT FUNCTIONS
The functions performed by the software are:
• Student can register/login to avail bus services.
• The user (parents / student) can access the information of a particular student, given
his/her student Id and password.
• Administrator can add new updated to the database of student.
20
• It stores the details of Teacher, Driver, Conductor and Student information so that in
emergency there is a flow of communication between school staff and parents.
• Guardian/ School staff can easily track the school bus location.
• Use of GIS expands the horizons of realizing the road and traffic status before-hand.
• It selects the optimal route for travelling.
• Software is reliable and gives accurate location of school bus at real time.
2.3 USER CHARACTERSTICS
To use the software, user should have:
• EDUCATIONAL LEVEL-
User should be at least graduate so that he/she can be comfortable with
English.
• EXPERIENCE-
User should be well informed about the rules and policies of the school
bus.
• TECHNICL EXPERTISE-
User should be comfortable using the general purpose application on a
computer.
2.4 CONSTRAINTS
• Early updating of the changes and additional in the database.
• Login for user associated with student Id and password only.
• Student ID will be provided to parents only.
21
• Changes in the software can be made only by administrator.
• Only administrator can allocate the buses.
• Student can’t delete their account from the software in case they don’t want to
avail bus facility. Administrator can only facilitates.
2.5 ASSUMPTIONS AND DEPENDENCIES
• User will try to access the records of that student only whose information is
present in the database.
• Parents/Guardian will login using student’s id and password.
• Drivers and Conductors will not be accessing the software. Also, they are not
provided the Student ID and password.
• User will not be interacting with the software (feedback/comments).
3. SPECIFIC REQUIREMENT
This following section consists of the Software Requirements and its details inclusive of the
System’s Design, detailed enough for testers to test the same.
3.1 EXTERNAL INTERFACES

The hardware and operating system requires a screen resolution of at least 1024 X 768 pixels.
3.2 FUNCTIONS
• System shall support generalized enquiry for run time parameters indicatively such as
Real time / history of the routes that bus travelled that are more than an “X” minutes
late (x input runtime by the user). Real time / history of all stops and distance between
two points with a feature to playback.
• Based on real time enquiry of a bus location based on bus number and to know next or
required place.
22
• System shall support real time enquiry based on Bus Stops/Pickup point, Bus Stand, trip
id, bus no etc., to find out whether the bus passed a pickup point/stop/bus stand/place, to
find out the nearby landmark to a given place/location/pickup point bound to specified
destination (which have not passed), to find out the nearby vehicle/s to a given vehicle
which have not passed/just passed/on the same route or on different route. The output
shall be possible both on map and text based display.
• Response to the query shall be appropriate to the channel from which the enquiry was
received such as SMS/ Web. SMS response will be perhaps a limited text message
while that from the web shall have relevant text output / Table and vehicle locations of
the bus on a web page with an overlay on the map.
3.3 PERFORMANCE REQUIREMENTS
The Portal should be able to operate on all major web-browsers with all of its fundamental
functions. It should not slow down the system even at hours without affecting the quality of
service of the system.
3.4 LOGICAL DATABASE REQUIREMENTS
• All information technologies must properly display, calculate, and transmit data.
• The system should interface to a standard SMS and email gateways using standard
protocols with encryption when registration is received.
• The system shall support 300 concurrent user queries/transactions with 20 vehicle
without affecting performance. The system shall be scalable with additional hardware
included as required at a later point.
23
3.5 DESIGN CONSTRAINTS
The school had 40 to 50 bus stops to include in their routes, which were being designed by
hand. These routes were not performing well in terms of cost or efficiency; the previous year’s
bus routes often had varying levels of bus capacity usage and travel times. Designing a bus route
that optimizes both student travel time and bus capacity is a difficult task, particularly when
there are many feasible routes that could include 40–50 bus stops. School Bus Management
took on the task of helping optimize bus routes and transportation planning.
3.6 SOFTWARE SYSTEM ATTRIBUTES
The quality attributes of software that serve as requirements are mentioned below:
3.6.1 RELIABILITY
• Software must respond to 99% of user requests within 2 seconds of the request.
• Software must produce correct and consistent results.
• If an error occurs, an ‘error message’ shall be displayed on the screen.
• Software must provide location information for each bus in less than 1 minute 99.9
percent of the time.
3.6.2 AVAILABILITY
• The system shall be available at all time but it requires internet connection to avail the
services of this software product.
3.6.3 SECURITY
The Security Section describes the need to control access to the data. This includes controlling
who may view and alter application data.
24
• Only registered students can access this application.
• A student must verify himself /herself by entering the pin code sent by SMS service
during the registration process.
• A student who uses this application shall have a Login id (Student id) and password.
• Any modification (insert, delete, and update) for the Database shall be synchronized and
done only by the administrator.
• A user will be able to view all the information but will not be allowed to modify the
database directly.
• Administrator shall be able to view and modify all the information.
3.6.4 MAINTAINABILITY
• The system shall provide the capability to back-up the Data.
• The system shall keep a log of all the errors.
3.6.5 PORTABILITY
• The software has the ability to be easily modified for a new environment. This software
can be installed in any school, if modified properly.
3.6.6 FLEXIBILITY
• The software can be modified if needed.
25
3.6.7 REUSABILITY
• The Software can be used in multiple applications.
3.6.8 USABILITY
• In order to access the application, user must be a computer literate i.e. he/she must have
the basic knowledge of computers.
• The interface is easy to learn and navigate; buttons, headings, and help/error messages
are simple to understand.
• The interface appears easy to use, rather than intimidating, demanding and frustrating.
3.7 ORGANISING THE SPECIFIC-REQUIREMENTS
The System Requirement Specifications documents will form the part of documentation
for the project.
Some desired features of the new system include:
3.7.1 SYSTEM MODE
• Provides real-time updates on school bus locations. School Bus tracker

sends alerts in the form of SMS, android push notifications or IOS
notifications and parents get to know about bus delays, unscheduled bus-
stops or the other emergencies.
• School Bus tracking systems help you to analyze the school driver’s
Performance and to save money in terms of fuel and the like by providing
you with reports on travel distance, travel speed, travel history etc.
• In case you detect any abnormality, you can get in touch with the school
bus driver.
• Helps you save energy and time by automatic routing and planning and
scheduling bus stops.
3.7.2 USER CLASS

Following criteria for operating the software are -
• USER
26
The parents are not expected to have a high educational and proficiency
level or technical expertise. Hence, the user interface is available in
Hindi, Gujarati, Marathi, Bengali, Telugu and English.
• ADMIN
The Admin is expected to have a field appropriate college degree and

experience of at least 2 years as admin and an additional 5 years in the IT
field. He / She have the privilege to update information in the database and
technical expertise in database and technical expertise in database
management.
3.7.3 FEATURES
System security and access levels are provided in the online system. There are varying levels
of system access and functional authority. Each student’s access is limited to his/her own
registration records. Only authorized system administrator’s has access to all student registration
records.
3.7.4 STIMULUS
Improved student safety and enhance operational efficiency with GPS Tracking. Our
customizable solution can help school districts simplify and optimize route management, reduce
maintenance expenditures and monitor student drop-off and pick-up times.
3.7.5 RESPONSE
Resolves locking issues and handle concurrent use of the system on a 24x7 basis.
Send, Receive and display user messages to assist the over-all user experience.
27
4.DATA FLOW DIAGRAM
4.1 CONTEXT LEVEL DIAGRAM
28
4.2 LEVEL-1 DFD
29
4.3 LEVEL-2 DFD
30
4.4 DATA DICTIONARY
Table 1 - Bus Information
Field Name Type Description

Bus_ID Integer Primary Key
Bus_No Character[20]
Route_No Integer Foreign Key
Driver_ID Integer Foreign key
Conductor_ID Integer Foreign Key
Teacher_ID Integer Foreign Key
31
Student_ID Integer Foreign Key
Table 2: Route Information

Route_no Integer Primary Key
Pick_up Character[20]
Drop_off Character[20]
Location Character[20]
Time Float
Bus_ID Integer Foreign Key
32
Table 3: User Information
Student_Name Character[20]
Parent_name Character[20]
Class_Section Character[10]
Student_ID Integer Primary Key
D_O_B Character[20]
Address Character[50]
Contact_No Long Integer
Table 4: Teacher Information
Teacher_Name Character[20]
Class_Section Character[10]
Teacher_ID Integer Primary Key
33
Table 5: Driver Information
Driver_Name Character[20]
Driver_ID Integer Primary Key
Table 6: Conductor Information
Conductor_Name Character[20]
Conductor_ID Integer Primary Key
34
Table 7: Main
Bus_ID Integer
Route_no Integer
Location Character[20]
Time Time Stamp
Loc_lat Degree Float
Min Float
Sec Float
Loc_log Degree Float
Min Float
Sec Float
Next_stop Integer
Last stop Integer
Pick_up Character[20]
Drop_off Character[20]
35
4.5 ENTITY RELATIONSHIP DIAGRAM
36
5. USER CASE DIAGRAM
37
5.1 USE CASE DESCRIPTION
1. REGISTRATION
• Brief Description-
This use case allows the actor to register for the School bus Services.
• Actors
The only actor who can perform this use case is student.
• Flow of Events
 Basic Flow-
1) Use case begins when a student visits the software and wishes to avail
the School Bus Services.
2) The system requests the student to enter the required information such as
student name, class and section, parents’ name, residential address and
contact number.
3) Once the Student enters the required details, he/she can now access the
system.
 Alternative Flow-
Student enters the incorrect/invalid details. The system displays the error
message. If the student wants to apply again for the registration then he/she
have to perform the use case again. Otherwise, the use case ends.
• Special Requirement
There is no special requirement.
• Pre- condition
Student must have opened the software prior to registration.
• Post-condition
1) Successful Registration
User now has an account and can fully utilize the software.
2) Registration Failed
User has not provided the valid details and is required to perform the previous steps
again.
• Extension Points
There is no extension points associated with this use case.
38
2. LOGIN
• Brief Description
This use case describes how the registered students and admin log into the system.
• Actors
Following actors can participate in this use case:
1) Student.
2) Admin.
• Flow of Events
 Basic Flow-
This use case starts when the student or admin wishes to log into the system.
 If the actor is ‘student’-
1) Student is asked to enter his/her Student ID and Password.
2) Student enters the required details.
3) System validates the details and logs the student into the system.
 If the actor is ‘Admin’-

1) Admin is asked to enter user name and password.
2) Once the admin enters the required details, system validates the
user name and password, and logs the admin into the system.
If in the basic flow the actor enters an invalid student Id/user name and/or
password, the system displays an error message. The actor can choose to
either return to the beginning of the Basic Flow or cancel the login, at
which point the use case ends.
Student Id and Password must be valid.
• Pre-condition
 If the actor is “Student” and already has an account, then he/she can directly
perform this use case. Otherwise, he must create an account first.
 There is no pre-condition for the actor “Admin”.
• Post-condition
 If the use case was successful, the actor is now logged into the system. If not the
system state is unchanged.
39
 If the actor is “Student”, he/she will have access to only screens corresponding to
Track Bus, Request Bus Information and Update Student information.
 If the actor is “Admin”, he/she will have access to complete software.
• Extension Point
There is no extension points associated with this use case.
3. REQUEST
This use case describes how an actor requests for the information he/she desires to see.
• Actors
Following actors can perform this use case:
1) Student.
2) Admin.
• Flow of Events
 Basic Flow
This use case starts when the actor wishes to view information regarding the
Bus Schedule or bus staff.
1) The system requests the actor to enter the Bus Id of that bus whose
information he/she wants to see.
2) Once the required Bus Id is entered, the system validates the Bus Id
and displays the desired information.
 Alternative Flow
If the Bus ID entered by actor is not a valid , then an error message will
be displayed. The actor can choose to either return to the beginning of
the Basic Flow or cancel the login, at which point the use case ends.
Bus Id must be valid.
• Pre-condition
1) If the actor is “Student”, then he/she must be a registered user.
2) No pre-condition is there for Admin.
40
• Post-condition
 Successful Operation-
If the Bus Id was valid, actor has complete information about the bus schedule or
bus staff.
 Failed Operation-
Error Message will be displayed.
• Extension Point
No extension point is there in this use case.
4. Track A Bus
This use case describes how an actor tracks a bus on a particular route.
• Actors
Following actors can participate in this use case:
1) Student.
2) Admin.
• Flow of events
 Basic Flow-
This use case begins when an actor wants to seek information regarding the
current location of the bus.
1) The system requests the actor to enter the Bus Id of the bus
he/she desired to track.
2) Once the required Bus Id is entered, the system validates the Bus Id and
displays the desired information i.e.
a) If the actor is “Student”, he/she will be provided with the real time
information-
i. Time to reach bus stop.
ii. Location.
iii. Route.
b) If the actor is “Admin”, he/she will be provided with the real time
information-
i. Time to reach nearest stop.
ii. Location.
iii. Route.
41
If the Bus ID entered by actor is not a valid, then an error message will be
displayed. Actor can choose either to restart the use case or exit.
Bus Id must be valid.
• Pre-condition
1) If the actor is “Student”, then he/she must be a registered user.
2) No pre-condition is there for Admin.
• Post-condition
If the Bus Id was valid, actor now have the complete information regarding the current
location of the Bus. Otherwise error message will be displayed.
• Extension Point
No extension point is there in this use case.
5. Update Student Information
This use case allows the actor to update his/her account details such as residential
address and contact no.
• Actors
Only Student can perform in this use case.
• Flow of Events
 Basic Flow-
This use case begins when the students wishes to update/change his/her
personal information.
1) System requests the student to select the particular information he/she

wants to change.
2) Once the student provides the new updated personal information (Address
and Contact no.), admin allots a Bus according to the information provided
by the student.
No Alternative Flow.
• Special Requirements
42
No Special requirement needed.
• Pre-conditions
If the actor is “Student”, then he/she must be a registered user and logged in to his/her
account.
• Post-conditions
If required a new Bus will be assigned to the student according to the new residential
address provided by the student.
• Extension Point
There is no extension point in this use case.
6. Delete Student Account
This use case allows actor to delete a student account.
• Actors
Only Admin can perform this use case.
• Flow of Events
 Basic Flow-
This use case starts when the admin has to delete a student account, reason
being that student might be leaving the school.
1) System asks the admin to enter the student Id of the student whose
account he has to delete.
2) Once the student Id is entered, system validates the student Id and deletes
the Student account associated with that Student Id.
If the Student Id provided by the admin is invalid then a error message will
be display and admin will has to perform the use case again.
Student Id must be Valid.
• Pre-conditions
Student Id provided by the admin must be valid i.e there must exist an account
associated with that student Id.
43
• Post-condition
1) Student’s account has been deleted.
2) The admin is notified that the requested account has been deleted.
No Extension Point is there.
7. Add/Delete Bus
This use case allows the actor to add/delete a School Bus.
• Actors
• Flow of Events
 Basic Flow-
This use case begins when the admin has to add or delete a School Bus.
 System will ask the admin to enter Bus Id associated with a particular Bus
no.
Add- Once the admin has provided a new Bus Id, system validates the Bus Id
and adds a new School Bus in the system.
Delete- Once the admin has provided a Bus Id, system validates the Bus Id
and deletes the existing School Bus from the system.
If the Bus id entered by the admin is invalid, an error message will appear on
the screen. Admin can either perform the use case or simply exit the use case.
• Special Requirement.
Bus Id must be Valid.
• Pre-conditions
Bus Id provided by the admin must be valid i.e
 If the admin wishes to add a new Bus , then there must not exist another bus with
the same Bus Id.
44
 If the admin wishes to delete a Bus, then there must exist the Bus Id associated
with that school bus in the system.
• Post-conditions
 Add- A new school bus will be added in the system.
 Delete- Required school bus will be deleted from the system.
There is no Extension Point in this use case.
8. Add/Delete Route
This use case allows the admin to add/delete a route associated with some School Bus.
• Actors
• Flow of Events
 Basic Flow-
This use case begins when the admin has to add or delete a route.
 System will ask the admin to enter a route no.
Add- Once the admin has provided a new route no., system validates the
route no. and adds a new route in the system.
Delete- Once the admin has provided a route no. associated with some route,
system validates the route no. and deletes the existing route from the system.
If the Route no. inserted by the admin is not valid, an error pop up will be
displayed on the monitor. Admin can simply begin the use case again or can
exit.
Route No. must be Valid.
• Pre-conditions
Route no. provided by the admin must be valid i.e
45
 If the admin wishes to add a new route Id., then there must not exist another
route with the same route no. in the system.
 If the admin wishes to delete a route, then there must exist the route no.
associated with that route in the system.
• Post-conditions
 Add- A new Route will be assigned to a school bus.
 Delete- Required Route will be deleted from the system.
9. Add/Delete Teacher In charge
This use case allows the admin to add or delete a Teacher In charge.
• Actors
• Flow of Events
 Basic Flow-
This use case begins when the admin has to add or delete a Teacher In
charge.
 System will ask the admin to enter the Teacher Id of the teacher he wants
to delete or add.
Add- Once the admin has provided a new Teacher Id, system validates the
Teacher Id and assigns a new Teacher In charge of the bus.
Delete- Once the admin has provided a Teacher Id, system validates the
Teacher Id and deletes the Teacher In charge of the Bus.
If the Teacher Id entered by the admin is illegal/invalid, then an error
message will appear on the screen. Admin can choose either to terminate the
use case or restart the use case.
46
Teacher Id must be Valid.
• Pre-conditions
Teacher Id provided by the admin must be valid i.e
 If the admin wishes to add a new Teacher In charge, then there must not exist
another Teacher In Charge with the same Teacher Id.
 If the admin wishes to delete a Teacher In charge, then there must exist the
Teacher Id associated with that Teacher In charge.
• Post-conditions
 Add- A new Teacher In charge will be assigned to the school.

 Delete- Required Teacher In charge will be deleted from the system.
10. Add/Delete Driver
This use case allows the admin to add or delete a Driver.
• Actors
• Flow of Events
 Basic Flow-
This use case begins when the admin has to add or delete a Driver.
 System will ask the admin to enter the Driver Id of the Driver he wants to
delete or add.
Add- Once the admin has provided a new Driver Id, system validates the
Driver Id and assigns a new Driver to the bus.
Delete- Once the admin has provided a Driver Id, system validates the Driver
Id and deletes the Driver of the Bus.
47
Error message will be displayed on the monitor if the Driver Id provided by
the admin is not valid/ correct. Admin has option to perform the use case
from the beginning or terminate the use case.
Driver Id must be Valid.
• Pre-conditions
Driver Id provided by the admin must be valid i.e
 If the admin wishes to add a new Driver, then there must not exist another Driver
with the same Driver Id.
 If the admin wishes to delete a Driver, then there must exist the Driver Id
associated with that Driver.
• Post-conditions
 Add- A new Driver will be assigned to the school bus.

 Delete- Required Driver will be deleted from the system.
11.Add/Delete Conductor
This use case allows the admin to add or delete a Conductor.
• Actors
• Flow of Events
 Basic Flow-
This use case begins when the admin has to add or delete a Conductor.
 System will ask the admin to enter the Conductor Id of the Conductor he
wants to delete or add.
Add- Once the admin has provided a new Conductor Id, system validates the
conductor Id and assigns a new Conductor to the bus.
Delete- Once the admin has provided a Conductor Id, system validates the
Conductor Id and deletes the conductor of the Bus.
48
If the Conductor Id entered by the admin is invalid, an error message will be
displayed .The use case ends or admin can perform the use case again.
Conductor Id must be Valid.
• Pre-conditions
Conductor Id provided by the admin must be valid i.e
 If the admin wishes to add a new Conductor, then there must not exist another
conductor with the same Conductor Id.
 If the admin wishes to delete a Conductor, then there must exist a conductor Id
associated with that conductor.
• Post-conditions
 Add- A new conductor will be assigned to the school bus.

 Delete- Required conductor will be deleted from the system.
6. WHITE BOX TESTING

We are Performing White Box Testing for Student Account Update.
Void Update_Student_Account()
{
Char User_id [20];
Read User_id;
Char password [8];
Read password;
IF (User_id is valid)
Then AllowAccess;
49
Else
Break;
END IF
DO WHILE (Perform update)

IF (user wants to change address)
Then fstream filehandler;
filehandler.open (“Student_information||address.add);
Char add [50];
Read updated address;
getline (filehandler, add);
filehandler.close ();
ELSE IF (user wants to change contact number)

Then fstream filehandler;
filehandler.open (“Student_information||contact details_contact)
int contact;
Read updated contact;
getline (filehandler, contact);
filehandler.close ();
END IF
END DO
END
50
6.1 FLOW GRAPH
3 4
6
51
7
9
8
10
11
12
13
6.2 FLOW CHART
3 4
52
5
8 7 11 69 10
12
13
53
6.3 CYCLOMATIC COMPLEXITY
1.
G=E–N+2
Here, Number of Edges = 16
Here, Number of Nodes = 13
Therefore,
So,
V (G) = (16-13) +2 = 5
2.
G=P+1
=> 4 + 1 = 5, Where P is the Predicate nodes [2, 6, 7, and 9]
3.
Number of Regions
=5
Hence By all means, Cyclomatic Complexity is 5
54
7. SCREENS
 LOGIN SCREEN
User and Admin will access the common screen to login to the software. Registered users can
enter their username and password. If they enter incorrect details then authentication message
will be generated. Further they can recover their password or username by selecting Forgot
Password.
NUMBER OF INPUT - 2
NUMBER OF OUTPUT - 1
NUMBER OF FILES - 1
NUMBER OF ENQUIRIES - 0
NUMBER OF EXTERNAL INTERFACE - 0

55
 REGISTRATION SCREEN
Non- registered students can create their account by filling up details offered by Registration
Screen. Screen will return confirmation message or error message.
NUMBER OF INPUT - 18
NUMBER OF FILES - 1
56
 USER OPTION SCREEN
Only user can access this screen. Software permits user to select one of option provided. My
Account option enables user to edit the basic information (contact no. and address) and saves
changes. Filling up Bus id and selecting bus details user can access information of the respective
bus and can Track the bus. Software provides real time route information, time and distance to
be covered to the user.
NUMBER OF INPUT - 1
NUMBER OF FILES - 0
57
 MY ACCOUNT SCREEN
Only user can access this screen, if he/she wish to update the basic information or view his/her
account. Software permits user to edit contact number and address only. Changes can be saved
and user is provided with confirmation message.
NUMBER OF INPUT - 6
NUMBER OF FILES - 1
58
 ADMIN OPTION SCREEN
Only admin can access this screen. Software permits admin to select one of option provided.
Delete Student’s Account option enables admin to delete the student account permanently and
saves changes. Filling up Bus id and selecting bus details admin can access information of the
respective bus and can Track the bus. Software provides real time route information, time and
distance to be covered to the user. Admin can also handle the staff related to bus like adding or
deleting the allocation of staff also adding new route or adding new bus.
NUMBER OF INPUT - 1
59
NUMBER OF FILES - 0
 DELETE STUDENT ACCOUNT SCREEN
Admin can perform this function, in case student leaves the leave service or changes school,
student is generally not bothered to delete his/her account so, admin can delete student account
permanently by providing student id and save changes.
NUMBER OF INPUT - 1
60
NUMBER OF FILES - 1
 UPDATE STAFF ACCOUNTS OPTION SCREEN
Admin can handle the staff accounts. Allocating a new teacher, driver or conductor to a bus or
deleting them. Adding new optimum route to be followed by bus also updating number of buses
running in service.
NUMBER OF INPUT - 1
NUMBER OF OUTPUT -0
61
NUMBER OF FILES - 0
 UPDATE TEACHER INFORMATION
Feature of Updating the Information of staff is enabled only for Admin. Admin can add or
delete the teacher in-charge allocated to a particular bus by providing suitable details asked in
screen. Confirmation message will be send once Admin save the changes.
62
NUMBER OF INPUT - 6
NUMBER OF FILES - 1
NUMBER OF ENQUIRIES -0
63
 UPDATE DRIVER INFORMATION
delete the driver allocated to a particular bus by providing suitable details asked in screen.
Confirmation message will be send once Admin save the changes.
NUMBER OF INPUT - 4
NUMBER OF FILES - 1
NUMBER OF EXTERNAL INTERFACE -0
64
 UPDATE CONDUCTOR INFORMATION
delete the conductor allocated to a particular bus by providing suitable details asked in screen.
Confirmation message will be send once Admin save the changes.
NUMBER OF INPUT - 4
NUMBER OF OUTPUT -1
NUMBER OF FILES - 1

 UPDATE ROUTE
Feature of Updating the Information of routes followed is enabled only for Admin. Admin can
add or delete the routes allocated to a particular bus by providing suitable details asked in
screen. Confirmation message will be send once Admin save the changes.
NUMBER OF INPUT - 2
NUMBER OF FILES - 1
66
 UPDATE NUMBER OF BUSES
Feature of Updating the Information of number of buses available for use is enabled only for
Admin. Admin can add or delete the bus allocated to a particular bus by providing suitable
details asked in screen. Confirmation message will be send once Admin save the changes.
NUMBER OF INPUT - 2
NUMBER OF FILES - 1
67
 BUS INFORMATION SCREEN
User and Admin will access this common screen to view the bus-wise details in the software.
User and Admin reach this screen through entering Bus Id and selecting Bus Details. This
screen provides the main feature of software is Track. User and Admin can proceed towards
tracking the Bus through this Screen.
NUMBER OF INPUT - 0
NUMBER OF OUTPUT -0
NUMBER OF FILES - 1
68
 TRACK SCREEN
Screen will display the graphic interface of the location of bus following a particular route. User
and Admin can view the Distance and Time covered during travel. Road construction and heavy
traffic will also be displayed.
69
NUMBER OF INPUT - 1
NUMBER OF FILES - 1
70
8. PROJECT METRICS
A software metric is a standard of measure of a degree to which a software system or process
possesses some property. Product metrics provide with a systematic way to assess quality based
on a set of clearly defined rules. They provide on-the-spot, rather than after-the-fact, insight.
This enables to discover and correct potential problems before they become catastrophic
defects.
FUNCTION ORIENTED METRICS

The function point (FP) metric can be used effectively as a mean for measuring the
functionality delivered by a system. Function points are derived using an empirical relationship
based on countable (direct) measures of software’s information domain and qualitative
assessments of software complexity.
To compute function points (FP), the following relationship is used:
FP = count total x [0.65 + 0.01 x ∑ (Fi)]
Evaluating function points (FP) value of a project with following information domain
characteristics:
 Number of User Inputs : 20
 Number of Output : 14
 Number of User Inquiry : 1
 Number of Logical Files : 9
 Number of External Interface : 1

Assuming the measurement parameters are equally divided among simple, average and
complex.
WEIGHTING FACTOR
Informatio Count Simple Average Complex

n
Domain
Value
External × 3 4 6 =
I/P 6.7 87
71
External × 4 5 7 =
4.7 75
O/P
External × 3 4 6 =
Inquiries 0.3 4
Internal 7 10 15
Logical 3
× = 96
Files
External 5 7 10
Interfaces 0.3 7
Files × =
COUNT TOTAL 269
The Fi (i=1 to 14) are value adjustment factors (VAF) based on responses to the following
questions:
QUESTIONS VAF
1. Does the system require reliable backup and recovery? 3
2. Are specialized data communications required to transfer information to or 3

from the application?
3. Are there distributed processing functions? 3
4. Is performance critical? 3
5. Will the system run in an existing, heavily utilized operational environment? 3
6. Does the system require online data entry? 3
7. Does the online data entry require the input transaction to be built over multiple 3
screens or operations?
8. Are the ILFs updated online? 3
9. Are the inputs, outputs, files, or inquiries complex? 3
10. Is the internal processing complex? 3
72
11. Is the code designed to be reusable? 3
12. Are conversion and installation included in the design? 3
13. Is the system designed for multiple installations in different organizations? 3
14. Is the application designed to facilitate change and ease of use by the user? 3
We evaluate, ∑ (Fi) = 42 (a moderately average product).

Therefore,
FP = 269 x [0.65 + (0.01 x 42)] = 287.83
Since, function point has been calculated it can be used to normalize measures for software
quality, productivity and other attributes such as:
 They can be used to size software applications accurately.
 Errors per FP
 Defects per FP
 Function Points can be used to determine whether a tool, a language, an environment, is

more productive when compared with others.
73
9. EFFORT ESTIMATION USING COCOMO MODEL
The COCOMO Model allows us estimate the cost, effort and scheduling when planning new
software development.
It consists of three sub models, each one offering increased integrity, further a long one is in the
project planning and design process. Listed increasing fidelity, these sub models are called the:
• Application Composition Model
• Early Design Model
• Post-Architecture Model
Since Our Software is based on Application Composition Model, We use COCOMO II

Software Model which includes the same (for early prototyping efforts) and the more detailed
Early Design and Post-Architecture models (for subsequent portions of the life cycle).
The COCOMO II Software model which is applicable uses object points
COMPLEXITY WEIGHT
OBJECT TYPE
SIMPLE MEDIUM COMPLEX
2 7 4
SCREENS
REPORTS 1
3GL COMPONENTS
Object point is used to calculate indirect count measure that is obtained with number of
Screens, Reports, and 3GL components.
74
Each Object instance is classified into three categories- Simple, Medium and Complex.
And the object count is obtained by the product of total number of object instances
obtained by weighing factor.
None of the components are being re-used in our Project and hence the %re-use here is zero.
As a Next step, we calculate New Object Point (NOP) by the following formula:
NOP = (Object Points)*[(100%-reuse)/100]
DEVELOPER’S EXPERIENCE/CAPABILITY Very low Low Nominal High Very High
ENVIRONMENT MATURITY/CAPABILITY Nominal High Very High

Very low Low
4 7 13 25 50
PRATE
"Productivity Rate" is computed using the following formula to derive an estimate of effort
PRATE = NOP / person-month
And Estimated Effort = NOP / PRATE
COCOMO ESTIMATION FOR OUR PROJECT
Number of Screens = 13
Number of reports = 1
Object Points for Simple:
= [(13*2) + (1*0)] = 26
75
NOP = (Object Points)*[(100%-reuse)/100]
= 26 * [(100-0)/100]
= 26 * 1
= 26
Person Per month assumed = 3
Therefore, PRATE = 26/3
= 8.67
Estimated Effort = 26/8.6
= 2.99
76
10. PROJECT SCHEDULING
The project scheduling is the tool that communicates what work needs to be performed,
resources required and timeframes in which that work needs to be performed. The project
schedule is reflecting all the work associated with delivering the project on time.
10.1 TIME-LINE CHART
Work Task January February March April
W W W W W W W W W W W W W W W W
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1. Problem
Statement
2. Software Process
Model
3. Structure of Team
4. Project
Scheduling
5. Software
Requirements
Specification
6. Data Flow
Diagram
6.1 Context Level
6.2 Level-1 DFD
6.3 Level 2 DFD
77
7. Data Dictionary
8. Entity
Relationship
Diagram
9. Use Case
Diagram
10. Use Case

Description
11. Software Testing
12. Software Metrics
13. Estimation Model

(COCOMO II
Model)
14. Risk Analysis
78
10.2 TASK TABLE
Work Tasks Planned Actual Planned Actual Assigned Effort

Start Start Complete Allocated
Complete Person(s)
1. Problem wk1,d1 wk1,d1 wk1,d7 wk1,d6 Ayushi, 3 p-d

Statement
Divya,
Shikha
2. Software Process wk2,d1 wk1,d7 wk2,d3 wk2,d3 Ayushi, 2 p-d

Model
Divya,
Shikha
3. Structure-of wk2,d4 wk2,d4 wk2,d7 wk2,d7 Ayushi, 2 p-d

Team
Divya,
Shikha
wk3,d1 wk3,d1 wk3,d3 wk3,d3 Ayushi, 2 p-d

4. Project
Scheduling
Divya,
Shikha
5. Software
Requirements wk3,d4 wk3,d4 wk4,d7 wk4,d6 Ayushi,
Specification
3 p-d
79
Divya,
Shikha
6. Data-Flow wk1,d1 wk1,d1 wk1,d4 wk1,d4 Ayushi, 3 p-d

Diagram
6.1 Context Level wk1,d5 wk1,d5 wk2,d7 wk2,d7 Divya,
6.2 Level-1 DFD wk3,d1 wk3,d1 wk3,d7 wk3,d6 Shikha
6.3 Level 2 DFD

Ayushi,
wk4,d1 wk3,d7 wk4,d7 wk4,d4 Divya, 2 p-d

7. Data Dictionary
Shikha
Ayushi,

8. Entity
Relationship Shikha
Diagram
wk1,d5 wk1,d2 wk1,d7 wk1,d3 Ayushi,

9. Use-Case Divya, 1 p-d
Diagram
Shikha
Ayushi,
10. Use-Case Shikha

Description
80
Work Tasks Planned Actual Planned Actual Assigned Effort
Start Start Complete Allocated
Complete Person(s)
11. Software wk2,d6 wk2,d3 wk3,d7 wk3,d5 Ayushi, 3 p-d

Testing
Divya,
Shikha
12. Software wk4,d1 wk3,d6 wk4,d7 wk4,d5 Ayushi, 2 p-d

Metrics
Divya,
Shikha
13. Estimation wk1,d1 wk4,d6 wk2,d3 wk2,d3 Ayushi, 2 p-d

Model
(COCOMO II Divya,
Model)
Shikha
14. Risk Analysis wk2,d1 wk2,d1 wk2,d7 wk2,d7 3 p-d

Ayushi,
Divya,
Shikha
81
11. RISK MANAGEMENT
A risk table provides with a simple technique for risk projection.
RISKS CATEGORY PROBABILITY IMPACT RMMM
Size estimate may be

PS 50% 3
significantly low
Larger number of users than

PS 30% 3
planned
Less reuse than Planned 4

PS 10%
End-users resist system BU 60% 4
Delivery deadline will be BU 40% 3

tightened
Funding will be lost CU 20% 2
Customer will change requirements PS 20% 1
Technology will not meet

TE 10% 1
expectation
Staff Inexperienced 10% 2

ST
Staff Turnover will be high ST 50% 2
IMPACT VALUES
1—CATASTROPHIC
2—CRITICAL 82
3—MARGINAL
4—NEGLIGIBLE
BIBLOGRAPHY
______________________________________________
 BOOKS -
 Software Engineering - A Practitioner’s Approach by Roger S.

Pressman (7th Edition).
 Software Engineering (Third Edition) by K.K. Aggarwal and

Yogesh Singh.
 JOURNALS AND OTHER ARTICLES –
 “Software Project Planning” - R.S.Pressman & Associates, Inc.
http://www.rspa.com/spi/project-plan.html
 ONLINE RESOURCES –
 Cocomo Model - https://en.wikipedia.org/wiki/COCOMO
 Interface of Google Maps
https://www.google.co.in/maps/@28.6678486,77.3841195,15z
83
84

School Bus Routing Management System: As A Part of The Curriculum of

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

School Bus Routing Management System: As A Part of The Curriculum of

Uploaded by

Copyright:

Available Formats

SHYAMA PRASAD MUKHERJI COLLEGE (FOR WOMEN)

As a part of the curriculum of

B.Sc. (H) COMPUTER SCIENCE

SOFTWARE ENGINEERING PROJECT REPORT (CSHP-410)

SCHOOL BUS ROUTING MANAGEMENT SYSTEM

AYUSHI GOYAL (14075270009)

K.S DIVYA KUMARI (14075270019)

SHIKHA MAHAUR (14075270039)

DR. BALJEET KAUR

SHYAMA PRASAD MUKHERJI COLLEGE (FOR WOMEN),

We place on record and warmly acknowledge the continuous encouragement,

We are grateful to Dr. Pooja Vashisth, Head of the Department of Computer

AYUSHI GOYAL ______________

K.S DIVYA KUMARI ______________

SHIKHA MAHAUR ______________

This is to certify that Ayushi Goyal (14075270009), K.S Divya Kumari

Guided & Approved by:

Dr. Baljeet Kaur

2. SOFTWARE PROCESS MODEL ………………………………………………. 10

3. SOFTWARE REQUIREMENT SPECIFICATION…………………………….. 11 - 25

1.3 Definitions and Abbreviations…………………………………………...12 -

2. The Overall Description……………………………………………………..14 - 20

2.1 Product Perspective……………………………………………………....14

2.1.1 System Interface………………………………………………….15

2.1.2 User Interface…………………………………………………….15 - 16

2.1.3 Hardware Interface……………………………………………….16 - 17

2.1.5 Communication Interface………………………………………......17

2.1.6 Memory Constraints………………………………………………..17

2.1.8 Site Adaption Requirements………………………………………..18

2.2 Product Functions…………………………………………………………..18 -

2.3 User Characteristics…………………………………………………............19

2.5 Assumptions and Dependencies…………………………………………...19 -

3.1 External Interfaces…………………………………………………….…20

3.3 Performance Requirements……………………………………………….21

3.4 Logical Database Requirements…………………………………….…….21

3.5 Design Constraints………………………………………………………..21

3.6 Software System Attributes………………………………………………21 -

3.7 Organizing the Specific-Requirements…………………………………...23

3.7.1 System Mode……………………………………………….…….23 - 24

3.7.2 User Class…………………………………………………………24

4. Data Flow Diagram……………………………………………………………26 - 33

4.1 Context Level Diagram……………………………………………………26

4.2 Level - 1 Data Flow Diagram………………………………………………27

4.3 Level - 2 Data Flow Diagram………………………………………………28

4.4 Data Dictionary…………………………………………………………….29 -

4.5 Entity Relationship Diagram……………………………………………….33

5. Use Case Diagram…………………………………………………………… 34 - 45

5.1 Use Case Description……………………………………………………..35

6.1 Flow Graph……………………………………………………………..48

6.2 Flow Chart ……………………………………………………………..49

6.3 Cyclomatic Complexity ……………………………………………….50

8. Project Metrics ………………………………………………………………66 - 68

9. Effort Estimation using Cocomo Model ……………………………………69 - 71

10. Project Scheduling ……………………………………………………….72 - 76

10.1 Time-Line chart ……………………………………………………..72 - 73

10.2 Task table …………………………………………………………..74 - 76

11. Risk Management ……………………………………………………….. 77

1.2 WHAT WILL THE SOFTWARE DO?

The Model is applied because:

• Requirements are well-defined, clear and fixed.

• Each phase has a review process.

• Each phase has well understood milestones.