WERABE UNIVERSITY

INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION SYSTEM.
PROJECT TITLE: ONLINE CENSUS MANAGEMENT SYSTEM FOR

WERABE TOWN

SUBMITED TO DEPARTMENT OF INFORMATION SYSTEM IN PARTIAL FULFILMENT

OF THE REQUIRMENT FOR THE DEGREE OF BACHLER OF SCIENCE IN
INFORMATION SYSTEM

BY

Group Member

No Name of Student Id No

1. Dawit Belete NSR/0304/13

2. Habtamu Aweke NSR/0522/13
3. Habtamu Berihun NSR/0527/13

Advisor Name: Mr. Keyre K

WERABE, ETHIOPIA

December 5, 2016
This to confirm that the project report entitled “online census management system for Werabe
town Submitted to Werabe University, Institute of Technology department of Information
System in Partial Fulfilment of the requirement for the award of degree of bachelor of science in
information system is an original work carried out by Dawit Belete, Habtamu Aweke, Habtamu
Berihun, under my guidance. The matter embodied in this project is reliable and is genuine work
done by the student and has not been submitted whether to this University or to any other
University/Institute for the fulfilment of the requirement of any study.

Student Team Approval Form

Student Name Student Signature

…………………………… ………………….

…………………………… ………………….

……………………………. ………………….

Advisor and department hard Approval Form

Advisor Name Advisor Signature

……………………………. ………………….

Department Hard Name Department Hard Signature

……………………………. …………………..

Examiner Approval Form

Examiner Name Examiner Signature

……………………………. ……………………

……………………………. ……………………

……………………………. ……………………
 Acknowledgment

First of all we would like to praise God, and we would like to thank our department Information
system to give us necessary courses and give us this final project to know more about all courses
we have learned and we would like to thank all of our group members who contribute their full
effort & cooperation and also we would like to thank our classmate for your guidance for starting
the project.
Secondly, highest thanks to our advisor Mr. Keyre k to starting the project for his guidance.
Finally, thanks to peoples who have directly or indirectly support to started this project.

i
Contents
Acknowledgment..............................................................................................................................i
List of table......................................................................................................................................v
List of Figures.................................................................................................................................vi
List of acronyms............................................................................................................................vii
ABSTRACT.................................................................................................................................viii
1 Chapter One: Introduction.......................................................................................................1
1.1 Introduction.......................................................................................................................1
1.2 Background of the project.................................................................................................1
1.2.1 Vision of Werabe Town Statistics Agency................................................................2
1.2.2 Mission of Werabe Town Statistics Agency.............................................................2
1.3 Statement of the problem..................................................................................................2
1.4 Objective the Project.........................................................................................................2
1.4.1 General Objective......................................................................................................2
1.4.2 Specific Objective......................................................................................................3
1.5 Feasibility study of the new system..................................................................................3
1.5.1 Technical feasibility...................................................................................................3
1.5.2 Operational feasibility...............................................................................................4
1.5.3 Economic Feasibility.................................................................................................4
1.5.4 Political feasibility.....................................................................................................4
1.5.5 Schedule feasibility....................................................................................................4
1.6 Scope and Limitation of the Project..................................................................................5
1.6.1 Scope of the Project...................................................................................................5
1.6.2 Limitation of the Project............................................................................................5
1.7 Cost of the project.............................................................................................................5
1.7.1 Recurrent cost............................................................................................................6
1.8 Significance of the project................................................................................................6
1.9 Benefit and beneficiary of the system...............................................................................6
1.9.1 Benefit........................................................................................................................6
1.9.2 Beneficiary.................................................................................................................7
1.10 Methodology for the project and tool............................................................................7

ii
 1.10.1 Data gathering methodology......................................................................................7
1.10.2 System analysis and design methodology.................................................................8
1.10.3 Tool selection.............................................................................................................8
1.11 Testing technique..........................................................................................................8
1.11.1 Black box testing.......................................................................................................9
1.11.2 White box testing.......................................................................................................9
1.12 Risks..............................................................................................................................9
1.13 Team composition.........................................................................................................9
2 Chapter Two: Description of Existing System......................................................................11
2.1 Introduction of Existing system......................................................................................11
2.2 Players in the existing system.........................................................................................11
2.2.1 Enumerator:.............................................................................................................11
2.2.2 Supervisor:...............................................................................................................11
2.3 Major functions...............................................................................................................11
2.4 Business Rule of the Existing system.............................................................................12
2.5 Forms used in the existing system..................................................................................12
2.6 Bottlenecks of the existing system..................................................................................13
2.6.1 Performance:............................................................................................................13
2.6.2 Input:........................................................................................................................13
2.6.3 Security:...................................................................................................................13
2.6.4 Efficiency:................................................................................................................13
3 Chapter Three: Proposed System...........................................................................................14
3.1 Introduction.....................................................................................................................14
3.2 Proposed System Overview............................................................................................14
3.3 Requirements of the Proposed System............................................................................14
3.3.1 Functional requirements..........................................................................................14
3.3.2 Non- functional requirements..................................................................................15
4 Chapter Four: System analysis..............................................................................................16
4.1 System models................................................................................................................16
4.1.1 Scenarios..................................................................................................................16
4.1.2 Use case model........................................................................................................20

