Advised by Mr.

Getnet Kornsa

Wolkite University, Wolkite, Ethiopia

Submission Date: Friday, June 22, 2018

 APPROVAL SHEET
This is to confirm that the project report entitled “Accident information Management System
for Wolkite Police station” submitted to Wolkite University, College of Computing and
Informatics department of (Computer science) in partial fulfillment of the requirement for the
award of the degree of Bachelor of Science in (Computer science) is an original work carried out
by under my guidance. The matter embodied in this project is reliable and is genuine work done
by the student and has not been submitted, whether to this University or to any other University
/Institute for the fulfillment of the requirement of any study.
Student Team Approval Form
Student Name Student Signature
------------------------------------ ---------------------------------
----------------------------------- ----------------------------------
----------------------------------- ----------------------------------
----------------------------------- ----------------------------------
----------------------------------- ----------------------------------
Advisor and Department Head Approval Form
Advisor Name Advisor Signature
------------------------------------------ ------------------------------
Department Head Name Department Head Signature
------------------------------------------- -------------------------------
Examiner Approval Form
Examiner Name Examiner Signature
-------------------------------- ---------------------------------------
-------------------------------- ---------------------------------------
--------------------------------- ---------------------------------------

i
Acknowledgement
First of all, we would like to thank our almighty God, who gives us love, patience,
healthy, wisdom and ability to walk through all the problems and obstacles during the period
of our document preparation. Secondly, we would like to thanks to our advisors Mr. Getnet Kornsa
for their willingness of constructive, invaluable, Suggestions and comments until the completion
of the documentation of the project .And next for all college of computing and Informatics staff
who contributed in the development of this document. Thirdly, we also like thanks for our
classmates for their help in sharing idea. Fourthly, we would like to say thanks Wolkite police
station office for giving us full information about how the current system work. Finally, thanks to
group members and other peoples who support us for our project document completion.

ii
Abbreviations
AIMS--------------------------------Accident Information management system

API ---------------------------------------Application programming interface

BR ----------------------------------------Business Rule.

HTTP ------------------------------------Hypertext transfer protocol.

MySQL ------------------------------- My Structural Query Language

MVC ------------------------------------Model, View, Controller

OOSAD ----------------------------------Object Oriented System Analysis and Design

PHP---------------------------------------Hypertext Preprocessor.

SNNPR-------------------------------- Southern Nations, Nationalities, and Peoples' Region.

SQL ------------------------------------- Structural Query Language

UI ----------------------------------------User Interface
UML ------------------------------------Unified modeling language.

iii
Table of Contents

Contents
APPROVAL SHEET ................................................................................................................................... i
Acknowledgement ....................................................................................................................................... ii
Abbreviations ............................................................................................................................................. iii
Table of Contents ....................................................................................................................................... iv
List of Tables ............................................................................................................................................ viii
Abstract....................................................................................................................................................... ix
Chapter One ................................................................................................................................................ 1
1.1 Introduction ........................................................................................................................................... 1
1.2 Background about the organization .................................................................................................... 1
1.3 Statement of the problem ..................................................................................................................... 1
1.4 Objective ................................................................................................................................................ 2
1.4.1 General objective ........................................................................................................................... 2
1.4.2 Specific objective ............................................................................................................................ 2
1.5 Scope and Limitation of project .......................................................................................................... 2
1.5.1 Scope of project .............................................................................................................................. 2
1.5.2 Limitation of the project................................................................................................................ 3
1.6 Significance and Target beneficiaries of the system .......................................................................... 3
1.6.1 Significant of the project ............................................................................................................... 3
1.6.2 Beneficiaries of project .................................................................................................................. 3
1.6.2.1 Police station ............................................................................................................................ 3
1.6.2.2 Citizens ..................................................................................................................................... 4
1.6.2.3 Police Department .................................................................................................................... 4
1.6.2.4 Team member ........................................................................................................................... 4
1.7 System Development Methodology...................................................................................................... 4
1.7.1 Data collection ................................................................................................................................ 4
1.7.2 Data Analysis .................................................................................................................................. 5
1.7.3 System development tool ............................................................................................................... 5
1.8 Feasibility study of the new system ..................................................................................................... 5
1.8.1 Technical feasibility ....................................................................................................................... 5
1.8.2 Economic Feasibility ...................................................................................................................... 5

iv
 1.8.3 Operation feasibility ...................................................................................................................... 5
1.8.4 Political feasibility .......................................................................................................................... 5
1.9 Document Organization ....................................................................................................................... 6
Chapter Two ................................................................................................................................................ 7
Description of the Existing System .............................................................................................................. 7
2.1 Introduction ........................................................................................................................................... 7
2.2 Organization structure ......................................................................................................................... 7
2.3 users in the existing system .................................................................................................................. 8
2.4 Major functions of the Current System .............................................................................................. 8
2.5 Existing System Workflow structure .................................................................................................. 9
2.6 Report generated in the existing system ........................................................................................... 10
2.7 Forms and other documents of the existing systems ........................................................................ 10
2.8 Bottlenecks of the existing system...................................................................................................... 12
2.8.1 Performance (response time) ...................................................................................................... 13
2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)............................................. 13
2.8.3 Security and Controls .................................................................................................................. 13
2.8.4 Efficiency ...................................................................................................................................... 13
Chapter Three ........................................................................................................................................... 14
Proposed system ........................................................................................................................................ 14
3.1 Introductions ....................................................................................................................................... 14
3.2 Business Rules ..................................................................................................................................... 14
3.3 Functional Requirement ..................................................................................................................... 14
3.3.1. Performance requirements......................................................................................................... 16
3.3.2. Process requirements .................................................................................................................. 16
3.3.3. Input related requirements ........................................................................................................ 16
3.3.4. Output related requirements ..................................................................................................... 16
3.3.5. Storage related requirements ..................................................................................................... 16
3.4. Nonfunctional Requirements ............................................................................................................ 17
Chapter Four ............................................................................................................................................. 19
System Analysis ......................................................................................................................................... 19
4.1 Scenarios .............................................................................................................................................. 19
4.2 System models ..................................................................................................................................... 20
4.2.1 User class and characteristics (Actor Identification) ................................................................ 20

v
 4.2.2 Use case Diagram ......................................................................................................................... 21
4.2.3 Object model: Class Diagram ....................................................................................................... 40
4.2.4 Sequence Diagram ....................................................................................................................... 42
4.2.5 Activity Diagram .......................................................................................................................... 49
4.2.6 State Diagrams .............................................................................................................................. 53
Chapter Five .............................................................................................................................................. 59
System Design ............................................................................................................................................ 59
5.1. System Overview ................................................................................................................................ 59
5.2. Design Considerations ....................................................................................................................... 59
5.2.1 Design Goals ................................................................................................................................. 59
5.2.2 Design Trade-offs ......................................................................................................................... 60
5.3. Architecture of the proposed System ............................................................................................... 61
5.3.1 Sub-system Decomposition ........................................................................................................ 62
5.3.2 Hardware/Software mapping (Deployment design) ............................................................... 64
5.4.3 Persistent data management ....................................................................................................... 66
5.3.4 Class interfaces ............................................................................................................................. 68
5.4 User interface design........................................................................................................................... 73
Chapter six................................................................................................................................................. 76
Implementation and testing ..................................................................................................................... 76
6.1 Introduction ...................................................................................................................................... 76
6.2 Hardware software acquisitions ........................................................................................................ 76
6.3 User manual preparation ................................................................................................................... 77
6.3.1 Tanning ......................................................................................................................................... 77
6.3.2 Installation process ...................................................................................................................... 77
6.3.3 Startup strategy ............................................................................................................................ 77
6.4 Algorithm ............................................................................................................................................. 78
6.5 Maintenance ........................................................................................................................................ 84
6.5.1 Maintaining code .......................................................................................................................... 84
6.5.2 Maintaining database .................................................................................................................. 84
6.5.3 Maintaining user interface .......................................................................................................... 84
CHAPTER 7 .............................................................................................................................................. 85
Testing plan ............................................................................................................................................... 85
7. 1 Introduction ........................................................................................................................................ 85

vi
7.2 Purpose................................................................................................................................................. 85
7.3 Features to be tested and not to be tested ......................................................................................... 85
7.3.1 Features to be tested .................................................................................................................... 85
7.3.2 Features not to be tested .............................................................................................................. 86
7.4 Sample Test Cases ............................................................................................................................ 86
7.5 Test Procedure .................................................................................................................................... 90
7.5.1 Unit Testing .................................................................................................................................. 90
7.5.2 Integration Testing.................................................................................................................... 90
7.5.3 System Testing.............................................................................................................................. 90
7.5.4 Acceptance Testing ...................................................................................................................... 91
Chapter Eight ............................................................................................................................................ 92
Conclusion ................................................................................................................................................. 92
8.1 Summary of Final product ................................................................................................................. 92
8.2. Recommendation................................................................................................................................ 92
References ................................................................................................................................................... 93

vii
 List of Tables
Table 1 use case description for login ......................................................................................................... 26
Table 2 use case description for Adding user ............................................................................................. 27
Table 3 use case description for Updating user count................................................................................. 28
Table 4 use case description for Delete user account ................................................................................. 29
Table 5 use case description for updating record ........................................................................................ 30
Table 6 use case description for deleting records ....................................................................................... 31
Table 7 use case description for Emergency report .................................................................................... 32
Table 8 use case description for Open incident .......................................................................................... 33
Table 9 use case description for Accident Handle report ........................................................................... 34
Table 10 use case description for Active report .......................................................................................... 35
Table 11 use case description for Posted information ................................................................................ 36
Table 12 use case description for View posted information ....................................................................... 37
Table 13 use case description for Add resource ........................................................................................ 38
Table 14 use case description for Allocate Resource.................................................................................. 39
Table 15 use case description for Logout ................................................................................................... 40
Table 16 Test case to register account ....................................................................................................... 87
Table 17 Test case to Login ........................................................................................................................ 88
Table 18 Test case to send report ................................................................................................................ 89

