Online Police Office Management System

RIFT VALLEY UNIVERSITY NEKEMTE CAMPUS
DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE
ONLINE POLICE OFFICE MANAGEMENT SYSTEM FOR THE NEKEMTE TOWN.
ADVISOR NAME: GETACHEW DIRIBA (MSC)
2014 E.C
NEKEMTE
RIFT VALLEY UNIVERSITY NEKEMTE CAMPUS
DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE
ONLINE POLICE OFFICE MANAGEMENT SYSTEM FOR THE NEKEMTE TOWN.
GROUP MEMBER
No Name ID Number Signature

1 Tadele Lema RVUCSE/0037
2 Gemechis Kebede RVUCSE/010
3 Bacha Tsegaye RVUCSE/004
4 Jiregna Balcha RVUCSE/052
5 Yisihaq Ararso RVUCSE/113
ADVISOR NAME: GETACHEW DIRIBA (MSC)

APPROVAL SHEET
This Document entitled “Online police office management system for the Nekemte town.” was read and
approved as meeting the preliminary Project requirement of Computer Science program in partial
fulfillment for award of the degree of bachelor of Computer Science, Rift Valley University, in Nekemte
campus.
Examining Board
Advisors Name: Signature: Date:
Internal Examiner: Signature: Date:
External Examiner: Signature: Date:
Chair Person: Signature: Date:

ACKNOWLEDGMENT
First of all to thank God who give our life worth living and thanking him for giving our strength to
accomplish our project. Secondly thanks our advisor Mr. Getachew Diriba (MSC) we would like
to thanks for giving your advice, full time and guidelines for finish our project on a time.
Additionally we want to thanks some persons working in the office Nekemte town polices officer
members for giving necessary information. Finally we want to thanks to our group members for
our actively participation on every task of the project.
RVU Computer Science Extension 2022 Page I

Abbreviation
CD…………………………………………………….....Compact Disk
DB……………………………………………………… Data Base
DFD……………………………………………………..Data Flow Diagram
ER……………………………………………………….Entity Relationship
FK……………………………………………..………..Foreign Key
HTML…………………………………………………..Hyper Text Markup Language
IP………………………………………………………..Internet Protocol
OFF NUM……………………………….………..……Office Number
PHP……………………………………….……..……..Hypertext Preprocessor
POMS……………………………………….……..….. Police Office Management System
PODB……………………………………………..……Police Office Data Base
PW……………………………………………………... Pass Word
PUB Name………………………………………………Public Name
POL Id…………………………………………………Police Identification
PK……………………………………………………….Primary Key
R ID…………………………………………………….Report Identification
R Type…………………………………………………..Report Type
Sec Id……………………………………………………Section Identification
Sec Name………………………………………………..Section Name
TCP/IP……………………………………………...…..Transfer Control Protocol/Internet Protocol
TVM…………………………………………………….Time Value of Memory
UN………………………………………………………User Name
UML…………………………………………………….Unified Modeling Language
VAR CHAR…………………………………………….Variable Character
RVU Computer Science Extension 2022 Page II

ABSTRUCT
The Nekemte town police office is not using Computerized Working System hence it is a serious
problem in time management and to perform their work efficiently. So making the system
automated will investigate the technological problems and to find ways and means to enable the
station computerized working system that could help him to work efficiently furthermore this
project is significant in that it enables the system.
The project focus on the objectives of the project, scope and limitation of the project. Therefore the
project design to using use case diagram and modeling, Beside to this on the project used software
such as: PHP, Java Script, Html for design the project and also MySQL for storing data .
RVU Computer Science Extension 2022 Page III

TABLE OF CONTENTS
Contents Page no
TABLE OF CONTENTS....................................................................................................................I
1 CHAPTER 1................................................................................................................................1
1.1 INTRODUCTION...............................................................................................................1
1.1.1 BACK GROUND INFORMATION............................................................................1
1.2 Strength and Weakness of Existing System.........................................................................1
1.2.1 Strength of the current system......................................................................................1
1.2.2 Weakness of the current system...................................................................................2
1.3 BACK GROUND OF THE PROJECT................................................................................2
1.4 STATEMENT OF THE PROBLEM...................................................................................2
1.5 OBJECTIVE OF THE PROJECT........................................................................................3
1.6 SCOPE AND LIMITATION OF THE PROJECT..............................................................3
1.6.1 Scope.............................................................................................................................3
1.6.2 Limitation.....................................................................................................................4
1.7 FEASIBILITY STUDY.......................................................................................................4
1.7.1 Operational/ Organizational Feasibility........................................................................4
1.7.2 Technical Feasibility.....................................................................................................4
1.8 BUDGET BREAKS DOWN AND WORK PLAN.............................................................5
1.8.1 Economic Feasibility....................................................................................................6
1.9 SIGNIFICANCE OF THE PROJECT.................................................................................7
1.10 BENEFICIARIES OF THE SYSTEM................................................................................8
1.11 METHODOLOGY OF THE PROJECT..............................................................................9
1.11.1 Data Collections Methodology.....................................................................................9
1.11.2 Case Tools....................................................................................................................9
1.12 RISK AND CONSTRAINTS..............................................................................................9
1.12.1 Action taken..................................................................................................................9
2 CHAPTER TWO.......................................................................................................................11
2.1 DESCRIPTION OF THE EXISTING SYSTEM...............................................................11
2.1.1 Description of the existing system..............................................................................11
2.2 Major Function of Existing System with Clear Inputs, Outputs and Process....................11
RVU Computer Science Extension 2022 Page IV

2.3 Generate reports.................................................................................................................12
2.4 Reporting crime..................................................................................................................13
2.5 Business Rules...................................................................................................................13
2.6 Report Generation in the Existing System.........................................................................13
2.7 Forms and Documents in the Existing System..................................................................14
2.8 Problem of Existing System Using Pieces Frame Wok.....................................................14
2.9 Performance related problem.............................................................................................14
2.9.1 Throughput.................................................................................................................14
2.9.2 Response Time............................................................................................................15
2.10 Information related problem..............................................................................................15
2.11 Economic...........................................................................................................................15
2.12 Control and Security problem............................................................................................15
2.13 Efficiency related problem.................................................................................................15
2.14 Service................................................................................................................................15
2.15 Practice to Be Preserved from Existing System.................................................................16
2.16 Alternative Options to Address problem of Existing System............................................16
2.17 System Requirement of the New System...........................................................................16
2.18 Functional requirement:.....................................................................................................16
2.19 Non Functional Requirements...........................................................................................17
3 CHAPTER 3..............................................................................................................................19
3.1 MODELING......................................................................................................................19
3.1.1 Use Case Diagram......................................................................................................19
3.1.2 Use Case Model..........................................................................................................19
3.1.3 Use case documentation.............................................................................................21
3.2 Sequence Diagrams............................................................................................................31
3.3 Activity diagram................................................................................................................37
3.4 Analysis level class diagram (conceptual modeling).........................................................41
3.5 Supplementary specification..............................................................................................42
3.6 Business rule of the new system........................................................................................42
4 CHAPTER FOUR.....................................................................................................................43
4.1 DESIGN.............................................................................................................................43
4.1.1 Introduction.................................................................................................................43
RVU Computer Science Extension 2022 Page V