iii
 4.1.3 Use case Description of the proposed system..........................................................20
4.1.4 Object model............................................................................................................31
4.2 Dynamic Model...............................................................................................................35
4.2.1 Sequence diagram....................................................................................................35
4.2.2 Activity diagram......................................................................................................39
4.2.3 State chart diagram..................................................................................................43
5 Chapter five: system design...................................................................................................44
5.1 Introduction.....................................................................................................................44
5.2 System Design Overview................................................................................................44
5.3 Design Goal.....................................................................................................................44
5.4 Design Trade-offs...........................................................................................................45
5.5 Architecture of the System..............................................................................................45
5.5.1 Current software architecture..................................................................................45
5.5.2 Proposed software architecture................................................................................46

iv
 List of table

Table 1: schedule feasibility………………………………………………………….….5

Table 2: recurrent cost …………………………………………………………….…..6

Table 3: Team Composition……………………….……………………………………10

v
 List of Figures

Figure 1: Area identification form………………………………………………………………12

Figure 2: Type of residence and housing identification form……………………………………13

Figure 3: use case diagram……………………………………………………………………

vi
 List of acronyms

BR: Business rule

DB: Database

CSS: cascade style sheet

OOD: Object oriented design

MySQLI: Structural query language

HTML: Hypertext markup language

vii
 ABSTRACT

The main aim of developing the census management system is to allow easier coordination of
activities from the beginning of the census process up to the end of the process. This is done by
automating the whole process, allowing statistical agency of Werabe Town to monitor the
population statistics online. It will also help to facilitate the management of population via the
web for enhanced management and efficiency. This project mainly concentrates on improving
the efficiency of census data collection. The conventional census data collection system involves
an authorized census collector (enumerator), who collects the census data manually with paper
and pen. This method is a lot of time consuming and tedious .So, we think to develop the finest
solution for automating the census system. The system is going to be developed so as to help the
user to enumerate the population online, validate census recording process, manipulate the
census data and represent it statistically, calculate critical rates and indicators from the census
data etc. To perform the aforementioned tasks the system will have our major modules namely:
census manipulation & statistics module, registration module, account & privilege management
module, reporting module, and collaborative module

viii
 1 Chapter One: Introduction

1.1 Introduction

The United Nations defines a population census as the total process of collecting,
compiling, and publishing demographic, economic, and social data pertaining to a specific time
to all persons in a country or delimited part of a country.

Census is of great interest to Ethiopia government a population and housing census as a case
study of great relevance to the economic, political and socio-cultural planning of a country.
Reliable and detailed data on the size, structure, distribution and socio-economic and
demographic characteristics of a country population is required for planning. A population
census of course, is the major source of census data.

1.2 Background of the project

Ethiopia, in its modern history, conducted some three national censuses. The first census was
conducted back in 1984, during the military regime. The total number of population was said to
be around 34.5 million people. Ethiopia has conducted the second and third population and
census in 1994 and 2007 basically the current constitution dictates census to be conducted every
10 years. Back in 1994 and 2007, the total population of the country was 53.5 million and 73.9
million, respectively. The werabe town census was established 1984. It was located in silte zone,
in central Ethiopia regional state which is located 172 km southwest of Addis Ababa, and it is 58
km away from Hosaena which is the capital city of central Ethiopia regional state. In 2015 total
population number of werabe town was 96,000, which was 47,198 male and 48,802 female. The
system currently uses manual system such as paper for the management system which leads the
system to be inefficient. Some of the problems are material records issue, searching and getting
of different data it takes long time; loss of document, security problem and retrieval problem to
be occurred. Our project is used to automate the current population census and housing unit for
Werabe Town.

1
1.2.1 Vision of Werabe Town Statistics Agency

The vision of this project is to make Werabe Town statics agency a model organization with in
a country by providing sufficient statistical information.

1.2.2 Mission of Werabe Town Statistics Agency

Our mission is to help Werabe Town statics agency to provide well organized and qualified
official statistical information for development policy, plans, researches and evaluation.

1.3 Statement of the problem

In the current system collecting data takes a long time, because enumerator has to manually fill
in the census form then again sort out the data. So we need a system that segregates data and
when data is entered. Another difficulty in this method is the accuracy of data entered. Until now
everything is done on paper. This system has dual work of collecting the data on paper and then
feeding it in computer. This also takes a vast amount of manpower into it. The information is
subjected to change as it is taken as a written work on a paper.

Generally, the current system has the following problems:

 Document Mismanagement: Chances for losing the census data is high.

 Requires More Resources: Consumes more resources and costs such as paper, pen,
