SCHOOL BUS ROUTING MANAGEMENT SYSTEM [FINAL]

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 - 141.1 Purpose……………………………………………………………………111.2 Scope……………………………………………………………………...11 -

121.2.1 Objective………………………………………………………… 111.2.2 Goal………………………………………………………………12

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

1.3.1 Definitions………………………………………………………..121.3.2 Abbreviations…………………………………………………….13

1.4 References……………………………………………………………….131.5 Overview………………………………………………………………...13 - 14

2. The Overall Description……………………………………………………..14 - 202.1 Product Perspective……………………………………………………....14

2.1.1 System Interface………………………………………………….152.1.2 User Interface…………………………………………………….15 - 162.1.3 Hardware Interface……………………………………………….16 - 172.1.4 Software Interface…………………………………………………..172.1.5 Communication Interface………………………………………......172.1.6 Memory Constraints………………………………………………..172.1.7 Operation……………………………………………………………17 - 182.1.8 Site Adaption Requirements………………………………………..18

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

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

4

2.4 Constraints………………………………………………………………......192.5 Assumptions and Dependencies…………………………………………...19 -

20

3. Specific Requirement…………………………………………………………20-25

3.1 External Interfaces…………………………………………………….…203.2 Functions…………………………………………………………………203.3 Performance Requirements……………………………………………….213.4 Logical Database Requirements…………………………………….…….213.5 Design Constraints………………………………………………………..213.6 Software System Attributes………………………………………………21 -

253.6.1 Reliability……………………………………………….………..21 - 223.6.2 Availability……………………………………………………….223.6.3 Security………………………………………………….………..223.6.4 Maintainability……………………………………………………233.6.5 Portability…………………………………………………………233.6.6 Flexibility…………………………………………………………233.6.7 Reusability………………………………………………………...233.6.8 Usability………………………………………………………..... 23

3.7 Organizing the Specific-Requirements…………………………………...233.7.1 System Mode……………………………………………….…….23 - 243.7.2 User Class…………………………………………………………243.7.3 Features……………………………………………………………243.7.4 Stimulus…………………………………………………………...243.7.5 Response…………………………………………………….….....25

4. Data Flow Diagram……………………………………………………………26 - 334.1 Context Level Diagram……………………………………………………264.2 Level - 1 Data Flow Diagram………………………………………………274.3 Level - 2 Data Flow Diagram………………………………………………284.4 Data Dictionary…………………………………………………………….29 -

324.5 Entity Relationship Diagram……………………………………………….33

5

5. Use Case Diagram…………………………………………………………… 34 - 455.1 Use Case Description……………………………………………………..35

45

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

6

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

7

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.

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.

8

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.

9

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 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:

10

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

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-

11

https://en.wikipedia.org/wiki/Vehicle_tracking_system

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.

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.

12

https://en.wikipedia.org/wiki/Fleet_vehicle

https://en.wikipedia.org/wiki/Computer_software

https://en.wikipedia.org/wiki/Automatic_vehicle_location

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.

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.

13

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 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:

14

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 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:

15

a Touch screen a Networked computer

PROCESSOR – P-1V(2.80 GHZ)

RAM – 512GB

STORAGE CAPACITY – 80GB

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-

16

Students who have already registered can access their account by logging in, using the student ID and Password.

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.

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.

17

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.

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

18

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.

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.

19

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.

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

20

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.

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.

21

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.

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

22

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 CLASSFollowing criteria for operating the software are -

USER

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

23

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.

24

4.DATA FLOW DIAGRAM

4.1 CONTEXT LEVEL DIAGRAM

25

4.2 LEVEL-1 DFD

26

4.3 LEVEL-2 DFD

27

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

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


28

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



29

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




30

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]

31

4.5 ENTITY RELATIONSHIP DIAGRAM

32

5. USER CASE DIAGRAM

33

5.1 USE CASE DESCRIPTION

1. REGISTRATION

Brief Description-This use case allows the actor to register for the School bus Services.

ActorsThe 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 RequirementThere is no special requirement.

Pre- conditionStudent must have opened the software prior to registration.

Post-condition1) Successful Registration

User now has an account and can fully utilize the software.

2) Registration FailedUser has not provided the valid details and is required to perform the previous steps again.

Extension PointsThere is no extension points associated with this use case.

34

2. LOGIN

Brief DescriptionThis use case describes how the registered students and admin log into the system.

ActorsFollowing 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.

Alternative Flow-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.

Special RequirementStudent 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.

If the actor is “Student”, he/she will have access to only screens corresponding to Track Bus, Request Bus Information and Update Student information.

35