4.1.2 Design goal.................................................................................................................43
4.1.3 CLASSTYPE ARCHTECTURE................................................................................44
4.1.4 Class modeling............................................................................................................45
4.1.5 Component Modeling.................................................................................................46
4.1.6 Deployment modeling................................................................................................47
4.1.7 Persistence data management.....................................................................................48
4.1.8 Mapping (hardware and software mapping)...............................................................52
4.1.8.1 Hardware Mapping
4.1.8.2 Physical and logical connectivity
4.1.8.3 Software Mapping
5 CHAPTER FIVE
Implementation And Testing
5.1 Implementation Method
5.2 Implementation Plan
5.3 Results and Advantages
5.4 Testing
Test Plan Overview
Features to be tested (Summery if finding)
Test Approach
Software Testing Strategy
Test Case Specification
CHAPTER SIX
Conclusion, Summery of finding, and recommendation
6.1 Conclusion
6.2 Summery of finding
6.3 Recommendation
5 References.................................................................................................................................53
RVU Computer Science Extension 2022 Page VI

RVU Computer Science Extension 2022 Page VII
RVU Computer Science Extension 2022 Page VIII
1 CHAPTER 1
1.1 Introduction
1.1.1 Back ground information
Nekemte town Police Office is one of the institutions of police office. It was established in 1975
E.C. In order to protect Nekemte town from crime and to give service such as peaceful security of
the people and their property etc. Those are protected by police and peoples. Not only these
security agencies such as justice office and others are works with community policing on the
handling, controlling and fighting against the crime and criminals. The institution of police station
is standing to protect peoples and their property from danger. But on the given of this service there
are many problems on the crime reporting system therefore our project has been prepared with
view of winning on approval for a project that has the objective of developing a new Police office
management System.
The proposed System applies to police institution all across the country and specially looks in the
subject of Police office management system. It is a well understood that crime prevention,
Detection and convection of criminals depend on a highly responsive. Back bone to information
management system. The efficiency of the policing function and the effectiveness with which it
tackles crime depend on what quality of information it can drive from its existing record and how
fast it can have access to it. The station has responsible for reporting and storing the nature of the
crime, the location details, the sequence of the crime, information on victims therefore this project
has the objective of driving a new database system for on line Police office management system
for Nekemte town.
1.2 Strength and Weakness of Existing System

1.2.1 Strength of the current system
The strength of current Nekemte town police office is explained as follows:
 Police man works with justice office to keep crime

 Any individual participates in keeping peace and security.
 It is almost preventing crime and controlling the criminal.
 It is transparent and openness to decide over the problem.
RVU Computer Science Extension 2022 Page 1

 No need of internet connections and digital materials (computers).
1.2.2 Weakness of the current system

 It needs much time to prepare criminal records.
 It needs more time for police man to come in to the office to report the events.
 The manual data storage takes large space.
 Decreases the accuracy of the work by causing work overload.
 It decreases the security of the files.
 Difficult to communicate with other parts.
1.3 Back ground of the project

Developing an online police office management system to improve the communication between
police and public which helps to improve the time utilization for solving crimes and not much time
is wasted to communicate with police. So, to reduce the time and increase problem solving
efficiency in time period, this application will be more helpful.
The Administrator is the key person for the entire application. He maintains all the users details,
create account, delete account, generates reports. He also has secure registration. He can
communicate with the other users through chat; besides can send mails to the users.
A police also have secure registration. He views the crime report sent by the public and starts
investigation on the case. He verifies whether all the proofs attached to it are valid or not and take
the next step in the investigation. After the investigation, he sends the report containing the proofs
to the administrator and closes the case. During the investigation, he sets the status of the case to
make aware of the public and the admin. After the submission, form is registered. He can
communicate with the other users through chat; besides can send mails to the admin and public.
User can report through online by posting the report. This form has different fields to describe the
crime details regarding the crime type, details of victims, suspects, reporters. They can check the
status of their case through progress tracking. Proofs should also be submitted along with the
report. They can also assign the case to security agents, detectives also. Public may communicate
with all the other users through mails, chat.

1.4 Statement of the problem
Since the police station apply manual Way of implementing tasks. It will also face many
technological problems to site some this multiphase factors in the case of police stations.
 File control mechanism is very tedious & complicated.

 High effort and coast is expanded in maintaining the records.
 Difficulty in conducting consistent reports.
 There is no fast and efficient way of sharing critical information across the police stations.
 It is not easy to retrieve the crime records.
 Much time is wasted in reporting the crime.
In the case of Nekemte town police office management system many of the affirmation factors are
existent. In fact the degree of severity varies from place to place but the above mentioned and
others problems of the station depicts our attention to work and automate the activates of the
station.
1.5 Objective of the project

The objectives of the project are to deeply investigate the technological problems of the Nekemte
town police management system which would alive the existing problem of the institution.
1.5.1 General objectives

 This project has general objectives of Online office management system for the Nekemte
town police office.
1.5.2 Specific objectives
 Analyzing the current system and to design new database system.
 To reduce human power (workers) so save budget of the police office.
 To prevent crime and control criminal person in simple and advanced manner.
 To make an online comprehensive crime reporting
 To hand over the results of the project for those who are concerned in order to disseminate
the project ideas and put it in to effect in all areas where it is needed.

1.6 Scope and limitation of the project
1.6.1 Scope
On completion of this project we expect the system will have:
 Reporting forms are available on webs.

 Maintain the centralized database to provide a security to information of complainers.
 Search tool is provided to recognize the criminals.
 Police are only liable to access to investigation tool.
 Every police station unique identity to access investigation tool.
 Secure registration and profile management for detectives and security agencies.
 Feedback is maintained for efficiency and Proofs are enclosed online.
1.6.2 Limitation
This project will be limited on developing a new data base for Nekemte town police office
management system on line.
1.7 Feasibility study
1.7.1 Operational/ Organizational Feasibility

The purpose of this project is to develop the system with operationally feasible which facilitates
quick performance and easy to understand every activity performed by the system. To achieve this
purpose, we have used friendly and easy understandable graphical user interfaces and also we will
prepare user manuals for the users. The activities of the system such as data entry, information
retrieval, updating and deletion of records from various tables etc. will be made easy. So the
system is operationally feasible.
1.7.2 Technical Feasibility

The system must have a set of hardware, software and peoples (professional peoples) to develop it
properly with technical feasibility. So we will come up with the required system since we have
taken various programming courses and software engineering course. Also our team member
learned Internet Programming; 1, Internet Programming 2 and developed some mini project like
individual website by using HTML and PHP language. Additionally our team members have
developed many mini projects like: payrol system, inistitutional website. We will uses MYSQL

server as backend Html and php MyAdmin as front end to develop the system. This software is
platform independent and has predefined functions and constraints such as to locate the charges,
validating functions etc. So because of team members past experience and software we have used,
we will achieve the target of the system that the system is technically feasible.
1.8 Budget breaks down and work plan
The expenditure items can broadly be classified in to material costs, service charges
No. List of Items Unit Quantity Unit Price Total Price
1. Stationary Materials
Stapler Pcs 1 150.00 150.00
Pencil Pcs 1 10.00 10.00
CD, (RW) Pcs 6 30.00 180.00
Flash disk 16GB Pcs 1 350.00 350.00
Sub total 690.00
2 Service charge
Typing & printing (data tools) Pages 210 page 3 1050
Typing & printing (1st draft thesis) Page 70 page 3 210
Binding Copies 4 35.00 140.00
Grand Total 2290
Budget allocated

