Vital Managment System All Chapters

Wolkite University
College of Computing and Informatics

Department of Information System
Title: Vital Management System for Gurage Zone
Group Members Id_No

Ismael Fetiku ……………………………. CIR/177/09
Binyam Tesfaye …….……………………CIR/073/09
Advisor
Mr. Wendosen Z. (Msc)
Wolkite University, Wolkite, Ethiopia
January 2020
Declaration
This is to declare that this project work, which is done under the supervision of
mr. Wendosen (msc) and having the title, Gurage zone vital management
system is the sole contribution of Ismael Tetiku and Binyam Tesfaye.
No part of the project work has been reproduced illegally (copy and paste)
which can be considered as plagiarism. All referenced parts have been used to
argue the idea and have been cited properly. We will be responsible and liable
for any consequence if violation of this declaration is proven.
Date: _____________________
Group Members:
Full Name Signature
_________________________ ____________________
_________________________ ____________________
i
Approval Form
This is to confirm that the project report entitled gurage zone vital
managment is submitted to wolkite university, college of computing and
informatics department of information systems by: Ismael Fetiku, Binyam
Tesfaye and Wendosen Z.(msc) is approved for submission.
Advisor Name Signature Date
----------------------------------------- ------------------------------
--------------
Department Head Name Signature Date

----------------------------------------- ------------------------------
----------------------Examiner 1 Name Signature
Date
----------------------------------------- ------------------------------
--------------
Examiner 2 Name Signature Date
----------------------------------------- ------------------------------
--------------
Examiner 3 Name Signature Date
----------------------------------------- ------------------------------
--------------
ii
Acknowledgment
First, we would like to thank almighty God/Allah for the strength, he has given us throughout
our life and this project; nothing could happen without the help of god. Secondly, we would
like to express our gratitude to our advisors Mr. Wendosen z(MSC) for his help, willingness
and commitment in giving his precious time to help us to accomplish this work. Thirdly, we
also very grateful and would like to extend our sincere thanks to our teachers and students of
college of computing and informatics for sharing their ideas, suggestions, and support
especially for their commitment. Fourthly, we would like to thanks for all Gurage zone vital
event employees who provides better information about the existing system.
Finally, we really give a great respect and credit to everyone who involved in our project
tasks.
Table of Contents
iii
Table of Contents
Approval Form......................................................................................................................................ii
Acknowledgment.................................................................................................................................iii
Table of Contents.................................................................................................................................iv
List of Figures.....................................................................................................................................vii
List of Table.......................................................................................................................................viii
List of Abbreviations............................................................................................................................ix
ABSTRACT..........................................................................................................................................x
CHAPTER ONE...................................................................................................................................1
1. INTRODUCTION.........................................................................................................................1
1.1 Background of the Organization............................................................................................1
1.2 Statement of the Problem......................................................................................................2
1.3 Objective of the Project.........................................................................................................3
1.3.1 General Objective..........................................................................................................3
1.3.2 Specific Objective................................................................................................................3
1.4 Feasibility Analysis...............................................................................................................3
1.4.1 Technical Feasibility.....................................................................................................3
1.4.2 Operational Feasibility..................................................................................................4
1.4.3 Economic Feasibility.....................................................................................................4
1.5 Scope and Limitation of the Project......................................................................................4
1.5.1 Scope of the Project.......................................................................................................4
1.5.2 Limitation of the Project.......................................................................................................5
1.6 Significance of the Project.....................................................................................................5
1.7 Beneficiary of the Project......................................................................................................5
1.8 Methodology of the Project...................................................................................................6
1.8.1 Data Collection Tools/Techniques.................................................................................6
1.8.2 System Analysis and Design.........................................................................................7
1.8.3 System Development Model..........................................................................................7
1.8.4 Development Tools and Technologies...........................................................................8
1.8.4.1 Frontend Technologies......................................................................................................8
1.9 Document Organization........................................................................................................8
2. DESCRIPTION OF THE EXISTING SYSTEM..........................................................................9
2.1 Introduction of Existing System............................................................................................9
iv
2.2 Users of Existing System......................................................................................................9
2.3 Major Functions of the Existing System..............................................................................10
2.4 Forms and Other Documents of the Existing Systems.........................................................10
2.5 Drawbacks of the Existing System......................................................................................13
2.6 Business Rules of the Existing System................................................................................14
CHAPTER THREE.............................................................................................................................16
3. PROPOSED SYSTEM................................................................................................................16
3.1 Functional Requirements.....................................................................................................16
3.2 Non-functional Requirements..............................................................................................16
3.2.1 User Interface and Human Factors.....................................................................................16
3.2.2 Hardware Consideration.....................................................................................................17
3.2.3 Security Issues....................................................................................................................17
3.2.4 Performance Consideration................................................................................................18
3.2.5 Error Handling and Validation...........................................................................................18
3.2.6 Quality Issues.....................................................................................................................18
3.2.7 Backup and Recovery.........................................................................................................18
3.2.8 Physical Environment.........................................................................................................18
3.2.9 Resource Issues..................................................................................................................19
3.2.10 Documentation.................................................................................................................19
Chapter Four.......................................................................................................................................20
4. SYSTEM ANALYSIS....................................................................................................................20
4.1 System Model...........................................................................................................................20
4.2 Object Model.............................................................................................................................32
4.2.1 Class Diagram....................................................................................................................32
4.2.2 Data Dictionary..................................................................................................................32
4.3. Dynamic Model........................................................................................................................34
4.3.1. Sequence Diagram.............................................................................................................34
4.3.2. Activity Diagram...............................................................................................................38
4.3.3 State Chart Diagram...........................................................................................................45
CHAPTER FIVE................................................................................................................................47
5. SYSTEM DESIGN.........................................................................................................................47
5.1 Design Goals.............................................................................................................................47
5.2 Proposed System Architecture..................................................................................................48
v
5.2.1 Subsystem Decomposition and Description.......................................................................49
5.2.2 Hardware/Software Mapping.............................................................................................51
5.2.3 Detailed Class Diagram......................................................................................................52
5.2.4 Persistent Data Management..............................................................................................52
5.2.5 Access Control and Security...............................................................................................58
5.3 Packages....................................................................................................................................59
5.4 Algorithm Design......................................................................................................................59
5.6 User Interface Design................................................................................................................60
CHAPTER - SIX.................................................................................................................................62
6. IMPLEMENTATION AND TESTING......................................................................................62
6.1 Implementation of the Database........................................................................................62
6.2 Implementation of Class Diagram.......................................................................................63
6.3 Configuration of Application Server...................................................................................64
6.4 Configuration of Application Security..................................................................................64
6.5 Implementation of User Interface........................................................................................70
6.6 Testing.................................................................................................................................71
6.6.1 Testing Tools and Environment...................................................................................71
6.6.2 Unit Testing.................................................................................................................71
6.6.3 Integration Testing......................................................................................................71
6.6.4 Acceptance Testing.....................................................................................................72
Chapter Seven.....................................................................................................................................73
7. CONCLUSION AND RECOMMENDATION...........................................................................73
7.1 Conclusion................................................................................................................................73
7.2 Recommendation.......................................................................................................................73
Bibliography........................................................................................................................................74
List of Figures
Figure 1-1 Ethiopians Vital events registration organizational structure.....................................................2
vi
Figure 2-1 Divorce registration form.........................................................................................................10
Figure 2-2 Marriage registration Form......................................................................................................11
Figure 2-3 Death Registration Form..........................................................................................................12
Figure 2-4 Birth Registration Form...........................................................................................................13
Figure 4--1 Use Case Diagram....................................................................................................................21
Figure 4-0-2 Class Diagram.......................................................................................................................32
Figure 4-3 Sequence diagram for register event........................................................................................34
Figure 4-4 Sequence diagram for update event..........................................................................................35
Figure 4-5 Sequence diagram for delete user.............................................................................................36
Figure 4-6 Sequence diagram for update event..........................................................................................37
Figure 4-7 Activity diagram for login........................................................................................................38
Figure 4-8 Activity diagram for create user...............................................................................................39
Figure 4-9 Activity diagram for delete account.........................................................................................40
Figure 4-10 Activity diagram for register event.........................................................................................41
Figure 4-11 Activity diagram for report event...........................................................................................42
Figure 4-12 Activity diagram for categorize data......................................................................................43
Figure 4-13 Activity diagram for print certificate......................................................................................44
Figure 4-14 State chart diagram for login..................................................................................................45
Figure 4-15 State chart diagram for register event.....................................................................................46
Figure 5-1 Proposed system architecture...................................................................................................49
Figure 5-2 Subsystem Decomposition.......................................................................................................50
Figure 5-3 Hardware/Software Mapping...................................................................................................51
Figure 5-4 Detailed Class Diagram...........................................................................................................52
Figure 5-5 Mapping table for zone class....................................................................................................53
Figure 5-6 Mapping table for account class...............................................................................................54
Figure 5-7 Mapping table for admin class.................................................................................................54
Figure 5-8 Mapping table for event class...................................................................................................55
Figure 5-9 Mapping table for kebele registrar class...................................................................................55
Figure 5-10 Mapping table for kebele class...............................................................................................56
Figure 5-11 Mapping table for News classFigure ……………………………………...…………….55
Figure 5-12 Mapping table for wereda registrar class................................................................................56
Figure 5-13 Mapping table for wereda class..............................................................................................57
Figure 5-14 Mapping table for zone registrar class....................................................................................57
Figure 5-15 Persistence data management.................................................................................................58
Figure 5-16 package..................................................................................................................................59
Figure 5-17 Registrar page user interface..................................................................................................60
Figure 5-18 Birth registration page user interface.....................................................................................61
List of Table
Table 3-0-1 Requirement specification......................................................................................................17
Table 4-0-1 Login Use case Description....................................................................................................21
vii
Table 4-0-2 Manage Account use case description....................................................................................22
Table 4-0-3 Register Event use case description.......................................................................................24
Table 4-0-4 Report Birth use acse discription............................................................................................24
Table 4-0-5 Update Event use case description.........................................................................................25
Table 4-0-6 Post News use case description..............................................................................................26
Table 4-0-7 Categorize Data use case description.....................................................................................27
Table 4-0-8 Print Certificate use case description.....................................................................................28
Table 4-10 Admin Table data dictionary...................................................................................................33
Table 4-11 Kebele Registrar data dictionary.............................................................................................33
Table 4-12 Wereda registrar table data dictionary.....................................................................................33
Table 4-13 Event Table data dictionary.....................................................................................................33
Table 5-1 Access Control..........................................................................................................................58
List of Abbreviations
HTML…………………………………. Hypertext Mark-up Language
CSS……………………………………...Cascading Style Sheet
PHP……………………………………. Hypertext Pre-processor
viii
MYSQL………………………………. My Structured Query Language
WAMP…………………………………Windows Apache MySQL PHP
UML………………………………….... Unified Modeling Language
BR……………………………………. Business Rule
UC……………………………………. Use Case
ALT……………………………………Alternate Course of Action
UCID……………………………………Use case Identifier
GHz……………………………………. Gigahertz
ABSTRACT
This project mainly focuses on vital management system for Gurage zone. The main
objective of the project is solving problems by identifying the existing system problems that
arise from the office and we analyses the problem, gather requirements and designing of the
system to solve existing problem. The reason we prefer the title is to ensure Gurage zone
vital registration go to computerized data control and management and have access to fast,
ix
accurate database. The project is web based so it is user friendly system and it provide more
significant for the developer, and office.
The document shows the detail study on registration management system. Fact finding
techniques like interview and documents analysis have been used to collect information
about the system. The new system is proposed and analyzed using object oriented methods
like Use Case Diagram, Activity Diagram, and Sequence Diagram. A specification of the
new system is designed using deployment diagram and class diagram. A detailed algorithm is
also developed for each method identified in the class diagram. The design part also
incorporates database design at the back end and interface design at the front end
CHAPTER ONE
1. INTRODUCTION
Vital Events registration generates documentation that supports an individual’s right to
recognition as a person before the law and acknowledges their formal relationship with the
state. Individuals are able to have their existence, identity, and vital events legally recognized
and obtain proof of legal and civil status through valid certificates. The absence of civil
registration has been described as a ‘scandal of invisibility’[ CITATION Wik19 \l 1033 ].
Ethiopia launched throughout the country on 4 August 2016 a permanent, compulsory and
universal registration and certification of vital events such as birth, death, marriage and
divorce, to stablish the legal documents required by law. Since then 18 percent of children
who are under age of 1 have been registered which is a great success compared to 2016
where only 3 percent were registered[ CITATION Eth16 \l 1033 ].
Vital event registration is now very important for countries including our country for various
purposes like developing appropriate policies for certain place based on the registered data,
used as evidence for courts and it also used for government planning and budgeting by
providing the exact number of population. In general, vital event registration means
registering events that are so important or have great impact on certain country.
1.1 Background of the Organization