transportation cost for paper, and storage place.
 Needs more manpower and cost than the automated system: the existing system
requires more man power than the proposed system to operate.
 Lack of automated statistical manipulations.
 High Data redundancy and erroneous data storing.
 The current system is not efficient, flexible, reliable, available and difficult to get
data.

1.4 Objective the Project

1.4.1 General Objective

The general objective of this project is to develop web-based online census system for Werabe
Town.

2
1.4.2 Specific Objective

To achieve the above mentioned general objective, the project includes the following
specific objective.

 To analyse the advantages and disadvantages of existing census system.

 To examine the negative and positive side of the proposed census system.
 To identify significant services and constraints on solution to needs.
 To create user interface for system users to login in to the system for solving the
security problem.
 To allow online enumeration of people and housing unit.
 To allow the end user to view or access different census data or report online.
 To search and access in a short period of time.
 To control loss of data.
 To minimize the amount of paper work by automating the existing system.
 To allow the system user to view and update records of census data.

1.5 Feasibility study of the new system

The feasibility study is the preliminary study that determines whether a proposed system project
is financially ,technically and operationally viable .The alternative analysis usually include as
part of the feasibility study, identifies viable alternatives for the system design and development.

1.5.1 Technical feasibility

We have enough capability and technical knowledge about:

 PHP to write the code or implementation with XAMPP.
 MySQLI to build the database to store the data.
 Unified Modelling Language (UML) model to do analysing and designing
in good manner. So the system will be technically feasible.

3
1.5.2 Operational feasibility

Our project will have a user friendly interface that can be implemented easily and can perform
many tasks that can be used by users.

1.5.3 Economic Feasibility

In the existing system, many people are involved in the process but in the proposed system,
number of persons involved be reduced drastically.
After this project finished it will reduce the cost of paper, pen, and transportation will be avoided
or we automate the system from manual system so that our project is economically feasible.
Intangible costs:

Intangible cost is a cost that is not seen but its effects are perceived later in future.
Tangible costs:

These are costs consequent from the design of a system that can be considered as money, so that
the costs for machine described below in cost estimation.

1.5.4 Political feasibility

Our project will not conflict with the rule and regulation of Ethiopian constitution and Ethiopian
statistical agency rather it gives advantage to our country.

1.5.5 Schedule feasibility

NO. Task name 2016E.c

Oct /24 Nov Dec Jan 20/2016- Apr

2016- Nov 11/2016- 15/2016-Jan Apr 15/2016 20/2016-May
10 /2016 Nov 10 /2016 15/2008
30/2016
1 Requirement
gathering

2 System
requirement
specification

4
3 System
designing

4 System
implementation

5 Operation
testing

Table 1: schedule feasibility

1.6 Scope and Limitation of the Project

1.6.1 Scope of the Project

The proposed system focused on Werabe Town statistics agency and covers only the population
and housing unit.

1.6.2 Limitation of the Project

The proposed system may have the following limitation.

 Performance degrade due to ICT infrastructure limitation/bandwidth and connectivity

problem
 The proposed system is not accessed by blind people.
 The employee that has not basic skills and knowledge of computer cannot accesses
proposed system.
 The proposed system is implemented only for Werabe Town i.e. it is not
implemented for other region, city, or town
 The proposed system is not mobile based application.

1.7 Cost of the project

Cost of the project is overall cost to develop our proposed web based online census system

5
1.7.1 Recurrent cost

No Activities Cost (in Birr)

1 For paper and pen 340.00

2 For printing and copying 300.00

3 For transport and telephone 500.00

4 For buying devices such as CD, Flash 450.00

Total 1590

Table 2: recurrent cost

1.8 Significance of the project

 The system will solve problem associated with the acquisition, storage, and retrieval
of information on human population with ease.
 A timely retrieval of information is anticipated with efficiency and reliability.
 It will provide security to data that are unauthorized, users will not gain access to
those files and fraud will be minimized in the society which will lead to improvement
in administration processes.

1.9 Benefit and beneficiary of the system

1.9.1 Benefit

These benefits are categorized into two.

1.9.1.1 Tangible:

 Reduce cost of registrations

 can reduce the amount of paperwork involved
 Save registration time
 It avoids data redundancy or Error reduction.
 Provide higher data backup
 Reduce resource requirements or unnecessary wastage of resource.
 Increase system performance
6
1.9.1.2 Intangible:

 To get well organized information in short period of time

 Accurate and faster access to data for timely decisions
 Improved users’ motivation by avoiding paperwork
 Saves enormous time and effort in data entry

1.9.2 Beneficiary

The beneficiary of this system includes:

 Administrator: - unlike the existing system the proposed system enable the admin to
manage the system Policy maker: - can access or get organized data easily for policy
making.
 Supervisor:-benefit from the system by easily supervising the enumerator online by using
browser.
 Journalists and researcher can access or get organized data easily from the system
 Government ministries and Local authorities: - They will get error free census data to
provide infrastructure for the people.
 Private and public companies:- They can access or get organized data for different