If the actor is “Admin”, he/she will have access to complete software.

Extension PointThere is no extension points associated with this use case.

3. REQUEST

Brief DescriptionThis use case describes how an actor requests for the information he/she desires to see.

ActorsFollowing actors can perform this use case:1) Student.2) Admin.

Flow of Events

Basic FlowThis 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 FlowIf 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.

Special Requirement Bus Id must be valid.

Pre-condition1) If the actor is “Student”, then he/she must be a registered user.2) No pre-condition is there for Admin.

Post-condition Successful Operation-

If the Bus Id was valid, actor has complete information about the bus schedule or bus staff.

36

Failed Operation-Error Message will be displayed.

Extension PointNo extension point is there in this use case.

4. Track A Bus

Brief DescriptionThis use case describes how an actor tracks a bus on a particular route.

ActorsFollowing 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.

Alternative Flow-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.

Special Requirement Bus Id must be valid.

37

Pre-condition1) If the actor is “Student”, then he/she must be a registered user.2) No pre-condition is there for Admin.

Post-conditionIf 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 PointNo extension point is there in this use case.

5. Update Student Information

Brief DescriptionThis use case allows the actor to update his/her account details such as residential address and contact no.

ActorsOnly 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.

Alternative Flow-No Alternative Flow.

Special RequirementsNo 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

38

If required a new Bus will be assigned to the student according to the new residential address provided by the student.

Extension PointThere is no extension point in this use case.

6. Delete Student Account

Brief DescriptionThis use case allows actor to delete a student account.

ActorsOnly 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.

Alternative Flow-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.

Special RequirementStudent Id must be Valid.

Pre-conditionsStudent Id provided by the admin must be valid i.e there must exist an account associated with that student Id.

Post-condition1) Student’s account has been deleted.2) The admin is notified that the requested account has been deleted.

Extension PointsNo Extension Point is there.

7. Add/Delete Bus

39

Brief DescriptionThis use case allows the actor to add/delete a School Bus.


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.

Alternative FlowIf 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-conditionsBus 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.

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.

Extension PointsThere is no Extension Point in this use case.

40

8. Add/Delete Route

Brief DescriptionThis use case allows the admin to add/delete a route associated with some School Bus.


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.

Alternative Flow-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.

Special Requirement. Route No. must be Valid.

Pre-conditionsRoute no. provided by the admin must be valid i.e

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.


41

9. Add/Delete Teacher In charge

Brief DescriptionThis use case allows the admin to add or delete a Teacher In charge.


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.

Alternative FlowIf 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.

Special Requirement.Teacher Id must be Valid.

Pre-conditionsTeacher 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.


42

10. Add/Delete Driver

Brief DescriptionThis use case allows the admin to add or delete a Driver.


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.

Alternative FlowError 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.

Special Requirement.Driver Id must be Valid.

Pre-conditionsDriver 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.


43

11.Add/Delete Conductor

Brief DescriptionThis use case allows the admin to add or delete a Conductor.


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.

Alternative FlowIf 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.

Special Requirement.Conductor Id must be Valid.

Pre-conditionsConductor 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.


44

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;

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;

45

filehandler.open (“Student_information||contact details_contact)

int contact;

Read updated contact;

getline (filehandler, contact);

filehandler.close ();

END IF

END DO

END

46

6.1 FLOW GRAPH

47

2

3 4

5

6

9

7

10

8

12

11

13

1

6.2 FLOW CHART

12

48

2

3 4

5

6

89

11 10

7

1

49

13

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

50

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

51

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



52

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



MY ACCOUNT SCREEN

53

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



54

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


NUMBER OF FILES - 0



55

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


NUMBER OF FILES - 1



56

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

NUMBER OF FILES - 0



57

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.

NUMBER OF INPUT - 6


NUMBER OF FILES - 1

NUMBER OF ENQUIRIES -0


58

UPDATE DRIVER INFORMATION

Feature of Updating the Information of staff is enabled only for Admin. Admin can add or 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

59

UPDATE CONDUCTOR INFORMATION

Feature of Updating the Information of staff is enabled only for Admin. Admin can add or 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



61

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



BUS INFORMATION SCREEN

62

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



63

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.

64

NUMBER OF INPUT - 1


NUMBER OF FILES - 1



65

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:

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.

Information

Domain Value

Count Simple Average Complex

External I/P

× 3 4 6 =

66

FP = count total x [0.65 + 0.01 x ∑ (Fi)]

WEIGHTING FACTOR

6.7 87

https://en.wikipedia.org/wiki/Software

External

O/P

× 4 5 7 =

External Inquiries

× 3 4 6 =

Internal Logical Files