The historical attempt to establish vital events registration system in Ethiopia started during
the reign of Minilik II. After time the other effort to establish the conventional vital events
x
registration system in Ethiopia was mainly associated with the inclusion of the civil
registration provisions (about 100 Articles) in Civil code of 1960. However, Article 3361 of
the code states that registration of civil status shall not come into force until a day to be
notified by Order published and the Order was not published and the provisions of the code
was not enforced. Since then 18 percent of children who are under age of 1 have been
registered which is a great success compared to 2016 where only 3 percent were
registered[ CITATION Eth16 \l 1033 ].
Ethiopians Vital events registration organizational structure look like this
Federal Body
Regional Vital Events Federal Vital Events

Registration Council Registration Council
Board of Management Board of Management
Director General of
Director General
Regional Vital
of Regional Vital
Events registration
Events registration
Zonal Registration
Office
Woreda
KEBELE
E
Figure 1-1-1 Ethiopians Vital events registration organizational structure
xi
1.2 Statement of the Problem
Government has used different mechanism like BPR (business processing and reengineering)
order to speed up the work with high quality and performance by using less number of
workers. Since Vital registration is a crucial source of reference to make country or regional
even zone level plans and decisions its data must be kept in a modernized way of information
management system.
It is known that there is a great difference between the offices those relies on computer to
perform their job and those who are paper based to provide the service for the society. The
Gurage Zone which have selected also relies on paper based to perform their daily task.
Records are not properly maintained. This creates a lot of problems like during information
retrieval and storage. Due to redundant data, more space is occupied by file cabinets.
Computerization of civil registration will broaden the uses that can be made of the civil
registration system, to mention the main advantage linkage of the civil registration system to
other computerized systems will become possible. In both the civil registration system and
the Vital statistics system, issuance of a unique registration or personal identification number
should take place at the time of birth or at the initial registration of an individual. One of the
main purposes of computerization will usually be to enhance the quality of civil registration
data and consequently the quality of the vital statistics[ CITATION Fed18 \l 1033 ].
1.3 Objective of the Project

1.3.1 General Objective
The general objective of this project is to develop an automated vital event registration
system for Gurage zone.
1.3.2 Specific Objective

In order to achieve the main objective, we planned the following specific objectives:
 To study the existing system.

 To specify the functional and Non-functional requirement of the new system.
 . To write document.
 To implement the new system
 To maintain and update the system when needed
