1

SAVITRIBAI PHULE PUNE UNIVERSITY

A PROJECT REPORT ON

Hazard Object Report to the Respective

Authorities

SUBMITTED TOWARDS THE

PARTIAL FULFILLMENT OF THE REQUIREMENTS OF

BACHELOR OF ENGINEERING (Computer Engineering)

BY
Kothule Dhanashri B120584237

Sonone Vaibhav B120584282

Sonawane Jayashre B120584280

Jadhav Riya B120584225

Under The Guidance of

Prof. G.D.Nikam

DEPARTMENT OF COMPUTER
ENGINEERING
Matoshri College of Engineering and Research Centre

Eklahare,Nashik Eklahare, Near Odha Gaon, Aurangabad Road, Nashik Pin No.:422135
MCOERC, Department Of Computer Engineering 2015-16
 2

Savitribai Phule Pune University

YEAR 2015-2016

Matoshri College of Engineering and Research Centre

DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE

This is to certify that the Project Entitled

Hazard Object Report to the Respective

Authorities
Submitted By

Kothule Dhanashri B120584237

Sonone Vaibhav B120584282
Sonawane Jayashree B120584280
Jadhav Riya B120584225
is a bonafide work carried out by Students under the supervision of Prof. G.D.Nikam
and it is submitted towards the partial fulfillment of the requirement of Bachelor
of Engineering (Computer Engineering).

Prof. G.D.Nikam Prof. V.H.Patil

MCOERC, Department Of Computer Engineering 2015-16
 3

Internal Guide H.O.D

Dept. of Computer Engg. Dept. of Computer Engg.

Dr. A. V. Deshpande
Principal
Smt.Kashibai Navale College of Engineering

Signature of Internal Examiner Signature of External Examiner

MCOERC, Department Of Computer Engineering 2015-16

 PROJECT APPROVAL SHEET

A Project Title

Hazard Object Report to the Respective

Authorities

Is successfully completed by

Kothule Dhanashri B120584237

Sonone Vaibhav B120584282
Sonawane Jayashree B120584280
Jadhav Riya B120584225

at

DEPARTMENT OF COMPUTER ENGINEERING

MATOSHREE COLLEGE OF ENGINEERING AND RESEARCH CENTER

SAVITRIBAI PHULE PUNE UNIVERSITY,PUNE

ACADEMIC YEAR 2015-2016

Prof. G.D. Nikam Prof. V.H, Patil

Internal Guide H.O.D
Dept. of Computer Engg. Dept. of Computer Engg.
 Abstract

We need to capture real time images of hazardous objects with their location and sync it with the server. The data captured
from android will be shown on Google Maps using Google Maps API v3. This data will be available to corresponding
departments of government. In existing system, people do not have any central platform where they can report all their
issues. So government does not understand the exact problem and their location. In Proposed system, we are developing
one central platform where all issues can be reported with their location to respective departments. The objective of the
system is to send the images, audio or video related to issue to the respective departments of the governments. We are
sending this using the web services and android device. Using this system, we can keep track of the ratio of complaints
registered and issues which are unsolved.
College Short Form Name, Department of Computer Engineering 2015-16 I
 Acknowledgments

It gives us great pleasure in presenting the preliminary project report on BE

Hazard Object Report To Respective Authorities.

I would like to take this opportunity to thank my internal guide Prof. G.D. Nikam for giving
me all the help and guidance I needed. I am really grateful to them for their kind support.
Their valuable suggestions were very helpful.

I am also grateful to Prof. V.H. Patil, Head of Computer Engineering Department,

Matoshree College Of Engineering and Research Center for his indispensable support,
suggestions.

In the end our special thanks to Mr. Nikhil Kokane , Mrs. Jayashree Bedade for providing
various resources.such as laboratory with all needed software platforms, continuous Internet
connection for Our Project.

Dhanashri Kothule

Vaibhav Sonone

Jayashree Sonawane

Jadhav Riya

(BE Computer Engg.)

INDEX
1 Synopsis 18
1.1 Project Title........................................................................................ 18
1.2 Project Option................................................................................... 18
1.3 Internal Guide.................................................................................... 18
1.4 Sponsorship and External Guide..................................................... 18
1.5 Technical Keywords (As per ACM Keywords)............................. 18
1.6 Problem Statement............................................................................ 19
1.7 Abstract.............................................................................................. 19
1.8 Goals and Objectives........................................................................ 19
1.9 Relevant mathematics associated with the Project........................ 19
1.10 Names of Conferences / Journals where papers can be published 21
1.11 Review of Conference/Journal Papers supporting Project idea . . 21
1.12 Plan of Project Execution................................................................. 21

2 Technical Keywords 22
2.1 Area of Project................................................................................... 22
2.2 Technical Keywords.......................................................................... 22

3 Introduction 24
3.1 Project Idea........................................................................................ 24
3.2 Motivation of the Project.................................................................. 24
3.3 Literature Survey............................................................................... 24

4 Problem Definition and scope 27

4.1 Problem Statement............................................................................ 27
 4.1.1 Goals and objectives........................................................... 27
4.1.2 Statement of scope.............................................................. 27
4.2 Major Constraints............................................................................. 28
4.3 Methodologies of Problem solving and efficiency issues......... 27
4.4 Outcome............................................................................................. 28
4.5 Applications...................................................................................... 28
4.6 Hardware Resources Required....................................................... 28
4.7 Software Resources Required........................................................ 29

5 Project Plan 30
5.1 Project Estimates.............................................................................. 30
5.1.1 Reconciled Estimates.......................................................... 30
5.1.2 Project Resources................................................................ 31
5.2 Risk Management w.r.t. NP Hard analysis................................... 32
5.2.1 Risk Identification............................................................... 32
5.2.2 Risk Analysis........................................................................ 34
5.2.3 Overview of Risk Mitigation, Monitoring, Management 35
5.3 Project Schedule............................................................................... 35
5.3.1 Project task set..................................................................... 35
5.3.2 Task network........................................................................ 36
5.3.3 Timeline Chart..................................................................... 37
5.4 Team Organization........................................................................... 37
5.4.1 Team structure...................................................................... 37
5.4.2 Management reporting and communication................... 38

6 Software requirement specification 39

6.1 Introduction....................................................................................... 39
6.1.1 Purpose and Scope of Document...................................... 39
6.1.2 Overview of responsibilities of Developer...................... 39
6.2 Usage Scenario................................................................................. 39
6.2.1 User profiles......................................................................... 39
6.2.2 Use-cases.............................................................................. 40
 6.2.3 Use Case View...................................................................... 41
6.3 Data Model and Description............................................................ 41
6.3.1 Data Description................................................................... 41
6.3.2 Data objects and Relationships . ........... 42
6.4 Functional Model and Description.................................................. 42
6.4.1 Data Flow Diagram.............................................................. 42
6.4.2 Activity Diagram:................................................................. 44
6.4.3 Non Functional Requirements: . .......... 44
6.4.4 State Diagram:...................................................................... 46
6.4.5 Design Constraints................................................................ 47
6.4.6 Software Interface Description . .......... 47