The figure below represents the main activities of the project together with their respective
start and end date.
01/07/2014-
15/07/2014-
06/08/2014-
16/08/2014-
25/08/2014-
10/09/2014-
14/07/2014
05/08/2014
15/08/2014
24/08/2101
09/09/2014
19/09/2014
Activity name Duration
Data collection 14
Preparation of proposal 21
Requirement analysis 10
System design 09
Implementation 15
Testing 10
Presentation At the schedule of our University

Figure 1 schedule of the project
1.8.1 Economic Feasibility
1.8.1.1 Tangible benefits
A tangible benefit means the cost benefit that can be easily quantified or expressed in terms of
dollars or birr. So the benefits that are easily quantified from the conducted system are:
 Fastest processing time and small amount of processing error.
 Small response time and many services.
 Easy and fast performances.
 Reduce cost for manual data management (Reduced expenses).
 Easy update & retrieval on stored records.
We calculated the corresponding tangible benefits based on the technique called the Time Value
of Money (TVM).

Cost Reduction and Avoidance: To calculate this we consider the following things.
Total Number of employee in existing system= 100

Average Salary of each employee per month = 2500.00Birr
Total money required for payment per year= 100*2500*12= 3,000,000.00 Birr
Average Number of employee needed when the new system is developed=40
Average Salary of each of them per month =2500.00Birr
Total money required for payment per year=40*2500*12= 1, 200,000.00Birr
Difference b/n before and after the system developed money required for payment
Cost Reduction and Avoidance= (3,000,000.00 Birr) – (1, 200,000.00Birr)
= 1,800,000.00 Birr
1.8.1.2 Intangible benefits

The Intangible benefit is benefits from the system that are unquantifiable such as:
 Better decision makings
 Better service for socities
 Little job burden of workers
1.9 Significance of the project

The Nekemte town police office is not using Computerized Working System hence it is a
serious problem in time management and to perform their work efficiently. So making the
system automated will investigate the technological problems and to find ways and means to
enable the station computerized working system that could help him to work efficiently
furthermore this project is significant in that it enables the system.
 Reduce man power & budget.

 Avoid document missing.
 Avoid material availability Complain.
 Avoid tiredness to separate the dead file from the no dead files.
 It ensuring the availability of documents in their proper place.

 It well understood that crime prevention, Detection and conviction of criminals depending
on highly responsive back bone of information management.
 Ensured efficiency of policing function and effectiveness with which it tackles crime
depend on what quality of information it can drive from its existing system.
 It ensures fast & efficient sharing of critical information across all police stations.
1.10 Beneficiaries of the system

The system after careful analysis has been identified to be presented with the following
beneficiaries:
 Administrator, Police, Detectives & Security agencies and Public Module.
Admin Module
 Admin can register the police’s in a state.

 Admin can accept the detective and security agencies requests.
 Admin can assign some criminal cases to particular detective and security agencies.
 Admin can view all criminal’s information.
 Admin can view all missing people information.
 Admin can view all type of criminal cases information.
Police Module
 Police can enter all criminal’s information.
 Police can enter all missing people’s information and he provides some contact
information’s.
 Policies can view the all queries raised by the public and takes some action depends up on
the proof.
 Police can send mails to others.
Detectives and Security agencies
 Detectives and security agencies can take some cases from administrator or normal public.
 Detective can start some discussion forums and post some information to others.
 Detectives and security agencies can enquiry of assigned cases and upload the details to
administrator.

Public Module
 Publican views all criminal’s information.
 Public can view all Missing people’s information’s and intimate to particular contact
person or polices.
 Public can also enter a relative’s people missing information and provide some contact
numbers.
1.11 Methodology of the project
1.11.1 Data Collections Methodology

To collect the data, we have used two fact-finding techniques, observation and interviews.
Observation
By using these data collection techniques, we have observed how the existing system is working,
how they keeping crime how they store modules and some necessary data. Generally, we have
observed how protecting and detecting process is performed within the existing system.
Interviews
It is a fact-finding technique where by the system analysts collect information from individual
through face-to-face interaction. So we face some persons working in the office and gather
information about the existing systems.
1.11.2 Case Tools

The tools we are going to use for implementation.
 For front end (At the implementation or client part):

 Html programming
 phpMyAdmin
 For Back end (On the server part):
 MySQL as database storage.

1.12 Risk and constraints
Some of the problems that we might face while doing this project would include: -
 Damage on the computer that we work on.

 Lack of enough references and much information about the current system.
 Shortage of equipment.
 Shortage of enough time to develop the system.
 Some software failures.
1.12.1 Action taken

Because of the above problems we have to require some kind of management and we had put some
methods to overcome these problems which are explained as follows respectively: -
 We would have to take daily backup CD after we do the project so that, the data could not
be loss.
 We would use antivirus the updated one.
 We have additionally laptop when the system fails.
 As much as possible we try to schedule our time when we have to do the project.
 We scan our computer and reinstall again software when the software is failed.

2 CHAPTER TWO
2.1 Description of the existing system
2.1.1 Description of the existing system

When we study about the existing system so what we have explained in the existing system is what
currently exists in Nekemte police office. So accordingly the existing system uses manual
techniques and most of the activities are paperwork and direct human language communication to
perform all process. This delays to perform this activity of the system:
 Existing system is not providing missing citizen information’s.

 Existing system is not providing facilities for searching capabilities like crime and criminal
search – region, crime-type, gender, age group wise etc.
 Existing system is not providing facilities for secure registration and profile management
facilities for detectives and security agencies.
 Existing system is not providing Facility for communication between all stakeholders.
2.2 Major Function of Existing System with Clear Inputs, Outputs and Process
The major function of existing system is explained as follow:
 Executing all orders and warrants lawfully issued to the police officer by any competent
authority.
 Collecting and communicating intelligence affecting the public peace to the competent
authority.
 Preventing the commission of offenses and public nuisance.
 Detecting and bringing offenders to justice and apprehending all persons whom the police
officer is legally authorised to apprehend.
 Entering and inspecting any drinking-shop, gaming house, or other places of resort of loose
and disorderly characters.
 Taking charge of unclaimed property and disposing it subject to the Magistrate's order.
 Taking appropriate steps on occurrence of fire.
 Regulating public assemblies and processions and licensing of the same.
 Stopping any procession, that violates the conditions of a license.

 Keeping order in public roads, streets, thoroughfares, landing places and at all other places
of public resort and preventing obstructions on the occasions of assemblies and processions
on the public roads or in any other places.
 Keeping general diary in the police station and recording there in all complaints and
charges preferred, the names of all persons arrested, the names of complainants, the
offences charged against them, the weapons or property that shall have been taken from
their possession or otherwise and the names of the witnesses who shall have been
examined.
Generating report
Posting crime
2.3 Generate reports

This process is performed when generally necessary information is gathered from different
department of each college. The report will be generated monthly or annually as pair as needed.
Work flow to reports
 Work flow starts by collecting different information from each different police station.
 Then the office generates different reports.
 Work flow ends after generating necessary reports.
Table 2.1 Input output process of Generate Report.
Preparing general report
Input The necessary files for generation of reports.
Process Prepare different level of report based on gathered information from different files that is already
stored in the office.
Output General report will be generated.

2.4 Reporting crime
Table 2.2 Input output process for reporting crime.
Reporting crime
Input The police or any stake holders may saw any individual committing crime.
Process Then after they come to police office and report the crime.
Output The crime will be reported.
2.5 Business Rules
 Each member of the Division of Police shall devote his whole time and attention to the
business of the organization
 All members of the division will be required to keep their persons, uniforms and equipment
in a strictly neat condition and in perfect order and repair.
 No member of the division wearing his uniform shall smoke while on the street, nor in
