Crime Reporter

7/28/2019 Crime Reporter

1/90

1

CHAPTER 1

INTRODUCTIONA journey of a thousand miles must begin with a single step.


2/90

2

1. Introduction

The target system is designed to provide a complete solution for mobile users to make

the society secure and safe using their mobile phones. It takes an initiative for providing

a facility to mobile users to report crime to the police at the time when it is happening

and also informs them about location where it is going on. The customers who would

use this application would not have to go to the police station or dial 911(100 in India) to

call police but instead use this application.

1.1 Need for System Development

Problem:

Crime goes under-reported all around the world. There are many reasons for it. For

instance, many times the victims and witnesses are afraid that the offender will come

after them, seeking revenge or the police would involve them too much into

investigation. Other times the witnesses are too lazy to go up to the police station to

report crime. So this application is designed for such people who are afraid and lazy. It

is also of great help to Police to catch the right offender making investigation really

easy.

Solution:

Here, mobile users have to click a photo of a crime scene that is going on from

wherever they are. This application connects the server, meant for police to view, to the

mobile phone. The mobile user can upload this picture on the server with or without a

description. As soon as this photo gets uploaded, the application uses GPS technology

to track the place where crime has taken place to upload it onsite to help the cops to

reach at the right place.

With the help of this server, it will become really easy for the Police department to track

the offender because a snapshot of a crime going on reveals almost everything.


3/90

3

CHAPTER 2

EXTENSIVE TECHNICAL RESEARCH

He who does not research has nothing to teach


4/90

4

2. Extensive Technical Research

2.1 Android as a Ubiquitous System

The primary principle behind all ubiquitous applications is to provide the users with

intelligent learning systems that supplement their everyday activities. This is the primary

consideration on which a ubiquitous application can be evaluated.

Consider a world where desktop computers are replaced by embedded computers

in typical physical objects, without interfering with the current functionality of those

objects. That is what Weisers vision was, and he termed it ubiquitous computing. The

computers would be small enough to be embedded within the object and will provide

enhancement to the functionality of object.

The requirements of a ubiquitous system have been classified in three categories:

system, software, business and organization. System refers to the platform i.e. the

hardware of the system, or the system running the subject software on top of it. The

term software represents the services and the components of system that have been

derived from the ubiquitous system. Business refers to the actors who are

providing the components and services for the development of the system.

Organization includes development methods and the processes needed for thedevelopment and integration of the system services.

2.2 Feature Implementation in Android

Interoperability: Content Provider handles it

Heterogeneity: Core libraries and Android Runtime handle it. It also includes

components like window manager, view systems, and telephony manager etc.

Mobility Activity Manager handles it Survivability Survival by protection is

achieved by Linux at core and SSL layer in middle-ware, giving an excellent

security mechanism.

Adaptability: Resource Manager and Package Manager provide the system

with information to encourage reusability of components.

Self-Organization: Notification Manager, XMPP Service and Location Manager


5/90

5

take up the responsibility to make system self organized and context aware.

Augmented Reality and Scalable content OpenGL, Linux kernel and proven

driver model of Linux makes it possible to implement such applications.

Implicit Interaction: Location Manager, and Linux driver model makes it possible

for system to interact implicitly with user

Task-based Interaction: Notification Manager, Activity Manager makes task

based interaction possible.

2.3 Android Architecture

Figure 1: android architecture


6/90

6

2.4 Survivability

Android has achieved the survivability by protection mechanism in itself, since the

architecture is based on LINUX; which has over the time, proven itself to be among the

league of secure operating systems. So at the bottom level SELINUX is taking care

of operating system level security. However, the intercommunication security has

been achieved by building in the SSL component. By using more secure

communication mechanisms the two devices

communicating via any device driver in kernel can use the security mechanisms

to ensure that there is no intrusion in the system. By restricting invalid or

unknown intrusion from any entity the system has made itself secure at operating

system level and communication level as well.

2.5 Component Types

Android defines four component types:

Activity components define an applications user interface.

Service components perform background processing.

Content provider components store and share data using a relational

database interface. Each content provider has an associated authority

describing the content it contains.

Broadcast receiver components act as mailboxes for messages

from other applications.


7/90

7

2.6 Literature Survey

The current technology for surveillance in public places that is being widely used is

Closed Circuit Televisions (CCTVs). This technology has found its use in widespread

public locales such as buildings, malls, shops, office buildings, etc. This technology can,

in some ways be compared to our target system with some glaring differences. For

example, the basic cost of a single CCTV camera unit ranges from anywhere between

Rs.850 and Rs.70000. thus it is rather expensive to install and maintain such cameras

in all the nooks and corners of a city as large as Pune. Another problem with such

cameras is detecting a red flag (a breach of security) will entail the monitoring of all

such cameras throughout the day. On the other hand, with the steep advent in the smart

phone market, the price of the technology is falling everyday and affording a phoneequipped with Android OS (compulsory for using the suggested system) is becoming

more and more possible for the general public. Also, in the case of organized crime,

CCTV cameras can be easily manipulated, and sometimes, more easily disabled by

snipping some wire. The response time for crimes in shops etc, depends on the

technology used in the CCTV camera, with some having live streaming features, but

most, due to financial problems, recording to a personal hard disk which can, as we

know, be manipulated easily. Also, for now, the criminals fear only the designated

enforcers of law, like the Police. However this technology being provided to the general

public will make the criminals look over their shoulder more often and fear people from

the general public as well. This can only improve the assurance among the general

public while doing otherwise to that of the potential criminals. The pros and cons in this

comparison are many but it is our belief that with criminals becoming more and more

technologically aware, the security measures taken to prevent such crimes need to be

new and innovative and constantly surprising the criminals or scaring away potential

criminals to be effective in their primary aim.


8/90

8

Following are some softwares which are available in the market based on similar

concept as Crime Reporter:

1. CRUSH

Reduction Utilizing Statistical Criminal History (Crush), an IBM

software technology which is now used by British police to predict future crimes, any

preventive action. Systems of this technologyto evaluate past and current events, and

then combine that information with a variety of data including crime

reports, intelligence briefings, profiles of actors, even the weather forecast. Through

data collection from the police's, Crush software technology will predict data based on

past and present. The result will be obtained which can predict the crime report. These

data not only based on the type and location of crime incidents, but also based on time

such as hours and certain days.

Software technologyhas this crush tested in Memphis, Tennessee. The result, overall

crime can be reduced by approximately 31%, while the physical crime around 15%.

Investment making this software alone reached U.S. $ 11 billion.

2. SPOTCRIME

At SpotCrime, we often request data from police departments that have purchased

crime mapping systems. Ostensibly, these crime maps displayed on the Internet are

intended to distribute crime information to the public, but at this current time, almost

every vendor that is contracted to map crime puts restrictions on access. When we

inform the police department that there are restrictions on access, about 50% of the

time we find out that the department was not aware their vendor had restrictions

preventing the press from republishing data. A good majority of the time, we are able to

access the data directly from the records system.

The other 50% of departments abdicate responsibility to the vendor as if they are not


9/90

9

responsible for the vendor they have contracted with to deliver public information.

Forgive the pun, but this is a cop out. If you are contracting with a company to deliver

public information to the public, shouldn't you be responsible for the vendor that puts

restrictions on what the public can and can't do with the data? And since the rules of

access are lengthy, why doesn't any police department take the time to discuss the

restrictions with the public when they send out releases about the new crime mapping

system?

Crime alert has taken motivation from the above products and is tring to built a system