7 Detailed Design Document using Appendix A and B 48

7.1 Introduction........................................................................................ 48
7.2 Architectural Design......................................................................... 48
7.3 Data design (using Appendices A and B) . 49
7.3.1 Internal software data structure . . 49
7.3.2 Global data structure............................................................ 50
7.3.3 Temporary data structure..................................................... 50
7.3.4 Database description............................................................ 50
7.4 Compoent Design.............................................................................. 51
7.4.1 Class Diagram....................................................................... 51

8 Project Implementation 53
8.1 Introduction........................................................................................ 53
8.2 Tools and Technologies Used........................................................... 53
8.3 Verification and Validation for Acceptance.. 53

9 Software Testing 54
9.1 Type of Testing Used........................................................................ 54
 9.2 Test Cases and Test Results............................................................ 56

10 Results 57
10.1 Screen shots....................................................................................... 57

11 Deployment and Maintenance 61

11.1 Installation and un-installation....................................................... 61
11.2 User help............................................................................................ 62

12 Conclusion and future scope 64

12.1 Conclusion. 64
12.2 Future Scope. 64
Annexure A References 65

Annexure B Laboratory assignments on Project Analysis of Algorithmic

Design 66

Annexure C Laboratory assignments on Project Quality and Reliability

Testing of Project Design 68

Annexure D Project Planner 71

Annexure E Reviewers Comments of Paper Submitted 74

Annexure F Plagiarism Report 75

Annexure G Term-II Project Laboratory Assignments 76

Annexure H Information of Project Group Members 77

List of Figures

6.2.1 Use case diagram............................................................................... 41

6.4.1 DataFlow Diagram. 42
6.4.2 Activity Diagram 44
6.4.4 State Diagram 46

7.2 Architecture Diagram 49

7.4 Class Diagram 51
List of Tables

3.1 Literature Survey............................................................................. 26

4.6 Hardware Requirement. 30

5.1 Cost Estimation..... 32

5.2.1 Risk Identification 36
5.2.2 Risk Table 37
5.2.3 Risk Probability Table. 37
5.2.4 Risk Impact Table 37

6.1 Use Cases.......................................................................................... 40

9.2 Test Cases. 56

D.1 Project Plan...................................................................................... 72

 CHAPTER 1

SYNOPSIS
1.1 PROJECT TITLE

Hazard Object Report to the Respective Authorities.

1.2 PROJECT OPTION

Sponsored

1.3 INTERNAL GUIDE

Prof. G.D.Nikam

1.4 Sponsorship And External

Guide

Company Name:- Opulent Infotech

PVT. LTD.

Sponsorer Name:- Mr. Nilesh Pagar

1.5 TECHNICAL KEYWORDS (AS PER ACM KEYWORDS)

GPS :- Hazardous Global Positioning System)

API :- Application Programming Interface)
Wi-Fi :- Wireless Fidelity)
Risk Level

1.6 PROBLEM STATEMENT

We need to capture real time images of hazardous objects with their location and sync it
 with the server. The data captured from android will be shown on Google Maps using Google Maps

API v3.This data will be available to corresponding departments of government

1.7 ABSTRACT

We need to capture real time images of hazardous objects with their location and sync it
with the server. The data captured from android will be shown on Google Maps using Google Maps API
v3. This data will be available to corresponding departments of government. In existing system, people do
not have any central platform where they can report all their issues. So government does not understand the
exact problem and their location.
In Proposed system, we are developing one central platform where all issues can be
reported with their location to respective departments. The objective of the system is to send the images,
audio or video related to issue to the respective departments of the governments. We are sending this using
the web services and android device. Using this system, we can keep track of the ratio of complaints
registered and issues which are unsolved.

1.8 GOALS AND OBJECTIVES

The objective of the system is to send the images, audio or video related to issue to the
respective departments of the governments. We are sending this using the web services and
android device. Using this system, we can keep track of the ratio of complaints registered and
issues which are unsolved.

1.9 RELEVANT MATHEMATICS ASSOCIATED WITH THE

PROJECT

System Description:

Input: {I1 , I2}

I1= Firstly new user login with the help of User_id And Password.

I2=Take Original general issues photos or videos and send to the server.

Output: : {O1,O2,O3}

O1=Action taken by municipal corporation on this issues.

O2=Action taken by Higher Authority .

O3=Last media to show all this issues and media creates the issue all this things.

Functions : {F1,F2,F3,F4,F5,F6,F7}

F1=Check valid user or not if valid then send message to the user login successful.

F2=Server get input photos from user.

F3=Classification is perform on photos because it is check to the user send photos is match with server

Save the photos of issue.

F4=After the image classification report get generate.

F5=Send this created report to the Municipal corporation

F6=Any action related message Department then stop otherwise send report to the

Higher Authority.

F7=After 2 days all photos send to the Social Media.

Mathematical formulation

1)Location = {L1,L2,.Ln}
2)Server = {S1,S2,.Sn}
3)Department = {D1,D2,.Dn}
4)Media = {M1,M2,.Mn}
 Success Conditions: The feedback is sending to user that is the problem is solved.

Failure Conditions: The problem will not resolved.

1.10 NAMES OF CONFERENCES / JOURNALS WHERE

PAPERS CAN BE PUBLISHED

Imperial Journals Of Interdisciplinary Research

(IJIR Publication)

1.11 REVIEW OF CONFERENCE/JOURNAL PAPERS SUPPORTING

PROJECT IDEA

The reviewers are provide the review within 10 days after submission of paper.
The reviewers are tell us there should be evaluation of the manuscript,
originality,methodology and contribution to liture survey, presentation of
results and support to future conclusion and future work are defined correctly
and appropriately.

After generating report we will published your paper.

1.12 PLAN OF PROJECT EXECUTION

The palan for execution is as follows:

1) We can firstly take the requirement of user and check the availability of
software.

2) After that we design the project plan and as per the project plan the task will
be assign to group members.

3) The group members are perform their task and start development of
software or system.

4) After development the testing will be perform for checking the correctness
of system.

5) If no error will be found then the deployment and maintainance phase will
be perform

6) Then system is working correctly.

 CHAPTER 2

TECHNICAL KEYWORD

2.1 AREA OF PROJECT

Networking

2.2 TECHNICAL KEYWORDS

GPS :- Hazardous Global Positioning System)

API :- Application Programming Interface)
Wi-Fi :- Wireless Fidelity)
Risk Level
 CHAPTER 3

INTRODUCTION
3.1 PROJECT IDEA

The project idea is to improve the social awareness into the people. All
authorities are not work properly so we get this idea to improve the working ability
of all authorities and they work properly.

3.2 MOTIVATION OF THE PROJECT

City should be clean everyday

All garbage in the city will be removed.
Improper roads in the city will be work properly after the authorities will
taking action on that issue.
All the higher and lower authorities will work on the peoples problem or
social problem which is reported by user or people.

