Census Management System - Documentation FINAL

______

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 by

automating the whole process, allowing the Ministry of Planning to monitor the population

statistics online. It is meant also to facilitate the management of population via the web for

enhanced management and efficiency.

1

PREFACE

This document is useful for everyone and anyone who intends to interact with a new

automated census management system. In this document one will be able to know the

problems that existed in the old system and the challenges the organization faced while using

the system.

This booklet provides extensive information on how the new system was developed and also

provides a user manual.

2

ACKNOWLEDGEMENT

This work would not be possible without the co-operation and assistance of very many

people. To them I owe my gratitude. I want to pay particular tribute to the following people.

Mr. Samuel Kiara (Supervisor Kiambaa region census) for providing all the information that

was required in order to come up with the new automated system.

Mr. Kuria for all the guidance, advice and tolerance throughout the project, also:

My lecturer: Mr. J. Alila who took the role of project supervisor

My fellow Students: Nahshon Ngao, John Kayeri and Mutinda Mummu and all my other

classmates for their useful and constructive comments on the draft of this work

My parents, for emotionally supporting me and sponsoring me financially to pursue the

course in Computer Technology and providing the stationery and other essentials needed.

I most of all I give thanks and dedicate this project to God who has helped me right from the

beginning to the completion of this project. He has guided me through the many up’s and

down’s while I went about this project and gave me hope, Patience and confidence. May his

name be Held up High!

3

DEDICATIONS

To my family: Dad, Mum and Sisters. Special thanks to them for all their support and

encouragement and for their useful and constructive comments on the draft of this work and

for all the financial support they offered me.

To the Almighty God for enabling me complete my project.

4

DECLARATION

I hereby declare that this project is my original work and has not been presented for any

award in any other institution of high learning before. Where material has been used from

other sources it has been properly acknowledged in accordance with the institute’s

regulations.

Student Signature: ……………………………………………………..

Student Name: Kenneth K. Mwiti

Project Supervisor Signature…………………………………………

Date…………………………………………………………………

5

ContentsABSTRACT................................................................................................................................2

PREFACE...................................................................................................................................3

ACKNOWLEDGEMENT..........................................................................................................4

DEDICATIONS..........................................................................................................................5

DECLARATION........................................................................................................................6

CHAPTER 1.............................................................................................................................13

1. INTRODUCTION................................................................................................................13

1.1 PROBLEM..........................................................................................................................14

1.2 PROPOSED SOLUTIONS.............................................................................................15

1.3 OBJECTIVES.................................................................................................................16

1.3.1 Personal Objectives......................................................................................................16

1.4 JUSTIFICATION...........................................................................................................16

1.5 REQUIRED RESOURCES............................................................................................17

1.5.1 Software requirements:............................................................................................17

1.5.2 Hardware requirements:...........................................................................................17

1.6 RISKS.............................................................................................................................17

1.7 INVESTIGATION PLAN..............................................................................................17

1.8 PROJECT DEVELOPMENT PLAN..............................................................................18

CHAPTER 2.............................................................................................................................19

2. LITERATURE REVIEW.....................................................................................................19

2.1 INTRODUCTION..........................................................................................................19

2.1.1 TOP IMAGE SYSTEM...........................................................................................19

2.1.2 LOCKHEED MARTIN CENSUS SYSTEMS.......................................................20

2.1.3 AUTOMATED CENSUS MAPPING SYSTEM....................................................21

2.1.4 CENSUS INFORMATION SYSTEM....................................................................22

CHAPTER 3.............................................................................................................................23

3. INTRODUCTION................................................................................................................23

3.0.1 Purpose.........................................................................................................................23

3.0.2 Project Scope...............................................................................................................23

3.0.3 Intended Audience and reading suggestions................................................................24

3.1 DATA COLLECTION METHODOLOGY...................................................................24

3.1.1 Requirements Determination...................................................................................24

3.1.2 Interviews.................................................................................................................24

3.1.3 Secondary sources....................................................................................................25

3.2 DATA ANALYSIS.........................................................................................................25

3.3 DEVELOPMENT METHODOLOGY...........................................................................25

6

3.3.0 METHODOLOGY REVIEW..................................................................................25

3.3.1 WATERFALL MODEL..............................................................................................26

3.4 GENERAL DESCRIPTION...........................................................................................27

3.4.1 Product perspective..................................................................................................27

3.4.2 Product Functionality...............................................................................................27

3.4.3 User characteristics..................................................................................................27

3.4.4 Assumptions.............................................................................................................28

3.5 SPECIFIC REQUIREMENTS........................................................................................28

3.5.1 Functional requirements:.........................................................................................28

3.5.2 Nonfunctional requirements.....................................................................................28

3.5.3 Operational Requirements.......................................................................................29

3.5.4 Training....................................................................................................................29

3.5.5 User Interface Design..............................................................................................29

3.6 SYSTEM FEATURES....................................................................................................30

3.6.1 Security....................................................................................................................30

3.6.1.1 Description and priority........................................................................................30

3.6.1.2 Stimulus/response sequences................................................................................30

3.6.1.3 Functional requirement.........................................................................................30

3.7 External Interface Requirements.....................................................................................30

3.7.1 User interface...........................................................................................................30

3.7.2 Hardware Interfaces.................................................................................................31

3.8 Software Interfaces........................................................................................................31

3.9 Communication Interfaces.............................................................................................31

3.9.1 Other Nonfunctional Requirements........................................................................31

3.9.1.1 Performance Requirement....................................................................................31

3.9.1.2 Safety Requirements.............................................................................................32

3.9.1.3 Security Requirements..........................................................................................32

3.9.2 Software Quality Attributes.....................................................................................32

1. Maintainability..............................................................................................................32

2. Reliability......................................................................................................................33

3. Documentation..............................................................................................................33

3.9.3 CONCLUSION........................................................................................................33

CHAPTER 4.............................................................................................................................34

4. INTRODUCTION................................................................................................................34

4.1.1 PURPOSE....................................................................................................................34

4.1.2 SCOPE OF THE DOCUMENT...................................................................................34

4.1.3 INTENDED AUDIENCE............................................................................................35

7

4.2 SYSTEM ENVIRONMENT..............................................................................................35

4.3 DESIGN REQUIREMENT LIST.......................................................................................35

4.4 THE SYSTEM OVERVIEW..............................................................................................36

4.4.1 DESIGN TOOLS.........................................................................................................36

4.4.1.1 HARDWARE TOOLS..........................................................................................36

4.4.1.2 SOFTWARE TOOLS...........................................................................................37

4.5 TECHNICAL CONSTRAINTS.........................................................................................37

4.6 SYSTEM ARCHITECTURE.............................................................................................38

4.6.1 Use Case Diagram........................................................................................................38

4.7 SEQUENCE DIAGRAM....................................................................................................39

4.8 ACTIVITY DIAGRAM......................................................................................................40

4.9 CLASS DIAGRAM............................................................................................................41

4.10 DATABASE DESIGN......................................................................................................42

4.10.1 SCHEMA DESIGN...................................................................................................42

4.10.2 NORMALIZATION..................................................................................................42

4.10.2 ENTITY RELATIONSHIP DIAGRAM...................................................................43

4.10.3 TABLE SCHEMA.....................................................................................................44

4.10.4 DATA DICTIONARY...............................................................................................45

4.10.5 MODELING..............................................................................................................47

4.10.5.1 INTERFACE DESIGN.......................................................................................47

4.10.6 LOGIN FORM...........................................................................................................47

4.10.7 Login fail page form..................................................................................................47

4.10.8 ENUMERATOR PAGE FORM................................................................................48

4.10.9 SUPERVISOR PAGE FORM...................................................................................49

4.10.10 Population and Housing...........................................................................................50

4.10.11 Information of Female aged 12years and above form.............................................51

4.10.12 Information of Female aged 3years and above form...............................................51

4.10.13 Housing Condition and Amenities Form.................................................................52

4.10.14 Information about hotel, prison, hospital in-patient citizens form...........................52

4.10.15 PHYSICAL DESIGN:.................................................................................................53

4.10.15.1 Software requirements..........................................................................................53

4.10.15.2 Hardware Requirements........................................................................................53

4.10.16 CONCLUSION:..........................................................................................................53

CHAPTER 5.............................................................................................................................54

5.0: SYTEM TESTING............................................................................................................54

5.1: INTRODUCTION.........................................................................................................54

5.2 Goals and objectives.......................................................................................................54

8

5.3 Statement of scope..........................................................................................................55

5.4 Major constraints............................................................................................................55

5.5 TEST PLAN....................................................................................................................56

5.5.1 Software to be tested................................................................................................56

5.5.2 Testing strategy........................................................................................................56

5.5.3 Component/unit testing............................................................................................56

5.5.4 Integration testing....................................................................................................58

5.5.5 Validation testing.....................................................................................................58

5.6 System testing.................................................................................................................60

5.6.1 Testing resources and staffing.................................................................................60

5.6.2 Test Work Products..................................................................................................60

5.7 Test Record Keeping.......................................................................................................60

5.8 Test Metrics....................................................................................................................61

5.8.1Testing tools and environment..................................................................................61

5.9 Test procedure.................................................................................................................61

5.9.1 Software to be tested................................................................................................61

5.9.2 Testing procedure.....................................................................................................62

5.9.3 Unit test cases..........................................................................................................62

5.9.3.1 Stubs and/or drivers for component: Interface Level Editor................................62

5.9.3.2 Test cases component: Interface...........................................................................62

5.9.3.3 Purpose of tests for component.............................................................................62

5.9.3.4 Expected results for component............................................................................62

5.9.3.5 Stubs and/or drivers for component: Interface Level Editor................................62

5.9.3.6 Test cases component: Database...........................................................................62

5.9.3.7 Purpose of tests for component.............................................................................62

5.9.3.8 Expected results for component............................................................................62

5.9.4 Integration testing....................................................................................................62

5.9.5 Test procedures for integration....................................................................................63

5.9.5.1 Stubs and drivers required....................................................................................63

5.9.5.2 Test cases and their purpose.................................................................................63

5.9.5.3 Expected results....................................................................................................63

5.9.6 Validation testing.........................................................................................................63

5.9.6.1 Testing procedure for validation...........................................................................63

5.9.6.2 Expected results....................................................................................................63

5.9.6.3 Pass/fail criterion for all validation tests...............................................................63

5.9.7 High order testing (System testing).............................................................................64

5.9.7.1 Recovery testing....................................................................................................64

9

5.9.7.2 Security testing......................................................................................................64

5.9.7.3 Regression testing.................................................................................................64

5.9.7.4 Stress testing.........................................................................................................65

5.9.7.5 Path Testing..........................................................................................................65

5.9.7.6 Performance testing..............................................................................................65

5.9.7.7 Alpha/beta testing.................................................................................................65

5.9.7.8 Documentation testing..........................................................................................66

5.9.7.9 Testing resources and staffing..............................................................................66

5.9.8 Test work products.......................................................................................................66

5.9.9 Test record keeping and test log..................................................................................66

5.9.10 Conclusion.................................................................................................................66

CHAPTER 6.............................................................................................................................67

6.0 IMPLEMENTATION STRATEGY...................................................................................67

6.1 Introduction.....................................................................................................................67

6.2 Purpose............................................................................................................................67

6.3 Implementation Overview..............................................................................................67

6.3.1 Installation................................................................................................................67

6.3.2 Training....................................................................................................................67

6.3.3 Execution.................................................................................................................67

6.3.4 Conversion Plan.......................................................................................................68

6.3.5 Hardware Installation...............................................................................................68

6.3.6 Software Installation................................................................................................68

6.3.7 Front-End-Implementation......................................................................................68

6.3.8 Review.....................................................................................................................68

6.3.9 Data Conversion.......................................................................................................68

6.4 Justification for the Changeover Method........................................................................68

6.4.1 Reasons for Using Parallel Changeover..................................................................69

6.5 Actual Implementation....................................................................................................69

6.6 Implementation Schedule................................................................................................70

6.7 Conclusions.....................................................................................................................71

CHAPTER 7.............................................................................................................................72

7.1 Conclusions.....................................................................................................................72

7.2 ACHIEVEMENTS.........................................................................................................72

7.3 SHORTCOMINGS.........................................................................................................72

7.4 THE WAY FORWARD.................................................................................................72

BIBLIOGRAPHY.....................................................................................................................73

APPENDICES..........................................................................................................................74

10

APPENDIX A: INTERVIEW QUESTIONS.......................................................................74

APPENDIX B: USER MANUAL........................................................................................74

1. INTRODUCTION...............................................................................................................74

1.1 Objectives:......................................................................................................................74

2.0 HARDWARE AND SOFTWARE REQUIREMENTS.....................................................74

3.0 UPLOADING FILES..........................................................................................................75

3.1 RUNNING THE APPLICATION..................................................................................75

3.2 Security Page..................................................................................................................78

3.3 Enumerator page.............................................................................................................78

3.4 Supervisor Details...........................................................................................................79

3.5 Home page......................................................................................................................79

3.6 Livestock form................................................................................................................80

3.7 Location Form.................................................................................................................80

3.8 Disability Form...............................................................................................................81

3.9 Female Aged 12 years and above Form..........................................................................81

4.0 Deaths in the Household Form.......................................................................................82

4.1 Hotel/Lodges/Hospital/Prison ResidentsForm................................................................82

4.2 Recruitment Form...........................................................................................................83

4.3 Amenities Form..............................................................................................................83

4.4 Information Regarding All Persons................................................................................84

4.5 Search form.....................................................................................................................84

5.0 APPENDIX C: CODE........................................................................................................85

11

CHAPTER 1

1. INTRODUCTION

The Kenya National Bureau of Statistics has a mandate to deliver efficient, reliable and

accurate statistics of the Country’s population. The importance of this process is to help the

Government to analyze and disseminate social economic statistics needed for planning,

allocation of resources in various constituencies within the country and policy formulation for

the country.

The Service Charter in the public declaration of the Ministry of State for Planning National

Development and vision 2030 to achieving targeted, effective and ethical results for Kenyans

