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.
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.
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 ups and downs while I went about this project and gave me hope, Patience and confidence. May his name be Held up High!
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.
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 institutes regulations. Student Signature: .. Student Name: Kenneth K. Mwiti
Project Supervisor Signature
Date
Contents
ABSTRACT.....................................................................................................................................1 PREFACE........................................................................................................................................2 ACKNOWLEDGEMENT...............................................................................................................3 DEDICATIONS...............................................................................................................................4 DECLARATION.............................................................................................................................5 Contents...........................................................................................................................................6 CHAPTER 1..................................................................................................................................12 1. INTRODUCTION.....................................................................................................................12 1.2 PROPOSED SOLUTIONS.................................................................................................14 1.3 OBJECTIVES......................................................................................................................15 1.3.1 Personal Objectives..........................................................................................................15 1.4 JUSTIFICATION................................................................................................................15 1.5 REQUIRED RESOURCES.................................................................................................16 1.5.1 Software requirements:.................................................................................................16 1.5.2 Hardware requirements:...............................................................................................16 1.6 RISKS..................................................................................................................................16 1.7 INVESTIGATION PLAN...................................................................................................17 1.8 PROJECT DEVELOPMENT PLAN..................................................................................17 CHAPTER 2..................................................................................................................................18 2. LITERATURE REVIEW..........................................................................................................18 2.1 INTRODUCTION...............................................................................................................18 2.1.1 TOP IMAGE SYSTEM...............................................................................................18 2.1.2 LOCKHEED MARTIN Census Systems ...................................................................19 2.1.3 AUTOMATED CENSUS MAPPING SYSTEM........................................................20 2.1.4 CENSUS INFORMATION SYSTEM.........................................................................21 CHAPTER 3..................................................................................................................................22 3. INTRODUCTION.....................................................................................................................22 3.0.1 Purpose..............................................................................................................................22 3.0.2 Project Scope....................................................................................................................23 3.0.3 Intended Audience and reading suggestions....................................................................23 3.1 DATA COLLECTION METHODOLOGY.......................................................................23 3.1.1 Requirements Determination.......................................................................................23 3.1.2 Interviews....................................................................................................................24 3.1.3 Secondary sources.......................................................................................................24 3.2 DATA ANALYSIS.............................................................................................................24 3.3 DEVELOPMENT METHODOLOGY...............................................................................25 6
3.3.0 METHODOLOGY REVIEW.....................................................................................25 3.3.1 WATERFALL MODEL...................................................................................................25 3.4 GENERAL DESCRIPTION...............................................................................................26 3.4.1 Product perspective......................................................................................................26 3.4.2 Product Functionality...................................................................................................26 3.4.3 User characteristics.......................................................................................................27 3.4.4 Assumptions ................................................................................................................27 3.5 SPECIFIC REQUIREMENTS............................................................................................28 3.5.1 Functional requirements:..............................................................................................28 3.5.2 Nonfunctional requirements.........................................................................................28 3.5.3 Operational Requirements............................................................................................28 3.5.4 Training.........................................................................................................................29 3.5.5 User Interface Design...................................................................................................29 3.6 SYSTEM FEATURES........................................................................................................29 3.6.1 Security.........................................................................................................................29 3.6.1.1 Description and priority............................................................................................29 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.....................................................................................................30 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..................................................................................................31 3.9.1.3 Security Requirements..............................................................................................32 3.9.2 Software Quality Attributes.........................................................................................32 1. Maintainability...................................................................................................................32 2. Reliability .........................................................................................................................32 3. Documentation...................................................................................................................33 3.9.3 CONCLUSION............................................................................................................33 CHAPTER 4..................................................................................................................................33 4. INTRODUCTION.....................................................................................................................33 4.1.1 PURPOSE.........................................................................................................................33 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...................................................................33 7
4.1.2 SCOPE OF THE DOCUMENT.......................................................................................34 4.1.3 INTENDED AUDIENCE................................................................................................34 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...............................................................................................36 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 7.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 8
5.1: INTRODUCTION..............................................................................................................54 5.2 Goals and objectives............................................................................................................54 5.3 Statement of scope...............................................................................................................55 5.4 Major constraints.................................................................................................................56 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................................................................................................57 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...........................................................................................................61 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 9
5.9.7 High order testing (System testing)..................................................................................64 5.9.7.1 Recovery testing........................................................................................................64 5.9.7.2 Security testing..........................................................................................................64 5.9.7.3 Regression testing......................................................................................................64 5.9.7.4 Stress testing..............................................................................................................64 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...............................................................................................65 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 10
BIBLIOGRAPHY..........................................................................................................................73 APPENDICES...............................................................................................................................74 APPENDIX A: INTERVIEW QUESTIONS............................................................................74 APPENDIX B: USER MANUAL.............................................................................................74 1. INTRODUCTION....................................................................................................................74 1.1 Objectives:...........................................................................................................................74 2.0 HARDWARE AND SOFTWARE REQUIREMENTS.........................................................75 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 Residents Form...................................................................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 Countrys 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 Ministrys 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 1980s upto early 2000, the capacity of Kenyas 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 countrys 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 surveys which the CBS managed to conduct were released so late that they were often irrelevant in an ever changing 12
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 evidencebased 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 peoples 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. STORAGE AND RETRIEVAL OF INFORMATION: There are difficulties in the storage of the census forms in the current operations. The forms are 13
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. 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
14
teach or record peoples 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 peoples records when conducting census is totally eradicated. The project will produce a system that will eliminate redundancy and enhance efficiency. 15
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: Remedy: with Generators and or UPS support installed data cannot be lost through power failure 16
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 1. 2. 3. 4. 5. Activities Project proposal Problem definition Feasibility study Fact finding Analysis and design 6. 7. Implementation Reviewing the system 1 2 8 9 12 13 14 15 16 17 18 19 20 22 24
TIME IN WEEKS
17
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 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 18
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 Kingdoms 2001 Census, and Canadas 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 Martins 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 Canadas dress rehearsal and full 2006 census, including the first successful use of the secure Internet channel. In every census we support, Lockheed Martins team strives to: 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.
19
Lockheed Martins 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 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 20
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)
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 21
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 Bureaus computing systems in near real-time for integration with other data sources.
The goal and principle of the system requirement specification is to prepare the scope of the document, the designers view of the clients 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. To describe the new systems functionality and the change its 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 systems 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. 22
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 systems 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 peoples 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 users database. Technicians: Will have the task of troubleshooting and maintaining the system.
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:
23
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.
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 interviewees 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.
24
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. 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. 25
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 Requirement specification System design Detailed design Coding and testing Integration and maintenance
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.
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. 26
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; 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.
27
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 peoples details. The system should allow the Clerks to record peoples 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)

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
28
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 users 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 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.
29
3.6.1.2 Stimulus/response sequences