capable of using the features of spotcrime to show the crime areas to police instead of

user and takes input from user instead of police. The future enhancement of this project

could be similar to crush, thus predicting future crime spots using the data available in

the database.

3. WIKICRIMES.ORG

WikiCrimes was founded by Professor Vasco Furtado of the University of Fortaleza.

Professor Vasco took a look around him and realized, Brazil has a lot of crimes and little

accountability. The police are generally feared or distrusted, and crime reporting is

sparse, so access to data is hard to come by. Vasco designed the site with this

unfortunate fact in mind, But he also relied on the realization that reports of crime are

best spread by word of mouth. Using WikiCrimes is easy. Its essentially a wiki map.

You can zoom in and put a marker on the Brazilian street you were robbed or you can

simply take a look at where not to go the next time youre in Brazil. If you do the former,

WikiCrimes will ask you to fill out a series of questions like if th e criminal was armed or

not. So the next time youre robbed in Brazil, you know what to do.

Crime Reporter is an application motivated from two of the above three web

applications, i.e., Spotcrime and wikicrimes. To make this application handy, it is made

as a mobile application instead of web application. Unlike spotcrime, crime reporter


10/90

10

shows a crime map to the police department instead of citizens. In wikicrimes.org,

people send a detailed description of crime that they witness to the server. Thus in the

same way in Crime Reporter, people send description of the witnessed crime to the

server (owned by police department), in the form of a picture along with the details of

time and place. What makes it different from wikicrimes is that, it is handy and sends

message to the police in a very speedy manner so that they can come to the crime spot

as soon as possible.


11/90

11

CHAPTER 3

PROJECT PLAN

No matter how carefully you plan your goals they will never be more than pipe dreams

unless you pursue them with gusto.


12/90

12

3. Project Plan

3.1 Purpose

Crime goes under-reported all around the world. There are many reasons for it. For

instance, many times the victims and witnesses are afraid that the offender will come

after them, seeking revenge or the police would involve them too much into

investigation. Other times the witnesses are too lazy to go up to the police station to

report crime. So this application is designed for such people who are afraid and lazy.

The current technology for surveillance in public places that is being widely used is

Closed Circuit Televisions (CCTVs). This technology has found its use in widespread

public locales such as buildings, malls, shops, office buildings, etc. This technology can,

in some ways be compared to our target system with some glaring differences. For

example, the basic cost of a single CCTV camera unit ranges from anywhere between

Rs.850 and Rs.70000. thus it is rather expensive to install and maintain such cameras

in all the nooks and corners of a city as large as Pune. Another problem with such

cameras is detecting a red flag (a breach of security) will entail the monitoring of all

such cameras throughout the day. On the other hand, with the steep advent in the smart

phone market, the price of the technology is falling everyday and affording a phoneequipped with Android OS (compulsory for using the suggested system) is becoming

more and more possible for the general public. Also, in the case of organized crime,

CCTV cameras can be easily manipulated, and sometimes, more easily disabled by

snipping some wire. The response time for crimes in shops etc, depends on the

technology used in the CCTV camera, with some having live streaming features, but

most, due to financial problems, recording to a personal hard disk which can, as we

know, be manipulated easily. Also, for now, the criminals fear only the designated

enforcers of law, like the Police.

Taking the above mentioned problems into consideration, this system is built to help the

police, citizens and the society. The system provides a complete solution for mobile

users to make the society secure and safe using this mobile application. It takes an


13/90

13

initiative for providing a facility to mobile users to report crime to the police at the time

when it is happening and also informs them about location where it is going on without

wasting any time.

3.2 Project Scope

The basic objectives of the project are:

1. To enables customers to report crime scene from the spot without letting anyone

know about it.

2. Users do not have to take any more efforts other than capturing and sending a

picture (with or without description), because the rest is taken care by the

application, due to the GPS functionality which records the time and location

while capturing the picture.

3. It helps the Police department in their investigation because a snapshot of the

crime can be a major evidence, thus, speeding up the whole process.

4. Saves time because witness need not go to police station to report crime.

5. The system is designed in such a way that it helps to secure users personal

information. Their information would be revealed nowhere else other than theserver which is handled by the police department.


14/90

14

The fulfillment of the objectives would lead to following benefits:

1. Crimes can be reported by anyone using android phones from the crimes spot

fearlessly.

2. Police investigation will become a lot simpler due to the major evidence, i.e.,

Snapshots.

3. People will become more aware and responsible about reporting crime because

what they need is just to click a photo and send.

3.3 Feasibility Test

Feasibility studies are preliminary investigations into the potential benefits associated

with undertaking a specific activity or project. The main purpose of the feasibility study is

to consider all factors associated with the project, and determine if the investment of

time and other resources will yield a desirable result. While considered a preliminary

study, it is not unusual for a feasibility study to be highly detailed.

The feasibility study will also address costs and other factors that are indirectly

associated with the project. In the instance of creating a new product for sale, this

second phase will look into the costs associated with reaching and cultivating a

consumer base for the new product. The overall idea of these preliminary studies is to

ensure that there is a reasonable understanding of what will be required to both create

the new product and also successfully market the finished goods at a profit.

The utilization of a feasibility study has often assisted companies in understanding

which projects to develop and which ones to abandon before investing resources insomething that ultimately shows no promise of generating revenue. Taking the time to

engage in a pilot or feasibility study does involve some usage of available resources,

but these costs are much more readily absorbed than the larger amount that would be

expended on a project that ultimately proved to be worthless.


15/90

15

Though the feasibility study cannot be focused on a single area some of the areas or

analysis made in feasibility study is given below. But all the steps given below would not

be followed by all system developed. The feasibility study varies based on the system

that would be developed. Considering Crime Reporter, its feasibility study is mentioned

below in the following points.

1. Feasibility study is made on the system being developed to analyze whether the

system development process require training of personnel. This help in designing

training sessions as required in later stage. To design Crime Reporter, the

developers need to have a core understanding of java and php. Also they should

be familiar with the software called eclipse and android SDK and ADT manager.

As the code is developed for android phone, thus, it has to be developed, tested,

debugged and ran on android SDK manager. Developers familiar with eclipse

would know that Eclipse has Android development tools plug-in, which makes it

the perfect software to develop this system. It offers insight into the salient

features of an Android app, along with a brief explanation of its basic

components. The Android process is introduced for developing rich UIs for the

apps, as widgets. Finally, it showcases how easy it is to test the developed app

by deploying it on an Android device simulator included in the SDK.

2. Is the system developed has scope for expanding or scope for switching to new

technology later if needed in ease. In other study is made to find the portability of

the system in future. Crime Reporter is presently made for Android mobile set,

but it also can be developed further for other smart phones, blackberry, etc

which does not use android.

3. Is the cost of developing the system high or does it meet the budgeted costs. In

other words an analysis is made on cost feasibility of the project. This helps in

identifying whether the organization would meet the budgeted costs and also

helps the organization in making earlier and effective plans for meeting extra

costs because of the system development. Crime Reporter needs almost nil cost


16/90

16

during the development. The cost that is involved while building this system is for

the online hosting space, for server side coding, and one android handset for

testing and debugging.

4. Analysis is made on what software to use for developing the system. This study

and analysis would help to choose the best implementation for system and the

organization. This feasibility study includes factors like scalability, how to install,

how to develop and so on. This feasibility study in short includes the analysis of

technical areas. This analysis helps the efficiency of the system developed to get