purpose

1.10 Methodology for the project and tool

1.10.1 Data gathering methodology

The following data gathering methodology are to develop the proposed system;

 Interviewing - We will interview the Coordinator. This will enable us to know the
requirements and if any training will be required before the system is implemented.
 Observation - This will help us to see the problems the enumerator, supervisors are
facing. This will be done by attending one census process.

 Questionnaires:-It contains fixed-response questions about various features of an

organization. It can be analysed quickly. This also another data gathering methods that

7
 are used for collecting information from the stake holder. This can be in terms of written
paper distributed for individuals.

1.10.2 System analysis and design methodology

We will use object oriented design (OOD) methodology in this project to model the
functionality of the system to organize the objects, classes, to identify the relationship between
each objects and classes and the behaviour of the objects. Because object oriented
methodology enable us to reuse, maintain, modify design and code the system and it increases
consistency among analyser, designer and taster.

1.10.3 Tool selection

1.10.3.1 Software requirements:

 Microsoft Office 2013.

 Operating system (Microsoft windows 10).
 PHP, CSS, HTML, JAVASCRIPT (We use PHP language for the system development;
to create user interface and our system (software) will be compatible on all hardware).

 MySQLI server: for designing the database.

 Adobe Photoshop: for editing image.
 Browsers: since our system is web based, it is very necessary requirement.

1.10.3.2 Hardware requirements:

 Desk top computer

 Network cable: since our system is web based it is very necessary requirement. It is also
help to as to extract relevant information about our project from the internet.
 Printer to print our documentation.
 32 GB flash drive used to make backup of important information in case of any damage.

1.11 Testing technique

We will use two different methods of testing technique.

8
1.11.1 Black box testing

The technique of testing without having any knowledge of the interior workings of the
application is Black Box testing. The tester is oblivious of to the system architecture and does
not have access to the source code. Typically, when performing a black box test, a tester will
interact with the system's user interface by providing inputs and examining outputs without
knowing how and where the inputs are worked upon.

1.11.2 White box testing

White box testing is the detailed investigation of internal logic and structure of the code. In
order to perform white box testing on an application, the tester needs to possess knowledge of
the internal working of the code. The tester needs to have a look inside the source code and find
out which unit/chunk of the code is behaving inappropriately

1.12 Risks

The following are risks that one may encounter while doing the project and the counter measures
that one can take in case of anything:

 Inadequate information for the available papers in the library.

Remedy: we will visit various websites which are related to our project so as to get more
detailed information.
 Power failure:
Remedy: with Generators and or UPS support installed data cannot be lost through power
failure
 Virus attacks
Remedy: Making sure that up-to-date software is installed frequently to avoid any
attacks.

1.13 Team composition

The project team composed of 3 members, one group leader, one v/ leader, and one secretary.
Problem solving is group activity. Decision on problem and approach are made by group
agreement, which is much better than individual decision.

9
Group Member Responsible for

Dawit Belete

Habtamu Aweke Data gathering and Analysis

Dawit Belete

Habtamu Aweke Documentation and Design

Habtamu Berihun

All Member Implementation and Testing

Table 3: team composition

10
 2 Chapter Two: Description of Existing System

2.1 Introduction of Existing system

As it is described in the first chapter the existing system is done manually. Registration,
documentation, writing, search and retrieval of the specific information of the population is
done manually. This type of system makes the worker to document erroneous and redundant
information, lack of automated statistical manipulations, decreases flexibility and it also
consumes the time of the worker for completing specific task. Moreover, there is no logging
function available to make the system secure.

2.2 Players in the existing system

2.2.1 Enumerator:

The Enumerator is the one who has a privilege to collect and fill the census by collecting the
information of the people manually. Each enumerator is given the map of an enumeration area
along with other census document and he/she is responsible to record all person and Households
in that enumeration area without omission and duplication. Each enumerator has a national
enumerator number given by Werabe Town statics agency to identify each and every
enumerator. The enumerator validates the collected census by its name and signature.

2.2.2 Supervisor:

The supervisor is the one who has a privilege which is given by Werabe Town statistical agency
to supervise and validate the collected census data by using its signature. Supervisor is assigned
to a supervision area and is responsible for ensuring the quality of the information collected in
the area of his/her jurisdiction.

2.3 Major functions

Data Input: Data has been inputted directly by the enumerator.

Data Processing: Count the inputted information collected by the enumerator manually.

11
 Data Output: The data collected so far is recorded in a document and the document
delivered to the Werabe Town statistics agency.

2.4 Business Rule of the Existing system

A business rule is 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 system.
Therefore, our new system has the following business rules:
BR1: Enumeration area should be mapped and unique code is given for each area.
BR2: A person to be counted as a member of a given family he/she must live there at least for
6 months.
BR3: A newly married person is counted with his/her new family regardless of the time she/he
started to live with her/his new family.
BR4: For one woreda 6 enumerators and one supervisor should be assigned.
BR5:200 families are given to one enumerator for urban areas.
BR6: The enumerator is given up to 150 families for rural areas.
BR7: The enumerators should be well trained.