3.3 LITERATURE SURVEY

Recently, the use of mobile communication devices, such as smart phones and cellular
phones, in field data collection is increasing due to the emergence of embedded Global Position
Systems (GPS) and Wi-Fi Internet access. Accurate, timely and handy field data collection is required
for disaster management and quick response during emergencies. In this article, we introduce a
web-based GIS system to collect the field data from personal mobile phones through a Post Office
Protocol POP3 mail server.
The main objective of this work is to demonstrate a real-time field data collection
method to students using their mobile phones to collect field data in a timely and handy manner,
either in individual or group surveys at local or global scale research. Geospatial data collection is one
of the important tasks for many spatial information users. Geospatial data collection may include
remote sensing data, field data and other in-house GIS data conversion processes (i.e. scanning,
geofencing, digitizing, etc.). Among them, field data collection is one of the first steps for spatial
information users, especially for geographers, geologists, biologists, crop scientists, ecologists, etc.
Field data collection is required for several reasons, such as collecting Ground Control Points (GCPs),

ground truth data collection for result validation, collecting soil contaminated sites, plant or animal species,
and gathering public opinions for retail market analysis in order to analyze the spatial distribution patterns
of objects and information on their associated attributes.
Accurate field data collection is also necessary for adequate spatial data analysis and proper decision
making. Traditional field data collection (i.e. pen-and-paper based) is a time consuming and bulky task.
For example, we need to prepare basemaps, collect an ancillary dataset, and other paperwork.
This is not practical to use in real-time disaster information collection, which occurs in unpredictable
places and requires a quick emergency response.
However, recent developments in mobile communication Global Navigation Systems, the Internet and
portable computational devices such as Netbooks or Ultra Mobile Personal Computers (UMPC) allow us
to conduct field data collection in a timely manner. Moreover, under the client-server setting for field
data collection, a field user may take advantage of digital repositories prepared for data collection
(i.e. basemaps, satellite images and other ancillary data), as well as information resources more
generally available via the Web.

Table 3.1: Literature Survey

Sr.No Year Author Name Techniques Remarks

applied

1 2013 Ko Ko Lwin , Web-Based GIS Image sending This paper is

Yuji Murayama System for Real- technique limited for
 Time Field Data knowledge

Collection Using about GIS

Personal Mobile system

Phone

2 2008 K2008, pp. Designing a By creating This paper is

Moe, B. Usable Mobile mobile limited for
Dwolatzky and Application for application for knowledge
R. Olst, Field Data sending data about the
Collection, application
IEEE AFRICON and use of
application.

3 2010 [2] S. Mouro Mobile Phone Sending data This paper is

and K. Okadata as a Tool for by using limited for
Data Collection Mobile phone knowledge
in Field and time limit about the how
Research, technique used the send data
by using
mobile phone
 CHAPTER 4
PROBLEM DEFINATION AND SCOPE
4.1 PROBLEM STATEMENT
We need to capture real time images of hazardous objects with their location and sync it

with the server. The data captured from android will be shown on Google Maps using Google Maps

API v3.This data will be available to corresponding departments of government.

4.1.1 Goals and objectives:

The objective of the system is to send the images, audio or video related to issue

to the respective departments of the governments. We are sending this using the web services and

android device. Using this system, we can keep track of the ratio of complaints registered and issues which

are unsolved.

4.1.2 Statement of scope :

Android Application
1. Design and creation
2. Web Services Design
3. Android layout design in XML
4. Login with user ID & Password as well as IMEI
5. Multiple Image capture logic
6. GPS integration

Dynamic Web Application

1. Database Design in MongoDB
2. GUI Design
3. Servlets and JSP

4.2 MAJOR CONSTRAINTS

Software Requirements
 To describe the logical and physical characteristics of each interface between the
software product and the hardware components of the system.This includes the supported device types,
the nature of the data and control interaction between the software and the hardware and
communication protocols to be used.
1. Operating System: Windows
2. Programming Environment: JDK 7.0
3. Programming Tool: Android Development Tool(Eclipse)
4. Database used: MongoDB

Hardware Requirements
Describe the connections between this product and other specific software
components (name and version),including databases, operating system, tools, libraries, and
integrated Commercial components.
Identify the data items or messages coming into the system and going out and describe the purpose of
each. Describe the services needed and the nature of communications.
1. Processor Type: Dual Core
2. Speed: 2.4 GHz
3. RAM: 2 GB
4. HDD: 100 G
Features of the System
The various features of the system are:-
1) Operating System:
Windows
2) Programming Environment:
We will be Using JDK 7.0 as the development platform for the prototype system.
3) Programming Tools:
Android Development Tool(Eclipse)
4) Android 2.2 supported mobile handset.
5) Google Map API v3 integration:
Data captured on android will be shown on Google Maps using Google Maps API v3.
6) Database:
We are using MongoDB as the database. We are using concept
of metadata in this system. The tables will be generated and managed at the run time in this system.
We are using MongoDB for transferring the videos.
Implementation, testing and documenting

Implementation is the part of the process where software engineers actually

program the code for the project. Software testing is an integral and important phase of the

software development process. This part of the process ensures that defects are recognized as soon

as possible. Documenting internal design of software for the purpose of future maintenance
and enhancement is done throughout development. This may also include the writing of an API,

be it external or internal. The software engineering process chosen by the developing team will

determine how much internal documentation (if any) is necessary.

4.3 METHODOLOGIES OF PROBLEM SOLVING AND EFFICIENCY

ISSUES

Methodologies:
1) Problem Solved By Lower Authority
When the problem is sending to lower authority or municipal party and
they provide the solution of problem with the generating report.
2)Problem Solved by Higher Authority
If the lower Authority is not solving the problem at that time the issue
will be send to higher authority and then higher authority provide solution
of problem.
3) Problem Solved by Media
If the problem is not solved by higher and lower authority then media will
display that images and videoson social media with their report.

Efficiency
1) If the problem will be solved by authorities with the correct generation of
report then the project will be efficient to use.
2) When the problem is not solved by authorities then it will take the more
timeto solve the problem and it will reduce the efficiency of project.

4.4 OUTCOME

The outcome of project is all the social problems in the city or any state will be
resolved and authorities will doing their work properly and efficiently. The city will neat
and clean at everyday

4.5 APPLICATIONS

This system provide the maximum solution of social problem.

It also used by all people or normal user to send their peoblem to

 authorities

Main application is all authority will work on the social problem or

user problem.

The will always neat and clean because of the authority will work
appropriately

4.6 HARDWARE RESOURCES REQUIRED

Table 4.6: Hardware Requirement

Sr. No Parameter Memory Justification

Required
1 Processor Type Dual Core Remark Required
2 Speed 2GHz Remark Required
3 RAM 2GB Remark Required
4 HDD 100G Remark Required
4.7 SOFTWARE RESOURCES REQUIRED

1. Operating System: Windows

2. Programming Environment: JDK 7.0
3. Programming Tool: Android Development Tool(Eclipse)
4.Database used: MngoDB
 CHAPTER 5

