Prisoner Information Managment System

Web based Prisoner Information Management System
(Debre Markos Town)

A PROJECT REPORT
Submitted by
NAME ID
1. Yemisrach Nehine………….TER/4698/07
2. Ayanaw Setegn……….........TER/4647/07
3. Wubet Molla…………….....TER/4695/07
4. Zerihun Alem………….......TER/4703/07
In partial fulfillment for the award of the degree of
BACHOLOR OF DEGREE IN INFORMATION TECHNOLOGY
Under the guidance of
Ayalneh B.
--------------------------------------
ADVISOR SIGNATURE
DEPARTMENT OF INFORMATION TECHNOLOGY

INSTITUTE OF TECHNOLOGY
DEBRE MARKOS UNIVERSITY
DEBRE MARKOS, ETHIOPIA

May:-2010.E.C
Declaration
We,undersigned,declere that thesis our original work, has not been presented for a degree in
this or any other university, and all the source of martial used for the thesis/project have been
acknowledged.
Name Id No Signature
1. Ayanaw Setegn 4647/07 ---------------------------
2. Zerihun Alem 4703/07 ---------------------------
3. Yemisrach Nehine 4698/07 ---------------------------
4. Wubet Molla 4695/07 ---------------------------
i
APPROVAL OF ADVISOR AND EXAMINERS

This project has been submitted for examination with our approval as the project
advisor.
Advisor Name ____________________ Signature ____________
This project has been examined with our approval as the project examiner.
Examiner Name:
1. ____________________ signature______________
2. ____________________Signature______________
3. _____________________Signature_____________
ii
Acknowledgment
We would like to say thanks to almighty God for giving us strength to complete this project. Then we
would like to thank our advisor Instructor Ayalneh Bitew for his constructive opinion and willingness to
participate in each part of our project and his effective direction, assistance and guidance for accomplish
this project. And also we wants thank Debre Markos prison administration for giving information about
existing system in the organization.
iii
Abstract
This project developed web based prisoner information management system. In this time the
overall activities of in Debre Markos prison use semi-automating way to manipulating prisoner
information. There are repetitive and impairment activities occur in the organization those are
difficult to integrate data from different individual prisoner records. Based on the above problem
this project automates the existing system use well organized database.
 The system enables registration, update and view of individual records of prisoner and
visitor.
 Generating reports and certificates based on the demand of the employer
 Identify pre_charge.
 Send request for transfer or appointment and approve request.
 Assign police and lawyer
Generally this project is mainly focuses on the prisoner which is already judged by the court, so
DMPIMS is concerns after having judged prisoner with its back ground detailed.
iv
Contents
List of Table ................................................................................................................................................ vii
List of figures ............................................................................................................................................ viii
Abbreviations ............................................................................................................................................. ix
Chapter One: Introduction ........................................................................................................................ 1
1.1. Introduction ........................................................................................................................................ 1
1.2. Background of the project .................................................................................................................. 1
1.3. Statement of Problem ......................................................................................................................... 2
1.4. Overview of Proposed system.......................................................................................................... 3
1.5. Objective of the Project...................................................................................................................... 3
1.5.1. General objective ........................................................................................................................ 3
1.5.2. Specific objective ........................................................................................................................ 3
1.6. Scope of the project ........................................................................................................................... 3
1.7. Significance of Project ....................................................................................................................... 4
1.8. System requirement ........................................................................................................................... 5
1.8.2. Hardware requirement................................................................................................................. 5
1.8.3. Programming language ............................................................................................................... 5
1.9. Methodology of the Project................................................................................................................ 6
1.9. 1. Data collection methodologies ................................................................................................... 6
1.9.2. Analysis and Design Methodology ............................................................................................. 6
1.9.3 .System Development Model ....................................................................................................... 6
1.10. Feasibility study of the project ......................................................................................................... 7
1.10.1. Technical Feasibility ................................................................................................................. 7
1.10.2. Operational Feasibility .............................................................................................................. 7
1.10.3. Economic Feasibility................................................................................................................. 7
1.10.4. Legal Feasibility........................................................................................................................ 8
Chapter Two: System analysis ................................................................................................................... 9
2.1. Overview of existing system .............................................................................................................. 9
2.2. System Requirement Specification .................................................................................................. 10
2.2.1. Functional requirement ............................................................................................................. 10
2.2.2. Non -functional requirement ..................................................................................................... 11
2.2.3. Business rule ............................................................................................................................. 12
v
2.3. System requirement analysis............................................................................................................ 12

2.3.1. Actor and Use case Identification ............................................................................................. 12
2.3.2. Sequence Diagram .................................................................................................................... 23
2.3.3. Activity Diagram....................................................................................................................... 26
2.3.4. Analysis class Diagram ............................................................................................................. 30
Chapter Three: System design ................................................................................................................. 32
3.1. Design Class Diagram...................................................................................................................... 32
3.1.1. Class diagram Description ........................................................................................................ 34
3.2. Database design /physical database model/ ..................................................................................... 36
3.3. User Interface Design ...................................................................................................................... 39
3.4. Deployment diagram ........................................................................................................................ 41
Chapter 4: System implementation ......................................................................................................... 43
4.1 Overview of the programming language used .................................................................................. 43
4.2 Algorithm Used ................................................................................................................................. 43
Algorithm use for login ..................................................................................................................... 43
4.3 Sample Codes.................................................................................................................................... 44
Chapter 5: Testing .................................................................................................................................... 50
5.1 Sample test ........................................................................................................................................ 50
Chapter six: Conclusion and Recommendations ........................................................................................ 51
6.1 Conclusion ........................................................................................................................................ 51
6.2 Recommendations ............................................................................................................................. 51
6.3 Future Enhancement ......................................................................................................................... 51
Reference ........................................................................................................................................... 52
vi
List of Table
Table 1: use case identification table .......................................................................................................... 13
Table 2: Login Use case description ........................................................................................................... 16
Table 3: create account use case description .............................................................................................. 16
Table 4: Register prisoner use case description .......................................................................................... 17
Table 5: Update prisoners’ information use case description ..................................................................... 18
Table 6: Generate report use case description ............................................................................................ 19
Table 7: Register Trainee use case description ........................................................................................... 20
Table 8: Request transfer use case description ........................................................................................... 21
Table 9: view request use case description ................................................................................................. 22
Table 10 :Prisoner class description............................................................................................................ 34
Table 11: Use account class description ..................................................................................................... 35
Table 12: Visitor class description .............................................................................................................. 35
Table 13: Register Prisoner table ................................................................................................................ 36
Table 14: Register Trainee table ................................................................................................................. 37
Table 15: prisoner lawyer table................................................................................................................... 38
vii
List of figures
Figure 1: use case diagram ............................................................................................................ 15
Figure 2:Sequence diagram for login page ................................................................................... 24
Figure 3: Sequence diagram for create account ............................................................................ 24
Figure 4: Sequence diagram for registration ................................................................................. 25
Figure 5: Sequence diagram for send request ............................................................................... 26
Figure 6: Activity diagram for Login page ................................................................................... 27
Figure 7: Activity diagram for registration ................................................................................... 28
Figure 8: Activity diagram for updating ....................................................................................... 29
Figure 9: Analysis class diagram .................................................................................................. 31
Figure 10: Design class diagram ................................................................................................... 33
Figure 11: User interface for login page ....................................................................................... 39
Figure 12: User interface for create account ................................................................................. 40
Figure 13: User interface for prisoner registration ....................................................................... 41
Figure 14: Deployment Diagram .................................................................................................. 42
Figure 15: System testing for identify pre_charge ....................................................................... 50
viii
Abbreviations
DMPIMS:-Debre Markos Prisoner Information Management System
CSS: - Cascade style sheet