viii
List of Figures
Figure 1 Organization structure .................................................................................................................... 8
Figure 2 Existing System Workflow structure .............................................................................................. 9
Figure 3 Use case diagram .......................................................................................................................... 22
Figure 4 Despatcher detail diagram ............................................................................................................ 23
Figure 5 Accident Control Team detail diagram ........................................................................................ 24
Figure 6 Field Officer Detail diagram......................................................................................................... 24
Figure 7 Society detail diagram .................................................................................................................. 25
Figure 8 Class Diagram .............................................................................................................................. 41
Figure 9 Login sequence Diagram .............................................................................................................. 42
Figure 10 Updating Database Sequence Diagram ...................................................................................... 43
Figure 11 Deleting record sequence Diagram............................................................................................. 44
Figure 12 Generate Emergency Report Sequence Diagram ....................................................................... 45
Figure 13 Accident handle report Sequence Diagram ................................................................................ 46
Figure 14 Add user account sequence diagram........................................................................................... 47
Figure 15 Add resource sequence diagram ................................................................................................. 48
Figure 16 Login activity diagram................................................................................................................ 49
Figure 17 Accident Report generation activity diagram ............................................................................. 50
Figure 18 accident handle activity diagram ............................................................................................... 51
Figure 19 Update activity diagram.............................................................................................................. 52
Figure 20 Create Account activity diagram ................................................................................................ 53
Figure 21 State chart Login Diagram .......................................................................................................... 54
Figure 22 Report emergency state diagram ................................................................................................ 55
Figure 23 Post Information state diagram ................................................................................................... 56
Figure 24 Post View state diagram ............................................................................................................. 57
Figure 25 Update State diagram.................................................................................................................. 58
Figure 26 Architecture of the proposed System.......................................................................................... 62
Figure 27 Sub-system Decomposition ........................................................................................................ 63
Figure 28 Hardware/Software mapping ..................................................................................................... 65
Figure 29 Persistent data management........................................................................................................ 66
Figure 30 Class interfaces of Resource ....................................................................................................... 68
Figure 31 Class interface of Emergency report........................................................................................... 69
Figure 32 Class interface of Incident Handle report .................................................................................. 70
Figure 33 Class interface of society............................................................................................................ 71
Figure 34 User Home page Interface .......................................................................................................... 73
Figure 35 Admin/Dispatcher page Interface ............................................................................................... 74
Figure 36 User emergency report interface................................................................................................. 75

viii
 Abstract
The project developing as web based Accident Information Management (AIM) system for
Wolkite Police station. The purpose of this project is changing the existing system in to Centralized
information control and improved accessibility of data. In Accident Information management
system institution for Wolkite city police station the emergency report generate and manage file
even today very old practices used. This may leads them for lack of security, resource
consumption. Proper generation of report take time to produce, Retrieval of information takes a
lot of time, Need large space to store file and Human energy loss. The main objective of this
project is solving problems by identifying problems in the existing system and we analyses the
problem, gather requirements and designing of the system to solve existing system problem. This
project can perform many functions like Manage file, Manage account, manage resource, post new
and Emergency report generating. The project is web based so it is user friendly system and it
provide more significant for the user, developer, and the organization.

ix
 Chapter One
1.1 Introduction
Accidents are global problems affecting all sectors of society. It brings huge economic loss to the
global economy in every fiscal year. The development of one country is analyzed from many
direction or factors such as peace, security of the people and their property etc. Those are protected
by accident management station such as police and society. The institution of accident
management station is standing to protect peoples and their property from danger. Our project
aimed to develop new web based accident information management system. The proposed system
applies to accident information management institution all across the country and specially looks
in the subject of accident information management system of Wolkite city. The efficiency of the
accident controlling and the effectiveness with which it deals with accident depend on what
quality of information it can drive or received from where the accident is occur and how fast it
can have response to it.

1.2 Background about the organization

Wolkite city police station is one of the institutions of accident information management station
in SNNPR of Ethiopia that standing to protect peoples and their property from danger .It was
established long years ago to give service to protect Wolkite city from suddenly accident. The
station has the responsibility for receiving the accident sound and having quick response to the
received accident sound and storing the nature of the accident, the location details, the sequence
of the accident, information on victims.

But still this task is managed manually beginning from collecting and recording data about the
accident and the technique of response to the accident. The accidents that can be happened either
natural or human made. Some of these are traffic accident, fire accident, killing or murder, flood,
electric current accident, earth quake etc.

1.3 Statement of the problem

Wolkite city police station accident management system apply manual way of implementing
tasks. The police station face the following problem:-

 Accident file control mechanism is very tedious and complicated.

 Data redundancy and inconsistency.

1
 Difficult of communication of field office, society and the station to give and get real time
response to the accident.
 Difficult to generate report.
 Difficult of getting available resource to control and detect the accident at real time and to save
human life and property.
 Difficult in conducting consistent reports because the record is documented
manually and require much time and human power to search and get wanted information (file).
 There is no fast and efficient way of sharing critical information across the station as well as
with the external environment.
 The current system high work load for staff of police department.
 Also there is security problem, the existing system is manually system in which document are
stored in packed paper files so that the file are highly exposed to damage and can be stolen by
any other unauthorized person or group.

1.4 Objective
1.4.1 General objective
The general objective of this project is developing web based accident information management
system for wolkite city police station.

1.4.2 Specific objective

 Reviewing how the current system works and operates.

 Find the solution for the problem found in existing system

 Investigating how the existing system is operating.

 Analyze the current system to design new data base system operated easily using web based
system.

 Develop user friendly or interactive interface design.

1.5 Scope and Limitation of project

1.5.1 Scope of project
This project will be developing web based system for Wolkite city police station .On completion
of this project we expect the system will have with less effort and cost the system is able to maintain
and store information, accurate way of recording and storing information in to the database, post

2
information (post unknown people die in accident), report accident, Presence of centralized
documented and organized record, Learn society they protect from accident, facilitate timely
management decision making and enable to have real time response to the accident detect it,
enabling the workers of the system to get reliable information where and when occurred as well as
the type and level of accident to give reliable to response on detecting the accident, the can use
English language, total number of each accident can be see easily and they can be prepared report
easily.

1.5.2 Limitation of the project

There are many constraints within our proposed system that limit their effectiveness of
performance. Our system is limited only in the process of web based accident information
management system of the Wolkite city police station. It does not include about crime file
management system and the system depends on electric power and network connection.

1.6 Significance and Target beneficiaries of the system

1.6.1 Significant of the project
 The new web based accident management is system which is customized to the Wolkite
city police station.
 The most important feature of the new system is that it is an accurate , easy and efficient
system to report detect accident as well as record accidental information such as date
and time when the accident occur, location and level of the accident.
 Simple and user friendly.
 It is enable searching the required information by using keys and also the main function
of the system is sharing of information to the appropriate of different station.
 Easy to maintain, fast, and accurate.
 Total number of each accident can be see easily.
 Learn society about they protect them self from accident.

1.6.2 Beneficiaries of project

1.6.2.1 Police station
 Avoiding improper resource consumption like paper, pen.
 Avoiding data loss because of improper data storage.
 Neat investigation files in the station can be transfers from generation to generation.

3
 Enhance security mechanisms to protect crime records.

1.6.2.2 Citizens
 Multiple channels to access services from police.
 Simplified process for reporting the accident.
 Can view posted information’s by the station anywhere at any time.
 Faster and assured response from police to any accident

1.6.2.3 Police Department

 Enhanced tools for investigation.
 Facilitates fast and efficient retrieval of data.
 Can post necessary information to society easily.
 Reduced workload of the police station back-office activities.
 Can easily control the system.
1.6.2.4 Team member
 The team member can get knowledge.

1.7 System Development Methodology

1.7.1 Data collection
 Interview

The project team had interviewed Wolkite city police station manager and other member police as
well as some peoples who live in the city too deeply understand the manual system and to develop
the proposed system perfectly.

 Document Analysis

Document analysis is used to understand how the system is working. We used this method to know
all about the police station mission, vision, function and overall of their work in short and brief.

 Questioners
We used this method to gathering information through preparing questions to user.

 Observation

4
The project team observed different things to get the overview of the existing system,
understanding the overall work flow and how everything is handled in and its overall system.

1.7.2 Data Analysis

The system will use object oriented system analysis and design (OOSAD) approach to analyze and
design the system based on the data collected from the old system.

1.7.3 System development tool

 Hardware tools:-
 Desktop computer/laptop.
 Displaying devices like printer and monitor.
 Storage devices: hard disk, flash disc.
 Internet cable
 Software tools:-
 Microsoft word 2013:- to prepare documentation.
 Microsoft PowerPoint: - to prepare slide shows.
 Apache server: - to facilitate works as local server.
 MYSQLI: - to store information.
 Notepad++: - to write different codes(PHP, CSS, JavaScript)
 Edraw max: - to Design UML diagrams.

1.8 Feasibility study of the new system

1.8.1 Technical feasibility
Our project can be done with current equipment, existing software technology and available
personnel and therefore it can be conclude that the system is technical feasibility.

1.8.2 Economic Feasibility

The system to be developed is economically feasible and the benefit is out weighting the cost.
Since this project already computerize the existing system by now there diction of cost for
materials used in manual operation becomes beneficiary to the organization.

1.8.3 Operation feasibility

The system to be developed will provide accurate, secured service and decrease the labor work
load. Also the system will be easily operation, it does not affect the existing organization structure.
So the system will be operation feasibility.

1.8.4 Political feasibility

The system to be developed is not conflict with any government directly or indirectly.
5
1.9 Document Organization
This document consists of eight chapters. Chapter 1: has presented the introduction, Background
of the Organization, statement of the problem, objectives of web based AIMS project, Scope and
limitation of the project, Significance and Target beneficiaries of the system, Methodology for the
project, Feasibility Analysis . The second chapter deals about Introduction of Existing System,
Organization structure, Users of Existing System, Major functions of the Current System, Existing
System Workflow structure, Report generated in the existing system, Bottlenecks of the existing
system. The third chapter deals about the Proposed System that means Business Rules, Functional
requirements and Nonfunctional of proposed system. Chapter four is system Analysis that means
scenario, and System models. Chapter five is all about over view of system design, Design
Considerations, Architecture of the proposed System, user interface design and object design of
the system design. Chapter six is about Implementation that means Introduction of
implementation, hard ware and software acquisition, User manual preparation, Algorithm, and
Maintenance. Chapter seven is about testing plan this chapter includes introduction testing plan,
Purpose, Features to be tested and not to be tested, Sample Test Cases , Test Procedure, and
Release criteria. The last chapter is all about summary of finally product, and Recommendation.

6
 Chapter Two
Description of the Existing System
2.1 Introduction
In this chapter we studied the existing system deeply, since it is necessary to know the existing
working system so as to develop a better system. When we studied the existing system we gave
emphasis for here under listed questions.

 How the existing system is working?

 What kind of method they use to handle accident data?
 In what way the police office is generate Report?

After studying the existing system, we also determined the requirement or the feature that must be
included in the proposed system. Furthermore by analyzing the current system, we could also
estimate how the propose system solve the setbacks of the existing system.

2.2 Organization structure