2.5 Forms used in the existing system

This form sections are used to collect data from the population
Area identification

12
Figure 1: Area identification form

Type of residence and housing identification

Figure 2: Type of residence and housing identification form

2.6 Bottlenecks of the existing system

2.6.1 Performance:

In the existing manual system there are more paper work, and didn’t respond very fast.

2.6.2 Input:

In the existing system data was collected door to door by the enumerator.

2.6.3 Security:

In the existing system there is no data security mechanism to protect the collected data.

2.6.4 Efficiency:

Since the existing system is manual it didn’t provide efficient data.

13
 3 Chapter Three: Proposed System

3.1 Introduction

We are going to improve the drawbacks of the existing system by developing an automated,
user friendly and interactive graphical user interface system make the data error free, Enhance
the efficiency and diversification of services activities, he system shall record information of
persons and housing unit, the non-functional requirement of the system deals with how well the
system provides service to the user

3.2 Proposed System Overview

We are going to improve the drawbacks of the existing system by developing an automated,
user friendly and interactive graphical user interface system which will:-
 reduce complexity of existing system,
 manage time effectively,
 make work easy,
 make the data error free
 utilize available resource effectively,
 Enhance the efficiency and diversification of services activities

3.3 Requirements of the Proposed System

 Here we have two requirements.

3.3.1 Functional requirements

The main functional requirements of this system are:

 The system shall record information of persons and housing unit.

 The system shall display the characteristics of individuals.
 The system must generate statistical report.
 The system must calculate the total number of population.
 The system must enable the administrator to configure settings of the system.
 The system shall enable the supervisor to approve the census record.

14
  The system must enable end user to give feedback and view census report.
 Record: this system must enable to insert the information of individuals in the database.
 Update: the system must enable to change the information of the individuals exist in the
data base.
 Search: the system must help the user to find the information from the data base.
 Remove: system must delete the detail information.

3.3.2 Non- functional requirements

The non-functional requirement of the system deals with how well the system provides service to
the user.

Performance:

Easy to use: unlike manual the automated system is easy to use.

Fast and reliable: The time needed to access the data is much less than the existing system.
Maintainability: To ensure that the system continues to work properly by checking it regularly
and making repairs and adjustments if required.
 Scalability: The system should provide flexibility and production of new versions suited
for new environments and changing needs.

 Usability: The system should be easy to use by all.

 Availability: The system should be up and running whenever needed.

 Security and access permission: the system should provide controlled access to
information while on transmission, only authorized users should access and modify data.

 Supportability: since our project is done by php, the code can run in any browsers.

 Legal: our group uses paid version of software’s to develop the system.

 Interface: our group designs the user interface by php and css to make the interface more
attractive.

15
 4 Chapter Four: System analysis

4.1 System models

System modelling involves the evaluation of system components in relationship with one
another to determine their requirements and how to satisfy them. Some system modelling
tools will be employed during the course of this project that will support development
tasks, from analysis to design, then to implementation. This will be represented with the
use of the sequence diagram, activity diagram, state chart diagram and class diagram for
the online census system.

4.1.1 Scenarios

Use case scenario for login

Use case name Login

Use case ID UC-1

Participating Actors administrator, enumerator, supervisor, end user

Precondition User must have user name and password.

Basic course of action action

Step:

1. User click login button

2. The user inputs user name, password and id number

Post condition The actor is now logged into the system

Exit condition The actor logout from the system

Use case scenario for configure admin setting

Use case name Configure admin settings

Use case ID UC-2

16
Participating Actors Administrator

Precondition Administrator must have to login.

Basic course of action Action

Step:

1. Administrator login to the system

2. Administrator select configure option button/menu from
admin page
3. Administrator selects the setting options one by one and
changes the setting.
4. Administrator click on save settings button

Post condition Administrator is now configured the system.

Exit condition Admin logout from the system

Use case scenario for view census report

Use case name view census report

Use case ID UC-3

Participating Actor End –user

Precondition User must have to go home page

Basic course of action Action

Step:

1. The end-user go to census home page

2. the end-user click census report option from menu
3. the user select different census report
4. the user can see the census report
Post condition The user have seen view census report

Exit condition The user view give census report

17
Use case scenario for fill census form

Use case name fill census form

Use case ID UC-4

Participating Actors Enumerator

Precondition The enumerator first login and click fill form button

Basic course of action Action

Step:

1. User login to the system as enumerator

2. Enumerator select fill census form option from enumerator
page
3. The enumerator fills that form
4. enumerator clicks one fill census form button
Post condition The actor fill census form

Exit condition The actor is now populate the census

Use case scenario for Generate report

Use case name Generate report

Use case ID UC-6

Participating Actors Supervisor

Precondition supervisor must login to the system

Basic course of action Action

Step :

