Crime Analysis System: A Proactive Approach to Policing for Kayole Police Station Mwasingo, Ernest Walter Mada 96107 An Information Systems Project documentation submitted to the Faculty of Information Technology in partial fulfillment of the requirements for the award of the Bachelor’s Degree in Business Information Technology of Strathmore University. Faculty of Information Technology Strathmore University Nairobi, Kenya November, 2019 ii Declaration and Approval I declare that this work has not been previously submitted and approved for the award of a Bachelor’s degree by this or any other University. To the best of my knowledge and belief, the documentation contains no material previously published or written by another person except where due reference is made in the documentation itself. Student’s Signature: Name: Mwasingo Ernest Walter Mada Signature: Date: The Information System Project II documentation of Mwasingo Ernest Walter Mada was reviewed and approved (for examination) by: Supervisor’s Signature: Name: Mr. Tiberius Tabulu Signature: Date: 12th November 2019 12th November 2019 iii Abstract To maintain law and order, the Kenya Police Service (KPS) deploys proactive policing methods based on reports of crime recorded in the Occurrence Book (OB) by the victims. Smart, effective, and proactive policing is clearly preferable to simply reacting to criminal acts. Data from crimes reported is carefully analyzed to create crime statistics, crime graphs, crime clocks and crime maps which form the guide to proactive policing. Crime Analysis System (CAS) seeks to digitize the process of data capture, analysis and visualization. This is as opposed to the current manual system of reporting and analyzing crime. This system automatically evaluates the data to produce real crime statistics and plot them on crime graphs and scatter plots while at the same time taking care of the crime clock. Crime statistics shows the numbers of actionable crimes over a period of time. Crime graph shows the crime trends in an area over a period of time while the scatter plots show the concentration and density of specific crimes in a specified area. The crime clock simply shows distribution of crime across the twenty four hours. With this, the KPS is better placed to review personnel deployment and allocation of resources to reduce and control crime to manageable levels. This web based system has the capability of notifying the police personnel of sudden rise in crime in a different areas and call for an intervention. Incremental methodology was used to develop the system. The first model incorporated important functionality with subsequent modules added on to the base model gradually. This factored-in the sensitive nature of crime handling and deployment plans of the police service. Keywords: Crime Analysis System CAS, digital OB, crime statistics, Kenya Police. iv Table of Contents Declaration and Approval ............................................................................................................ ii Abstract ......................................................................................................................................... iii List of Figures .............................................................................................................................. vii List of Tables .............................................................................................................................. viii List of Appendices ........................................................................................................................ ix List of Abbreviations .................................................................................................................... x Chapter 1: Introduction ............................................................................................................. 1 1.1 Background of the Study .................................................................................................. 1 1.2 Problem Statement ........................................................................................................... 2 1.3 General Objective ............................................................................................................. 3 1.4 Specific Objectives ........................................................................................................... 3 1.4.1 Research Questions ................................................................................................... 3 1.5 Significance of the Study ................................................................................................. 3 1.6 Scope ................................................................................................................................ 4 1.7 Limitations ....................................................................................................................... 4 Chapter 2: Literature Review ................................................................................................... 5 2.1 Introduction ...................................................................................................................... 5 2.2 Crime Analysis in KPS .................................................................................................... 5 2.2.1 Challenges of the Manual System............................................................................. 5 2.3 Related Works .................................................................................................................. 6 2.3.1 Usalama..................................................................................................................... 6 2.3.2 NCRC Kenya ............................................................................................................ 7 2.3.3 A Mobile and Web Base Application for Security Intelligence Gathering .............. 8 2.4 Gaps in Existing Works .................................................................................................. 10 2.5 Conceptual framework ................................................................................................... 10 2.6 Conclusion ...................................................................................................................... 11 Chapter 3: System Development Methodology ..................................................................... 13 3.1 Introduction .................................................................................................................... 13 3.2 Development Methodology ............................................................................................ 13 3.2.1 Incremental Development Methodology ................................................................ 13 v 3.3 Justification of the Methodology.................................................................................... 14 3.4 Functional Requirements ................................................................................................ 14 3.4.1 Login Functionality ................................................................................................. 15 3.4.2 Record Reports........................................................................................................ 15 3.4.3 Generate Crime Statistics ........................................................................................ 15 3.4.4 Populate Crime Map ............................................................................................... 15 3.4.5 View Crime Data .................................................................................................... 15 3.5 Nonfunctional Requirements .......................................................................................... 15 3.5.1 Ease of Use ............................................................................................................. 15 3.5.2 Data Security ........................................................................................................... 15 3.5.3 Scalability ............................................................................................................... 16 3.5.4 Portability ................................................................................................................ 16 3.6 Tools and Techniques to be Applied .............................................................................. 16 3.6.1 Document Analysis ................................................................................................. 16 3.6.2 Observation ............................................................................................................. 16 3.6.3 PHPMyAdmin and MariaDB .................................................................................. 16 3.6.4 HTML, CSS, PHP and Javasacript ......................................................................... 16 3.7 Milestones and Deliverables .......................................................................................... 16 3.7.1 Concept Note .......................................................................................................... 17 3.7.2 Proposal................................................................................................................... 17 3.7.3 Analysis and Design Diagrams ............................................................................... 17 3.7.4 System Demo/Prototype ......................................................................................... 17 3.7.5 Test Cases ............................................................................................................... 18 3.7.6 Project Report and Documentation ......................................................................... 18 3.7.7 System Manual........................................................................................................ 18 Chapter 4: System Analysis and Design ................................................................................. 19 4.1 Introduction .................................................................................................................... 19 4.2 Analysis Diagrams ......................................................................................................... 19 4.2.1 Use Case Diagram................................................................................................... 19 4.2.2 Sequence Diagram .................................................................................................. 20 4.2.3 Class Diagram ......................................................................................................... 21 vi 4.2.4 Flow Chart Diagram ............................................................................................... 22 4.2.5 Activity Diagram .................................................................................................... 22 4.3 Design Diagrams ............................................................................................................ 24 4.3.1 Database Schema .................................................................................................... 24 Chapter 5: System Implementation and Testing ................................................................... 27 5.1 Introduction .................................................................................................................... 27 5.2 Description of Implementation Environment ................................................................. 27 5.2.1 Hardware Specification ........................................................................................... 27 5.2.2 Software Specification ............................................................................................ 27 5.3 Description of Testing and Results ................................................................................ 27 5.3.1 How Testing was Done ........................................................................................... 27 5.4 Test Data and Results ..................................................................................................... 29 5.4.1 Functional Requirements Result Table ................................................................... 29 5.4.2 Non – Functional requirements ............................................................................... 29 5.5 Description of Results .................................................................................................... 30 Chapter 6: Conclusions, Recommendations and Future Works ......................................... 31 6.1 Conclusions .................................................................................................................... 31 6.2 Recommendations .......................................................................................................... 31 6.3 Future Works .................................................................................................................. 31 References .................................................................................................................................... 32 Appendices ................................................................................................................................... 34 Appendix A: Gantt Chart .......................................................................................................... 34 Appendix B: Interfaces .............................................................................................................. 35 vii List of Figures Figure 2.1: Usalama Mobile Application ....................................................................................... 7 Figure 2.2: NCRC Kenya Application ........................................................................................... 8 Figure 2.3: Security Intelligence Gathering System .................................................................... 10 Figure 2.4: Conceptual Framework ............................................................................................. 11 Figure 2.5: Perceived vehicle crime hotspots versus actual vehicle crime hotspots ................... 12 Figure 3.1: Development Lifecycle .............................................................................................. 14 Figure 4.1: CAS use case diagram ............................................................................................... 20 Figure 4.2: CAS sequence diagram .............................................................................................. 21 Figure 4.3: CAS class diagram ..................................................................................................... 21 Figure 4.4: CAS flow chart diagram ............................................................................................ 22 Figure 4.5: CAS activity diagram ................................................................................................. 23 Figure 4.6: CAS Database schema ............................................................................................... 25 Figure 4.7: CAS Database Schema .............................................................................................. 26 viii List of Tables Table 5.1: Unit Testing ................................................................................................................. 27 Table 5.2: Functional Requirements Results ................................................................................ 29 Table 5.3: Non-Functional Requirement Results.......................................................................... 29 ix List of Appendices Appendix 1: Gantt Chart ............................................................................................................... 34 Appendix 2: User Registration...................................................................................................... 35 Appendix 3: Admin Landing Page ................................................................................................ 35 Appendix 4: Universal Login ........................................................................................................ 36 Appendix 5: Crime Reporting ....................................................................................................... 36 Appendix 6: Report Office Personnel Crime View ....................................................................... 37 Appendix 7: Supervisor’s Crime View .......................................................................................... 37 Appendix 8: Investigator’s Crime View ........................................................................................ 38 Appendix 9: Crime Map ................................................................................................................ 38 Appendix 10: Crime Statistics ....................................................................................................... 39 Appendix 11: Crime Chart ............................................................................................................ 40 Appendix 12: Crime Graph ........................................................................................................... 40 x List of Abbreviations CAS Crime Analysis System CR No. Criminal Register Number DCI Directorate of Criminal Investigations KPS Kenya Police Service NIS National Intelligence Service NPS National Police Service NSC National Security Council OB Occurrence Book OCS Officer Commanding Station Ops Room Operations Room SCPC Sub-County Police Commander OCPD Officer Commanding Police Division SSO Service Standing Orders 1 Chapter 1: Introduction 1.1 Background of the Study The Police force can be defined as the civil force of a state responsible for the prevention and detection of crime and the maintenance of public order (Oxford University, 2019). The Kenya Police Service (KPS) has its beginnings between 1887 and 1902 in pre-Independence Kenya (Kenya Police Service, 2018). Its core mandate is maintenance of law and order through detection, prevention and investigation of crimes and apprehension of offenders. Crime also known as an offence is defined as an act, attempt or omission punishable by law (Laws of Kenya, 2014). KPS deploys among other methods, proactive policing in its daily operations. Proactive policing lays an emphasis on prevention of crime by predicting when and where a crime may occur. Weisburd & Majmundar (2018), states that proactive policing targets the broader underlying forces at work that may be driving crime and disorder. Predictions are generated through statistical calculations that produce estimates, at best; like all techniques that extrapolate the future based on the past, they assume that the past is prologue. Consequently, the results are probabilistic, not certain. The proactive method contrasts with the standard model of policing, which involves an emphasis on reacting to particular crime events after they have occurred, mobilizing resources based on requests coming from outside the police organization, and focusing on the particulars of a given criminal incident. The statistical process starts with extracting data from the Occurrence Book (OB). The OB bears reports of alleged crimes made by supposed crime victims. However not all reports made in the OB are actionable and therefore proper sifting is done before a report qualifies to be added to the statistics. In the end, crime and intelligence analysts within KPS come up with crime statistics, crime graphs and crime patterns. Crime statistics displays actionable crimes in numbers over a period of time. Crime statistics indicates all crimes pending under investigation, all cases pending before court and the cases that have been finalized and accused either convicted or acquitted. Crime graph show the crime trend over time. It shows the upward or downward trend of crime. A crime pattern is a way of explaining when and why crimes are committed in certain areas and in a certain manner. Crime pattern analysis is a key step employed by law enforcement and criminal justice agencies towards understanding the spatial environment that generates crime patterns as Shekhar et al. (2012) observes. 2 With this information, the KPS comes up with a crime analysis report. The report guides in formulating security policies, reviewing of personnel deployment and allocation of resources in the fight against crime. Crime analysis consists of mapping crimes for command staff and producing crime statistics. It is defined as a set of systematic, analytical processes directed at providing timely and pertinent information. This information is relative to crime patterns and trend correlations. It assists operational and administrative personnel in planning the deployment of resources for the prevention and suppression of criminal activities, aiding the investigative process, and increasing apprehensions and the clearance of cases. Osborne & Wernicke (2003) states that crime analysis report aims at finding meaningful information from the vast amounts of data and disseminate this information to officers and investigators in the field to assist in their efforts to apprehend criminals and suppress criminal activity. Gottlieb et al. (1994) emphasizes that crime analysis supports a number of department functions including patrol deployment, special operations and tactical units. The also aides investigations, planning and research, crime prevention, and administrative services through budgeting and program planning. It is therefore very important that the criminal data is properly recorded, correctly extracted and properly analysed and thereafter safely stored for the success of any police department and moreso, the Kenya Police Service. 1.2 Problem Statement The crime reporting process in Kenya is crippled with manual systems of data capturing, storage and analysis. When a crime victim visits a police station, their complaint is recorded in writing in the OB (Transparency International Kenya, 2016). The OCS periodically calls for the OB to go through the reports made and allocates them to investigators accordingly thereby interrupting the process of crime reporting. The investigator in turn manually extracts information from the OB to compose a case file, inquiry file, inquest or any other relevant correspondence. Further the crime analyst will at the end of the day go through the reports and compose crime statistics, crime graphs and crime maps/scatter plots. Korir (2017) states that it is cumbersome and difficult to obtain instant information on the nature of prevailing crimes in different locations in the country due to the use of manual Occurrence Book across the country by the police. Once the OB is filled up, it is stored in cabinets at the station records office where it is susceptible to extreme weather and pests. As Muritu (2014) reports, our police stations are filled with dusty, 3 tattered and faded manual files that smell of a police service in dire need of a technology revolution. Based on the aforementioned challenges, this work digitizes the process of data capture at data entry points. This work further automates the process of crime analysis whose output will greatly improve the decision making process within the police. The system eventually provides crime statistics, crime graphs and the scatter plots for personnel deployment planning. 1.3 General Objective To develop a web based Crime Analysis System (CAS) that digitizes data capture, analysis and storage in Kayole Police Station. 1.4 Specific Objectives i. To review the manual system of crime analysis as is currently undertaken by KPS officers at Kayole Police Station. ii. To identify the parameters that should be considered for proactive crime analysis. iii. To develop a Crime Analysis System for Kayole Police Station. iv. To test the system with stakeholders to determine whether the system addresses the challenges identified. 1.4.1 Research Questions i. What are the challenges that the KPS officers at Kayole face as they manually analyze crime? ii. What are the parameters considered in proactive crime analysis? iii. How can a Crime Analysis System be developed? iv. How can the Crime Analysis System be tested? 1.5 Significance of the Study Crime pattern analysis is a key step employed by law enforcement and criminal justice agencies towards understanding the environment that generates crime patterns. The analysis of crime datasets with multiple crime types may reveal sudden increase in the activity of a subset of crime types in certain areas. This understanding provides insight into predicting future crime incidents and mitigates existing crimes. However, the growth in the size and volume of crime datasets poses serious challenges. This necessitates the growing need for law enforcement to have scalable systems to generate meaningful crime patterns that may lead to hypotheses regarding the nature of crime as opposed 4 to human driven enumeration of all possible hypotheses. Shekhar et al. (2012) in their Crime Pattern Analysis report gives this example: in a typical crime dataset containing 40 different crime types, there may be over 2 40 different patterns of association between different types. Enumerating all these patterns manually would be an arduous task even for trained analysts. Kayole Police Station aims at accomplishing crime mitigation and crime prevention with very few resources; this system will come in handy for the station. 1.6 Scope This application analyses data entered into the system to produce meaningful information that is used by KPS commanders at Kayole in their quest to police the area. This system however does not have a provision to capture information from informers and other sources although the officers are at liberty to incorporate the same in their decision making. 1.7 Limitations The functionality of this system is limited to crimes reported and entered in the OB at the report office. The system is not on an online platform and therefore does not support remote crime reporting. The users of this system will require analytical skills and necessary computer knowledge. 5 Chapter 2: Literature Review 2.1 Introduction This chapter analyzed the need for CAS through the study of works by other scholars. Shortfalls of the current system were examined and existing solutions reviewed. Gaps identified were addressed by this system. 2.2 Crime Analysis in KPS According to their Standing Orders (National Police Service, 2018), the OCS through the crime records personnel at the station level, compiles daily comprehensive reports based from those made at their stations during the preceding twenty-four hours occurring in their police station jurisdiction. The report contains all the essential details regarding the incidences. These details include name of Station, County, Criminal Register Number (CR No.) or OB No., map reference or township, road, name of complainant, and short précis’ of the offence or modus operandi, details of the accused, status of the case and details of the investigating officer. From these reports, they then update the crime clock and the crime map in the office of the OCS. The crime graph and crime statistics are compiled monthly. The reports are then submitted to the Sub-County Police Commander (SCPC) formerly known as the Officer Commanding Police Division (OCPD). The SCPC consolidates reports from all the stations (wards) under him and submits in a clear and detailed format to the County Police Commander. At the same time, the SCPC maintains a crime map, crime clock and crime graph in his Operations Room (Ops Room) which is updated daily by his Ops Room personnel. The same is repeated at the County level, Regional level and at Police Headquarters. The final report compiled at Police Headquarters is presented monthly to the National Security Council (NSC) by the Inspector General. NSC is chaired by the President and it exercises supervisory control over national security organs and reports annually to Parliament on the state of the security of Kenya. The current process is therefore purely manual with regard to data entry, extraction, submission and presentation. 2.2.1 Challenges of the Manual System Data in institutions is known to be error prone because the data was not extracted accurately when being moved from one system to the other. In a station as busy as Kayole, a data entry process where hundreds of reports are made every day, it is impossible to maintain absolute accuracy when extracting data. Even though quality checks may be implemented, the content is 6 difficult to review as this will involve cancellations and overwriting which in turn will hurt the credibility of the report. Unfortunately, as McCue (2006) would have it, the report may also contain misspellings, typographical errors, incomplete and missing information, as well as other inconsistencies, all of which significantly limit the analysts’ ability to effectively exploit the information. As explained by (Biderman & Reiss, 1967), concepts, definitions, quantitative models, and theories must be adjusted to the fact that the data are not some objectively observable universe of "criminal acts," but rather those events defined, captured, and processed as such by some institutional mechanism. Intentional errors exist where information is deliberately omitted in order to defeat a cause or due to too much pressure to perform. Most commonly it is used to portray an area as safe since the rate of crime has for long time been used as a performance indicator of an area OCS. This in turn leads to a phenomenon known as ‘dark figures of crime’. Dark figures of crime are occurrences that by some criteria are called crime yet are not registered in the statistics of whatever agency that is the source of the data being used (Biderman & Reiss, 1967). The data entry process itself might be flawed. For instance, the standard way of report taking may not be followed by the officer writing the report. The report by standard should contain details such as who is reporting, his/her residence, contacts, his home area, what is being reported, when it happened, any suspects and etcetera. However out of sheer negligence and ignorance, these details may not be captured which always hamper investigations. Different officers will report crime incidents in different formats, even though the same crime elements may be present from report to report. In their book Introduction to Crime analysis, (Osborne & Wernicke, 2003) note that it is important for analysts to recognize inconsistencies and attempt to correct them prior to the analysis. 2.3 Related Works This section looked into some of the existing solutions that try to address policing challenges experienced in Kenya. 2.3.1 Usalama Usalama is a mobile application that provides fast, convenient and accurate emergency communication (Usalama Technology Ltd, 2018). Usalama links a victim to an emergency service provider on the providers tab and get help instantly from them. It allows one to send emergency messages to emergency service providers and three predefined contacts of close 7 family and friends. This makes use of GPS to capture the exact geographical location of the victim, which is relayed together with the crime scenario. Usalama allows victims to communicate quickly with their next of kin in case of an emergency. It provides the ability to set automated alerts if one is going to a risky location. Allows location based situation alerts to allow one to share and receive news on crimes and criminal activities in the location. Usalama allows users to view and connect with each other within a 200m radius and keep tabs on each other’s position as they move. This is as summarized in Figure 2.1. However, the information that the users have submitted is not submitted for analysis, instead it is sent to other mobile users for alerting purposes and emergency response. This however creates a risk for users who submit false information, and there is no way to validate if information is authentic. This information is not analysed to provide predictive features to curb potential threats before they happen as it is not in the database of the KPS. Figure 2.1: Usalama Mobile Application (Usalama Technology Ltd, 2018) 2.3.2 NCRC Kenya NCRC Kenya is the official mobile application for the National Crime Research Centre (NCRC) of Kenya. It is a crime incident reporting tool used in researching the causes of crime and its 8 prevention. NCRC is tasked with the mandate of carrying out research into the causes of crime and its prevention and to disseminate the research findings and recommendations to the relevant government agencies concerned with the administration of criminal justice and other stakeholders (National Crime Research Centre, 2018). The major advantage of this application is that the data is used in crime research. Analysts in the NCRC evaluate the data submitted, observes crime trend and establish causes of crime and provides a recommended solution. The raw information however does not reach the KPS. The KPS are consumers of outcome reports and policies set by NCRC. This does not therefore give a real-time mapping of crime that would be relevant to the police as they deliver their duties on a daily basis. The outlook of the application is as shown in Figure 2.2. Figure 2.2: NCRC Kenya Application (National Crime Research Centre, 2018) 2.3.3 A Mobile and Web Base Application for Security Intelligence Gathering This is a Master Thesis by Francis (2016) seeking to digitise intelligence gathering mechanisms. He observes that the government’s efforts towards reducing these crimes have been ineffective as there are no mechanisms for gathering intelligence at low levels. 9 Intelligence gathering especially from the public is very essential in tackling matters to do with insecurity. He goes ahead to propose a simple, convenient and efficient solution to the security challenges that Kenya is currently facing with respect to systematic gathering of intelligence and its analysis by the use of a mobile and web based application. The mobile based solution integrates the use of GPS location services and machine learning predictive models. It provides detailed descriptive statistical analysis, text mining analysis of criminal activity taking place, as well as prediction analysis to predict crime patterns. The solution has an administrative web- based backend that will be accessed by the police force to ensure they get detailed information of criminal activities. From this portal, tests were done by entering information regarding suspicious person, potential suspicious person names associated with the submitted information are provided together with relevant scores to depict the most likely accurate name. This gives the system the major advantage in that a criminal is known and arrested before he commits a crime. The author in a blurry manner attempts to advance two forms of policing; predictive policing (also known as proactive policing) and intelligence-led policing both of which are data-driven methods. According to LeCates (2018), predictive policing uses computers to analyze the big data regarding crimes in a geographical area in an attempt to anticipate where and when a crime will occur in the near future. Intelligence-led policing, on the other hand, attempts to identify potential victims and potential repeat offenders, then works in partnership with the community to provide offenders with an opportunity to change their behavior before being arrested for a more severe crime. However, the author in his document talks about intelligence gathering from members of the public who submit information about suspicious persons. He does not talk about crime reporting which is a vital element in predictive policing. Further, the important component about intelligence-led policing is that it is a multisectoral collaboration amongst the various security agencies and the community. These not only include the KPS, but other local law enforcement agencies like the DCI, Military Intelligence and the NIS. Figure 2.3 shows the conceptual framework of the proposed intelligence gathering system. 10 Figure 2.3: Security Intelligence Gathering System (Francis, 2016) 2.4 Gaps in Existing Works The law enforcement community acknowledges the benefits of using data to guide policing strategy, yet still takes the practise of data analysis for granted when integrating it into the daily operations of police departments (Dolly & Shawver, 2018) as has been the case with the Kayole Police Station. Crime analysis is an important technical function that is part of modern police enforcement. Until now crime analysis at Kayole Police Station has been hindered by technology. Rudimentary crime analysis comprising manual graphing of crime sites, review of criminal records, and using pin maps has since revolutionized to incorporate advanced spatial crime modeling with data mining and mapping tools (Ratcliffe, 2010) but the KPS is yet to adopt. Comprehensive amounts of crime incidents which together with their associated location information and timestamps are accumulated in police database over time can now be used intelligently to reveal offending patterns. 2.5 Conceptual framework Figure 2.5 shows the data flow in the system. A reportee/victim will visit the station and make his complaint at the report office. The officer at the report office will enter the report into the system which will be saved on a central database. The OCS will allocate cases to an investigator from the convenience of his office. The investigator reviews the report and marks it as actionable or otherwise. If it is actionable, the crime map and the crime statistics graph/chart will be updated instantaneously. This will in turn be used to influence the decision on personnel deployment, resource allocation and administrative roles. 11 Figure 2.4: Conceptual Framework 2.6 Conclusion Police analysts routinely map crime incidents in order to both detect general patterns of crime that can focus their enforcement and prevention efforts as well to identify and apprehend specific offenders who are committing crimes. Figure 2.4 shows the importance of crime mapping in that it gives the specific location of crime instead of assumed hotspot areas and thereby helps the police in their deployment and planning. 12 Figure 2.5: Perceived vehicle crime hotspots versus actual vehicle crime hotspots (Adapted From: Chainey, 2001) The information gained from such analysis is used for a variety of applications from focusing deployment more specifically on hot spots to targeting crime prevention efforts on particular communities to tracking the behavior of a serial offender for whom the police intend to apprehend and, even, to mapping motor vehicle crash locations (Levine, 2005). By making use of the available crime data and appropriate spatial and temporal methods in crime mapping, the proposed system aims to observe crime and offender dynamics, and the factors affecting crime negatively and positively. Temporal data analysis will be used to make inferences and draw correlations that can be used to monitor and predict what crimes are happening when and why (Lillian, 2017). The outcome of the analysis will have practical implications due its high relevance to policy and wide applicability for Kayole Police Station. 13 Chapter 3: System Development Methodology 3.1 Introduction This chapter looked into the methodology that was used to develop the system, its justification, requirements, tools and techniques and deliverables. 3.2 Development Methodology This is the philosophy that tries to address the need for a new system in a structured way. It involves systems planning and selection, systems analysis, systems design and systems implementation and operation (Valacich et.al., 2012). 3.2.1 Incremental Development Methodology Incremental development methodology is a process of software development where requirements are divided into multiple standalone modules of the software development cycle. In this model, each module goes through the requirements, design, implementation and testing phases. Every subsequent release of the module adds function to the previous release. The process continues until the complete system achieved. This system was at its initial stage developed through implementation of existing policy guidelines as the initial requirements. A study of the SSO, the Police Manual Booklet and the Police Practical Procedures notes gave rise to the initial requirements. An initial basic system was then developed through the processes of analysis, design and implementation. This basic system was then exposed to the user for testing and evaluation. The feedback collected was used to refine the requirements to suit what the officers at Kayole Police Station would require to effectively analyse crime. This led to an increment to the initial system. The process was repeated until all the requirements were captured and an adequate system developed as shown in Figure 3.1. 14 Figure 3.1: Development Lifecycle (SMC Solutions, 2013) 3.3 Justification of the Methodology Incremental Development is a project development and management methodology, which allows for iterative project development and periodic progress measurement (SMC Solutions, 2013). The entire project cycle was sub-divided into vertical segments, referred to as "slices" wherein each slice is a deliverable. Slices are not sub-systems. They represent features. They are executable and demonstrable They cut across as much of the functionality of the system as possible, being tangible sets of functionality that allow the user to get a look and feel. This allowed a tangible part of the project to be complete at the end of a slice. Complete testing was carried out after each iteration. The deliverables for each of the slices included an executable that met the functionality, associated analysis and design documentation and test results. Each slice is developed in isolation. These slices were analyzed, designed, implemented and tested in a tight loop. Slice partitioning was done up-front, with the selection criteria as guided by Figure 3.1. This methodology therefore facilitates better risk management, better control on the project schedule through better monitoring and early corrective actions and better requirements management in an incremental mode. The methodology facilitates requirement evolution during the development as well as helps in managing larger projects. 3.4 Functional Requirements Functional requirements describe what the software should do so that the user can accomplish a specific task. They are directly related to a process in the system. They describe the capabilities and functions that have to be included in the system. They expound more on the user 15 requirements. Functional requirements are defined in the analysis phase and are used in the design phase, to design the solution/system. 3.4.1 Login Functionality This system allows registered users and the admin to log in and perform their various tasks. This differentiates different levels of users by their duties and privileges. 3.4.2 Record Reports The system allows users at the report office to record victim reports. This module is accessible by the officer on duty at the report office. 3.4.3 Generate Crime Statistics Once reports are entered, the system generates crime statistics. The module displays the crime trend and tabular view of crimes reported. 3.4.4 Populate Crime Map After the reports have been made and reviewed by the investigator, the system allows the user to populate the crime map. The module allows for pinning of crimes on the map to show intensity of different crimes on a map of the area. 3.4.5 View Crime Data The system allows the user to view previous reports as well as progressive crime statistics and crime maps. It serves to inform the officers in their decision making when delivering their policing duties. 3.5 Nonfunctional Requirements These describe the quality attributes, design and implementation constraints and external interfaces which the system must have. They are linked to the behavioral aspects of the system. 3.5.1 Ease of Use The User Interface design is focused on the anticipation of what the users might need to do by ensuring that the interface has elements that are easy to access, understand, and use to facilitate those actions. It brings together concepts from interaction design, visual design, and information architecture. 3.5.2 Data Security The system does not allow any user to change his/her designation for example from normal user to investigator. Only the admin has the privileges of changing the designation. This is to protect 16 and maintain data integrity as different categories of users have differing privileges when it comes to data view. 3.5.3 Scalability The web based system is hosted on a machine that has the capability to support at least 50 users logged in at the same time. 3.5.4 Portability Being a web based system; the system is able to run on different operating system environments provided there is a web server. 3.6 Tools and Techniques to be Applied The following tools and techniques were applied. 3.6.1 Document Analysis Document analysis involved the study of the Service Standing Orders (SSO) of the National Police Service (NPS), the NPS Police Manual and Police Practical Procedures which gives guidance to all procedures of the KPS. 3.6.2 Observation Observation involved a keen scrutiny of how the KPS actually conduct their operations around report taking and crime analysis. This was aimed at finding out further information that may be in practice but not described in the documents mentioned above. 3.6.3 PHPMyAdmin and MariaDB PHPMyAdmin was used to develop the database using MariaDB. 3.6.4 HTML, CSS, PHP and Javasacript Hyper Text Markup Language (HTML) is the standard markup language for creating Web pages. It describes the structure of a Web page and it tells the browser how to display the content. Cascading Style Sheets (CSS) is a language that describes the style of an HTML document. CSS describes how HTML elements should be displayed. 3.7 Milestones and Deliverables A deliverable is a measurable and tangible outcome of the project. They are developed in alignment with the goals of the project. Milestones on the other hand are checkpoints throughout the life of the project. They identify when one or multiple groups of activities have been completed thus implying that a notable point has been reached in the project. 17 3.7.1 Concept Note A concept note is a brief outline of the proposed project. The purpose of a concept paper is to help the student develop a more competitive proposal and to save time by eliminating proposals that are not likely to be considered. This was done at the beginning of the process. 3.7.2 Proposal A proposal, in this context, is an academic document that describes the ideas for an investigation on a certain topic. It outlines the process from beginning to end and is used to request approval for a project. The goal of the proposal was to present and justify the need to develop this system to solve the identified existing problem and to present the practical ways in which the system should be developed. 3.7.3 Analysis and Design Diagrams Design diagrams provide concrete representations of the system. Model elements, such as actors, use cases, classes, and packages were used to show a specific perspective of this system. They were used to capture system use cases in a use-case model during the requirements gathering phase, to define the application domain in an analysis model during the system analysis phase, and to refine the application model in a design model during the detailed design phase. 3.7.4 System Demo/Prototype A prototype is an original model, form or an instance that serves as a basis for other processes. It is a working example through which a new model or a new version can be derived. Using a prototype gives an opportunity to research new alternatives and test the existing design to confirm a product’s functionality prior to production. A prototype’s main benefit is getting valuable feedback from the user even before the actual system is implemented. In this case, the prototype was used to test the following modules. 3.7.4.1 Admin Module From this module, the ability of the system administrator to add/delete/approve users, allocate/change user designation and troubleshoot the system was put to test. 3.7.4.2 Data Entry/Viewing Point This is the front end of the system. From here the police officer at the report office is able to key- in new reports and view previous reports. 18 3.7.4.3 Investigators Module From this module an investigator has the privilege of reviewing an entry as actionable or not. He is able to adjust charge preferred to a suitable one according to available evidence. 3.7.4.4 Crime Map Module From here the OCS or patrol commander is able to guide the patrol teams on which areas to enforce what measures. It is also from this module that the system automatically generates alerts about sudden increase in crimes that need immediate intervention. 3.7.4.5 Supervisor Module This is the module for the OCS and his deputy. From here the OCS is able to allocate cases to investigators, determine allocation of resources and patrol methods and techniques. 3.7.5 Test Cases A Test Case is defined as a set of actions executed to verify a particular feature or functionality of the software application. It is a document that has a set of test data, preconditions, expected results and postconditions, developed for a particular test scenario in order to verify compliance against a specific requirement. Test Case acts as the starting point for the test execution, and after applying a set of input values, the application has a definitive outcome and leaves the system at some end point or also known as execution postcondition. For each of the modules above, the system has different home pages and varying rights to view or edit data in the system. This is to ensure data security and minimize chances of system breaches. 3.7.6 Project Report and Documentation Project documentation is the information that describes the system to its users. It consists of the product technical manuals. It also contains the source information about the product contained in design documents, detailed code comments, white papers and blackboard session notes. 3.7.7 System Manual The System Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use. It is a system focused composite document that includes the operation manual, maintenance manual, and additional information of use to the owner after they begin using the information system. 19 Chapter 4: System Analysis and Design 4.1 Introduction System analysis is conducted for the purpose of studying a system or its parts in order to identify its objectives. It is a problem solving technique that improves the system and ensures that all the components of the system work efficiently to accomplish their purpose. Systems design is the process of planning a new business system or replacing an existing system by defining its components or modules to satisfy the specific requirements. System design (Tutorials Point, 2019) focuses on how to accomplish the objective of the system. System Analysis and Design (SAD) mainly focuses on systems, processes and technology. This chapter will address the above through implementing analysis and design diagrams. 4.2 Analysis Diagrams Use case, sequence, class, flow chart, activity and state chart analysis diagrams are presented in the following sections. 4.2.1 Use Case Diagram A use case diagram is a graphic depiction of the interactions among the elements of a system. It’s used to identify, clarify, and organize system requirements. Figure 4.1 shows the use case diagram for this system. The report office personnel represents the officer taking in reports at the report office. His main duty is to enter victim reports. He may also view previous reports. The supervisor represents the OCS. He has the ability to view victim reports already saved in the system and allocate investigators to investigate the reports. From his terminal he is also able to view the crime graph/statistics and the crime map. This aids in his decision to allocate resources and plan deployment. The investigator views and updates cases allocated to after his investigations. 20 Figure 4.1: CAS use case diagram 4.2.2 Sequence Diagram Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. A sequence diagram is a good way to visualize and validate various runtime scenarios. These can help to predict how a system will behave and to discover responsibilities a class may need to have in the process of modeling a new system. 21 Figure 4.2: CAS sequence diagram 4.2.3 Class Diagram Class diagram is a static diagram. It represents the static view of an application. Class diagram is used for visualizing, describing, and documenting different aspects of a system. Is it also used for constructing executable code of the software application. Figure 4.3 shows CAS class diagram and it describes the attributes and operations of each class and also the constraints imposed on the system. Figure 4.3: CAS class diagram 22 4.2.4 Flow Chart Diagram Figure 4.4 shows CAS program flowchart. It is a diagram that uses a set of standard graphic symbols to represent the sequence of coded instructions fed into a computer, enabling it to perform specified logical and arithmetical operations. It shows steps in sequential order and is widely used in presenting the flow of algorithms, workflow or processes. Typically, a flowchart shows the steps as boxes of various kinds, and their order by connecting them with arrows. Figure 4.4: CAS flow chart diagram 4.2.5 Activity Diagram Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. The control flow is drawn 23 from one operation to another. This flow can be sequential, branched, or concurrent. Activity Diagrams describe how activities are coordinated to provide a service which can be at different levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the operation is intended to achieve a number of different things that require coordination, or how the events in a single use case relate to one another, in particular, use cases where activities may overlap and require coordination. It is also suitable for modeling how a collection of use cases coordinate to represent business workflows. Figure 4.5: CAS activity diagram 24 4.3 Design Diagrams Below is the database design diagram. 4.3.1 Database Schema A database schema is the skeleton structure that represents the logical view of the entire database. It defines how the data is organized and how the relations among them are associated. It formulates all the constraints that are to be applied on the data. The schema defines its entities and the relationship among them. It contains a descriptive detail of the database, which can be depicted by means of schema diagrams. Figures 4.6 and 4.7 shows the database schema for CAS. 25 Figure 4.6: CAS Database schema 26 Figure 4.7: CAS Database Schema 27 Chapter 5: System Implementation and Testing 5.1 Introduction This chapter looks into how the system was implemented and tested. This is through a description of implementation environment and a description of testing and results. 5.2 Description of Implementation Environment This describes the hardware and software specification for the application. 5.2.1 Hardware Specification For this application to run correctly, the following minimum hardware requirements should be met. i) 2.5 gigahertz (GHz) 64-bit (x64) processor ii) 4 gigabyte (GB) RAM iii) 32 GB available hard disk space iv) DirectX 11 graphics device with WDDM 1.0 or higher driver 5.2.2 Software Specification This is a web based application and will require the following software specifications i) Windows 7 operating system or above ii) Database server installed supporting Mariadb/MySQL 5.3 Description of Testing and Results 5.3.1 How Testing was Done i. Unit Testing Unit testing refers to a level of software testing where individual components of an application are tested. The purpose of using this testing paradigm was to validate that each unit was performing as required. Table 5.1 shows how testing was done. Table 5.1: Unit Testing The Test Data Expected Tested Result Actual Test Result User registration Register as a system user pending approval by the administrator. Registration as a user and confirmation by the admin works. Appendix 2 shows the user - registration form. Approve Registration The admin after confirming the Admin can approve, reject, 28 existence of an employer can approve/reject their registration, he can add employees and he can suspend or delete users. He however cannot view crimes reported. update or delete a user as shown in Appendix 3. Login Form Login as a registered system user if approved by admin. Users can login and see content relevant to their user groups/roles. Appendix 4 shows the login page. Report a Crime After a Report Office Personnel logs in, they are able to see crime report module where they can enter a crime report from a victim. The Report Office Personnel can view the crime reporting form and report a crime. Appendix 5 the crime reporting form. View a Crime Report The Report Office Personnel can view previous reports which then enables him direct victims to their investigators. The Supervisor (OCS) can view reports and allocate them to investigators. He then follows up on investigations. The OCS can view crime map, crime charts/graphs and crime statistics. The Investigators can view reports only allocated to them. They can accept or reject an allocation with reasons. They can make notes on the progress of cases. All users can perform their intended duties in the system. Appendix 6, 7 and 8 show the different views for the different users. Crime Map When a crime is entered, its location is pinned on a map. From the Map pins can change color. Supervisor can view map as 29 Supervisors module, the map can be viewed to show concentration of crime in an area with the color changing to red with concentration. shown in Appendix 9 Crime Statistics When a crime is entered, the crime statistics table is automatically updated. The supervisor can view and download the statistics. The Supervisor can download crime statistics in an excel form sampled in Appendix 10 Crime Charts/Crime Graph The system provides a summary of crimes reported via a pie chart. The Supervisor can view crime charts as shown in Appendix 11 and 12 5.4 Test Data and Results 5.4.1 Functional Requirements Result Table Table 5.2: Functional Requirements Results Test Id Test Item Description Results 001 Universal Login If username and/or password correct, login successfully else display an error. Pass 002 Crime Reporting Enter crime report particulars and save. Pass 003 Generate Crime Statistics Ability to generate a crime statistics table. Pass 004 Populate Crime Map Ability to pin crimes on a map and view the crime map. Pass 005 View Crime Data View crime charts and crime graph Pass 5.4.2 Non – Functional requirements Table 5.3: Non-Functional Requirement Results Test Id Test Item Description Results 001 Ease of Use The User Interface design is focused on the anticipation of what the users might need to do bringing together concepts from interaction design, Pass 30 visual design, and information architecture. 002 Data Security Authority to view data only applicable to user roles and privileges. To ensure data security only the admin has the privileges of changing the designation as different categories of users have differing privileges when it comes to data view. Pass 003 Scalability The web based system is hosted on a machine that has the capability to support at least 50 users logged in at the same time. Not tested 004 Portability The system is able to run on different operating system environments provided there is a web server. Not tested 5.5 Description of Results From the results, a conclusion can be drawn that the system is performing its required functionalities. These functionalities include report a crime, view and allocate a crime, review crime reports, populate and view crime statistics, maps, charts and graphs. From the reports, the OCS Kayole can easily assign resources and deploy his personnel pegged on crime incidences. 31 Chapter 6: Conclusions, Recommendations and Future Works 6.1 Conclusions The CAS system has fully addressed the gaps identified in Chapter 2 of this documentation. The system can perform real-time crime analysis right from when the crime report is entered. Further the system fully digitizes the report-to-analysis process. This process includes follow up on crime investigations and administrative processes like guide on allocation of resources and deployment of personnel in Kayole guided by crime occurrences as reflected in the crime map. The OCS Kayole will have a bird's-eye view of his area of jurisdiction right from the comfort of his office. This by large enhances his supervision and ‘grip’ of the area. As the system is used over time, it can predict when and where a crime may occur. Predictions are generated through statistical calculations by use of the reports generated by the system. This then introduces proactive policing method for Kayole Police Station. 6.2 Recommendations For better performance of the system, it is recommended that the server be physically located in the premises of Kayole Police Station for faster transactions with an offline backup for security of data. The system computers shall be isolated from internet connection for privacy concerns. A system administrator shall always be available on site to address any challenges that may arise. 6.3 Future Works The current system only supports reports made at the station. In the future, online reporting can be included to allow citizens report crime remotely. 32 References (2014). Laws of Kenya. In Penal Code (p. 17). Nairobi: National Council for Law Reporting. Biderman, A. D., & Reiss, A. J. (1967). The ANNALS of the American Academy of Political and Social Science. On Exploring the "Dark Figure" of Crime, 1-15. Chainey, S. (2001). GIS and Crime Mapping. London: UCL Jill Dando Institute. Dolly, C., & Shawver, B. (2018). Policing: A journal of Policy and Practise. The Organizational and Practical Considerations of Starting a Crime Analysis Unit: A Case Study of a Midwestern Police Department, 4-6. Francis, O. (2016). A Mobile and web based application for security intelligence gathering: a case study of Nairobi County. Strathmore University, Faculty of Information Technology. Nairobi: Strathmore University. Gottlieb, S., Arenberg, S. I., & Singh, R. (1994). Crime Analysis: From First Report to Final Arrest. Montaclair: Alpha Publishing. Kenya Police Service. (2018). Background. Retrieved May 27, 2019, from Kenya Police Service: http://www.kenyapolice.go.ke/pages/search/71-background.html Korir, C. (2017, April 10). Latest News: Ministry of Information, Communications and Technology. Retrieved June 6, 2018, from Ministry of Information, Communications and Technology Website: http://www.ict.go.ke/police-asked-to-discard-manual-occurrence- book/ LeCates, R. (2018, October 17). Intelligence-led Policing: Changing the Face of Crime Prevention. Police Chief Online, pp. 1-3. Levine, N. (2005). Crime Mapping and the Crimestat Program. Geographical Analysis, 1-16. Lillian, P. (2017, March 26). Data Science: Temporal Analysis for Crime Prevention and Monitoring. Retrieved June 6, 2019, from Dummies a Wiley Brand website: https://www.dummies.com/ McCue, C. (2006). Data Mining and Predictive Analysis: Intelligence Gathering and Crime Analysis. Elsevier Science & Technology. Muritu, J. (2014, July 30). Commentaries: Daily Nation. Retrieved June 5, 2018, from Daily Nation: https://www.nation.co.ke 33 National Crime Research Centre. (2018, July 3). Home: National Crime Research Centre. Retrieved June 9, 2019, from National Crime Research Centre Web Site: http://crimeresearch.go.ke/ National Police Service. (2018). Service Standing Orders. Nairobi: Government Printer Kenya. National Task Force On Police reforms. (2009). Report of the National Task Force On Police reforms. Nairobi: GOK. Osborne, D., & Wernicke, S. (2003). Introduction to Crime Analysis : Basic Resources for Criminal Justice Practice. London and New York: Routledge. OSCE. (2017). Intelligence Led Policing. Vienna: OSCE Secretariat. Oxford University. (2019). Definition of police in English. Retrieved May 27, 2019, from Oxford Living Dictionaries: https://en.oxforddictionaries.com/definition/police Ratcliffe, J. (2010). Crime Mapping: Spatial and Temporal Changes. Weisburg: A.R. Piquero and D. Weisburd (eds.). Shekhar, S., Mohan, P., Oliver, D., & Zhou, X. (2012). Crime Pattern Analysis: A spatial frequent pattern mining approach. Minneapolis: University of Minnesota. SMC Solutions. (2013, January 12). Methodology: Project Management. Retrieved June 17, 2019, from SMC Solutions Website: http://www.smc-sol.com Transparency International Kenya. (2016). Kenya Police Service Satisfaction Survey And Needs Analysis Report. Nairobi: Transparency International Kenya. Usalama Technology Ltd. (2018, December 5). Home: Usalama Technology Ltd. Retrieved June 9, 2019, from Usalama Technology Ltd Website: https://www.usalamatechnology.com/ Valacich, J., George, J., & Hoffer, J. (2012). Essentials of System Analysis and Design (5th ed.). New Jersey: Pearson Education Inc. Weisburd, D., & Majmundar, M. (2018). Proactive Policing: Effects on Crime and Communities. Washington DC: National Academies Press. 34 Appendices Appendix A: Gantt Chart Appendix 1: Gantt Chart 35 Appendix B: Interfaces Appendix 2: User Registration Appendix 3: Admin Landing Page 36 Appendix 4: Universal Login Appendix 5: Crime Reporting 37 Appendix 6: Report Office Personnel Crime View Appendix 7: Supervisor’s Crime View 38 Appendix 8: Investigator’s Crime View Appendix 9: Crime Map 39 Appendix 10: Crime Statistics 40 Appendix 11: Crime Chart Appendix 12: Crime Graph