PROJECT PLAN

5.1 PROJECT ESTIMATES

5.1.1 Reconciled Estimates

1) Cost Estimate
Effective software project estimation is one of the challenging and important activities in
software development. The four basic steps in software project estimation are:

1. Estimate the size of development product. The units of measure are lines of
codes(LOOC) and function point (FP).

2. Estimate the effort in person-months or person-hours.

3. Estimate the schedule in calendar months.

4. Estimate the project cost in rupees.

Table 5.1.1 : Cost Estimation

Total number of persons working on project 04

Total time allotted per day in terms of hour 02

Actual working hours 480

Cost per hours 50

Total Cost Estimation Of Project 24000

2) Time Estimates

A bar chart is perhaps the simplest form of formal management. The bar
chart is used almost exclusively for scheduling purposes and therefore controls only the time dimension
of projects.
Gantt chart (developed by Henry L.Gantt) are a project control technique that can be used for
several purposes, including scheduling, budgeting and resources planning. A Gantt chart is a bar chart,
with each bar representing an activity. The bars are drawn against time line. The length of each bar
is proportional to the length of the time planned for the activity.
A Gantt chart helps in scheduling the activities of a project, but it does not help in identifying them.

One can begin with the activities identified in the work breakdown structure, as we did for the

compiler example. During the scheduling activity, and also during implementation of the project,

new activities may be identified that not envisioned during the initial planning. The manager must then

go back and revise the breakdown structure and the schedules to deal with these activities

5.1.2 Project Resources

Hardware Interface

Describe the connections between this product and other A Software

Requirement Specification(SRS)-a requirement for a software system-is a complete description

of the behavior of a system to be developed and may include set of use cases that describe interactions

the users will have with the software. In addition it also contains non-functional requirements.

1) Introduction

The system is to send the images, audio or video related to issue to the

Respective departments of the governments. We are sending this using the

web services and android device. Using this system, we can keep track of the

ratio of complaints registered and issues which are unsolved.

2) Product Scope

Nowdays, cleaning the cities is the important issue of all over the world. It is

not possible to clean all the cities in every day but it is possible to clean the city in a week.

But our municipal party will not take the any action about this that is clean the city.

So for this reason we implement this system.The system takes the images,videos of
 garbage, damage road etc and it will send to the server. Then server will take the action

by checking the feasibility of image that is this image is for MNC and if it is for MNC then it

will send to the MNC and MNC will take the action on it.If the all higher and lower authority

will not take the action then it will automatically send to the media.

By using this system the MNC will take the strict action and clean the city always and everyday.

It gives the more improvement in MNC work.

3) Overall Description

Further is the overall description of the proposed system in detail with respect

to the various methods to be used or implemented in system.

4) Product Perspective

When the user capture the image or video and it will send to the server at that

time if server will not take the action then this is wastage of efforts to solve this problem. We

need to implement the system which take the action on sending images of user and if the action is

not taken then server will send to this images to media.Cost and Time of the system is equal to cost

and time to required for taking the action And it is guarantee that the action will be taken by

MNC when the media will create the issue.

External Interface Requirements

Some of the user interface of the system is as follows

1) User Interfaces:
1.Login Form
2. Survey Form
3. Image Upload Form
4. Sync Settings Form
5. Google Map View
6. Master Form

Software Interface

To describe the logical and physical characteristics of each specific

software components (name and version),including databases, operating system, tools, libraries,
and integrated Commercial components. Identify the data items or messages coming into the system
and going out and describe the purpose of each. Describe the services needed and the nature
 of communications.
5. Processor Type: Dual Core
6. Speed: 2.4 GHz
7. RAM: 2 GB
8. HDD: 100 G

5.2 RISK MANAGEMENT W.R.T. NP HARD ANALYSIS

5.2.1 Risk Identification

Table 5.2.1: Risk Identification

Sr. Questions Yes No

No

1. Have top software and customer managers

formally committed to support the project?

2. Are end user enthusiastically committed to

the project and the system/product to be
built?

3. Are Requirements fully understood

by the software engineering team
and its customers?

4 Have customers been involve fully in the

definition of requirement?

5. Do end user have realistic expectation?

6 Does the software engineering team have

the right mix of skills?

7. Are the project requirement stable?

8. Is the number of people on the project
team adequate to do the job?

9. Do all the customer/user constituencies are

agree on the importance of project and
requirements of system to be built?
 5.2.2 Risk Analysis

The risks for the Project can be analyzed within the constraints of time and quality

Table 5.2.2: Risk Table

ID Risk Description Probability Impact

Schedul Overall Quality
e
1 The issue which is sending by
user will not processed further Low Low High Low
authorities.
2 User sending problems are not Low High Low Low
solved.

Table 5.2.3: Risk Probability Table

Probability Value Description

High Probability of occurrence is > 75%
Medium Probability of occurrence is 26 75%
Low Probability of occurrence is < 25%

Table 5.2.4: Risk Impact Defination

Impact Value Description
Very high > 10% Schedule impact or Unacceptable quality
High 510% Schedule impact or Some parts of the project have low
quality
Medium < 5% Schedule impact or Barely noticeable degradation in qua
ity Low Impact on Quality can be incorporated
5.2.3 Overview of Risk Mitigation, Monitoring, Management

Following are the details for each risk.

Risk ID 1

Risk The issue which is sending by user it will not proceed

Description further

Category Java

Source Software requirement Specification

document.

Probability Low

Impact High

Response Mitigate

Strategy Data will be send to authorities

Risk Status Occurred

Risk ID 2
Risk Description User sending problems are not solved
Category Correct report generation for solving
problem
Source Software Design Specification
documentation review.
Probability Low
Impact High
Response High
Strategy Better testing will resolve this issue.
Risk Status Identified

5.3 PROJECT SCHEDULE

5.3.1 Project task set

 Major Tasks in the Project stages are:

Task 1: Analysis on Requirement of user.

Task 2: Designing the project plan.

Task 3: Perform Requirement gathering and start development of system

Risk ID 3
Risk Description When user send images that time network error will occure

Category Wi-Fi
Source This was identified during early development and testing.

Probability Low
Impact Very High
Response Accept
Strategy Network connection will disconnect while sending data

Risk Status Identified

Task 4: After Development the testing will be performed

Task 5: If no error will occure then system will correctly implement and deployment
and maintainance will performe
5.3.2 Task network
5.3.3 Timeline Chart

Table 5.3.3 : Timeline chart

5.4 TEAM ORGANIZATION

5.4.1 Team structure

Team members work will be divided that is one team member will gather the
requirement of system
Second team member will analysis that requirement gathering.
Third member will start development and testing.
Fourth member will perform deployment and maintainance of system.

5.4.2 Management reporting and communication

 Table 5.4.2: Progress of System/Project

Sr.no Progress Modules Checked

1 Module 1 1st week of
January
2 Module 2 4th week of
January
3 Module 3 2nd week of
February
4 Module 4 4th week of
February
5 Module 5 2nd week of
March
 CHAPTER 6