1. Supervisor login to the system

2. Supervisor click generate report button.
Post condition The supervisor generate report

Exit condition The supervisor logout from the system

18
Use case scenario for Search

Use case name Search

Use case ID UC-7

Participating Actors Administrator

Precondition Administrator must login as administrator

Basic course of action Action

Step:

1. Administrator login to the system

2. Administrator click search button from admin page
3. Administrator inserts the keyword
Post condition The Administrator is now search the census

Exit condition Admin logout from the system

Use case scenario for Register new enumerator

Use case name Register enumerator

Use case ID UC-8

Participating Actors Supervisor

Precondition Supervisor must login to system

Basic course of action Action

Step:

1. The Supervisor login to the system

2. The Supervisor click add user button
3. Supervisor type information about the enumerator
Post condition The supervisor create new enumerator

Exit condition The supervisor logout from the system

19
Use case scenario for Manage census data

Use case name Manage census data

Use case ID UC-9

Participating Actors Administrator, Enumerator

Precondition Actor must login to the system.

Basic course of action Action

Step:

1. Enumerator login to the system

2. Enumerator click manage button
3. Enumerator update, display or delete enumerated
Post condition The Enumerator is now managed the enumerated data

Exit condition The Enumerator logout from the system

4.1.2 Use case model

4.1.2.1 Actor

In this system, the interaction of actors with the system is through the interface of the system. In
the proposed system, the following actors are identified.

 Administrator
 Supervisor
 Enumerator and
 End-user

4.1.3 Use case Description of the proposed system

Use case diagrams are usually referred to as behaviour diagrams used to describe a set of
functions that some system or systems should perform in collaboration with one or more external
users of the system. Each use case should provide some observable and valuable result to the
actors or other stakeholders of the system.

20
The proposed system use case includes the following:

 Login
 Configure admin settings
 View census report
 Fill census form
 Manage census data
 Search
 Add enumerator
 Generate report

21
Figure 3: use case diagram

Use Case Description for login

Use case name Login

Use case ID UC-1

Participating Actors administrator, enumerator, supervisor, end user

Description The authentication for authorized users in the system and deliver
them the right to visit their specified page

22
Precondition user must have user name and password

Basic course of action action

Step:

1.
User initiate login system
2.
System display login form
3.
The user inputs user name, password and id number
4.
The system checks the validity of the entry and then
verifies whether the user is authenticated and
authorized.
5. The system displays the requested page for further
action.
Alternate flow of Action 1A. If the user’s entry (user name, ID number and Password) is
not correct the system displays error message and return to step
2.

Post condition The actor now use the system.

Exit condition The actor logout from the system

Use Case Description for configure administrator setting

Use case name Configure admin settings

Use case ID UC-2

Participating Actors Administrator

Description How administrator configure and manage the sitting of the system

Precondition Administrator must have to login.

Basic course of action Action

Step:

1. User login as admin to the system

2. The System display admin page
3. Administrator select configure option button/menu from
admin page

23
 4. The configuration setting options are displayed by the
system
5. Administrator selects the setting options one by and
changes the setting.
6. Administrator
7. r click on save settings button
8. The system display done message
Post condition Administrator is now configured the system

Exit condition The administrator logout from the system

Use Case Description for view census report

Use case name view census report

Use case ID UC-3

Participating Actors End –user

Description How an end-user view census report

Precondition User must have to go home page

Basic course of action Action

Step:

1. The end-user go to census home page

2. the end-user view census report option from menu
3. system display view census report page
4. the user select different census report
5. system display the census report
6. the user can see the census report
Post condition The user have seen report about census

Exit condition The user leave the system

Use Case Description for fill census form

Use case name fill census form

Use case ID UC-4

24
Participating Actors Enumerator

Description How a system user enumerate the population

Precondition Enumerator must have to login with user name and password

Basic course of action Action

Step:

1. User login to the system as enumerator

2. System display enumerator page
3. Enumerator select fill census form option from enumerator
page
4. System display the fill census form
5. The enumerator fills that form
6. System validate the filled information
7. The system populate the census
8. System display populated message

Alternate flow of Action 7.If the filled information is not correct

1. System displays error message And continues from step 4

Post condition The enumerator is now populated the census

Exit condition The enumerator logout from the system

Use Case Documentation for give feedback

Use case name Give feedback

Use case ID UC-5

Participating Actors End –user

Precondition User must have email address

Description How an end-user give feedback

Basic course of action Action

25
 Step:

1. The end-user go to census home page

2. The user select feedback or contact us option from home
page
3. system display feedback page
4. the user inserts name, email address and give feedback on
the text area provided
5. user click on feedback button
6. system saves the feedback and display each feedback on
admin page
7. system display the success message
Post condition The user gives feedback

Use case description for Generate report

Use case name Generate report

Use case ID UC-6

Participating Actors Supervisor

Description How the supervisor generates the report

Precondition supervisor must login to system

Basic course of action Action

Step :