in the area mandate. Through this charter it also aims to enhance the level of awareness of the

Ministry’s role in the overall facilitation and coordination of the national development

planning process within the overall structure of the Government of Kenya.

Census is the procedure of systematically acquiring and recording information

about the members of a given population. It is a regularly occurring and official count of a

particular population. The term is used mostly in connection with national 'population and

door to door censuses' (to be taken every 10 years according to United Nations

recommendations), agriculture, and business censuses.

Since late 1980’s upto early 2000, the capacity of Kenya’s National Statistical System (NSS)

to produce timely, high quality and relevant statistical information had deteriorated. Reasons

for this included declining financial outlays to produce and disseminate statistics, inadequate

professional staff at the senior management levels, and poor management. Until very recently,

surveys were conducted but not analyzed, or when analyzed, the results were not released to

the public in time.

Several statistical products such as the Economic Survey and the Statistical Abstract were

produced without release calendars, leading to delays in making information available to the

public. Production of other statistical products such as the Statistical Digest, the Annual Trade

Statistics, and the Annual Education Statistics ceased. Household surveys and industrial

production surveys were conducted sporadically, depending on the availability of donor

funding, since Government allocations to the former Central Bureau of Statistics (CBS) were

inadequate to finance them. The country’s input/output tables and the social accounting

matrix were last produced in 1976, while the system of national accounts used in the

compilation of national accounts aggregates had not been fully revised to reflect the

guidelines of the United Nations System of National Accounts 1993 (SNA93). Results of the

12

http://en.wikipedia.org/wiki/United_Nations

surveys which the CBS managed to conduct were released so late that they were often

irrelevant in an ever changing environment. The production of statistics through the routine

data systems in the line ministries also declined over time. Moreover, production of statistics

by various agencies was not well coordinated, resulting in duplication of data collection

efforts. In addition, annual symposiums for data users and producers, which used to be held in

the 1980s to ensure that data users and data producers maintained an active dialogue, were not

held.

Meanwhile, demand for statistics to benchmark and track implementation progress of national

development initiatives and programs substantially increased. The opening up of democratic

space in Kenya in the recent years, coupled with increased media freedom and coverage of

economic and social issues, raised public awareness of the value of accurate and timely

statistical information. Government has alsoincreasingly come to appreciate the usefulness of

good statistics for evidence–based policymaking in guiding major Government policies and in

monitoring development programs and the Millennium Developments Goals.

1.1 PROBLEM DEFINITION

LACK OF DATA INTEGRITY: The Census process is usually a cumbersome work

as it requires the clerks to move all over the Country into people’s homestead. The

techniques used for data collection are not always reliable as some assumptions are

made about the far unreached areas hence supplying wrong information based on this

assumption.

COST: The cost incurred during the census process generally high, has to employ

many clerks in various parts of the country with the task of collecting data and later

transfer the data into the centralized database for analysis and review.

TIME FRAME: In Kenya Census is usually conducted over a decade i.e. after every

10 years which create problems to the Ministry of planning and the Ministry of

Finance during each budget of every financial year. This is as a result of high

population growth in the country of which it may not be accounted for in the budget.

Inconvenience: The current system in many parts of the country is usually

conducted during the night with the assumption that every family member is available

at their respective houses while this is not usually the case. Also with the increase rate

of crime within the country people tend to lock out clerks who conduct census hence

they are unable to gather the required data.

13

STORAGE AND RETRIEVAL OF INFORMATION: There are

difficulties in the storage of the census forms in the current operations. The forms are

bulky and occupy much space. This makes it tedious during the process of retrieval

and analyses of data collected from the field.

MIS-PLACEMENT OF RECORDS. This problem occurs in areas where

there are security lapses. Clerks often lose the data they have collected as a result of

sabotage by criminals; this problem mostly arises because this process is often

conducted during the night when all persons are expected to be in their homestead.

PAPER WORK. There is a lot of paper work which is done right from the

estimation period of an area when a rough calculation is done till when the actual

census is carried out. This also increases the cost incurred during this process.

INADEQUATE MATERIALS AND THEIR TRANSPORTATION.

The materials required to carry out census at times are inadequate for all parts of the

country and the mode of their transportation is hindered especially in area with chaos

and instability. Economic Survey and the Statistical Abstract

were produced without release shsedules, leading to delays in making information

available to the public.

1.2 PROPOSED SOLUTIONS

Based on the above challenges the organization has decided, to implement an online census

management system. The easy to use system shall allow the Ministry to conduct the census

with ease and for a shorter period.

Its features maximizes the security of the system and the ease of use.

Features of the proposed system shall include:-

Search facility – online users shall be able to search for their details to confirm

whether they have been successively been entered in the database.

Interactivity – the applications interactive nature enables online users post their

details as required by the Ministry.

Security- the systems will enhance the security measure that only the people who

have supplied all their details e.g. valid ID Numbers are eligible to use the census

system.

Convenience- the system I intend to build will be online hence it will be accessible

24hrs a day hence people can conduct their census at their own time.

14

Reduce Costs & Increase Efficiency-the system will entirely reduce the cost of

employing many clerks at various places. Only some few IT staff will be needed to

teach or record people’s details. Also paper work will be reduced and in turn cut down

the cost of purchasing papers.

1.3 OBJECTIVES

The system should be able to provide high security and anyone who wants to access it

should have proper authorization.

The system should reduce the workload of conducting the census and hence increase

efficiency.

The system should reduce the storage requirements and be able to store all the details.

The system should be able to deal with data redundancy within the database.

To investigate the current system that is in use within the organization.

Reduce the time taken by management in coming up with concrete decisions.

Help in efficient collection, storing, processing and analysis of data for ease in

manipulation.

1.3.1 Personal Objectives

Gain knowledge.

Learn more about the commonly used data gathering methods by applying them

practically in the project.

Learn how to work with large volumes of information within a set timeline, and

analyze it.

Explore further the field of programming languages.

1.4 JUSTIFICATION

Some of the justification to carrying out the project is:

The project will enable me to use both my project management and programming

skills that I have acquired during my study.

The project will also see that misplacement of people’s records when conducting

census is totally eradicated.

15

The project will produce a system that will eliminate redundancy and enhance

efficiency.

Upon completion and implementation of the project it will enable the Supervisor to

generate a report about the census in all constituencies.

Coming up with a project is an essential requirement of Bachelors in Information

Technology and thus I would like to implement an information system to the

organization.

1.5 REQUIRED RESOURCES

1.5.1 Software requirements:

Microsoft Office 2003

Operating system (Microsoft windows XP)

Kaspersky Antivirus or an equivalent

Macromedia Dreamweaver.

My SQL

1.5.2 Hardware requirements:

Standard personal computer (Pentium IV 40GB, 512MB RAM)

Printer

3 magnetic or optical disks - used to make backup of important information in case of

any damage.

1.6 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:

1) Inadequate financial support to ensure the completion of the project.

Remedy: I have already saved up money in case of any influx on my budgeted costs.

2) Inadequate information for the available papers in the library.

Remedy: I will visit various websites which are related to my project so as to get more

detailed information.

3) Power failure:

16

Remedy: with Generators and or UPS support installed data cannot be lost through power

failure

4) Virus attacks

Remedy: Making sure that up-to-date software is installed frequently to avoid any attacks.

1.7 INVESTIGATION PLAN

I plan to investigate using the following methods.

Interviewing - I will interview the Coordinator. This will enable me to know the

requirements and if any training will be required before the system is implemented.

Document Review - This will enable me to know the current state of the learning

institution. This will be done through the reports and documentation kept.

Observation - This will help me see the problems the enumerator, supervisors are

facing. This will be done by attending one census process.

1.8 PROJECT DEVELOPMENT PLAN

Any work to be done has to have a plan in order to do the work according to a time frame,

in this case 15 weeks. Thus I have apportioned the work in manageable chunks so that I

may be able to successfully complete the project on time.

A REPRESENTATION OF THE PROJECT ON A GRATT CHART

No Activities

1. Project proposal

2. Problem definition

3. Feasibility study

4. Fact finding

5. Analysis and

design

6. Implementation

17

7. Reviewing the

system

1 2 8 9 12 13 14 15 16 17 18 19 20 22 24

TIME IN WEEKS

CHAPTER 2

2. LITERATURE REVIEW

Literature review is an evaluation report of information found in the field related to the

selected area of study. It describes, summarizes, evaluates and clarifies the kind of system that

is to be developed. The main aim of literature review is to analyze previous work done and

give new insights on better ways of producing a good census management system.

Reasons as to why literature review is carried out are:

To identify information and ideas that may be relevant to my project.

To identify methods that could be relevant to my project.

To identify gaps in previous literature reviews.

To increase knowledge in ones subject area.

2.1 INTRODUCTION

2.1.1 TOP IMAGE SYSTEM

Top image Systems has developed a software solution for capturing, processing and

validating data from all types of sources such as census forms. In this project, TiS’ solution

simplified the data capture process, reduced the dependence on manual data entry and

provided the customer with data integrity and accurate content.TiS’ fast and efficient forms

processing proved its unprecedented character recognition and error detection capabilities.

The TiS solution used powerful engines with an exclusive voting algorithm to achieve the

most accurate results.

During the project TiS’ software:

Captured all types of data, including: OMR,OCR, ICR (handwritten)

Monitored and managed the workflow in real-time, indicating any bottlenecks in the

process that allowed immediate corrective actions

Allowed the operations manager to quickly define and change the workflow

18

Enabled the setup team to easily customize new stations

Provided unique routing rules to define the flow of data

Offered a unique statistics tool that summarized information for all tasks in the

system, from recognition details to additional information on the performance of the

data entry typists

Provided one easy-to-use design tool to design all applications, workflows and

processing stations

2.1.2 LOCKHEED MARTIN CENSUS SYSTEMS

The Lockheed Martin Census Business Practice team is a premier international provider of

integrated census data collection, processing and analysis solutions. More than 10 years of

unmatched experience, resources, methods, systems and commitment ensure that our census

solutions are flexible, secure, accurate and cost effective.

Our Census Business Practice successes include the U.S. 2000 Census, the United Kingdom’s

2001 Census, and Canada’s 2006 Census, which was the first census in North America that

allowed citizens nationwide the choice to submit their census via a secure Internet solution.

The team is currently supporting the U.S. Census Bureau with the Decennial Response

Integration System for the 2010 Census.

In the United States, the Corporation supported the Census 2000 with the Data Capture

System (DCS). The U.S. Census 2000 was the largest, most sophisticated - and most accurate

- census undertaken; encompassing 120 million forms with 98 percent accuracy. It

represented the first census to use scanned optical character recognition (OCR) technology to

process the handwritten forms.

For the 2001 UK Census, Lockheed Martin’s team provided data capture and coding services,

including form printing, dress rehearsal services and census services for nearly 30 million

forms with an accuracy rate of better than 99 percent.

Lockheed Martin provided hardware and software integration for Statistics Canada’s dress

rehearsal and full 2006 census, including the first successful use of the secure Internet

channel.

In every census we support, Lockheed Martin’s team strives to:

19

http://www.lockheedmartin.com/products/DRIS/index.html

http://www.lockheedmartin.com/products/DRIS/index.html

• Provide the general public with multiple, easy-to-use and secure methods of response.

• Help census authorities collect and capture the data accurately and completely.

• Employ robust processes and tools to ensure complete protection of individuals’ personal

information.

Lockheed Martin’s Census Business Practice represents technology expertise that make

census taking highly accurate, more automated and efficient, and easier for citizens as well as

for governments to use.

Reference