xii
1.4 Feasibility Analysis
1.4.1 Technical Feasibility
In this system development time, are using the resource that met need of knowledge in our
standard. In our three years of student experience, we gained a lot of knowledge regarding
about the development and maintenance of a full functioning front and back end web system.
So for the front end of the system we will be using HTML, CSS, JavaScript, Bootstrap; PHP
script for server side, MySQL to manage our database management system and Apache as a
back end server which fast and work smoothly with PHP and compatible with MySQL.
We are familiar with all listed development tools, so we are hoping this system will be
technically feasible.
1.4.2 Operational Feasibility

The new system will have user-friendly and simple navigation interface to be operated by
both employees and customers easily. And the proposed system will capable of working
on less complexity operating system used in user computer. Since this is a web-based
system only need a web browser to run the system and the system will be operated under
the compatible windows.
In this system personnel or who is supposed to manipulate this system shall have trained how
to work with the new system. Therefore, the proposed system or the new system is
operationally feasible because:
 The new system fits with the existing operational system.
 Satisfy the user need or requirement.
 Provide the customer and workers with timely, accurately, reliable and flexible
and usefully formatted information.
1.4.3 Economic Feasibility

One of the reasons to develop this system is to minimize the cost that keeps wasting for
unnecessary reasons like paper and employee fees to control search and keep the paper based
system.
After the development of this system:
xiii
 Employees fee cost will be minimized
 Small response time and many services, since residents stop wasting time in kebele
for the simple task they would go back to their work immediately; This will help
indirectly for the development of the country
 zonal annual budget would not be wasted after the deployment of the system as they
use the Vital management system to know the number, age, sex, and relation status of
the residents.
1.5 Scope and Limitation of the Project

1.5.1 Scope of the Project
The current system is manual and runs at many stages so our working boundary will be the
overall structure of Gurage Zone event registration offices that specially focuses on
registration of birth, death, marriage, adoption, and divorce events and generating reports like
event certificates. Our project will serve for only Guirage Zone Vital Events registration
office.
1.5.2 Limitation of the Project

Doesn’t register vital events like stillbirth, fetal death, annulment and separation
1.6 Significance of the Project

Generally, the system minimizes the problem of traditional system by providing the
following benefits:
 Reduce time and resource required to transfer information between different

government offices.
 Manage the stored data and control from different risks.
 Reduces probability of errors.
 Fasten and facilitate the registration process for residents.
 Provide timely and well-organized information.
 Avoiding data loss.
 Reduce the redundancy of data.
 Flexible way of information exchange.
 Gives effective and efficient service to user.
xiv
1.7 Beneficiary of the Project
For the employees that work in every stage of registration: -
 It can facilitate the vital events registration system by changing it to more automated
system.
 It transmits data quicker than the existing system.
 Help to avoid errors on registering form of data.
 Effective and efficient data collection.
 Effectively manage data statistically
For government:
 Government can easily perform national census and categorize population into
different group.
 Government can easily find out why some vital events are occurring more frequently
in some places and recommends the solution.
 Helps in designing appropriate policy by providing reasonable statistical data.
 Use as evidence in many areas like citizenship, courts, and to eliminate things that are
done arbitrarily like early marriage etc.
 Provides a secure exchange of vital and statistical information.
For end users: -
People can ask their rights using the registered data as evidence.
For example:
 To ask for Keble id card

 To ask citizenship
 To ask government different types of infrastructures.
 To use it as evidence in courts. etc.
1.8 Methodology of the Project

1.8.1 Data Collection Tools/Techniques
we used different types of data collection methods both primary and secondary sources.
Primary data source:
xv
 Interview: we used interview as one of the major data collection methods. During the
interview we got different necessary information from the vital event registration
office of Gurage Zone.
 Observation: in order to get better information about the system we have gone
through
the vital event registration process.
Secondary source data
 Internet: We used internet to cross check the constitutional rights people get if they
register vital events that they experience trough their life. And also the internet helps
us to see the available sample and to download different types of tutorials which help
us in developing the system.
 Document Analysis: we analyzed different documents and brochure from the
Gurage Zone vital event registration office.
1.8.2 System Analysis and Design

There are different types of software development methodologies from this we chose Object
oriented system analysis and design methodology for the following reasons:
 It is easy to understand.
 It is easy to maintain, so after the system is installed the maintenance wouldn’t be a
problem
 It provides re-usability.
 It reduces the development time & cost.
 It improves the quality of the system due to program reuse.
 It is process oriented
 Its main focus is process
 There is a separation of the systems data and processes
 It breaks down the system data through the use of Data Flow Diagram (DFD).
1.8.3 System Development Model
We are planning to use the iterative model for system development. The reasons that we are
selecting the Iterative SDLC (System Development Life Cycle) Model is:
xvi
 Easily incarnate or backward to any phase
 Results are obtained early and periodically this will help us to make changes on the
system if it doesn’t met the required quality.
 A parallel development can be planned
 Progress can be measured we can easily know where we are in the process of
development.
 Less costly to change the scope/requirements, since we aren’t that much familiar with
the Vital registration of Gurage zone working flow or the rules and regulation with it
we can easily change the scopes and functionality of the system.
1.8.4 Development Tools and Technologies

1.8.4.1 Frontend Technologies
For the front end of the system we will be using HTML, CSS, JavaScript, Bootstrap
(tweeter’s product framework, which is awesome) and some other available and easy to work
with technologies.
1.8.4.2 Backend Technologies

We will be using PHP script for server side scripting and MySQL to manage our database
management system. Apache as a back end server which fast and work smoothly with PHP
and compatible with MySQL.
We are familiar with all listed development tools, so we are hoping to be sure this system
will be technically feasible.
1.8.4.3 Documentation and Modeling Tools
We use Edraw max to design the UML diagram, Microsoft word to write documentation.
1.9 Document Organization

The rest of the document is organized as follows. In the second chapter we will describe the
existing system working flow step by step. We clarify the users of the existing system. We
will ask and answer the major functions of the system. In addition, we will list down
disadvantages and many more difficulties to work well.
In the third chapter we will discuss the overall description of our proposed system,
functional requirements, and non-functional requirements. We will show what kind of
interface the system provides. And we will identify how money users can be serviced at a
concurrent time. We will also provide technical documentation at this chapter.
xvii
In the fourth chapter we will model comprised use case diagram, use case definitions, and
actor definitions to document the functional requirements of a system. And also we provide
the systems class diagram, dynamic diagram, activity diagram, state chart diagram.
In the fifth chapter we will provide a brief overview of the design goals, current and
proposed software architecture, Hardware/software mapping, Persistent data management
and Access control and security.
CHAPTER TWO
2. DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction of Existing System
A vital event is a major change in an individual’s status that leads to a change of population
size and status. There is no consensus among policy makers and demographers as to what
specifically constitute vital events. So the Gurage zone vital registration office register birth,
death, marriage, divorce and adoption in a centralized manner for the aim of providing strong
supportive data for policy makers, government planners and other purposes like business
plan making process.
All this listed registration process are done in lower level of government agency which is
kebele. Then the kebele pass those data to wereda registration offices and to zone. No copy
of data is left at wereda level, which means all residents data passed to zone level registration
offices.
2.2 Users of Existing System

The current system has many users. Those are: -
1. Government offices: - government offices are major user of this vital event registration
system. This helps the government to make effective decisions, to design appropriate polices
for appropriate place; it can give recommendations to solve some problems etc. This
government office includes:
 Central statistics agency: -the vital events registration management system can
also be useful to central statistics agency by providing easy way to conduct
statistical analysis on population. For example, making easy to do national
census, to know easily that how frequently occur those vital events and the cause
of them.
 Zonal education offices: -vital event registration information is very important