improved. This is because by choosing the correct technology by making

analysis on the needs of system helps in improving the efficiency of the system.

Android as a Ubiquitous System

The primary principle behind all ubiquitous applications is to provide the users

with intelligent learning systems that supplement their everyday activities. This is

the primary consideration on which a ubiquitous application can be evaluated.

Consider a world where desktop computers are replaced by embedded

computers in typical physical objects, without interfering with the currentfunctionality of those objects. The requirements of a ubiquitous system have

been classified in three categories: system, software, business and organization.

System refers to the platform i.e. the hardware of the system, or the system

running the subject software on top of it. The term software represents the

services and the components of system that have been derived from the

ubiquitous system. Business refers to the actors who are providing the

components and services for the development of the system


17/90

17

Feature Implementation in Android

Interoperability: Content Provider handles it

Heterogeneity: Core libraries and Android Runtime handle it. It also includes

components like window manager, view systems, and telephony manager etc.

Mobility Activity Manager handles it Survivability Survival by protection is

achieved by Linux at core and SSL layer in middle-ware, giving an excellent

security mechanism.

Adaptability: Resource Manager and Package Manager provide the system

with information to encourage reusability of components.

Self-Organization: Notification Manager, XMPP Service and Location Manager

take up the responsibility to make system self organized and context aware.

Augmented Reality and Scalable content OpenGL, Linux kernel and proven

driver model of Linux makes it possible to implement such applications.

Implicit Interaction: Location Manager and Linux driver model makes it possible

for system to interact implicitly with user

Task-based Interaction: Notification Manager, Activity Manager makes

task based interaction possible.

Survivability

Android has achieved the survivability by protection mechanism in itself, since

the architecture is based on LINUX; which has over the time, proven it to be

among the league of secure operating systems. So at the bottom level

SELINUX is taking care of operating system level security. However, the

intercommunication security has been achieved by building in the


18/90

18

SSL component. By using more secure communication mechanisms the two

devices communicating via any device driver in kernel can use the security

mechanisms to ensure that there is no intrusion in the system. By

restricting invalid or unknown intrusion from any entity the system has made

itself secure at operating system level and communication level as well.

Component Types

Android defines four component types:

Activity components define an applications user interface.

Service components perform background processing.

Content provider components store and share data using a relational

database interface. Each content provider has an associated authority

describing the content it contains.

Broadcast receiver components act as mailboxes for messages

from other applications.

5. The above feasibilities are analysis which helps in development of the system.

But the scope of feasibility study does not end with this. Analysis or feasibility

study also includes the analysis of maintenance stage. In other words feasibility

study is made to analyze how one would maintain the system during

maintenance stage. This helps sin planning for this stage and also helps in risk

analysis.

3.4 Resources

3.4.1 Resource Pyramid

The second project planning task was the estimation of resources required to

accomplish the software development effort. There are three tiers of the

resources Human resources, reusable resources and hardware/ software tools.


19/90

19

This formed a development environment consisting of hardware/software tools as

base, reusable as middle tier and people as a primary resource at the top.

3.4.2 Human Resources

Planning began by scope and skills required to complete the development, Mona

Mishra, Harshit Adichwal, our Internal guide, Prof. Mrs. S.R. Vij and our external

guide, Mr. Gaurav Joshi as a team to develop this system. Following the

guidelines provided by the internal guide and with her invaluable suggestions, the

process of implementing the entire project and thereby aiming to complete the

work by April 12.

3.5 Estimation

3.5.1 COCOMO Model

This is a simple cost model for estimating the number of person-months required to

develop software. The model also estimates the development schedule in months and

produces an effort and schedule distribution by major phases. This model is based

on Barry Boehm's Constructive Cost Model (COCOMO). This is the top-level model,

Basic COCOMO, which is applicable to the large majority of software projects.

Basic COCOMO is good for rough order of magnitude estimates of software costs, but

its accuracy is necessarily limited because of its lack of factors to account for

differences in hardware constraints, personnel quality and experience, use of modern

tools and techniques, and other project attributes known to have a significant influence

on costs.

The model estimates cost using one of three different development modes: organic,

semidetached and embedded. Here is a summary of how Boehm describes the modes:


20/90

20

Organic

In the organic mode, relatively small software teams develop software in a highly

familiar, in-house environment. Most people connected with the project have extensive

experience in working with related systems within the organization, and have a thoroughunderstanding of how the system under development will contribute to the organizations

objectives. Very few organic-mode projects have developed products with more than 50

thousand delivered source instructions (KDSI).

Semidetached

The semidetached mode of software development represents an intermediate stage

between the organic and embedded modes. "Intermediate" may mean either of two

things:

1. An intermediate level of project characteristic.

2. A mixture of the organic and embedded mode characteristics.

The size range of a semidetached mode product generally extends up to 300 KDSI.

Embedded

The major distinguishing factor of an embedded-mode software project is a need to

operate within tight constraints. The product must operate within (is embedded in) a

strongly coupled complex of hardware, software, regulations, and operational

procedures, such as an electronic funds transfer system or an air traffic control system.


21/90

21

3.6 Schedule

No. From. To. Task

1 11 Aug 11 11 Aug 13 Discuss and decide the project domain

2 11 Aug 14 11 Aug 25 Met with external guide and he suggested some

of the constraint about our topic and also

discussed our understanding of the topic

3 11 Aug 26 11 Aug 27 Submitted our project synopsis to external

guide

4 11 Aug 27 11 Aug 29 Met the internal guide and told in brief about our

project and submitted the synopsis

5 11 Aug 30 11 Sep 05 Went through Ieee papers and did somebackground research( Literature Survey)

6 11 Sep 06 11 Sep 12 Download and installation of android SDK and

eclipse Plug-in

7 11 Sep 13 11 Sep 20 Start of requirement gathering with the help of

internal and external guides

8 11 Sep 21 11 Sep 25 Worked on Software Requirement Analysis

9 11 Sep 26 11 Oct 13 Drawing UML diagrams and also studied

Android Programming by referring various

tutorials

10 11 Oct 14 11 Oct 20 Study sample code of camera and storage and

tried to make new codes

11 11 Oct 21 11 Oct 27 Complete the UML diagrams and high level, low

level design documents and made interim

report.

12 12 Jan 06 12 Mar 30 Coding

13 12 Mar 31 12 Apr 18 Testing

Table 1: Project Timeline table (Date is written as Year_Month_Day)


22/90

22

Figure 2: Timeline Chart


23/90

23

3.7 Risk Management

3.7.1 Introduction

Risk analysis and management are a series of steps that help software team to

understand and manage uncertainty. Many problems can plague a software project. A

risk is a potential problem; it might or might not happen. But regardless of its outcome,

its a good practice to identify it, access its probability of occurrences, estimate its

impact and establish a contingency plan should the problem actually occur.

For any project being developed, it is empirical for the team to monitor and manage

risks. Risks are the unexpected delays and hindrances that are faced by the software

team and needed to be actively managed for rapid development.

The key functions of software management are to identify, address and estimate

sources of risk before they become threat to successful completion of software project.

An effective strategy must address three issues:

o Risk avoidance

o

Risk monitoringo Risk management and contingency planning

If a software team adopts a proactive approach to a risk, avoidance is the best strategy.

This is achieved by developing a plan for risk mitigation. As the project proceeds, risk

monitoring activities commence and the project manager provides factors that may

indicate if the risk is becoming more or less likely. Risk management and contingency

planning assumes that mitigation efforts have failed and the risk has become a reality.