(http://www.lockheedmartin.com/products/census-systems/index.html)

2.1.3 AUTOMATED CENSUS MAPPING SYSTEM

The Statistics Bureau and Statistics Center of the Management and Coordination Agency of

Japan developed an Automated Census Mapping System (CMS) by applying the Geographic

Information System technology. The geographic data of Basic Unit Block boundaries

introduced in the 1990 population census and the attribute data of population census are

registered in the database by this system, which made it possible to understand statistical

maps and distribution maps using Graphic user interface.

The population census adopts Basic Unit Blocks as the most basic small-data units, and

thereby allows the compilation of statistical and distribution maps (which show various

information such as population, number of households, population density, population

growth/decrease rate, percentage of employed persons by industry) for each prefecture or

municipality by processing data based on each Basic Unit Block. It is also possible to

demarcate Densely Inhabited Districts (DIDs) and process data for small areas such as

subdivisions by cho and aza, school districts, and divisions by health center jurisdiction or

local residents association. A wide range of applications include the tabulation of the

population and number of households in a commercial quarter within a radius of 500 m from

the station, and the calculation of population and number of riverside households, which are

prone to damages by failure of embankment, in disaster prevention efforts.

The purpose of introducing the notion of Densely Inhabited District (DID) was to reveal the

urban population based on the results of population census. In the traditional statistical

20

presentation, the terms "all shi (i.e. cities)" and "all gun (i.e. machi (towns) and mura

(villages)" were customarily used to represent urban and rural areas, respectively. However,

many towns and villages were merged under the Towns and Villages Consolidation

Promotion Law of 1953 and the New Towns and Villages Creation Promotion Law of 1956.

This resulted in the involvement of sparsely inhabited agricultural areas within the boundaries

of "all shi" that were originally meant to represent urban areas. The population density of the

"all shi" was consequently lowered, and the term "all shi" lost its original sense of urbanity. It

was then felt that the statistical data of DIDs were becoming increasingly inappropriate.

Under such circumstances, the Statistics Bureau introduced a new definition of boundaries

that would clearly represent urban areas in the 1960 population census. As a result, statistical

data that were the accurate representation of the actual state of urban population were

provided. These data are now widely used as a criterion for calculating local allocation taxes,

and as a valuable source for establishing such administrative policies as town planning,

regional development programs, urban redevelopment programs, industrial location planning,

transport planning, public health policies and crime and disaster prevention policies, as well

as being applied in diverse academic and private marketing fields.

At the operational level, however, the demarcation of DIDs took more than seven months by

manual operation. To overcome this problem, the procedures for demarcating DIDs were

redesigned by grouping a number of districts evaluated as contiguous on the basis of

population and population density (as well as household density) of a certain level.

To computerize the new demarcation procedures, experimental studies on system

development started in June 1992 based on Arc Info, and the development of a prototype

system started in February 1993 utilizing the CMS data collected in 1990. This was followed

by a series of verification studies that started in September 1993, which led to the

modification of the prototype system in September 1994. Furthermore, AML was

implemented to suit the new conditions in May 1995, for the purpose of demarcating DIDs in

the population census of the same year. Today, the results of all these efforts are realized in

the Automated Census System for Densely Inhabited District at the Statistics Bureau of the

Management and Coordination Agency of Japan.

Reference (http://proceedings.esri.com/library/userconf/proc98/proceed/to400/pap355/

p355.htm)

21

2.1.4 CENSUS INFORMATION SYSTEM

Harris Corporation has been applying decades of experience in systems engineering,

information and data processing, systems integration, and production operations for

mission critical systems to applications for the United States Census Bureau. Harris is

committed to assisting the U.S. Census Bureau in meeting its current and future strategic

goals of providing Census-related statistics with increased accuracy at a reduced cost.

Through the MAF/TIGER Accuracy Improvement Project (MTAIP), Harris has designed,

developed, and implemented an integrated production environment, and all necessary

systems to improve existing geocoded boundary data for street center-lines, lakes, rivers,

housing units, and other geographic entities to 7.6 meters of accuracy. MTAIP is a major

milestone in the partnership between the U.S. Census Bureau and Harris Corporation.

MTAIP will help ensure that Census takers can quickly and accurately arrive at the door

of the over 115 million residents across the nation.

The U.S. Census Bureau Field Data Collection Automation (FDCA) program will provide

advanced, automated systems that deliver data to the Census Bureau’s computing systems

in near real-time for integration with other data sources.

CHAPTER 3

3. INTRODUCTION

The goal and principle of the system requirement specification is to prepare the scope of the

document, the designer’s view of the client’s needs and requirements before the actual system

is designed. It serves like the evidence tool that implies both client and designer have

accepted to introduce the new system. The system is first evaluated to verify how it operates,

view the problems of the current system, its specifications and additional technological

options. Measures the weakness and strength that the system is bound to get.

3.0.1 Purpose

To determine and fully document how the system under development would work

better to support the institution needs.

22

To describe the new systems functionality and the change it’s intended to bring to the

institution as a whole.

Define all the functional and non functional requirements of the system.

Aid budget estimations for the system’s undertaking i.e. facilitate the estimation or

calculation of the necessities and this could be in terms of actual cost and time to be

taken to develop the system.

Guide in defining all the tools required for the development of the system i.e. Help in

identifying the system scope and the tools that are to be used for the system

development.

Clearly outline the roles and responsibilities of all the parties involved in the

development process of this system. (enumerators, supervisor)

3.0.2 Project Scope

The new system will allow the institution to manage its information effectively. This system

will provide a more reliable alternative to the existing system by ensuring efficient

information retrieval, secure and convenient mode of storing data and database management.

The system will be integrated in parallel with the existing system. As its services are to

enhance the existing one, it will not replace the existing one. This system requirement

document is the initial release and will only cover the requirements through preliminary

analysis of the proposed system’s features. These requirements have been developed through

intensive consultations with users and include a summary of all the necessary assumptions

and relations. The system provides ultimate protection against unauthorized access trying to

access the system which contains the organizations data by setting up logins. It will have a

large database that would provide enough space to store the people’s records gathered from

the field.

3.0.3 Intended Audience and reading suggestions.

The document is intended for the clients below:

Developers: The developers will be able to access the various features provided by the

application thus increasing the security.

Users: Users include the field clerks and the Supervisors of the system.

System Administrators: They will ensure that the system is working well and will be

responsible of managing the user’s database.

Technicians: Will have the task of troubleshooting and maintaining the system.

23

3.1 DATA COLLECTION METHODOLOGY

3.1.1 Requirements Determination

This task involves a data collection process to determine the features that must be included in

the system to satisfy business requirements. The various techniques for data collection

available include:

Interviews: A planned meeting during which the interviewer obtains information from

the interviewee.

Document review: Reviewing the existing system documentation to understand how

the system is supposed to work.

Observation: Observing the current/available system under operation to understand it

better.

The methodologies applied in this case are interviews and observation

3.1.2 Interviews

The interviews were done for the following reasons:

They allow more detailed questions to be asked

Interviews usually achieve a high response rate.

Ambiguities can be clarified and incomplete answers followed up

Precise wording can be tailored to respondent and precise meaning of questions

clarified

Interviewees are not influenced by others in the group

The persons interviewed were:

o Clerks at the field who carry out data collection.

o Supervisor at the main office who Coordinate overall supervision.

o General public so as to get their view about the process.

3.1.3 Secondary sources

1. Internet – Material provided on the Internet was used to develop a clear understanding on

the relevance of online census management over the web.

2. Books – Books, magazines and journals on Online Census Management System design

contributed to the collection of the required information.

24

3.2 DATA ANALYSIS

According to the research carried out mostly data collection tool are dealt on, which are very

useful, this was the interviewing method. With this one was able to interview almost all the

people working at the learning institution. Using the interviewee’s responses I was able to

come up with a full report, which detailed the problems, faced, non-functional requirements,

and proposed solutions to the problems etc.

Depending on the type of data in question, this might include application of statistical

methods, selecting or discarding certain subsets based on specific criteria, or other techniques.

During this process the researcher is required to involve all stakeholders who will guide him

on what is of importance and what is not, in the proposed system. The developer lists all that

is required and with this final result is what he will use to build the system.

After all data had been analyzed the users finally convinced the Coordinator that starting up

this project that would help them overcome all their problems as they had stated.

3.3 DEVELOPMENT METHODOLOGY.

3.3.0 METHODOLOGY REVIEW

A methodology is composed of one of the software development models used in conjunction

with various techniques. A methodology mainly involves both models and techniques. There

are various methodologies that can be used to develop a system. Some of the methodologies

that can be used include; prototyping, Clean room, Waterfall, Software development lifecycle,

incremental.

3.3.1 WATERFALL MODEL

The waterfall model is an approach of development that emphasizes completing a phase of the

development before proceeding to the next phase. Sometimes a need to change a particular

requirement may be identified, in order to make a change to some of the requirements a

formal change process is followed to make the change. The graphic representation of these

phase development resembles the downward flow of a waterfall. At most times it is referred

as the traditional way of developing a system.

Advantages of the waterfall model

1. It is very simple to use and implement in this project as it is suitable for small projects.

25

2. Testing is inherent to each of the phase in this model and thus eliminating mistakes in

the system developed thus reducing the cost to correct.

3. The model is rigid and each phase requires deliverables and a review immediately

helping a developer know if he or she is delivering the expected system.

Disadvantages

1. It is of high risks especially when requirements change thus leading to extreme time

consumption which may not be available in the development of this system.

2. When developing the system using this model, it is not guaranteed that one phase of

the model is perfect before one moves to the next phase and this may lead to the

system been resisted by the user.

3. It is not suitable for developing intended system as it involves review and testing after

each phase which is time consuming and may lead the project been completed late.

A diagram showing all phases in a waterfall model

3.4 GENERAL DESCRIPTION

3.4.1 Product perspective

The product is distributed but requires web server software to operate. It has two external

interfaces consisting of a configuration interface and a client interface. Both require the use of

a web-browser running on the client computer. The product is designed to run on existing

hardware software.

26

Requirement specification

Integration and maintenance

System design

Detailed design

Coding and testing

3.4.2 Product Functionality

Data Input. Data will be input directly by the system users i.e. data from both the

clients and the.

Data Processing. Data processing will be on the basis of first come first served. i.e.

the first bit of data to be entered in the system will be the first one to be processed.

Data Output. Processed data will be displayed on the screen first to view if there are

any errors that are to be removed before it may be sent to the printer incase a hard

copy is required.

Monitoring. The system will be able to monitor some destructive activities like when

deleting of any record. It will also inform the users of information such as record

updated and so on.

Control. The system will be able to provide some useful controls such as navigating

from one user to the next or previous. It will also provide the last and first options.

Any user who is to access the system will be required to log into the system using a

valid password and username.

3.4.3 User characteristics

The users of the system have different skills and some will require a lot of training to be able

to use the system comfortably. In this case, use of menus in the application system will be a

very good option so as to avoid a lot of training. In addition to menus, there will be the need

to come up with a user guide that will be able to show the instructions on what is performed in

the system.

The general characteristics of the users are:

All the users are computer literate

Users at the operational level have skills for comprehensive data capturing, data entry

and manipulation of the databases.

Users at the management level use the system to study summarized data and for

strategic decision-making.

3.4.4 Assumptions

The system assumptions that relate to the requirements here are;

27

That the sample interviewed and respondents of the questionnaires adequately

represent the entire population and that the computer systems shall fully support

the application.

That the systems are meant only for users running the windows operating systems

and the users shall keep to the domain scope and not traverse it.

The system is not supposed to exceed the stated budget since this may lead to

omission of some necessary requirements that are stated in this project.

The system will be fully integrated with the University website.

3.5 SPECIFIC REQUIREMENTS

3.5.1 Functional requirements:

The system should allow the user to view their full report.

The system should allow Clerks to update all people’s details.

The system should allow the Clerks to record people’s details.

Security should be enhanced by the system.

The system should allow the user to cancel an entry that they had previously placed.

The system should collect and store the detailed information provided by the user.

3.5.2 Nonfunctional requirements

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

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

Security: the system should provide controlled access to information while on

transmission. Only authorized users should access and modify data.

Extensibility: The system functionality should be easy to extend to include features

that will unfold in the future.

Evolution: The system should provide flexibility and production of new versions

suited for new environments and changing needs.

3.5.3 Operational Requirements

Computer with 533Mhz processor speed or above and at least 128MB memory

Windows 2000 operating systems or higher versions with a web browser (at least

Internet Explorer 6, Opera Browser 8.0, Netscape 2.1, or higher versions)

28

Database management staff.

Connection to the Internet directly or through a network.

Database management software preferably MySQL.

Phpdev 4.23

Internet Explorer 6.0 or later

Macromedia Dream weaver

3.5.4 Training

The staff will need to be equipped with the necessary skills that will enable them to

discharge their obligations according to the wishes of the clients.

3.5.5 User Interface Design

This involved designing the interface that will be used for input and output of systems data

i.e. an interface through which the user will interact with the system. Principles employed in

this section were:

User familiarity: The interface is user friendly in the sense that it uses terms and

concepts familiar to the user drawn from user’s experience.

Consistency: The interface was designed such that where possible, comparable

operations should be activated in the same way.

Recoverability: The interface was designed to include mechanisms to allow users to

recover from errors.

User guidance: The interface was designed to provide meaningful feedback when

errors occur and provide context-sensitive user help facilities.

User diversity: The interface was designed to provide appropriate interaction facilities

for different types of system users.

3.6 SYSTEM FEATURES

3.6.1 Security

3.6.1.1 Description and priority

Security of data is the major feature this system will provide. Administrator has highest

priority of access to the database thus increasing data integrity. The risk of losing data or

29

having data corrupted is very high and could cost the institution invaluable expense in data

recovery. Each user will have a unique username and password combination to allow

authenticity to the system.

3.6.1.2 Stimulus/response sequences

Integrity of data is enhanced thus information will be safe. User’s accounts will be managed

by the system administrator through the server by checking the current performance of each

user i.e. Each client’s entry.

3.6.1.3 Functional requirement

Each user have a login name and password and this information is required before the user is

allowed to access any information from the database thus integrity is enhanced. Request will

be stored in a database, which will be run by MySql.

The system shall receive requests from the users then process the data thus giving information

to the users. The system will also ensure that the data and information is safe from

unauthorized users by use of username and password.

3.7 External Interface Requirements

3.7.1 User interface

The user interface will provide usability to the user. This will be made possible by the fact

that the user access windows are limited and the use of menus. Moreover it will provide the

ability to search for reports by category for faster reference.

3.7.2 Hardware Interfaces.

Hardware contains the components that are used by the user to interact with the

system either in inputting or retrieving information.

The mouse will be used to navigate various windows/sections required by user

The keyboard will be used for data entry to the screen

The monitor will be used to show information inputted or retrieved by the user.

The database will serve as the information repository.

The central processing unit will enable control of writing to and retrieving information

30

from the database.

3.8 Software Interfaces.

The application will be communicated with the database through MySql. There will be many

forms to allow user interactivity with the system. It will provide links which will guide the

user to various pages.

3.9 Communication Interfaces.

Sharing protocols such as FTP (File Transfer Protocol) will be used to share instances of files

across the network. The system shall receive requests from the users then process the data and

information is safe from external users by use of passwords.

Data shall be received from the packets. The system shall then verify the input of user by

giving to the users certain messages. The data records shall then be stored into the database

then retrieved when required. The system shall also ensure that no resource information is

deleted maybe by negligence of users.

3.9.1 Other Nonfunctional Requirements.

3.9.1.1 Performance Requirement.

The web application will support simultaneous user access only if there are multiple

terminals.

The application shall be running on a hard disk with 160GB capacity, this is where the

database shall be located and it provides enough memory to store volumes of files and

records.

Only textual information will be handled by the software. Amount of information to

be handled can vary from user to user.

3.9.1.2 Safety Requirements

The server should be serviced regularly to ensure that it runs properly and the data saved at

consecutive intervals. Power is a significant feature and Uninterrupted Power Supply always

on standby incase power surges or blackouts that could cause fire breakages or loss of data.

31

Other risks or harm that can result from usage of the system are:

Back and neck pain and discomfort caused by maintaining an unnatural or unhealthy

posture while using the computer.

Eye strain resulting in visual fatigue, burning and watering eyes, headaches and

frequent changes in prescription glasses.

Precautions to be undertaken to avoid the problem:

Taking regular breaks from the working area.

Positioning mouse and keyboard at same level.

Adjusting your monitor brightness.

3.9.1.3 Security Requirements.

The application will ensure that only the authorized users will gain access to the resources by

the use of username and passwords. Reports will be kept secure allowing access to only

authorized users.

Measures to ensure security is enhanced:

A firewall to protect data.

Regular security tests and processes.

Implementing and maintaining an information security policy.

3.9.2 Software Quality Attributes

1. Maintainability

The system shall be able to provide room for future changes including addition of more

features, removal of some unwanted features, and should also be able to change with the new

operating systems and hardware. Changes can be made to the system in future through

upgrading, degrading, and adding more features to it. This enables its survival and reliability

in future.

2. Reliability

The system shall be available to the users at all time and it should provide the expected

results. In case of any failure, system down time should be very minimal. Backups shall also

be done on a daily basis so as to provide recovery means in case of any system failure. Having

put mechanisms in place will see to it that failure of the system is kept to the minimum.

32

3. Documentation

The system shall have its relative documentation on how to install, operate and trouble shoot

it in case of any problems. This will also assist in case new users are brought into the system

and also when programmers change.

3.9.3 CONCLUSION.

This project is aimed at developing an information system for the institution to help them in

the storage and retrieval of their data.

System Requirement Specification (SRS) helps to prepare the scope and purpose of the


is designed.

With all the information about the system having been obtained the design of the system can

now begin and the data collected will help me design a system that will run and perform the

needed tasks.

CHAPTER 4

4. INTRODUCTION

It is a description of the structure of the software to be implemented, the data which is part of

the system, the interface between system component and the algorithms used. The objective

of this document is to detail the operation of the information system. The design document

will hence help in the final design of the system. Graphical representation will be used to

create a clear understanding and expected graphical user interface.

4.1.1 PURPOSE

Systems design is the process or art of defining the architecture, components, modules,

interfaces and data for a system to satisfy specified requirements. One could see it as the

application of systems theory to product theory.

Software Design Specification Document contains design level statements regarding the

system to be developed. This document a detailed description of the systems design for the

online human population census system. i.e. the modules in the system and how they integrate

33

and relate to each other. It is going to act as a guide for the system developer for it describes

how system requirements contained in the requirement specification document are carried out

or implemented in the system. The document would also show how users would visualize the

system and detailed descriptions of the inputs, processes and anticipated outputs of specific

sub-parts of the system. System Design Specification (SDS) is a description of how the

anticipated functional and non-functional system requirements specified in the Software

Requirements Specifications (SRS) are achieved in the system. This document generally

includes the design of usecase, sequence, activity diagrams.

4.1.2 SCOPE OF THE DOCUMENT

This document explains the design structures that are used in the development of the online

human population census system. It explains level by level of how data flows throughout the

entire system. Summary of the scope of design document can be given as:-

To design the online human population census system, showing the interfaces, processes and data.

To come up with a diagrammatical representation of the system that shows how data flows from the input, how data is processed and how data flows to the output.

To come up with an attractive design to address the mission and the objectives the online human population census system.

Come up with a simple and easy way of storing data and ensuring that data security and integrity is enhanced.

Enhance easy of generating reports whenever required.

4.1.3 INTENDED AUDIENCE.

The intended audiences are the users who will be using the document for reference, it will

also be used by the system designers who might be wishing to make any changes to the

system, and the system administrators will also use it to make any updates required to ensure

that they do not lose track of the of the system performance.

34

4.2 SYSTEM ENVIRONMENT.

It is concerned with the environment where the users are exposed to no their day to day

activities. the clients will also be in a safe environment in that they can send information

through the online system about their complains and feel safe that the information which is

stored in the system will be safe in that it can be used for reference and they are confident in

that no information can be gotten lid off because the security is maintained.

The user of the system will register into the system to get authority to manipulate data

in the system.

The user will use the system for data entry so that all the surrendered information is

input to be stored in the database so that it can be used for future reference and the

information is secure from an authorized access.

The users will be able to generate any report needed during the census process.

The administrator is responsible for managing the database as well as the website.

He/she ensures that all the information is updated to the database and monitors all the

users’ performance and also ensures that there is no unauthorized access.

4.3 DESIGN REQUIREMENT LIST.

Input data: this is the data that is entered by the enumerator or supervisor in charge of

supervision.

Data requirements: this includes the population details and any other information

that is stored in the database.

User Authentication: the system shall verify the claimed identity by users who use

the system, every supervisor and enumerator who has a username and password will

have access to the system.

User Authorization: depending on the type of access, the system shall give

permissions to read, modify, delete and perform other user level tasks within the

system. The users who have higher authority will have access to more information

from the database unlike the other users.

Reports: the system shall be able to produce reports such as all the information that

has been received using the online system.

Data Organization: the system is supposed to gather the data entered into files. This

will ensure that all the information is well updated in all the required tables.

35

Information Retrieval: the system will allow users to access existing information for

modifications necessary and for general view. It will ensure updates are made so that

all those who are assessed several times, their records are clearly updated. The system

will be able to store all the data/information and their retrieval will be easy to manage.

Information Storage: the system shall consist of database which will store all details

4.4 THE SYSTEM 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 back ups are performed to

prevent data loss, to develop a more customer focused service, to improve integrity

impartiality and to improve accuracy of records kept.

4.4.1 DESIGN TOOLS

4.4.1.1 HARDWARE TOOLS

Free available space on the hard drive should be at least 500Mb

40 GB hard disk drive.

UPS for preventing loss of unsaved information during power failure.

A computer running a modern operating system.

256 MB RAM.

4.4.1.2 SOFTWARE TOOLS

Windows 2000 operating systems or higher versions with a web browser (at least

Internet Explorer 6, Opera Browser 8.0, Netscape 2.1, or higher versions)

Macromedia Dream weaver version 8.

Database management software preferably MySQL.

PHP provided under the package which comes with Apache web server.

36

4.5 TECHNICAL CONSTRAINTS

The online system was difficult to implement because the system would need to use the

language which the users can easily interact with. The file transfer process will be

cumbersome as all the previous records are all in paper files.

37

4.6 SYSTEM ARCHITECTURE

4.6.1 Use Case Diagram.

38

Senior Supervisor

Issue population and housing census forms

Allocates each supervisor his supervision area

Assign tasks to deputy supervisors

DeputySupervisor

Distribute the population and housing forms

Fill in the population details

Assigns a unique code to area of visitation

Verify the details

Return the forms to senior supervisor

Generates a final report

Enumerator

Record in database

IT Clerk

4.7 SEQUENCE DIAGRAM

: Senior supervisor : Enumerator : Deputy Supervisor : IT Clerk

7: Query ()

8: Generates

112: Records ()

113: Generates ()

39

1: Issues census forms()

6: Query for population information ()

2: Fills in details()

9:Generates a population information ()

4: Reject if incorrect()

10: Assess information()

11: Record in findings()

14: Generate overall report

15:Filling takes place()

:Database

3: Assess details 5: update()

4.8 ACTIVITY DIAGRAM.

Supervisor Enumerator IT clerk

Incorrect details

Correct details

40

Conducts Training

Assigns task to Enumerator

Determine supervision area

Issues census forms

Fills in the population details

Verify population details.

Record the population details in the database

Visit the supervision area and assign code

4.9 CLASS DIAGRAM

41

SupervisorSupervisor IDSupervisor nameAddressEmailPhone NumberEnquire ()Select area ()Train ()Register ()

Enumerator

Enumerator IDEnumerator nameAddressEmail

Enter population details ()Assigns code ()

1.........* 1.........*

1.........*

IT clerkRegistration no.NameAddress

Verify ()Send feedback ()

Census formHousehold number LocationAddressAgeReligionMarital StatusBirth PlaceOrphan hood

Issued ()Filled ()

4.10 DATABASE DESIGN

4.10.1 SCHEMA DESIGN

In relational database design, this is the process of organizing data to minimize duplication.

Normalization involves dividing a database into more tables and defining relationship

between the tables. The objective is to isolate data so that additions, deletions, and

modifications of a field can be made in just one table and then propagated through the rest of

the database via the defined relationship.

7.2 NORMALIZATION

42

UNFSUPERVISOR NAME SUPERVISOR ID F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDENUMERATOR NAME ENUMERATOR ID F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORD

Household number LocationAddressAgeReligionMarital StatusBirth PlaceOrphan hoodPrevious ResidenceDuration of residenceTribe/NationalityLivestockExotic CattleIndigenous cattleSheepGoatCamelsDonkeysPigsChickenAssetsHouseholdRadioTelevisionCarLandline

1NFSUPERVISOR ID SUPERVISOR NAME F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDENUMERATOR NAME ENUMERATOR ID F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDHousehold number LocationAddressAgeReligionMarital StatusBirth PlaceOrphan hoodPrevious ResidenceDuration of residenceTribe/NationalityLivestockExotic CattleIndigenous cattleSheepGoatCamelsDonkeysPigsChickenAssetsHouseholdRadioTelevisionCarLandline

3NFSUPERVISOR ID SUPERVISOR NAME NAME F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDENUMERATOR NAME ENUMERATOR ID F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDHousehold number LocationAddressAgeReligionMarital StatusBirth PlaceOrphan hoodPrevious ResidenceDuration of residenceTribe/NationalityLivestockExotic CattleIndigenous cattleSheepGoatCamelsDonkeysPigsChickenAssetsHouseholdRadioTelevisionCarLandline

2NF

SUPERVISOR ID SUPERVISOR NAME NAME F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDENUMERATOR NAME ENUMERATOR ID F_NAME L_NAMEADDRESSEMAILPHONE NUMBERPASSWORDHousehold number LocationAddressAgeReligionMarital StatusBirth PlaceOrphan hoodPrevious ResidenceDuration of residenceTribe/NationalityLivestockExotic CattleIndigenous cattleSheepGoatCamelsDonkeysPigsChickenAssetsHouseholdRadioTelevisionCarLandline

4.10.2 ENTITY RELATIONSHIP DIAGRAM

Key

Entity

Data Store

Data Flow

Process

43

IT clerk

System

Enumerator

4.10.3 TABLE SCHEMA

SUPERVISORField name Data type SizeSupervisor Name Varchar 20Supervisor ID Number 20First name Text 20Last name Text 20Address Int 10Email Text 20Phone No. Int 15Password Varchar 20

ENUMERATOR Field name Data type SizeEnumerator Name Varchar 20Enumerator ID Number 20First name Text 20Last name Date time 20Address Date time 10Email Text 20Phone No. Int 15Password Varchar 20

ASSETSField Name Data type SizeCar Number 20Household Number 20Radio Number 20Landline Number 20Television Number 20

HOUSEHOLDField Name Data type SizeLocation Varchar 20Address Int 20Place of birth Varchar 20Duration of residence Varchar 20Religion Varchar 20Marital status Varchar 10

LIVESTOCKField Name Data type SizeCattle Varchar 20Goat Int 20Pigs Varchar 20

44

4.10.4 DATA DICTIONARY

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

the databases:

Supervisor TableField name Description

Supervisor Name Holds the name of the Supervisor

Supervisor First Name Holds the First name of the Supervisor

Supervisor Last Name Holds other names of the Supervisor

Supervisor ID Field for identifier of the Supervisor

Address Holds the contact of the supervisor

Email Highlights the email of the supervisor

Phone No. Fields holds phone number of the supervisor

Password Indicates the password

Enumerator Table

Enumerator Name Holds the name of the Enumerator

Enumerator First Name Holds the First name of the Enumerator

Enumerator Last Name Holds other names of the Enumerator

Enumerator ID Field for identifier of the Enumerator

Address Holds the contact of the Enumerator

Email Highlights the email of the Enumerator

Phone No. Fields holds phone number of the Enumerator

45

Household details Table

Location Indicates the location for household

Address Indicates the Address for household

Age Indicates the age of residents

Religion Indicates the religion of residents

Marital Status Indicates the marital status of residents

Birth Place Indicates the birth place of residence

Orphan hood Indicates the orphan in the residence

Previous Residence Indicates the previous residence of residents

Duration of residence Indicates the location for household

Tribe/Nationality Indicates the tribe of residents

Livestock Table

Enumerator Name Field containing Enumerator Name

Cattle Indicate the number of cattle one posses

Goats Indicate the number of goats one posses

Pigs Indicate the number of pigs one posses

46

4.10.5 MODELING

4.10.5.1 INTERFACE DESIGN

The interface design has been divided into two main parts.I. Input design

II. Output design

4.10.6 LOGIN FORM

This page is loaded whenever the user clicks on the login link in the home page

Figure 1: Log in form

4.10.7 Login fail page form

47

LOGINIf you are a member please login below:

User Name:

Password:If you are not a member please register here;

Login

Your password is incorrect

If you are a member please login below:

User Name:

Password:If you are not a member please register here;

Login

Figure2: Login fail page form

4.10.8 ENUMERATOR PAGE FORM

This page is loaded whenever the Enumerator wants to become a member and he/she clicks

the register link on the website.

Figure3: Enumerator page form

48

ENUMERATOR

Please fill in the Enumerator form with all the details specified (*)

ENUMERATOR NAME:

ENUMERATOR ID:

FIRST NAME:

LAST NAME:

ADDRESS:

EMAIL:

PHONE NO:

PASSWORD:

Register Clear details

4.10.9 SUPERVISOR PAGE FORM

This page is loaded whenever the Supervisor wants to become a member and he/she clicks the

register link on the website.

Figure3: Supervisor page form

49

Supervisor

Please fill in the Supervisor form with all the details specified (*)

SUPERVISOR NAME:

SUPERVISOR ID:

FIRST NAME:

LAST NAME:

ADDRESS:

EMAIL:

PHONE NO:

PASSWORD:

Register Clear details

4.10.10 Population and Housing

This page is loaded whenever the Enumerator wants to fill in the population details and he/she

clicks Population and Housing link on the website.

Figure 4: Population and Housing

50

Population and Housing

Please fill in the Population and Housing details:

Name:

Relationship:

Sex:

Age

Name of Mother:

Usual members:

Tribe:

Religion:

Marital status:

Birth Place:

Previous residence

Duration residence

Province

District

Division

Location

Sub-Location

E.A number

E.A Type

E.A Status

Household No.

Household Type

Constituency

Structure No.

Submit Clear details

4.10.11 Information of Female aged 12years and above form

This page is loaded whenever the Enumerator clicks the female aged 12 years on the website.

Figure 5: Register page form

4.10.12 Information of Female aged 3years and above form

51

Information of Female aged 12years and above form

Please enter all details:

Children ever born alive:

Children born alive and in the household:

Children born alive and not in the household:

Children born alive but have died:

When was your last child born?

If date of birth is not known code

“99” and “9999”

Was this Birth notified?

Was the child (twin use 2?)

Is the child still alive?

SEND CLEAR DETAILS

Information of Female aged 3years and above form

Record the Observation made on the field

What is the school attendance status?

What is the highest std/form/level reached?

What is the highest std/form/level completed

Submit Clear text

4.10.13 Housing Condition and Amenities Form

This page is loaded whenever the Enumerator wants assess Enumerator clicks the Housing Condition and Amenities Form on the website.

4.10.14 Information about hotel, prison, hospital in-patient citizens form

This page is loaded whenever the Enumerator wants assess Enumerator clicks the Information about hotel, prison, hospital in-patient citizen’s form on the website.

52

Housing Condition and Amenities Form


How many dwelling units does your house has:

How many habitable rooms does this unit have?

Tenure status of main dwelling unit:

Main source of water:

Main mode of human waste disposal:

Main type of cooking fuel:

Main type of lighting fuel

Please fill in the details of household assets

Send Clear Details

Information about hotel, prison, hospital in-patient citizens


Serial Number:

Name:

Sex:

Age:

Duration of stay:

Education Level:

Home district:

Tribe:

Type of Institution:

Name of Institution:

Send Clear Text

4.10.15 PHYSICAL DESIGN:

4.10.15.1 Software requirements

Operating system(windows 2000 or a higher version)

Flash Player 8 or a higher version.

My SQL database.

Microsoft Office 2003

Macromedia Dreamweaver 8.

Kaspersky Anti-virus 7.0

4.10.15.2 Hardware Requirements

computer

Printer.

4.10.16 CONCLUSION:

This project is aimed at developing a census system for the institution to help them in the

storage and retrieval of their data of the entire country population.

System Requirement Specification (SRS) helps to prepare the scope and purpose of the


is designed.

With all the information about the system having been obtained the design of the system can

now begin and the data collected will help me design a system that will run and perform the

needed tasks.

53

CHAPTER 5

5.0: SYTEM TESTING

5.1: INTRODUCTION

It is the exhaustive and thorough process that determines whether the system produces the

desired results under known conditions. It ensures that all the errors that might bring about

problems to the system operation are debugged. It shows the testing schedule, tested items,

testing process, requirement traceability. Testing will be done to ensure that the system meet

user requirements. Testing plays the much more comprehensive role of methodically

searching for and exposing bugs, not just fixing those that show up.

The software testing activity should be documented through the following documents:

Test Plan: the present document, under the responsibility of the software infrastructure and

testing team, should keep updated and stored in the subdirectory.

Test Case Specification: a minimal and clear description of the aim of the aim of the test

should be written following the specific template. The specification should include also the

expected results and special run conditions if they are needed.

Test Log: Each nightly or pre-release build should end with a test log connected with the

release version.

Apart from the present test plan document a test deliverable is indentified which consists of:

An executable (binary or script), a set of input data (optional), a reference output for the test

validation.

A clear description (using the proposed template) of the test’s aim together with the specific

environment needs to run it.

For each test, the test case should specify the pass/fail criteria.

The deliverable must be working within the software configuration management tool,

software testing frameworks.

5.2 Goals and objectives

Software meets requirements: To demonstrate to the developer and the customer that

the software meets its requirements.

Find defect: This is the classic objective of testing. A test is run in order to trigger

failures that expose defects.

54

Maximize bug count: The distinction between this and “find defects” is that total

number of bugs is more important than coverage.

Minimize technical support costs: Working in conjunction with a technical support

or help desk group, the test team will identifies the issues that lead to calls for support.

These are often peripherally related to the product under test for example, getting the

product to work with a specific printer or to import data successfully from a third party

database might prevent more calls than a low-frequency, data corrupting crash.

Assess conformance to specification: Any claim made in the specification is

checked. Program characteristics not addressed in the specification are not (as part of

this objective) checked.

Conform to regulations: If a regulation specifies a certain type of coverage (such as,

at least one test for every claim made about the product), the team creates the

appropriate tests. If the regulation specifies a style for the specifications or other

documentation, the test team probably checks the style. In general, the test group is

focusing on anything covered by regulation nothing that is not covered by regulation.

Minimize safety-related lawsuit risk: Any error that could lead to an accident or

injury is of primary interest. Errors that lead to loss of time or data or corrupt data are

checked.

5.3 Statement of scope

A primary purpose for testing is to detect software failures so that defects may be uncovered

and corrected. Testing cannot establish that a product functions properly under all conditions,

but can only establish that it does not function properly under specific conditions. The scope

of software testing often includes examination of code as well as execution of that code in

various environments and conditions as well as examining the aspects of code: does it do what

it is supposed to do and do what it needs to do. A test plan for a development project specifies

in detail how a test strategy will be carried out for the project. It specifies

The various level of testing

Items to be tested

Order the will be tested in

The test environment

5.4 Major constraints

Some errors were not traceable using the testing tools and took time to debug them.

55

It was very hard for the third party who was there to assist to help trace the errors.

Difficult to create a summarized report for the output of the test result file.

Took time to move from one stage to another because no error would be left out

without solving it.

During integration it was hard to identify where the error occurred.

5.5 TEST PLAN

5.5.1 Software to be tested

Login mechanism using correct and incorrect logins.

An interface component which includes the level editor, database read/write and

file exporter.

System presentation facility to check that information about document is displayed

properly.

Check that the online system will clearly show all the details that the client intends

to input to the system.

5.5.2 Testing strategy

It is a plan of the overall approach in testing for the software development organization. It

specifies the level of testing as well as the method technique and tools to be used.

56

Unit test

User acceptance test

System test

Integration test

5.5.3 Component/unit testing

The different modules/component of the system shall be tested independently. During

development each module shall be tested on completion to establish if each module conforms

to its specification. Its goal is to expose faults in these components. To undergo component

testing include.

Source code: to check for programming errors and test the code modules or

functions

Username: the system prompts the user to enter the username to login to the

system.

Password: should only accept the valid password, when incorrect password is

entered display an error message.

Forms: the user can fill the forms without any problem

Tables: a single number can be entered to perform search for the particular

information.

TEST FIELD EXPECTED

OUTPUT

ACTUAL OUTPUT

UN

IT T

ES

TIN

G

USER NAME

e.g.

admin

The field should

prompt a user to

enter the correct

username to login the

system.

It was successful

PASSWORD

e.g.

lisa

The field should only

accept a valid

password.

It was successful

TEXT FIELDS

e.g. eryt56

Should accept

alphanumeric data

without returning any

errors.

It was successful

Numeric Fieldse.g. Numbers only 234567

Should only work with numeric values and never accept alphabetic. Should return an error in any attempt to do so.

It was successful

57

Required Fields e.g. ID Number

Should not allow user to proceed without data entry

It was successful

Forms The user can easily afford to fill the forms without any problem.

It was successful

5.5.4 Integration testing

It exposes defects in the interfaces and interaction between integrated components (modules).

Progressively larger groups of tested software components corresponding to elements of the

architectural design are integrated and tested until the software works as a system. During this

stage different modules of the system will be integrated and tested for compatibility. The team

will have access to the source code of the system, the source of the problem will be identified

and the component will be debugged.

5.5.5 Validation testing

It explains how test and test results will be mapped to documented system requirements. It

describes the procedure to ensure that the requirements are validated. Here test data is

indentified, what is to be tested, the expected output, the actual results after inputting the test

data, problems or failures found and suggestion or notes.

Type of Test Requirement Purpose

Test Case Expected Results

Actual Results

P/F Notes

Username & Password

Authentication & security

Login Successful login for correct username and password combination

It was successful

It worked well

Screen Design and Layout

Ease of use the web pages in the designed layout.

Layout All the web pages are in the format that the user can easily find information they need

It was successful

It worked well

Accessibility of the

Ability to access the

Accessing The website is accessible by

It was successful

It worked

58

Website website by most browsers

most types of browsers e.g. internet explorer, Opera, Netscape navigator.

well

Navigation Testing

Links to various pages

Navigation All pages are linked and there is a simple and easy way to navigate.

It was successful

It worked well

Navigation Testing

Links to various pages

Navigation All pages are linked and there is a simple and easy way to navigate.

It was successful

It worked well

Hardware Testing

Communication of the Web browser and local server

Communication The web browser and the local server should communicate effectively without any interfering problems

It was successful

It worked well

Form validation Testing

Ease of filling the forms and the functionality of data been recorded in the database

Validation Error message appear when an error process occurs.

It was successful

It worked well

Output design Testing

Ease of producing reports in a clear format

Output The reports should be easily produced as the user wants and should convey the information the user needs.

It was successful

It worked well

Database Testing

Correct storage of information

Storage The information entered by

It was successful

It worked well

59

the user should be stored correctly in the database.

5.6 System testing

It will involve integrating two or more components that implement system functions and the

testing the integrated system. It will test an increment to be delivered to the customer. The

system will be tested as a whole to ensure that it produces the expected output and conforms

to its specification.

Parties outside software will be asked to help with the final testing phase: public beta testing.

Each beta tester will be given a copy of the software. Beta tester will be expected to submit

bug reports and any opinions they may have concerning the software (especially the interface

layout).

5.6.1 Testing resources and staffing

Resources

No special resources are required beyond those already needed for development.

Staffing

Test Team Leader.

Unit Testing Coordinator.

Integration Testing Coordinator.

System Testing Coordinator.

Beta Testing Coordinator.

5.6.2 Test Work Products

Frame Rate Counter

60

In order to monitor the number of frames the engine is capable of producing per second, an

additional piece of software was developed. The frame rate counter is valuable tool in

determining system performance.

5.7 Test Record Keeping

A test log is kept to monitor the tests that have been applied. An error, or bug log is kept to

monitor any problems that have risen during testing. A beta tester report form exists to aid

beta tester in organizing their communication with the software.

5.8 Test Metrics

Function Point: This metric will be used when calculating statistics as per the complete testing

process.

Bang Point: This metric will be used to provide an indication of the number of test case

required.

Breadth of Testing: This metric provides an indication of testing completeness.

Depth of Testing: This metric provides a measure of percentage of independent basis paths

covered by the testing versus the total number of basis paths in the program.

Faults Profile: This metric is used to prioritize and categorize uncovered errors.

Frame per second: This metric is used to gauge the performance of the engine.

5.8.1Testing tools and environment

Test data files will be constructed for unit and integration testing. A frame rate counter is used

in determining program performance. There are no other special tools or hardware.

5.9 Test procedure

It is the final stage of test design and specifies the process for conducting the test cases for

each item, the input which contained one of the victim information will be entered to test the

system, and the same information will be searched via the database to check if the required

result will be displayed. The online system will also be tested by typing some

Information to the station to check if the information will be received as expected. It should

show what the system should do and what the system should not do.

61

5.9.1 Software to be tested

Interface Components to be tested

Engine Component to be tested

Installation Components to be tested

5.9.2 Testing procedure

5.9.3 Unit test cases

It will test each program separately and the team will check the output which the systems will

execute. example the case of searching for the expected output the correct information to be

searched will be keyed in to check if the executed output will be the as required by the user.

5.9.3.1 Stubs and/or drivers for component: Interface Level Editor

None

5.9.3.2 Test cases component: Interface

All editor function will be tested in a white box fashion.

5.9.3.3 Purpose of tests for component

Is to ensure correct operation of all controls in the interface, as well as verifying proper

placement of backgrounds and collision areas.

5.9.3.4 Expected results for component

The interface is expected to perform within design specifications.

5.9.3.5 Stubs and/or drivers for component: Interface Level Editor

None

5.9.3.6 Test cases component: Database

The database function will be tested in a white box fashion. A sample database will be loaded

into the database.

5.9.3.7 Purpose of tests for component

Is to ensure correct read and write operations made by the database.

5.9.3.8 Expected results for component

The database is expected to perform within design specifications.

62

5.9.4 Integration testing

It will involve building a system from its components and testing the resultant system from

the components that arises from the component interactions. It will check that all the

components will work together correctly and transfer the right data across their interface.

5.9.5 Test procedures for integration

It will involve identifying cluster of components that deliver some system

functionality.

Integrating this by adding code that makes them work together.

It will involve bottom up integration where the team will first integrate infrastructure

components that provide common service e.g. networks and database access then add

functional components

5.9.5.1 Stubs and drivers required

The object handler is used to test bed.

The data loader is used to parse information from the data files into the object handler.

5.9.5.2 Test cases and their purpose

Each object will be attached to the object handler in the order specified above.

5.9.5.3 Expected results

The system is expected to integrate without major flaws.

5.9.6 Validation testing

5.9.6.1 Testing procedure for validation

The features and functionality in the final system will be cross-referenced with the software

requirements specification document to verify that the software demonstrates conformity with

the requirements.

5.9.6.2 Expected results

The software will perform within the specifications of the software requirements document.

63

5.9.6.3 Pass/fail criterion for all validation tests

Features corresponding to the design document requirements do not need to coincide verbatim

with the requirements. Instead, it is important that they retain the spirit of the requirements.

5.9.7 High order testing (System testing)

5.9.7.1 Recovery testing

It is the activity of testing how well the application is able to recover from crashes, hardware

failures and other similar problems.

Recovery testing is the forced failure of the software in a variety of ways to verify that

recovery is properly performed. Examples of recovery testing:

1. While the application running, the team will suddenly restart the computer and after

that check the validness of application's data integrity;

2. While application receives data from the network, the team will unplug and then in

some time plug-in the cable, and analyze the application ability to continue receiving

of data from that point, when network connection disappeared;

3. The browser will be tested by restarting the system while the browser will have

definite number of sessions and after rebooting check, that it is able to recover all of

them.

5.9.7.2 Security testing

The ability of the system to resist different types of attack will be tested. This will be very

significant to the system in that it will prevent frauds where convict information can be

eliminated or distortion of information which can bring problems to the station. All the files

created should have appropriate access permissions; this will be tested by entering the wrong

username and password. The system should automatically terminate user sessions after a

period of inactivity. Strong passwords will also be used which are mixed of letters, numbers,

and punctuations.

5.9.7.3 Regression testing

After the product is released, errors maybe found or enhancements suggested by the

customers in the field. As these are corrected or implemented, the rest of the system will also

64

http://en.wikipedia.org/wiki/Web_browser

http://en.wikipedia.org/wiki/Crash_(computing)

http://en.wikipedia.org/wiki/Application_software

be tested by the team to make sure that the new details modifications will not affect the other

system code.

5.9.7.4 Stress testing

This involves designing test around the limits of the system i.e. is making demands that are

outside the demand limits of the software. E.g. the transaction process system will be

designed to handle 300 transactions per second; the operating system maybe designed to

handle 1,000 separate terminals. The stress testing continuous this test beyond the maximum

design load of the system until the system fails. It will be used for two functions;

It will test the failure behavior of the system. This may arise due to unexpected

combination of events where the load placed on the system exceeds.

It will stress the system and may cause the defects to come into light that would not

have been discovered.

5.9.7.5 Path Testing

It is a structural testing strategy where the team wants to exercise every independent

execution path through a component or program. If every independent path is executed then

all statement in the component must have been executed at least once. This will reduce the

number of errors that are likely to found in the components after they are integrated.

5.9.7.6 Performance testing

It has to be designed to ensure that the system can process its intended load. It is concerned

with both demonstrating that the system meets its requirements and discovering problems and

defects in the system. An operational profile will be constructed to where a set of tests will be

recoded to reflect the actual mix of work that will be handled by the system.

5.9.7.7 Alpha/beta testing

Alpha testing: is simulated or actual operational testing by potential users/customers

or an independent test team at the developers' site. It is often employed for off-the-

shelf software as a form of internal acceptance testing, before the software goes to beta

testing.

Beta testing: comes after alpha testing. They are released to a limited audience

outside of the programming team. The software is released to groups of people so that

65

further testing can ensure the product has few faults or bugs. It will be made available

to the open public to increase the feedback field to a maximal number of future users.

5.9.7.8 Documentation testing

The team will conduct a test to test the accuracy of the documentation. This will ensure that

no features are missing, and the contents can be understood with ease.

5.9.7.9 Testing resources and staffing

Testing Resource

No special resources are required for testing beyond those already needed for development.

Test Staff

Test Team Leader

Unit Testing Coordinator

Integration Testing Coordinator

System Testing Coordinator

Beta Testing Coordinator

5.9.8 Test work products

Frame Rate Counter

In order to monitor the number of frames the engine is capable of producing per second, an

additional piece of software was developed. The frame rate counter is a valuable tool in

determining system performance.

5.9.9 Test record keeping and test log

Test record keeping

A test log is kept to monitor the tests that have been applied. An error or a bug log is kept to

monitor any problem that has arisen during testing. Also a bête tester report form exists to

help testers in organizing their communication with the software.

5.9.10 Conclusion

The document will enhance and facilitate proper testing for the new software and will assist in

recognizing where the errors are and rectify them before the final system implementation. The

66

http://en.wikipedia.org/wiki/Feedback#In_organizations

system will demonstrate to the developer and the customer that the software meets its

requirements.

CHAPTER 6

6.0 IMPLEMENTATION STRATEGY

6.1 Introduction

This is the process of converting a system specification into an executable system. The system

has been developed to replace the old system. It is the handover of the system from development

team to the client who will make use of the system. It describes in detail the strategy to be used

during implementation and also the plan of the implementation process. The main purpose of this

document is to clearly map out how the system will be integrated into the organization to

optimize and eventually phase out its current system. It will indicate the system change over plan

as well as the actual implementation of that plan.

6.2 Purpose

The significance of implementation is to introduce the system to the organization. This will be

aimed at training the users on how to use the system. The programmers will perform their own

test at the system then the users will test the system after it passes the acceptance test then it will

be implemented.

6.3 Implementation Overview

These are the overall operations that are going to be performed during the implementation of

the system.

6.3.1 Installation

It will involve both hardware and software installation and will be carried out by the team.

6.3.2 Training

The training phase of implementation will involve introducing the staff at the organization to

the system and its functionality. The training will be delivered through workshop case study,

tutorials or practice.

67

6.3.3 Execution

It will involve the actual operation of the system in parallel with the manual system the

organization management team will perform the execution phase so that they can confirm that

the system is performing as required by the users.

6.3.4 Conversion Plan

There were various steps in the conversion plan before the commencement of the operations.

6.3.5 Hardware Installation

It will involve the purchasing of cables, computers, printers and their related accessories that

will all be set at the organization tested and certified as being operational.

6.3.6 Software Installation

It will involve the installation of operating system as stated in the requirements specification

document, the Microsoft suite and finally the newly census management system.

6.3.7 Front-End-Implementation

The front-end of this system was implemented using HTML (Hypertext Mark-up Language),

Cascading Style Sheets (CSS) and Personal Home Pages (PHP).

6.3.8 Review

During the review phase the system developer, a moderator and related stake holders who will

analyze, inspect the system, compare the manual system to the automated system and draw

conclusions on the changeover.

6.3.9 Data Conversion

This will involve changing the data from the old system to a format compatible with the new

system. Since the old system was manual this stage will thus involve copying all the data in

the manual files and keying it to the computer systems’

6.4 Justification for the Changeover Method

Parallel changeover will be used in replacing the old system with the new system. This will

involve the team groups working together during implementation to ensure that the new

system I implemented in parallel with the manual existing system. Certain modules of the new

system will be implemented over time and the old system is phased out as functions are

successfully replaced by the new system.

68

The users will be able to learn the new system step by step and still be able to carry out the

normal operations until they are comfortable with the new system. In this method the

developer will run the new automated system in parallel with the existing manual system until

there is a certainty that the new system is working correctly.

Parallel running is likely to be expensive since it involves doing the work twice for a period of

time, however it is the safest.

6.4.1 Reasons for Using Parallel Changeover

I. Continuity of organization operations: it will enable development team to curb the

errors that might arise without having to completely alter all the operations of the

organization.

II. Convenient: this is because it is not possible for the whole organization operations to

come to a halt waiting for the whole system to be implemented.

III. Time to train the users: it will be easier to train the users as the old system is running

so that some of the data is keyed in the computer during the training while other user

are using the manual system to record the data.

IV. Secure: this is because all the data that was in the old manual records will be keyed in

to the new system in the process of training the users on the operation of the new

system.

V. Capture data processing errors in the new system: it will enable the developing

team to curb errors that might arise without having to completely alter the operations

of the organization.

6.5 Actual Implementation

The following are the steps that will be performed during the actual implementation of the

system.

i. Phase 1

Acquiring and installation of required hardware.

Installation of new system to all machines

Create space for the applications and the database files on the machine.

Configuration of directories for applications

Create an administrator user account

User administrator creates list and set users access level

ii. Phase 2

69

User training and orientation

Define procedure for adding new users

Define procedures for users to get help

iii. Phase 3

Collect processing, performance and output results of the new system.

Monitor and review system performance and problems.

Compare the result of the new system with the current system.

Evaluation of both systems.

iv. Phase 4

Stopping the operation of the old system and putting the new secure

computerized information system

6.6 Implementation Schedule

Task Description Activities involved Expected start

time

Expected end

time

Task 1 Installation Installation of the required

hardware.

Installation of the required

application and system

software.

15/11/2009 15/11/2009

Task 2 Conversion File conversions Configurations of

directories for application Data entry Create an administrator

user account.

16/11/2009 16/11/2009

Task 3 Actual system

installation

The actual system

installation

18/11/2009 18/11/2009

Task 4 Training User training and

orientation

Define procedure for

adding new users

Explanation of how each

module works.

20/11/2009 20/11/2009

Task 5 Evaluation Post implementation 24/11/2009

70

evaluation.

Task 6 Maintenance System maintenance at

clients’ site.

25/11/2009

6.7 Conclusions


normal operations until they are comfortable with the new system. This will ensure that the

developer watches over the system as the users are engaging in their day to day operations to

ensure that they are comfortable with the system. The system will help the users in fast

retrieval of information and research of existence of records, security and updated records.

71

CHAPTER 7

7.1 Conclusions


normal operations until they are comfortable with the new system. This will ensure that the

developer watches over the system as the users are engaging in their day to day operations to

ensure that they are comfortable with the system. The system will help the users in fast

retrieval of information and research of existence of records, security and updated records.

7.2 ACHIEVEMENTS

By completing this project, I have been able to achieve my objectives set earlier at the

beginning. I have also learnt that census management is a very wide and important area of

concern for all learning institutions that consider their data to be of importance.

7.3 SHORTCOMINGS

Though I was able to implement the census management system to a certain acceptable level,

I still feel that more should be done to ensure both the recruitment process should be entirely

online to avoid favourism.

7.4 THE WAY FORWARD

Given more time and the proper resources (financial mostly), I wish to delve further into this

topic of census and be able to implement a top-down system that full implements census

period at levels of the organization’s processes.

72

BIBLIOGRAPHY

1) Allen, Julia H. (2001). The CERT Guide to System and Network Security Practices.