Integrity of data is enhanced thus information will be safe. Users accounts will be managed by the system administrator through the server by checking the current performance of each user i.e. Each clients 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 from the database.
30
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. 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 31
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 document, the designers view of the clients needs and requirements before the actual system 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.
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 and 33
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 subparts 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
34
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.
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. 35
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. 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. 36
Database management software preferably MySQL. PHP provided under the package which comes with Apache web server.
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.
Issue population and housing census forms
Assign tasks to deputy supervisors
Allocates each supervisor his supervision area
Senior Supervisor
Distribute the population and housing forms
Fill in the population details
Assigns a unique code to area of visitation Enumerator Deputy Supervisor Verify the details
Return the forms to senior supervisor IT Clerk Generates a final report Record in database
38
4.7 SEQUENCE DIAGRAM
:Database
: Senior supervisor : Enumerator : Deputy Supervisor
3: Assess details
: IT Clerk
1: Issues census forms()
2: Fills in details()
5: update()
4: Reject if incorrect()
6: Query for population information ()
7: Query ()
9:Generates a population information ()
8: Generates
10: Assess information()
11: Record in findings()
112: Records () 113: Generates ()
14: Generate overall report
15:Filling takes place()
39
4.8 ACTIVITY DIAGRAM.

Supervisor Enumerator IT clerk
Conducts Training
Issues census forms
Determine supervision area
Assigns task to Enumerator
Visit the supervision area and assign code
Verify population details. Incorrect details Correct details
Fills in the population details
Record the population details in the database
40
4.9 CLASS DIAGRAM
Supervisor
Supervisor ID Supervisor name Address Email Phone Number
Enumerator Enumerator ID Enumerator name
Address Email
Enter population details () Assigns code ()
Enquire () Select area () Train () Register ()
1.........*
1.........* IT clerk Registration no. Name Address Verify () Send feedback ()
Census form Household number Location Address Age Religion Marital Status Birth Place Orphan hood Issued () Filled ()
1.........*
41
3NF
SUPERVISOR ID SUPERVISOR NAME
4.10 DATABASE DESIGN