for education offices and schools because if children registered those offices can
xviii
easily know that how many children are ready to go to school and can mobilize
parents to send the children to school.
2. Health officers: -are also users of this system. They give newborn notifications to kebele
and zone registration offices.
3. Zone registration office: workers of this office analyze the collected resident’s data, they
also give printed registration certificates.
4. Wereda registration offices: At this level, workers of the office can see the data, which is
sent from kebele, and review it then passed to zone level offices.
5. Kebele Registration offices: - those offices have responsibility to register the vital events
that occur
within the Keble.
2.3 Major Functions of the Existing System

The major functions in the existing system are as the following: -
Registration: - the existing system is mainly used for registration of vital events.
Give certificates: - after registration of events the existing system gives certificates.
Generate reports: the existing system give reports about the residents to the government,
health centers, education egency and national statics agency.
xix
2.4 Forms and Other Documents of the Existing Systems
Figure 2-2-2 Divorce registration form
xx
Figure 2-2-3 Marriage registration Form
xxi
Figure 2-2-4 Death Registration Form
xxii
Figure 2-2-5 Birth Registration Form
2.5 Drawbacks of the Existing System

Performance (Response Time): During the time of accessing information the system
response time takes too much time, and when residents try to get passport they have to go to
regional and federal registration offices in person hopefully after the development of our
system this problem will be fixed.
Security: Since the existing system is manual it is not secure that there is no authentication
mechanism for checking the information that is collected from the individual.
Service: Data transferring between different offices is done manually.
Redundancy: Having or storing the same information related to residents in multiple
location.
xxiii
2.6 Business Rules of the Existing System
For birth registration:
BR1: If both parents are, alive they should come physically to registration office or if the
father or mother cannot come physically one of them can register the baby [ CITATION Fed18 \l
1033 ].
BR2: If one of the parent is not alive, the parent who is alive should come to registration
office with death certificate of the other parent[ CITATION Fed18 \l 1033 ].
BR3: birth registration is done only for the child who is born alive[ CITATION Fed18 \l 1033 ].
BR4: if the person older than 18 wants to register his birth he can do it himself, without his
parent’s support[ CITATION Fed18 \l 1033 ].
BR5: If the parents are less than 18 years old, they should come with the letter from kebele,
which verifies their residence in that kebele[ CITATION Fed18 \l 1033 ].
BR5: When the guardian come to the registration office, he should present his court adoption
approval paper[ CITATION Fed18 \l 1033 ].
For marriage registration:

BR6: A couple getting married are required to give notification of their intention to marry
to a Registrar at least 1 months before the intended date of the marriage [ CITATION Fed18 \l
1033 ].
BR7: both the man and the woman should be older than 18 years old[ CITATION Fed18 \l
1033 ].
BR8: the couple getting married cannot be blood related [ CITATION Fed18 \l 1033 ].
BR9: all marriages undergo the federal or regional family laws [ CITATION Fed18 \l 1033 ].
BR10: the man and the women should come with 2 witness; parents can’t be
witness[ CITATION Fed18 \l 1033 ].
BR11: If one of them or both have been married, other person before they should come
with a certified copy of divorce, annulment, termination, or death record must be presented at
the time of your appointment[ CITATION Fed18 \l 1033 ].
For divorce registration:
xxiv
BR12: Divorcer’s information copied from court’s document, if divorcers come without
enough document they will be asked the information to fill on the document [ CITATION
Fed18 \l 1033 ].
BR13: If representative does the divorce registration, they should come with evidence of
representation [ CITATION Fed18 \l 1033 ].
For death registration:

BR14: the person who is registering the death of the person should come with kebele
identification card [ CITATION Fed18 \l 1033 ].
BR15: If the registering person is a police officer, he should come with the police badge
(ID)[ CITATION Fed18 \l 1033 ].
For death registration:

BR16: If there is departed person’s ID, passport or visa it should be presented in time of
registration [ CITATION Fed18 \l 1033 ].
BR17: The person who is registering the event should come with valid resident
identification card [ CITATION Fed18 \l 1033 ].
BR18: If dead person is foreigner, death certificate from health center must be
presented [ CITATION Fed18 \l 1033 ].
xxv
CHAPTER THREE
3. PROPOSED SYSTEM
The existing system has its own problem and drawbacks. Therefore, that, the project team
tries to develop a system, which is better than the existing system in terms of time and cost
efficiency. The team try to make the existing system that improve system performance. The
proposed system is capable of provides high security of data, capability of organizing all
information in a single client-server system, easy way of recording and accessing items
information by its well organized user-friendly interface. Generally, the proposed system will
improve the performance of the existing system and reduce this problems, time wastage,
bring data security, data inconsistency, Poor quality service delivery, and reduces wastage of
paper.
3.1 Functional Requirements

The system should allow the administer to:
 Login to the system.
 Manage users account (create, view, activate, deactivate, update and assign roles).
 Post news
The system should allow the Kebele Registrar to:

 Login to the system
 Register vital events
 Update events
 Print certificates
The system should allow the wereda Registrar to:
 Categorize data
The system should allow the wereda Registrar to:
 Generate Report
xxvi
3.2 Non-functional Requirements
3.2.1 User Interface and Human Factors
The user interface of our system should be simple the user understand easily, clear and
provide s a clear understanding of what is happening behind the scenes or provide
visibility to the functioning system. The system will have graphical user interface which
suitable for any kind of user by using easily used buttons and safe web colors with more
attractive to stay on the website and reduce the training cost as well as predictable what
comes next after press the system. The system shall be design according to standards and
the system shall replace existing system and to be consistent.
3.2.2 Hardware Consideration

The system should run in any desktop and personal computer with any flat form .Because we
will use PHP server side scripting language to implement the system that support platform
independent. And needs server to start the system and contain database.
The hardware that required developing the system is the following: -

Table 3-3-1 Requirement specification
Number ITEM Specification
1 CPU 32-bit or 64-bit Core i3(TM) 1.8 GHz
2 RAM Minimum of 2GB
3 HARD DISK Minimum 22GB
4 Flash Disk Minimum of 2GB
5 Color printer ----
3.2.3 Security Issues

In order to make the system secure from an authorized access and modification, the system
uses a login account to differentiate among the different users of the system on the
organization side. This enables the system to verify who has logged in using the correct
logging account provided and display the right form associated with that user. The
security service provided by the system will maintain the security, confidentiality and
integrity of the system. Users will have their own authentication based on user name and
password. Through which they could gain access to the system and using md5 encryption
xxvii
algorithm encryption that changes the plain text to cipher text to prevent data theft and secure
sensitive information in the system.
3.2.4 Performance Consideration

1. Response Time- Upon request for user inquiry the system under normal condition should
display results as quickly as possible.
2. Processing Time- Since the system is developing with efficient programming language and
database upon request for user’s activities the system under normal condition should process
the request as quickly as possible by using multi-tier architectures.
3. Concurrent-processing: the system can support multiple users at a time.
3.2.5 Error Handling and Validation

The system will check user inputs to the system to handle error. It handles and show error by
showing the message “invalid input” when the user enters invalid input. We handle these
errors in client side by using java script validation.
In addition, the system shall handle an attempt to login with incorrect username and
password and display error message.
3.2.6 Quality Issues

Reliability: - The new system under normal condition should keep service without any fault
within 24 hours.
Availability: the new system is available at any time in the customer service.
Usability
 User operability: -The system will offer simple navigation any user so, can
operate function.
3.2.7 Backup and Recovery
To make our project safer from different risks and attacks we use backup for our project files
using External Hard Disk and Flash Disk, incase suddenly the computer that contain the file
is damaged we can easily recover the data.
3.2.8 Physical Environment

The physical environment can affect the proposed system we are going to develop when a
natural disaster occurs. On the other hand, external conditions such as weather condition will
not have any effect on the performance of the system. To protect the system from attacks like
xxviii
viruses and worms the team members develop the backup (recovery) system to protect the
data when the system damage.
3.2.9 Resource Issues
The resource issues that consumed by our system are-
 Back-up: It should be under taken on a daily basis.The system administrator will be