Boston, MA: Addison-Wesley. 0-201-73723-X.

2) Krutz, Ronald L.; Russell Dean Vines (2003). The CISSP Prep Guide, Gold Edition,

Indianapolis, IN: Wiley. 0-471-26802-X.

3) Layton, Timothy P. (2007). Information Security: Design, Implementation,

Measurement, and Compliance. Boca Raton, FL: Auerbach publications. 978-0-8493-

7087-8.

4) McNab, Chris (2004). Network Security Assessment. Sebastopol, CA: O'Reilly. 0-

596-00611-X.

5) Peltier, Thomas R. (2001). Information Security Risk Analysis. Boca Raton, FL:

Auerbach publications. 0-8493-0880-1.

6) Peltier, Thomas R. (2002). Information Security Policies, Procedures, and Standards:

guidelines for effective information security management. Boca Raton, FL: Auerbach

publications. 0-8493-1137-3.

7) White, Gregory (2003). All-in-one Security+ Certification Exam Guide. Emeryville,

CA: McGraw-Hill/Osborne. 0-07-222633-1.

8) http://www.e-citizen.gov.uk/NP/rr/pdf/Literature_Review_survey.pdf

9) Software Engineering by Pressman, Somerville, and Van Vliet.

10) Object-Oriented Development by Booch, Rumbaugh, Berard, and Wirfs-Brock.