Dispatcher

Accident Control Team Field Officer

Information desk Society

7
 Figure 1 Organization structure

2.3 users in the existing system

The existing system enables the Field officer:

 If the field officer exist in accident place report the accident to the dispatcher in police
station.
 Directly work with society.
 Collect all necessary information about the accident.

The existing system enables the society:

 If society see the accident happen directly report the accident

 He/she report in two way either in telephone or physically going to police station.
 Send their comment either in oral or written form

The existing system enable the Dispatcher:

 The dispatcher accept the emergency accident report and based on emergency report
assign resource and give information to accident control team.
 The dispatcher checks the availability of resources
 View previous accident report

The existing system enable the Accident controlling team:

 Accident report the dispatcher send accident controlling team in the place of the accident.

2.4 Major functions of the Current System

Report accident: - in the existing system the emergency accident reported in two way. First is
society calling telephone to police station most time the telephone is busy. Second the society
come to police station in physically.

Generate report:-the report prepared in day, three day weeks, month, three month, six month,
year report. This report is major report generate time. All report generate is very tedious and
complex because all thing is done in manually so difficult to prepared report, especially the month,

8
three month, six month, year report are more difficult and additional task to police department to
search the file.

Store the accident file:-the existing system store the accident information in manually. This
method is not secured, also have not backup. The accident file only in one document if the paper
damage also damage the accident file.

2.5 Existing System Workflow structure

society

Field officer

Accident controlling
Dispatcher
team

Information desk

Figure 2 Existing System Workflow structure

When an accident occurs in a society, the society informs the occurrence and other reliable
information about the accident for the field officer. Then, the field officer informs the dispatcher

9
by preparing emergency report to detect the accident. After the dispatcher view the detail
information sent by the field officer, he/she allocates resource and sends the accident controlling
team to the place where the accident has occurred.

2.6 Report generated in the existing system

Each station prepares and presents report daily, weekly, monthly, in 3 months, in 6 months, and
per year for the main station wolkite city police station. In the same way the main station of the
city prepare report based on the reports collected from the sub-stations and presents it for the Zone
station. Daily reports can be by paper, if the substation is near to the main station or simply by
using telephone if it is not possible, but weekly and further longer time reports would be reported
with paper and all data would be given to the information desk controller.

2.7 Forms and other documents of the existing systems

Form of accident investigation report form

10
Accident/Incident Report Form

Date of incident: _______________ Time: ________ AM/PM

Name of injured person _____________________________________________

Address:

__________________________________________________________

Phone

Number(s): ________________________________________________________

Date of birth: ________________ Male ______ Female _______

Who was injured person? (Circle one) Passenger System Employee

Type of injury _____________________________________________________

Details of accident

__________________________________________________________

11
__________________________________________________________

Signature date

2.8 Bottlenecks of the existing system

In wolkite city police station accident management apply manual way of implementing tasks. It
will be face many technological problem to site some this multiphase factors in the case of police
station are the following problem problems

 Difficult of getting real information at real time when accident occurred that help to have
real time response to accident.
 Difficult to manage the overall system.
 Accident file control mechanism is very tedious and complicated.
 Data redundancy and inconsistency
 Difficult of communication of field office, society and the station to give and get real time
response to the accident.
 Difficult to generate report
 The officer loss the paper that write the report is also loss the information about the
accident.
 Difficult of getting available resource to control and detect the accident at real time and
to save human life and property since there is no organized detective in the system to
control the accident rather than the society and police are tries to detect the accident as
much as possible.
 Difficult in conducting consistent reports because the record is documented manually and
require much time and human power to search and get wanted information (file).
 There is no fast and efficient way of sharing critical information across the station as well
as with the external environment.
 System has work load for police department.
 Also there is security problem as we mentioned before, the existing system is manually
system in which document are stored in packed paper files so that the file are highly
exposed to damage and can be stolen by any other unauthorized person or group.

Generally the existing system have a number of problems according to their:-

12
2.8.1 Performance (response time)
The performance of the existing systems is very low because all activities can be done in manual
form this manual activity can consume more time and takes more response time.

2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)

Data is not accurately captured if it contains errors. Then the input data is not validated Information is
redundantly generated, also system is inflexible to change. According to that it might not get relevant
information.

2.8.3 Security and Controls

The existing system is manually system in which document are stored in packed paper files so that
the file are highly exposed to damage and can be stolen by any other unauthorized person or group.

2.8.4 Efficiency
In existing system, there is no efficiency because all activities performed manually in the paper. It
can reduce the efficiency of the system. As we observed in existing system to perform some action,
it takes more time and many resources and it results economic problem

13
 Chapter Three
Proposed system
3.1 Introductions
The main aim of this project is to automate the current system and it will solve the problems that
are exists in the manual system. We are going to design a web application that address the existing
system problems. This chapter will fully describe Business rules, all the functional and
nonfunctional requirements, and other factors necessary to provide a complete and comprehensive
description of the requirements in accident management system for Wolkite city.

3.2 Business Rules

Identifying the business rule of the proposed system will help us to specify and
describe each use case in effective way. The business rules of the accident information
management system are listed as following:-

Br1: The society inform the emergency to the field officer.

Br2: The field officer generate report to the dispatcher.

Br3: Dispatcher police officer view the incident report that come from field officer and should
work for 24 hours to accept accident reports

Br4: Allocating resource based on the emergency report.

Br5: The dispatcher send notification to the Accident control team.

Br6: The Accident Controlling Team should go to the place where the accident has occurred.

Br7: Then the accident Controlling Team generate accident active report when it’s needed and the accident
should get fast response.

3.3 Functional Requirement

The new system will be a networked application that will run on client-server and to
provide case to use user interfaces to the users and window server for the server side
application.
All the functionalities that will be provided by the system are the following:

14
Manage accident report: system easily manage accident report because everything should be
done in web based. Accident report Date, accident Time, Information Type, Place of accident,
Name of Police, and Received Time take the system as input. After inputting data validation checks
on various fields is performed. On submission of the information the record is stored on database.
If the submitted information is valid, and found in the database then the corresponding record is
displayed.

Manage accident file: manages accident file using web based system in manner that more
secured than previous system. Every accident record in a database so, the system user can simply
access and make the system secured from illegal or unauthorized users or persons.

Manage resource: Manage resource that means added resource, allocate /Set/resource and check
the availability resource is easily performed by the new system.

Emergency accident report online: The Users would be able to emergency accident online
without coming to the police station office by using the proposed system. The society and the field
officer report emergency accident easily using the proposed system. The users of the system fill
all the necessary information, if enter the data correct the system report to dispatcher and get the
acknowledgement.

Sending SMS: Our system will send SMS notification so as to inform the emergency accident to
the wolkite police station.

Update accident information: The system able to search, insert, delete and update the accident
information when it is needed in propose system they can update easily because all data are in the
database so we can update easily and in short time.

Posting news: the system can post news for the society in order to make them inform about the
some additional information.

Retrieve accident files: we can easily retrieve the accident information from database by only
enter the accident number, and accident type name. Then the system checks that accident type and
accident number the system processes it if it valid display the information.

15
Poste unknown people die in accident: this very important for new system because
someone come other place then sadly die in accident. So the user of the system is post easily this
person using this automate system.

The accident information management system can do the following functions those are: -

3.3.1. Performance requirements

For the enhancement of performance of the new system, we require compatible & supporting web
browsers, secured database for storage & retrieval of accurate data, validated input is only accepted
by the system.

3.3.2. Process requirements

The system can be accessible based on the accessible privilege or based on authentication.

The system automatically gives the form to fill to the users of the system whom want to report the
accident. Data error from the user’s end and from the back-end database-processing
end must be gracefully handled.

3.3.3. Input related requirements

The system shall have the form to accept the accident report detail.

The above requirements are input related requirements of our system, and the facilities that
the system uses to take inputs from the users are listed below:

Forms: This makes users fill their forms, which is required to be filled.

Dialog: This enables users to make their confirmation for any request.

3.3.4. Output related requirements

The system shall allow a Society to sees the posted information by Dispatcher. The system should
allow the administrator/Dispatcher to view incident report from which are reported by Field officer
and Accident control Team.

3.3.5. Storage related requirements

The proposed system requires central database to store every accident information and easily
retrieve the accident information by only enter the accident no, and accident type name. Among
our system functionality: -

16
  The system should allow accidents report data stored in to the database.
 The system should allow to store data in organized manner, which must be easy to access.
 The system should allow to modify stored data easily.
 The system allows updating, modifying and even deleting the existing information.

3.4. Nonfunctional Requirements

Non-functional requirements describe user-visible aspects of the system that are not directly
related with the functional behavior of the system. These requirements do not directly affect the
performance of the system but are nonetheless important. They are concerned with security,
performance, internationalization, usability, maintainability, reliability, modifiability, efficiency,
portability across operating systems, testability, and understandability. Generally the non-
functional requirements of the system are presented below:

 Speed: AIMS will respond the requested task and operation quickly as fast as possible.
 Reliability: the system should be reliable in retrieving and displaying only the requested
data for the user. Users can rely on the information be gotten would be true and dependable.
 Security: The system will apply security mechanisms in which users can only
access information and perform any operation through their privilege. Only authenticated
users can access the system.

Security measures are provided to prevent unauthorized access of the system at various levels.
Security is the main issue to protect and secure the entire project to unintended loss of data,
deletion of data and modification by unauthorized and unauthenticated users. We try to handle
this though

 Prevent unauthorized access of data: Users are restricted to access specifically what
the grant they are provided.
 Only assigned users can use the system to increase reliability.
 Prevent unauthorized by presentation of Use Name and password: Only authorized
user is use the system.
 Quality: The system allows putting backup of data and it fulfills all user requirements.

17
 User friendly interface: Simple and interactive user interface components should be part
of the system. This user friendly interface requirement of the system will be available in
any end user and system administrator interface of the application.
 Usability: The system provides a help and support menu in all interfaces or
give direct input for the user to interact with the system. The user can use the system by
reading help and support.
 Performance: Our system speed operation is very high. That means the accuracy and
response time of the system should be very fast.
 Availability: The system should always be available for access at 24 hours, 7 days a week.
 Maintenance: New additional features can be added if required and also the system
components i.e. memory, disk, drives shall be easily serviceable without much alteration
in the code.
 Generate error message for invalid inputs: Wrong input entry shouldn’t be accepted by
the system it should prevent and notify for the user so that wrong output will not be
generated.
 Portability: The system supports every operating system.

18
 Chapter Four

System Analysis
4.1 Scenarios
Scenario is the description that shows the process or steps while the interaction between the
system and user. We can describe scenario of the system as follows:-

