Project Chapter Summaries and System Requirements

Contents
Chapter One................................................................................................................................................................................. 1
1.Introduction..............................................................................................................................................................................1
1.1. Background of the project................................................................................................................................................1
1.2. Current System................................................................................................................................................................. 1
1.3. Problem Statement...........................................................................................................................................................2
1.4. Objective the Project........................................................................................................................................................2
1.4.1. General Objective......................................................................................................................................................2
1.4.2. Specific Objective......................................................................................................................................................2
1.5. Scope of the project..........................................................................................................................................................3
1.6. Limitation of the project...................................................................................................................................................3
1.7. Significance of the project................................................................................................................................................4
1.7.1. Tangible benefits........................................................................................................................................................4
1.7.2. Intangible benefits......................................................................................................................................................4
1.8. System Requirements.......................................................................................................................................................4
1.8.1. Hardware requirement..................................................................................................................................................4
1.8.2. Software requirement.................................................................................................................................................5
1.8.3. Programming language..............................................................................................................................................5
1.9. Methodology of the Project..............................................................................................................................................6
1.9.1. Data gathering methodology......................................................................................................................................6
1.9.2. Data Analysis Methodology.......................................................................................................................................6
1.9.3. Implementation Methodology....................................................................................................................................6
1.10. Feasibility study..............................................................................................................................................................7
1.10.1. Technical feasibility..................................................................................................................................................7
1.10.2. Operational feasibility..............................................................................................................................................7
1.10.3. Economic Feasibility...............................................................................................................................................8
1.10.4. Legal feasibility.......................................................................................................................................................8
1.11. Budget Schedule............................................................................................................................................................8
Department of Information Technology Page

Web based Census Management System 2018
1.12. Work breakdown..........................................................................................................................................................10
1.13. Team members and their responsibilities.....................................................................................................................11
CHAPTER TWO....................................................................................................................................................................... 12
2. REQUEREMANT ANALYSIS.........................................................................................................................................12
2.1. Introduction................................................................................................................................................................... 12
2.2. Current System...............................................................................................................................................................13
2.3. Practical Work of the Current System.............................................................................................................................13
2.4. Supplementary Requirements.............................................................................................................................................14
2.4.1. Business rules..........................................................................................................................................................14
2.4.2. Constraints...............................................................................................................................................................14
2.5. Software Requirement Specification (SRS).....................................................................................................................14
2.5.1. Functional Requirement...........................................................................................................................................15
2.5.2. Non Functional Requirement...................................................................................................................................16
2.6. System Model............................................................................................................................................................16
2.6.1. Use case Modeling...................................................................................................................................................17
2.6.1.1. Actor..................................................................................................................................................................... 17
2.6.2. Essential Use case diagram......................................................................................................................................17
2.6.3. Use Case of the Proposed System............................................................................................................................18
2.6.4. Class Responsibility Collaborator (CRC) Analysis..................................................................................................31
2.6.5. Sequence Diagram...................................................................................................................................................33
2.6.6. Activity Diagram.....................................................................................................................................................38
2.6.7. CLASS DIAGRAM.................................................................................................................................................46
2.6.8. User Interface Design..............................................................................................................................................48
CHAPTER Three.......................................................................................................................................................................... 51
3. SYSTEM DESIGN................................................................................................................................................................. 51
3.1. INTRODUCTION..........................................................................................................................................................51
3.2. DESIGN GOAL.............................................................................................................................................................51
3.3. System design Architecture ……………………………………………………………………………………………………………………………………..52
3.4. SUBSYSTEM DECOMPOSITION...................................................................................................................................54

3.5. COMPONENT DIAGRAM.............................................................................................................................................54
3.6. DEPLOYMENT DIAGRAM............................................................................................................................................56
Department of Information TechnologyPage

3.7. PERSISTENCE MODELING...........................................................................................................................................57
3.8. Access control Security……………………………………………………………………………………………………………………………………………….58
3.8.1 Boundary conditions and Exception Handling...........................................................................................................59

3.8.1.1 Boundary Conditions.................................................................................................................................................59
3.8.1.2 Exception Handling...................................................................................................................................................60
3.9 USER INTERFACE DESIGN...........................................................................................................................................60
CHAPTER FOUR.......................................................................................................................................................................... 64
4. IMPLEMENTATION.................................................................................................................................................................64
4.1. INTRODUCTION...............................................................................................................................................................64
4.1.1. IMPLEMENTATION TOOLS.......................................................................................................................................64
4.2. CODING.......................................................................................................................................................................... 64
CHAPTER FIVE........................................................................................................................................................................ 71
5. TESTING, CONCLUSION AND RECOMMENDATIONS..............................................................................................................71
5.1. SOFTWARE TESTING GOAL AND FUNDAMENTALS.........................................................................................................72
5.1.1. IMPORTANCE OF TESTING.........................................................................................................................................72
5.1.2. TESTING TECHNIQUE.................................................................................................................................................73
5.1.3. BLACK BOX TESTING....................................................................................................................................................73
5.1.4. White box testing…………………………………………………………………………………………………………………………………………………..73
5.1.5. STRATEGIES OF TESTING............................................................................................................................................74

5.1.6. UNIT TESTING.............................................................................................................................................................77
5.1.7. INTEGRATION TESTING...............................................................................................................................................77
5.1.8. SYSTEM TESTING.........................................................................................................................................................77
5.1.9. Recommendation and future enhancement..............................................................................................................78
References..........................................................................................................................................................79

Figure lis
Figure 1 Essential use case diagram..................................................................................................................................18

Figure 2 Use case Diagram ..............................................................................................................................................20
Figure 3 CRC Diagram of the system...............................................................................................................................32
Figure 4 Sequence diagram for login.................................................................................................................................33
Figure 5 Sequence diagram for create account..................................................................................................................34
Figure 6 Sequence diagram for update account.................................................................................................................35
Figure 7 Sequence diagram of delete account.....................................................................................................................36
Figure 8 Sequence diagram for Register.............................................................................................................................37
Figure 9 Sequence diagram for message.............................................................................................................................38
Figure 10 Activity diagram for login..................................................................................................................................39
Figure 11 Activity diagram for create account....................................................................................................................40
Figure 12 Activity diagram for message.............................................................................................................................41
Figure 13 Activity diagram for view account.....................................................................................................................42
Figure 14 Activity diagram for update account..................................................................................................................43
Figure 15 Activity diagram for register..............................................................................................................................44
Figure 16 Activity diagram for Generate report..................................................................................................................45
Figure 17 Class diagram......................................................................................................................................................47
Figure 18 Login interface....................................................................................................................................................48
Figure 19 User interface prototype.....................................................................................................................................49
Figure 20 Regestration Interface.........................................................................................................................................50
Figure 21 System arcitucture of Secure webbased census...................................................................................................53
Figure 22 Sub system diagram............................................................................................................................................54
Figure 23 Component diagram............................................................................................................................................55
Figure 24 Deployment diagram...........................................................................................................................................56
Figure 25 Persistance diagram.............................................................................................................................................57
Figure 26 User interface for Login......................................................................................................................................61
Figure 27 Regester census interface....................................................................................................................................62
Figure 28 admin interface...................................................................................................................................................63
Figure 29 Add enumerator interface....................................................................................................................................63

Table lis
Table 1 Budget Schedule......................................................................................................................................................9