11) http://www.sorwar-engine.com

12) Julie C. Melon(2003)PHP essentials, 2nd edition.

13) David Power(2005) Foundation PHP for dreamweaver8.

14) McGraw Hill(1997)Software Engineering A Practitioner’s Approach,Roger

S.pressman.

73

http://www.sorwar-engine.com/

APPENDICES

APPENDIX A: INTERVIEW QUESTIONS

The questions asked include:

What system is currently being used in carrying out the census program?

What are the shortcomings associated with the current system?

What are some of the main activities that you would like to automate?

What benefits do you expect to get from automating the activities?

What are the planned future needs in terms of embracing the new proposed

system?

Which systems use the proposed system?

The financial resources the management is willing to commit for the system

Data collection, analysis, storage and reporting techniques that is currently in use.

APPENDIX B: USER MANUAL

1. INTRODUCTION

A system user manual is a documented guide that will help the user to operate the system with

ease. The purpose of this document is to provide an interface between the system and the user.

It helps the users to understand all the procedures involved in operating the system. The

document also gives the overall details of the system

1.1 Objectives:

The documentation of how to operate the system will help the end users to learn the new

system with much ease and guide them in troubleshooting the system.

74

2.0 HARDWARE AND SOFTWARE REQUIREMENTS

The resources required for the completion of this project are: -