Scenario Name: S #1
Actor: Dispatcher
Flow of event:
The dispatcher of the system activates the system to login in to the system and then enter his/ her
password and user name. The system checks either the entered Password or Username is correct
or not. If the Password and Username corrects then the user access system, if not the system
displays the message like “the Password or Username you entered is incorrect please try again!”

Scenario Name: S#2

Actor: Accident Control Team
Flow of event:
The accident control team of the system login in the system and click on accident handle button,
then the system displays accident handle form. The accident control team fill the form and click
on accident handle button then the system check the filled form and generate the accident handle
report.

Scenario Name: S#3

Actor: Field officer
Flow of event:
The field officer click the emergency report button and the system display the emergency report
fill form, then the field officer write into report form, next click the emergency report send button.
Then the system check the filled form and generate the accident emergency report.

19
4.2 System models
We can represent our system by using different system models such as use case models, object
models, Sequence Diagram, activity diagram, and state diagrams. The system models describe
problem to be solved and as system models represented by graphically they are more
understandable than more detailed natural language description of the system requirement.

4.2.1 User class and characteristics (Actor Identification)

Dispatcher: has the following responsibilities

 Has direct access the database

 Open accident reports

 Notifying field officer that it provide the report

 Manage resource

Allocating resource based on the emergency report come from field officer

Announcing accident control team to detect accident by having allocated resource

Managing staff

Information Desk: has the following responsibilities

 Retrieve data and give appropriate information to user and dispatcher
 Document and organize daily report come from Field officer and accident controlling team
with the final modification.
 Archive the data relative to duration they created
Accident controlling team: has the following responsibilities

 Detecting and controlling accident by going on the shortest path i.e. generated by the
system.
 Generate Handled accident detection report which includes the process of accident control
and effect of the accident.
 Active report
Field officer: has the following responsibilities

 Gathering information about the accident from the society.

20
  To generate emergency report and to send to the Dispatcher.
 Updating the report if any information is received.

Society: has the following responsibilities

Informing occurrence and cause of the accident

Participating on detection of the accident

4.2.2 Use case Diagram

A use case is a list of steps, typically defining interaction between a role or actor and the system
to achieve a goal. We can represent use case model by general system use case diagram and detail
diagram and description.

I. General system Use Case Diagram

21
 Accident information management
system

Check availability
resource

Allocate resource
Extend
Extend
Add resource
Update report
Manage resource Extend

<<Include>>

Request
<<
Open incident Inc emergency
lud
e>
Dispatcher >
Field officer
<<Include>>
<<
Inc
Send notice lud
e>
>
View request
<<
Inc
lud
e>
>
<<Include>>
Post information
<<Include>>
emergency request
<<Include>>
Manage staff Login
<<Extend>>

<<Extend>> View information

Update User
<<Extend>> <<Include>> Society

Delete User
<<Include>>
<<Include>>
View notice
Add User

Active report

Handled Incident
report

Accident Control
Team

Figure 3 Use case diagram

22
 II. Detail Diagram and description for each use cases

 Detail Diagram

Dispatcher Detail Diagram

Check availability
resource
d
ten
Ex
Extend Allocate resource
Manage resource Ex te
nd
Add resource
<<
Open incident << Inc
Inc lud
lud e>
e> >
>
<<In
c lude
Send notice >>
Login
>>
c lude
<<In
>>
Post information c lude
Dispatcher <<In

Extend
Add User
Manage staff Ex te
nd
Ex
ten
d Delete User

Update User

Figure 4 Despatcher detail diagram

23
 Accident Control Team Detail Diagram

View notice
>
e>
c lud
< <In
<<Include>>
Login Active report
<<In
c lude
>>
Accident Control
Team
Handle Incident
Report

Figure 5 Accident Control Team detail diagram

Field Officer Detail Diagram

Update report
>>
l ude
c
< <In
>> Request
c lude
<<In
Login emergency
<<
Inc
lud
e>
Field officer
>
View request

Figure 6 Field Officer Detail diagram

24
 Society Detail Diagram
emergency
request

Society
View information

Figure 7 Society detail diagram

25
  Description for each use cases
Use case description provides critical information needed to understand in what context the use
cases are and briefly explain how the functionalities precede using natural language in a step wise
manner. Here is the use case description for Wolkite city police station Accident management
system:

Use case: Login

Table 1 use case description for login

Use case Name Login

UC_ID UC_01

Actor Dispacher,Accident controlling team, Field officer, and information desk

Description This use case is used to ensure security for login into the system.

Precondition The user must have at least correct User Name and Password

Actor action System response

Step1: This use case is Step2: The system displays login form
initiated when the actors click Step5: The systems check authorization. If
on the login option she/he is authorized system displays the
Step3: The actor enter the main page if not display unauthorized
username and password message.
Step4: Click login button
Flow event
Step6: The user gets access
the User page.
Post condition The main page will be displayed then user gets access to it privilege and
after finishing his/her work he can logout
Alternative Step5.1: If the actor does not fill correct username and password then the
course of action systems display error message and return to step2.

26
 Use case: Adding User

Table 2 use case description for Adding user

Use case Name Adding user

UC_ID UC_02

Actor Dispatcher

Description It describes how to add a new user or account in the system.

Precondition The user should have logged in as Dispatcher

Actor action System response

Step1:The dispatcher clicks Step2: The system display the form.
On add user option. Step5: The system validates the new user detail.
Step3: The dispatcher enters new Step6: The system save the user detail to the

Flow event user name, account type, password database.

and reenter password to the Step8: The system display successful message
system. of adding new user.
Step4: The dispatcher click on Step9: The system ends.
Add new user button.
Step7:The dispatcher tells the
category, user name and password
to the user

Post condition The new user information are add to the database

27
 Use case: Updating user account

Table 3 use case description for Updating user count

Use case Name Updating user account

UC_ID UC_03

Actor Dispacher
It describes how the dispatcher modify the user database.
Description

Precondition The user should have logged in as dispatcher.

Actor action System response

Step1: The dispatcher wants to Step3: The system display appropriate user
update an account and he/she information.
login to the system. Step6: The updating process ends.
Step2: The dispatcher enter ID of

Flow event the user to be modified.

Step4: The Dispatcher update the
user information.
Step5: He/she clicks on Update
button.

Post condition The system modifies the records with the new entered data.
Alternative course of System restores the previous information if failure occurs.
action

28
 Use case: Delete user account

Table 4 use case description for Delete user account

Use case Name Delete user account

UC_ID UC_04

Actor Dispatcher

Description It describe how the dispatcher removes the user account from database.

Precondition The user should have logged in as Dispatcher

Actor action System response

Step1:The dispatcher wants Step3: The system display a delete form.
Flow event to delete the account and Step6: The system checks the entered information
He/She login to the system. with the existing account in the database.
Step2:The dispatcher Step7: The system sends message. “do you
Selects the delete Option. Want to delete?” to the dispatcher.
Step4: The dispatcher enters the Step9: The system delete the account from system
account type and Username of the Step10: End the use case.
user.
Step5: The dispatcher click on
delete button.
Step8: The dispatcher selects the
yes option.
Post condition The system removes the user details from record.
Alternative course of Step6.1: The system displays try again message.
action Step4.1: The system displays empty form.
Step8.1: The system ends if he/she selects no.

29
 Use case: updating record

Table 5 use case description for updating record

Use case Name Updating record

UC_ID UC_05

Actor Dispatcher, Information desk, and Field officer

Description This is for modifying the content of the database.
Precondition The user should have logged in as Dispatcher
Actor action System response
Step1: The Users wants to update Step3: The system display Update
an account and he/she login to the form.
system.
Flow event Step2:The users click on update
option
Step6: The system will check the
Step4: The users enter the accident
accident ID or number
ID or number.
Step7: The system sends message”
Step5:The users clicks on
does u want to update?”
Update button. Step9: The system updates the
.Step8:The users selects the
information.
Yes option.
Step9: The system displays
Step10: End the use case.
Successful message of updating.
Post condition The system saves the modified record to the database.

Alternative course of Step 6.1: displays “try again” message.

action
Step7.1: if the investigative users select the no option, the system displays
‘Updating aborted’ message.

30
 Use case: deleting records

Table 6 use case description for deleting records

Use case Name Deleting record

UC_ID UC_06

Actor Dispatcher, information desk

Description This is for dropping the content of the database.

Precondition The user should have logged in as Dispatcher

Actor action System response

Step1: The User wants to delete the step3: The system display delete form
record and he/she login to the system. page.

Flow event Step2: The user selects the delete Step6: The system checks the entered
option. information with the existing account in
the database
Step4: The user enters the accident
type and accident number. Step7: The system display message
Step5: The user click on delete button.
“Do you want to delete?” to the users
Step8: The users selects the yes
option. Step9: The system delete the record

Step 10 :The use case ends from the system.

Post condition The system removes the user details from the record

Step 6.1: If the enter accident type and accident number is incorrect the system
Alternative course of displays “try again” message.
action
Step7.1: if the investigative users select the no option, the system displays
‘Updating aborted’ message.

31
USE CASE: Emergency report

Table 7 use case description for Emergency report

Use case Name Emergency report

UC_ID UC_07

Actor Field officer, society

Description There must be accident and collected information about it.

There must be accident and collected information about it.
Precondition
Actor action System response

Step1: The user click emergency Step2: system display the emergency
report option. report form.

Flow event Step3: The user fill accident report Step5: The system checks the filled
form. form.
Step6: displays successful message to
Step4: Next click the emergency
user.
report button.
Step7: send emergency report to
Dispatcher.

Step8: End use case.

Post condition The system generated the report and displays successful message
Alternative course of Step5.1: if not correct display try again message.
action

32
 Use case: Open incident

Table 8 use case description for Open incident

Use case Name Open incident

UC_ID
UC_08

Actor
Dispatcher

Description This is used to view the emergency report.

Precondition The field officer must generate a new emergency report.

Actor action System response

Step1: The user wants to see the Step3: system display incident
incident and she/he login to system. reports.

Step2: And click on Incident link. Step 7:end use case

Flow event
Step4: User see the incident.

Step5: Notify accident controlling

team the accident

Step 6: Send the notification to field

officer.

Post condition Acknowledge field officer.

33
 USECASE: Accident Handle

Table 9 use case description for Accident Handle report

Use case Name

Accident Handle
UC_ID UC_09

Actor Accident controlling team

Description This is used to know daily, monthly, 3 months, half of year, and 1 year
information’s about the accident detections.

Precondition Accident must be handled or controlled.

Actor action System response