GB: - Giga byte
GUI:- graphical user interface
HTML: - hypertext markup language
PHP: - Hyper Text Pre processor
JS -java script
UC: - Use Case
UML: - unified model language
OOADs-object oriented analysis and design
ix
Chapter One: Introduction

1.1. Introduction
Nowadays, Information technology benefits the world by allowing organization to work more
efficiently and to maximize productivity. As information technology students, we believe that the
basis for managing organization information to change the day to day manual activities into
computer based system ,but it is true that the majority enterprises that is found in Ethiopia does
not use computer base system as a result we can be a witness for the problem occurred in the
organization. In Debre Markos prison administration organization has several activities performs
but to facilitate their activity the organization uses semi-automated. Due to this reason, it is hard
to register, search and update a single data of many prisoners’ information, easily data loss, use
much space and human power and security problem exist in the organization. By analyzing these
problems, our group proposed web based system for Debre Markos prison administration to
solve this semi-automated work flow and fast the working structure in the organization.
Generally, the proposed system focused registering, managing, storing and evaluating all
prisoner information easily through a computerized way in the organization.
1.2. Background of the project

Debre Markos prison administration was established in 1983 E.C by central government with
name of so called “kerichelie, ”weyenbeit” in Amharic for the purpose of managing prisoner
activities. When constitution recognized in 1989 E.C the name changed into East Gojjam Debre
Markos prison administration. Prisoners’ can be punished by heavy and simple crimes such as
murder, kidnapping/abduction, steal, terrorism and corruption. The prisoners’ in side are
maximum arresting year is 25 and the list 10 day. The total number of prisoners’ in 1983 is 400,
but the number of prisoners’ increase through year to year due to the increment of criminal
person for this reason the number of prisoners’ in Debre Markos prison at this time more than
1600 prisoners’. The current system organization uses use semi automated but there are many
drawback like difficult to access prisoner information, register trainee of prisoner and visitor ,
send request generate report and certificate. Due to this system employee in the organization loss
their time, human power and money manage prisoner information.
1
Vision
The main vision of Debre Markos prison is to be the popular one in emendation and training
place in 2015 E.C throughout the region.
Mission
The mission of Debre Markos prison office is to enable prisoners’ to be productive and peaceful
citizen who have been sent by court order by giving security, food and educational training.
1.3. Statement of Problem

Debre Markos prison administration applies semi-automated way of recording prisoners’
information.It leads to many problems, some of those problems existing semi-automated
processing are the following:
Data sharing problem Recorded Prisoner information in a single computer but no

networked that enables employees want to do their works on another computer. This may
lead to repetitive work and may decrease the efficiency of the work.
The existing system takes much time and effort when employee manages prisoner
information like register trainee, give certificate and generate report.
Difficult for prisoner to view personal information, send request like to transfer or
appointments.
The system requires much human power to accomplish the task in the organization.
The existing system do not have good material utilization since the system is manual use
different materials to accomplish the task , like papers, pens, copy machines .
System not secured because easy access prisoners’ information by unauthorized user.
Inconsistence data search mechanisms when to search any prisoners’ information must be
visit all document on the shelf.
Files are exposed to loss and damage since the files are stored on a paper in scattered
manner.
Difficulty in conducting consistent reports.
Poor flow of critical information between departments in the organization.
Human errors are always possible in entering the data.
2
1.4. Overview of Proposed system

The proposed system is primarily aimed to eliminate the existing system problems. To eliminate
or solve the existing system problems and the proposed system expected to include the
following tasks it is expected to include the following tasks:
 To automate the existing system by using centralized DB.
 The system is able to maintain and store prisoner information.
 The system produce reports when needed.
 The systems modify prisoner records when needed.
 The system able to identify prisoner recharges means check whether the prisoner has
record or not.
 The systems record the visitors when they come to visit the prisoner.
 The system produces sufficient backup and recovery to save time and energy.
 The system easy to access prisoner information.
1.5. Objective of the Project

1.5.1. General objective
The general objective of the project is to develop a web based prison information management
system for Debre Markos prison administration.
1.5.2. Specific objective
To achieve Our General objective, we follow the following tasks:
 To develop well organized database system that store, manipulate, searching and
retrieving prisoner information.
 To develop easy and attractive user interface to manipulate prisoner records.
 To develop system that is easily accessible and used by any authorized user.
 To generate different notification like request notification.
 To develop the system for automatic generates report about prisoner.
 To make data transfer and communication fast between different system uses.
 To avoid document duplication and loss in the organization..
1.6. Scope of the project

The scope defines both boundaries and activities of the system. The physical boundary of the
project only limited to Debre Markos prison administration. This system includes the
following task:
 Manage user account.
3
 Backup and recovery.

 Registration of user.
 Updating.
 Send request
 Record appointment for court and health.
 View System user.
 Search System user.
 Generate report
 Identify the prisoner per-charge means checking whether the prison record or not.
 Generate certificate
 It allows parole for prisoner based on specific evaluation.
 Notice.
 Notification
1.7. Significance of Project

The proposed system of Debre Markos Prison Information management system has a lot of
significances in every aspect related to prisoners’ information managements.
Debre Markos Prison administration wouldbe beneficiary by this project in many ways like:
Significances for prison:

 To reduce time consuming activities like register, search; update prisoners’ and visitors’
information easily in the organization.
 The prison is beneficiary because it can perform different activities with minimum
effort.
 To create fast & efficient sharing of critical information within the Staff.
 To increase efficiency of data integrity in the organization.
 To avoid data redundancy, which means extended data can be retrieved without affecting
other data.
 To reduce unwanted resources as human power and material wastage in the organization
Significances for prisoner:
 Easy access personal information.