Table 2 Work breakdown....................................................................................................................................................10
Table 3 Team members and their responsibilities................................................................................................................11
Table 4 Description of Actor...............................................................................................................................................19
Table 5 Use Case Description for login................................................................................................................................22
Table 6 Use Case Description for Approve.........................................................................................................................23
Table 7 Use Case Description for generate report...............................................................................................................24
Table 8 Use Case Description for Create account...............................................................................................................25
Table 9 Use Case Description for update account...............................................................................................................26
Table 10 Use Case Description for View report...................................................................................................................27
Table 11 Use Case Description for Register.........................................................................................................................28
Table 12 Use Case Description for Search person...............................................................................................................29
Table 13 Use Case Description message.............................................................................................................................30
Table 14 Describes actors are controlling access of the system............................................................................................59
Table 15 Implementation tools.............................................................................................................................................64
Table 16 Describes test case for login.................................................................................................................................74
Table 17 Test Case for Regester census Interface...............................................................................................................75
Table 18 Test case for house enumeration……………………………………………………………………………………………………………….…….76

Chapter One
1. Introduction
The central statics agency defines a population census as the total process of collecting, counting
demographic, socio-economic related data at a specific time of all people since a country or part of a
country. [1]
The central statics agency conducts, produces, and administers data generated from surveys and censuses
in Ethiopia. Census is a great interest to Ethiopia governmental population and house holding. Census as a
case study to know the number of people and to help economic political and socio-cultural planning of a
country. It is also reliable and detailed data on the size, structure, and distribution and socio- economic and
demographic characteristics of a country population is required for planning.
1.1. Background of the project

The system has been done manually meaning that the system is doing every activity traditionally, census
data collection demands an authorized enumerator, Who collects the census data manually which is time
consuming and waste of resource document mismanagement, require manpower, data redendency.so the
team member Can see this problem change the manual system into web based census management system
to consume rescores to avoid data redundancy to know exact number of population number and To
minimize the manual system by web based census management system.
Since Dessie city is suitable to live, currently it is estimated that there are over 800,500 people who live in
it. From these 399,900 are males and 400,600 are females. However, it is difficult to know the exact
number of person and house. There is no known project done for Dessie city statistical agency office
before this project started.[2]
The system creates a mechanism to register, update, and search census and housing data for Dessie city
administration. It will avoid time consuming as enumerator of the existing system goes through each
person’s house door to door. Generally, the new proposed system automates the current population census
and housing unit for Dessie city.
1.2. Current System

In the existing system tasks are done by manually. The registration, documentation, writing, searching and
retrieving of the specific information of the population is done manually. These types of system make the
Department of Information Technology Page

worker to document erroneous and redundancy information, decreases flexibility and it also time
consuming of workers for completing specific task.[1]
1.3. Problem Statement

Since the current census and house enumeration system is done manually, it needs automated statistical
manipulation. So there were many problems or difficulties to perform census related activities.
Generally, the project team analyzes the following problem:

 Document Mismanagement: Chances for losing the census data is high in the
existing system.
 More paper work: because the current system is done manually it required a lot of
paper.
 It requires more Resource such as paper, pen, transportation and place of storage.
 It needs more manpower
 High data redundancy and erroneous data storing: there is no data validation concept
in the current system as result the chance to store duplicate data is high.
 The current system is not efficient, flexible, reliable, available and difficult to
retrieve the data that is placed in the shelf.
 It is difficult to generate statically data.
1.4. Objective the Project
1.4.1. General Objective

The general objective of this project is to develop web based census management system for Dessie
city.
1.4.2. Specific Objective

To achieve the above mentioned general objective, the project includes the following specific
objective.
 Study the existing system and identifying the problems under the existing system.
 Requirement analysis of the existing system with respect to functional and nonfunctional
requirement.
 Design new system based on the requirement analysis of the existing system.
 Implementing the new system.
 Testing the system using different testing methodology.
 Deploying the system after the system is tested.
1.5. Scope of the project

Scope of the system identifies the problem to be studied, analyze, design, constructed and ultimately
improved. It is specifically concerned with what problem the new proposed system address.
In scope
 Registering new person, house ,migration, death, birth rate and marriage.
 Generate census report.
 Messaging
 The system is implemented only for Dessie city.
Out scope
 Generate certificate
 The project is not calculating the total record of disability, illiteracy, economic
character, Employment status, Current Marital status, marriage.
1.6. Limitation of the project

The limitations of this project are:
 Performances degrade due to ICT infrastructure limitation/bandwidth and connectivity

problem.
 The new proposed system is not mobile based application.
 Due to time limitation our system supports only English language.

1.7. Significance of the project
The problem is listed by manual census system and it will solve after the implementation of the
project. The project gives a mechanism for automating statistical manipulation.
The benefits of the project can be tangible or intangible.
1.7.1. Tangible benefits

There are benefits that can be measured in monetary terms. These include:
 Reduce the amount of resources
 Reduce transportation cost
 Helps to save time.
1.7.2. Intangible benefits

Intangible benefits can’t be measured in monetary terms directly but they do have a very
significant business impact. This includes:
 Satisfaction of work.
 Reliable data retrieval.
 Increased system performance.
 Decrease errors in data sorting.
 Data accessed easily.
 Data security is better.
1.8. System Requirements
1.8.1. Hardware requirement

 Personal computer-to write document.
 Printer to print our documentation.
 8 GB flash drive to store data and CD to store data.
 Paper used to organize the idea before writing to computer and to draft all the idea on it.
 Pen used to write the drafting of the idea on the paper.
1.8.2. Software requirement

 Operating system (Microsoft window 7)-user friendly

operating system.
 Microsoft word 2007-used to write a document.
 Microsoft power point 2007-for presentation of the document.
 WAMP server-platform independent and used to run test applications before being uploaded on
to the actual server)
 MySQL database-the project team used MySQL database since:
 Easy to use
 Open Source
 It is fast
 It is secure
 Notepad ++-to edit source code.
 Edrawmax-to draws UML diagrams.
 Microsoft office Visio 2007 to draws UML diagrams.
1.8.3. Programming language

 PHP-Server-side scripting.
The project team used to PHP programming language since
 Easy to use
 Platform Independent (It can be run on all major operating systems)
 Supports all major Web Servers
 Supports all major Databases
 open source
 Easy to fix problem set.
CSS-in order to design the user interface.
 HTML-in order to use Client side scripting.
 JS-In order to define different functions.
1.9. Methodology of the Project

1.9.1. Data gathering methodology
To get enough data for the project we will use types of data collection methods like:
 Interviews: This is one of the methods used for collection of data (gathering
information)
about the existing systems and also we gather information that used for the project
that we develop.
 Questionnaires: This is one of the methods that we have used for gathering
information about the existing system and how the users satisfy by the system.
You are supported by Mr. Mesfin to answer all the questions.
 Documentary analysis: We use documentary analysis for gathering information (data
collection).It is analyzing the document prepared in the existing system, this means we
analyze different documents like form and report sample when the existing system use
at the time of giving service for peoples.
1.9.2. Data Analysis Methodology

For the system analysis and design we followed object oriented system analysis
methodology. Object-oriented approach combines data and process called method into single
entities called object. The goal of object-oriented approach is to make system elements more
reusable, thus improving system quality and the productivity of systems analysis and design.
To understand and express the essential and interesting features of an application in the
complex real world, an object-oriented model is built around objects. [4]
1.9.3. Implementation Methodology
 For Front end programming we use: CSS, JavaScript, HTML
 For Server Side Scripting we use: PHP
 For Backend (Data Storage) we use: MYSQL Server. Because it requires low
computer resource requirements, and easy to implement for web based system.

1.10. Feasibility study
According to the project’s workability, impacts on the organization, ability to meet user need and
effective use of resource, the alternative analysis usually include as part of the feasibility study, identifies
viable alternatives for the system design and development.
1.10.1. Technical feasibility

The project is technically feasible since the project team know the tools that are used to develop the
system like the database (MySQL), the programming language (PHP), the system modeling (UML) tools
and others of software and hardware requirements that the project team used to work the project easily.
1.10.2. Operational feasibility

The project is operationally feasible since the system has a user friendly interface that can be implemented
easily and can perform tasks that can be used easily by user.