Hardware

Pentium IV 2.0GHZ processor

256 MB RAM

40 GB Hard Disk

Printer

Software

Phpdev 4.23

Internet Explorer 6.0 or later

Microsoft Office application package

Widows XP or Windows 200 Professional operating system

Database system preferably MySQL(XAMPP)

3.0 UPLOADING FILES

1. In the CD Open the system folder.

2. Copy the Census folder

3. Go to My Computer>Local Disk (C)xampp>htdocs

4. Paste your folder in the htdocs folder.

5. Copy database folder.

6. Go to My Computer>Local Disk (C)xampp>mysql>data

7. Paste your database in the data folder

3.1 RUNNING THE APPLICATION

1. Run the xampp-win32-1.6.3a-installer in the folder system>select the default language English.

2. Make sure your Web server is running - its status can be checked by looking at the system tray icons for Apache server and making sure that it is running. This automatically implies that you can run this system.

3. Open your browser and type in “http://localhost/xampp/”

4. Xampp for windows webpage will be displayed.

75

5. Select phpMyAdmin under the tools option to establish the connection.

6. PhpMyAdmin webpage displays

76

7. Select the database option.

8. The following window display

9. Open the system folder>home.php.>on the right hand side click on Application

tab>then database>click on the (+) sign>mySql>to connect.

The following window displays

77

3.2 Security Page

This page loads which prompt user to enter his/her username and password or register with the system.

3.3 Enumerator page

This page loads when an enumerator wants to register with the system

78

3.4 Supervisor Details

This page loads when the supervisor wants to register with the system

3.5 Home page

This page loads when the supervisor or the enumerator logs in successfully

79

3.6 Livestock form

When one clicks the livestock link this page will display

3.7 Location Form

When one clicks the location link this page will display

80

3.8 Disability Form

When one clicks the Disability link this page will display

3.9 Female Aged 12 years and above Form

When one clicks the Female Aged 12 years and above Form link this page will display

81

4.0 Deaths in the Household Form

When one clicks the Deaths in the Household Form link this page will display

4.1 Hotel/Lodges/Hospital/Prison Residents Form