4
 The details information of the prisoner stored in the database without any error and
redundancy.
 Avoid document missing from natural disaster.
1.8. System requirement

Our proposed system will be implemented with the following requirement and technologies.
1.8.1. Software requirement
Visio 2007: - This software is used for drawing the different diagrams we are going to
develop our proposed system.
 WAMP server: - To manage server setting.

 Microsoft Word 2010: -For writing documentation.
 GUI DesignStudio_R46155_Setup: Used to design user interface.
1.8.2. Hardware requirement

 Desktop computer and laptop computers: -These computers are used to install the
above software’s and used to develop system.
 Flash disk (8 GB): The data in the computer may be lost because of different cases,
to take available data from different source and to secure.
 Pen: used to write the drafting of the idea on the paper.
 A4 Size Paper: This is used to draft all the idea on the paper, to collect different
information from any sources and print document.
1.8.3. Programming language
The proposed system implemented by using the following programming language:
 CSS: - For styling the web page.
 Html: - To display content.
 Java script: For client side scripting (interpreted by the browser).
 PHP: - For server side scripting (interpreted by the server).
The project team chooses PHP as server side scripting language because PHP is:-
 Clear and easy to understand.

 Easier to fix problems.
 Operates much faster than other scripting languages.
5
 Open source.
1.9. Methodology of the Project

In developing prisoner information management system for Debre Markos prison administration
the following development methodologies and tools applied.
1.9. 1. Data collection methodologies

Data collection is one of the important tasks to analyze how activities done in existing system
and developed the new system. Data for developing this system obtained from different
sources. These data sources were system users and documents used in the office and reports
of the office. The followings are data collection methods we used:
 Interview: - Was used to gather required data for the project by contacting
different employees of the organization like police officer and inspector.
 Observation : used to gather additional data by observing the actual work being
done by the staff. And consolidated with what was obtained through Interview.
 Document analysis: Was used to collect and analyzed written documents that
describe the operations organizations relevant to the project.
1.9.2. Analysis and Design Methodology

We used object oriented analysis and design approach for modeling and Designing the modules
of the proposed system. The main reason behind using OOAD is:
 In order to check the reusability of the current prisoner information management system.
 In order to define new or modified objects that can be combined with the current prisoner
information management systems in the prison.
1.9.3 .System Development Model
There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred as “Software
Development Process Models". Each process model follows a Series of steps unique to its type
to ensure success in the process of software development. But the proposed system follows
Incremental model. Because In this model, each module passes through the requirements,
design, implementation and testing phases. A working version of software is produced during the
first module, so you have working software early on during the software life cycle. Each
6
subsequent release of the module adds function to the previous release. The process continues till
the complete system is achieved.
1.10. Feasibility study of the project

The main objective of feasibility study is an analysis of how successfully a project can be
completed and to test the technical, operational, economical and legal feasibility.
1.10.1. Technical Feasibility
Does the necessary technology exist, does equipment’s exist? Can the user use the system
without or with less training? The system that has been answering the listed question is said to be
technically feasible.
This project is technically feasible since
 It was accomplished with the available technology like PHP.

 The new automated system will be technically acceptable to the organization since
members to manipulate the system with minimal system training.
1.10.2. Operational Feasibility

It determines how the system satisfies organizations needs or solves the organizations problem
and system has good user interfaces it is simple for users to use the system after developed, So
the system operationally feasible as it very easy for end user to operate and would be
acceptable to Debre Markos prison administration.
1.10.3. Economic Feasibility

Both hardware and software required for developing this system are highly available and can be
owned with small cost, and its benefit had outweighs the cost used to develop the system. The
proposed system to develop will decrease a lot of birr that was expensive to buy the hard
document material such as paper, pencil, rubber, and printer and so on. Also reduce the loss of
data that means if it reduces the loss of data it also reduces the cost of replacing the lost data. If
the organizations have 900 prisoners’ to handle all information there must be use many
employees to manage the data and a lot of paper, pen, and pencil will be bought. But after the
system developed these data can be managed with small employee and in single computer in
very short time.
7
1.10.4. Legal Feasibility

Legally the proposed system is fully feasible because it never contradicts with legal and criminal
laws of the country. If the system has contradicted with the governmental rules regulations
automatically rejected. But this system has not contradicted with the governmental rule and
regulations. Therefore the system is legally feasible
8
Chapter Two: System analysis

2.1. Overview of existing system
The activities of Debre Markos prison administration is semi computerized system. Among that semi
computerized activity prisoners’ registration is the most common system activity, but other activities like
generate report, visitor registration, trainee registration has done in manual and there is no well-organized
database to store and manage prisoners’ information. This is leads to a very inefficient and awkward way
of storing records and greatly slow down the flow of critical information as well as makes looking up of
information time consuming. Generally the existing system has the following problems:
Registration related problem
 Visitor, trainee, and generate report is done manually. This in turn will result in poor
techniques handling the data.
Information Problem
 Due to semi-automated collecting of data there is a redundant record and inconsistency

problems.
 Inaccuracy of data and information may produce.
 Poor flow of information between staff.
 Lack of a well-organized database system.
 Difficult to change.
Data storage problem:
 Data are not easily accessible due to its integration which is placed in different location.
 Loss of data may occur.
Efficiency Problem
 The efficiency of the existing system is not optimal, because Storing, locating of data of
prisoners’ takes much more time.
Security and control problem
 The existing system can be accessed by unauthorized person, since it doesn’t have any
authentication and authorization system.
9
User of existing system
 Inspector
 Office guard
 Police Department/officer
 Parole committee
 Remission Manager
 Training department
 Prisoner release officer
 Prisoners’
 Visitors’
 polices
2.2. System Requirement Specification

2.2.1. Functional requirement
Functional requirements are fundamental building block requirements. It is a statement of
Exactly what the system must do. The following are some functionality of new system:-
 Manage accounts: enables system admin to create, activate, deactivate and update
accounts.
 Authentication: the system will be verified by denying unauthorized user from
using the system for better security.
 Registration: register new prisoner, visitor and trainee to the system.
 View reports and certificates.
 The system should display full information about prisoners’ from the database.
 Send request when transfer prisoner from one prison to another prison.
 Identify the prisoner per-charge means checking whether the prison record or not.
 It allows parole for prisoner based on specific evaluation.
 Room allocation for prisoner
 Create backup and recovery