RMMM plan tackles risks through Risk assessment and risk control.

Risk assessment involves Risk Identification, Risk Analysis and Risk Prioritization; while

Risk control involves Risk Management planning. Risk Resolution and Risk Monitoring.


24/90

24

3.7.2 Risk Assessment

Risk Identification

Our development team identified 20 potential risks to the project. These risks were

analyzed and were classified into various categories depending upon the threats

they posed to the project. Some of these risks were generic risks while others were

product specific risks. A considerable amount of time was spent in analyzing the

product specific risks.

Risk Analysis

These risks were analyzed individually and came up with a classification of risk onthe basis of their impact on project schedule. These risks were rated as follows:

Catastrophic

Critical

Marginal

Negligible

Risk PrioritizationAfter analyzing the risks, the risks were prioritized based on the review and

consensus among the developers.

Risk Control

After the risks had been categorized, prioritized and their probability of occurrences

determined, action will be taken to control these risks, which involved mitigating and

monitoring these risks. The key steps for risk control are as follows:

1. Stricter Completion Deadline

2. Wrong estimate on size and effort


25/90

25

3. Overly optimistic schedule

4. Lower reuse of code than expected

5. Lack of training on technology and tools

6. Developers work slower than expected

7. Increase on workload on developers and hence divided attention on project

8. Lack of Software resources

9. Developers assignments do not match their strengths

10. Lack of rapport among project team members

11. Change of technical guide

12. Inexperience in project software environment

13. Inexperience in programming language

14. Lack of technical support on unforeseen environment

15. Schedule omits necessary tasks

16. Requirements keep changing

17. Design neglects major issues resulting in redesign of certain components

18. Technology does not match expectation

19. Larger number of users accessing the server simultaneously

20. Error prone modules require more testing and implementation work


26/90

26

Risk Category Probability Impact RMMM

Working with unfamiliar

implementation

software

Technology risk Moderate Incorporate the

learning time in the

schedule

Crowded, noisy and

disruptive working

environment

Development

environment risk

Marginal Avoid crowded

workplaces

Unable to complete the

project tasks in the

stipulated time

Project size risk Critical Follow the

schedule

Slow progress due to

changing demands

Policy risks Moderate Keep the project

structure as

flexible as possible

Loss of technical

support

Policy risk Critical Try out other

sources for

support

Table 2: Project Risk Table


27/90

27

3.8 RMMM Plan

1. Stricter Completion Deadline

Risk mitigation:

Schedule the project in such a fashion that major modules (authentication,

sending a picture and showing location on the map) are completed first so that

they get enough time for testing and debugging.

Follow an incremental model of software development.

Risk Monitoring and Management:

Keep track of schedule slips.

Put in extra hours to make up for the lost hours.

2. Wrong estimation on size and effort

Risk Mitigation:

Qualify the size and schedule using ranges, so that the schedule estimate is not

treated as very precise and gives sufficient padding for schedule estimates.


Keep a track of the project by lines of code and complexity.

Keep track on the number of man hours spent.

Modify the estimates as the project develops and it becomes clearer as the

development phase progresses.

3. Overly optimistic schedule

Risk Mitigation:

Use available estimation tools to find the rough schedule estimate.

Have best case, worst case and average case times on each project activity.

This would give an idea on the confidence factor on estimates.


28/90

28


Keep track of schedule slips.

Modify the estimates as the project develops and it becomes clearer as the

development phase progress.

4. Lower reuse of code than expected

Risk Mitigation:

Design modules in such a way that code reuse are maximized.


Consult guide and developers for suggestion on code reuse.

If code reuse is less than expected then modify the design appropriately.

5. Lack of training on technology and tools

Risk Mitigation:

Given enough time to learn all the technologies required before actual coding

starts.

Develop sample applications using these technologies.


Consult technical guide in case of any problem.

6. Developers work slower than expected

Risk Mitigation:

Prepare a detailed completion schedule keeping short-term deadlines.

Review and keep log of the work done by each developer daily.


29/90

29


See to it that the set deadlines are followed strictly.

7. Increase on workload on developers and hence divided attention on project.

Risk Mitigation:

Schedule some simpler tasks related to project during this time.

Increase efficiency of work.


Try to decrease the other workload as soon as possible.

8. Developers assignments do not match their strengths

Risk Mitigation:

Involve all the team members in a joint assignment to nurture understanding

among team members and to test and understand the interests and expertise of

the developers.

Involve more than one developer in each task, so that at least one could continue

the work, if the other is unable to perform satisfactorily.


Perform regular reviews to check that the productivity is high and all developers

are suitable and equally loaded.

If a developer is unable to perform to the desired standards, reassign the task to

another developer.

Reschedule the planner to balance the workload.


30/90

30

9. Lack of rapport among project team members

Risk Mitigation:

Involve all the team members in a joint assignment to nurture the understanding

among team members and to test and understand the interests and experience

and expertise of the developers.

Occasionally have outings together to understand each other better.

Discuss each others problems and try to solve them through mutual consensus.


Review each others work every time when any of the members comes with

something productive.

In case of misunderstanding try to resolve the matter as soon as possible so that

it doesnt hamper the project deadline.

10. Inexperience in project software environment

Risk Mitigation:

Try to adapt to new project software environment.


Consult the people working in this environment in case of any problems.

11. Inexperience in programming languages

Risk Mitigation

Learn required programming thoroughly before starting with the coding.

Make coding of simple applications using the new programming languages.


Consult the people working in this environment in case of any difficulties.


31/90

31

12. Lack of technical support on unforeseen environment

Risk Mitigation:

Design a very user-friendly user interface.

Provide help to help users navigate through the system.

13. Requirements keep changing

Risk Mitigation:

Study techniques in detail and come up with the comprehensive and detailed list

of the requirements.

Understand the problem definition precisely so that there is a smaller probability

of change later.


Keep a track of the progress and check if something had been forgotten when

the requirements were laid down.

In case of change of requirement, follow a reverse engineering approach so that

the change reflects in all the work performed till date.

14. Schedule omits necessary tasks

Risk Mitigation:

Prepare schedule that prioritizes the tasks according to importance and workflow.

See to it that tasks are completed within their deadlines.


Get the schedule reviewed from the guide from time to time.


32/90

32

15. Design neglects major issues resulting in redesign of certain components

Risk Mitigation:

Prepare a detailed design document.

Get the design approved from the external guide.


Follow the design document when designing the classes.

16. Technology does not meet expectation

Risk Mitigation:

Keep a track of the code to be changed which changes with the change in

version of some software.

Keep the code compatible to change in versions as far as possible.


Check regularly for change in the version of the software being used.

17. Error prone modules require more testing and implementation work

Risk Mitigation:

Keep a fixed date for the first prototype to enter the testing phase.


Design the test cases as an umbrella activity.

In case the code is reused, go through the documentation and consider the side

effects due to coupling among modules.


33/90

33

3.9 SQA Plan

3.9.1 Introduction

The Software Quality Assurance Plan provides a road map for instituting software

quality assurance. It serves as a template for SQA activities.

3.9.2 Documentation

This section lists the documents that are produced as a part of software process:

Project Documents:

Software Quality Assurance Plan

Risk Mitigation, Monitoring and Management Plan

Project Plan

Technical Documents:

Software Requirements Specification

Software Design Document

Software Test PlanUser Document:

User document implies the document provided to the user. It contains the

information about how to use the system.

3.9.3 Audits and Reviews