4.10.1 SCHEMA DESIGN
NAME F_NAME L_NAME ADDRESS EMAIL PHONE NUMBER PASSWORD

ENUMERATOR NAME ENUMERATOR ID
the tables. The objective is to isolate data so that additions, deletions, and modifications of a Household number Location field can be made in just one table and then propagated through the rest of the database via the Address defined relationship. Age UNF Religion 2NF SUPERVISOR NAME Marital Status 7.2 NORMALIZATION SUPERVISOR ID SUPERVISOR ID 1NF Birth Place SUPERVISOR NAME F_NAME SUPERVISOR ID Orphan hood NAME L_NAME
ADDRESS EMAIL PHONE NUMBER PASSWORD
ENUMERATOR NAME ENUMERATOR ID SUPERVISOR NAME
F_NAME L_NAME ADDRESS In relational database design, this is the process of organizing data to minimize duplication. EMAIL Normalization involves dividing a database into more tables and defining relationship between PHONE NUMBER PASSWORD
F_NAME L_NAME ADDRESS EMAIL PHONE NUMBER PASSWORD

ENUMERATOR NAME ENUMERATOR ID
Household number
Location Address Age Religion Marital Status Birth Place Orphan hood
Previous Residence Duration of residence Tribe/Nationality Livestock Exotic Cattle Indigenous cattle Sheep Goat Camels Donkeys Pigs Chicken Assets Household Radio Television Car Landline
F_NAME L_NAME ADDRESS EMAIL PHONE NUMBER PASSWORD ENUMERATOR NAME ENUMERATOR ID F_NAME L_NAME ADDRESS EMAIL PHONE NUMBER PASSWORD
Household number
Household number
42
4.10.2 ENTITY RELATIONSHIP DIAGRAM
Enumerator
IT clerk
System
Key
Entity Data Store Data Flow Process
43
4.10.3 TABLE SCHEMA