Step1: Accident Controlling Team Step3: System display handle
login to the system incident reports form.
Flow event Step2:Accident controlling Team
Step6: The system checks the filled
Click on handle link. form.
Step7: System generate the report to
Step4: The Accident controlling
the appropriate user.
Team fill the form

Step5:Click on the handle Step8: Display successful messages.

Step 9:End use case

report button

Post condition Accident controlling team protects the accidents.

34
 USECASE: Active report

Table 10 use case description for Active report

Use case Name Active report

UC_ID UC_10

Actor Accident controlling team

This is used to report information to the Dispatcher when the additional resource
Description need to the accident control team.

Precondition There must be accident.

Actor action System response

Step1: Accident Controlling Team login
to the system
Step2:Accident controlling Team
Flow event
Click on Active report link.
Step3: The system display active report
form.
Step6: The system checks the filled form.
Step7: The system generated the report

Step4: The Accident controlling Team to the selected user.

fill the form Step8: The system displays successful
message.
Step5: Click on the active report
button.

Step 8: The report process ends

Post condition Accident controlling team protects the accidents.

Alternative course of Step5.1: If the investigative officer enters invalid information then the system will
action generate an error message in order to fill again the information properly.

Step5.2: Use case ends

35
 Use case: Posted information

Table 11 use case description for Posted information

Use case Name Posted information

UC_ID UC_11

Actor Dispatcher

Description In this use case the Dispatcher can post information.

The dispatcher should have to enter a valid user name and
Precondition password to upload information.

Actor action System response

Step1: The dispatcher wants to post Step2: System display
new and clicks on post button. post form.
Flow event Step3: The dispatcher fills the needed Step4: The system checks
information. the filled form.
Step7: The report process ends. Step5: The system post
the filled information’s.

The user entered valid user name and password then he/she can
Post condition post the information.
Alternative course of Step 5.1: The system display an error message.
action

36
 USECASE: View posted information

Table 12 use case description for View posted information

Use case Name View posted information

UC_ID UC_012

Actor Society/User

Description
This use case allows the user to see posted information’s.

Precondition There should be posted information’s.

Actor action System response

Flow event Step 1: The user wants to view the Step4: The system displays
posted information’s. posted information’s.

Step2: The user gets access to the

system.

Step3:Clicks on view post info

button

Step5: The user view posted

information’s.

Step 6: The report process ends

Post condition The user views posted information’s.

37
 Use case: Add resource

Table 13 use case description for Add resource

Use case Name Add Resource

UC _ID UC_14

Actor Dispatcher

Description In this use case the dispatcher add resource in to the system

Precondition The dispatcher should have to enter a valid user name and password to add
resources.

Actor action System Response

Step1 The dispatcher wants to add Step3: The system drops different

Flow event resources, he/she login to the system. links of from manage resource
Step2: The dispatcher click on the page.
manage resources links. Step5: The system generate forms
Step4: Then the dispatcher click on the Step8: The system checks all the
add resource links. entered information.
Step6:The dispatcher fill the form Step9:The system displays
Step7: The dispatcher click on the add successful message
button Step10: End the use case.

Post condition The system inserts all information into the database.

alternatives Step8.1: if there is an invalid inputs error generate.

38
USECASE: Allocate Resource

Table 14 use case description for Allocate Resource

Use case name Allocate resources

UC_ID UC_15

Actor Dispatcher

Description In this use case the dispatcher allocate resources in to the system.

Precondition The dispatcher should have to enter a valid user name and password to
add resources.

Flow event Actor action System responsibility

Step1 The dispatcher wants to allocate Step3: The system drops

resources, he/she login to the system. different links of from manage
Step2: The dispatcher click on the resource page.
manage resources links option. Step5: The system generate
Step4: Then the dispatcher click on allocate resource form.
the allocate resources link. Step8: The system checks all the
Step6: The dispatcher fill the form entered information.
Step7:And click on allocate button Step9:The system displays
successful message

Step10: End the use case.

Post condition The system allocate resources into the database and announce to the
accident control team.

39
 Use case: Logout

Table 15 use case description for Logout

Use Case Name Logout

UC_ID UC_16

Actor System administrator(dispatcher), field officer, Information desk and accident

controlling team

Description: Logout and back to the login page.

The System administrator, field officer, and accident controlling team should have
Precondition Internet connection.
Flow Event:
Actor action System response
Step 1:The user click logout button

Step3: End use case Step2: The system returns to login page

Post condition The user will be out of the system or database

4.2.3 Object model: Class Diagram

Class diagram shows the static structure of data and the operations that act on the data,
i.e. it shows the static structure of an object-oriented model the object class.

40
 Resource

+Name:string
+Amount:string
+Catagory:string

+Viewstatus()
+CheckAvailability()
+Allocateresource()
+addresource() Society

+Name:string
+IDNo:string
Communication +phone:int
AccidentControllingTeam -Geneder:string
FieldOffice -UserName:string -Location:string
+Sendmessage()
-Password:string
+GenerateReport() +ViewMessage()
+UpdateReport() +Notify() +handledIncidentReport() +GenerateReport()
+Acknowledge() +ViewAllocateResource()

0...*
+ControlTime()
1..*

0..*
HandleIncident

+IncidentNo:int
Dispatcher EmergencyReport
+Date:date
Incident 1..* TypeAccident:string +ReportNo:int
+OpenInccident() 1 AccidentWieght:string +Date:date
+AllocateResource() Name:string
+Optimizepath() +TypeIncident:string -Time:time
+GenerateDectReport()
+AddResource() +IncidentNo:int -Location:string
+AddUser() WeightIncident:string +AccidentType:string
+Time:time +AccidentWeight:strng
+Date:date
+GenerateReport()
-Location:string

+Generate() 1 1..*
User 1...*
+FName:string Message
+LName:string +Subject:string
+PhoneNumber:strig +Comment:string
+Role:string +Date:date
+username:string
+Password:string
+sendMessage()
+ViewMessage()
+AddUser()
+Cnagestatus()
+Viewuser()

0....*

Figure 8 Class Diagram

41
 4.2.4 Sequence Diagram

Login

User page
Login Login Login Database <<UI>>
<<Link>> <<UI>> <<controller>> <<server>

Constraint

User
1:click
2:send

3:display

4:Fill form

7:check
5:click on login button
validity
6:send

8:valid 9:check
8:invalid autoniticate
10:not
autoniticate
10:autoniticate
Display user page

Figure 9 Login sequence Diagram

42
 Update

Update Update Update

Login Database
<<link> <<UI>> <<controller>>
<<UI>>

Constraint
Actor
1: Login
2:send
3:click

4:display

5:Fill update form

6:click update button 7:send 8:check

9:[Invalid]
9:[valid]modify()

Figure 10 Updating Database Sequence Diagram

43
 Delete

Delete Delete Delete Database

Login
<<link> <<UI>> <<controller>>
<<UI>>
Constraint Constraint
Constraint Constraint
Constraint

Actor
Constraint
1: login
2: send
3: click

4:display

5:Enter Info ID

8:check
6:Click Delete button
7:send
9:[Invalid] 9:[Valid]drop

Figure 11 Deleting record sequence Diagram

44
 Generate
Emergency report

Login Emergency report Emergency report Emergency report Accident detection

<<UI>> <<link> <<UI>> <<controller>> center

Constraint
Constraint Constraint
Constraint Constraint

Field
officer
Constraint

1:login
2: send
3: click

4:display

5:Fill form

5:Click report handle button 8:Check

7:send
8:[invalid]
9:[Valid]send

10:Acknowlegement

Figure 12 Generate Emergency Report Sequence Diagram

45
Generate Accident
handle report

Login Handle Handle report Handle report Information desk

<<UI>> <<link>> <<UI> <<controller>>

Constraint Constraint
Constraint Constraint
Constraint
Constraint
Accident
control Team
1: Login
2:send
3: click

3:display

4:Fill handle report form

5:Click report handle button

6:send 7:check

8:[Invalid]
8:[Valid] send

9:Acknowlegement ()

Figure 13 Accident handle report Sequence Diagram

46
 Add user

Login Add user Add user Add user Database

<<UI>> <<link>> <<UI>> <<controller>>

Constraint

Dispatcher
1:Login
2:send
3: click

4:display

5:Fill form

6:click on add button

8:check
7:send

9:[Invalid]
9:[valid]save

Figure 14 Add user account sequence diagram

47
Add Resource

Login Add resource Add resource Add resource Database

<<UI>> <<link>> <<controller>>
<<UI>> <<server>>

Constraint
Dispatcher

1:Login
2:send
3: click

4:display

5:Fill form

6:click on add button

7:send 8:check

9:[Invalid]
9:[valid]save

Figure 15 Add resource sequence diagram

48
4.2.5 Activity Diagram
An activity diagram describes a system in terms of activities. Activities are states that
represent the execution of a set of operations. The completion of these operations
triggers a transition to another activity. They can be used to represent control flow
(i.e., the order in which operations occur) and data flow (i.e., the objects that are
exchanged among operations Login to the System)

Open Home click

page Login link

Enter UserName and

Password

Click Login button

Check the userName and Invalid Error massage

Password display

Valid

Logged

Figure 16 Login activity diagram

49
Login to the click emergency
system report link

Fill emergency
report form

Click emergency
report button

Check enter Invalid

Error message
form

Valid

Successfully
generated

Figure 17 Accident Report generation activity diagram

50
 click Accident
Login to the
handle report
system
link

Fill Accident handle

report form

Click Accident
handle report button

Check enter Invalid

Error message
form

Valid

Successfully
generated

Figure 18 accident handle activity diagram

51
Login to the Click
system Update Link

Fill Update Page

Click Update
button

Is Input Invalid
Error message
valid

Valid

Updated

Figure 19 Update activity diagram

52
 login to the click Create
system Account link

Fill create
Account
Form

Click create
Account
button

Invalid Error massage

Is Input Valid
display

Valid

Created

Figure 20 Create Account activity diagram

4.2.6 State Diagrams

State chart diagram describes the flow of control of the Wolkite police station
accident management proposed system from one state to another state to describe the

53
system dynamically. States are defined as a condition in which an object exists and it
changes when some event is triggered. So the most important purpose of State chart
diagram is to model life time of an object from creation to terminal.

Idle

Home page

Activate

Login link

Click

Login form

Fill login form

Login button
Incorrect
Clickon

If valid

Correct

Confirm login

Display appropriate
page

Final state

Figure 21 State chart Login Diagram

54
 Idle

Home page

Activate

Login link

Click and login

Report emergency
link

Click

Report emergency form

Fill

Report emergency button