public places, nor drink any kind of intoxicating liquors, nor engage in any game of cards
or billiards in any place. All members who have whether uniform, headgear, blouse, dress
coat, or overcoat on, will be considered under this rule to be in uniform.
 Each member of the division will be furnished with a copy of the rules and regulations,
which he shall at all times keep in his possession, and he shall make himself perfectly
familiar with its contents.
 Each member of the division will be required to give immediate obedience to every order
than may be given to him, and whenever assigned to any special duty, other than his
regular duties by his superior officers, shall be prompt in compliance with such orders.
 No member of the division shall make false official report or make a false report, or gossip
concerning a member of the division either as to his personal character or conduct or the
business of the division to the discredit or detriment of any member of the division.
2.6 Report Generation in the Existing System.

Different reports are generated in the existing system reports and summaries are the fundamentals
of any business organization. They tell how the business is running at any given time with

specified quires of the party that require those reports and summaries. The following are the
reports and summaries generated in police office management system.
 Annual Report requesting for police man.

 Monthly Report Compensation and Evaluation.
 Daily Report on police man evaluation.
2.7 Forms and Documents in the Existing System

Police attendance form:-The presence or absence of each police is filled in this form.
Detective information form:-The form that they use to identify the general information of
detective.
Agreement form:-This is the form that they are using for different agreement between police
station.
Traffic control form: The form that they are using for preparing the schedule like traffic police in
the town.
2.8 Problem of Existing System Using Pieces Frame Wok

The problems identified are presented as follow: -
 Existing system developed in intra network.

 Public cannot interact through internet.
 Authentication of reporters cannot be done.
2.9 Performance related problem

Performance related problem can be measured using two broad categories of performance
measurement. These are throughput and response time of different processes in the existing
system.
2.9.1 Throughput
For the reason that of every activity in the existing system is manual based it is unable to provide
some necessary information on time.

 Wastage of time to organize & integrate related files.
 High resource time and throughput.
 The task of report generating takes much time of the office, since it requires summarizing
bulk data.
2.9.2 Response Time

It is difficult to predict the response time of each process based on the detailed description of the
major functions of the existing system such as generating summarizing report, updating the given
data when needed, and so on.
2.10 Information related problem

Information related problems can be measured with respect to input and output information of the
existing system.
Output related problems

 Lack of relevant information in report generation.
 No standard method of generating reports.
 Inputs: redundant input information.
Stored Data
 Information is not secure.
 Criminal information is not well organized.
2.11 Economic
This term is a direct relation with that of ‘cost’ needed per each activity performed in the system.
The existing system is manual based and it needs high human power per each activity that incurs
high cost.
2.12 Control and Security problem

There are many security problems with the existing system. Due to little security control an
authorized body is capable to access information.
2.13 Efficiency related problem

There is also an efficiency problem with the existing system. Workers waste their time due to
redundantly input data’s when registering new criminals, generating reports, and others.

The use of several forms and copies in the record keeping will insure additional material cost.
2.14 Service
 The system is inflexible to new or exceptional situations.

 The system is inflexible to change.
 The system is not coordinated with other systems (standalone system).
2.15 Practice to Be Preserved from Existing System

The development of this new system contains the following activities, which try to automate the
entire process keeping in the view of database integration approach.
 Proposed system is providing facilities for secure registration and profile management
facilities for detectives and security agencies.
 Proposed system is providing Facilitate communication between all stakeholders.
 Proposed system is providing facilities for searching capabilities like crime and criminal
search – region, crime-type, gender, age group wise etc.
 Proposed system provides the information about the Missing citizen or valuables.
 This provides the facility of Recognition of citizen and other users’ contribution in
solving criminal issues.
2.16 Alternative Options to Address problem of Existing System

As we have tried to explain in the previous section the existing system has drawn backs that limit
the functionality, performance, efficiency and speed of the system because of the system operates
manually and it does not use the available resources effectively. So it is important to address this
problem as much as possible to increase the system is efficiency performance, speed, etc.
Depending on the problems identified the following alternative solutions can be considered to
address the problems. These are:
 Redesign the manual business process and let it continue: That means identifying the strength
and weakness of the business process of the existing system and enhancing the strength of
the business process of existing system for the new system.


 Changing the whole manual system in to computerized. Changing every activity in the
system that has side affection on the performance of the activities into computerized form.
 Automate the existing system by using centralized data base: That all the data of an
organization is stored on the server. So it is easier to maintain and back up data. Furthermore,
it is also easier to maintain data integrity, because once data is stored in a centralized
database, outdated data is no longer available in other places.
2.17 System Requirement of the New System
2.18 Functional requirement

The new system will be a networked application that will run on client -server with Window XP
Operating system and to provide case to use user interfaces to the users and window server for the
server side application. All in all, the functionalities that will be provided by the system are the
following:-
 Crime reporting forms, progress tracking, proof attachments.

 Facilitate crime and criminals search – region, crime-type, gender, age group wise etc.
 Missing citizen or valuables reporting and search.
 Recognition of citizen and other users’ contribution in solving criminal issues.
 Secure registration and profile management facilities for detectives and security agencies.
 Facilitate communication between all stakeholders - Discussion forum/chat/mail.
 Help book & time-to-time instructions to users through mail.
 Strategic details for admin and police authority.
2.19 Non Functional Requirements

Nonfunctional requirements describe user-visible aspects of the system that are not directly related
with the functional behavior of the system. It describes the aspect of the system that is concerned
with how the system provides the functional requirements. According to our system the non-
functional requirements are:-
 Security: The system should provide a high level of security and integrity of the data held by
the system, only authorized personnel can gain access to the system ‘s secured page on the
system and only users with valid password and user name can log in to view user ‘s page.

 Performance and response time: The system should have high performance rate when
executing user is input.
 Error Handling: Error should considerably minimize and an appropriate error message that
guides the user to recover from an error should be provided.
 Availability: This system should always available and access able.
 User friendly: The system is user friendly and easy to use to understand and required less
training.
 Quality issues: Quality should be needed from the system to make it reliable, available and
robust.
 Accuracy: Every activity performed by the system should be accurate and precise.
 Hardware considerations: The system should be compatible with hardware.
 Maintainability and modifications: The system should be easily modifiable.
 Backup and Recovery: The system should be holding a backup of the data and available any
time without interruption back.

3 CHAPTER 3
3.1 Modeling
3.1.1 Use Case Diagram

A use case represents a complete flow of events through the system in a sense that it describes a
serious of related interactions that result from the initiation of the use case. The following use case
describes the overall functionality of POMS from the user point of view.
3.1.2 Use Case Model

Use cases are used during requirement elicitation to present the functionality of the system from
the actor’s point of view. A use case represents a complete flow of events through the system in
the sense that it describes a serious of related interactions that results from the limitation of the use
case. In other words, it focuses on the behavior of the system from the external point of view. Each
use case will describe function, which will be done by actors.
An actor is a person which has a relation with the system externally. The identification of actors
and use cases result in the definition of the boundary of the system which is, in differentiating the
tasks accomplished by the system and the tasks accomplished by its environment.
Use case diagram

«uses»
send status «uses»
«uses»
«uses» «uses»
login police
«uses»
submit proof «uses» view crime
registration
«uses» «uses»
search
«uses» «uses»
«uses» «uses»
«uses» «uses»
view crime
«uses» «uses»
«uses» generate rpt
«uses»
«uses» change pswd
admin «uses»
create account security agency
delete account
Figure 3.1 use case diagram