SUPERVISOR Field name Supervisor Name Supervisor ID First name Last name Address Email Phone No. Password ENUMERATOR Field name Enumerator Name Enumerator ID First name Last name Address Email Phone No. Password ASSETS Field Name Car Household Radio Landline Television HOUSEHOLD Field Name Location Address Place of birth Duration of residence Religion Marital status LIVESTOCK Field Name Cattle Goat Pigs
Data type Varchar Number Text Text Int Text Int Varchar Data type Varchar Number Text Date time Date time Text Int Varchar Data type Number Number Number Number Number Data type Varchar Int Varchar Varchar Varchar Varchar Data type Varchar Int Varchar
Size 20 20 20 20 10 20 15 20 Size 20 20 20 20 10 20 15 20 Size 20 20 20 20 20 Size 20 20 20 20 20 10 Size 20 20 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 Table Field name Supervisor Name Supervisor First Name Supervisor Last Name Supervisor ID Address Email Phone No. Password Description Holds the name of the Supervisor Holds the First name of the Supervisor Holds other names of the Supervisor Field for identifier of the Supervisor Holds the contact of the supervisor Highlights the email of the supervisor Fields holds phone number of the supervisor Indicates the password
Enumerator Table Enumerator Name Holds the name of the Enumerator
Enumerator First Name Enumerator Last Name
Holds the First name of the Enumerator Holds other names of the Enumerator
Enumerator ID Address Email Phone No.
Field for identifier of the Enumerator Holds the contact of the Enumerator Highlights the email of the Enumerator Fields holds phone number of the Enumerator
45
Household details Table Location Address Age Religion Marital Status Birth Place Orphan hood
Previous Residence
Duration of residence
Indicates the location for household Indicates the Address for household Indicates the age of residents Indicates the religion of residents Indicates the marital status of residents Indicates the birth place of residence Indicates the orphan in the residence Indicates the previous residence of residents Indicates the location for household Indicates the tribe of residents
Tribe/Nationality
Livestock Table Enumerator Name Cattle Goats Pigs Field containing Enumerator Name Indicate the number of cattle one posses Indicate the number of goats one posses 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
LOGIN If you are a member please login below: User Name: Password: If you are not a member please register here;
Login
Figure 1: Log in form
4.10.7 Login fail page form
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
47
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
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
48
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
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
49
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
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 50
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.
Information of Figure 5: Register page form 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
4.10.12 Information of Female aged 3years and above form
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 51
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.
Housing Condition and Amenities Form

Record the Observation made on the field 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 Clear Send Details
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 citizens form on the website.
Information about hotel, prison, hospital in-patient citizens

Record the Observation made on the field Serial Number: Name: Sex: Age: Duration of stay: Education Level: Home district: Tribe: Type of Institution: Name of Institution: Send Clear Text
52
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 document, the designers view of the clients needs and requirements before the actual system 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 tests 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
55
5.4 Major constraints

Some errors were not traceable using the testing tools and took time to debug them. 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.
Unit test
Integration test
System test
User acceptance test
56
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. TEST 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. FIELD EXPECTED OUTPUT The field should prompt a user to enter the correct username to login the system. The field should only accept a valid password. Should accept alphanumeric data without returning any Numeric Fields e.g. Numbers only 234567 errors. Should only work with numeric values and never accept alphabetic. Should return an error in any attempt to do so. Should not allow user to proceed without data entry The user can easily afford to fill the forms without any It was successful It was successful It was successful ACTUAL OUTPUT It was successful
UNIT TESTING
USER NAME e.g. admin PASSWORD e.g. lisa TEXT FIELDS e.g. eryt56
Required Fields e.g. ID Number Forms
It was successful It was successful
57
problem.
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 Username & Password Requirement Purpose Authentication & security Test Case Login Expected Results Successful login for correct username and password combination All the web pages are in the format that the user can easily find information they need The website is accessible by most types of browsers e.g. internet explorer, Opera, Netscape Actual Results It was successful P/F It worked well Notes
Screen Design and Layout
Ease of use the web pages in the designed layout.
Layout
It was successful
It worked well
Accessibility of the Website
Ability to Accessing access the website by most browsers
It was successful
It worked well
58
Navigation Testing
Navigation Testing
Hardware Testing
Form validation Testing
Output design Testing
Database Testing
navigator. Links to various Navigation All pages are It was It pages linked and successful worked there is a well simple and easy way to navigate. Links to various Navigation All pages It was It pages are linked successful worked and there well is a simple and easy way to navigate. Communication Communication The web It was It of the Web browser and successful worked browser and the local well local server server should communicate effectively without any interfering problems Ease of filling Validation Error It was It the forms and message successful worked the appear when well functionality of an error data been process recorded in the occurs. database Ease of Output The reports It was It producing should be successful worked reports in a easily well clear format produced as the user wants and should convey the information the user needs. Correct storage Storage The It was It of information information successful worked entered by well the user should be stored correctly in the database. 59
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 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.
60
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.
5.9.1 Software to be tested