Click on report button

Error
Is Valid Input Invalid
message

Valid

Generate Report

Figure 22 Report emergency state diagram

55
 Initial State

Idle

Home page

Activate

Login

click and login

Post Link

Click

Post form

Fill

Post button

Incorrect
click

Is Valid

correct

Confirm posting
is successful

Final State

Figure 23 Post Information state diagram

56
 Activate Click on view
user page Click and login report
Home page Login link View report link Report type

Select

Report

Initial state

Display

Final state

Figure 24 Post View state diagram

57
 Idle

Activate

Home page

Click

Login link

Click

update link

Fill Update form

Update page

Click

Update button

click

Invalid
Is valid Input Error message

Valid

Updated

Figure 25 Update State diagram

58
 Chapter Five
System Design
5.1. System Overview
System design is the transformation of the analysis model into a system design model. Up to now
we were in the problem domain. System design is the first part to get into the solution domain in
a software development. This chapter focuses on transforming the analysis model into the design
model that takes into account the non-functional requirements and constraints described in the
problem statement and requirement analysis sections discussed earlier. The purpose of designing
is to show the direction how the system is built and to obtain clear and enough information needed
to drive the actual implementation of the system. It is based on understanding of the model the
software built on. The objectives of design are to model the system with high quality.
Implementing of high quality system depend on the nature of design created by the designer. If
one wants to change to the system after it has been put in to operation depends on the quality of
the system design. So if the system is design effectively, it will be easy to make changes to it. The
purpose of design phase is to plan a solution for problem specified by the requirements.
In this section, the systems is described by defining the design consideration of our project, by
decomposing the system into smaller subsystems that can be easily realized or proposed system
architecture and by selecting strategies for building the system, such as the hardware or software
platform on which the system will run, the persistent data management strategy and Class
interfaces. The result of system design is a clear description of each of these strategies, subsystem
decomposition, and a deployment diagram representing the hardware/software mapping of the
proposed system.
The designer’s goal is to produce a model or representation of an entity that will later be built.
Beginning, once system requirement has been specified and analyzed, system design is the first of
the three technical activities -design, code and test that is required to build and verify software.
The importance can be stated with a single word “Quality”. Design is the place where quality is
fostered in software development.

5.2. Design Considerations

5.2.1 Design Goals
These describe the qualities of the system that we should optimize. Many design goals are inferred
from the nonfunctional requirements or from the application domain.
The new system is considered to be successful if it meets the following sets of criteria’s.
 User Interface: The user interface of the system should be attractive and easy to use
by each user of the system with little training.

59
  Documentation: System users are provided with proper documentation about the
software’s features.

 Performance: The system should be able to serve a number of users which are
expected to access it concurrently.

 Error Handling: The system should be robust enough to handle error conditions and
continue with normal operations.

 Availability: The system availability should be available most of the time

since it is handling emergency situations.

 Security: The system should prevent the sensitive data from unauthorized
access.

 Modifiable: The system should be designed in Object Oriented language so

that modification to some part of the system could not affect other parts.

5.2.2 Design Trade-offs

Development Cost versus Functionality

 AIMS provides many functions for users such as manage staff, manage resource,
manage file etc. Each function of the system requires extra design and this causes an
extra cost for the development. Without functionality, the system is nothing so, we
focus on functionality rather than development cost.
Understandability versus Efficiency
 Understandability of the code is too important especially during the testing phase.
Each class and method must be readable, so number of methods increase in the
system and functions must be implemented in a clear way. Writing comments into
the source code increases the understandability of the code. This causes an
additional time taking in the developing phase.
Security versus Availability
 In AIMS (Accident information management system), users must have authorized to
connect to the system from web, and unauthorized people should not be able to access
the system. Each user will be able to login to the system by using the username and
password that is assigned by Administrator.
 Moreover, Availability is the degree to which a system or component is operational
and accessible when required for use. We know that if the system is available,
discussing about security is nothing.

60
5.3. Architecture of the proposed System
Our proposed system uses three tier software architecture systems i.e. three-tier
architecture is a client-server architecture in which the functional process logic, data
access, computer data storage and user interface are developed and maintained as
independent modules on separate platforms. Three-tier architecture is a software design
pattern and well-established software architecture. It has client side, server side and
database.

 Client Tire (user interface): which runs on the user’s computer or in this side
Dispatcher, accident control team, Field officer and other workers and other
interface exists in this side. It is also called presentation logic is responsible
for formatting and presenting data on user’s screen.

 Server side: This middle tier runs on a server and is often called the application
server or the web server connects to the database and gives respond for client
request. It handles processing logic, business rule logic and data management
logic.

 Database Server: that stores the data required by the middle tier. It is also
called data storage tire. Database communication, MYSQL queries and
completing them via the related API.

The general architecture of the software looks like the following picture. At the top
layer the user interface of the system is set, at the middle the AIM process and at the
end the database that store the data.

61
 <<Web browser>>
Web server response
Response
Ip/Tcp Request Include
MYSQLI Request

Web server
Database server
Client
Figure 26 Architecture of the proposed System

5.3.1 Sub-system Decomposition

The system decomposition includes a report generation, incident management, Manage Resource
{Add resource, Availability checker and Allocator}, manage file, communication subsystems, post
management and manage staff.
The report subsystem: this subsystem provides the different format of generating report which
allows different users send the report to the available receiver. This system can also sub divided
into Field Officer Side, society side and Accident controlling team which provide their respective
functionalities to the report receiver corresponding to them.
The Incident Manager subsystem: provides an interface between the main station and the client.
I.e. it allows the Dispatcher to retrieve the report send by the Field Officer or the accident control
team.
The Manage Resource subsystem: this subsystem includes four parts of services. These are
adding new resource record, checking resource availability and allocating resource. This is
implemented by the Dispatcher.
The Manage File subsystem: this subsystem includes two parts of services. These are
documenting handled incidents and archiving important documents. This is implemented by the
Information Desk.
The Manage staff subsystem: this subsystem includes three parts of services. These are add user
account, Delete user account, and Update account. This is also implemented by the Dispatcher.

62
The Communication controller subsystem this subsystem allows communication between the
dispatcher with the Field Officers and Accident Controlling in the form of sending report or
notification service.
System decomposition identifies the sub-system from the functional requirements outlined earl
in analysis:
Report
subsystem

-Generate report
-View report

Incident Communication
management Controller
subsystem subsystem

-Open Incident
-Update incident Connection -Send notice
-Delete incident Subsystem -View notice

Database connection
Manage Staff
subsystem

-Add user account

-Update user account
-delete user account

Manage Resource
subsystem

-Add Resource
-Allocate Resource
-Check availability resource

Figure 27 Sub-system Decomposition

63
5.3.2 Hardware/Software mapping (Deployment design)
The deployment design architecture used for our system is a three tier Client/Server Architecture
where a client can use Internet browsers to access the online report accident and other services that
provided by the system anywhere using the Internet.
The client tier is the system user interface containing data entry forms. Users interact directly with
the application through user interface.
Aweb server is a program that runs on a network server (computer) to respond to HTTP
requests.The web server used in this system is apache web server. HTTP used to transfer data
across the Internet. The application server implements the placement logic.
Database server stores all information of the system.
The hardware software mappings illustrated by UML deployment diagram to diagrammatically.
Deployment diagrams show the configuration of run-time processing elements and the software
components, processes, and objects that live on them. Software component instances represent
run-time manifestations of code units.

64
 Hardware and Software mapping

Application Server

Allocate resource

OPen incident
MYSQLI Database Server
Request
Client Computer
Manage user Login
account security
HTTP Request
Response
Report generate
Web Browser
Response
View information
Database

Generate
emergency
accident

Post unknown
people die in
accident

Figure 28 Hardware/Software mapping

65
5.4.3 Persistent data management
Persistent data management deals with how the system is going to handle the actual
data need to be stored on the database of the system. The purpose of persistence
modeling is which objects in the system design are required to be stored persistently.
Clearly, in a database driven application like this one, almost all system interactions
have deal with persistent data. Online accident information management system will largely
depend on a relational database to perform day-to day operations and storing log data.
Data will be stored in a MySQL Data Base Management system and manipulated
through the Database Subsystem, which will ensure data integrity and consistency.
Database Subsystem will contain all necessary SQL queries that will be accessible by
the rest of the Subsystems.
Figure 29 Persistent data management

Feedback Feedback<<Table>>

+User_ID varchar(20)<<PK>>
+User_ID varchar(20) +Name Varchar(20)
+Name Varchar(20) +Address Varchar(15)
+Address Varchar(15) +Email Varchar(20)
+Email Varchar(20) +Content Varchar(500)
+Content Varchar(500)

EmergencyReport
EmergencyReport
<<Table>>

ReportNo Varchar(20) ReportNo Varchar(20)<<PK>>

+Date date
-Time Time stamp
-Location Varchar(20)
+AccidentType Varchar(20)
+AccidentWeight Varchar(20)
+Date date
-Time Time stamp
-Location Varchar(20)
+AccidentType Varchar(20)
+AccidentWeight Varchar(20)

ActiveIncident ActiveIncident

+Name Varchar(20) +Name Varchar(20)

+Number Int +Number Int<<PK>>
+Date date +Date date
Additionalresource Varchar(20) Additionalresource Varchar(20)

66

HandleIncident
+IncidentNo Varchar(20)
+Date date
+TypeAccident Varchar(20)
+AccidentWieght Varchar(20)
HandleIncident<<Table>> HumanResource
HumanResource <<Table>>
+IncidentNo Varchar(20)
<<PK>>
+Date date +Name Varchar(20) +Name Varchar(20)
+TypeAccident Varchar(20) +IDNo Varchar(10) +IDNo Varchar(10)<<PK>>
+AccidentWieght Varchar(20) -Position Varchar(15) -Position Varchar(15)

Material Resource Archive Archive<<Table>>

Material Resource
<<Table>>
+Name Varchar(20) +Name Varchar(20)
+Number int(15) +Number int(15)<<PK>>
+Name Varchar(20)
+Name Varchar(20) +Time timestamp +Time timestamp
+ID Varchar(10)<<PK>>
+ID Varchar(10) -Date Varchar(10) -Date Varchar(10)
-Position Varchar(20)
-Position Varchar(20) +Type_accident Varchar(20) +Type_accident Varchar(20)
-Catagory Varchar(15)
-Catagory Varchar(15) +Accident_weight Varchar(10) +Accident_weight Varchar(10)
+Location Varchar (30) +Location Varchar (30)