SOFTWARE REQUIREMENT
SPECIFICATION
6.1 INTRODUCTION

1) Purpose and Scope of Document

The purpose of SRS is to be that it provides the all software

and hardware requirements with their scope
It also provide the hardware and software interface with
overall description with product scope
Cost estimation and timeline estimation with chart also
provide by the SRS.

2) Responsibilities of Developer

The developer is responsible

for developing a software

Developer is also responsible

for gather the requirement and
as per the user requirement the
software will be developed.

Developer must design the

software without error.

Developer is responsible for

perform the coding operation
in appropriate manner.

6.2 USAGE SCENARIO

6.2.1 User profiles

Normal User

The normal user is login into system and sending their issue or problem in the
format of image or video.

Government Employee

The government employee will generate the report as per the issue and solve the
 problem.

Media Employee

This media will display the generated report of government on the television.This
onlu perform when the government authorities will not work on that issue.

Google API Map

This is performed the location tracking. That is where it from user sending their
problems or issue.

MongoDB

This MongoDB is used to generate the database online. Used to display the
report in database format

6.2.2 Use-cases

Table 6.2 : Use Cases

Sr. No Use Case Description Actor Assumption

1 Login User login on to system after Normal user The user will login
registration successfully.
2 Submit Issue User send their problem in Normal User Problem
image format. and Google successfully
API Map submitted to system
with their location.
3 Monitor Issue Issue will be monitor by Government Perform analysis on
authorities Employee issue
4 Solve Issue The issue will be resolved Government Solve issue
Employee
5 Report generate Generation of report will be Government Generation of
performed. Employee and Report
MongoDB
6 Logout After Submitting issue the user Media Feedback is
will be logout. Employee and provided to user.
Government
Employee
 6.2.3 Use Case View

Fig. 6.2 : Use Case Diagram

6.3 DATA MODEL AND DESCRIPTION

6.3.1 Data Description

User
The user will register on the system and after registration the logid id and password will
provide to user.
 Image

User will sending their issue in the image format to authorities.

Report_Submitted to

The report will be submitted to authorities for resolve their issues.

Report

The report will generated on respected Issue using Database.

Registration_Type

The user will be register on local network or through wireless system.

Department

There are higher and lower authorities which solved the user issue.

6.3.2 Data objects and Relationships

 Fig. 6.2.3 : E-R Diagram

6.4 FUNCTIONAL MODEL AND DESCRIPTION

6.4.1 Data Flow Diagram

1) Level 0 Data Flow Diagram

2) Level 1 Data Flow Diagram

3) Level 2 Data Flow Diagram
6.4.2 Activity Diagram
 Fig. 6.4.2 : Activity Diagram

6.4.3 Non Functional Requirement

Performance Requirements
The system being under development works under the principle of
Adaptive Image Contrast Technique. So as to develop a Contrast Image of given Image, the time required
may be differ according to the input given as image.The time required for construction may be different
from system to system depending upon the hardware configuration of the system or computer.
Safety Requirements
No Safety Requirements have been identified for the system being yet
developed.
Security Requirements
Due to some of the application areas of the system being developed, the security
of the system being is of paramount importance. There are user classes which might be using this project on some
confidential document images.
For this purpose, we have made use of inbuilt features of .NET Framework.
The .NET framework provide many useful classes and services that enable developers to easily write secure
code and enable system administrators to customize the permissions granted to code so that it can access
protected resource.In addition, the runtime and the .NET Framework provide useful classes and services that
facilitate the use of cryptography and role-based security.
Software Quality Assurance
 1) Security
We can provide the authentication to the system through user id, password.

Each user can only have the information that is efficient for his/her day to day working using his own id

and password. It makes the system more secure.

2) Reliability

This system is reliable as it easily retrieves all data from pdf and store in

database without any error or inconsistency and noise in data. So user can easily perform operations on

that data and can retrieve the data form the database.

3) Performance

The performance of proposed system is higher in peaceful environment and

with proper input from the user. All the work of exam section is now automatically done through the

proposed system. Every time it will give you correct information when you want it from system.

4) Maintainability

The system Exam Section Simplifier is more efficient to maintain as it requires

less efforts to sustain its workflow and structure.

5 )Compatibility

This application is compatible with system that has configuration which is

mention in the requirement.

6) Testability

Using various testing approaches, proposed system can be easily tested for verification

of system that whether it satisfies all user requirements or not.

6.4.4 State Diagram:

 Fig. 6.4.4 : State Chart Diagrams

6.4.5 Design Constraints

Submit Issue
This constraint will impact on other subsystem. If this constraint is contain fake
images then the problem will not solved and incorrect report will be generated.
MongoDB
This database is created online on the system. If this database is not used then it
gives the report generation will fail.
Reports
If the generated reports are incorrect then the solution of problem is not found.

6.4.6 Software Interface Description

1 ) Software Interface

To describe the logical and physical characteristics of each specific

software
components (name and version),including databases, operating system, tools, libraries, and
integrated Commercial components. Identify the data items or messages coming into the system
and going out and describe the purpose of each. Describe the services needed and the
nature of communications.

1) Processor Type: Dual Core

2) Speed: 2.4 GHz
3) RAM: 2 GB
4) HDD: 100 G
 CHAPTER 7

DESIGN AND DOCUMENT

USING APPENDIX A AND B

7.1 INTRODUCTION
Hazard reporting is an android application which is really useful for the people who want to
do something for their society. Using this application the user need to capture real time images of hazardous objects with
their location and sync it with the server. The data captured from android will be shown on Google

Maps using Google Maps API v3. This data will be available to corresponding departments of
government. In existing system, people do not have any central platform where they can report all their issues. So
government does not understand the exact problem and their location. In Proposed system, we are developing one central
platform where all issues can be reported with their location to respective departments. The objective of the system is to
send the images, audio or video related to issue to the respective departments of the governments. The user sending this
using the web services and android device. Using this system, we can keep track of the ratio of complaints registered and
issues which are unsolved

7.2 ARCHITECTURAL DESIGN

This architecture shows overall description of our system.We need at least one android
mobile device and a dedicated server to host the application. Dedicated Server is used tostore the data. Dedicated server
should have MongoDB installed on it to handle the database part. We are using dedicated server for good performance In
android development we are designing the database using SQlite.
 Fig. 7.2 : System Architecture

7.3 DATA DESIGN (USING APPENDICES A AND B)

7.3.1 Internal software data structure

Dedicated Server
Used for storage and process of data.

MongoDB
Used to create the online database for report generation.

Web GIS
Used for data conversion and integration.
7.3.2 Global data structure

Sending data from cellular phone

Using cellular phone we will send the issue to authorities through internet

7.3.3 Temporary data structure

After providing the feedback to user the report should be deleted because the
solution of probem is found.

7.3.4 Database description