Interface Components to be tested Engine Component to be tested Installation Components to be tested 61
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.
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. 62
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.
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.
63
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 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 64
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 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.
65
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 bte 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 system will demonstrate to the developer and the customer that the software meets its requirements.
66
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.
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. 67
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. 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. 68
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 ii. 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 User training and orientation Define procedure for adding new users Define procedures for users to get help
Phase 2
iii.
Phase 3 69
iv.
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. Stopping the operation of the old system and putting the new secure computerized information system
Phase 4
6.6 Implementation Schedule

Task Task 1 Description Installation Activities involved Installation of the required hardware. Installation of the required application and system Task 2 Conversion Task 3 Task 4 Actual system installation Training Task 5 Task 6 Evaluation Maintenance software. 16/11/2009 File conversions Configurations of directories for application Data entry Create an administrator user account. 18/11/2009 The actual system installation User training and orientation Define procedure for adding new users Explanation of how each module works. Post implementation evaluation. System maintenance at clients site. 24/11/2009 25/11/2009 20/11/2009 16/11/2009 Expected start time 15/11/2009 Expected end time 15/11/2009
18/11/2009 20/11/2009
70
6.7 Conclusions
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. 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
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. 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 organizations 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, 7087-8.
Timothy
P.
(2007).
Information
Security:
Design,
Implementation,
Measurement, and Compliance. Boca Raton, FL: Auerbach publications. 978-0-8493-
4)
McNab, Chris (2004). Network Security Assessment. Sebastopol, CA: O'Reilly. 0-59600611-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 Practitioners Approach,Roger S.pressman.
73
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. 4. Open your browser and type in http://localhost/xampp/ 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"> <!-.style1 {font-size: 36px} .style2 {font-size: 18px; } body { background-color: #00FF00; } --> </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 <!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"> <!-.style1 {font-size: 36px} 87
body { background-color: #00FFCC; } .style2 {font-size: 14px} body,td,th { color: #660000; } --> </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 require_once('Connections/censusconnect.php'); ?> <?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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; 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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "home.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; 92
} header(sprintf("Location: %s", $insertGoTo)); } ?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #3333FF; } --> </style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 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> <tr valign="baseline"> <td nowrap align="right">TV:</td> <td><input type="text" name="TV" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Phone:</td> <td><input type="text" name="Phone" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Landline:</td> <td><input type="text" name="Landline" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Computer:</td> <td><input type="text" name="Computer" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Bicycle:</td> <td><input type="text" name="Bicycle" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Motor Cycle:</td> <td><input type="text" name="Motor_Cycle" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Car:</td> <td><input type="text" name="Car" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Lorry:</td> <td><input type="text" name="Lorry" value="" size="32"></td> </tr> <tr valign="baseline"> 94
<td nowrap align="right">Refrigerator:</td> <td><input type="text" name="Refrigerator" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Boat:</td> <td><input type="text" name="Boat" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Cart:</td> <td><input type="text" name="Cart" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Canoes:</td> <td><input type="text" name="Canoes" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Tuk tuk:</td> <td><input type="text" name="Tuk_tuk" value="" size="32"></td> </tr> <tr valign="baseline"> <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 require_once('Connections/censusconnect.php'); ?> <?php $colname_Recordset1 = "1"; 95
if (isset($_POST['name'])) { $colname_Recordset1 = (get_magic_quotes_gpc()) ? $_POST['name'] : addslashes($_POST['name']); } mysql_select_db($database_censusconnect, $censusconnect); $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); ?> <!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"> <!-body { background-color: #CCFF33; } --> </style><head> <p align="right">KNBS</p> <p align="center" class="style1"><strong>Republic of Kenya </strong></p> <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> <th scope="col"> </th> 96
<th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> <th scope="col"> </th> </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 require_once('Connections/censusconnect.php'); ?> <?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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } $editFormAction = $_SERVER['PHP_SELF']; if (isset($_SERVER['QUERY_STRING'])) { $editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']); }
98
if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] == "form2")) { $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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "account.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $insertGoTo)); } ?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #009966; } 99
--> </style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 Fill in the Supervisors Details:</strong></p> </form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <td nowrap align="right">Name:</td> <td><input type="text" name="Name" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Fname:</td> <td><input type="text" name="Fname" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Lname:</td> <td><input type="text" name="Lname" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Id:</td> <td><input type="text" name="id" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Address:</td> <td><input type="text" name="Address" value="" size="32"></td> 100
</tr> <tr valign="baseline"> <td nowrap align="right">Email:</td> <td><input type="text" name="Email" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Phone no.:</td> <td><input type="text" name="Phone_no" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Password:</td> <td><input type="text" name="password" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right"> </td> <td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> <input type="hidden" name="MM_insert" value="form2"> </form> <p> </p> </body> </html> Enumerator Form <?php require_once('Connections/censusconnect.php'); ?> <?php function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue; switch ($theType) { case "text": 101
$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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } 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 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
mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "account.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $insertGoTo)); } ?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #00FF99; } --> </style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 Fill in the Enumerators Details:</strong></p> 103
</form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <td nowrap align="right">Name:</td> <td><input type="text" name="Name" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Fname:</td> <td><input type="text" name="Fname" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Lname:</td> <td><input type="text" name="Lname" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Id:</td> <td><input type="text" name="id" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Email:</td> <td><input type="text" name="Email" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Password:</td> <td><input type="text" name="password" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Phone no.:</td> <td><input type="text" name="Phone_no" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right"> </td> 104
<td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> <input type="hidden" name="MM_insert" value="form2"> </form> <p> </p> </body> </html> Orphanhood Page <?php require_once('Connections/censusconnect.php'); ?> <?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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; 105
} 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 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_househol d_during_dates_state'], "int"), GetSQLValueString($_POST['how_many_deaths_occured_in_this_household_b etween_stated_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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "home.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $insertGoTo)); } 106
?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #00FFFF; } --> </style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 Fill in the information About Deaths in the Household Form:</strong></p> </form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <td nowrap align="right">How many live birth occured in this household during dates state:</td> <td><input type="text" name="How_many_live_birth_occured_in_this_household_during_dates_state" value="" size="32"></td> 107
</tr> <tr valign="baseline"> <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> <tr valign="baseline"> <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> <tr valign="baseline"> <td nowrap align="right">Was this death notified:</td> <td><input type="text" name="Was_this_death_notified" value="" size="32"></td> </tr> <tr valign="baseline"> <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> <tr valign="baseline"> <td nowrap align="right">Male/female:</td> <td><input type="text" name="malefemale" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right"> </td> <td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> <input type="hidden" name="MM_insert" value="form2"> </form> <p> </p> 108
</body> </html> Livestock page form <?php require_once('Connections/censusconnect.php'); ?> <?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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } $editFormAction = $_SERVER['PHP_SELF']; if (isset($_SERVER['QUERY_STRING'])) { $editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']); 109
} if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] == "form2")) { $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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "home.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $insertGoTo)); } ?> <!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> 110
<style type="text/css"> <!-.style1 {font-size: 36px} body { background-color: #0000CC; } --> </style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 Fill in the Livestock Details:</strong></p> </form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <td nowrap align="right">Exotic Cattle:</td> <td><input type="text" name="Exotic_Cattle" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Indigenous cattle:</td> <td><input type="text" name="Indigenous_cattle" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Sheep:</td> <td><input type="text" name="Sheep" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Goat:</td> 111
<td><input type="text" name="Goat" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Camels:</td> <td><input type="text" name="Camels" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Pigs:</td> <td><input type="text" name="Pigs" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Indigenous chicken:</td> <td><input type="text" name="Indigenous_chicken" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Chicken commercial:</td> <td><input type="text" name="Chicken_commercial" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Bee Hives:</td> <td><input type="text" name="Bee_Hives" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Other:</td> <td><input type="text" name="Other" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right"> </td> <td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> <input type="hidden" name="MM_insert" value="form2"> </form> 112
<p> </p> </body> </html> Persons with disability form <?php require_once('Connections/censusconnect.php'); ?> <?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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } return $theValue; } $editFormAction = $_SERVER['PHP_SELF']; if (isset($_SERVER['QUERY_STRING'])) { 113
$editFormAction .= "?" . htmlentities($_SERVER['QUERY_STRING']); } if ((isset($_POST["MM_insert"])) && ($_POST["MM_insert"] == "form2")) { $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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); $insertGoTo = "home.php"; if (isset($_SERVER['QUERY_STRING'])) { $insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?"; $insertGoTo .= $_SERVER['QUERY_STRING']; } header(sprintf("Location: %s", $insertGoTo)); } ?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #0066FF; } --> 114
</style> </head> <body> <form name="form1" method="post" action=""> <p align="right">KNBS</p> <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 Fill in the Disability Form:</strong></p> </form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <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> <tr valign="baseline"> <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 valign="baseline"> <td nowrap align="right"> </td> <td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> <p> </p> <table width="200" border="1"> <caption> Type of disability </caption> <tr> 115
<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> <td>None</td> </tr> </table> <table width="200" border="1"> <caption> 116
difficuties if any </caption> <tr> <th width="38" scope="col"><div align="left">1</div></th> <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> <input type="hidden" name="MM_insert" value="form2"> </p> </form> <p> </p> </body> </html> General Information Page <?php require_once('Connections/censusconnect.php'); ?> <?php function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue = "") { $theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue; 117
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": $theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL"; break; case "defined": $theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue; break; } 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 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"), 118
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")); mysql_select_db($database_censusconnect, $censusconnect); $Result1 = mysql_query($insertSQL, $censusconnect) or die(mysql_error()); } ?> <!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"> <!-.style1 {font-size: 36px} body { background-color: #660099; } --> </style> </head> <body> <form name="form1" method="post" action=""> 119
<p align="right">KNBS</p> <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 Fill in the information Regarding All Persons:</strong></p> </form> <form method="post" name="form2" action="<?php echo $editFormAction; ?>"> <table align="center"> <tr valign="baseline"> <td nowrap align="right">Name:</td> <td><input type="text" name="name" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Relationship:</td> <td><input type="text" name="Relationship" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Sex:</td> <td><input type="text" name="sex" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Age:</td> <td><input type="text" name="Age" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">No. of Mother:</td> <td><input type="text" name="No_of_Mother" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Household No:</td> <td><input type="text" name="Household_No" value="" size="32"></td> </tr> <tr valign="baseline"> 120
<td nowrap align="right">Nationality:</td> <td><input type="text" name="Nationality" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Religion:</td> <td><input type="text" name="Religion" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Marital Status:</td> <td><input type="text" name="Marital_Status" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Previous Residence:</td> <td><input type="text" name="Previous_Residence" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Duration of residence:</td> <td><input type="text" name="Duration_of_residence" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Is father alive:</td> <td><input type="text" name="is_father_alive" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right">Is mother alive:</td> <td><input type="text" name="is_mother_alive" value="" size="32"></td> </tr> <tr valign="baseline"> <td nowrap align="right"> </td> <td><input type="submit" value="Insert record"> <input type="reset" name="Reset" value="Clear"></td> </tr> </table> 121
<p> </p> <table width="200" border="1" align="right"> <caption> Relationship </caption> <tr> <th width="49" scope="col"><div align="left">1</div></th> <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> </tr> <tr> <td>7</td> <td>Nephew/Niece</td> </tr> <tr> 122
<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="49" scope="col"><div align="left">1</div></th> <th width="135" scope="col"><div align="left">Catholic</div></th> </tr> <tr> <td>2</td> <td>Protestant</td> </tr> <tr> <td>3</td> <td>Other Christian </td> </tr> <tr> <td>4</td> 123
<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> <table width="200" border="1"> <caption> Marital Status </caption> <tr> <th width="33" scope="col"><div align="left">1</div></th> <th width="151" scope="col"><div align="left">Never married </div></th> </tr> <tr> <td>2</td> <td>Married monogamous </td> 124
</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> <input type="hidden" name="MM_insert" value="form2"> </p> <p> </p> <p> </p> </form> <form name="form3" method="post" action="results.php"> <input type="text" name="name"> <input type="submit" name="Submit" value="search"> </form> <p> </p> </body> 125
</html>
126

Census Management System - Documentation FINAL

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Census Management System - Documentation FINAL

Diunggah oleh

Hak Cipta:

Format Tersedia

______

Project Supervisor Signature

1.1 PROBLEM DEFINITION

INADEQUATE MATERIALS AND THEIR TRANSPORTATION.

1.2 PROPOSED SOLUTIONS

1.3.1 Personal Objectives

1.5 REQUIRED RESOURCES

1.5.1 Software requirements:

1.5.2 Hardware requirements:

1.7 INVESTIGATION PLAN

1.8 PROJECT DEVELOPMENT PLAN

CHAPTER 2 2. LITERATURE REVIEW

2.1.1 TOP IMAGE SYSTEM

2.1.2 LOCKHEED MARTIN CENSUS SYSTEMS

2.1.3 AUTOMATED CENSUS MAPPING SYSTEM

2.1.4 CENSUS INFORMATION SYSTEM

3.0.2 Project Scope

3.0.3 Intended Audience and reading suggestions.

3.1 DATA COLLECTION METHODOLOGY

3.1.1 Requirements Determination

3.1.3 Secondary sources

3.2 DATA ANALYSIS

3.3 DEVELOPMENT METHODOLOGY.

3.3.0 METHODOLOGY REVIEW

3.3.1 WATERFALL MODEL

3.4 GENERAL DESCRIPTION

3.4.1 Product perspective

3.4.2 Product Functionality

3.4.3 User characteristics

3.5 SPECIFIC REQUIREMENTS

3.5.1 Functional requirements:

3.5.2 Nonfunctional requirements

3.5.3 Operational Requirements

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

Phpdev 4.23 Internet Explorer 6.0 or later Macromedia Dream weaver

3.5.5 User Interface Design

3.6 SYSTEM FEATURES

3.6.1 Security 3.6.1.1 Description and priority

3.6.1.2 Stimulus/response sequences

3.6.1.3 Functional requirement

3.7 External Interface Requirements

3.7.1 User interface

3.7.2 Hardware Interfaces.

3.8 Software Interfaces.

3.9 Communication Interfaces.

3.9.1 Other Nonfunctional Requirements. 3.9.1.1 Performance Requirement.

3.9.1.2 Safety Requirements

3.9.1.3 Security Requirements.

3.9.2 Software Quality Attributes 1. Maintainability

4.1.2 SCOPE OF THE DOCUMENT

4.1.3 INTENDED AUDIENCE.

4.2 SYSTEM ENVIRONMENT.

4.3 DESIGN REQUIREMENT LIST.

4.4 THE SYSTEM OVERVIEW

4.4.1 DESIGN TOOLS

4.4.1.1 HARDWARE TOOLS

4.4.1.2 SOFTWARE TOOLS

Macromedia Dream weaver version 8. 36

4.5 TECHNICAL CONSTRAINTS

4.6 SYSTEM ARCHITECTURE

Assign tasks to deputy supervisors

Allocates each supervisor his supervision area

Distribute the population and housing forms