Document Document
User Account User Account<<Table>>
<<Table>>
+DocumnetNo int(15) +FName Varchar(20)
+DocumentNo int(15) <<PK>> +FName Varchar(20) +Lname Varchar(20)
+Time timestamp +Time timestamp +Lname Varchar(20) ID Varchar(20)<<PK>>
-Date Varchar(10) -Date Varchar(10) User_ID Varchar(20) +Sex Varchar(10)
+Name Varchar(20) +Name Varchar(20) +Sex Varchar(10) +accountType Varchar(20)
+Type_accident Varchar(20) +Type_accident Varchar(20) +AccountType Varchar(20) -UserName Varchar(20)
+Accident_weight Varchar(10) +Accident_weight Varchar(10) -UserName Varchar(20) -Password Varchar(20)
+Location Varchar (30) +Location Varchar (30) -Password Varchar(20)

67
 5.3.4 Class interfaces
Figure 30 Class interfaces of Resource

Resource

+Name:string
+Amount:string
+Catagory:string

+Viewstatus()
+CheckAvailability()
-Allocate()

Class Resource
Attribute: Name
 Description: It identifies name of Resource.
 Type: String.
 Maximum-size: 20
 Visibility: public.
Attribute: Amount
 Description: It contains amount of Resource.
 Type: Integer.
 Maximum-size: 20
 Visibility: public.
Attribute: Category
 Description: It identifies category of Resource.
 Type: string.
 Maximum-size: 20
 Visibility: public.

Method: ViewStatus ()

68
  Pre-condition:- Must have login to the system to view the status of the resource.
 Post –condition: - Resource status view.
Method: CheckAvailablity ()
 Pre-condition:- Must have login to the system
 Post-condition:-Check availability resource
Method: Allocate ()
 Per-condition: - Must have login to the system to allocate the resource.
 Post-condition: -Allocate resource to the Accident control team.
Figure 31 Class interface of Emergency report

EmergencyReport

+ReportNo:int
+Date:date
-Time:time
-Location:string
+AccidentType:string
+AccidentWeight:strng

+GenerateReport()

Class EmergencyReport
Attribute: ReportNo
 Description: It unique identification of Emergency.
 Type: Integer.
 Maximum-size: 15.
 Visibility: public.
Attribute: Date
 Description: It contains date of Emergency report.
 Type: Time stamp.
 Maximum-size: 15.

69
  Visibility: public.
Attribute: Location
 Description: It contains location of Emergency.
 Type: String.
 Maximum-size: 20.
 Visibility: private.
Attribute: Accident Type
 Description: It contains the Type of the accident.
 Type: String.
 Maximum-size: 20.
 Visibility: Public.
Attribute: Accident Weight
 Description: It contains the weight of the accident.
 Type: String.
 Maximum-size: 20.
 Visibility: Public.
Method: GeneratReport ()
 Per-condition: -Must have login to the system and fill emergency report form.
 Post-condition: - Generate emergency report.
Figure 32 Class interface of Incident Handle report

HandleIncident
+IncidentNo:int
+Date:date
TypeAccident:string
AccidentWieght:string
+GenerateDectReport()

Class HandleIncident
Attribute: IncidentNo

 Description: It unique identification of handle incident.

 Type: Integer.
 Maximum-size: 15.  Visibility: public.

70
Attribute: Date

 Description: It contains the date of the handle incident report.

 Type: Date.
 Maximum-size: 15.
 Visibility: public.

Attribute: Accident Type

 Description: It contains the Type of the accident.

 Type: String.
 Maximum-size: 20.  Visibility: Public.
Attribute: Accident Weight

 Description: It contains the weight of the accident.

 Type: String.
 Maximum-size: 20.  Visibility: Public.
Method: GeneratReport ()

 Per-condition: -Must have login to the system and fill accident handle report form.
 Post-condition: - Generate handle incident report.
Figure 33 Class interface of society

Society

+Name:string
+IDNo:string
+phone:int
-Geneder:string
-Location:string

+GenerateReport()

Class Society
Attribute: Name
 Description: It identifies name of society.
 Type: String.
 Maximum-size: 20
 Visibility: public.

71
Attribute: IDNO
 Description: It unique identification of the society.
 Type: String.
 Maximum-size: 20
 Visibility: public.

Attribute: Phone
 Description: It contains the phone number of the society.
 Type: Integer.
 Maximum-size: 20
 Visibility: public.
Attribute: Gender
 Description: It contains the gender of the society.
 Type: String.
 Maximum-size: 20
 Visibility: private.
Method: GenerateReport ()
 Per-condition: - Must have fill Emergency report form.
 Post-condition: -Generate emergency report.

72
5.4 User interface design

Figure 34 User Home page Interface

73
Figure 35 Admin/Dispatcher page Interface

74
Figure 36 User emergency report interface

75
 Chapter six
Implementation and testing
6.1 Introduction
Implementation refers to the coding of the all documents gathered starting from requirement
analysis to Design phase. All documents, business logic, information gathered are designed into
the code so that the system will be implemented for the user to be used for the purpose it
developed. The chapter here describes about the final testing system, hardware and software
acquisitions, and installation process. The functional system from the design phase above is the
key input to the implementation phase. The deliverable of the implementation phase (the project)
is the operational system that will enter the operation and support stage of the system’s life cycle.
Here is the sample code for each module.

6.2 Hardware software acquisitions

Hardware acquisition /HW: The system is going to be implemented on the Accident Information
Management System. Since our system is web based for its deployment a web server is needed.
As a Mail server and domain name server, our system need servers. From user’s point of view,
they can use it from anywhere through domain name of the system that provided after
implementation. Here the hardware requirements are the minimum that they need to be part of
internet. For the project implementation; the following Software and hardware tools are used.

Hardware

 Computers
 Printer: For printing Documentation
 Network cable: for used to connecting internet.
 Server: for connection to the client computer (to host the system)

Software tools

For the System implementation the following software’s are used.

 Browsers (Mozilla Firefox, Google chrome)

 Notepad++
 Sublime text
 Xampp
 Microsoft word

76
  Notepad
 Edraw Max
 Visual paradigm for UML diagram.

6.3 User manual preparation

6.3.1 Tanning
During the deployment of the system, the project group members will give short time training for
the system administrators and clerks explaining how the system works and in what way they can
manage the system developed.

6.3.2 Installation process

Since our project is a web-based System, there is no need to install it on a particular machine and
no need high installation process rather it will be hosted on a web server and provide domain name
for the web server in which the system is hosted and Database server will also be configured.

6.3.3 Startup strategy

Once the system is hosted, it has two parts: One which needs password and username that is for
administration and the user. To access those parts one has to have password and user name so that
he/she can enter into it and use it. The other part is those which do not need pass word and username
so they can be view by anybody.

77
6.4 Algorithm
The code for home page

<body class="fixed-nav sticky-footer bg-dark" id="page-top">

<!-- Navigation-->

<nav class="navbar navbar-expand-lg navbar-dark bg-inverse fixed-top" id="mainNav"

style="background-color: #2F4F4F ;">

<a class="navbar-brand " style="margin-top: 10px;" href="index.php">AIMS Home</a>

<button class="navbar-toggler navbar-toggler-right" type="button" data-toggle="collapse" data-

target="#navbarResponsive" aria-controls="navbarResponsive" aria-expanded="false" aria-
label="Toggle navigation">

<span class="navbar-toggler-icon"></span>

</button>

<br/>

<div class="collapse navbar-collapse" id="navbarResponsive">

<ul class="navbar-nav navbar-sidenav" style="margin-top: 100px;" id="exampleAccordion">

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="Home">

<a class="nav-link" href="index.php">

<br/><br/>

<i class="fa fa-fw fa-home"></i>

<span class="nav-link-text">Home</span>

</a>

</li>

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="SMS">

<a class="nav-link " href="sms.php">

<i class="fa fa-envelope-o"></i>

<span class="nav-link-text">SMS Message</span>

</a>

</li>

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="New">

<a class="nav-link data-toggle="tooltip" href="new.php" data-parent="#exampleAccordion">

78
 <i class="fa fa-envelope-o"></i>

<span class="nav-link-text">New Information </span>

</a>

</li>

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="About Us">

<a class="nav-link" href="about.php">

<i class="fa fa-history"></i>

<span class="nav-link-text">About Us</span>

</a>

</li>

<?php

if(isset($_SESSION['user_role'])) {

if(isset($_GET['p_id'])) {

$the_post_id = $_GET['p_id'];

echo "<li><a href='admin/posts.php?source=edit_post&p_id={$the_post_id}'>Edit

Post</a></li>";

?>

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="feedback">

<a class="nav-link" href="feedbacks.php">

<i class="fa fa-fw fa-comment"></i>

<span class="nav-link-text">Feedback</span>

</a>

</li>

<li class="nav-item" data-toggle="tooltip" data-placement="right" title="Contact Us">

<a class="nav-link" href="contact.php">

<i class="fa fa-address-book"></i>

79
 <span class="nav-link-text">Contact Us</span>

</a>

</li>

</ul>

<ul class="navbar-nav ml-auto" style="margin-top: 8px;">

<li class="nav navbar-right top-nav" >

<a href="sidebar.php" class="text-white" style="margin-right: 60px;">

<li class="fa fa-fw fa-user text-white" data-toggle="modal" aria-haspopup="true" aria-

expanded="false" >Login </li>

</a>

</li>

</ul>

</div>

</nav>

<div class="content-wrapper">

<div class="modal fade" id="exampleModal" tabindex="-1" role="dialog" aria-

labelledby="exampleModalLabel" aria-hidden="true">

<div class="modal-dialog" role="document">

<div class="modal-content">

<button class="close" type="button" data-dismiss="modal" aria-label="Close">

<span aria-hidden="true">×</span>

</button>

</div>

</div>

</div>

80
The code for login
<?php session_start();

unset($_SESSION['userid']);

if(!isset($_SESSION['username'])) // Checking whether the session is already there or not if

// true then header redirect it to the home page directly

header("Location:index.php");

?>

<?php include "includes/db.php"; ?>

<?php include "admin/functions.php"; ?>

<?php

if(isset($_POST['login']))

$_SESSION['user']="true";

$_SESSION['user_id']="true";

if (isset($_POST['username'])&&($_POST['password']))

$username=$_POST['username'];

$user_password = md5($_POST['password']);

$sql = "select * from users where username='".$username."' and password='".$user_password."' and

status='1'";

$result = mysqli_query($connection,$sql) or die();

$records = mysqli_num_rows($result);

if ($records==0)

echo

"<script type=\"text/javascript\">".

"window.alert('Invalid UserName or Password! !!.');".

81
 "top.location = 'sidebar.php';".

"</script>";

else

$_SESSION['username']=$username;

while($row=mysqli_fetch_array($result))

$status=$row['user_role'];

$username=$row['username'];

$pass=$row['password'];

if($_POST['username']==$row['username'] && md5($_POST['password'])==$row['password'])

$_SESSION['logged']="true";

$session = "1";

$user_role=$row['user_role'];

if($status=="dispatcher")

session_start();

$_session['userid']=$row['user_id'];

$_session['pass']=$row['password'];

$_session['username']=$row['username'];

$_SESSION['logged']="true";

$username=$row['username'];

$session = "1";

header("location:admin/index.php");

else if ($status=="fieldofficer")

82
 session_start();

$_session['userid']=$row['user_id'];

$_session['pass']=$row['password'];

$_session['username']=$row['username'];

$_SESSION['logged']="true";

$session = "1";

header("location:accidentp/index.php");

else if ($status=="controlteam")

session_start();

$_session['userid']=$row['user_id'];

$_session['pass']=$row['password'];

$_session['username']=$row['username'];

$_SESSION['logged']="true";

$session = "1";

header("location:accidentc/index.php");

} else

header("location:sidebar.php");

}}