When one clicks the Deaths in the Household Form link this page will display

82

4.2 Recruitment Form

When one clicks the Recruitment Form link this page will display

4.3 Amenities Form

When one click the Deaths in the Amenities Form link this page will display

83

4.4 Information Regarding All Persons

When one clicks the Information Regarding All Persons Form link this page will display

4.5 Search form

When one clicks the Search link on the home page this page will display

84

5.0 APPENDIX C: CODE

Login Page

<?php require_once('Connections/censusconnect.php'); ?>

<?php

// *** Validate request to login to this site.

session_start();

$loginFormAction = $_SERVER['PHP_SELF'];

if (isset($accesscheck)) {

$GLOBALS['PrevUrl'] = $accesscheck;

session_register('PrevUrl');

}

if (isset($_POST['textfield'])) {

$loginUsername=$_POST['textfield'];

$password=$_POST['textfield'];

$MM_fldUserAuthorization = "";

$MM_redirectLoginSuccess = "home.php";

$MM_redirectLoginFailed = "account.php";

$MM_redirecttoReferrer = false;

mysql_select_db($database_censusconnect, $censusconnect);

$LoginRS__query=sprintf("SELECT Username, password FROM account WHERE

Username='%s' AND password='%s'",

get_magic_quotes_gpc() ? $loginUsername : addslashes($loginUsername),

get_magic_quotes_gpc() ? $password : addslashes($password));

$LoginRS = mysql_query($LoginRS__query, $censusconnect) or die(mysql_error());

$loginFoundUser = mysql_num_rows($LoginRS);

if ($loginFoundUser) {

$loginStrGroup = "";

//declare two session variables and assign them

85

$GLOBALS['MM_Username'] = $loginUsername;

$GLOBALS['MM_UserGroup'] = $loginStrGroup;

//register the session variables

session_register("MM_Username");

session_register("MM_UserGroup");

if (isset($_SESSION['PrevUrl']) && false) {

$MM_redirectLoginSuccess = $_SESSION['PrevUrl'];

}

header("Location: " . $MM_redirectLoginSuccess );

}

else {

header("Location: ". $MM_redirectLoginFailed );

}

}

?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<title>Untitled Document</title>

<style type="text/css">



</style>

</head>

86

<body>

<p align="right">KNBS</p>

<form name="form1" method="POST" action="<?php echo $loginFormAction; ?>">

<p align="center" class="style1"><strong>Republic of Kenya </strong></p>

<p align="center" class="style1"><strong>Population and Housing Census </strong></p>

<p align="center" class="style1"><strong>Please enter your details below:</strong></p>

<p align="center">Username:

<input type="text" name="textfield">

</p>

<p align="center">passward:

<input type="password" name="textfield">

</p>

<p align="center" class="style2">

<input type="submit" name="Submit" value="login">

<input type="reset" name="Reset" value="Reset">

</p>

<p align="center" class="style2">if you are unregistered please enter the following

information:</p>

<p align="center" class="style2">For <a href="supervisor.php">Supervisor</a></p>

<p align="center" class="style2">For <a href="enumerator.php">Enumerator</a> </p>

</form>

<p align="center" class="style1"> </p>

</body>

</html>

Home Page Form



<html>

<head>






</style>

</head>

<body>

<form name="form1" method="post" action="">

<p align="right" class="style1">KNBS</p>

<p align="center" class="style1"><strong><img src="MTP2008_2012cOVER.jpg"

width="100" height="120" align="left">Republic of Kenya </strong></p>

<p align="center" class="style1"><strong>Population and Housing Census</strong></p>

<table width="200" height="414" border="1" align="left">

<tr>

<td><a href="amenities.php">AMENETIES</a></td>

</tr>

<tr>

<td><a href="assets.php">ASSETS</a></td>

</tr>

<tr>

<td><a href="education.php">EDUCATION</a></td>

</tr>

<tr>

<td><a href="females.php">FEMALES</a></td>

</tr>

<tr>

<td><a href="all%20person.php">GENERAL INFORMATION</a> </td>

</tr>

<tr>

88

<td><a href="disability.php">DISABILITY</a></td>

</tr>

<tr>

<td><a href="ict.php">ICT</a></td>

</tr>

<tr>

<td><a href="labour.php">LABOUR</a></td>

</tr>

<tr>

<td><a href="livestock.php">LIVESTOCK</a></td>

</tr>

<tr>

<td><a href="orphanhood.php">ORPHANHOOD</a></td>

</tr>

<tr>

<td><a href="outdoors.php">OUTDOORS</a></td>

</tr>

<tr>

<td><a href="location.php">KNBS</a></td>

</tr>

<tr>

<td><a href="recruitment.php">RECRUITMENT</a></td>

</tr>

</table>

<p align="center" class="style1"><span class="style2"><strong><a

href="account.php"><img src="email.gif" width="55" height="60"

align="baseline"></a></strong></span></p>

<p align="center" class="style1"><span class="style2"><strong>VISION</strong><br>

<br>

National Development Planning to Create a Better Quality of Life for all Kenyans

</span></p>

<p align="center" class="style2"><strong> MISSION</strong><br>

<br>

To provide leadership in policy formulation, provision of quality information and </p>

89

<p align="center" class="style2"> statistical data and co-ordinating sound economic policies

for sustainable development.<br>

<br>

<strong>GOAL</strong><br>

<br>

Enhanced capacity in national planning and policy management for improved living

standards of Kenyans </p>

<p align="center" class="style2"> Our Core Functions </p>

<div align="center">

<table cellpadding="0">

<tr>

<td width="742" valign="top" class="style2"><ul>

<li> The coordination of government economic policies, including regional and

international cooperation policies; </li>

<li><br>

The coordination and preparation of the planning components of the Medium Term

Expenditure Framework(MTEF); the Fiscal Strategy Paper and the requisite budget

documents; </li>

<li><br>

The provision of leadership and coordination in the preparation of the main National

Development Plan documents, including the District Development Plans; National

Development Plans, and specific socio-economic programmes and plans; </li>

<li><br>

The coordination and management of population, economic and national statistical

services within government; and </li>

<li><br>

The Coordination and provision of leadership in the national Monitoring and

Evaluation (M&E) framework. </li>

</ul>

<table cellpadding="0">

<tr>

<td></td>

</tr>

</table></td>

90

</tr>

</table>

</div>

<p align="center"><a href="account.php">LOG OUT</a> </p>

</form>

</body>

</html>

Assets Page Form


<?php

function GetSQLValueString($theValue, $theType, $theDefinedValue = "",

$theNotDefinedValue = "")

{

$theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue;

switch ($theType) {

case "text":

$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";

break;

case "long":

case "int":

$theValue = ($theValue != "") ? intval($theValue) : "NULL";

break;

case "double":

$theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL";

break;

case "date":


break;

case "defined":

$theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue;

break;

}

91

return $theValue;

}

$editFormAction = $_SERVER['PHP_SELF'];

if (isset($_SERVER['QUERY_STRING'])) {

$editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']);

}

if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] == "form2")) {

$insertSQL = sprintf("INSERT INTO assets (Radio, TV, Phone, Landline, Computer,

Bicycle, `Motor Cycle`, Car, Lorry, Refrigerator, Boat, Cart, Canoes, `Tuk tuk`) VALUES

(%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)",

GetSQLValueString($_POST['Radio'], "int"),

GetSQLValueString($_POST['TV'], "int"),

GetSQLValueString($_POST['Phone'], "int"),

GetSQLValueString($_POST['Landline'], "int"),

GetSQLValueString($_POST['Computer'], "int"),

GetSQLValueString($_POST['Bicycle'], "int"),

GetSQLValueString($_POST['Motor_Cycle'], "int"),

GetSQLValueString($_POST['Car'], "int"),

GetSQLValueString($_POST['Lorry'], "int"),

GetSQLValueString($_POST['Refrigerator'], "int"),

GetSQLValueString($_POST['Boat'], "int"),

GetSQLValueString($_POST['Cart'], "int"),

GetSQLValueString($_POST['Canoes'], "int"),

GetSQLValueString($_POST['Tuk_tuk'], "int"));


$Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error());

$insertGoTo = "home.php";


$insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?";

$insertGoTo .= $_SERVER['QUERY_STRING'];

92

}

header(sprintf("Location: %s", $insertGoTo));

}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the Household Assets

Form:</strong></p>

</form>

<form method="post" name="form2" action="<?php echo $editFormAction; ?>">

<table align="center">

<tr valign="baseline">

<td nowrap align="right">Radio:</td>

<td><input type="text" name="Radio" value="" size="32"></td>

93

</tr>


<td nowrap align="right">TV:</td>

<td><input type="text" name="TV" value="" size="32"></td>

</tr>


<td nowrap align="right">Phone:</td>

<td><input type="text" name="Phone" value="" size="32"></td>

</tr>


<td nowrap align="right">Landline:</td>

<td><input type="text" name="Landline" value="" size="32"></td>

</tr>


<td nowrap align="right">Computer:</td>

<td><input type="text" name="Computer" value="" size="32"></td>

</tr>


<td nowrap align="right">Bicycle:</td>

<td><input type="text" name="Bicycle" value="" size="32"></td>

</tr>


<td nowrap align="right">Motor Cycle:</td>

<td><input type="text" name="Motor_Cycle" value="" size="32"></td>

</tr>


<td nowrap align="right">Car:</td>

<td><input type="text" name="Car" value="" size="32"></td>

</tr>


<td nowrap align="right">Lorry:</td>

<td><input type="text" name="Lorry" value="" size="32"></td>

</tr>


94

<td nowrap align="right">Refrigerator:</td>

<td><input type="text" name="Refrigerator" value="" size="32"></td>

</tr>


<td nowrap align="right">Boat:</td>

<td><input type="text" name="Boat" value="" size="32"></td>

</tr>


<td nowrap align="right">Cart:</td>

<td><input type="text" name="Cart" value="" size="32"></td>

</tr>


<td nowrap align="right">Canoes:</td>

<td><input type="text" name="Canoes" value="" size="32"></td>

</tr>


<td nowrap align="right">Tuk tuk:</td>

<td><input type="text" name="Tuk_tuk" value="" size="32"></td>

</tr>


<td nowrap align="right"> </td>

<td><input type="submit" value="Insert record">

<input type="reset" name="Reset" value="Reset"></td>

</tr>

</table>

<input type="hidden" name="MM_insert" value="form2">

</form>

<p> </p>

</body>

</html>

Search page Form


<?php

$colname_Recordset1 = "1";

95

if (isset($_POST['name'])) {

$colname_Recordset1 = (get_magic_quotes_gpc()) ? $_POST['name'] :

addslashes($_POST['name']);

}


$query_Recordset1 = sprintf("SELECT * FROM information WHERE name = '%s'",

$colname_Recordset1);

$Recordset1 = mysql_query($query_Recordset1, $censusconnect) or die(mysql_error());

$row_Recordset1 = mysql_fetch_assoc($Recordset1);

$totalRows_Recordset1 = mysql_num_rows($Recordset1);

?>



<html>

<head>






</style><head>



<p align="center" class="style1"><strong>Population and Housing Census Search Details

</strong></p></head>

<body>

<table width="996" height="223" border="1">

<tr>

<th scope="col">Name</th>

<th scope="col"> </th>


96











</tr>

<?php do { ?>

<tr>

<td><?php echo $row_Recordset1['name']; ?></td>

<td><?php echo $row_Recordset1['Relationship']; ?></td>

<td><?php echo $row_Recordset1['sex']; ?></td>

<td><?php echo $row_Recordset1['Age']; ?></td>

<td><?php echo $row_Recordset1['No. of Mother']; ?></td>

<td><?php echo $row_Recordset1['Household No']; ?></td>

<td><?php echo $row_Recordset1['Nationality']; ?></td>

<td><?php echo $row_Recordset1['Religion']; ?></td>

<td><?php echo $row_Recordset1['Marital Status']; ?></td>

<td><?php echo $row_Recordset1['Previous Residence']; ?></td>

<td><?php echo $row_Recordset1['Duration of residence']; ?></td>

<td><?php echo $row_Recordset1['is father alive']; ?></td>

<td><?php echo $row_Recordset1['is mother alive']; ?></td>

</tr>

<?php } while ($row_Recordset1 = mysql_fetch_assoc($Recordset1)); ?>

</table>

</body>

</html>

<?php

mysql_free_result($Recordset1);

?>

97

Supervisor Form


<?php



{


switch ($theType) {

case "text":


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

}

return $theValue;

}




}

98


$insertSQL = sprintf("INSERT INTO supervisor (Name, Fname, Lname, id, Address, Email,

password) VALUES (%s, %s, %s, %s, %s, %s, %s)",

GetSQLValueString($_POST['Name'], "text"),

GetSQLValueString($_POST['Fname'], "text"),

GetSQLValueString($_POST['Lname'], "text"),

GetSQLValueString($_POST['id'], "int"),

GetSQLValueString($_POST['Address'], "int"),

GetSQLValueString($_POST['Email'], "text"),

GetSQLValueString($_POST['Phone_no'], "int"));



$insertGoTo = "account.php";




}


}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the Supervisors

Details:</strong></p>

</form>




<td nowrap align="right">Name:</td>

<td><input type="text" name="Name" value="" size="32"></td>

</tr>


<td nowrap align="right">Fname:</td>

<td><input type="text" name="Fname" value="" size="32"></td>

</tr>


<td nowrap align="right">Lname:</td>

<td><input type="text" name="Lname" value="" size="32"></td>

</tr>


<td nowrap align="right">Id:</td>

<td><input type="text" name="id" value="" size="32"></td>

</tr>


<td nowrap align="right">Address:</td>

<td><input type="text" name="Address" value="" size="32"></td>

100

</tr>


<td nowrap align="right">Email:</td>

<td><input type="text" name="Email" value="" size="32"></td>

</tr>


<td nowrap align="right">Phone no.:</td>

<td><input type="text" name="Phone_no" value="" size="32"></td>

</tr>


<td nowrap align="right">Password:</td>

<td><input type="text" name="password" value="" size="32"></td>