responsible for making the backups
 System installation: The project team will be responsible for the installation of system
 System administrator: The system administrator will be responsible for handling the
system maintenance.
3.2.10 Documentation
The system will provide two types of system documentation. These are internal and external
documentation. System documentation addresses programmers, system developers, owners,
and users. Programmers include those who are currently working on the project as well as
those who give support and maintain the system including the system administrator.
 Internal Documentation: This contains program source code.

 External Documentation: This also contains, use case models, the class and
interaction diagrams (activity, sequence, and state diagrams).
xxix
Chapter Four
4. SYSTEM ANALYSIS
4.1 System Model
This section consists of the modeling of the proposed system using object-oriented
methodologies such as unified modeling language (UML). Here represents the proposed
system by using different system models such as use case models, object models, dynamic
models, that describe the problem to be solved and as the system models represented by
graphically, they are more understandable than more detailed natural language description of
the system requirement[ CITATION Wor19 \l 1033 ].
4.1.1 Use Case Model

Actor Specification
In our system we have the following actors.
o Kebele Registrar
o Wereda Registrar
o Zone Registrar
o Health officer
o Government offices
o Administrator
xxx
4.1.1.1 Use Case Diagram
Figure 4--0-6 Use Case Diagram
4.1.1.2 Use Case Description
Table 4-2 Login Use case Description
Use case name Login
xxxi
Use case identifier UCID - 01
Actor(s) Kebele Registrar, Wereda Registrar, Zone Registrar, Health
officer, Government office, administrator.
Description Allows user to access the system and interact with the
system.
Precondition The users must have valid username and password.
Basic Course of Action Actor actions System Responses
1. user initiates the 2. The system shows the
system on home login interface for the user.
UCID - 01
page.
4. The system validates user
3. user enter username name and password.
and password.
5. The system display user
home page.
The Use case end.

Alternative Course of Action Step4.1: The system displays error message.
Step4.2: The system returns to step2.
Post condition The user accesses the system.
Table 4-3 Manage Account use case description

UCID - 02
Use case name Manage account

Actor(s) administrator
Description Allows administrator to create account for valid users to access the
system, update and delete accounts of the users.
Precondition The administrator must login to the system.
xxxii
Basic Course of Actor actions System Responses
Action 1 administrator enter username 2 The system validates
and password. user name and
4 administrator select manage password.
account:
3. The system display
i. Create account
administrator page.
ii. Update account
iii. Delete account 5 The system displays Create
account page.
4.1 If the administrator selects
Create account go to Step5. 7 The System checks added
user information.
6 administrator enter user account
information. 8 The System add user account
information to the database and
4.2 If the administrator selects
go to Step4.
Update account then go to Step9.
9 The system displays Update
account page.
information to be updated.
11 The System checks updated
4.3 If the admin selects Delete
account information and go to
account go to Step12.
Step4.
12 The system displays Delete
information to be Deleted.
account page.
4.4 If the administrator selects View
14 The System checks deleted
account go to Step15.
account information and go to
Step4.
15 Display user accounts

information.
xxxiii
The Use case end.
Alternative Course of Step2.1: If the user name and password is incorrect.
Action
Step2.1.1: The system displays error message and Go to Step1.
If the input is incorrect or empty, then go to step4 select one of the

following operations and fill the required information correctly.
Post condition The administrator successfully creates, update and delete user account.
Table 4-4 Register Event use case description

UCID - 03
Use case name Register Events
Actor(s) Kebele Registrar
Description Allow the Kebele registrar to register new vital events.
Precondition The registrar must have an account with insert privilege.
1 registrar enter username and 2 The system validates user

password. name and password.
4. The registrar click ‘register 3. The system display home

events’ link. page.
6. Chose Event to register from 5. The system displays

death, birth, adoption, marriage or registration page.
divorce.
7 The system displays the
8. Fill the registration form. specified registration form.
9 Click submit button 10 Validate registration form
11 System display computer

saved successfully
xxxiv
Use Case Ends
Action
Step10.1: If there is error on submitted data.
Post condition Successfully register events.
Table 4-5 Report Birth use acse discription

UCID - 04
Use case name Report Birth

Actor(s) Hospital
Description Allow the hospital to report newborn babies to kebele.
Precondition The hospital must have an account with insert privilege.
1 The Hospital enters username and 2 The system validates user
4 The hospital fills the form. 3The system displays report

form.
5 Click submit button
6 Validate report form
7 System display ‘report sent

successfully’ message.
Use Case Ends

Action
xxxv
Step6.1: If there is error on submitted data.
Step6.1.1: The system displays error message and go back to Step4.
Post condition New birth event reported to kebele.
Table 4-6 Update Event use case description

UCID - 05
Use case name Update Events

Actor(s) Kebele Registrar
Description Allow the Kebele registrar to update vital events.
Precondition The registrar must have an account with update privilege.
1 registrar enter username and 2 The system validates user
4. The registrar click on ‘update 3 The system display home

events’ link. page.
6 Enter registration identification 5 The system displays update

number. page.
9 The registrar fill update form. 7 The system searches the

information using registration
10 Click ‘update’ button.
identification number from
the database.
8 Display the registered event

information for update.
11 Validate update form
12 System display computer

updated successfully.
xxxvi
Use Case Ends
Action
Step7.1: If there is no registered event with the specified registration

identification number:
Step7.1.1: The system displays ‘no data found’ message and Go to

Step4.
Step11.1: if the form has error:
Step11.1.1: display ‘there is error in the form’ and go back to step9.

Post condition Successfully update events.
Table 4-7 Post News use case description

UCID - 06
Use case name Post News

Actor(s) administrator
Description Allow the administrator to post News related to Gurage zone vital
events
Precondition The health officer must have an account with insert privilege.
1 The administrator enters username 2 The system validates user
and password. name and password.
4 The administrator writes the news 3 The system displays Text

he wants to deliver. area.
5 Click ‘post’ button 6 the system check if the text

area is not empty.
xxxvii
7 System displays the news
on home page.
Action
Step6.1: If the text area is empty:
Step6.1.1: the system displays error message and go to step4.
Post condition The News posted on home page.
Table 4-8 Categorize Data use case description

UCID - 07
Use case name Categorize Data

Actor(s) Zone Registrar and Wereda Registrar
Description Allow the Zone Registrar and Wereda Registrar to categorize
registered data.
Precondition Both registrars must login to the system.
1 The registrars enters username and 2 The system validates user
3 They click on categorize data link. 4 the system displays lists of

categories to choice from.
5 They click on the one of the lists
from:
 Gender 8 System displays the

 Age categorized data.
 Marital status
 Religion
6 they click on show button
xxxviii
Use Case Ends
Action
Post condition The registrars view categorized data.
Table 4-9 Print Certificate use case description

UCID - 08
Use case name Print Certificate

Actor(s) Kebele Registrar.
Description Allow the Kebele Registrar print out certificates.
Precondition Kebele Registrar must login to the system.
1 The Kebele Registrar enters 2 The system validates user
username and password. name and password.
3 click on print certificate link. 4 the system displays search

area to accept registration ID.
5 registrar enters registration ID of
resident. 7 The system displays the
data registered with the
6 click on search button
entered ID.
8 registrar clicks on print button
Use Case Ends

Action
Step7.1: if there is not registered data with the entered ID:
Step7.1.1: The system display ‘there is no registered data with the

entered ID please try again’ and go back to step5.
xxxix
Post condition The Zone registrar print out Certificate.
4.1.1.3 Use case Scenarios

1. Login scenario.
Scenario Name: - Login.
Participating Actor: - Abeba
Flow of Event: -
Abeba first open the system.
System display the home page that contain the login link.
 Abeba click the login link.
 The system displays the login form.
 Abeba enter username and password then click on login button.
 The system checks the validity of the user name and password.
 The system displays the required page.