Software reviews are taken as a filter for the software engineering process of MITCOLat various points during development and errors and defects are removed. A review is a

way of using the diversity of a group of people to point out needed improvements in the

product. It helps in achieving technical work of more uniform quality. We use Formal

Technical Review (FTR) as a reviewing technique.


34/90

34

Reviews and audits are performed in order to:

Observe different approaches to software analysis, design and implementation.

Uncover errors in function, logic or implementation of java coding.

To ensure that the software has been represented according to predefinedstandards.

To develop the software in uniform manner.

To make the project more manageable.

3.9.3 Standardization

Document Standards

Text font size: 12

Text font: Arial

Title font size: 14

Justified, with page numbers center printed.

Coding standards

Code should ensure minimum database access, and at the same time avoid

unnecessary replacing of data in the systems environment.

Emphasis should be given on modularity and reusability.

All function names should follow a uniform pattern.


35/90

35

CHAPTER 4

SOFTWARE REQUIREMENT SPECIFICATION

The most difficult part of requirements gathering is not the act of recording what the

user wants, it is the exploratory development activity of helping users figure out what

they want.


36/90

36

4.1 Introduction

Software is a part of a larger system. Work begins by establishing requirements of the

software. The system view is essential when software must interact with other elements

such as Hardware, people and database. System Engineering and analysis encompass

requirement gathering at the system level with a small amount of top-level design and

analysis.

Software requirement analysis may be divided into 5 areas of effort:

a) Problem recognition.

b) Evaluation and synthesis

c) Modeling

d) Specifications

e) Review

With lots of discussion with the company people, we try to understand depth of project.

As problem evaluation and synthesis is an important area, we have defined all

externally observable data objects and decided flow and contents of information.

4.2 Purpose

This SRS describe the basic information about Crime Reporter. Primary users of this

SRS are Developers, Stakeholders and Testers.


37/90

37

4.3 Scope in detail

The basic objectives of the project are:

1. To enable customers to report crime scene from the spot.

2. To enable users to also mention the location of crime scene using GPS

technology.

3. To help Police in their investigation.

4. Saves time because witness need not go to police station to report crime.

5. To allow users to view the details of all the crimes they have reported in the form

of history.

6. To develop a system that would secure customers personal information.7. The police administration would have access to the server via a username and

password.

8. It would be easier for police administration to locate crime spot as it would be

visible on the server in the form of a map.

The fulfillment of the objectives would lead to following benefits:

1. Crimes can be reported by anyone using android phones from the crimes spot.2. Police investigation will become a lot simpler.

3. People will become more aware and responsible about reporting crime because

what they need is just to click a photo and send.


38/90

38

4.4 Overall Description

4.4.1 User Characteristics

Mobile applications strongly require a clear understanding of the motivations and

circumstances surrounding mobile device use and adoption from the perspective of the

consumers. In particular, culture is an important determinant of mobile device use and

adoption since different cultures developed different traditions for mobile services use.

For instance, people in Japan use a mobile to surf the web, making more surfing on

mobiles than on PCs.

This means that investigation into characteristics of prospective users, contexts of use

and technology adoption factors must be a starting point in developing mobile

applications for such a complex and specific task as Crime Reporter.

This section describes various user classes that according to our anticipation will use

this system. The main characteristic of each class is given below:

Standard Users

These users are the one targeted by the final release of the Crime Reporter. They are in

possession of an mobile device running the Androidplatform and use it in case of an

emergency (911 emergency). We expect their number to be quite important once this

Androidbased system will be released.

Police Administration

These users are familiar with the Crime Reporter and they will be assigned a specific

number of usernames and passwords to access it. They will primarily use this

application to view the areas where crimes are going on and will act accordingly. These

would be the second users of the Crime Reportersince the release of Crime Reporter.


39/90

39

4.4.2 Operating Environment

The operating system at client side would be a mobile device with android 2.2 or above

with camera and GPS functionality embedded in it. While on the server side operating

system should be windows 98 and above, Linux and Mac OSX. The system must befully compatible with all the major browsers such as Netscape navigator, internet

explorer, Google chrome etc.

4.5 External Interfaces Required

4.5.1 Hardware Requirement:

A server machine is needed, that is capable of running a web server. There are no

hardware requirements for running the application because the user cannot customize

the hardware. For running the software, they will have to visit their mobile carrier buy a

device running Android 2.2 or higher and has camera and GPS embedded in it.

4.5.2 Software Requirement:

The sections below describes the system and software requirements for

developing Android applications using the Android Development Tools

Supported Operating Systems

Windows XP (32-bit) or Vista (32- or 64-bit)

Mac OS X 10.4.8 or later (x86 only)

Linux (tested on Linux Ubuntu Hardy Heron)

o 64-bit distributions must be capable of running 32-bit applications.

For information about how to add support for 32-bit applications, see

the Ubuntu Linux installation notes.


40/90

40

Supported Development Environments

Eclipse IDE

o Eclipse 3.4 (Ganymede) or 3.5 (Galileo)

Recommended Eclipse IDE packages: Eclipse IDE for Java EE

Developers, Eclipse IDE for Java Developers, Eclipse for

RCP/Plug-in

Developers, or Eclipse Classic (3.5.1+)

Eclipse JDT plug-in (included in most Eclipse IDE packages)

o JDK 5 or JDK 6 (JRE alone is not sufficient)

o Android Development Tools plug-in (optional)

o Not compatible with Gnu Compiler for Java (gcj)

Other development environments or IDEs

o JDK 5 or JDK 6 (JRE alone is not sufficient)

o Apache Ant 1.6.5 or later for Linux and Mac, 1.7 or later for Windows

o Not compatible with Gnu Compiler for Java (gcj)

If JDK is already installed on your development computer, it should meet the version

requirements listed above. In particular, some Linux distributions may include JDK 1.4

or Gnu Compiler for Java, both of which are not supported for Android development.

4.5.3 Technology Used:

The service can be integrated into a system that uses GPS GPRS and GSM

technologies. It can be used with only android phones as it uses android technology, i.e.

Android 2.2 or higher.

4.5.4 Function Point calculation

The function point method was originally developed by Bij Albrecht. A function point is a

rough estimate of a unit of delivered functionality of a software project. Function points

(FP) measure size in terms of the amount of functionality in a system. Function points


41/90

41

are computed by first calculating an unadjusted function point count (UFC). Counts are

made for the following categories

1. Number of user inputs = 21

Each user input that provides distinct application oriented data to the software is

counted.

2. Number of user outputs = 12

Each user output that provides application oriented information to the user is counted. Inthis context "output" refers to reports, screens, error messages, etc. Individual data

items within a report are not counted separately.

3. Number of user inquiries = 7

An inquiry is defined as an on-line input that results in the generation of some

immediate software response in the form of an on-line output. Each distinct inquiry is

counted.

4. Number of files = 18

Each logical master file is counted.

5. Number of external interfaces = 6

All machine-readable interfaces that are used to transmit information to another system

are counted.


42/90

42

Once this data has been collected, a complexity rating is associated with each count

according to Table

Measurement parameter Weighting factor

Count Simple Average Complex Total Count

Number of user input 12 x 4 4 5 48

Number of user output 9 x 4 5 7 36

Number of user inquiries 5 x 3 4 6 15

Number of files 18 x 7 10 15 180

Number of external interfaces. 6 x 5 7 10 30

309

Table 3: Function point complexity weights

Each count is multiplied by its corresponding complexity weight and the results are