MongoDB
MongoDB (from humongous) is a cross-platform document-oriented database.
Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favor
of JSON-like documents with dynamic schemas , making the integration of data in certain types of applications easier and
faster.
 MongoDB is developed by MongoDB Inc. and is published as free and open-
source software under a combination of the GNU Affero General Public Licenseand the Apache License. As of July 2015,
MongoDB is the fourth most popular type of database management system, and the most popular for document stores.
MongoDB feature are:

1. Document-oriented

Instead of taking a business subject and breaking it up into multiple relational structures, MongoDB can store the
business subject in the minimal number of documents. For example, instead of storing title and author information in two
distinct relational structures, title, author, and other title-related information can all be stored in a single document called
Book.

2. Ad hoc queries

MongoDB supports field, range queries, regular expression searches. Queries can return specific fields of
documents and also include user-defined JavaScript functions.

3. Indexing

Any field in a MongoDB document can be indexed including within arrays and embedded documents (indices in
MongoDB are conceptually similar to those in RDBMSes). Primary and secondary indices are available.

4. Replication

MongoDB provides high availability with replica sets.[6] A replica set consists of two or more copies of the data.
Each replica set member may act in the role of primary or secondary replica at any time. The primary replica performs all
writes and reads by default. Secondary replicas maintain a copy of the data of the primary using built-in replication. When
a primary replica fails, the replica set automatically conducts an election process to determine which secondary should
become the primary. Secondaries can optionally perform read operations, but that data is eventually consistent by default.

5. Load balancing

MongoDB scales horizontally using sharding. The user chooses a shard key, which determines how the data in a
collection will be distributed. The data is split into ranges (based on the shard key) and distributed across multiple shards.
(A shard is a master with one or more slaves.). Alternatively, the shard key can be hashed to map to a shard enabling an
even data distribution.

MongoDB can run over multiple servers, balancing the load and/or duplicating data to keep the system up and
running in case of hardware failure. MongoDB is easy to deploy, and new machines can be added to a running database.
 7.4

COMPOENT DESIGN

7.4.1 Class Diagram

 Fig. 7.4 : Class Diagram

CHAPTER 8

PROJECT IMPLEMENTATION
8.1 INTRODUCTION
Hazard reporting is an android application which is really useful for the people who want to
do something for their society. Using this application the user need to capture real time images of hazardous objects with
their location and sync it with the server. The data captured from android will be shown on Google

Maps using Google Maps API v3. This data will be available to corresponding departments of
government. In existing system, people do not have any central platform where they can report all their issues. So
government does not understand the exact problem and their location. In Proposed system, we are developing one central
platform where all issues can be reported with their location to respective departments. The objective of the system is to
send the images, audio or video related to issue to the respective departments of the governments. The user sending this
using the web services and android device. Using this system, we can keep track of the ratio of complaints registered and
issues which are unsolved

8.2 TOOLS AND TECHNOLOGIES USED

WATP 8.5 Tool
Wireless Technology
 8.3 VERIFICATION AND VALIDATION FOR ACCEPTANCE

Verification and validation are independent procedures that are used together for checking
that a product, service, or system meets requirement and specification and that it fulfill its intend purpose. These are critical
components of a quality management system such as ISO 9000.
The words verification and validation are sometimes protected with independent( or IV
and V) , indicating that the verification and validation is to be performed by a disinterested third party.Verification and
validation ( V and V) is the process of checking that a software system meets specification and that it fulfills its intended
purpose. It is normally the responsibility if software testers as part of the software development lifecycle.

CHAPTER 9

SOFTWARE TESTING

9.1 TYPE OF TESTING USED

1) Unit Testing
Unit testing, also known as component testing, refers to tests that verify the functionality of a
specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level,
and the minimal unit tests include the constructors and destructors.
Unit testing is a software development process that involves synchronized application of
a broad spectrum of defect prevention and detection strategies in order to reduce software development risks, time, and
costs. It is performed by the software developer or engineer during the construction phase of the software development
lifecycle. Rather than replace traditional QA focuses, it augments it. Unit testing aims to eliminate construction errors
before code is promoted to QA; this strategy is intended to increase the quality of the resulting software as well as the
efficiency of the overall development and QA process.
2) Verification and Validation Testing
Verification and validation are independent procedures that are used together for checking that
a product, service, or system meets requirement and specification and that it fulfill its intend purpose. These are critical
components of a quality management system such as ISO 9000. The words verification and validation are sometimes
protected with independent( or IV and V) , indicating that the verification and validation is to be performed by a
disinterested third party.Verification and validation ( V and V) is the process of checking that a software system meets
specification and that it fulfills its intended purpose. It is normally the responsibility if software testers as part of the
software development lifecycle.

3) System Testing
System testing of software or hardware testing conducted on a complete, integrated
system to evaluate the system compliance with its specified requirement. System Testing falls within the Scope of blackbox
testing, and as such , should require no knowledge of the inner design of the code or logic. System testing, or end-to-end
testing, tests a completely integrated system to verify that it meets its requirements.For example, a system test might
involve testing a logon interface, then creating and editing an entry, plus sending or printing results, followed by summary
processing or deletion (or archiving) of entries, then logoff
4) Integration Testing

Integration testing is the phase in the software testing in which individual software modules
are combined and tested as group. Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be integrated in an iterative way or all together
("big bang"). Normally the former is considered a better practice since it allows interface issues to be located more quickly
and fixed. Integration testing works to expose defects in the interfaces and interaction between integrated components
(modules). Progressively larger groups of tested software components corresponding to elements of the architectural design
are integrated and tested until the software works as a system.

5) Regression Testing
Regression testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, as degraded or lost features, including old bugs that have come back.
Such regressions occur whenever software functionality that was previously working correctly, stops working as intended.
Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the
software collides with the previously existing code. Common methods of regression testing include re-running previous
sets of test-cases and checking whether previously fixed faults have re-emerged.
Regression testing is typically the largest test effort in commercial software development, due to
checking numerous details in prior software features, and even new software can be developed while using some old test-
cases to test parts of the new design to ensure prior functionality is still supported.
 9.2 TEST CASES AND TEST RESULTS

Table 9.2: Test Cases

Case Test Case Test Case Input Actual Expected

output
Name Description Output

1 App Android app on Capture images Sent to the Action on Hazard

mobile &videos Server problems

2 Server Classification of Take images Classify Real Problem

images & Videos &Videos from images & Images from user
User videos with
MNC action
Problem or
Not

3 MNC Real action Server Images MNC Take Clear all problems
Problem Action

4 Higher Suppose MNC not Server Images Higher Clear Real cities
take action then Authority problem
Authority
Images sent to the Take Action
Higher Authority

5 Media If Both of them are Images And Media Create When media create
not taking Action Videos the issues the issues then
MNC work
properly
 CHAPTER 10
RESULTS

10.1 SCREEN SHOTS

Fig. 10.1.1 : User Registration Form

The Fig.9.1.1 shows registration form of user where the user will be filled all the details
and after filling the detail the user login id and password will be created.

Fig. 10.1.2 : User Login Form