1.10.3. Economic Feasibility

The project is economically feasible since it has many benefits that it gives than the
existed manual system .Even if it needed cost to develop the system the time,
performance, accuracy and security in terms of cost is higher. And also it reduces the
cost of paper, pen and the resources. Generally, the cost after the implementation of
the project will be less when compared with the current cost.
1.10.4. Legal feasibility

The project is legally feasible since it does not violate or contradict any law,
regulation, custom, value of Ethiopian constitution and Ethiopian statistical agency.
1.11. Budget Schedule

The following table lists budget required for the successful development of the project
Department of Information Technology Page 8

Types of costs Tool name Quantity Unit price (in Total price (in
Hardware costs Personal computer 1 12,000 12,000

Flash(8 GB) 1 150 150
CD ROM 2 7 14
DVD 2 18 36
Pen 6 4 24
Paper 1 packet 100 100
Notebook 1 30 30
Total Price 12,354
Wamp server 1 Free Free
Microsoftoffice2007 1 Free Free
Notepad++ 1 Free Free
Edrawmax 1 Free Free
Software costs Adobe Photoshop 1 Free Free
Windows 7 OS 1 Free Free
Microsoft office Visio 2007
Total cost - - - -
Table 1 Budget Schedule

1.12. Work breakdown

The table below represents the main activities of the project together with their
respective start and end date.
Dec 2017 Jan 2018 Feb 2018 Mar 2018 Apr 2018
ID Task Name Start Finish Duration
1 proposal 11/15/2017 11/30/2017 2w 2d

2 System analysis 12/4/2017 12/28/2017 3w 4d
3 System design 1/3/2018 1/30/2018 4w
4 System implementation 2/5/2018 3/30/2018 8w
5 Testing and conclusion 4/2/2018 4/27/2018 4w
Table 2 Work breakdow

1.13. Team members and their responsibilities
No Name Activities
1 Mahlet Asfaw Proposal
Tirsit simur
2 Alemu Sefiw System Analysis
Ayalnesh Tadesse
Asiya Mohammed
Awekush Kasie
3 All group members System Design
4 Implementation
All group members
5 Tirsit Simur Conclusion
Table 3 Team members and their responsibilities

CHAPTER TWO
2. REQUEREMANT ANALYSIS
2.1. Introduction
System Analysis is the detailed study of the various operations performed by the system and
their relationships within and outside the system.
Analysis is the process of breaking something into its parts so that the whole may be
understood. System analysis is concerned with becoming aware of the problem, identifying
the relevant and most decisional variables, analyzing and synthesizing the various factors and
determining an optimal or at least a satisfactory solution. During this a problem is identified,
alternate system solutions are studied and recommendations are made about committing the
resources used to design the system.
This system specification including the existing system of the Dessie town census
management system and proposed system of functional and non functional requirements used
to design the system. It also includes:
System Requirement Specifications (SRS), Use case diagrams, Use case description (for each
use case identified), and Sequence diagram, Activity Diagram and User Interface
Prototyping.

2.2. Current System
As it is described in the first chapter, the existing system does everything manually.
Registration, documentation, writing, search and retrieval of the specific information of
the population is done manually. These types of system make the worker to document
erroneous and redundancy information, lack of automated statistical manipulations or
analysis, decreases flexibility and it also consume the time of employee for completing
specific task.[2]
2.3. Practical Work of the Current System

Major actors of the existing system are they only two
 Enumerator:
The Enumerator is the one who has privilege to collect and fill the census by collecting the
information of the people on the paper manually. Each enumerator was given the map of an
enumeration area along with other census document and he/she was responsible to record all
persons and households in that enumeration area without omission and duplication. Each
enumerator contains a national enumerator number given by central statics agency to identify
each and every enumerator.
 Supervisor:
Supervisor is a person who has a privilege to supervise and validate the collected census data.
He/she will assign to a supervision area and will responsible for ensuring the quality of the
information collected in the area of his/her jurisdiction.
Section of census form
According to Ethiopian census 2010, the census form has the following section:
 Section 1:Area identification
 Section 2:Type of residence and housing identification
 Section 3:Details of a person in household
 Section 4:Death in the household during the last 12 months
 Section 5:Information in housing unit

2.4. Supplementary Requirements
2.4.1. Business rules

In every organization or institution there are rules and policies. which are used
to govern all activities in specified work flow, control the work flow and
performed in the work environment are called business rules. So, Dessie city
statistical office has the following rules:
 BR1: Each house must have owner.
 BR2: Each house has a unique identification number.
 BR3: A person to be counted as a member of a given family, he/she must
live there at least for 6 months.
 BR4: Administrator should deliver unique user name and password
for each user.
 BR5: All Users must have a valid user name and password.
2.4.2. Constraints
Constraints are effectively global requirements such as limited development resources or a
decision by senior management that restricts the way to develop a system. Constraints can be
economic, political, technical, or environmental schedule, target environment, or to the system
itself. So, where are the constraints?
2.5. Software Requirement Specification (SRS)

Software Requirement Specification (SRS) is a description of a software system to be developed.
Requirement is divided into two: function requirement and non-functional requirement.

2.5.1. Functional Requirement
The main functional requirements of this system are:
 The system enables the enumerator to record the information person

and housing unit.
 The system generates different statistical reports (like birth rate,
mortality rate, migration).
 The system would calculate the total number of people or density of
population in the Dessie city.
 The system allows messaging to the users.
 The system allow for system administrator to create account, update
account and delete account.
 The system enables the supervisor to approve the census recorded by
the enumerator.
 The system allow for system administrator to activate and deactivate
accounts.
 Search: the system would enable to help the user to find the information
from the data base.
 Remove: system would enable to delete the information detail when it
is required.

2.5.2. Non Functional Requirement
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 automate is easy to use
because it is just pressing a simple and single keys or
symbols.
 Fast and reliable: since the data is stored and accessed
electronically, like that of manual it cannot be failed always
and Serve users efficiently.
 Speed: it will let the employers to access the needed information
quickly.
 Security: Provide authentic and authorized features to the current system
where private and confidential data can only be viewed by authorized user.
 Maintainability: to ensure that the system continues to work properly by
checking it regularly and making repairs and adjustments if required.
 Organization of menu: menus are organized in hierarchical manners.
 Scalability: it is the ability of a system to continue to function well as it
(its context) is changed in size or volume in order to meet a user need.
2.6. System Model

System model are the function of the use case, identifying actors, identifying use case,
constructing use case model and use case scenarios and final designing of user interface.
System modeling involves the evaluation of system components in relationship with one
another to determine their requirements and how to satisfy them. This will be represented
with the use of the sequence diagram, activity diagram, state chart diagram, collaboration
diagram and class diagram for the web based census system.

2.6.1. Use case Modeling
 Essential Use case modeling.
 System use case modeling.
2.6.1.1. Actor
An actor describes any entity that interacts with the system. Our project system
contains the following actors:
 Administrator
 Supervisor
 Manager
 Enumerator
2.6.2. Essential Use case diagram

An essential use case is a use case that is technology independent. It describes the
fundamental business task without bringing technological issues into account.
Essential use case is often used to explore usage based requirements.
Essential use case describes the interaction between the user and the system at a high
level of abstraction.

Essential use case of Census
management System
Adminstrator Manage account
view report
Supervisor
message
Regester
Enumerator
Figure 1: Essential use case diagram
2.6.3. Use Case of the Proposed System

Use case diagrams are usually referred to as behavior diagrams used to describe a set of
actions. The system should or can perform in collaboration with one or more external
users of the system (actors). Each use case should provide some observable and valuable
result to the actors or other stakeholders of the system.

Table 4 : Description of Actor
User Characteristics
Administrator  Create account
 Delete account
 Update account
 View account
Supervisor  Approve
 View report
 Search
 Communicate with message
Manager  Generate report

 View report
Enumerator  Register (new person, migration, death,
birth, household and marriage)
 View report

System use case of Census Management System
Register
<<include>>
logout
<<extend>>
Login
<<include>>
Update account <<include>>

Approve
<<include>> Enumerator
Create account <<include>>
<<extend>> <<include>> View report
<<extend>>
<<include>>
Send report
Manage account <<include>>
message
<<extend>> Supervisor
<<extend>>
view account
Search
Delete account Manager
Generate report
Administrator
Figure 2: Use case Diagram
Use case Scenario

1. Use case scenario name login
Actor: Administrator

Actor name: Mr. Melese
Flow of event: - first Mr. Melese must enter the right user name and password and click
on the
login Button. Then if the password and user name is right he can see the admin page and
gain
access to it.
2. Use case scenario name creating user Account
Actor: Admin
Actor name: Mr. Alemu
Flow of action: - first Mr. Alemu must insert the right user name and password and click
on the login Button. Then he can access the menus on the admin page and click on the
create button to create a new user account and fill the form and click Save Button. After
that logout from the page then the task is completed.
Table 5 : Use Case Description for login

Use case name Login
Use case ID UC-1

Actors Administrator, Enumerator, Supervisor ,Manager
Precondition User must have user name, password to access the system
Post condition The actor is logged into the system and can access it
Description It helps to access the system by authenticating and authorizing un and pw
Basic course of User System

action
Step 1.User initiate login system Step 2.System display login form
Step3.The user input user name, Step 4. The system checks the validity of the
password and submit. entry and then verifies whether the user is
authenticated and authorized.
Step 5. If the user is authenticated &

authorized the system displays the requested
page
Step 6. Use case end.
Alternative course If the username and password is incorrect

of action 1A. The user can try again to access the system or return to step 3.
Table 6 : Use Case Description for Approve

Use case name Approve
Use case ID UC-2
Participating Supervisor
Actors

Precondition Supervisor must have to logged in to the system.
Post condition The Supervisor is now approved the record data
Description The Supervisor approve the recorded census data

action
Step1.Click recorded data Step 2. display the recorded data
Step3. view recorded data Step 5.The system move the data from
temporary database to permanent census
Step 4.The actor click on approve button
data base
Step 6.The system display done

message
Step 7.use case end.
Alternative course 1A.if the recorded data is not valid return to basic course of action 3
of action
Table 7: Use Case Description for generate report

Use case name Generate report
Use case ID UC-3
Actors Manager
Precondition Manager must be authenticated and authorized.

Post condition Manager generates report successfully.
Description Manager generates person data & house holding filled by enumerator.
Basic course of System

User
action
Step1. Manager click on Step 2.The system display generate
generate person report or person report or generate house
generate house report report
Step3. Manager view recorded
Step 4.The system display recorded
data
data
Step 5. Manager generates Person
report and house report. Step 6. The system display report
generate successfully.
Step 7. use case end
Alternative course 1A. If there is no data the system display error message go to step3.
of action
Table 8 : Use Case Description for Create account

Use case name Create account
Use case ID UC-4
Actors Administrator
Precondition Administrator must be authenticated and authorized.
Post condition User can use the account to interact to the system.

Description The administrator can create new user account for the purpose of
accessing the system
Basic course of action System
User
Step2. The system show
Step1. Open homepage
options like
Step3. Administrator click on
create account button.  Create, update and
 delete account
Step5. Administrator fills create Step4. The system display
account form. creates account form.
Step6. Click create account
Step 7. The system display your
button.
account is successfully created.
Step8. use case end

Alternative course of 1A. If the administrator’s entry is invalid data the system displays
action error message and return to step 5.
Table 9: Use Case Description for update account

Use case name Update account
Use case ID UC-5
Actors Administrator
Precondition Administrator must be authenticated and authorized.
Post condition An administrator can view the account.

Description An administrator can update exiting account.
Basic course of System
action User
Step: Open homepage
Step1. Step2. The system show options
Step3. Administrator click on update like
account button.  Create, update and
Step5. Administrator fills update account  delete account
form.
Step4. The system display updates
Step6.Clicking update button.
account form.
Step 7. The system display account

updated successfully.
.
Step8. Use case end.
Alternative course 1A. If the administrator’s entry invalid data the system displays error message
of action and return to step 5.
Table 10 : Use Case Description for View report

Use case name View report
Use case ID UC-6
Actors Supervisor & Manager
Precondition User must have to logged in to the system

Post condition The user leaves view report page.
Description The user view person report and house report on the data base.
Basic course of action User System

.
Step1. Users go to census homepage.
Step3. The user click view person Step 2. The system display
homepage
button menu or view house report.
Step 5.Enumerator, Supervisor views Step 4.Thesystem displays
the person or house report. the person or house report.
Step 6.use case end
Alternative course of 1A.If there is not sent to database(no report)return to

action
Step 3.
Table 11: Use Case Description for Register

Use case name Register
Use case ID UC-7
Actors Enumerator
Precondition User must have to logged in to the system

Post condition The enumerator see registration success
Description The enumerator register new person, migration, birth rate, death, marriage
And house holding.

action Step 1.click the registration page Step2: The system displays the
Step3:Fill the registration form registration form.
Step4. Click on registration button. Step 5:The system check whether the
entered value is correct or not correct
Step 6: The System display
registration is success.
Step 7: use case end.
Alternative course If the entered value is not correct

of action
1A. The Enumerator can register again or return to step 3&4.
Table 12: Use Case Description for Search person

Use case name Search
Use case ID UC-8
Actors Enumerator, Supervisor, Manager
Precondition Enumerator ,Supervisor, Manager must get search person page

Post condition Enumerator, Supervisor, Manager can get person detail information.
Description User can search person data

action Step2.the system display homepage
Step 1. Open homepage
Step3. User click on the search button Step 4.The system displays the text box
to enter data.
Step5. User enters Person ID in the
form. Step 7. The system displays searched
Step6. User searches person by clicking data.
search button.
Step8.use case end
Alternative course 1A.If user enter invalid person ID the system displays error message and go
of action to step 5.
Table 13 : Use Case Description message

Use case name Messaging
Use case ID UC-9
Actors Enumerator, Supervisor, Manager
Precondition Enumerator, Supervisor, Manager logged to the system.

Post condition Enumerator, Supervisor, Manager must communicate with each other by messaging
Description Enumerator, Supervisor, Manager must communicate by message to share

information to each other.
action
Step: 1. Open homepage Step 2.The system display
homepage
Step3.Enumerator, Supervisor, Manager select
messaging page. Step5. Display message form.
Step4.Click on message button. Step7. The system checks the

validity of the entry and then verifies
Step 6.The user inputs user name, position and
whether the user is authenticated and
send.
authorized.
Step 8. Use case end
Alternative course 1A. If the user’s entry (user name and Password) is not validated and verified the
of action system displays error message and return to step 6.
2.6.4. Class Responsibility Collaborator (CRC) Analysis

. CRC card is a collection of standard index card that has three sections: class name,
responsibility and collaboration.
 Class name indicates the name of the class the card represents.
 Responsibility refers to what a class knows and does

 Collaboration refers to interaction with other classes to fulfill the responsibility of
one class. It helps to work together or combine for the purpose of showing its
relationship.
Supervisor
Fname Message
Lname
Age
Sex
Send message()
View message()
Enumerator
ID Report
Fname
Lname
Age
Sex
Salary
View report()
Send report()
Delete report()
Administrator
ID Account
Fname
Lname
Age
Sex
Salary

Create account()
View user account()
Delete account()
Change profile()
Enumerator
ID Birth
Fname
Lname
Age
Sex
Salary
Register birth rate()
View birth rate()
Delete birth rate()
Figure 3: CRC Diagram of the system
2.6.5. Sequence Diagram

Sequence diagram show the sequence of interactions among objects and used to
represent or model the flow of messages, events and actions between the objects or
components of a system.
An important characteristic of a sequence diagram is that time passes from top to bottom
and the interaction starts near the top of the diagram and end at the bottom. Their popular
use there is to document the dynamics in an object-oriented system.

User Login Login DB
Sequence
<<Actor>> <<UI>> <<Controller>> <<Serv er>>
diagram for Login
1. Open the page
4.send input 5.check

2. Display login form
3.Enter UN&PW then

submit 6. Invalid
7. valid
8. Display login is success
Figure 4: Sequence diagram for login

User Login Create account Create Account Create Account DB
Sequence diagram
<<actor>> <<UI>> <<link>> <<UI>> <<controller>> <<server>>
for Create account
1.Login
2.Click
3.Request
4.Display Create account form
5.Fill the Create account form and click Create

button
6.Send
7 . check
8. If invalid
9.If valid-> saved
10.Display Create account is success
Figure 5: Sequence diagram for create account

User Login Update account Update Account Update Account DB
Sequence diagram
<<actor>> <<UI>> <<link>> <<UI>> <<controller>> <<serv er>>
for Update account
1.Login
2.Click
3.Request
4.Display update account form
5.Fill the update account form and click update

button
6.Send
7 . check
8. If invalid
9.If v alid-> saved
10.Display update account is success
Figure 6: Sequence diagram for update account

User Login Delete Account Delete Account Delete Account DB
Sequence diagram
for delete account
1.Login
2.Click
3.Request
4.Display delete account form
5.Fill the delete account form and click delete

button
6.Send
7 . check
8. If invalid
9.If valid-> saved
10.Display delete account is success
Figure 7: Sequence diagram of delete account

User Login Register Register Register DB
Sequence diagram
for Register
1.Login
2.Click
3.Request
4.Display Restration form
5.Fill the Restration form and submit

6.Send
7 . check
8. If invalid
9.If valid-> saved
10.Display restration is success
Figure 8: Sequence diagram for Register
Department of information technology page 37

Sequence diagram User Login Message Message Message DB
For <<actor>> <<UI>> <<link>> <<UI>> <<controller>> <<server>>
message
1.Login
2. Click
3. Request
4. Display messaging
form
5. Fill the message form and submit

6. Send
7. Check
8. If invalid
9. If valid->
Saved
10. Display message is success
Figure 9: Sequence diagram for messaging
2.6.6. Activity Diagram

Activity diagrams are typically used for business process modeling, for
modeling the logic captured by a single use case or usage scenario, or for
modeling the detailed logic of a business rule.

Open home Display login
click login link
page form
Enter UN & PW,

Submit
No
Dispaly error
Check message
Yes
Display Login
is success
Figure 10: Activity diagram for login

Open Click login link Display login
home Form
page
Enter UN & PW,
Submit
Display error
Check No Message
Yes
Click Create
Account link
Display Create
Account form
Fill the
Account form
Display error No
Message Check
Yes
Display Create
Account is success
Figure 11: Activity diagram for create account

click login link
page form
Enter UN & PW,

Submit
Dispaly error
No
Check message
Yes
Click
message link
Dispaly
messaging form
Fill the message

form
No
Dispaly error
message Check
Yes
Display message is
success
Figure 12: Activity diagram for message

click login link
page form
Enter UN & PW,

Submit
Dispaly error
No
Check message
Yes
Click V iew
account link
Dispaly V iew
account form
Search
account
No
Dispaly error
message Check
Yes
Display V iew
account is success
Figure 13: Activity diagram for view account

click login link
page form
Enter UN & PW,

Submit
Dispaly error
Check No
message
Yes
Click update
account link
Dispaly update
account form
Fill the Update

account form
No
Dispaly error
message Check
Yes
Display Update
account is success
Figure 14: Activity diagram for update account

click login link
page form
Enter UN & PW,

Submit
Dispaly error
Check No
message
Yes
Click
Registeration link
Dispaly
Registeration form
Fill
Registeration
form
No
Dispaly error
message Check
Yes
Display
Registeration is
success
Figure 15: Activity diagram for register

click login link
page form
Enter UN & PW,

Submit
Dispaly error
No
Check message
Yes
Click Report link
Dispaly Report
form
Fill Report form
No
Dispaly error
message Check
Yes
Display Report is
success
Figure 16: Activity diagram for Generate report

2.6.7. CLASS DIAGRAM
The class diagram shows a collection of classes, interfaces, associations, collaborations

and constraints. It is also known as a structural diagram.
So the purpose of the class diagram can be summarized as:
1. Analysis and design of the static view of an application.

2. Describe responsibilities of a system.
3. Base for component and deployment diagrams.

user
-userid : uint
-fname : string
-lname : string
-age : int
-sex : uint
-Address : string
+sendmessage() : string
+viewmessage() : string
+deletemessae()() : string
+login() : string
+logout() : string
Adminstrator
-has
Supervisor
Enumerator
+Createaccount() 0..1
1..* +GenerateReport()
+Deleteaccount() +Regester()
+Approve()
+Updateaccount() -has
*
+Viewaccount() 1
- * has
1..*
1..*
-has
*
-has 1..*
1 - has 1..* 1..*
1..* Marriage
Migration 1..*
+date -Date
Death -Year
+year Birth
+deathdate -Description
1 +description -birthdate
1..* +Description -Register()
-Register() -birthyear
-Register() -View()
-view() -Description
Useraccount -View() -Update()
-Delete() -Register()
-Username -Update() -Delete()
-Update()
1 -View()
-Password -Delete()
-Delete()
+Createaccount()
-Update()
+Changeaccount()
Report
-ReportID
-ReportDate 1..*
message
+Generatereport()
-messagedate : double
-messagedescrption : string
0..* -sender : string
1..*
-reciver : string
+sendmessage() : string
+recivemessage() : string
Figure 17: Class diagram
2.6.8. User Interface Design

User Interface (UI) Design focuses on anticipating what users might need to do and

ensuring that the interface has elements that are easy to access, understand, and use to
facilitate those actions. UI brings together concepts from interaction design, visual design,
and information architecture.
In this system, users will communicate with the system through the following user
interfaces.
User name:
Password: Figure 18: Login interface
Login
Figure 18: Login interface
Home page
Login
Administrator Supervisor Enumerator

Create Generat
e report Register
account
Manager
Approve
Send report
Search
Message
Message
Message
Household ID:
Person ID:
First Name:
Figure19: user interface Prototype
Middle Name:
Last Name:
Date of birth Year Month Day
Region:
Wereda:
Town:
Kebele:
Ethnic group:
Current Marital Status:
Type of Residence:
Census form
Residence Status:
Are you disabled?
Employment Status:
Sex male female
Add house information:

Add migration:
Register
Figure 20: Registration interface
CHAPTER Three
3. SYSTEM DESIGN
3.1. INTRODUCTION
The purpose of designing is to show the direction how the web page is built and to obtain clear
and enough information needed to drive the actual implementation of web page. It is based on

understanding of the model the web page built on, System design also focuses on decomposing
the system in to manageable parts. Furthermore, it supports the non-functional requirements of
the system which helps to achieve the functional requirements.[3]
The objectives of design are to model the system with high quality. The design goals are derived
from non-functional requirements that means non-functional requirement is the description of the
feature characteristics and attribute of the system as well as any constraints that may limit the
boundary of the proposed solution.
3.2. DESIGN GOAL

The goals of the design are:-
 Reduce the complexity for establishment of the new system.
 Show the best way to feasible output of the project.
 Minimize the extravagancy which is occurring due to done without design.
 Locate the necessary actor to make easy and clear system development way.
 Avoid inappropriate thing which will can be the obstacle of the new system.
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 without any impact if any change is happened.
 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.
3.3. SYSTEM DESIGN ARCHITECTURE

Web based census system is developed based on two components: the server side and the
enumerator (client) side which runs on the browser. The server is a set of applications that serve
the requests made by client. Data servers which is responsible for managing tabular data at the
server side and sending the information to the client. This system is viewed in any standard web
browser. The performance of the system is measured by the ability to respond to requests faster,
and the reliability of the system. Typically, the response to a certain query must not take longer
than 30 second. The overall system performance is dependent on the combination of browser,
server and networking performance, not the individual components, and is controlled by the
weakest component within the total solution. In this phase of the project, one server machine is
used for the functionality of the web server and data server, which are installed together. The
diagram below illustrates a general view of the system design architecture.[3]
Figure21: System architecture of secure web based census

The above system is 3-tier architecture by inserting another program at the server level. We call
this the server application. Now the client application no longer directly queries the database; it
queries the server application, which in turn queries the data server. The advantage of this
system, when the enumerator wants to register or retrieve data the following happens: The
enumerator on browser asks the web server, the web server asks the server application and the
server application queries the data server, the data server serves up a record set with all the
populations‟ data. The server application does all the processing to determine the data and serves
up the final data to the web server. The web server displays the final data information to the
enumerator. The three tiers in three-tier architecture are:
1. Web server known as Presentation Tier: it interacts closely with the user. Occupies the
top level and displays information related to services available on a website. This tier
communicates with other tiers by sending results to the client and other tiers in the
network.
2. Application server known as Application Tier: Also called the middle tier, logic tier,
business logic or logic tier, this tier is pulled from the presentation tier. It controls
application functionality by performing detailed processing.
3. Data server also known as Data Tier: This is the most critical aspect of the application;
it is where the user data, operational data and metadata are stored for easy access and
retrieval. Houses database servers where information is stored and retrieved. Data in this
tier is kept independent of application servers or business logic. Thus, a database is an
organized collection of structured data, to serve many applications with minimum
redundancy.
3.4. SUBSYSTEM DECOMPOSITION

Subsystem decomposition is undertaken to reduce the complexity of the system and gaining
insight into the identity of the constituent components. The project is decomposed in to smaller
sub-system as shown in the following figure.

census management system
administrator
supervisor enummerator manager
view report
regester generate
restor view record report
backup
delate regester
change password
enumerator enuminator
approve
enumerated
date
Figure 22: Subsystem Diagram
3.5. COMPONENT DIAGRAM

Systems may be built from components in component-based architecture. Component
diagram shows how objects (classes) in your system will grouped together and form
components. The components interact with each other either in giving service to other
components or requesting service from other component. Component diagrams are
particularly useful with larger teams

Application CMS Database
Client server server
server
manage account
Adminstrator
backup account Security
Enumerator backup person
approve Persistance infrastructure
Supervisor
regester person
System<<Database>>
Manager
messaging
view report
Generate report
Figure 23: Component diagram

3.6. DEPLOYMENT DIAGRAM
Deployment diagrams are used to describe the static deployment view of a system. In other
words, deployment diagrams show the hardware for your system, the software installed on that
hardware, and the middleware used to connect the disparate machines to one another. [7]
creat backup
chang password
administroter view report
chang password
enumerator
update census My sql

supervisor
regester
update enumerated
manager
populate census
approve enumerator
delate enumerator
assign enumerator
generate report
Figure 24: Deployment diagram

3.7. PERSISTENCE MODELING
Persistence models in our system are used to communicate the design of database. This is
basically the entity relation in database application. The system that we design overall persistent
modeling is described at class modeling part. To design the database we will use the table to
indicate what our database looks like and we define appropriate field name, data types and length
of the input, primary key, foreign key and comment. [4]
Figure 25: persistence diagram

3.8. ACCESS CONTROL SECURITY
Access to the system must be controlled by creating different authentication levels and using
password for login purposes. Any person who has the authentication to use the system has to
provide a username and password in order to perform what is supposed to do. Administrator has
a full privilege to access the whole system and has also right? other anomalies. Each user has a
security access level and each document has a sensitivity level. [5]

Table14: Describes actors are controlling access of the system.
Function User/Actor
Access Administrator Manager Enumerator Supervisor
Login Yes Yes Yes Yes

Register census No No Yes No
Delete enumerated No No Yes No
Approve enumerated No No No Yes
View census report Yes Yes Yes Yes
Change password Yes Yes No No
Add enumerator No Yes Yes Yes
Add supervisor Yes No No No
Update census Yes No No No
Give feed back No Yes Yes Yes
View feed back Yes No No No
Messaging No Yes Yes Yes
3.8.1. Boundary conditions and Exception Handling
3.8.1.1. Boundary Conditions

Here, some of the objects that act as a boundary object and exception handling mechanisms are
described.
The System is Client–Server architecture and allows a remote access. The following
requirements are mandatory on both Client and Server side.
Client slide
 Internet connection should be available on the client side
 Web browser is demanding to connect with the web server of the system
 The customer should be legitimate and having an account provided by the system
 It should give the URL (Uniform Resource Locator) address of the web site.
 The customer communicates the different hyperlinks/pages using the homepage.
 The Customer can get different service from viewing the available books up to
ordering and making payment.

Server Side
 The system administrator/Web Master initiates and updates the system using
his/her preferred privileges
 The server side should be registered on the local or any other service provider.
 It should have Internet connection and database driven-website for remote access.
 It automatically save the changes and take backups.
3.8.1.2. Exception Handling

 The system will display messages if it is tried to access using wrong/invalid account
by checking against the account table.
 It uses two hard disks in order to prevent data lose in case of system crashes.
 There will be a recovery mechanism so as to save temporary states in the case of
network link failure.
3.9. USER INTERFACE DESIGN

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that
the interface has elements that are easy to access, understand, and use to facilitate those actions.
UI brings together concepts from interaction design, visual design, and information architecture.
Interface elements include but are not limited to:
 Input Controls: buttons, text fields, checkboxes, radio buttons, dropdown lists, list
boxes, toggles, date field
 Navigational Components: slider, search field, pagination, slider, tags, icons
 Informational Components: tooltips, icons, progress bar, notifications, message boxes,
modal windows
There are times when multiple elements might be appropriate for displaying content. When this
happens, it’s important to consider the trade-offs. For example, sometimes elements that can
help save you space, put more of a burden on the user mentally by forcing them to guess what is
within the dropdown or what the element might be.
Implementations of the best practices for designing an interface include:
 Keeping the interface simple

 Creating consistency and using common UI elements.
 using color and texture
 Using typography to create hierarchy and clarity
Login interface
This is the Login page through which supervisor, administrator and enumerator login in to the
system. All users’ access is denied until he/she enters a user name, id number and password.
Login module is the first page in web based census system.
Figure26: User interface for Login

Figure27: Register census interface

Figure28: admin interface
Figure29: Add enumerator interface

CHAPTER FOUR
4. IMPLEMENTATION
4.1. INTRODUCTION
Implementation is a phase in which our design is converted into code. In this phase we mainly
focus on the implementation part. Implementation concerned with the type of material (hardware
and software )required and techniques to develop the system . Algorithm for the system ,code
sample of the system ,data preparation are briefly describe this part of our document .Coding and
implementation refers to the coding of all the design modules mentioned in the design pattern of
the system starting from requirement analysis to design phase. After the due to coding the
system will be implemented for the purpose it is designed and developed.
As we have introduced in the first chapter, for this system we used PHP for the coding part (front
end) because the system is web application. PHP is more related with web application. It
provides the right amount of flexibility and also it is simple, modern and type-safe scripting
language. And we used MYSQL as data base server to implement the system.
4.1.1. IMPLEMENTATION TOOLS

Apache is used as web server to implement the project and the following technology as front
and back end to implement the system.
Table 15: Implementation tools

Front end Back end
HTML MySQL data base engine
JavaScript PHP
CSS and related scripting language
4.2. CODING
The physical design specification created by the designers is turned in to working computer code
by the programmer. [6]
Example
Login client side script

<html>
<head>
<link href="iconic.css" media="screen" rel="stylesheet" type="text/css" />
<script src="prefix-free.js"></script>
<link href="css.cssss" rel="stylesheet" type="text/css">
<link href="styles.css" rel="stylesheet" type="text/css">
<link rel="stylesheet" href="style.css" type="text/css" media="all">
<link href="indexxx.cs.css" rel="stylesheet" type="text/css">
</head>
<script type="text/javascript">
function noBack()
window.history.forward()
noBack();
window.onload = noBack;
window.onpageshow = function(evt) { if (evt.persisted) noBack() }
window.onunload = function() { void (0) }
</script>
<div id="container">

<div class="example">
<ul id="nav">
<li class="current-menu-item"><a href="index.html"><span class="iconic

home"></span>Home</a></li>
<li><a href="#"><span class="iconic plus-alt"></span>About</a>
<li><a href="developer.php"><span class="iconic mail"></span>developer</a></li>
<li><a href="feedbackhtml.php"><span class="iconic mail"></span>Feedback</a></li>
<li><a href="help.php"><span class="iconic pencil"></span>Help</a>
</li>
<li><a href="loginhtml.php"><span class="iconic unlocked"></span>login</a></li>
</ul>
</div>
<div id="content-container1">
<div id="content-container2">
<div id="section-navigation"
<link href="style.css" rel="stylesheet" type="text/css">
</head>
<hr><br> <div id="login">
<form action="login.php" method='POST' onload="done();">
<tr>

<td colspan='2' color="white" border="0"><img src="photo/down.jpg" width="900"
height="200" valign="top" align="center"></td></tr>
<font><marquee behavior="alternate"><h1><font color="green"><font size="200">Well come

to login page</font></font></marquee></h1></center></font>
<table valign='top' width="60%" border="1" align="center">
<tr>
<tr><td width="50px" >     <font face='monotype corsiva'

size='5px'><font color="green" size="6px"></font><b> User Name:</b>
</font></td><td><input type="text" required name="username"
id="username"></td></tr><br><br>
<tr><td height="5px">       <font face='monotype

corsiva' size='5px'><font color="blue" size="6px"></font><b>Password:</b></font>
</td><td><input type="password" required name="password"
id="password"></td></tr><br><br>
<!--<tr><td
height="5px">         <font
face='monotype corsiva' size='5px'><font color="red" size="6px">@</font>Position:</font>
</td><td><select name="position" id="position"
required><option></option><option>manager</option><option>Enumerator</option><option>
supervisor</option><option>Admin</option></select></td></tr> <br>
<tr><td colspan=2>
<tr><td colspan=2>
<fieldset>
<form>
Position:  <select id="position" name="position"> <option selected

>..select..</option><option >admin</option><option >enumerator</option>

<option>Supervisor</option><option>Manager</option></select><br><br>
<button class="submit"name="submit"type="submit" onClick="done();">login</button>
</fieldset>
</form>
<?php
$conn=mysql_connect("localhost","root","");
$db1=mysql_select_db("census",$conn);
if(isset($_POST['login']))
$uname=$_POST['username'];
$password =$_POST['password'];
$position=$_POST['position'];
$query = "SELECT * FROM account WHERE username = '{$uname}' AND password =

'{$password}'AND position='{$position}'AND status='1'";
$result_set=mysql_query($query);
$row=mysql_fetch_array($result_set);
$user=$row['position'];
if(mysql_num_rows($result_set)>0)
if($user==admin)

session_start();
$_SESSION['accountid']=$row['accountid'];
echo "<script>window.location='adminpage.php';</script>";
else if($user==enumerator)
session_start();
echo "<script>window.location='populatehtml.php';</script>";
else if($user==Supervisor)
session_start();
echo "<script>window.location='adduser.php';</script>";
else if($user==Manager)
session_start();
echo "<script>window.location='adduser1.php';</script>";

}
else{
echo '<script type="text/javascript">alert(" enter correct User Name and

Password!!"); location=\'login.php\';</script>';
echo "successfully login";
mysql_close($conn);
?></body>
</html>
CHAPTER FIVE
5. TESTING, CONCLUSION AND RECOMMENDATIONS

In this project, we focus on the feature to testing, some testing techniques, testing strategies and
testing case specification system are clearly described in this part of our preparation
documentation. Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. Software testing can also
provide an objective, independent view of the software to allow the business to appreciate and
understand the risks of software implementation. Test techniques include the process of
executing a program or application with the intent of finding software bugs (errors or other
defects).
It involves the execution of a software component or system component to evaluate one or more
properties of interest. In general, these properties indicate the extent to which the component or
system under test:
 meets the requirements that guided its design and development,

 responds correctly to all kinds of inputs,
 performs its functions within an acceptable time,
 is sufficiently usable,
 can be installed and run in its intended environments and
 Achieves the general result its stakeholder’s desire.
5.1. SOFTWARE TESTING GOAL AND FUNDAMENTALS

The fundamental testing goal is to find error and that a goal test is one that has high probability
of finding an error. That is where software techniques enter the picture. These techniques provide
systematic guidance for designing test.
Software testing has three main purposes: verification, validation, and defect finding.

 The verification process confirms that the census systems meet its technical
specifications. A “specification” is a description of a function in terms of a measurable
output value given a specific input value under specific preconditions.
 The validation process confirms that the system meets the business requirements.
 A defect is a variance between the expected and actual result. The defect’s ultimate
source may be traced to a fault introduced in the specification, design, or development
(coding) phases.
5.1.1. IMPORTANCE OF TESTING
Software testing is important to find the bugs in the code. Is the instinctive response and many
people, developers and programmers included, think that that’s what debugging during
development and code reviews is for, so formal testing is redundant at best. But a “bug” is really
a problem in the code; software testing is focused on finding defects in the final product.
The value of software testing is that it goes far beyond testing the underlying code. It also
examines the functional behavior of the application. Behavior is a function of the code, but it
doesn’t always follow that if the behavior is “bad” then the code is bad. It’s entirely possible that
the code is solid but the requirements were inaccurately or incompletely collected and
communicated. It’s entirely possible that the application can be doing exactly what we’re telling
it to do but we’re not telling it to do the right thing.
5.1.2. TESTING TECHNIQUE
5.1.3. BLACK BOX TESTING

Black box testing alludes to tests that are conducted at the software interface. A black box test
examines some fundamental aspect of system with little regarded for the internal logical
structure of software.
Black box testing also called behavioral testing focuses on the functional requirement of the
software. That is black box testing enables us to drive sets of input condition that will fully
exercise all functional requirements for program.
Black box tests of attempts to find errors in the following categories:

 Incorrect or missing function
 Interface errors
 Error in data structure or external database access
 Behavior or performance error
 Initialization and termination
5.1.4. WHITE BOX TESTING

White box testing is the detailed investigation of internal logic and structure of the
code. White box testing is also called glass testing or open box testing. 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 in appropriately.
– Knowing the internal workings of a product, test that all internal operations are
performed according to specifications and all internal components have been
exercised
– Involves tests that concentrate on close examination of procedural detail
– Logical paths through the software are tested
– Test cases exercise specific sets of conditions and loops
So our team tested the web based census system according to the above and every error is
removed.
5.1.5. STRATEGIES OF TESTING

Strategies for software testing integrate software test case design methods into well-planned
series of steps that result in the successful construction of software. A software testing strategy
should be flexible enough to promote a customized testing approach.
Table 16: Describes Test Case for Login
Test type Black boxing

Test Case id 1
Test Case Name Login
Test case description To test login screen
Precondition User has username and password

Post condition User is authenticated and successfully login to the system
Test priority Medium
Specification
Input Expected output Output result Pass or fail
Valid User name and Error message Display error message Pass
Invalid password
Invalid User name Error message Display error message Pass
and
valid password
Valid User name and User page is Login Pass
valid password displayed
Empty User name Show please enter Display please fill out Pass
and valid password username this field
valid User name and Show please enter Display please fill out Pass
empty password password this field
Invalid User name Display wrong Display username or Pass
and Invalid password username and password invalid
password message message
Table 17: Test Case for Register census Interface

Test Case Number 2
Test Case Name Populate census screen
Test case description This test describes how to populate census
Precondition User has to login as enumerator
Post condition Enumerator is successfully enumerated the census
Specification
Valid or correct Display the invalid Display” success Pass
population enumeration
Empty field Display “this field is Display “this field is Pass
not be empty not be empty
‘message ‘message
Invalid person id Display” please enter Invalid Fail

valid person id
“message
Valid person id Display “please enter Valid Fails
valid person id
“message
Table18: Test case for house enumeration

Test Case Number 4
Test Case Name House enumeration screen
Test case description This test describes how to enumerate house information
Precondition User has to login as enumerator
Post condition Enumerator is successfully enumerated the house
Specification
Valid or correct house Display the invalid Display” success Pass
attribute enumeration
Empty field Display “this field is Display “success Fail
not be empty ‘message
‘message
Invalid / empty house Display” please enter Display” Pass
number valid house number please enter valid
/this field is not empty house number /this
“message field is not empty
“message
Valid house number Display “please enter Valid Pass

valid house number
“message
5.1.6. UNIT TESTING

Every module of the System is separately tested, i.e. we have tested every module by applying
some selection mechanism. Several errors were occurred during testing and we removed all the
bugs as per the specification of testing standards.
5.1.7. INTEGRATION TESTING

In this testing part, all the modules will be joined together and tested for its strength with each
other and with the systems functionality. The error occurred during integration of; the module
will be identified and removed by the project team.
5.1.8. SYSTEM TESTING

System Testing tests all components and modules that are new, changed, affected by a change, or
needed to form the complete application. The system test may require involvement of other
systems but this should be minimized as much as possible to reduce the risk of externally-
induced problems. Testing the interaction with other parts of the complete system comes in
Integration Testing. The emphasis in system testing is validating and verifying the functional
design specification and seeing how all the modules work together.
It is the final step of testing. In this the team members tested the entire system as a whole with
all forms, code, modules. In this we tested all the functionalities in the System. All errors in the
forms, functions, modules have been tested. Finally System testing ensures that the entire
integrated software system meets the desired requirements. It tests a configuration to ensure
known and predictable results.
Conclusion
The project team had implemented the secure web based census system based on
browser-structure. It is flexible, accurate and attractive with easy GUI approach.
Concussively, the issues raised in the summary of finding were being discussed in this

conclusion part. Therefore, the project team concludes that:
1. The program was complete in modular forms and in its overall status where it consists of all
the necessary features required for a system to link a system. The testes and evaluations made
show that the system is full-filled and completed.
2. The developed system can conclusively be called user friendly in which the form
developed are suitable for use by any user who will defiantly get accustomed to the
system’s environment easily.
3. The team can be also concluded that the graphical user interface is developed with all the
necessary dropdown menu and textual representation with the use of the international language
and National Languages.
4. The system is strongly secure with the use of identification user name and a password.
5. The database of the system is properly organized with fulfilled tables on their connection is
appropriately made with the right forms through the coding. All the necessary tables are created
effectively and in a sufficient manner.
5.1.9. Recommendation and future enhancement

We have developed the census management system for Dessie city, but by the shortage of
time we are not able to finish everything. So the project team recommends that any other
interested system developers can do this system in the future:
 B y generating reports by graph and percentage.
 B y including other statistical reports like death and migration.
Finally the team would like to recommend to Dessie city Statistics Agency to use this
system by knowing it to the way that it can give full web based census system.

References
[1] Census management system documents
[2] www.wdc/index.php/about-us/history-of-census, Accessed Date:-5 DEC, 2010 E.C, 9:14 PM
[3] "google.com," google, [Online]. Available: http://www.google.com/systemdesign.Accessed

Date 16:- DEC 2010 E.C].
[4] https://en.m.wikipedia.org/wiki/object-orented analysis and design, Accessed Date:-8 DEC,

2010 E.C, 11:51 AM
[5] googl.com, [Online]. Available: http://www.google.com/accesscontrol/matrix. [Accessed

Date:-12 DEC, 2010 E.C, 3:15 AM
[6] www.smallbusiness.chron.com/introduction-census-management-system-41581.html,
Accessed Date:-5 DEC, 2010 E.C, 9:33 PM
[7] Wikipedia," [Online]. Available: http://www. Wikipedia.com/deploymentdiagram Accessed

Date:-21 DEC, 2010 E.C.
[8] www.smallbusiness.chron.com/census-activities-75726.html, Accessed Date:-2 DEC, 2010

E.C, 10:12 PM

Project Chapter Summaries and System Requirements

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Chapter Summaries and System Requirements

Hochgeladen von

Copyright:

Verfügbare Formate

Contents

Department of Information Technology Page

3.4. SUBSYSTEM DECOMPOSITION...................................................................................................................................54

Department of Information TechnologyPage

3.8.1 Boundary conditions and Exception Handling...........................................................................................................59

5.1.5. STRATEGIES OF TESTING............................................................................................................................................74

Department of Information TechnologyPage

Figure 1 Essential use case diagram..................................................................................................................................18

Department of Information TechnologyPage

Table 1 Budget Schedule......................................................................................................................................................9

Department of Information TechnologyPage

1.1. Background of the project

1.2. Current System

Department of Information Technology Page

1.3. Problem Statement

Generally, the project team analyzes the following problem:

1.4. Objective the Project

1.4.1. General Objective

1.4.2. Specific Objective

1.5. Scope of the project

1.6. Limitation of the project

 Performances degrade due to ICT infrastructure limitation/bandwidth and connectivity

Department of Information TechnologyPage

1.7.1. Tangible benefits

1.7.2. Intangible benefits

1.8. System Requirements

1.8.1. Hardware requirement

1.8.2. Software requirement

Department of Information TechnologyPage

1.8.3. Programming language

1.9. Methodology of the Project

Department of Information TechnologyPage

1.9.2. Data Analysis Methodology

Department of Information TechnologyPage

1.10.1. Technical feasibility

1.10.2. Operational feasibility

Department of Information TechnologyPage

1.10.3. Economic Feasibility

1.10.4. Legal feasibility

1.11. Budget Schedule

Department of Information Technology Page 8

Hardware costs Personal computer 1 12,000 12,000

Table 1 Budget Schedule

Department of Information Technology Page 9

1.12. Work breakdown

1 proposal 11/15/2017 11/30/2017 2w 2d

Table 2 Work breakdow

Department of Information Technology Page 10

Table 3 Team members and their responsibilities

Department of Information Technology Page 11

Department of Information Technology Page 12

2.3. Practical Work of the Current System

Department of Information Technology Page 13

2.4.1. Business rules

2.5. Software Requirement Specification (SRS)

Requirement is divided into two: function requirement and non-functional requirement.

Department of Information Technology Page 14

 The system enables the enumerator to record the information person

Department of Information Technology Page 15

2.6. System Model

Department of Information Technology Page 16

2.6.2. Essential Use case diagram

Department of Information Technology Page 17