summed to provide the UFC. The adjusted function point count (FP) is calculated by

multiplying the UFC by a technical complexity factor (TCF) also referred to as Value

Adjustment Factor (VAF). Components of the TCF are listed in Table 2

F1 Reliable back-up and recovery F2 Data communications

F3 Distributed functions F4 Performance

F5 Heavily used configuration F6 Online data entry

F7 Operational ease F8 Online update

F9 Complex interface F10 Complex processing

F11 Reusability F12 Installation ease

F13 Multiple sites F14 Facilitate change

Table 4: Components of the technical complexity factor


43/90

43

Alternatively the following question could be utilized

a. Does the system require reliable backup and recovery?

3

b. Are data communications required?

5

c. Are there distributed processing functions?

2

d. Is performance critical?

5

e. Will the system run in an existing, heavily utilized operational environment?

4

f. Does the system require on-line data entry?

2

g. Does the on-line data entry require the input transaction to be built over multiple

screens or operations? 0

h. Are the master files updated online?

3

i. Are the input, outputs, files or inquiries complex?

3

j. Is the internal processing complex?

3

k. Is the code designed to be reusable?

4


44/90

44

l. Are conversions and installation included in the design?

4

m. Is the system designed for multiple installations in different organizations?

4

n. Is the applications designed to facilitate change and ease of use?

5

Each component is rated from 0 to 5, where 0 means the component has no influence

on the system and 5 means the component is essential (Pressman, 1997). The VAF can

then be calculated as:

VAF= 0.65 + (Sum of GSCs x 0.01)Where, Sum of GSCs = SUM (Fi)

= 0.65 + (47 x 0.01)

=1.12

The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5) (Fenton,

1997). The final function point calculation is:

Final Adjusted FP = UFC x VAF

= 309 x 1.12

= 346.08


45/90

45

CHAPTER 5

DESIGN SPECIFIACTION

Design is not just what it looks like and feels like. Design is how it works.

5. Design Specification

5.1 Mathematical Analysis of Global Positioning System

The idea behind GPS is rather simple. If the distances from a point on the Earth (a GPS

receiver) to three GPS satellites are known along with the satellite locations, then the

location of the point (or receiver) can be determined by simply applying the well-known


46/90

46

concept of resection. Now arises a question on how we can get the distances to the

satellites as well as the satellite locations?

5.1.1 Introduction

As mentioned before, each GPS satellite continuously transmits a microwave radio

signal composed of two carriers, two codes, and a navigation message. When a GPS

receiver is switched on, it will pick up the GPS signal through the receiver antenna.

Once the receiver acquires the GPS signal, it will process it using its built-in software.

The partial outcome of the signal processing insists of the distances to the GPS

satellites through the digital codes (known as the pseudo ranges) and the satellite

coordinates through the navigation message.

Theoretically, only three distances to three simultaneously tracked satellites are

needed. In this case, the receiver would be located at the intersection of three spheres;

each has a radius of one receiver-satellite distance and is centered on that particular

satellite . However from the practical point of view, a fourth satellite needed to account

for the receiver clock offset

5.1.2 Numerical Expression of the Coordinates

The launching over the last three decade of the so-called geosynchronous satellites(i.e., satellites located at a fixed point above the surface of the earth) has made it

possible to determine tracking signal position anywhere on earth. This is done by

measuring the time it takes for a signal to travel between the observer and any satellite

and translating it into distance between the two. To exact the desired coordinates of the

observer from these measurements, we construct a sphere of radius ri about each of

four satellites. The equations

These spheres are given by:


47/90

47

Where xi, yi, zi are the known coordinates of the satellites in the space and x, y, z are

the unknown coordinate of the observer on the earth as shown. We now subtract the

first of these equations from each of the three. This eliminates quadratic terms in x, y, z

and leads to the following set of non homogeneous linear equation in x, y, z:

Figure 3:-Satellite and Observer in the Global Positioning System


48/90

48

This system can be solved by either Mathematica or Matlab containing package for

Gaussian elimination.

Let us consider an actual numerical example. Assuming that the coordinate of the

satellites with respect to a chosen point on the earth are given by the following values(in meters):

Suppose that in addition the distances registered by the GPS devices are given by:

Using the Gaussian Elimination to solve the system (S), the following results are

obtained:

These are the coordinates of the observer with respect to a fixed known origin on earth.

Hence we have here the application of simple expressions drawn from the analytical

geometry of sphere and the elementary use of Gaussian elimination to arrive at the

solution of a problem of some sophistication.

5.1.3 Numerical Solution Using Mathematics

The computer output obtained in connection with the above problem is as follow:


49/90

49

GPS

The 3-dimensional coordinates of each satellite are the following:

x1 := 2088202.299

y1 := -11757191.370

z1 := 25391471.881

x2 := 11092568.240

y2 := -14198201.090

z2 := 21471165.950

x3 := 35606984.591

y3 := -4447027.239

z3 := 9101378.572

x4 := 3966929.048

y4 := 7362851.831

z4 := 26388447.172

The distances registered in the GPS device are:

r1 := 23204698.51

r2 := 21585835.37

r3 := 31364260.01

r4 := 24966798.73


50/90

50

eqn1 := 2(x2-x1)x + 2(y2-y1)y + 2(z2-z1)z=r1^2-r2^2-x1^2+x2^2



In[721] := Solve [{eqn1, eqn2, eqn3}, {x,y,z}]

Out[721] = {{x --> -3.0168*10^6, y --> 7231.03, z --> -3.13188*10^7}}

The striking feature in this output is the terseness of the statement implementing the

solution. The bulk of the output is taken up with the description of the system to be

solved and listing of the numerical coefficients of the equations involved.

Implementation takes only two lines and is obtained with the command In[721], where

Solve is the code for the Gaussian elimination routine and the Out[721] is the result of

its application. It is worth mentioning here that the entire procedure is thus hidden in a

"black box," which can be cracked open to provide more solution details, albeit at the

cost of some additional effort. Black boxes containing standard AE or ODE solution

methods often run to several hundred pages of instructions or more, which typical user

never sees. The practical implementation of the GPS had to await the deployment of

geosynchronous satellite and the hardware needed to reduce compact GPS devices,

which can now be installed in automobiles. It is worth mentioning here that three

equation (i.e., the use of only three satellites in our case given that many can be

involved) would have been sufficient to calculate the Coordinates x, y, z of the observer.

In practice problem when many satellites come into play. Hence, this algorithm could be

used to solve the problem in such situation.

5.2 UML Diagrams

5.2.1 Use Case Diagram


51/90

51

Use case diagrams overview the usage requirements for a system. They are useful for

presentations to management and/or project stakeholders, but for actual development,

use cases provide significantly more value.

Use case diagrams depict:

4. Use cases. A use case describes a sequence of actions that provide something

of measurable value to an actor and is drawn as a horizontal ellipse.

5. Actors. An actor is a person, organization, or external system that plays a role in

one or more interactions with your system. Actors are drawn as stick figures.

6. Associations. Associations between actors and use cases are indicated in use

case diagrams by solid lines. An association exists whenever an actor is involvedwith an interaction described by a use case.

7. Packages (optional). Packages are UML constructs that enable you to organize

model elements (such as use cases) into groups. Packages are depicted as file

folders and can be used on any of the UML diagrams, including both use case

diagrams and class diagrams

Figure 4: use case 1
http://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htm


52/90

52

Figure 5: use case 2


53/90

53

5.2.2 Activity Diagram