Fig.9.1.2 shows the login form of user side. The password and login id will be
provided to user from where the user will be send their issues or problem to the system.
 Fig. 10.1.3 : User Inbox After Login

Fig. 9.1.3 shows the User inbox where the

options are available that is what type of
problems send the user, problem is solved or not and how many reports the user will be send.

Fig. 10.1.4 : User Report To Hazard

Fig.9.1.4 shows the user will send their issues or problem in the format of image or video
with the title and image/video description.
 Fig. 10.1.5 :
Authorities Registration
On System

Fig.9.1.5 shows the registration form of authorities where to authorities have to register
to the system. After Registration the login id and password will be created.

Fig. 10.1.6 : Authorities Login Form

Fig.9.1.6 shows the login form of authorities where the login id and password will be provided.
After login the authorities will see the generated reports which is send by user.
 Fig. 9.1.7 : MongoDB Database Connectivity

Fig.9.1.7 shows the connectivity of database. By using this Database the Report will be
generated.

Fig. 9.1.8 : Submitted Report To Authorities

Fig.9.1.8 Shows the report generation of problems/issue which send by user.This reports will
help to authorities to where the problem will be occur, shows the location and also give the status that
the problem is completely solve or not.
 CHAPTER 11
DEPLOYMENT AND MAINTENANCE

11.1 INSTALLATION AND UN-INSTALLATION

11.1.1 JAVA
The target of java is to write a program once and then run this program on
multiple operating system. Java has the following properties:
Platform Independent: Java programs use the java virtual machine as abstraction and do not
access the operating system directly. This makes java programs highly portable. A Java programs
(which is standard-complaint and follows certain rules ) can run unmodified on all supported platform,
e.g., Windows or Linux
Object-Oriented Programming Language: Except the primitive data type, all elements in java are objects.
Strongly-Typed Programming Language: Java is strongly-typed, e.g. the types of the used variable must
be predefined and conversion to other objects is relatively strict, e.g., must be done in most cases by
the programmer.

11.1.2 MongoDB
MongoDB (from humongous) is a cross-platform document-oriented database.
Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure
in favor of JSON-like documents with dynamic schemas , making the integration of data in certain types
of applications easier and faster. MongoDB is developed by MongoDB Inc. and is published as
free and open source software under a combination of the GNU Affero General Public License and the
Apache License.
As of July 2015, MongoDB is the fourth most popular type of database
management system, and the most popular for document stores

11.2 USER HELP

The user help is nothing but there is something is which
 is not understand by User.

This provide online help option to user where the user

will enter there query and the number of helping option
will be provided to that user.

This help option gives the solution of user query.

This also gives the more option with the steps to be

taken.
 CHAPTER 12
CONCLUSION AND FUTURE SCOPE

12.1 Conclusion

This system will help authorities to mark the area with more no of issues. This app will
send notification and messages according to risk level. There is also a hall of mark page where a person
whose max cases are genuine and solved and authority that is doing well in solving it will be awarded with
hall of mark.
Thus we look forward to develop an android application for both users and authorities and
a web application using JSP and servlet for authorities with MongoDB as backend.

12.2 Future Scope

The future scope of this project is provide the cleanliness of city or world.
It provide the no garbage on the roads or anywahere in future.
The authorities are doing there work correctly.
The social awareness in the people are improve.
By using this system the diseases are reduced because the garbage is nt anywhere
and it is in there proper position i.e. dustbean.

CHAPTER 12
 CONCLUSION AND FUTURE SCOPE

12.1 Conclusion

This system will help authorities to mark the area with more no of issues. This app will
send notification and messages according to risk level. There is also a hall of mark page where a person
whose max cases are genuine and solved and authority that is doing well in solving it will be awarded with
hall of mark.
Thus we look forward to develop an android application for both users and authorities and
a web application using JSP and servlet for authorities with MongoDB as backend.

12.2 Future Scope

The future scope of this project is provide the cleanliness of city or world.
It provide the no garbage on the roads or anywahere in future.
The authorities are doing there work correctly.
The social awareness in the people are improve.
By using this system the diseases are reduced because the garbage is nt anywhere
and it is in there proper position i.e. dustbean.

12.3 Summery
We can understand that what should we implement this system and how it is
helpful for people.
 ANNEXURE A AND REFERENCES

[1] Web-Based GIS System for Real-Time Field Data Collection Using a Personal Mobile Phone

Ko Ko Lwin, Yuji Murayama Graduate School of Life and Environmental Sciences,University of

Tsukuba, Tsukuba, Japan Received June 18, 2013; revised July 25, 2013.

[2] S. Mouro and K. Okadata, Mobile Phone as a Tool for Data Collection in Field Research,

World Academy of Science, Engineering and Technology, Vol. 70, 2010, pp.222-226.

[3] University of Washington, Cell Phones Become Handheld Tools for Global Development,

Science Daily, 2009. http://www.sciencedaily.com/releases/2009/10/09102914 1249.html

[4] K2008, pp. Moe, B. Dwolatzky and R. Olst, Designing a Usable Mobile Application for Field

Data Collection, IEEE AFRICON,. 1187-1192.

[5]. K. K. Lwin and Y. Murayama, Personal Field Data ColK. lection by UM-FieldGIS

(UMPC, UltraMobile PC and Embedded Google Map API), Proceedings of the 16th Annual Meeting of

GIS Association of Japan, Hokkaido University, 20-21 October 20

ANNEXURE B
 LABORATORY ASSIGNMENTS ON
PROJECT ANALYSIS OF
ALGORITHMIC DESIGN

NP Hard And NP Complete

It is non-deterministic problem developed by S.A.Cook.

This non-deterministic problem gives the set of solution of given problem.

Two types of NP-Problem as follows:-
1) NP-Complete(SAT) Problem-Satisfiability
2) NP-Hard Problem
We Compare our project with NP-Complete and NP-Hard Problem as follows:-

NP-Complete
The NP-Complete problem gives the satisfaction of result or satisfiable result.
Our project is hazard system that is it gives the result. We capture the images and send that images to
the server at that time the problem will occur that is NP-Problem.
Each user should get the satisfiable result and problem should be resolvable. At that time our system
gives the result at some given time or polynomial time.
We sure that our system will definitely produce the result after some time it is called NP-Complete
(SAT) problem.From above statement we say that

P C
Relationship
NP between P and NP
NP = Non-Polynomial
P = Polynomial

NP
NP-Hard Problem
It is not NP-Complete Problem.It is also called halting stage.

The halting stage state that Is it possible to determined the whether an algorithm will ever halt
or enter in loop on certain input.

Relationship between P and NP-Complete in NP-Hard

 NP-
Compl
P
ete

The NP-Hard problem gives the solution in some set of problem but after some time it
gives error or going to halting stage and we find out that we are not get back the solution of this problem.
If suppose our system have to be take the images from user or user sends the images to server at that time
server have the maximum load and it gave the result not properly and we see that the server not giving
feasible solution.
After some time the condition is occurred that is we are sending Images continuously
and server have the maximum load and server will go slow down. then it does not taking images and it gives
an error. If we are sending images after giving error at that time server will go into halting stage and does
not giving any response. It will be stop.