echo " <br><font color= 'black'

size='2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Invalid UserName or
Password!</font>";

echo' <meta content="4;sidebar.php" http-equiv="refresh" />';

}}

mysqli_close($connection);

} }

?>

83
6.5 Maintenance
Our system is maintainable in the following different perspective mentionable.

6.5.1 Maintaining code

Our system code part is easily maintainable because it can be maintained without affect other parts of the
system and any failed.

6.5.2 Maintaining database

Data base is the one part of our system that can also maintainable without effect of other system module.

6.5.3 Maintaining user interface

Our System user interface is also maintainable without affect the other modules.

84
 CHAPTER 7
Testing plan
7. 1 Introduction
In this chapter we discuss about introduction for testing, purpose of testing, features what we are
tested, what we are not tested, what we use testing tools and environments to test the system and
discus about testing procedures.
This project's goal is providing an automated system for Wolkite city accident information
management system. Once the system is working successful, the finding of Organization that
gives accident information performance will increase at certain level than the former stair.
However, once the system is operational, this initial selection of products will be reviewed to
determine if they will ultimately provide the kind of scalability needed for the foreseeable future.
Specifically, testing will now consist of the following phases (listed chronologically): · Unit and
integration level – adherence to coding standards and successful communication between units
and integration level · System level – compatibility, performance, usability, functionality etc. ·
System Quality Assurance & Acceptance (acceptance into Production).

7.2 Purpose
Software testing is performed to verify that the completed software package functions according
to the expectations defined by the requirements/specifications. The overall objective to not to find
every software bug that exists, but to uncover situations that could negatively impact the students
and organizations, usability and/or maintainability. From the module level to the application level,
this article defines the different types of testing. Depending upon the purpose for testing and the
software requirements, a combination of testing methodologies is applied.

7.3 Features to be tested and not to be tested

7.3.1 Features to be tested
In order to test a program, a test engineer must perform a sequence of testing activities. These
explanations focus on a single test case. In software quality assurance, there is various features to
be tested. Characteristics to be tested are listed below

 Graphical user interface

 Input output functions

85
  Sub system communication
 Data base transaction
 Login capability
 Access privileged
 User interface and database interaction
 Coding structure style
 Software platform

7.3.2 Features not to be tested

Features not be tested includes the feature of the application which cannot be measured directly or
indirectly. These features cannot make serious damage to system but indirectly have an influence
on our application performance and acceptance. These features include

 User satisfaction of the system

 Exact response time of the system

7.4 Sample Test Cases

It is the final step of testing done by developers. All errors in the forms, functions, modules have
been tested by the developers. Finally, System testing ensures that the entire integrated software
system meets the desired requirements. It tests a configuration to ensure known and predictable
results.

86
Table 16 Test case to register account

Test Case 1: Register user account

Test case objective : To create account

Test case description: Admin enters basic info of the user, then presses register button.
Client program contacts with server, server contacts with the database, and database checks
for registration and sends message to the administrator.

Requirements Verified: Yes

Test Environment: Apache MySQL server must be in running state, Database Should
contain appropriate table and link must be established between server and client program.

Test Setup/Pre-Conditions: Apache server should be in running state and all fields should
be filled.

Actions Expected Results

The administrator should login and press the register menu. Displays registration page.

Administrator should enter user information Displays success message

If some fields are not filled the system display to fill the fields again.

87
 Table 17 Test case to Login

Test Case 2: Login

Test case objective : To login to the system

Test case description: Admin enters Username and Password, then presses login button.
Client program contacts with server, server contacts with the database, and database checks
for authentication and displays administrator page.

Requirements Verified: Yes

Test Environment: Apache MySQL server must be in running state, Database Should
contain appropriate table and link must be established between server and client program.

Test Setup/Pre-Conditions: Apache server should be in running state and User name and
Password fields should be filled correctly.

Actions Expected Results

The administrator should enter the correct user name and Displays administrator page.
password to login.

If user name and password are not filled correctly the system display to fill the user name
and password again.

88
Table 18 Test case to send report

Test Case 3: send report

Test case objective : To send report

Test case description: the reporter that means Field officer and Accident control team should
login to the system. Reporters fill the fields to report the information and press send button.

Requirements Verified: Yes

Test Environment: Apache MySQL server must be in running state, Database Should contain
appropriate table and link must be established between server and client program.

Test Setup/Pre-Conditions: The reporter’s login to the system and fill the report form

Actions Expected Results

Displays report
information page.
The report sent.

If the report is not fill correctly, the system will display to fill the basic info.

89
7.5 Test Procedure
7.5.1 Unit Testing
Unit test is a way of testing each of the system functionality independently. Unit testing is done at
the source or code level for language-specific programming errors such as bad syntax, logic errors,
or to test particular functions or code modules. The unit test cases shall be designed to test the
validity of the programs correctness.

In this level of testing process, the Accident Information Management system developers test the
different sub procedures, and functions tested.

Sample Tests

 Check whether the return type of the functions is correct.

 Check if the correct output is produced for different inputs.
 Check the efficiency of the code with respect to the memory and CPU time.
 Check the input data that we write on the GUI must be submitted to the data base.
 Check the GUI can access the privileged data from the data base.

7.5.2 Integration Testing

In this level of testing we have examined how the different procedures work together to achieve
the goal of the sub system. The type of integration testing that we have followed is bottom up.
Since Accident Information Management system is web-based application each and every access
is depending on hypertext transfer protocol (HTTP). So, we integrate each component from single
functionality (individual interface) to the main function incrementally step by step through link tag
by using test driver.

Sample Tests

 Check the interaction between individual functionality which performs the specific tasks.
 Evaluate the functionality of subsystem after combination all individual functionality.
 Identify the Independence of each subsystem with other subsystem.

7.5.3 System Testing

In this level of testing process, we have examined how the whole subsystems of Accident
Information Management system work together to achieve the desired goal (user’s requirements
of the system). The goals of system testing are to detect faults that can only be exposed by testing
90
the entire integrated system or some major part of it. Generally, under this testing is mainly
concerned with areas such as performance, security, validation, and load/stress of Accident
Information Management system. But we will more focus only on function validation and
performance.

Sample Tests

 Evaluate the functionality of subsystem after combination of individual sub system weather
it works correctly or not.
 Check the coherence and coupling of each subsystem.
 Check the overall functionality of Accident Information Management System that achieves
the user’s requirement.
 Measure the system boundary which is beyond the goal or not.
 Measure the weakness and the strength of the system using different metrics.
 Check the interaction of each subsystem that performs the specified business process.
 Verify the system completeness-based user’s requirement.

7.5.4 Acceptance Testing

Real users will participate on the acceptance testing of our system. According to system
requirements and other resources (documentation, source code, user manual) test cases are
generated to determine (validation and verification) whether the system satisfies users need and
expectation to maintain the reliability of our system and also meet the user’s requirements. 7.6

7.6 Release criteria

Software release criteria is the activity that makes our software system available for
users. The general release criteria consists of several interrelated activities with possible
transitions between them. These activities can occur at our side (the developers of the
system) or at the consumer side or both. Because every software system is unique, the
precise processes or procedures within each activity can hardly be defined.

91
 Chapter Eight
Conclusion
8.1 Summary of Final product
Currently Accident Information Management System is manual based Accident information
management system. Due to this many problem are there. Like to society communicating with
their police station to give information about the accident and, communicating between Field
officer, Accident control team and Dispatcher has taken more time and resource.

By analyzing this problem, the group team proposed, analyze, design, and implement this
computerized accident information management system for Wolkite city Accident information
management system station. The system that will provide more efficiency, and accuracy than the
manual based Accident information management system. So, the new computerized accident
information management system performs many operations than manual based. It prevents the loss
of paper documents, time, effort and so on. This system solves many problem of the organization,
society, and police station. It reduces work load of police station and society. The new system can
retrieve data in real time. From this we conclude that the project is very important in work
environment of the Wolkite police station Accident information management system and society
of that areas.

In general during the various phases of the project, we have learned a lot in multidisciplinary
technologies required to be embed with this system and these technologies would be useful in our
future techno-economic career.

8.2. Recommendation
While doing this system the team has faced different types of challenges. But by the cooperation
of all the group members and the adviser, the team is now able to reach to the final result. All the
group members strongly fought these challenges and take the turn to the front.

We would like to recommend some of the extra features to this System which we could not do
due to time limitation and unavoidable reasons and challenges including the following features.

 Include the crime management system.

 Integrate with the court system.

92
References

(n.d.). Retrieved from https://www.lucidchart.com/pages/uml-activity-diagram

(n.d.). Retrieved from https://www.lucidchart.com/pages/uml-sequence-diagram
(n.d.). Retrieved from https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-class-diagram/
(n.d.). Retrieved from http://www.e-solutionsltd.com/Aims.
Dutoit, B. B. (n.d.). System Design:.
Group, O. M. (1997, January). UML Tutorial. Retrieved from
https://www.tutorialspoint.com/uml/index.htm
Group, O. M. (1997, January). UML Tutorial. Retrieved from
https://www.tutorialspoint.com/uml/uml_use_case_diagram.htm
(2010, october 29). Manual document of the organization. (w. c. station, Interviewer)
Simon Bennett, R. F. (2010). Object-oriented Systems Analysis and Design: Using UML.
McGraw-Hill Education, 2010.
Subsystem decomposition. (n.d.). http://selab.hongik.ac.kr/show_data/education/F-ch06.pdf.

93