Activity diagrams are typically used for business process modeling, for modeling the

logic captured by a single use case or usage scenario, or for modeling the detailed logic

of a business rule. Although UML activity diagrams could potentially model the internal

logic of a complex operation it would be far better to simply rewrite the operation so that

it is simple enough that you dont require an activity diagram. In many ways UML activity

diagrams are the object-oriented equivalent offlow charts and data flow diagrams

(DFDs) from structured development.
http://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/businessRule.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/businessRule.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htm


54/90

54

Figure 6: Activity Diagram


55/90

55

5.2.3 Class Diagram

The purpose of a class diagram is to depict the classes within a model. In an object

oriented application, classes have attributes (member variables), operations (member

functions) and relationships with other classes. The UML class diagram can depict all

these things quite easily. The fundamental element of the class diagram is an icon the

represents a class.

Figure 7: Class Diagram

5.2.4 Sequence Diagram

A fundamental goal of UML is to allow users to capture more than just structural

relationships. UML is intended to capture processes and flows of events. Sequence

diagrams draw from nearly every other facet of the language to put together a set of

diagrams that capture communications between objects.


56/90

56


57/90

57

5.2.5 State Diagram

Derived using sequence and class diagram. It shows the transition of one state into

another.

Figure 9 : State Diagram


58/90

58

5.2.6 Package Diagram

Packages provide a way to group related UML elements and scope their names. For

example, you can put all elements having to do with 3D rendering into a package

named 3DGraphics. Package diagrams provide a great way to visualize dependencies

between parts of your system and are often used to look for problems or determine

compilation order.

Figure 10: Package Diagram


59/90

59

5.2.7 Component Diagram

When modeling large software systems it is common to break the software into

manageable subsystems. UML provides the component classifier for exactly this

purpose. A component is a replaceable, executable piece of a larger system whose

implementation details are hidden. The functionality provided by a component is

specified by a set of provided interfaces that the component realizes. In addition to

providing interfaces, a component may require interfaces in order to function. These are

called required interfaces.

Figure 11: Component Diagram


60/90

60

5.2.8 Deployment Diagram

Deployment diagrams are used to visualize the topology of the physical components of

a system where the software components are deployed. So deployment diagrams are

used to describe the static deployment view of a system. Deployment diagrams consist

of nodes and their relationships.

Figure 12: Deployment Diagram


61/90

61

CHAPTER 6CODING

The first 90 percent of the code accounts for the first 90 percent of the developmenttimeThe remaining 10 percent of the code accounts for the other 90 percent of the

development time.


62/90

62

6.1 Code Specification

The project has been developed using Java and PHP. The software that is used is

Eclipse and Android SDK. Android has many amazing and unique features that are of

significance to developers and users alike, some of which are:

Application Framework that enables reuse and replacement of components

Optimized Graphics that is powered by customized 2D graphics library and 3D

graphics based on the OpenGL ES 1.0 specification

Media Support for common video, audio, and still image formats (MPEG4, H.264,

MP3, AAC, AMR, JPG, PNG, GIF)

Provision of Wi-Fi

SQLite for structured data storage

Open source WebKit engine based integrated web browser

Camera, GPS.

GSM Telephony

Dalvik virtual machine optimised for mobile devices

Rich Development environment that includes a device emulator, debugging tools,

performance and memory profiling and an Eclipse IDE plugin.

Google Android will be available with a host of features that includes a web browser,

email client, calendar, contacts, SMS feature, maps and others. All the Google Android

applications are written in Java and run on Dalvik virtual machine, which itself functions

on top of a Linux kernel.

With the above mentioned features and many more features of android, developers can

get complete access to the identical framework APIs as used by the core applications.

Besides this the app architecture is so designed so as to make the reuse of components

simpler and the capabilities of any application can be published and used by any other

app subject to the relevant security constraints. The users can also replace the

components using the same mechanism.


63/90

63

The fully integrated Android package comprising an OS, middleware, applications and

user friendly interface is expected to considerably speed-up product development while

lowering the cost of mobile services development.

6.2 Software Used

Operating System: Windows

Technology/ Platform: Android SDK with Eclipse Plug-in

Editor: Eclipse and Dreamweaver

6.3 Coding Style Followed

All variable is named by its work. It means name of all variable is how to use this

variable. All the functions are named in same manner. It is to increase the

understanding between team members. In case of android application, we divide codes

and main activity will call the functions in other java file. The function which is working

for the database in android mobile has been placed in different files. Also, all the

functions related to Google map, and Export as text file or KML file. All the string used in

GUI of application is placed in String.xml file. Initialization of variables, buttons in

functions to reduce confusion and increase readability of code. Comment is used for all

the functions to explain the code works. Server manager application is divided by main,

Dialog for IP, Dialog for Customer information insertion. It is made of JFC Swing so

control JDialog is placed in different function with main function. Space from left of page

is to divide code from other function. It will be able to increase the readability by each

member.


64/90

64

CHAPTER7

TESTING

All code is guilty, until proven innocent.


65/90

65

7. Test Plan

7.1 Introduction

Testing provides a road map that describes the steps to be constructed as a part of

testing, when these steps are planned and then undertaken and how much effort, time

and resources will be required. this section provides an overview of the entire test

document. this section provides both test plan and test procedure.

7.2 Goals and objectives

Following are some of the important goals and objectives of the entire test process:

to find out if each one of the requirements that have been mentioned in the

document have met correctly.

To find out if all the functionalities mentioned in the SRS have been performed.

To check whether all the possible cases for various different modules have been

handled and taken care of.

To find out errors due to certain specific positions and input and rectify them.

To ensure that the application avoids the unacceptable behaviour under normal

conditions and behaves properly across a variety of conditions and inputs,

normal and abnormal. To ensure that the program recovers gracefully and quickly from anomalous

behaviour or conditions.

The following initial test cases can be identified early in the design process as a vehicle

for checking that the implementation is basically correct. No attempt has been made at

this point to do thorough testing, including all possible errors and boundary cases. That

needs to come later. These cases represent an initial check that the functionalityspecified by the use cases is present.


66/90

66

7.3 Test Cases

Use Case Function Being

Tested

Initial System

State

Input Expected

Output

Application

startup

Started by user

by clicking on it.

Application is

off

User clicks on

application

Application

verifies Mobile

user.

Application

startup

On verification

opens camera

and activatesGPS

System verifies

user

_ GPS gets

activated and

camerainterface

appears

Application

startup

Application

closes if

authentication

fails

System verifies

User

_ Application

shuts down.

Camera Snapshots gets

saved

Application

opens camera

interface and

activates GPS.

Captures

Snapshot

Photo gets

saved and

records time

with it.

Camera Snapshots

records time

Snapshot taken _ time recorded

when snapshot

is taken

GPS location recorded Time recorded _ Location where

snapshot is


67/90

67

taken is

recorded.

Camera User chooses toopen photo

gallery

Camerainterface

opened

Selects photo Photo isselected to

send

Sending

Image

User clicks send Image selected User clicks send User is asked to

add description

Sending

Image

User sends with

or without

description

user asked to

add description

After adding

description user

presses send

Image goes for

verification.

Sending

Image

Image if edited Image goes for

verification

_ Image is

rejected by

application

Sending

Image

Image if not

edited

Image goes for

verification

_ Sent to server

in encrypted

form

Server Image gets

decrypted

waits to

receive image

_ Gets stored in

database

Server administratorwants to login

Waits foradministrator to

login

Enters Usernameand password