2. Manage Account scenario
Scenario Name: - Manage Account.
Participating Actor: - Ayele
Flow of Events: -
 Ayele first opens his page from the system.
 The system displays his page for provided activities for the administrator.
 Ayele selects one of the activities.
 The system display page based on the administrator’s selection.
 Ayele performs his tasks.
3. Print certificate scenario.
When the user of the system wants to print certificate.
Scenario Name: -Print certificate
Participating Actor: - Barakat.
Flow of event: -
 Barakat first open the system.
 The system displays home page.
 Barakat click login link and enter in to his page.
 Barakat select and clicks on the “print certificate” link on the page.
xl
 Then the system displays search area to accept registration ID.
 Barakat enters registration ID.
 The system load the searched registered data.
 Barakat enter ‘print’ button.
 The vital registration certificate printed successfully.
4. Register Event scenario.

When the user of the system wants to Register event.
Scenario Name: - Register Event
Participating Actor: - Iman.
Flow of event: -
 Iman enters user name and password.
 The system display home page.
 Iman click ‘register events’ link.
 The system displays registration page.
 Iman chose Event to register from death, birth, adoption, marriage or divorce.
 The system displays the specified registration form.
 Iman fill the registration form.
5. Categorize Data
Scenario Name: -Categorize Data.

Participating Actor: - Laila
Flow of Event:
 Laila enters user name and password.
 Laila click on ‘categorize data’ link.
 The system display list of categories.
 Laila choice one from the list.
 The system displays categorized data.
6. Print Certificate
Scenario Name: Print Certificate.
Participating Actor: - Dilala
xli
Flow of Event: -
 Dilala enters user name and password.
 Dilala click on ‘print certificate’ link.
 The system displays search area to accept registration ID.
 Dilala enters Registration ID.
 The system displays the data registered with the entered ID.
 Dilala click on ‘print’ button.
 The certificate printed successfully.
7. Update Events
Scenario Name: -Categorize Data.
Participating Actor: - Lemi
Flow of Event:
 Lemi enter username and password.
 The system display home page.
 Lemi click on ‘update events’ link.
 Lemi enter registration identification number.
 The system display the registered event information for update.
 Lemi enters ‘update’ button.
 The registered data successfully updated.
xlii
4.2 Object Model
4.2.1 Class Diagram
Figure 4-0-7 Class Diagram

4.2.2 Data Dictionary
Table 4-9 Account Table data dictionary
Field name Data type Constraint Description

userName Varchar(30) Primary key It stores user name
role Varchar(30) Not null It stores the role of the account.
firstName Varchar(30) Not null It store first name
lastName Varchar(30) Not null It store last name
password Varchar(70) Not null It stores password
email Varchar(70) Not null It store email address
phoneNumbe Varchar(14) Not null It stores phone number
r
xliii
Table 4-10 Admin Table data dictionary

Admin_ID Varchar (30) Primary key It stores system admin id
userName Varchar(30) Foreign key It stores user name
Table 4-11 Kebele Registrar data dictionary

kRID Varchar (30) Primary key It stores kebele registrar ID
userName Varchar (30) Foreign key It stores user name
weredaID Varchar (30) Foreign key It stores wereda ID
ZoneID Varchar (30) Foreign key It stores zone ID
Table 4-12 Wereda registrar table data dictionary

WRID Varchar(50) Primary key It stores wereda registrar Id.
UserName Varchar (30) Foreign key It stores user name
weredaID Varchar (30) Foreign key It stores wereda ID
ZoneID Varchar (30) Foreign key It stores zone ID
Table 4-13 Event Table data dictionary

registration_ID Primary key Primary key It store registration ID.
firstName Varchar(50) Not null It store first name.
middleName Varchar(50) Not null It store middle name.
lastName Varchar(50) Not null It store last name.
region Varchar(30) Not null It stores region
eventZone Varchar(30) Not null Stores zone of the event.
keble Varchar(30) Not null Stores kebele of the event.
city Varchar(30) null Stores city of the event.
xliv
4.3. Dynamic Model
4.3.1. Sequence Diagram
Figure 4-0-8 Sequence diagram for register event
xlv
Figure 4-0-9 Sequence diagram for update event
xlvi
Figure 4-0-10 Sequence diagram for delete user
xlvii
Figure 4-0-11 Sequence diagram for update event
xlviii
4.3.2. Activity Diagram
Figure 4-0-12 Activity diagram for login
xlix
Figure 4-0-13 Activity diagram for create user
l
Figure 4-0-14 Activity diagram for delete account
li
Figure 4-0-15 Activity diagram for register event
lii
Figure 4-0-16 Activity diagram for report event
liii
Figure 4-0-17 Activity diagram for categorize data
liv
Figure 4-0-18 Activity diagram for print certificate
lv
4.3.3 State Chart Diagram
Figure 4-0-19 State chart diagram for login
lvi
Figure 4-0-20 State chart diagram for register event
lvii
CHAPTER FIVE
5. SYSTEM DESIGN
5.1 Design Goals
The Design goal below represents the quality of Gurage zone vital management system focus
on the following.
Performance:
The system is programmed with PHP and MYSQL that reduce the complexity of the
algorithm such as amount of space that the algorithm needs and running time that replies in a
minimum amount of time.
Dependability:
The Organization expect the system to be highly dependable as non-IT professionals use it.
The system should be robust and fault tolerant. The proposed system should achieve the
following dependability characteristics in order to resist crash and be available and reliable.
 Robustness: Since the system is a web-based system that mainly uses a menu driven
access there would not be an input problem by the user side. However, for the server
side there might be an error during the process of entering a data. In this time the
system will provide an error page and the system will continue without failure or
affection.
 Availability: -as long as there is an internet connection the system will be available
24/7.
 Security: the system should be secured, i.e., not allow unauthorized users to access
the database system.
 Reliability: the information provided by the system is as reliable as it is presented on
the web page interface, and this is maintained by the persistent database.
Maintenance:
In time of failure or need modification the system needs to be maintained. To be
maintainable the system should meet the following maintenance criteria.
lviii
 Extensibility: - If it is needed to add new functionality to the system, this must be
achieved by only making a separate page and integrate this page with the existing
system.
 Modifiability: - If in the system, some functionality requires to be modified, this
modification must be done specifically to that function or page without affecting the
overall system organization.
End User Criteria
The system should have simple and understandable graphical user Interface such as forms
and buttons, which have descriptive names. It should give reliable response for each user
request at least before the session expires.
Priorities of Design Goal
 Developing reusable components that are easy to modify and maintain by paying
attention to low coupling and high cohesion principle. We strongly believe that, using
well-known design patterns can help us to attain this goal.
 Providing easy graphical user interface to increase user friendliness.
 Developing system that can handle errors that is invalid inputs and give meaningful
feedback to users.
5.2 Proposed System Architecture

The project team selected three tier system architecture because Three-tier architecture
allows any one of the three tiers to be upgraded or replaced independently. The reason why
three-tier architecture is selected for this project is the following:
 It gives us the ability to update the technology stack of one tier, without affecting
other areas of the application.
 It allows for different development teams to each work on their own areas of
expertise. Today’s developers are more likely to have deep competency in one area,
like coding the front end of an application, instead of working on the full stack.
 Scalability: - You are able to scale the application in and out. A separate backend
tier, for example, allows you to deploy to a variety of databases instead of being
locked into one particular technology. It also allows you to scale up by adding
multiple web servers.
 Reliability: - It adds reliability and more independence of the underlying servers or
services.
lix
 Maintainability: - It provides an ease of maintenance of the code base, managing
