Sei sulla pagina 1di 44

TRAFFIC POLICE

SHREE M. & N. VIRANI SCIENCE COLLEGE


RAJKOT

PROJECT REPORT

AS A PARTIAL REQUIREMENT
FOR THE DEGREE OF

BACHELOR OF COMPUTER APPLICATION

YEAR: 2016

TRAFFIC POLICE

GUIDED BY: SUBMITTED BY:


Mr. PRAKASH GUJARATI
CHAUN SHANI J.

1 Prepared By: Chaun Shani


TRAFFIC POLICE

`Sr.No. Chapter Name Page Number


1. Project Profile 4
1.1 Project profile
2. Introduction to the System 6

2.1 Overview of the System


2.3 Drawback of the System
2.3 Proposed system
3. System Planning 9

3.1 Scope of the system


3.2 Feasibility Study
3.3 Software Development Process Model

3.4 Software Specification


3.5 Hardware Specification
4. Requirement Analysis 16

4.1 Software Requirement Specification (SRS)


5. System Design 19

5.1 Context DFD


5.2 Data Flow Diagram (DFD)
6. Data Dictionary 27

7. System Output 30
Project Schedule

Testing
8. Limitation And Scope of Development 52

8.1 System Limitation

2 Prepared By: Chaun Shani


TRAFFIC POLICE

ACKNOWLEDGEMENT
It gives me great pleasure to express my gratitude and respect to all
who inspired me in completion of this project, with heart-felt
gratitude; I would like to acknowledge the great support, help and
guidance of my Internal Project Guide Prof. MR. Prakash Gujarati
who stimulated my mind towards technical and logical thinking and
gave me guidance to make project highly useful and knowledge based
experience.

I have developed a TRAFFIC POLICE APPLICATION as a project work during


the Third Year (6th Semester) of B.C.A, Atmiya Institute of Technology & Science
(Rajkot).

I would like to thank all our faculty members of my college and staff
members of this institute and our colleagues with whom we have shared
thoughts and moments in improving my skills.

Thanking you all for your guidance.

3 Prepared By: Chaun Shani


TRAFFIC POLICE

4 Prepared By: Chaun Shani


TRAFFIC POLICE

Traffic Police
PROJECT-PROFILE

Project-Title:
Atmiya College Management System

Institution: Shree M. & N. Virani Science College

Front-End: Android (Eclipse)

Back-End: SQLite

Team-Size: 1

Project-Guide Mr. Prakash Gujarati

Submitted By: Shani Chaun J.

Submitted To: Saurashtra University.

5 Prepared By: Chaun Shani


TRAFFIC POLICE

6 Prepared By: Chaun Shani


TRAFFIC POLICE

2.1 OVERVIEW OF THE SYSTEM


Official Traffic police Android App

Through This App one can able to see Traffic E-Challan generated for vehicles in Gujarat State.

This is a part of Road Safety and Traffic Violation Control System.

7 Prepared By: Chaun Shani


TRAFFIC POLICE

DRAWBACK OF THE SYSTEM


The Problem with manual transaction is sometime wrong and hard to handle it.

The aim of this application is traffic police can add challan from application and victim can
aware about acts and rules.

Some of the drawbacks of the existing system are as under.

 Easy to handle large amount of data.

 Paper less system

 Friendly environment

2.3 PROPOSED SYSTEM

 Add Challan .

 View Challan.
 List of Rules and Acts.
 Save paper

 Easy to handle data.

8 Prepared By: Chaun Shani


TRAFFIC POLICE

9 Prepared By: Chaun Shani


TRAFFIC POLICE

3.1 SCOPE OF THE PROPOSED SYSTEM

 The proposed system will handle all day to day transactions.

 Manages all the detail about challan.

 It will generate challan for the victim

10 Prepared By: Chaun Shani


TRAFFIC POLICE

3.2 FEASIBILITY STUDY


Feasibility Study is the test of the system proposal according to it
work ability, impact on the current system, ability to meet the needs
of the current users and effective use of the resources. Its main
objective is not to solve the problem, but to acquire its scope. It
focuses on following:

 Meet user requirements.


 Best utilization of available resources.
 Develop a cost effective system.
 Develop a technically feasible system.

 There are three aspects in the feasibility study:


 Technical Feasibility
 Economical Feasibility
 Operational Feasibility
.

11 Prepared By: Chaun Shani


TRAFFIC POLICE

Technical feasibility: -
 The technical issues usually raised during the feasibility stage of the
investigation include following:

 The necessary technology must be existed to do what is suggested.

 The proposed equipment must have the technical capacity to hold


the data required to use the new system.

 There must be technical guarantees of accuracy, reliability ease of


access and data security.

 Software to be used for making the system like as Android


eclipse and SQLite available within the organization and therefore
technically the project is feasible.

12 Prepared By: Chaun Shani


TRAFFIC POLICE

EconomicalFeasibility: -
In economical feasibility, analysis of the cost of the system is carried
out.
The system should be only developed if it is going to give more
benefits than its cost

 In this system it reduces duplication of data as


they are stored and used twice and thrice as it is
stored in database.

13 Prepared By: Chaun Shani


TRAFFIC POLICE

3.3 SOFTWARE DEVELOPMENT PROCESS MODEL

There are a variety of varying process models for software


engineering. They are as follows:
1. The Linear Sequential Model (The Waterfall Model).
2. The Prototyping Model.
3. The RAD Model.
4. The Incremental Model.
5. The Spiral Model.

Our system follows waterfall model.

14 Prepared By: Chaun Shani


TRAFFIC POLICE

3.4 SOFTWARE SPECIFICATION

Given below is recommended specification of required software to


develop the system
Operating system : Microsoft Windows7 for higher

Front End : Android Eclipse

Back End : SQLite

Browser : Jellybean 4.2 to upgrade version

3.5 HARDWARE SPECIFICATION


Given below is recommended hardware specification that
required at server side to run the software

 512 MB Memory card

 2 GB RAM

15 Prepared By: Chaun Shani


TRAFFIC POLICE

16 Prepared By: Chaun Shani


TRAFFIC POLICE

4.1 SOFTWARE REQUIREMENT SPECIFICATION (SRS)


4.1.1 Introduction
 Purpose: The purpose of this document is to describe all the external requirements for
the traffic police app package.

 Scope: Appropriate road safety policy is one of the essential elements of a well-balanced overall
transport and public health policy (Michael Ray, 1995). From this point of view, the national
parliament, government, government ministries and agencies have one of the main
responsibilities for road safety. They prepare professional starting points, decide about
transport and health policy and put them into a practice.1 Road safety responsibility also lies in
private agencies, different associations, non governmental organisations and individual road
users.

 Definition:
o Traffic Police application

4.1.2 Functional Requirements

Following is the general description of Traffic Police Application.

Presently, most of the processes are done online. Following are functional requirements,
which atomization are expected from the Traffic Police Application.

 Maintain personal profile of each Police officer.

 Application Provide To Information all victim.

 Application Provide to Online Product Penalty to the victim.

17 Prepared By: Chaun Shani


TRAFFIC POLICE

4.1.4 Performance Constraints


The application should take only reasonable amount of time while furnishing the
above-mentioned reports.

4.1.5 Design Constraints

Software Constraints:
o In addition to this server module use SQLite as back end database management
system.

o It has to be written in Android eclipse.

Hardware Constraints:
The application will run on an android operating system jellybean 4.2 or above processor

18 Prepared By: Chaun Shani


TRAFFIC POLICE

5.1 DATA FLOW DIAGRAM (DFD)


One of the tools of the structure analysis is the Date Flow Diagrams. A DFD is a
graphical representation of the system. The Data Flow Diagram is used by the system analyst
to explain the flow of the data in the system.

 Process

A process represents some Amount of work being performed on the data. A process does
transformation of data from one form to another. A circle represents a process. The process
must be named and numbered appropriately.

 Data flow

A Data Flow designates an interface among different components in the DFD. It represents
the path of data as it flows through the system. An Arrow represents a data flow. The name
of the data flow is written along the line.

 Data source

A Data Source is a repository of data. An open‐ended rectangle or two horizontal parallel


lines represent it.

A DFD, which describes the system at a very general level, is called the Context Diagram. It
contains a single process, but it plays a very important role in studying the system.

The following pages displayed the context diagram and the DFD’s of subsequent levels of the
Hard & Soft Solution

19 Prepared By: Chaun Shani


TRAFFIC POLICE

PROCESS

ENTITY

DATA FLOW

DATA STOCK / DATA BASE

20 Prepared By: Chaun Shani


TRAFFIC POLICE

5.1.1Context Level DFD


(Admin)
Level 0

Admin Add, Update, Delete


Traffic Police

View Record

Display Record

21 Prepared By: Chaun Shani


TRAFFIC POLICE

5.1.1Context Level DFD


(User Side)

User Add, Update and Delete Challan


Traffic Police

Display Result

22 Prepared By: Chaun Shani


TRAFFIC POLICE

5.2.1SYSTEM ACTIVITY DIA-GRAM

System Activity-Diagram

Login
page

Registerform

Login successfully Login failed

Home
page

23 Prepared By: Chaun Shani


TRAFFIC POLICE

1.Admin

Login

Add Challan Add/Update Update,Del View Challan


/ delete ete Challan
Challan

Logout

24 Prepared By: Chaun Shani


TRAFFIC POLICE

25 Prepared By: Chaun Shani


TRAFFIC POLICE

This page is Splash Screen.

26 Prepared By: Chaun Shani


TRAFFIC POLICE

Admin Side : login

This Page is used for ADMIN Login.

27 Prepared By: Chaun Shani


TRAFFIC POLICE

Home

This page display Home Page.

28 Prepared By: Chaun Shani


TRAFFIC POLICE

Registration

Registration Form.
29 Prepared By: Chaun Shani
TRAFFIC POLICE

This page Add to Chalan.


30 Prepared By: Chaun Shani
TRAFFIC POLICE

All Recoreds Display in this page.


31 Prepared By: Chaun Shani
TRAFFIC POLICE

List & Rules

This
32
page dislay Rules and Acts. Prepared By: Chaun Shani
TRAFFIC POLICE

This page shows about Developer


33 Prepared By: Chaun Shani
TRAFFIC POLICE

34 Prepared By: Chaun Shani


TRAFFIC POLICE

Project Schedule:

Index Task Name Start Finish Duration Dec Jan Feb Mar

2015 2016 2016 2016

1. Requirement 04/12/2015 11/12/2015 3 Days


Analysis

2. Project 05/12/2015 18/12/2015 10 Days


Planning

3. System Design 22/12/2015 25/12/2015 16 Days

4. Detail Design 29/12/2015 10/08/2015 16 Days

5. Coding & Unit 18/01/2016 25/01/2016 40 Days


Testing

6. System 26/02/2016 25/02/2016 12 Days


Integration &
Testing

7. Submission 11/03/2016 11/03/2016 1 Days

35 Prepared By: Chaun Shani


TRAFFIC POLICE

36 Prepared By: Chaun Shani


TRAFFIC POLICE

Test documentation is the complete suite of artifacts that describe test planning, test
design, test execution, test results and conclusions drawn from the testing activity. As testing
activities typically consume 30% to 50% of project effort, testing represents a project within a
project. Testing activities must therefore be fully documented to support resource allocation,
monitoring and control. This page identifies the types of documents you need to set up and
run your test program and summaries their content.

37 Prepared By: Chaun Shani


TRAFFIC POLICE

TESTING:

This section discusses the testing strategy, methodology and types


of tests that the product must pass in order to pass quality
assurance and customer acceptance. A detailed test plan will be
created as part of the implementation phase.

Test Strategy:

The testing strategy used will focus on reliability and performance


of the product. This includes the reporting client hardware,
software, management software, and overall system integration.

The foundation for the success of this product is the Good


Bandwidth. No matter how reliable the software if the bandwidth is
not good the website will not work.

The next key to success is the performance of the website both the
reporting user and remote server. Most operations must
performance at a sub second performance level. This does not mean
that the operation is completed in a sub second although every
effort should be done to actually hit the task assign metric rather
that the user sees the system respond in some function within a
second.

38 Prepared By: Chaun Shani


TRAFFIC POLICE

The final key is that the internal and scheduled processes


operator reliable over long stretches of time with limited user
intervention. In order to grade the quality of the implementation,
the testing will focus on grading the reliability and perfor mance
characteristics of the all aspects of the product. The system will
have to pass multiple repeated testing and hit specific metric agreed
upon ranges. Failure to meet the metric will mean the product is not
implemented correctly and must be corrected. This does not mean
the product will be defect free however it will have no show stopper
bugs and all the features work a majority of the time (95+%) or
report why it did not work and how the user can correct the
problem. In addition, the system if possibl e should report all
exceptions. Once in the field the product reliable will be gauged by
how many error reports are received .

Testing Methodology:

The testing team will adopt the following methodology for


testing:
1. All errors anomalies will be reported to a bug database.

2. No new builds will be accepted for testing without:


a. An issue report includes what issues were resolved in
the build, what issues are left, their status and by
when the issue will be resolved.
b. The mock test results which must be all pass.
c. The unit testing results which must be all pass.
3. Automated testing will be used where ever possible. These
automated tests will be incorporated into the build
process. Failure to pass all automated tests is a failed
build.

39 Prepared By: Chaun Shani


TRAFFIC POLICE

4. Before a bug can be fixed every e ffort must be used to


create a test script that reproduces the error. If a bug
cannot be reproduced using a test script then the bug is
marked not reproducible. If too many bugs are marked as
not reproducible then all development will stop until it is
determined why the bugs cannot be reproduced or the
development team reproduces the bugs.

5. Hand testing will only be used if no other recourse exists .

The goal of automated testing is to make sure that no new bugs are
introduced while fixing bugs. Every feature will have a test that the
software fails before a single line of code is written. Development
will adhere to test driven development methodology.

More complex tests will be created by the QA group and client for
acceptance. This includes metrics. These metrics will cover:

 Mean time to Failure – The amount of time before the


system fails.
 The percentage reliability – The percentage of passed tests
divided by the total number of tests and number of runs of
the tests.
 Performance for each major feature set – This is the actual
runtime performance of the system. There will be a metric
for each major feature set.

40 Prepared By: Chaun Shani


TRAFFIC POLICE

The testing will include :

 Unit testing – Scripted testing of all program elements including


system libraries written by development and user interface.
 Integration testing – Scripted testing of various scenarios using the
whole system.
 Reliability and recovery testing of the reporting user – Testing for
breaking the system including failure scenarios like unplugging the
system in the middle of a task.
 Scalability testing of the management server – Testing to see how
many users can use the system and the degradation to the
performance of the system.

41 Prepared By: Chaun Shani


TRAFFIC POLICE

42 Prepared By: Chaun Shani


TRAFFIC POLICE

8.1 SYSTEM LIMITATION

Most of the software projects have certain limitation. This system has limitation in its
functional areas.

It’s provides normal security features (not encryption).

Future Enhancements:

1) Handle all kind of things about police by one


application.

43 Prepared By: Chaun Shani


TRAFFIC POLICE

BIBLIOGRAPHY

Websites
 www.tutorialpoints.com

Books
 Android

44 Prepared By: Chaun Shani

Potrebbero piacerti anche