Verifiesadministrator

Server administrator verifies admin Wrong username Asks


68/90

68

cannot login and password administrator to

enter correct

username and

password

Server Admin logins Verify

administrator

right username

and password

administrator is

able to login

Server views Geomap System logins

to administrator

account

_ views Geomap

Server views Crime

details

Geomap view

of account

administrator

points cursor to

places where

crime took place

as it would be

shown with a

mark

views location

wise photos

along with

details

Server views all details

of user who has

uploaded he

photo

Geomap view

of account

clicks on pointed

location

views senders

details

Server administrator

downloads the

details of crime

along with

senders details

views crime

and senders

details

click download details gets

downloaded


69/90

69

Server administrator

prints the details

of crime along

with sendersdetails

views crime

and senders

details

click print details gets

printed

Server admin logouts geomap clicks on logout administrator

logouts

Table 5: Test Cases

7.4 GUI test

In computer science, GUI software testing is the process of testing a product that uses a

graphical interface to ensure it meets its written specifications. This is normally done

through the use of variety of test plans. Most client in client/server and web based

systems deliver system functionality using a graphical user interface(GUI).

This section provides tests about delivery, running the application, display and usability

of the application.

1. Delivery

1.1. For the client server solutions, is the server Software available?

Yes

2. Running


70/90

70

2.1. Does the application provide exit functionality?

Yes

2.2. If the application is not launched within 6 (six) seconds, is a warning message or a

progress bar displayed?

Yes

2.3. If the application is resumed from a suspended state, does it return to this state?

Yes

2.4. When at the application main menu, is the application suspended?

No

3. Screens

3.1. Does the first screen contain the application name or title in a title bar?

No

3.2.Are the screens properly refreshed after dismissing any another screen?

Yes

3.3. In the text fields, is the insertion point automatically placed at the end of the field?

Yes

3.4. Is the delay to display the next screen enough short (e.g. less than 10 seconds)?

Yes

3.5. If your application display icons, are they clear, visible and appropriate?

Yes

4.4. System


71/90

71

4.1. If the application supports backup/restore feature, if the user wipes data, reinstalls

the application and restore data, the previous data should be available in the

application.

Yes

4.2. If the application is a widget, can it be installed in the home screen application?

No

4.3. If geo location is supported, is the accuracy sufficient?

Yes

4.4. If geo location is supported, does it save battery and data exchange as soon aspossible?

Yes

4.5. If geo location is supported and if updates are supported, do the location updates

work?

Yes

4.6. If the application shares content with another application, can this another

application access to these data?

No

4.7. If the application supports calendar and read events, can it read an event calendar?

No

4.8. If the application read files, can it read a file?

No


72/90

72

7.5 Tools for testing

The test cases are intended to be run manually. But some parts can be automated with

specific tools.

1. Pre-Tests

This section provides general tests about launching the application.

Is the application launched successfully?

No

Once launched, does the application gain control?

Yes

Does the installation of your application not interfere with the pre-installed applications?

Yes

Can you come back to the application main menu screen in less than 3 seconds?

No

2. Network

This section is only applicable for applications that support network capabilities.

2.1. Protocol


73/90

73

Does the application meet the protocols implemented on the handset (like HTTP

protocol)?

Yes

3. User interactions

Tap on the screen ten times at different positions, the application should work normally

and not freeze.

No

When the application supports various ways to enter data, are all these solutions run

correctly?

Yes

Does the application manage correctly multi key press?

No


74/90

74

CHAPTER 8

PERFORMANCE ENHANCEMENT

A software never dies before its last user


75/90

75

8. Performance measurement

The first and foremost requirement for installing the application (Crime Reporter) on

your device is that the operating system should be Android 2.2 or higher equipped with

camera functionality. GPS is the main resource for getting exact position of the parcel.

Performance can be measured by the factors like time required for turning on the app,

saving the picture, time required for sending the picture to the server and authentication.

Most android phones are having different OS versions. So, performance may vary from

device to device.

Response of application can be different. It depends on the environment of the

execution and different factors such as free memory and space. However, latest model

of Android handsets are equipped with dual core processor and enhanced graphic chip.

So performance of Android handset is going to be increased.

Therefore, core operations of the application are also increased but execution in the

lower version of Android OS and minimum specification can be slower.


76/90

76

CHAPTER 9

FUTURE ANHANCEMENT

Future depends on what we do in the present


77/90

77

8. Future Enhancement

This project can be enhanced with much more features like future crime prediction,

which could use data sent by users to analyze and detect where in future there is apossibility of crime taking place. This enhanced feature could be used with Android

mobile set as well as other device which is support android OS and GPS features.

And it also can be developed further for other smart phones, blackberry, etc which does

not use android.


78/90

78

CHAPTER 10

CONCLUSION

The software isn't finished until the last user is dead


79/90

79

9. Conclusion

We have outlined some of the specification which would be helpful for carrying out tests

on the system. System will be able to handle all the data securely. This applicationwould help a lot in reducing the crime atleast at the city level and we hope that it would

also create awareness among people to fight crime and reduce it, thus making the city a

nice place to live in.


80/90

80

CHAPTER 11

SNAPSHOTS


81/90

81


82/90

82


83/90

83


84/90

84


85/90

85


86/90

86


87/90

87


88/90

88

CHAPTER 12

REFERENCES


89/90

89

10. References

[1] Zohaib Sibte Hassan , Ubiquitous Computing and Android, National University of

Computer & Emerging Sciences, Lahore, Pakistan

[2] John Whipple William Arensman Marian Starr Boler, A Public Safety Application of

GPS-Enabled Smartphones and the Android Operating System, Information Systems

Engineering Department Southwest Research Institute, P. O. Drawer 28510, San

Antonio, Texas, 78228-0510

[3] Machigar Ongtang, Stephen McLaughlin, William Enck and Patrick McDaniel,

Semantically Rich Application-Centric Security in Android, Department of ComputerScience and Engineering,The Pennsylvania State University, University Park, PA 16802

[4] Hyun Jung La and Soo Dong Kim, A Service-based Approach to Developing

Android Mobile Internet Device (MID) Applications, Department of Computer Science,

Soongsil University, 511 Sangdo-Dong, Dongjak-Ku, Seoul, Korea 156-743

[5] Maoqiang Song , Wenkuo Xiong , Xiangling Fu, Research on Architecture of

Multimedia and Its Design Based on Android, School of Software Engineering

Beijing University of Posts and Telecommunications Beijing, China

[6] Thomas Blasing, Leonid Batyuk, Aubrey-Derrick Schmidt, An Android Application

Sandbox System for Suspicious Software Detection, Seyit Ahmet Camtepe, and Sahin

Albayrak Technische Universitat Berlin - DAI-Labor

[7] Roy Want, Android: Changing the Mobile Landscape, Intel Labs

[8] Tapas Kumar Kundu, Prof. Collin Paul, improving android performance and energy

efficiency, Dept.of computer science and engineering, IIT Delhi.


90/90

[9] Wei Tang, Guang Jin, Jiaming He, Xianliang Jiang, Extending Android Security

Enforcement with A Security Distance Model, College of Information Science and

Engineering Ningbo University, Ningbo, Zhejiang, China

[10] Changhao Ai, Jie Liu, Chunxiao Fan, Xiaoying Zhang and Junwei Zou, Enhancing

Personal Information Security on Android with a New Synchronization Scheme, School

of Electronic Engineering Beijing University of Posts and Telecommunications

Beijing, China