3.1.3 Use case documentation
Each and every use case we have used in this project is explained in table form as following table.
Table 3.1 Description of login Use case with actor Administrator
Use case name Login
Actor Administrator
Description This use case allows the Administrator to log in to the system
Flow of events Actor action System response
step1: This use case is initiated Step2: The system validates the
when the administrator selects password and inserted user name to
administrator login form and select identify whether the user is legal or
user name and insert password. illegal.
step4: The administrator can access Step3: The system displays the
the administrator homepage. administrator homepage if the user is
legal user.
step5: Use case ends.
Alternative events step2: If the User name and password is not valid, send a notification to the
administrator to reselect user name and re-inter password again.
Pre-condition The login form is currently displayed on the screen and the administrator is
ready to log in.
Post-condition The administrator logged in to the system and select tasks.

Table 3.2 Description of login Use case with actor police man
Use case name Login
Actor Police
Description This use case allows the police to log in to the system.
step1: This use case is initiated when the Step2: The system validates the password
police selects the user name and inserts and selected user name.
his password.
Step3: The system displays the page for
step4:.The police selects the station police.
Step6: The police can access the selected Step5: The system displays the selected
station and can perform different tasks. page.
Step7: Use case ends.
Alternative step2: If the User name and password is not valid, send a notification to the police
events and redirect to the previous login form to redo user name selection and password
insertion again.
Pre-condition The login form is currently displayed on the screen and the police.
Post-condition The police is logged into the system and performs his tasks.
Table 3.3 Description of login Use case with actor security agency
Use case name Login
Actor Security agency
Description This use case allows the security agency to log in to the system.
step1: This use case is initiated when Step2: The system validates the
the security agency selects and inserts password and selected user name.
the user name and insert password.
Step3: The system displays the security
Step4: The Security agency can access

the homepage. agency homepage if the user is legal user.
Alternative step2: If the User name and password is not valid, send a notification to security
events agency and repeat step one.
Pre-condition The login form currently displayed on the screen and the security agency is ready to
log in.
Post-condition The Security agency is logged into the system and performs his tasks.
Table 3.4 Description of Generate report Use case with actor administrator
Use case name Generate report
Actor Administrator
Description This use case allows the Administrator to generate report.
Flow of events
Actor action System response
step1: This use case is initiated when the

Administrator selects the generate report
Step2: The system display the
form.
generate report form.
Step3: The Administrator selects the report
Step4: The system generates the
type as required.
report.
Pre-condition The administrator selects report to be generated on specified tasks.
Post condition Report is generated.

Table 3.5 Description of Create Account Use case with actor Administrator
Use case name Create Account
Actor Administrator
Description This use case allows the Administrator to create account.
step1: This use case starts when the Step2: The system displays the create
administrator browse creates account form. account form.
Step3: Then he fills the necessary information. Step4: The system validates the
inserted information.
Step6: Use case ends after the confirmation is
sent for the administrator. Step5: The system notify the as the
account is created.
Alternative Step4: The system determines the invalidation of the inserted information and notifies
event to re-insert information again.
Pre-condition The administrator login to the system and browse create account form
Post condition The administrator creates the new account.
Table 3.6 Description of Change Password Use case with actor Administrator
Use case name Change password
Actor Administrator
Description This use case allows the Administrator to change the password.
step1: This use case starts when the Step2: The system displays the change
administrator browse change password. password form.
Step3: Then he fills the necessary Step4: The system validates the inserted
information to change password. information.

Step6: Use case ends after the confirmation Step5: The system notify as the password
is sent for the administrator. is changed.
Alternative Step4: The system determines the invalidation of the inserted information and notifies to
event re-insert information again.
Pre-condition The administrator login to the system and there should be account with password to be
changed.
Post condition The password with the given account will be changed.
Table3.7 Description of Delete Account Use case with actor Administrator
Use case name Delete Account
Actor Administrator
Description This use case allows the Administrator to delete account.
step1: This use case starts when the administrator Step2: The system displays the
selects delete account button. delete account form.
Step3: Then the administrator fills the necessary Step4: The system validates the
information. inserted information.
Step6: Use case ends after the confirmation is Step5: The system notify the as the
sent for the administrator. account is deleted.
Table 3.8 Description of View Crime Use case with actor Security agency
Use case name View crime
Actor Security agency
Description This use case is help for the Security agency to view the crime and submit it.
Step1: The Security agency login to the system and Step3: The system displays the
click on view crime button. crime posted
Step2: Then the Security agency selects the crime he Step5: The system processes
wants to see. the answer of the Security
agency and displays the result
Step4: The Security agency views the crime post

online on the web site of Nekemte town police office. of the Security agency.
Step7: Use case ends after the Security agency gets the Step6: The system
feedback of the crimes. automatically gives the crime
feedback.
Pre-condition The crime should have to store on the database by the administrator or others.
Post condition The Security agency will know the crime posted.
Table 3.9 Description of post crime Use case with actor public
Use case name post crime
Actor Public
Description This use case is help for the public to post the crime.
Step1: The public login to his own Google account Step4: The system
or other by his user name and password automatically gives the crime
feedback.
Step2: Then the public writes the crime he saw
(crime done on himself or if he saw any individual
who committing the crime)
Step3: The public posts the crime online on the web

site of Nekemte town police office.
Step7: Use case ends after the public gets the

feedback of the post crimes.
Pre-condition The public should have email address or should have internet service
Post condition The criminal will be cached
Table 3.10 Description of submit proof Use case with actor police
Use case name Submit proof
Actor Police
Description This use case is help for the police to submit proof.

Step1: The police login to the system and click on Step3: the police click on the
view crime button. submit button
Step2: Then the police write the poof. Step6: The system
automatically gives the proof
Step4: The police submit the crime online to the
feedback.
web site of Nekemte town police office.
Step7: Use case ends after the police get the

feedback of the proof.
Pre-condition The police should have use name and password
Post condition The proof will store on the data base.
Table 3.11 Description of search criminals Use case with actor police
Use case name Search criminals
Actor Police
Description This use case allows the police to search the criminals from the system
Step1: This use case is initiated when the Step2: The system process search
police search the criminal by criminal functions for inserted criminal
name name.
Step4: The police select the wanted Step3: The system displays the
criminal from displayed criminals. criminal information.
Alternative Step2: The system notifies the non-existence of criminals with the inserted
event criminal name.
Pre-condition The police should have to know the criminal name.
Post condition The system displays the searched criminal.

Table 3.12 Description of Give Feedback Use case with actor public
Use case name Give feedback
Actor Public
Description This use case allows the public to give feedback
Step1: This use case starts when the public Step2: The system displays
selects give feedback button. the feedback form.
Step3: Then the public insert his E-mail address Step4: The system validates
the inserted E-mail address.
Step5: The public give feedback on the system
Step6: The system notify the
Step7: Use case ends after the notification is sent
as the feedback is sent.
for the public.
Alternative Step4: The system determines the invalidation of the inserted E-mail address and
event notifies to re-insert valid E-mail address again.
Pre-condition The public must have valid e-mail address.
Post condition The feedback will be sent.

Table 3.12 Description of send status Use case with actor police
Use case name Send status
Actor Police
Description This use case allows the police to send status
Step1: This use case starts when the police Step2: The system displays the
select send status button. send status form.
Step3: Then the police log in it the system Step4: The system validates the
inserted user name and
Step5: The police send status on the system
password.
Step7: Use case ends after the notification is
Step6: The system notify the as
sent for the police.
the status is sent.
Alternative Step4: The system determines the invalidation of the inserted user name and
event password and notifies to re-insert valid user name and password again.
Pre-condition The police must have valid user name and password.
Post condition The status will be sent.
Table 3.13 Description of View Status Use case with actor public
Use case name View status
Actor Public
Description This use case is help for the public to view the status.