×

7 10 15

=

External Interfaces Files

×

5 7 10

=

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 from the application?

3

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 screens or operations?

3

8. Are the ILFs updated online? 3

9. Are the inputs, outputs, files, or inquiries complex? 3

10. Is the internal processing complex? 3

67

COUNT TOTAL

4.7 75

0.3

3

0.3

4

96

7

269

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.

68

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

Object point is used to calculate indirect count measure that is obtained with number of Screens, Reports, and 3GL components.

69

OBJECT TYPECOMPLEXITY WEIGHT

SIMPLE MEDIUM COMPLEX

SCREENS

REPORTS

3GL COMPONENTS

2 7 4

1

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]

"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

NOP = (Object Points)*[(100%-reuse)/100]

70

DEVELOPER’S EXPERIENCE/CAPABILITY

ENVIRONMENT MATURITY/CAPABILITY

PRATE

Very low Low Nominal High Very High

Very low Low Nominal High Very High

4 7 13 25 50

= 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

71

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

1

W

2

W

3

W

4

W

1

W

2

W

3

W

4

W

1

W

2

W

3

W

4

W

1

W

2

W

3

W

4

1. Problem Statement

2. Software Process Model

3. Structure of Team

4. Project Scheduling

5. Software Requirements Specification

6. Data Flow Diagram6.1 Context Level6.2 Level-1 DFD6.3 Level 2 DFD

7. Data Dictionary

8. Entity

72

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

10.2 TASK TABLE

Work Tasks Planned Start

Actual Start

Planned

Complete

Actual Complete

Assigned

Person(s)

Effort Allocated

1. Problem Statement

wk1,d1 wk1,d1 wk1,d7 wk1,d6 Ayushi,

Divya,

3 p-d

73

2. Software Process Model

3. Structure-of Team

4. Project Scheduling

5. Software Requirements Specification

6. Data-Flow Diagram6.1 Context Level

6.2 Level-1 DFD

6.3 Level 2 DFD

wk2,d1

wk2,d4

wk3,d1

wk3,d4

wk1,d1

wk1,d5

wk3,d1

wk1,d7

wk2,d4

wk3,d1

wk3,d4

wk1,d1

wk1,d5

wk3,d1

wk2,d3

wk2,d7

wk3,d3

wk4,d7

wk1,d4

wk2,d7

wk3,d7

wk2,d3

wk2,d7

wk3,d3

wk4,d6

wk1,d4

wk2,d7

wk3,d6

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

2 p-d

2 p-d

2 p-d

3 p-d

3 p-d

74

7. Data Dictionary

8. Entity Relationship Diagram

9. Use-Case Diagram

10. Use-Case Description

wk4,d1

wk1,d1

wk1,d5

wk2,d1

wk3,d7

wk4,d5

wk1,d2

wk1,d4

wk4,d7

wk1,d5

wk1,d7

wk2,d6

wk4,d4

wk1,d2

wk1,d3

wk2,d2

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

2 p-d

1 p-d

1 p-d

3 p-d

Work Tasks Planned Start

Actual Start

Planned

Complete

Actual Complete

Assigned

Person(s)

Effort Allocated

11. Software Testing

wk2,d6 wk2,d3 wk3,d7 wk3,d5 Ayushi,

Divya,

Shikha

3 p-d

75

12. Software Metrics

13. Estimation Model(COCOMO II Model)

14. Risk Analysis

wk4,d1

wk1,d1

wk2,d1

wk3,d6

wk4,d6

wk2,d1

wk4,d7

wk2,d3

wk2,d7

wk4,d5

wk2,d3

wk2,d7

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

Ayushi,

Divya,

Shikha

2 p-d

2 p-d

3 p-d

11. RISK MANAGEMENT

A risk table provides with a simple technique for risk projection.

76

RISKS RMMMIMPACTPROBABILITYCATEGORY

Size estimate may be significantly low

Larger number of users than planned

Less reuse than PlannedEnd-users resist systemDelivery deadline will be tightenedFunding will be lostCustomer will change requirementsTechnology will not meet expectation Staff InexperiencedStaff Turnover will be high

PS

PS

PSBUBUCU

50%

30%

STSTTEPS10%60%40%20%20%10%50%

3

110%

3

4432221

77

IMPACT VALUES

1—CATASTROPHIC

2—CRITICAL

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

78

https://www.google.co.in/maps/@28.6678486,77.3841195,15z

https://en.wikipedia.org/wiki/COCOMO

http://www.rspa.com/spi/project-plan.html

Documents

SCHOOL BUS ROUTING MANAGEMENT SYSTEM [FINAL]