presentation code and business logic separately, so that a change to business logic, for
example, does not affect the presentation layer.
Figure 5-0-21 Proposed system architecture

5.2.1 Subsystem Decomposition and Description
User management subsystem: in this subsystem managing of information regard to account
and perform:
 Create account
 Deactivate account
 Activate account
 Update account
Notification management subsystem: In this subsystem News are posted and deleted if
needed.
Event registration management subsystem: In this subsystem all vital events are registered
which are:
 Birth
 Death
 Marriage
 Divorce
 Adoption
Data Manipulation subsystem: In this sub system statistic and non- statistic data is
generated and also registration certificates are generated in hard copy.
lx
Figure 5-0-22 Subsystem Decomposition
lxi
5.2.2 Hardware/Software Mapping
Figure 5-0-23 Hardware/Software Mapping
lxii
5.2.3 Detailed Class Diagram
Figure 5-0-24 Detailed Class Diagram

5.2.4 Persistent Data Management
For persistent data management, we use MYSQL, a popular open source RDBMS. This
database keeps track of detailed information of the school members. We have identified the
following relationships between the system classes.
lxiii
Figure 5-0-25 Mapping table for zone class
lxiv
Figure 5-0-26 Mapping table for account class
Figure 5-0-27 Mapping table for admin class
lxv
Figure 5-0-28 Mapping table for event class
Figure 5-0-29 Mapping table for kebele registrar class
lxvi
Figure 5-0-30 Mapping table for kebele class
Figure 5-0-31 Mapping table for News class
Figure 5-0-32 Mapping table for wereda registrar class
lxvii
Figure 5-0-33 Mapping table for wereda class
Figure 5-0-34 Mapping table for zone registrar class
lxviii
Figure 5-0-35 Persistence data management
5.2.5 Access Control and Security
The proposed system follows multi user system. In multi user system, different actors have
access to different functionality and data. Then it must be having: -
 Confidentiality: Only authorized person can see the information. Private data is kept
private; personal privacy is respected.
 Integrity: There are limits on who can change the data in this system.
 Availability: The system is available at all times to authorized users.
Table 5-14 Access Control
Operation
Actors Manage Post Report Print Register Update Generate Categorize Req
Account News new certificat Event Event report data uest
Birth e Rep
ort
Admin  
Kebele   
lxix
Registrar
Wereda  
Registrar
Zone  
Registrar
Health 
officer
Governmen 
t office
5.3 Packages
Figure 5-0-36 package
5.4 Algorithm Design

I Algorithm Design for Login
1. Get user name and password

2. If user name is equal to the entered Username & the password is equal to the entered
Password
lxx
3. Then login successful
4. Else login failed
5. End If.
II Algorithm to Create user account
1. Click on create account link Form is displayed

2. Fill information for the user
3. Click on create button
4. IF (valid) Display successful message.
5. EISE Display invalid input message
6. END IF
5.6 User Interface Design
Figure 5-0-37 Registrar page user interface
lxxi
Figure 5-0-38 Birth registration page user interface
lxxii
CHAPTER - SIX
6. IMPLEMENTATION AND TESTING
6.1 Implementation of the Database

