CHAPTER 1 INTRODUCTION

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

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.

CHAPTER 2 EXTENSIVE TECHNICAL RESEARCH

He who does not research has nothing to teach

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 the development 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

4

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

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.

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 phone equipped 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.

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 technology to 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 technology has 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

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
9

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.

10

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.

11

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 phone equipped 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
12

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 us ers personal information. Their information would be revealed nowhere else other than the server which is handled by the police department.

13

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 in something 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.

14

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
15

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 current functionality 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

16

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
17

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.

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.

18

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:

19

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 thorough understanding 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.

20

3.6 Schedule No. 1 2 From. 11 Aug 11 11 Aug 14 To. 11 Aug 13 11 Aug 25 Task Discuss and decide the project domain 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 some background 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 9 11 Sep 21 11 Sep 26 11 Sep 25 11 Oct 13 Worked on Software Requirement Analysis 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 13 12 Jan 06 12 Mar 31 12 Mar 30 12 Apr 18 Coding Testing

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

21

Figure 2: Timeline Chart

22

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 monitoring o 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.

23

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 on the basis of their impact on project schedule. These risks were rated as follows: Catastrophic Critical Marginal Negligible

Risk Prioritization

After 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

24

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

25

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

26

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. Risk Monitoring and Management: 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.
27

Risk Monitoring and Management: 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. Risk Monitoring and Management: 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. Risk Monitoring and Management: 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.

28

Risk Monitoring and Management: 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. Risk Monitoring and Management: 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. Risk Monitoring and Management: 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.

29

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. Risk Monitoring and Management: 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. Risk Monitoring and Management: 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. Risk Monitoring and Management: Consult the people working in this environment in case of any difficulties.

30

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. Risk Monitoring and Management: 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. Risk Monitoring and Management: Get the schedule reviewed from the guide from time to time.

31

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. Risk Monitoring and Management: 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. Risk Monitoring and Management: 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. Risk Monitoring and Management: 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.

32

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 Plan User 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 MITCOL at 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.

33

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 predefined standards. 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.

34

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.

35

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.

36

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.

37

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 Android platform and use it in case of an emergency (911 emergency). We expect their number to be quite important once this Android based 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 Reporter since the release of Crime Reporter.

38

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 be fully 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.

39

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+)

o o o

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

JDK 5 or JDK 6 (JRE alone is not sufficient) Android Development Tools plug-in (optional) Not compatible with Gnu Compiler for Java (gcj)

Other development environments or IDEs

o o o

JDK 5 or JDK 6 (JRE alone is not sufficient) Apache Ant 1.6.5 or later for Linux and Mac, 1.7 or later for Windows 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
40

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. In this 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.

41

Once this data has been collected, a complexity rating is associated with each count according to Table Measurement parameter Count Number of user input Number of user output Number of user inquiries Number of files Number of external interfaces. 12 9 5 18 6 x x x x x Simple 4 4 3 7 5 Weighting factor Average 4 5 4 10 7 Complex 5 7 6 15 10 Total Count 48 36 15 180 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 F3 F5 F7 F9 F11 F13 Reliable back-up and recovery Distributed functions Heavily used configuration Operational ease Complex interface Reusability Multiple sites F2 F4 F6 F8 Data communications Performance Online data entry Online update

F10 Complex processing F12 Installation ease F14 Facilitate change

Table 4: Components of the technical complexity factor

42

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

43

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

44

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

45

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:

46

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

47

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

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

49

eqn1 := 2(x2-x1)x + 2(y2-y1)y + 2(z2-z1)z=r1^2-r2^2-x1^2+x2^2 eqn2 := 2(x3-x1)x + 2(y3-y1)y + 2(z3-z1)z=r1^2-r3^2-x1^2+x3^2 eqn3 := 2(x4-x1)x + 2(y4-y1)y + 2(z4-z1)z=r1^2-r4^2-x1^2+x4^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

50

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 involved with 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

51

Figure 5: use case 2

52

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 of flow charts and data flow diagrams (DFDs) from structured development.

53

Figure 6: Activity Diagram

54

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

56

5.2.5 State Diagram Derived using sequence and class diagram. It shows the transition of one state into another.

Figure 9 : State Diagram

57

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

58

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

59

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

60

CHAPTER 6 CODING
The first 90 percent of the code accounts for the first 90 percent of the development timeThe remaining 10 percent of the code accounts for the other 90 percent of the development time.

61

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.

62

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.

63

CHAPTER7 TESTING
All code is guilty, until proven innocent.

64

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 functionality specified by the use cases is present.

65

7.3 Test Cases Use Case Function Being Initial System Input Tested State Expected Output

Application startup

Started by user Application by clicking on it. off

is User

clicks

on Application verifies user. Mobile

application

Application startup

On opens and GPS

verification System verifies _ camera user activates

GPS activated camera interface appears

gets and

Application startup

Application closes authentication fails

System verifies _ if User

Application shuts down.

Camera

Snapshots saved

gets Application opens

Captures

Photo saved records with it.

gets and time

camera Snapshot and

interface

activates GPS.

Camera

Snapshots records time

Snapshot taken

time

recorded

when snapshot is taken

GPS

location recorded

Time recorded

Location where snapshot is

66

taken recorded.

is

Camera

User chooses to Camera open gallery photo interface opened

Selects photo

Photo selected send

is to

Sending Image

User clicks send

Image selected

User clicks send

User is asked to add description

Sending Image

User sends with user asked to After or without add description description

adding Image goes for user verification.

description

presses send

Sending Image

Image if edited

Image goes for _ verification

Image rejected application

is by

Sending Image

Image edited

if

not Image goes for _ verification

Sent to server in form encrypted

Server

Image decrypted

gets

waits receive image

to

Gets stored in database

Server

administrator wants to login

Waits

for Enters Username Verifies administrator

administrator to and password login

Server

administrator

verifies admin

Wrong username Asks

67

cannot login

and password

administrator to enter correct and

username password

Server

Admin logins

Verify administrator

right

username administrator is able to login

and password

Server

views Geomap

System

logins _

views Geomap

to administrator account

Server

views details

Crime Geomap of account

view administrator

views

location photos with

points cursor to wise places where along

crime took place details as it would shown mark view clicks on pointed views senders location details with be a

Server

views all details Geomap of user who has of account uploaded photo he

Server

administrator downloads

views the and

crime click download senders

details

gets

downloaded

details of crime details along with

senders details

68

Server

administrator

views

crime click print senders

details printed

gets

prints the details and of with details crime along details senders

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

69

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

70

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 as possible? 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

71

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

72

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

73

CHAPTER 8 PERFORMANCE ENHANCEMENT

A software never dies before its last user

74

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.

75

CHAPTER 9 FUTURE ANHANCEMENT

Future depends on what we do in the present

76

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 a possibility 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.

77

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

78

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 application would 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.

79

CHAPTER 11 SNAPSHOTS

80

81

82

83

84

85

86

87

CHAPTER 12 REFERENCES

88

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 Computer Science 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.

89

[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

90