10
 Generate report and `certificate from the database.

 Update system data information
 Search any system information
 Record court and health appointment
2.2.2. Non -functional requirement
Non-functional requirements describe how the system works, while functional requirements
describe what the system should do. Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the specific services delivered by the system to
its users.
Technical requirement
Security:-The system only permits authorized user to enter the system. Authorized users are who
have username and passwords.
Scalability: If the number of prisoners and user increases in the organization it does not effect
on the database.
Usability: The system has an interactive and attractive GUI which eases users’ usage problem. It
needs simple training, because it is easy to use and adapt.
User Interface: The interface will be user friendly and can properly guide the user how to use
the system and perform operations easily since every link name in the system similar to the task
performed.
Performance: The system performs its task efficiently and effectively because the team project
will uses advanced programming language, less number of iterations for a given task and
optimized query to develop the system
Availability: -This system should always be available for users to access.
Portable: It becomes portable for different platform because we develop the system using
online so it very smart technology to use any browser.
11
2.2.3. Business rule

Business rule is effectively an operating principle or policy the software must satisfy. It often
pertain to access control issues, business calculations, or operating polices and principles of the
organization. Therefore, our new system has the following business rules.
BR1. All users who want to get the service from the system must be valid user name and
password.
BR2. Age of prisoner to register must be greater than 18.
BR3. To get parole Prisoner fulfill conditional evaluation points must be greater than or
equal to 75%.
BR4. Visitors whose age less than 9 are not registered in the system.
BR5. Should be allocating room for male and female separately.
2.3. System requirement analysis

The purpose of System Requirements Analysis is to obtain detailed understanding of the
business need. The primary goal of this phase is to create a detailed Functional Specification
define the full set of system capabilities to be implemented, along with accompanying data and
process models illustrating the information to be managed and the processes to be supported by
the new system.
2.3.1. Actor and Use case Identification

Actor Identification
 Actors: An actor is a person, organization, or external system that plays a role in one or
more interactions with your system.
In our system the following actors are involved: -
 Inspector
 System administrator
 Discipline officer
 Registrar officer
 Security manager.
 Police
 Training officer.
12
 Prisoner lawyer
Use case identification
 Use cases: is a symbol that describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
In this project, we identified the following use cases:
Table 1: use case identification table
Use case name Use case Id Includes

Login UC1
Manage account UC2 Login
Create backup and recovery UC3 Login
Register prisoners’ UC4 Login
Search user information UC5 Login
Update user information UC6 Login
View user information UC7 Login
Assign police UC8 Login
Identify pre-charge UC9 Login
Notice UC10 Login
Send request UC11 Login
Register visitor UC12 Login
Register trainee UC13 Login
Approve request UC14 Login
Evaluate parole point UC15 Login
View request UC16 Login
Generate Report UC17 Login
View prisoner information UC18 Login
13
Create lawyer account UC19 Login
View response UC20 Login
Room allocate UC21 Login
Assign lawyer UC22 Login
View Notification UC23 Login
View applicant UC24 Login
Register user UC25 Login
Use Case Diagram

 Use case diagram shows use cases, actors, and their interrelationships. A use case
diagram is a graphic depiction of the interactions among the elements of a system. A use
case is a methodology used in system analysis to identify, clarify, and organize system
requirements. A use case model describes the proposed functionality of a new system.
A use case diagram contains four components.
 The boundary, which defines the system of interest in relation to the world around it.
 The actors, usually individuals involved with the system defined according to their roles.
 The use cases, which the specific roles are played by the actors within and around the
system.
 The relationships between and among the actors and the use cases.
14
Prison Information Management System

register user Creat account
Extend Notice
Extend View police
Mange account notification
Inactive account
Backup and recovery Approve Inspector

Assign police
System admin
Register prisoner Evaluate parol

information point
<<Include>>
include
include view request
<<Include>>
<<Include>>
update user <<Include>>
information <<Include>>
<<Include>> <<Include>><<Include>>
Register visitor Discipline officer
<<Include>>
Identify pre-charge <<Include>>
<<Include>>
<<Include>>
Room allocation
view appiontement
<<Include>> <<include>>
Registrar officer Security manager
create Accout for <<Include>> Login <<Include>>

laywer view prioner
View user<<Include>>
<<Include>> infromation
information
<<include>> include
<<Exclude>>
assign lawyer Send request
<<Include>>
<<include>> <<Include>> prisoner laywer
Generate Report
<<Include>> <<Include>>
view response
Logout
veiw applicant
Training officer
Notify
Register trainee
Give certificate Police
view notification
Figure 1: use case diagram
Use case description

A use case is an interaction between users and a system. It captures the goal of the users and the
responsibility of system to its users. It is the functionality of the system or the service provided
by the system.
15
Table 2: Login Use case description
Use case Id UC1
Use case Name Login
Actor Inspector, System administer, Security manager, police, Training

officer, Registrar officer ,prisoner lawyer and Discipline Officer
Description: User are authenticated and taken to their own user interface based on
the given privilege.
Pre-conditions User must have valid user name and password.
Post condition The user is authenticated and taken to his/her own user interface.
Basic course of action User action System response
1. The user opens home page. 3. The system will display

2. User click login menu. login form.
4. The user fills the login form. 6. The system will check the
5. The user click on login button. user name and password is
correct.
7. User action performed the
wanted page displayed.
8. End use case
Alternative course of A1.If user name or password is invalid.

action A2.The System display Error Message and return back the user to login
page
Table 3: create account use case description
Use case Id UC2
Use case Name Create account
16
Actor System administer
Description: The administrator creates an account for the actor those who comes to
login to system.
Pre- conditions The system is in the create account state and has the create account
screen displayed.
Post condition Account Created Successfully

1. The system admin click 2. The system will display user
on the create account account creation form.
link. 5. The system will check the filled
3. The system admin fill the form.
form. 6. The system will create user
4. The system admin click account.
on create account button. 7. The system will display
successful message.
8. End use case.
Alternative course of A1. If user misses the required field or entered wrong data, the system
action notifies “the missed field or wrong data” and the process continue
from step 3.
Table 4: Register prisoner use case description
Use case Id UC4
Use case Name Register prisoners’.
Actor Registrar officer.
17
Description: Registers new prisoners.
Pre-conditions The Register office must login into the system
Post condition Prisoners registered.
1. The user click on 2. The system will display

register prisoner registration form.
menu. 5. The system will check the
3. The user fills filled form.
registration form. 6. The system will display
4. The user click on successfully registered
register button. message.
. 7. End use case
Alternative course of A1 .If invalid data register.

action A2. Return to step 3 of flow of events.
Table 5: Update prisoners’ information use case description
Use case Name Update prisoners’ information
Actor Registrar officer and security manager
Description: Update prisoner information when ever needed.
Pre-conditions Prisoner’s information record must exist.
Post condition The prisoner information updated.
18
1. The user click on edit 2. The system will

menu. display update form.
3. The user edits any 5. The system will
information in the form. check filled result.
4. The user click on update 6. The system will
button. update prisoner
information.
7. The system will
display successfully
updated message.
11. End use case.
Alternative course of A1. If user misses the required field or entered wrong data, the system
action notifies “the missed field or wrong data” and the process continue
from step 3.
Table 6: Generate report use case description
Use case Id UC19
Use case Name Generate Report
Actor Registrar officer
Description: Generate a report specified.
Pre- conditions General report.
Post condition Report is generated.
19
1. User click generate report 2. The system display search form.

menu. 5. The system will check the filled
3. The user selects one criteria form.
from combox. 6. The system display wanted
4. The user click on view information.
button. 7. End use case.
Table 7: Register Trainee use case description
Use case Id UC14
Use case Name Register Trainee
Actor Training officer
Description: Register prisoners on different training activities.
Pre- conditions View applicant of prisoner to participate training activities
Post condition Registered trainee prisoners.
Basic course of User action System

response
20
action 1. User click view applicant form 2. The system display all
3. If the user want to register that applicant for trainee.
applicant click on approve button. 4. The system automatically
registers.
5. Use case ends.
Alternative course of A1. If user not accept applicant click on reject button and the system
action automatically send message for prisoner lawyer page.
Table 8: Request transfer use case description
Use case Id UC11
Use case Name Send request
Actor prisoner Lawyer
Description: Prisoner Lawyer can send any request about prisoner based on different
reason like for transfer one prison into another prison or for appointment.
Pre-conditions Prisoner Lawyer Should have account or registered and assign for prisoner.
Post condition System transfer request to inspector.
Basic course of User Action System Response

action
21
1. The prisoner lawyer click on 2. The system will display the link:-
send Request menu.
o Transfer.
3. The prisoner lawyer clicks on o Appointment
transfer or appointment link. o Parole
5. The prisoner lawyer fills the 4. The system display form.

form.
7. The system will check the filled
6. The prisoner lawyer click on form.
send button.
8. The system will display successful
message.
9.End use case
Alternative course A1.If the form is not filled with correct data’s the system will loopback to
of action step 5 and messaged the prisoner what type of error has been occurred.
Table 9: view request use case description
Use case Id UC17
Use case Name View request
Actor Inspector, security manager and training officer
Description: View any request that comes from prisoner lawyer page
Pre-conditions The actor must be login in to the system.
Post condition Actor can be accept or reject the request.
Basic course of action User action System Response
22
1. User clicks on view request menu. 2.The system will display

view request
3. User clicks on inbox menu.
4. The system will display
5. User will select from selection
all Inbox requests.
box.
7.User click on OK button
selection button that
contain.
o Approve request
o Reject request
8. The system will send the
response.

successful message.
10. End use case.
2.3.2. Sequence Diagram

Sequence diagrams are used to show how objects interact in a given situation. An important
characteristic of a sequence diagram is that time passes from top to bottom: the interaction starts
near the top of the diagram and ends at the bottom. The boxes across top of the diagram
represent classifiers or their instances; typically use cases, objects, classes or actors. The solid
lines hanging from the boxes are called objects lifelines, representing the life span of object
during the scenario being modeled. Messages indicate as labeled arrows, when the source and
the target of a message is an object or class label the signature of the method invoked in response
to the message. However, if either the source or target is the human actor, then the message is
labeled with brief text describing the information is available. Generally, a sequence diagram
shows object interactions arranged in time sequence.
23
System Login User page

Controller
All users Home page interface
1.Open()
Actor
2.Click login link
3.Display()
4.Enter username and password

5.Validate form( )
6.Invalid
7.Display error message
8.Valid
9.Click login button
10.Display user page()
Figure 2:Sequence diagram for login page
Admin home Account Controller Database

page interface
System
admin 1.Open()
2.Click account create link

3.Display()
4.Fill form 5.Validate form( ) 6.Invalid
8.Valid
9.Click creat account button
10.Check( )
11.If check not true
14.Successfully created account

13.If check is true
Figure 3: Sequence diagram for create account
24
Registrara Registration Controller Database

Officer page interface
Registrar
officer 1.Open()
2.Click register link

3.Display()
4.Fill form 5.Validate form( ) 6.Invalid
8.Valid
9.Click register button
10.Check( )
11.If check not true
14.Successfully registred
13.If check is true
Figure 4: Sequence diagram for registration
25
Prisoner Request Controller Database

Home page interface
Prisoner
1.open()
2.Click request link

3.Display()
4.fill form 5.Validate form()

6.Invalid
8.Valid
9.Click send request button
10.Check() 11.If check not true
13.If check is true

14.Successfully send report
Figure 5: Sequence diagram for send request
2.3.3. Activity Diagram

Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system. Activity
diagram are best starting point to model logic of business process, use case or method.
This activity diagrams are developed based on the requirement analysis which is done
previously. The team members try to depict the logic of the business process and use case
which was done previously. The red filled circle represents the starting point of the
activity diagram effectively. A place holder and a filled circle with a border represent the
ending point. The rounded circle represents a process of activities that are performed.
The diamond represents decision points and arrows represent the transition between
activities modeling the flow order between the various activities.
26
System home page
Click login menu
Display login form
Re-enter username and password
Enter username and password Click login button
No
If un and pw is
Correct?
Yes
Successfully login
Figure 6: Activity diagram for Login page
27
Click register menu
dispaly register form
Re-enter
Fill the form Click register button
No If the filled
form
is correct?
Yes
Successfully registerd
Figure 7: Activity diagram for registration
28
View
Re-enter
Click Update button
Display update form
Fill the form Click on update button
No If edit
The form
Is correct?
Yes
Updated successfully
Figure 8: Activity diagram for updating
29
2.3.4. Analysis class Diagram

Class diagrams are fundamental to the object modeling process and model the static structure of
a system. Depending on the complexity of a system, you can use a single class diagram to model
an entire system, or you can use several class diagrams to model the components of a system.
Class diagrams are the blueprints of your system or subsystem. You can use class diagrams to
model the objects that make up the system, to display the relationships between the objects, and
to describe what those objects do and the services that they provide. You can use class diagrams
to visualize, specify, and document structural features in your models. You can create class
diagrams to perform the following functions:
 Capture and define the structure of classes.

 Define relationships between classes.
 Illustrate the structure of a model by using attributes and operations.
 Show the common roles and responsibilities that define the behavior of the system.
 Show an inheritance hierarchy among classes.
 Show the workers and entities as business object models in the system.
30
Police
user * send
+Notify()
systemadmin -uid +view notifcation()
-Ufname Notify
+Manage Account()
-Ulname -polID
1
1 *
-edul_evel -fname
-lname
registerar officer -phone_no -sex
-message
-sex -for
+Register()
+generate report() -role Displine officer
+assign() -user_photo
+evaluate()
+view() Evaluation point *
+login() +view()
-Prisoner ID
Traning officer -Goodbehivor:
1 use
view -Workaholice: 1
inspecter -If reconciled: 1
+register trainee() prisoner lawyer * -don.t cheos and coup
1
+prepare certficate() -Totale: *
+approve() send eval_point
1 +view()
+send request() +post notice() 1 view
has 1 1 1
+view response() +assign()
use 1 use
use *
Account Class
1use 1 1
1
-UId
send 1 -usename Security Manager
use 1 1
-password use assign
register -Role 1
+register vistore()
1 assign +generate report()
1 use
+assign() 1
1
1 * * +view()
prisoner
Request view assign police
-PId -Pid 1
-policeId
-Pfname -request type
* * -PID
-Pmname -To -appontiment date register
*
-Plname -request date
-return date
Trainee
-natinality -request case
-region -traning type Vistore
-zone -request date -Vid
-woreda -Pid
-kebele * -fname
-entry date -mname
-exit date -lname
-appdate -sex
-court name -region
-crime type visit
-woreda
-photo -kebele
* * -date
Figure 9: Analysis class diagram
31
Chapter Three: System design

System design is the process of defining the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through that system. 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. It is a means to satisfy specific needs and
requirements of a business or organization through the engineering of a coherent and well-
running system.
3.1. Design Class Diagram

It represents the static view of an application. Class diagram is not only used for visualizing,
describing and documenting different aspects of a system but also for constructing executable
code of the software application. The class diagram shows a collection of classes, interfaces,
associations, and constraints.
Generally, the objectives of design are to model the system with high quality. The design goals
are derived from non-functional requirements that means non-functional requirement is the
description of the feature characteristics and attribute of the system as well as any constraints
that may limit the boundary of the proposed solution.
32
Police
user send
*
+Notify()
systemadmin -uid varchare(30) +view notifcation()
-Ufname varechare(30) Notify
+Manage Account()
-Ulname varchare(30) 1 -polID varechare(20)
1 -edul_evel varchare(30) -fname varchare(20) *
-lname varchare(20)
registerar officer -phone_no varchare(20) -sex vatchare(6)
-message varchare(200)
-sex varchare(20) -for varchare(20)
+Register()
+generate report() -role varchare(20) Displine officer
+assign() -user_photo longtext

+view() * +evaluate()
+login() Evaluation point +view()
Traning officer use -Prisoner ID varchare(20)
1 view -Goodbehivor: int 1
inspecter -Workaholice: int 1
+register trainee() -If reconciled:int
prisoner lawyer * -don.t cheos and coup int * send eval_point
+prepare certficate() 1
+approve() -Totale:int
* 1 +view()
1 +send request() +post notice() 1 view
use has 1 1
+view response() +assign()
1 use
use use
1
Account Class 1 1
1
-UId varchare(20)
register send -usename varchare(20) Security Manager
1 1 use 1
use -password varchare(20) assign
-Role varchare(20) 1
+register vistore()
1 assign +generate report()
use
+assign() 1
1
1 * * +view()
1 *
Request view assign police
-Pid varchare(20) -policeId varchare(20) 1
prisoner
-request type varchare(20) -PID varchare(20)
-PId varchare(20) * -To varchare(20) -appontiment date date
-Pfname varchare(20) -return date date register
-request date varchare(20) *
-Pmname varchare(20)
-request case varchare(20)
-Plname varchare(20)
-natinality varchare(20)
-region varchare(20) Vistore
-zone varchare(20) -Vid varchare(20)
-woreda varchare(20) * -Pid varchare(20)
-kebele varchare(20) Trainee
-fname varchare(20)
-entry date date -traning type varchare(20) -mname varchare(20)
-exit date date -request date date -lname varchare(20)
-appdate date -sex varchare(6)
-court name varchare(20) -region varchare(20)
-crime type varchare(20) visit -woreda varchare(20)
-photo longtext -kebele varchare(20)
* -date date
*
Figure 10: Design class diagram
33
3.1.1. Class diagram Description

Documenting class model is used to document the detail about a class as well as the
Reasoning behind any trade off .The following are the documentation of the class model for the
prisoner information management system.
Table 10 :Prisoner class description
Attribute Description Data Type

PID To represent identification number for the Varchar
prisoner.
Fname To represent first name of the prisoners. Varchar
Mname To represent middle name of the prisoners. Varchar
Lname To represent last name of the prisoners. Varchar
Sex To represent gender type of prisoners. Varchar
Age To represent age of prisoners Int
Nationality To represent nation of the prisoner. Varchar
Region To represent region which the prisoner comes. Varchar

Zone To represent zone which the prisoner comes. Varchar
Woreda To represent woreda which the prisoner Varchar
comes.
Kebele To represent kebele which the prisoner Varchar
comes.
Education level To represent education level of the prisoner Varchar
Entry date To represent date of when the prisoner comes Date
to the prison.
Duration To represent the duration (how long he/she Int
live) of that prisoner.
Exit date To represent date of when the prisoner exit Date
from the prison.
Crime type To represent crime type of the prisoner does. Varchar
Religious To represent religion of the prisoner Varchar
Court name To represent name court that prisoner located. Varchar
34
Prisoner lawyer method

Method Description
Send request() Used to send request to transfer from one prison to another
prison.
View() Used to view personal information.
Table 11: Use account class description

User ID To represent identification of user. Varchar
Username To represent user name for user. Varchar
Password To represent password for user. Varchar
Role To represent select role for user. Varchar
Status To represent active/inactive for user. int(1)
Table 12: Visitor class description

VID To represent identification of visitor. Varchar
PID To represent identification for Varchar
prisoner.
Fname To represent first name for visitor. Varchar
Mname To represent middle name for visitor. Varchar
Lname To represent last name for visitor. Varchar
Sex To represent gender for visitor. Varchar
Region To represent region for visitor. Varchar
Zone To represent zone for visitor. Varchar
Woreda To represent woreda for visitor. Varchar
Kebele To represent kebele for visitor. Varchar
Relation To represent relative for visitor. Varchar
35
3.2. Database design /physical database model/

Physical data model represents how the model built in the database. A physical database model
shows all table structures, including column name, column data type, column constraints,
primary key, foreign key, and relationships between tables.
Table 13: Register Prisoner table
36
Table 14: Register Trainee table
37
Table 15: prisoner lawyer table
38
3.3. User Interface Design

User Interface Designs the design of computers, appliances, machines, mobile communication
devices, software applications, and websites with the focus on the user's experience and
interaction. The goal of user interface design is to create user centered design to enable user to
interact with the system effectively and efficiently. The following interface design pictures
describe the logical characteristics of some interfaces between the system and the users. So the
sample interfaces are shown as follows:
Figure 11: User interface for login page
39
Figure 12: User interface for create account
40
Figure 13: User interface for prisoner registration
3.4. Deployment diagram

Component diagrams and deployment diagrams are closely related. Component diagrams are
used to describe the components and deployment diagrams shows how they are deployed in
hardware. UML is mainly designed to focus on software artifacts of a system. But these two
diagrams are special diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on hardware topology of a system. The purpose of deployment diagrams can
be described as:
 Visualize hardware topology of a system.

 Describe the hardware components used to deploy software components.
 Describe runtime processing nodes.
For this project the project team developed the following deployment diagrams:-
41
Client(Browser) Application server Database

Manage account
Serever
System admin
Register user information
Identify pre-charge
Registrar officer
view personal information
Prisoner Request transfer
Calculate relase time
Security
Give clerance
Release manager
Register Traniner
Give certificate
Traning officer
Register vistore
Security manager Recored appointement
View report
Inspector
View request SQL

Discipline officer Database
Recored parol evaluation point
Figure 14: Deployment Diagram
42
Chapter 4: System implementation

The implementation document helps users on how to work with the system. It acts as a user
manual and it helps users not to be the system confused with. It includes sample forms and some
selected fragment code. It gives the users a brief over view of the system. This document
describes the project implementation for developing the prisoner information management
system. The project implements PHP, MySQL and standard HTML.
4.1 Overview of the programming language used

This project used PHP, CSS, HTML and JS for select the best interface programming technology
Integrated with wamp server database with a programming language.
The project team chooses PHP as server side scripting language because PHP is:-
 Clear and easy to understand.

 It runs on many different operating systems.
 Operates much faster than other scripting languages.
 Open source.
In general PHP is a widely used open source general purpose programming language that is
especially suited for web development and can be embedded into HTML.
4.2 Algorithm Used

Pseudo code
Pseudo code is compact and informal high level description of a computer programming
algorithm that uses the structural conventions of a programming language but is intended for
human reading rather than machine reading. The purpose of using pseudo code is that it is easier
for humans to understand than conventional programming language code, and that it is a
compact and environment independent description of the key principles of an algorithm.
Algorithm use for login

Begin -if
Fill
The Login Form
Click the Login button
If (Form is filled)
If (valid)
Generate SQL select queries
Connect to database
Pass queries to database
If (any query fails)
Display error message
Else
Read session
43
If session exists on database, user is already logged in,

Display the page
Else
Display the page error message

End if
End if
Else
Display error message
Ask the user to refill the form
End if
End if
4.3 Sample Codes

Sample code for assign police
<?php
session_start();
?>
<html>
<div class="square">
<head>
<style>
.date{
margin-top:-330px;
}
.error {color: #FF0000;}
.success{color:#3d8e1e;
}
</style>
<title>Police assign</title>
<link rel="stylesheet" href="css/main_menu.css">
<link rel="stylesheet" href="css/no1.css">
<link rel="stylesheet" href="css/backgroundcolor.css">
<link rel="stylesheet" href="css/securitycss.css">
<style>
.error {color: #FF0000;}
.success{color:#12810c;}
.date{
margin-top:-183px;
}
#section {
width:650px;
float:left;
44
padding:48px;
height:160px;
margin-bottom:5px;
margin-left:180px;
margin-right:10px;
margin-top:-230px;
}
</style>
</head>
<body>
<div id="header">
<?php
include("header.php");
?>
</div>
<div id='cssmenu'>
<?php include("inc\hearderlogout.php"); ?>
</div>
<?php
include("security.php")
?>
<div class="date">
<div class="date">
<?php
require("inc/profile_date.php");
?>
</div>
<?php
if(isset($_SESSION['Username'])&& isset($_SESSION['Password']))
{
$police=$_SESSION['$police'];
//echo $police;
?>
<div id="section">
<fieldset style="height:230px; width:500px; border:1px
solid #336699;
border-radius:20px; margin-top:-115px;
margin-left: 29px;" >
<br>
<form enctype="multipart/form-data" action="" method="POST">
PoliceID:
<select name="poid" style=" width: 60%; height:9%; border-radius:4px;font-
size:15px;box-sizing: border-box; border: 1px solid #060907; box-sizing: border-box;
padding: 0px;">
45
<?php
$sql1="select * from usertable where role='police' and status='Active'and
policestatus='free'";
$sql1=mysqli_query($con,$sql1);
if($sql1)
{?>
<option value="">Select polic ID from user table</option>

<?php
while ($row=mysqli_fetch_array($sql1))
{?>
<option value="<?php echo $row["UserID"];?>">

<?php echo $row["UserID"];?>
</option>
<?php
}}
?>
</select>
<br><br>
PrisonerID:
<select name="pid" style=" width: 60%;height:9%; border-radius:4px;font-
size:15px;box-sizing: border-box; border: 1px solid #060907; box-sizing: border-box;
padding: 0px;">
<?php
$sql1="select * from requesttable where unread='yes' and Requesttype='Health'";
$sql1=mysqli_query($con,$sql1);
$date=date('Y-m-d');
$sql="select * from prisoner where appdate='$date' and appstatus='new'";
$sql=mysqli_query($con,$sql);
if($sql1 or $sql)
{?>
<option value="">Select prisoner ID from requesttable</option>
<?php
while($row=mysqli_fetch_array($sql1))
{
?>
<option value="<?php echo $row["pid"];?>">

<?php echo $row["pid"];?>
</option>
<?php
46
while($row1=mysqli_fetch_array($sql))
{
$pid=$row1['pid'];
?>
}
<option value="<?php echo $pid;?>">
<?php echo $pid;?>
</option>
<?php
}}?>
</select>
<br><br>


<input type="submit" value="Assgin" name="assgin" style="width:72px;">

<input type="reset" value="Reset" style="width:72px; margin-left:-10px;"/>
</form>
<?php
if(isset($_POST["assgin"]))
{
$poid=$_POST["poid"];
$pid=$_POST["pid"];
//$Requesttype=$_POST["Requesttype"];
if($con)
{
$sql1="select * from prisoner where pid='$pid' and
app='Court'";
$result=mysqli_query($con,$sql1) ;
if($result)
{
while($row1=mysqli_fetch_array($result))
{
$fnc=$row1['firstname'];
$lnc=$row1['middlename'];
$sexc=$row1['sex'];
$pcrimetypec=$row1['crimetype'];
$appc=$row1['app'];
$photoc=$row1['Photo'];
47
$sql4="insert into assginpolice

values('$poid','$pid','$fnc','$lnc','$sexc','$pcrimetypec','$photoc','','$appc','yes','identity(1
1)')";
$inserted=mysqli_query($con,$sql4);
if($inserted)
{
$sql="update usertable set policestatus='no free' where UserID='$poid'and
role='police'";
$update=mysqli_query($con,$sql);
if($update)
echo "<div class='success'><img src='image/success.jpg' style='height:19px;'/>
This police is assigned successfully...</div>".mysqli_error($con);
else
echo "<div class='error'><img src='image/delete.jpg'style='height:19px;'/>
not assigned</div>".mysqli_error($con);
}
}
}
else
{
$sql="select * from requesttable where pid='$pid' and Requesttype='Health'";
$result1=mysqli_query($con,$sql) ;
while($row=mysqli_fetch_array($result1))
{
$fn=$row['Pfname'];
$ln=$row['plname'];
$sex=$row['sex'];
$pcrimetype=$row['pcrimetype'];
$trasfer=$row['Requesttype'];
$photo=$row['photo'];
$sql3="insert into assign police
values('$poid','$pid','$fn','$ln','$sex','$pcrimetype','$photo','','$trasfer','yes','identity(1,1)')
";
$inserted=mysqli_query($con,$sql3);
if($inserted)
{
$sql="update usertable set policestatus='no free' where UserID='$poid'and
role='police'";
$update=mysqli_query($con,$sql);
if($update)
echo
"<div class='success'><img src='image/success.jpg' style='height:19px;'/>
This police is assigned successfully...</div>".mysqli_error($con);
else
echo "<div class='error'><img src='image/delete.jpg' style='height:19px;'/>
48
not assigned</div>".mysqli_error($con);
}
}
}
else
echo "Connection Failed";
}
?>
</fieldset>
</div>
<?php
}
else
{
header("location:login.php");
}
?>
<div id="footer">
<?php
include("inc/foot.php");
?>
</div>
</div>
</div>
</body>
</div>
</html>
49
Chapter 5: Testing
Testing is the final phase of implementation. Testing is a process to show the correctness of the
program. Testing is checking of the system workability in an attempt to discover errors and
avoiding such errors from the system. In this the team members tested the entire system as a
whole with all forms, code, modules.
5.1 Sample test

In essence system testing is not about checking the individual parts of design, but about checking
the system as a whole. System testing insures the following have been met correctly.
1. Performance testing: Determines how the system performs on the range of possible
environments in which it may be used. This test is done by configuring the system in different
environments like different operating system, different hardware configurations.
2. Testing the Accuracy: the system give only valid result, if no data is found with the specified
criteria the system should not give invalid response. Since, our application fulfils these
characteristic it is accurate.
3. Security testing: Security testing was done by trying to access the system that is not
authorized. For example without the valid user name and password tester will try to access the
system
Figure 15: System testing for Login page.
50
Chapter six: Conclusion and Recommendations

6.1 Conclusion
The project is aimed at developing a web based prisoner information management system. The
system allow employee in the organization easily manage all prisoner information in easy way.
After we have completed the project we are sure the problems in the existing system would
solved. This automated system provides many advantages for all system users. The main focus of
this project is to reduce human effort.
6.2 Recommendations
Nowadays, the world is highly becoming a competitive world in technology. So, Organizations
should have to divert their attention on using the recent technology to facilitate their work
properly. This can be real if they are able to use recent information technology (IT) to
successfully achieve their objective.
We are recommended Debre Markos prison to use the developed system in order to facilitate the
work process and to reduce wastage time to manage all prisoner information in the organization.
Finally, we would like to recommend some points on the usage and accessibility of this system.
 The organization should have adequate computer facilities for the introduction of the new
system.
 These systems need an educated person so every user’s should know about how
computer works and take basic computer training skills.
6.3 Future Enhancement

According to scope of our project the team develops web based application. Because of the time
constraint we may have limitation which should be consideration in, but n the feature the team
believes that this system should be fully operationally by adding some functionality that are not
Included in the proposed system. We also want to recommend this project can be expanded and
more automated with additional functionalities by integrating with many new technologies.
We recommend to be included the following functionality
 The system will include all employee or staff worker in the prison not only prisoner.
 The system will take attendance for prisoner each day.
 The system will support other language like Amharic.
51
Reference
1) https://chilot.files.wordpress.com/2011/01/reg-no-138-treatment-of-federal-prisoners.pdf
2) https://www.ibm.com/support/knowledgecenter/...9.../cclassd.html
3) System analysis and design 5th edition.
4) https://www.smartdraw.com/use-case-diagram/
5) https://www.inflectra.com/ideas/topic/requirements-definition.aspx
6) https://www.w3schools.com/
52

Prisoner Information Managment System

Uploaded by

Copyright:

Available Formats

Prisoner Information Managment System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Prisoner Information Managment System

Uploaded by

Copyright:

Available Formats

What is the purpose of developing this system?

What is the purpose of developing this system?

What are the main functions of the system?

What are the main functions of the system?

Web based Prisoner Information Management System

(Debre Markos Town)

DEPARTMENT OF INFORMATION TECHNOLOGY

DEBRE MARKOS, ETHIOPIA

APPROVAL OF ADVISOR AND EXAMINERS

Advisor Name ____________________ Signature ____________

2.3. System requirement analysis............................................................................................................ 12

CSS: - Cascade style sheet

Chapter One: Introduction

1.2. Background of the project

1.3. Statement of Problem

Data sharing problem Recorded Prisoner information in a single computer but no

1.4. Overview of Proposed system

1.5. Objective of the Project

1.6. Scope of the project

 Backup and recovery.

1.7. Significance of Project

Significances for prison:

1.8. System requirement

 WAMP server: - To manage server setting.

1.8.2. Hardware requirement

 Clear and easy to understand.

1.9. Methodology of the Project

1.9. 1. Data collection methodologies

1.9.2. Analysis and Design Methodology

1.10. Feasibility study of the project

This project is technically feasible since

 It was accomplished with the available technology like PHP.

1.10.2. Operational Feasibility

1.10.3. Economic Feasibility

1.10.4. Legal Feasibility

Chapter Two: System analysis

Registration related problem

 Due to semi-automated collecting of data there is a redundant record and inconsistency

Security and control problem

User of existing system

2.2. System Requirement Specification

 Generate report and `certificate from the database.

Availability: -This system should always be available for users to access.

2.2.3. Business rule

2.3. System requirement analysis

2.3.1. Actor and Use case Identification

In our system the following actors are involved: -

In this project, we identified the following use cases:

Table 1: use case identification table

Use case name Use case Id Includes

Approve request UC14 Login

Evaluate parole point UC15 Login

View request UC16 Login

Generate Report UC17 Login

View prisoner information UC18 Login

Create lawyer account UC19 Login

View response UC20 Login

Room allocate UC21 Login

Assign lawyer UC22 Login

View Notification UC23 Login

Advisor Name ________ Signature