The system uses relational database for storing information. It uses relation database for
storing required information of system users like Kebele, woreda, and zone registrars and
registered vital events. and document database for storing image of different kinds. We have
chosen mysql database because mysql database is fastest database with advanced
performance and more capabilities to simplify operation of data base in a short time.
Sample code
-- Database: `vital`--
------------------------------------------------------
CREATE TABLE àccount` (
ìd` int(11) NOT NULL,
`main_id` int(11) NOT NULL,
ùsername` varchar(25) NOT NULL,
`fname` varchar(25) NOT NULL,
`mname` varchar(25) NOT NULL,
`lname` varchar(25) NOT NULL,
`password` varchar(1000) NOT NULL,
`role` int(11) NOT NULL,
èmail` varchar(50) NOT NULL,
`zoneID` int(11) NOT NULL,
`woredaID` int(11) NOT NULL,
`KebeleID` int(11) NOT NULL,
`gender` varchar(10) NOT NULL,
`login_attempts` int(11) NOT NULL,
`status` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- Table structure for table `marriage`--
lxxiii
CREATE TABLE `marriage` (
ìd` int(11) NOT NULL,
`rid` int(11) NOT NULL,
`hfname` varchar(100) NOT NULL,
`dom` varchar(25) NOT NULL,
`hpicture` varchar(100) NOT NULL,
`hreligion` varchar(30) NOT NULL,
`hdob` varchar(30) NOT NULL,
`hstatus` varchar(30) NOT NULL,
`haddress` varchar(1000) NOT NULL,
`hzip` varchar(20) NOT NULL,
`hidn` varchar(20) NOT NULL,
`wfname` varchar(100) NOT NULL,
`wpic` varchar(1000) NOT NULL,
`wreligion` varchar(100) NOT NULL,
`wdob` varchar(20) NOT NULL,
`wstatus` varchar(30) NOT NULL,
`waddress` varchar(1000) NOT NULL,
`wzip` varchar(100) NOT NULL,
`widn` varchar(100) NOT NULL,
`wfname1` varchar(100) NOT NULL,
`waddress1` varchar(1000) NOT NULL,
ùser` varchar(200) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
6.2 Implementation of Class Diagram
In class implementation the following activities we have perform:
lxxiv
 We Define attributes with the appropriate data type and access visibilities (private,
protected, public).
 We define all methods with appropriate return type, parameters and the corresponding
data types and access visibility.
6.3 Configuration of Application Server
We use XAMPP application server because the installation process is very simple and fast. Once
XAMPP is installed on your local computer it acts as a local server or localhost. You can test the websites
before uploading them to the remote web server. This XAMPP server software gives you a suitable
environment for testing MYSQL, PHP, Apache, and Perl applications on a local computer.
6.4 Configuration of Application Security
We validate our inputs by using client and server side validations. Validation of the inputs on
client side allow the user to fill correct information in our system we validate all the input to
enter the correct format. Example the name must be in the form of string not include other
like spatial character number our system refuse this inputs. In addition, age must be in the
form of number. Let see the login page validation process.
lxxv
Figure 6-1 Login page user Interface
<script type="text/javascript">
function loginUser(){
var username = document.getElementById("un").value;
var password = document.getElementById("pd").value;
$.ajax({
type:'POST',
url:'includes/login_signup_codes.php',
data:{'req':'login_code','un':username,'pd':password},
beforeSend:function(){
lxxvi
$('.login_signup_btn1').hide();
$('#login_wait').html("Loading...");
},
success:function(data){
$('#login_wait').html(data);
if (data == "Welcome...") {
$('#login_wait').html("<p class='alertGreen'>Welcome...</p>");
setTimeout(' window.location.href = "home"; ',2000);
else{
$('.login_signup_btn1').show();
},
error:function(err){
alert(err);
});
$('#signinFunCode').click(function(){
loginUser();
});
$(".login_signup_textfield").keypress( function (e) {
if (e.keyCode == 13) {
lxxvii
loginUser();
});
</script>
This the above code validate users input on the client side before it passed to application
server by examining the length of the input and also by checking each input boxes are not
empty. After client server validation is done server side validation proceeds.
if ($user == null && $pass == null) {
echo "<p class = 'alertRed'>Enter Username to Sign In</p>";
elseif ($user == null) {
echo "<p class = 'alertRed'>Enter Username to Sign In</p>";
elseif ($pass == null) {
echo "<p class = 'alertRed'>Enter Password to Sign In</p>";
else{
$selectuser = "SELECT * FROM account WHERE (username = '$user' OR email =

'$em') AND password = '$pass'";
$query = mysqli_query($conn, $selectuser);
$checkuser = mysqli_num_rows($query);
lxxviii
while ($row = mysqli_fetch_assoc($query)) {
$fetchrole = $row['role'];
if ($fetchrole == 'Admin') {
if (isset($_COOKIE['linAtt']) AND
$_COOKIE['linAtt'] == $user) {
echo "<p class = 'alertRed'>Cannot sign in attempts</p>";
if ($checkuser == 1) {
$_SESSION['Username'] = $user;
echo "<script>window.open('../Home.php', '_self')</script>";
else{
echo "<p class='alertRed'> Username and

password incorrect!</p>";
elseif ($fetchrole == 'Kebele') {
lxxix
echo "<script>window.open('../KebeleHome.php', '_self')</script>";
else{

elseif ($fetchrole == 'Woreda') {
echo "<script>window.open('../WoredaHome.php',
'_self')</script>";
else{

elseif ($fetchrole == 'Zone') {
lxxx
echo "<script>window.open('../ZoneHome.php', '_self')</script>";
else{

else{
echo "<p class='alertRed'> Something is happened, try

it letter!</p>";
6.5Implementation of User Interface
The user interface of this system does not support command languages but menus and
graphical user interface. We use user model of user interface to represent different feature of
end users and roles playing in the system.
lxxxi
Regarding to the user interface, we have applied the following.
 The user interface that we develop is user adjusted design. It means we have to make
our user interface be attractive to users by developing compatible, well-matched and
friendly user interface
 The user interface that we develop is consistent and dependable
 the user interface is consistent and stable which does not create any confusion for
users easily understandable with clear and steady navigation.
6.6 Testing
6.6.1 Testing Tools and Environment
XAMP, chrome, Sublim-text3 are used for every module development. By tracing and
correcting bugs and errors our system’s stability is increased. Since our codes are written in
latest development environment it is easy to keep tracking any mistakes especially in unit
testing phase.
6.6.2 Unit Testing
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 most
significantly PHP-focused package for Sublime Text is called sublime PHP companion.
sublime PHP companion has auto completion, syntax checking and method integration
method that makes it favourable for unit testing.
6.6.3 Integration Testing
In this level of testing, we have examined how the different procedures work together to
achieve the goal of the subsystem. The type of integration testing that we have follow bottom
up. So, we integrate each component from single function to the main function incrementally.
Sample Tests
1. Check the interaction between individual functionality which performs the specific
tasks.
2. Evaluate the functionality of the subsystem after combination all individual
functionality.
lxxxii
3. Identify the Independence of each subsystem with another subsystem.
The goals of system testing are to detect faults that can only be exposed by testing the entire
integrated system or some major part of it. Generally, under this testing is mainly concerned
with areas such as performance, security, validation, load/stress, and configuration sensitivity
of face recognition. But we will more focus only on function validation and performance.
Sample Tests
1. Evaluate the functionality of the subsystem after a combination of individual

subsystem whether it works correctly or not.
2. Check the coherence and coupling of each subsystem.
3. Check the overall functionality of face recognition that achieves the user’s
requirement.
6.6.4 Acceptance Testing
Will be carried out by the user to ensure that the delivered services meet the requirement
and works as the users expected. It includes
Alpha testing – conducted by users to ensure they accept the system with sample data.
Beta testing – conducted by users with real data, not test data.
lxxxiii
Chapter Seven
7. CONCLUSION AND RECOMMENDATION
7.1 Conclusion
This project which has two phases; the first phase concerned with the analysis phase of
the life cycle, the design phase and the next phase is about implementation. As the end of
the first phase, we need to review that we have covered in accordance with what we have
planned at the beginning. We began our work by identifying the significance of
automated systems and the overall techniques to be used in the development process.
This involved defining the system development methodology, identifying resource and
cost requirements, and setting the deliverable and scheduled for the project.
The analysis helps the team to well understand the major functional areas and processes
of the system. Through this method we evaluate the existing system that is manual
system weakness. After that, we performed requirements elicitation to discover user and
system requirements. This phase consisted of drawing the functional as well as non-
functional requirements of the system. Then we have undertaken a major phase in system
development process: object oriented Analysis. Here, we tried to model the new system
we proposed using UML diagrams: Use case, sequence, and class diagrams Also, we
designed the new system user interface prototyping and implementation.
During the progress of the project we become with understanding that information is very
important in every fields but it is better with Vital events for government and health. The
project team understand that and tried to solve some problems that face with vital registration
area.
7.2 Recommendation
During development of this system the team members has faced different challenges due
to lack of project development resources especially time. Nevertheless by the cooperation
of all the group members is now able to reach to the final result. All the group members
strongly fight these challenges and take the turn to the front.
lxxxiv
Bibliography
[1] Wikipedia, "Vital statistics (government records)," 10 December 2019. [Online]. Available:
https://en.wikipedia.org/.
[2] U. Ethiopia, "First ever civil registration and vital statistics day observed in Ethiopia," Ethiopia,
UNICEF, Adis Ababa, 2016.
[3] F. V. r. agency, የወሳኝ ኩነቶች ምንነት እና ጠቀሚታ, Addis Abeba: Selam And Berhan printing, 2018.
[4] Z. M. Worku Muluye(MSC), Final WKU Reviewed Industrial Project, 2019.
[5] n. a. P. o. E. the nations, Constitution of Ethiopia, Ethiopian Government, 1994.
[6] A. P. Mathur, Foundations of Software Testing: Fundamental Algorithms and Techniques, india:
Pearson India, 2007.
[7] R. O. O. V. Morten korsaa, "Iterative Software Development," February 2002.
lxxxv

Vital Managment System All Chapters

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

Vital Managment System All Chapters

Uploaded by

Copyright:

Available Formats

Wolkite University

College of Computing and Informatics

Title: Vital Management System for Gurage Zone

Group Members Id_No

Wolkite University, Wolkite, Ethiopia

Department Head Name Signature Date

1.1 Background of the Organization

Ethiopians Vital events registration organizational structure look like this

Regional Vital Events Federal Vital Events

Board of Management Board of Management

1.3 Objective of the Project

1.3.2 Specific Objective

 To study the existing system.

1.4.2 Operational Feasibility

 The new system fits with the existing operational system.

 Satisfy the user need or requirement.

1.4.3 Economic Feasibility

After the development of this system:

1.5 Scope and Limitation of the Project

1.5.2 Limitation of the Project

1.6 Significance of the Project

 Reduce time and resource required to transfer information between different

For end users: -

 To ask for Keble id card

1.8 Methodology of the Project

Primary data source:

Secondary source data

1.8.2 System Analysis and Design

1.8.4 Development Tools and Technologies

1.8.4.2 Backend Technologies

1.9 Document Organization

2. DESCRIPTION OF THE EXISTING SYSTEM

2.2 Users of Existing System

2.3 Major Functions of the Existing System

Figure 2-2-2 Divorce registration form

2.5 Drawbacks of the Existing System

For marriage registration:

For divorce registration:

For death registration:

For death registration:

3.1 Functional Requirements

The system should allow the Kebele Registrar to:

3.2.2 Hardware Consideration

The hardware that required developing the system is the following: -

1 CPU 32-bit or 64-bit Core i3(TM) 1.8 GHz

2 RAM Minimum of 2GB

3 HARD DISK Minimum 22GB

4 Flash Disk Minimum of 2GB

5 Color printer ----

3.2.3 Security Issues

3.2.4 Performance Consideration

3. Concurrent-processing: the system can support multiple users at a time.

3.2.5 Error Handling and Validation

3.2.6 Quality Issues

3.2.8 Physical Environment

 Back-up: It should be under taken on a daily basis.The system administrator will be

 Internal Documentation: This contains program source code.

4.1.1 Use Case Model

Figure 4--0-6 Use Case Diagram

4.1.1.2 Use Case Description

Table 4-2 Login Use case Description

Use case name Login

The Use case end.

Step4.2: The system returns to step2.