</tr>




<input type="reset" name="Reset" value="Clear"></td>

</tr>

</table>


</form>

<p> </p>

</body>

</html>

Enumerator Form


<?php



{


switch ($theType) {

case "text":

101


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

}

return $theValue;

}




}


$insertSQL = sprintf("INSERT INTO enumerator (Name, Fname, Lname, id, Email,

password) VALUES (%s, %s, %s, %s, %s, %s)",

GetSQLValueString($_POST['Name'], "text"),

GetSQLValueString($_POST['Fname'], "text"),

GetSQLValueString($_POST['Lname'], "text"),

GetSQLValueString($_POST['id'], "int"),

GetSQLValueString($_POST['Email'], "text"),

GetSQLValueString($_POST['password'], "text"));

102



$insertGoTo = "account.php";




}


}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the Enumerators


103

</form>





<td><input type="text" name="Name" value="" size="32"></td>

</tr>


<td nowrap align="right">Fname:</td>

<td><input type="text" name="Fname" value="" size="32"></td>

</tr>


<td nowrap align="right">Lname:</td>

<td><input type="text" name="Lname" value="" size="32"></td>

</tr>


<td nowrap align="right">Id:</td>

<td><input type="text" name="id" value="" size="32"></td>

</tr>


<td nowrap align="right">Email:</td>

<td><input type="text" name="Email" value="" size="32"></td>

</tr>


<td nowrap align="right">Password:</td>

<td><input type="text" name="password" value="" size="32"></td>

</tr>


<td nowrap align="right">Phone no.:</td>

<td><input type="text" name="Phone_no" value="" size="32"></td>

</tr>



104



</tr>

</table>


</form>

<p> </p>

</body>

</html>

Orphanhood Page


<?php



{


switch ($theType) {

case "text":


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

105

}

return $theValue;

}




}


$insertSQL = sprintf("INSERT INTO orphanhhod (`How many live birth occured in this

household during dates state`, `how many deaths occured in this household between stated

dates`, `Name of the household member who died`, `Was this death notified`, `How old was

the person`, male/female) VALUES (%s, %s, %s, %s, %s, %s)",

GetSQLValueString($_POST['How_many_live_birth_occured_in_this_household_during_da

tes_state'], "int"),

GetSQLValueString($_POST['how_many_deaths_occured_in_this_household_between_state

d_dates'], "int"),

GetSQLValueString($_POST['Name_of_the_household_member_who_died'],

"int"),

GetSQLValueString($_POST['Was_this_death_notified'], "int"),

GetSQLValueString($_POST['How_old_was_the_person'], "int"),

GetSQLValueString($_POST['malefemale'], "int"));







}

106


}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the information About Deaths in the

Household Form:</strong></p>

</form>




<td nowrap align="right">How many live birth occured in this household during dates

state:</td>

107

<td><input type="text"

name="How_many_live_birth_occured_in_this_household_during_dates_state" value=""

size="32"></td>

</tr>


<td nowrap align="right">How many deaths occured in this household between stated

dates:</td>

<td><input type="text"

name="how_many_deaths_occured_in_this_household_between_stated_dates" value=""

size="32"></td>

</tr>


<td nowrap align="right">Name of the household member who died:</td>

<td><input type="text" name="Name_of_the_household_member_who_died" value=""

size="32"></td>

</tr>


<td nowrap align="right">Was this death notified:</td>

<td><input type="text" name="Was_this_death_notified" value="" size="32"></td>

</tr>


<td nowrap align="right">How old was the person:</td>

<td><input type="text" name="How_old_was_the_person" value="" size="32"></td>

</tr>


<td nowrap align="right">Male/female:</td>

<td><input type="text" name="malefemale" value="" size="32"></td>

</tr>





</tr>

</table>

108


</form>

<p> </p>

</body>

</html>

Livestock page form


<?php



{


switch ($theType) {

case "text":


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

}

return $theValue;

}

109




}


$insertSQL = sprintf("INSERT INTO livestock (Èxotic Cattle`, Ìndigenous cattle`, Sheep,

Goat, Camels, Pigs, Ìndigenous chicken`, `Chicken commercial`, `Bee Hives`, Other)

VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s)",

GetSQLValueString($_POST['Exotic_Cattle'], "int"),

GetSQLValueString($_POST['Indigenous_cattle'], "int"),

GetSQLValueString($_POST['Sheep'], "int"),

GetSQLValueString($_POST['Goat'], "int"),

GetSQLValueString($_POST['Camels'], "int"),

GetSQLValueString($_POST['Pigs'], "int"),

GetSQLValueString($_POST['Indigenous_chicken'], "int"),

GetSQLValueString($_POST['Chicken_commercial'], "int"),

GetSQLValueString($_POST['Bee_Hives'], "int"),

GetSQLValueString($_POST['Other'], "int"));







}


}

?>



<html>

110

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the Livestock


</form>




<td nowrap align="right">Exotic Cattle:</td>

<td><input type="text" name="Exotic_Cattle" value="" size="32"></td>

</tr>


<td nowrap align="right">Indigenous cattle:</td>

<td><input type="text" name="Indigenous_cattle" value="" size="32"></td>

</tr>


<td nowrap align="right">Sheep:</td>

111

<td><input type="text" name="Sheep" value="" size="32"></td>

</tr>


<td nowrap align="right">Goat:</td>

<td><input type="text" name="Goat" value="" size="32"></td>

</tr>


<td nowrap align="right">Camels:</td>

<td><input type="text" name="Camels" value="" size="32"></td>

</tr>


<td nowrap align="right">Pigs:</td>

<td><input type="text" name="Pigs" value="" size="32"></td>

</tr>


<td nowrap align="right">Indigenous chicken:</td>

<td><input type="text" name="Indigenous_chicken" value="" size="32"></td>

</tr>


<td nowrap align="right">Chicken commercial:</td>

<td><input type="text" name="Chicken_commercial" value="" size="32"></td>

</tr>


<td nowrap align="right">Bee Hives:</td>

<td><input type="text" name="Bee_Hives" value="" size="32"></td>

</tr>


<td nowrap align="right">Other:</td>

<td><input type="text" name="Other" value="" size="32"></td>

</tr>



<td><input type="submit" value="Insert record"> <input type="reset" name="Reset"

value="Clear"></td>

112

</tr>

</table>


</form>

<p> </p>

</body>

</html>

Persons with disability form


<?php



{


switch ($theType) {

case "text":


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

}

return $theValue;

113

}




}


$insertSQL = sprintf("INSERT INTO disability (`What is the type of disability`, ìs there

any difficulties in the disability`) VALUES (%s, %s)",

GetSQLValueString($_POST['What_is_the_type_of_disability'], "int"),

GetSQLValueString($_POST['is_there_any_difficulties_in_the_disability'],

"int"));







}


}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the Disability Form:</strong></p>

</form>




<td nowrap align="right">What is the type of disability:</td>

<td><input type="text" name="What_is_the_type_of_disability" value=""

size="32"></td>

</tr>


<td nowrap align="right">Is there any difficulties in the disability:</td>

<td><input type="text" name="is_there_any_difficulties_in_the_disability" value=""

size="32"></td>

</tr>





</tr>

</table>

<p> </p>

115

<table width="200" border="1">

<caption>

Type of disability

</caption>

<tr>

<th width="33" scope="col"><div align="left">1</div></th>

<th width="151" scope="col"><div align="left">Visual</div></th>

</tr>

<tr>

<td>2</td>

<td>Hearing</td>

</tr>

<tr>

<td>3</td>

<td>Speech</td>

</tr>

<tr>

<td>4</td>

<td>Physical</td>

</tr>

<tr>

<td>5</td>

<td>Mental</td>

</tr>

<tr>

<td>6</td>

<td>Selfcare</td>

</tr>

<tr>

<td>7</td>

<td>Others</td>

</tr>

<tr>

<td>8</td>

116

<td>None</td>

</tr>

</table>


<caption>

difficuties if any

</caption>

<tr>


<th width="146" scope="col"><div align="left">Yes</div></th>

</tr>

<tr>

<td>2</td>

<td>No</td>

</tr>

<tr>

<td>3</td>

<td>NA</td>

</tr>

<tr>

<td>4</td>

<td>DK</td>

</tr>

</table>

<p> </p>

<p>


</p>

</form>

<p> </p>

</body>

</html>

General Information Page


117

<?php



{


switch ($theType) {

case "text":


break;

case "long":

case "int":


break;

case "double":


break;

case "date":


break;

case "defined":


break;

}

return $theValue;

}




}


118

$insertSQL = sprintf("INSERT INTO info (name, Relationship, sex, Age, `No. of Mother`,

`Household No`, Nationality, Religion, `Marital Status`, `Previous Residence`, `Duration of

residence`, ìs father alive`, ìs mother alive`) VALUES (%s, %s, %s, %s, %s, %s, %s, %s,

%s, %s, %s, %s, %s)",

GetSQLValueString($_POST['name'], "text"),

GetSQLValueString($_POST['Relationship'], "int"),

GetSQLValueString($_POST['sex'], "int"),

GetSQLValueString($_POST['Age'], "int"),

GetSQLValueString($_POST['No_of_Mother'], "int"),

GetSQLValueString($_POST['Household_No'], "int"),

GetSQLValueString($_POST['Nationality'], "int"),

GetSQLValueString($_POST['Religion'], "int"),

GetSQLValueString($_POST['Marital_Status'], "int"),

GetSQLValueString($_POST['Previous_Residence'], "int"),

GetSQLValueString($_POST['Duration_of_residence'], "int"),

GetSQLValueString($_POST['is_father_alive'], "int"),

GetSQLValueString($_POST['is_mother_alive'], "int"));



}

?>



<html>

<head>






</style>

</head>

<body>





<p align="center" class="style1"><strong>Please Fill in the information Regarding All

Persons:</strong></p>

</form>





<td><input type="text" name="name" value="" size="32"></td>

</tr>


<td nowrap align="right">Relationship:</td>

<td><input type="text" name="Relationship" value="" size="32"></td>

</tr>


<td nowrap align="right">Sex:</td>

<td><input type="text" name="sex" value="" size="32"></td>

</tr>


<td nowrap align="right">Age:</td>

<td><input type="text" name="Age" value="" size="32"></td>

</tr>


<td nowrap align="right">No. of Mother:</td>

<td><input type="text" name="No_of_Mother" value="" size="32"></td>

120

</tr>


<td nowrap align="right">Household No:</td>

<td><input type="text" name="Household_No" value="" size="32"></td>

</tr>


<td nowrap align="right">Nationality:</td>

<td><input type="text" name="Nationality" value="" size="32"></td>

</tr>


<td nowrap align="right">Religion:</td>

<td><input type="text" name="Religion" value="" size="32"></td>

</tr>


<td nowrap align="right">Marital Status:</td>

<td><input type="text" name="Marital_Status" value="" size="32"></td>

</tr>


<td nowrap align="right">Previous Residence:</td>

<td><input type="text" name="Previous_Residence" value="" size="32"></td>

</tr>


<td nowrap align="right">Duration of residence:</td>

<td><input type="text" name="Duration_of_residence" value="" size="32"></td>

</tr>


<td nowrap align="right">Is father alive:</td>

<td><input type="text" name="is_father_alive" value="" size="32"></td>

</tr>


<td nowrap align="right">Is mother alive:</td>

<td><input type="text" name="is_mother_alive" value="" size="32"></td>

</tr>


121




</tr>

</table>

<p> </p>

<table width="200" border="1" align="right">

<caption>

Relationship

</caption>

<tr>


<th width="135" scope="col"><div align="left">Head</div></th>

</tr>

<tr>

<td>2</td>

<td>Spouse</td>

</tr>

<tr>

<td>3</td>

<td>Son/Daughter</td>

</tr>

<tr>

<td>4</td>

<td>Grandchild</td>

</tr>

<tr>

<td>5</td>

<td>Brother/Sister</td>

</tr>

<tr>

<td>6</td>

<td>Father/Mother</td>

122

</tr>

<tr>

<td>7</td>

<td>Nephew/Niece</td>

</tr>

<tr>

<td>8</td>

<td>In Law </td>

</tr>

<tr>

<td>9</td>

<td>Grandparent</td>

</tr>

<tr>

<td>10</td>

<td>Other relative </td>

</tr>

<tr>

<td>11</td>

<td>Non relative </td>

</tr>

</table>

<table width="200" border="1" align="left">

<caption>

Religion

</caption>

<tr>


<th width="135" scope="col"><div align="left">Catholic</div></th>

</tr>

<tr>

<td>2</td>

<td>Protestant</td>

</tr>

123

<tr>

<td>3</td>

<td>Other Christian </td>

</tr>

<tr>

<td>4</td>

<td>Muslim</td>

</tr>

<tr>

<td>5</td>

<td>Hindu</td>

</tr>

<tr>

<td>6</td>

<td>Traditionalist</td>

</tr>

<tr>

<td>7</td>

<td>Other religion </td>

</tr>

<tr>

<td>8</td>

<td>No religion </td>

</tr>

<tr>

<td>9</td>

<td>DK</td>

</tr>

</table>


<caption>

Marital Status

</caption>

<tr>

124


<th width="151" scope="col"><div align="left">Never married </div></th>

</tr>

<tr>

<td>2</td>

<td>Married monogamous </td>

</tr>

<tr>

<td>3</td>

<td>Married polygamous </td>

</tr>

<tr>

<td>4</td>

<td>Widowed</td>

</tr>

<tr>

<td>5</td>

<td>Divorced</td>

</tr>

<tr>

<td>6</td>

<td>Separated</td>

</tr>

<tr>

<td>7</td>

<td>Dk</td>

</tr>

</table>

<p>


</p>

<p> </p>

<p> </p>

</form>

125

<form name="form3" method="post" action="results.php">

<input type="text" name="name">

<input type="submit" name="Submit" value="search">

</form>

<p> </p>

</body>

</html>

126

Date post:	23-Oct-2014
Category:	Documents
Upload:	peter-rocky-ray
View:	211 times
Download:	68 times

Census Management System - Documentation FINAL

Documents