Step1: The public inserts his e-mail address Step3: The system displays the
and go to the Nekemte town police office status posted
website
Step5: The system processes the
Step2: Then the public selects the status he answer of the public and
wants to see. displays the result to the public.
Step4: The public views the status post online Step6: The system automatically
on the web site of Nekemte town police office. displays status
Step7: Use case ends after the public view

status of the crimes.
Pre-condition The crime should have to store on the database by the administrator or others.
Post condition The public view the status of the crime posted.
Table 3.14 Description of Registration Use case with actor Administrator
Use case name Registration
Actor Administrator
Description This use case allows the Administrator to register.
Step1: This use case starts when the Step2: The system displays the
administrator browse Registration form. Registration form.
Step3: Then he fills the necessary information. Step4: The system validates the
inserted information.
Step6: Use case ends after the confirmation is
sent for the administrator. Step5: The system notify the as
it has been registered.
Alternative Step4: The system determines the invalidation of the inserted information and
event notifies to re-insert information again.
Pre-condition The administrator login to the system and browse Registration form
Post condition The administrator Registration the information.
3.2 Sequence Diagrams

Sequence diagrams are dynamic model of use cases, showing the interaction among classes during
a specified time period. Sequence diagrams graphically document the use case by showing the
classes, the messages, & the timing of the messages. Sequence diagrams show the timing of

transaction between object as they occur. It depicts the interactions between objects during a
certain period of time. The interaction proceeds from top to bottom a vertical timeline, while the
horizontal arrows represent messages from one object to another.
Sequence diagrams are used to model the logic contained in usage scenarios. A usage scenario is
the description of the way a potential use case is used. They are one of two dynamic models-the
other being activity diagram-used to model the dynamic aspect of our system. In recognition of its
growing popularity and its simplicity, we apply sequence here.
Figure 3.2 Sequential diagrams for login form

Figure 3.3 sequential diagrams for report use case
Figure 3.4 Account delete sequence diagram

Figure 3.5 Change password sequence diagram

Figure 3.7 sequence diagram for create account use case
3.3 Activity diagram

It highlights the activities performed in the system. Each activity is represented by a narrow and
more oval shape. The processing with in an activity goes to completion and then an automatic
transition to the next activity occurs an arrow represents the transition from one activity to the
next. The starting point of an activity diagram is represented by a filled-in circle and an end point
represented by bull’s eye.
Activity diagram are used to document the logic of a single operation/method, a single use case, or
flow of logic of business operation. In many ways activity diagram are the object oriented
equivalent of flow charts and data flow diagrams (DFD) from structured development.

This part of the project documentation consists of an activity diagram that depicts the flow of
action in two main use cases.
Figure 3.8 General login activity diagrams
Figure 3.9 login for administrator

Figure 3.10 police login
3.4 Analysis level class diagram (conceptual modeling)

We have used class diagram to describe the detailed understanding of the problem for our system.
Using this diagram, we showed classes of a system, their relationship and attributes of the class. It
also describes the type of objects in the system and various kinds of static relationships that exist in
the system.

Figure 3.11 class diagram
3.5 Supplementary specification

The supplementary specification contains three major classes of software requirements. First, it
contains those functional requirements that are not expressed in the use cases. Second, it
contains nonfunctional requirements, those requirements that describe attributes of the system and
of the systems environment, including items such as usability, reliability, and performance
requirements, as well as legal, regulatory, and documentation requirements. Finally, the
supplementary specification contains any design constraints imposed on the system or the
development process used to develop the system. So accordingly the supplementary specification
for the proposed system is the requirements that what we have not contained in use case model,
user interface model or domain models in the document.
3.6 Business rule of the new system

As we have tried to explain in the business rule of the existing system there are many business rule
that the police station has. So it is important to inherit this some of business rule for the new
system that we are going to develop. That means the system should have to include the business
rule of the existing system.

4 CHAPTER FOUR
4.1 Design
4.1.1 Introduction
In the previous section of our project we have identified the functional and non-functional
requirements of the system and produced the analysis model. Now the followings are discussed in
this section: design goals, Class Type Architecture, component diagram, deployment diagram,
persistence data modeling, and service specification. Specifically, the purposes of the system are:-
 To replace the manual system by an automated system.

 To ensure security in the system by using different security mechanisms.
 To make the data organized and centralized implementing a database system.
 To increase the flexibility of the proposed system.
 To specify how the system, do some tasks for the user.
4.1.2 Design goal

The design goals represent the desired qualities that the system should have and provide a
consistent set of criteria that should be taken into consideration when making design decisions.
The following are outlined to be the design goals of the proposed system for police office
management system.
Performance: Our system will make the system easy and fast since it is web based application
system. So the user can perform all of his activities within a short time as well as other tasks which
need long time do. Since the system is not complicated, it does not make the hardware busier or
slow. It also not consumes large space of the computer memory. So that it allows us to use our
memory efficiently with other applications we want.
Dependency: The system allows us to use any computer model, because of it is independent to any
hardware /platform independent and also we can use it with any application or operating system
that installed on our computer.
Include qualities that are desirable from a users’ point of view that have not yet been covered
under the performance and dependability criteria.

Maintenance: -The system is easily modifiable when some failure of software or hardware is
occurred and also if some transaction is occurred. The system is portable from window plat form in
to other plat forms easily that means the system primarily designed to be used in many plat form.
Availability: - The system should be available at every time.
Portability: - The system should be well suited to work on various platforms like windows 7
operating system or XP etc. i.e. customers are not required to install any software in order to access the
systems services.
Robustness: - The system should be designed in such a way that users can’t proceed having entered
invalid input or data in all cases of interacting with the system.
Generally some designed goals that we will achieve after the completion of this project: -
 The system has an ability to detect invalid input by responding “wrong Input” message.
 The system provides privileges to authorized user by giving account. In addition, the system
has a mechanism to prevent unauthorized users.
 The system primarily designed to be used in web based forms.
 The system performs its functions well and thoroughly without waste of money and time.
4.1.3 Class type architecture

Since our system modeling approach is object oriented, we have to describe the system in terms of
its architecture, such as, hardware /software mapping, persistency management, access and control
and security. In this section we have demonstrated different types of class type architectures; that
represent a high level layering strategy for software application. The various layers are represented
by the rectangles and collaboration between layers indicated by the arrows. The primary name of
the layer is indicated first, and other common names indicated in parenthesis.

User Interface (system interface)
- Administrator form screen ()
-police form screen ()
-security agency form screen ()
-Account screen ()
-generate report screen ()
-view crime screen ()
Control/process layer System

(Application, controller) (infrastructure
-Validate System User
plat form)
Domain (Business)
Persistent classes (Data) Store

search Delete update
Data Sources
Figure 4.1 Class type Architecture diagram
4.1.4 Class modeling

Class modeling are the mainstay of object oriented analysis and design, and before the UML most
methodologies called them object models instead of class models. In this document we have used
class models to explain the class and the attributes of each class with their data types, operation
and their interrelationships.

Figure 4.2 class modelin
4.1.5 Component Modeling
Component diagram is the software components, their interfaces, and their dependencies. We use
component diagrams to model software systems of our project at a high level or to show
components at a lower, package level.
Component diagram supports component-based development in which a software system is