1. Supervisor initiate login

2. The system display login form
3. Supervisor enters user name and password.
4. The system display menus.
5. Supervisor click generate report button and report criteria.
6. The system generates report based on the criteria.
Post condition The supervisor generate report

Exit condition The supervisor logout from the system

26
Use Case description for Search

Use case name Search

Use case ID UC-7

Participating Actors Administrator

Precondition administrator must have to login

Description How administrator search the required information.

Basic course of action Action

Step :

1. User login as administrator to the system

2. System display Administrator page
3. User select Search user option from user page
4. The system display the field to be searched
5. User select the field
6. Administrator click on search button
7. System search the required information
8. System display done message
Post condition The required information is now searched

Use Case description for Register enumerator

Use case name Register enumerator

Use case ID UC-8

Participating Actors Supervisor

Precondition User must have to login

Description How supervisor register each enumerator in its supervision area

Basic course of action Action

Step:

1. The user login as supervisor

2. System displays supervisor page
3. The user select register user option from supervisor page

27
 4. system display the form
5. the supervisor fill the form
6. user click on register button
7. system register each user
8. system display the success message
Post condition The user is now registered

Exit condition The supervisor logout from the systems

Use case name manage census data

Use case ID UC-9

Participating Actors Administrator, Enumerator

Description How a system user enumerate the population

Precondition Enumerator must have to login with user name and password

Basic course of action Action

Step:

1.Actor login to the system as enumerator

2. System initiates sub activity update (enumerated, census),

delete (enumerator, enumerated, supervisor), display
enumerated.

2.System display enumerator page

3.Actor select populate census form option from enumerator

page

4.System display the fill census form

5.Actor fills that form

6.System validate the filled information

7.The system populate the census

8.System display populated message

28
 Alternate flow of Action 7A1. If the filled information is not valid

2. System displays error message

The use case continues from step 4

Post condition The enumerator is now populated the census

Exit condition The enumerator logout from the system

Use Case description for manage census data

Use Case description for update enumerated (S1)

Use case name Update enumerated

Use case ID S1

Participating actors Administrator, Enumerator

Precondition User must have to login

Description How a system user update the census

Basic course of action Action

Step:

1. User login into the system as enumerator

2. System display enumerator page
3. enumerator select update census option from
enumerator page
4. System displays update census page
5. Enumerator enter information related to the
record to be updated
6. System displays the census record to be
updated
7. Enumerator updates the census field
8. System validate information
9. System updates the census record
10. System display update message
Post condition The enumerator is now updated the census

29
Use Case Documentation for delete census (S2)

Use case name Delete census data

Use case ID S2

Participating Actors Administrator, Supervisor, Enumerator

Precondition user must have to login

Description How a system user Delete census

Basic course of action Action

Step:

4. Actor login to the system

5. System display the admin page
6. Actor select the delete census option from admin page
7. System ask the user to insert keyword
8. Actor inserts the keyword
9. Actor click on delete button
10. System check for the existence of specified keyword
11. System display conformation for deletion
12. Actor confirm the deletion
13. System display done message
Alternate flow of Action 7A1. if the requested keyword is not found in the database

1. The System display not found message

2. Use case continue from step5
9A1. if the user does not needs to delete the information

1. User click on cancel button

Post condition The Administrator is now Deleted the census

30
Use Case Documentation for display enumerated (S3)

Use case name Display enumerated

Use case ID S3

Participating Actors Supervisor, enumerator

Precondition User must have to login

Description How a system user display the enumerated census from

temporary data base for approval or update.

Basic course of action Action

Step:

1. The User login to the system

2. System display user page
3. The User selects the display option from the user
page
4. The system displays the display page
5. User select type of information to be displayed
6. System display the census accordingly
Post condition The actor is now displayed the recorded census data

4.1.4 Object model

Object model deals with object oriented of the system. This includes, class diagram, relationship
between these classes, methods in the class and properties

4.1.4.1 Data Dictionary

This gives a brief description of the field names used in the tables and what they define as per the
databases.

Supervisor Table

Field name Data type Size Description

supervisor_name Varchar 20 Holds the name of the

Supervisor
Supervisor_id Number 20 Holds the First name of

31
 the Supervisor

first_name Text 20 Holds other names of the

Supervisor
last_name Text 20 Field for identifier of the
Supervisor
Address Int 10 Holds the contact of the
supervisor
email Text 20 Highlights the email of
the supervisor
Phone_no. Int 15 Fields holds phone
number of the supervisor
Password Varchar 20 Indicates the password

Table: supervisor table

Enumerator Table

Field name Data type Size Description

Enumerator_name Varchar 20 Holds the name of the

Enumerator
Enumerator ID Number 20 Holds the First name of
the Enumerator
first_name Text 20 Holds other names of the
Enumerator
Last_name Date time 20 Field for identifier of the
Enumerator
Address Date time 10 Holds the contact of the
Enumerator
email Text 20 Highlights the email of the
Enumerator
Phone_no. int 15 Fields holds phone number
of the Enumerator
Password Varchar 20 Holds the name of the
Enumerator
Table: supervisor table