Relationship between P, NP, NP-Complete and NP-Hard

ANNEXURE C
 LABORATORY ASSIGNMENTS ON
PROJECT QUALITY AND
RELIABILITY

Testing of Project
Testing is the set of activities that can be planned in advanced and
conducted systematically. A strategy for software engineering testing may be viewed in context of spiral
model. Testing in an investigation conducted to provide stakeholders with information about the quality of
the product or services under test.
A test plan is the document detailing a systematic approach to testing a systemsuch as machine or software.
The plan typically contain a detail understanding of what eventual workflow will be. Test plan document is
the strategy that use to verify and ensure that a product or system meet its design specification or by
significant input from test engineers. Depending on the product and the responsibility of the organization
to which the test plan applies, the test plan include one or more or the following:
1) Design verification and the compliance test to be performed during the development or
approval stages of the product, typically on a small samples of unit.
2) Manufacturing or production test to be performed during preparation or assemble
of the product in ongoing manner for purpose of performance verification and quality control.
3)Acceptance and commissioning test to be performed at the time of delivery or installation
of product.
4) Service or repair test to be performed as required over the service life of the product.
5) Regression test to be performed on an existing operational product, to verifythat
existing functionality did not get broken when other aspects of the environment are changed
( e.g. Upgrading the platform on which an existing application runs).

Mathmatical Model

1)Location = {L1,L2,.Ln}
2)Server = {S1,S2,.Sn}
3)Department = {D1,D2,.Dn}
4)Media = {M1,M2,.Mn}

Venn Diagram:


Functional Diagram:


Fig. Annexure C: Mathematical Model

Set of inputs: {I1 , I2}

I1= Firstly new user login with the help of User_id And Password.

I2=Take Original general issues photos or videos and send to the server.

Set of Functions: {F1,F2,F3,F4,F5,F6,F7}

F1=Check valid user or not if valid then send message to the user login successful.

F2=Server get input photos from user.

F3=Classification is perform on photos because it is check to the user send photos

is match with server saved photos of issues.

F4=After the image classification report get generate.

F5=Send this created report to the Municipal corporation

F6=Any action related message Department then stop otherwise send report to the

Higher Authority.

F7=After 2 days all photos send to the Social Media.

Set of Outputs: {O1,O2,O3}

O1=Action taken by municipal corporation on this issues.

O2=Action taken by Higher Authority .

O3=Last media to show all this issues and media creates the issue all this things.

ANNEXURE D

PROJECT PLANNER
 Project Plan
A project plan, according to the Project Management Body of Knowledge,

isa formal, approved document used to guide both project execution and
project control.
The primary uses of the project plan are to document planning assumptions and
decisions, facilitate communications among stakeholders, and document approved
scope, cost, and schedule baselines. A project plan may be summarized or detailed.

Task Months and Year Schedule Task Name

ID
(Weeks)

1 June 2015 All Registration of project group

2 July 2015 1st and 2nd Idea about project selection/Project topic selection

3 July 2015 3rd and 4th Submission of project synopsis/Abstract

4 July 2015 5th Guide allocation and Literature survey

5 August 2015 1st To display list of project groups with guide name

6 August 2015 2nd First presentation with the guide about idea of project
(feasibility study)

7 August 2015 3rd and 4th Requirement analysis(SRS Document) preparation and
submission

8 September 2016 1st and 2nd Design of project-Low Level,High Level, Datastuctures,
Database Tables and Algorithms

9 September 2016 3rd Presentation 2 with design

10 September 2016 1st Submission of the partial report of the project

11 October 2016 2nd University exam on partial report

12 January 2016 1st Coding

13 January 2016 2nd At least two modules should finish(30%) total work

14 February 2016 1st First demonstration on project work expected(60%) of

total work

15 March 2016 1st and 2nd Test plan , design, and installation

16 March 2016 3rd Final Project Demonstartion

17 March 2016 4th Preparation of project report,preparable project and manual

18 March 2016 1st Submission of project report(Final Submission) and project

work book to project coordinator

19 May 2016 2nd Final University Exam

 ANNEXURE E

REVIEWERS COMMENTS

OF PAPER SUBMITTED

1. Paper Title:

Hazard Object Report To Respective Authorities.

2. Name of the Conference/Journal where paper submitted :

Imperial Journal Of Interadisciplinary Research

3. Paper accepted/rejected :

Accepted.

4. Review comments by reviewer :

 1) The paper contents are correctly defined
2) The Paper also contain the result set that is input and output of system with the
screenshots.
3) In the paper the conclusion and future scope defined appropriately for future
use.
4) The paper has detailed description about the project or system

5. Corrective actions if any :

No
 ANNEXURE F

PLAGIARISM REPORT

ANNEXURE G
TERM-II PROJECT
 LABORATORY
ASSIGNMENTS

Participated Certificate
1) MET National Level Project Compitition

2) MCOERC State Level Project Compitition

Installation Software
1) Programming Language : JAVA

2) Database : MongoDB

Interfaces and GUI

1) The interface is used for communication between the
process which perform by the system.

2) The GUI is used for graphical representation of project

i.e the images are provide in background in the system.

Reliability Testing
The reliability testing is used for to check the system is
reliable for use or not.The system should be work
properly without any defect and when the defect will
occure then the system is not reliable.Systm should be run
correctly and each and every function gives the correct
output of each input.

ANNEXURE H

INFORMATION OF PROJECT
 GROUP MEMBERS

1. Name : Kothule Dhanashri Kailas PHOTO

2. Date of Birth : 25 June 1994

3. Gender : Female

4. Permanent Address : At post Pimpalnare,Pimpalgaon,Nashik

5. E-Mail : dhanashrikothule47@gmail.com

6. Mobile/Contact No. : 9921753527

7. Placement Details : No Placement

8. Paper Published : IJIR Publication

1. Name : Sonone Vaibhav Punjaji

2. Date of Birth : 2 September1994 PHOTO

3. Gender : male

4. Permanent Address : Pachore, Akola

5. E-Mail : sononevaibhav71@gmail.com

6. Mobile/Contact No. : 9890090264

7. Placement Details : No Placement

8. Paper Published : IJIR Publication

1. Name : Sonawane Jayashri

2. Date of Birth :

3. Gender : Female
PHOTO
4. Permanent Address : Amrutdham,Nashik

5. E-Mail :

6. Mobile/Contact No. : 917554906

7. Placement Details : No Placement

8. Paper Published : IJIR Publication

1. Name : Jadhav Riya Sanjay

2. Date of Birth : 20 February1995

3. Gender : Female

4. Permanent Address : Amrutdham,Nashik

5. E-Mail : riajadhav15@gmail.com

6. Mobile/Contact No. : 9423278600

7. Placement Details : No Placement

8. Paper Published : IJIR Publication