divided into components and interfaces that are reusable and replaceable.
Component diagrams are useful for the following reasons:

 Defining the executable and reusable aspects of a software system.
 Revealing software configuration issues through dependency relationships.

 Showing an accurate depiction of a software application before you make changes or
enhancements.
We use component diagram to show the software component in detail
Figure 4.3 component diagram
4.1.6 Deployment modeling

The software going to be developed is allowed by UML model. UML deployment diagram show
physical view of system, taking software into real world by showing how software gets assigned to
hardware and how communicates.
The deployment diagram shows how the software components, processes, and objects are
deployed into the physical architecture of the system.
It shows the configuration of the hardware units (e.g. Computers, communication devices, etc) and
how the software components are distributed across the units.

Figure 4.4 deployment diagram
4.1.7 Persistence data management

Persistence data model or Entity relationship (ER) models are used to communicate the design
of a database, usually a relational database, to both users and other developers.
Persistence are used the schema of database. The strength of persistence data models is that data
entities are conceptually the same as the table of relation data base and that attributes are the
same as table columns.
4.1.7.1 Persistence layer

Persistence layer encapsulate the capability to store, retrieve, and delete objects/data permanently
without revealing details of the underlying storage technology. In the current database system, we
have used different tables as object and each object is related to each other and enforced by
referential integrity by the use of foreign key and primary key. This schema enables as data
manipulation activity such as select, search, delete, update on the data base.

Figure 4.5 Persistence data management
Table 4.1: class diagram description of attribute Admin

No Field name Data type Description
1 Admin_Name VarChar(15)not null name of admin
2 Admin_ID VarChar(15)not null Identification of admin
3 Email VarChar(20)not null Email of admin
4 Phonu_num int Phone number of Admin
5 Office_num int Office number of admin
6 State Int State of admin
7 Town Int Town of Admin
Method: Login(), Clear(), Exit()
Login (): specify Admin to login to the system.
Clear(): to clear the inserted statement
Exit(): to close the page
Table 4.2: class diagram description of attribute police

1 Police_Name VarChar(15)not null name of Police
2 Police_ID VarChar(15)not null Identification of Police
3 Email VarChar(20)not null Email of Police
4 Phone_num int Phone number of Police
6 State Int State of Police
7 Town Int Town of Police

Login (): specify Police to login to the system.
Table 4.3: class diagram description of attribute Security agency

1 Security agency_Name VarChar(15)not null name of Security agency
2 Security agency _ID VarChar(15)not null Identification of Security agency
3 Email VarChar(20)not null Email of Security agency admin
4 Phonu_num int Phone number of Security agency
5 Office_num int Office number of Security agency
6 State Int State of Security agency
7 Town Int Town of Security agency
Login (): specify Admin to login to the system.
4.1.8 Mapping (hardware and software mapping)
4.1.8.1 Hardware Mapping

The hardware used for Nekemte town police office system is personal computers like laptop or
desktop and other necessary hardware will be included.
4.1.8.2 Physical and logical connectivity

Our Proposed system has no physical connectivity, because, our proposed System is to manage a
file into database system. In addition; there are many types of constraints that we tried to inform in
this project limitation part that has limited from physical connectivity.
4.1.8.3 Software Mapping

The system uses Microsoft Windows Ultimate Operating System. The proposed system uses
C# programming to develop the system. The system uses MySQL data base to store data.

Figure 4.6 hardware and software mapping

CHAPTER FIVE
5. IMPLEMENTATION (CODING)
Implementation and Testing

Implementation is the stage in the project where the theoretical design is turned into a working
system and is giving confidence on the new system for the users that it will work efficiently and
effectively. It involves careful planning, investigation of the current system and its constraints on
implementation, design of methods to achieve the changeover, an evaluation of change over
methods. Apart from planning major task of preparing the implementation are education and
training of users. The implementation process begins with preparing a plan for the implementation
of the system. According to this plan, the activities are to be carried out, discussions made
regarding the equipment and resources and the additional equipment has to be acquired to
implement the new system. In network backup system no additional resources are needed.
Implementation is the final and the most important phase. The most critical stage in achieving a
successful new system is giving the users confidence that the new system will work and be
effective. The system can be implemented only after thorough testing is done and if it is found to
be working according to the specification. This method also offers the greatest security since the
old system can take over if the errors are found or inability to handle certain type of activity while
using the new system.
5.1Implementation Methods
There are several methods for handling the implementation and the consequent conversion from
the old to the new computerized system.
The most secure method for conversion from the old system to the new system is to run the old and
new system in parallel. In this approach, a person may operate in the manual older processing
system as well as start operating the new computerized system. This method offers high security,
because even if there is a flaw in the computerized system, we can depend upon the manual
system. However, the cost for maintaining two systems in parallel is very high. This outweighs its
benefits.

Another commonly method is a direct cut over from the existing manual system to the
computerized system. The change may be within a week or within a day. There are no parallel
activities. However, there is no remedy in case of a problem. This strategy requires careful
planning.
A working version of the system can also be implemented in one part of the organization and the
personnel will be piloting the system and changes can be made as and when required. But this
method is less preferable due to the loss of entirety of the system.
5.2. Implementation Plan
The implementation plan includes a description of all the activities that must occur to implement
the new system and to put it into operation. It identifies the personnel responsible for the activities
and prepares a time chart for implementing the system. The implementation plan consists of the
following steps.
 List all files required for implementation.

 Identify all data required to build new files during the implementation.
 List all new documents and procedures that go into the new system.
The implementation plan should anticipate possible problems and must be able to deal with them.
The usual problems may be missing documents, mixed data formats between current and files,
errors in data translation, missing data etc.
5.3Results & Advantages
Interpretation of the Result
The system has been implemented and tested successfully. It meets the information Requirements
specified to the great extent. Although the system has been designed keeping the Present and
future requirements in mind and made very flexible. There are limitations of the System. Proper
consideration has been given for a wide range of new enhancements in The future, throughout the
development of system. The system is developed user friendly. In future, if it is required to

generate reports other than provided by the system, it can be simply achieved by a separate module
to the main menu without affecting the design of the system.
ADVANTAGES
 It simplifies the operation.

 It avoids a lot of manual work.
 Avoids errors by avoiding the manual work.
 User friendly screen to enter the data and enquire the database tables.
 User can easily access the system without much experience.
 Provide Hardware and software securities.
 It provides security to the data.
 Portable and flexible for further extension.
 The access to the Server information is more secured by using the Authentication
process of manager.
5.3. Testing
Testing is a process to show the correctness of the program. Testing is needed to show
completeness, it improve the quality of the software and to provide the maintenance aid. Some
testing standards are therefore necessary reduce the testing costs and operation time.
Testing software extends throughout the coding phase and it represents the ultimate review of
configurations, design and coding. Based on the way the software reacts to these testing, we can
decide whether the configuration that has been built is study or not. All components of an
application are tested, as the failure to do so many results in a series of bugs after the software is
put to use.
5.3.1.1. Test Plan Overview

Test Plan is defined as a strategic document which describes the procedure how to perform various
testing on the total application in the most efficient way.
 This document involves the scope of testing,

 Objective of testing,
 Areas that need to be tested

 Areas to be automated, various testing tools used
Test Development:
1. Test case Development (check list)

2. Test Procedure preparation. (Description of the test cases)
Test Execution:
1. Implementation of test cases. Observing the result.