Household Table

Field Name Data type Size Description

Location Varchar 20 Indicates the location for

household

32
Address int 20 Indicates the Address for
household

Place_of_birth Varchar 20 Indicates the age of

residents

Duration_of_residenceVarchar 20 Indicates the religion of

residents

Religion Varchar 20 Indicates the marital status

of residents

Marital_status Varchar 10 Indicates the birth place of

residence

Orphan_hood Varchar 20 Indicates the orphan in the

residence

Previous_residence Varchar 20 Indicates the previous

residence of residents
Duration_of_residence Int 20 Indicates the location for
household

Nationality Varchar 20 Indicates the tribe of

residents

Table: house holds

33
4.1.4.2 Class Diagram (Conceptual Modelling)

Figure: class diagram

34
4.2 Dynamic Model

4.2.1 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. A popular use for them is to
document the dynamics in an object-oriented system.

Figure sequence diagram for login

35
Figure sequence diagram for fill form

36
Figure sequence diagram for update

37
Figure sequence diagram for delete

38
4.2.2 Activity diagram

Activity diagrams are typically used for business process modelling, for modelling the logic
captured by a single use case or usage scenario, or for modelling the detailed logic of a business
rule. Although UML activity diagrams could potentially model the internal logic of a complex
operation it would be far better to simply rewrite the operation so that it is simple enough that
you don't require an activity diagram. In many ways UML activity diagrams are the object
oriented equivalent of flow chart and data flow diagram (DFDs) from structured development.

39
40
41
Activity diagram for register

42
4.2.3 State chart diagram

State chart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. The
most important purpose of State chart diagram is to model lifetime of an object from creation to
termination. It used to model the states and also the events operating on the system. When
implementing a system, it is very important to clarify different states of an object during its life
time.

Figure State chart diagram for Fill census form

43
 5 Chapter five: system design

5.1 Introduction

The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on. System design is a phase of creativity rules
where customer requirements, business needs and technical considerations all come together in
the formulation of the system. Design is the first step to the development phase. The objectives
of design are to model the system with high quality. Implementing of high quality system
depends on the nature of design created by the designer. Generally this chapter describes how the
project is designed, what tasks to done under the project and different modules and their way of
functioning.

5.2 System Design Overview

The system will replace the manual system in the organization by ensuring that all the users’
requirements are met. It will ensure that proper records are kept all backups are performed to
prevent data loss, to develop a more customer focused service, to improve integrity impartiality
and to improve accuracy of records kept.

5.3 Design Goal

The design goal can be inferred from non-functional requirements which will be discussed as
follows

 Reliability: Reliability is “the probability that a system will perform a required function,
under stated conditions, for a stated period of time”. Our system is reliable to provide
reliable service for the user.
 Manageability: it is easy for system administrators to manage the application, usually
through sufficient and useful instrumentation exposed for use in monitoring systems and
for debugging and performance tuning.
 Maintainability: is the ability of the system to undergo changes with a degree of ease.
These changes could impact components, services, features, and interfaces when adding
or changing the functionality, fixing errors, and meeting new business requirements. our
system can be maintained easily if any change is happened.

44
  Performance: Performance is an indication of the responsiveness of a system to execute
any action within a given time interval. It can be measured in terms of latency or
throughput. Latency is the time taken to respond to any event. Throughput is the number
of events that take place within a given amount of time.
 Security: our system prevents malicious or accidental actions outside of the designed
usage, and prevents disclosure or loss of information. A secure system aims to protect
assets and prevent unauthorized modification of information.
 End User Criteria: - The system should have simple and understandable graphical user
interface such as forms, navigation menu and buttons which have descriptive names.

5.4 Design Trade-offs

Conceptual design involves a series of trade-off decisions among significant parameters - such as
operating speeds, memory size, power, and I/O bandwidth - to obtain a compromise design
which best meets the performance requirements. Both the uncertainty in these requirements and
the important trade-off factors should be ascertained. Those factors which can be used to
evaluate the design trade-offs (usually on a qualitative basis) include:

 Maintainability
 Compatibility

Maintainability: Since our project is developed by php, Repair should be readily accomplished
during ground operation, and if inflight maintenance is desired, this should be specified as a
design requirement. Generally, maintenance procedure is to remove bad components or
subsystems from the system and replace them with another component.

Compatibility: Since our project is developed by php. It can easily run in any web browser
without any problem.

5.5 Architecture of the System

Architecture is a critical aspect of designing a system, as it sets the foundation for how the
system will function and be built. It is a conceptual that defines the structure behaviour more
view of the system, including the selection of hardware and software components, the design of
interfaces, and the overall system structure.

5.5.1 Current software architecture

The existing system is performed manually. So, there is no any type of software architecture .

45
5.5.2 Proposed software architecture

46
47
48
1