Result Analysis:
1. Expected value: is nothing but expected behavior of application.

2. Actual value: is nothing but actual behavior of application.
Bug Tracing: Collect all the failed cases, prepare documents.
Reporting: Prepare document (status of the application)
5.3.1.2. Features to be tested (Summery of findings)

I. Black box testing
Black box testing also called behavioral testing, focuses on the functional requirements of
software. This testing approach enables the software engineer to derive the input conditions that
will fully exercise all requirements for a program. Black box testing attempts to find the errors like
 Incorrect or missing functions

 Interface errors
 Errors in data structures or external database access
 Behavior or performance errors
 Initialization and termination errors
In Black box testing software is exercised over a full range of inputs and outputs are observed for
correctness.
II. White Box Testing

White box testing is also called Glass box testing is a test case design control; structure of the
procedural design to derive test cases using White box testing method, the software engineer can
derive the test cases that guarantee that all independent paths within the module have been

exercised at least once. Exercise all logic decisions on their true or false sides. Execute all loops at
their boundaries and within their operational bounds. Exercise internal data structure to ensure
their validity.
5.3.1.3 Test Approach
Testing can be done in two ways:
 Bottom up approach
 Top down approach
Bottom up approach: Testing can be performed starting from smallest and lowest level modules
and proceeding one at a time. For each module in bottom up testing a short program executes the
module and provides the needed data so that the module is asked to perform the way it will when
embedded within the larger system. When bottom level modules are tested attention turns to those
on the next level that use the lower level ones they are tested individually and then linked with the
previously examined lower level modules.
Top down approach: This type of testing starts from upper level modules, since the detailed
activities usually performed in the lower level routines are not provided stubs are written. A stub is
a module shell called by upper level module and that when reached properly will return a message
to the calling module indicating that proper interaction occurred. No attempt is made to verify the
correctness of the lower level module.
5.3.3. Software testing strategies

Testing involves
 Unit testing
 Integration testing
 System testing
 Acceptance testing
The first level of test is unit testing. The purpose of unit testing is to ensure that each program is
fully tested.

The second step is integration testing. In this individual program units or programs are integrated
and tested as a complete system to ensure that the software requirements are met.
The third step System testing is actually a series of different tests whose primary purpose is to fully
exercise the computer-based system.
Acceptance Testing involves planning and the execution of various types of tests in order to
demonstrate that the implemented software system satisfies the requirements. Finally our project
meets the requirements after going through all the levels of testing.
5.4. Test Case Specification

Test scope:
1. Test coverage is provided for the screen “Contraction project Management status entry”
form of a project, employee, Material, Scheduling, modules of CMS application.
2. Areas of the application to be tested
For Home page

CHAPTER SIX
Conclusion, Summery of finding, and recommendation
6.1. Conclusion
 Our group in doing the study the team has tried to follow design methodology. Since the
success and failure of any system depends on gathering the right information through different
fact-finding techniques and user involvements.
 After a detail review and study of the existing system develop police office management
system for Nekemte town models have been designed to reflect the new system that is
supposed to solve problems.
6.2. Summary of finding
The current police office management system for Nekemte town is manual file handling system.
The great challenge when to develop this system
 Lack of finance.
 Lack of power.
 Virus attacks the software.
 Lack of enough reference.
 Lack of time and etc.. Is great challenges and to help on our summary of findings.
 The summary of our group members are findings to develop police office management
system for Nekemte town and change manual to automated (Computerized) system.

6.3. Recommendation
Based on our experience in the process of this project undertaking and as the computer science
professionals we recommend:-
 We recommend the Organization to which the system is developed to strictly follow the
user training requirements listed in the user training section for the respective users to
effectively use the system.
 We want to recommend any students, who have the intension to update, change and modify
this project.
 In general we are hopeful to our recommendation will be get the spectators and performed
for the next coming of our follower batch students.

7. References
Borland International (1991). Borland C++ 3.0 Library Reference, Scotts Valley, CA: Borland
International. Borland International (1991). Borland C++ 3.0 Programmer’s Guide, Scotts Valley,
CA: Borland International. Cantù, Marco (1995). Mastering Delphi [incl. CD-ROM], Alameda,
CA: Sybex. Sprigg, Graham (ed.) (1995). Image Processing, Volume 7: Issues 1-6. Jackson,
Richard and MacDonald, Lindsay and Freeman, Ken (1994). Computer Generated Color: A
Practical Guide to Presentation and Display, Glasgow, Scotland: John Wiley & Sons. Langdon,
Glen G., and Rissanen, Jorma (1981).

Online Police Office Management System

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Police Office Management System

Uploaded by

Copyright:

Available Formats

RIFT VALLEY UNIVERSITY NEKEMTE CAMPUS

DEPARTMENT OF COMPUTER SCIENCE

ONLINE POLICE OFFICE MANAGEMENT SYSTEM FOR THE NEKEMTE TOWN.

ADVISOR NAME: GETACHEW DIRIBA (MSC)

DEPARTMENT OF COMPUTER SCIENCE

ONLINE POLICE OFFICE MANAGEMENT SYSTEM FOR THE NEKEMTE TOWN.

No Name ID Number Signature

ADVISOR NAME: GETACHEW DIRIBA (MSC)

Advisors Name: Signature: Date:

Internal Examiner: Signature: Date:

External Examiner: Signature: Date:

Chair Person: Signature: Date:

RVU Computer Science Extension 2022 Page I

DB……………………………………………………… Data Base

DFD……………………………………………………..Data Flow Diagram

HTML…………………………………………………..Hyper Text Markup Language

OFF NUM……………………………….………..……Office Number

POMS……………………………………….……..….. Police Office Management System

PODB……………………………………………..……Police Office Data Base

PW……………………………………………………... Pass Word

PUB Name………………………………………………Public Name

POL Id…………………………………………………Police Identification

Sec Id……………………………………………………Section Identification

Sec Name………………………………………………..Section Name

TCP/IP……………………………………………...…..Transfer Control Protocol/Internet Protocol

TVM…………………………………………………….Time Value of Memory

RVU Computer Science Extension 2022 Page II

RVU Computer Science Extension 2022 Page III

RVU Computer Science Extension 2022 Page IV

RVU Computer Science Extension 2022 Page V

4.1.8.2 Physical and logical connectivity

4.1.8.3 Software Mapping

Implementation And Testing

5.1 Implementation Method

5.2 Implementation Plan

5.3 Results and Advantages

Test Plan Overview

Features to be tested (Summery if finding)

Software Testing Strategy

Test Case Specification

Conclusion, Summery of finding, and recommendation

6.2 Summery of finding

RVU Computer Science Extension 2022 Page VI

1.2 Strength and Weakness of Existing System

The strength of current Nekemte town police office is explained as follows:

 Police man works with justice office to keep crime

RVU Computer Science Extension 2022 Page 1

1.2.2 Weakness of the current system

1.3 Back ground of the project

RVU Computer Science Extension 2022 Page 2

 File control mechanism is very tedious & complicated.

1.5 Objective of the project

1.5.1 General objectives

RVU Computer Science Extension 2022 Page 3

 Reporting forms are available on webs.

1.7 Feasibility study

1.7.1 Operational/ Organizational Feasibility

1.7.2 Technical Feasibility

RVU Computer Science Extension 2022 Page 4

1.8 Budget breaks down and work plan

No. List of Items Unit Quantity Unit Price Total Price

Stapler Pcs 1 150.00 150.00

Total money required for payment per year=40250012= 1, 200,000.00Birr