WOLAITA SODO UNIVERSITY

SCHOOL OF INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE AND INFORMATION TECHNOLOGY

A Senior Project On Municipality Information Management System (In

Case of Wolaita Sodo Town)

Group3 Members:

Name Id_ No:-

1. Trekign Firew 485/05

2. Gizatu Bekele 244/05
3. Kedija Guye 1512/04
4. Kuri Kussia 301/05
5. Alemitu Chama 048/05

ADIVISOR: ALEMAYEHU D.

Wolaita sodo, Ethiopia

2016
 Abstract

Municipality information management system is the smallest administrative unit of Ethiopia

similar to a ward, a neighborhood or a localized and delimited group of people. In this part of the
town or district, currently tasks are being performed manually. The project is essentially aimed to
develop an automated system which solves the manual delivering service problems and data
management at municipality offices. The proposed system mainly will have the significances of
reducing man power, time and cost and wastage of resource. The data gathering methods used
are interview, document analysis and observation. We used various hardware and software
technologies in order to develop our system. Generally the final project provide service such as
Registering Resident, Registering Family Request ID card for citizen ,Request certificate,
Request testimony letters for resident and delivering news.

Acknowledgment

First of all I would like to say thanks almighty God who helped us to preparation of this project
proposal and documentation part

Next we thank also our Advisor Mr. Alemayehu Dereje for Advising. Guidance, giving great full
support for inspiration and constructiveness the team and idea generation which is helpful for
preparation of our project proposal with documentation

Then, we would also like to thanks our friends who helped us a lot in finishing this all phase of
industrial project first phase within the limited time.

i|Page
Contents
Abstract ........................................................................................................ i
Acknowledgment ............................................................................................ i
Chapter one Introduction .................................................................................... 1
1. BACKGROUND OF THE SYSTEM ................................................................... 1
Structure of Organization .................................................................................... 2
2. Statement of The problem ................................................................................. 3
3. TEAM COMPOSITION .................................................................................. 3
4. OBJECTIVES OF THE PROJECTS ...................................................................... 4
4.1 GENERAL OBJCTIVES .............................................................................. 4
4.2 SPECIFIC OBJECTIVES ............................................................................. 4
5. SCOPE OF THE PROJECT ............................................................................... 5
5.1 Target Beneficiaries of the project .................................................................... 5
6. Significance of the project ................................................................................. 6
7. Feasibility Analysis ........................................................................................ 7
7.1 Technical Feasibility .................................................................................. 7
7.2 Economic feasibility ................................................................................... 7
7.3 Operational feasibility ................................................................................. 8
7.4 Political Feasibility .................................................................................... 8
7.5 Schedule Feasibility ................................................................................... 8
8. Methodology of the project ............................................................................... 9
8.1 Data sources ........................................................................................... 9
8.2 Fact-finding Techniques ............................................................................... 9
8.2.1 Document Analysis ............................................................................... 9
8.2.2 Interview Technique .............................................................................. 9
8.5 System Analysis and Design Approach ............................................................... 9
9. Development Tools to use ................................................................................ 10
9.1 Development Tools. .................................................................................. 10
10. Cost of the project ....................................................................................... 10
2. Chapter Two SYSTEM REQUIREMENTS SPESFICATION (SRS)................................... 13
2.1 Description of the Existing System ..................................................................... 13
2.1.1Players in existing system ........................................................................ 14
Resident ............................................................................................... 15

i|Page
 2.1.1Major Function activities in current system...................................................... 15
2.1.3 Business rules .................................................................................... 16
2.1.4Report generated in Existing System............................................................. 17
2.1.5Forms and Other documents of Existing System ................................................ 17
2.1.6Bottlenecks of the existing system ............................................................... 20
2.2Description of Proposed System ...................................................................... 22
2.1.1Requirements of the proposed system............................................................ 23
3.1. Use case diagram .................................................................................... 25
Designing the system use case diagram .................................................................. 25
3.1.1. Actor specification .............................................................................. 26
3.1.2. Use Case Description ........................................................................... 27
Actor ...................................................................................................... 35
Administrator ............................................................................................. 35
Description................................................................................................ 35
Describe in detail, Remove user account from system if it is unnecessary .............................. 35
Precondition .............................................................................................. 35
Administrator must be suitable to login and the existed account is invalid or not functional ........... 35
Post condition ............................................................................................. 35
The account has been removed or deleted from the system ............................................. 35
Includes ................................................................................................... 35
Login ...................................................................................................... 35
Basic course action ....................................................................................... 35
6. Use case ends .......................................................................................... 35
Name ...................................................................................................... 35
Delete comment .......................................................................................... 35
ID ......................................................................................................... 35
UC11 ...................................................................................................... 35
Actor ...................................................................................................... 35
Administrator ............................................................................................. 35
Description................................................................................................ 35
Use case deletes the comment. ........................................................................... 35
Precondition .............................................................................................. 35
Manager able to delete the message after seeing the message ........................................... 35
Post condition ............................................................................................. 35

ii | P a g e
 The system displays the comment form .................................................................. 35
Includes ................................................................................................... 36
Login ...................................................................................................... 36
Basic course action ....................................................................................... 36
3.2. Class modeling ....................................................................................... 36
3.3. Dynamic model ...................................................................................... 38
3.3.1. Sequence Diagram .............................................................................. 38
3.3.2. ACTIVITY DIAGRAM ........................................................................ 45
3.4. User interface prototyping ........................................................................... 53
4. CHAPTER FOUR SYSTEM DESIGN ................................................................ 54
4.1. Introduction .......................................................................................... 54
4.2. Over view of system design ......................................................................... 54
Architectural design .................................................................................. 55
Logical design ......................................................................................... 55
Physical design ........................................................................................ 55
4.3. Design goal .......................................................................................... 56
4.4. The Proposed Software Architecture ................................................................ 58
4.5. Hardware/Software mapping ........................................................................ 60
4.6. PERSISTENT DATA MANAGEMENT ......................................................... 61
4.6.1. Database design ................................................................................. 61
4.6.2. Entity Relationship (ER DIAGRAM) .......................................................... 63
4.7. User Interface Design ................................................................................ 63
Chapter Five: ................................................................................................ 68
Implementation and Testing ................................................................................ 68
5.1 Introduction ........................................................................................... 68
5.2 Hardware software acquisitions ...................................................................... 69
5.3 User manual preparation .......................................................................... 69
Chapter Six: ................................................................................................. 73
Conclusions and Recommendation ......................................................................... 73
6.1Conclusion............................................................................................. 73
6.2 Recommondations .................................................................................... 73
Reference .................................................................................................... 75

iii | P a g e
 List of tables
Figure 1.1 structure of organization ..................................................................... 2
Table 1.1 team composition .............................................................................. 4
Table 1.2 development tools ............................................................................ 10
Table 1.3 Hardware Cost ................................................................................. 10
Table 1.4 Software Cost .................................................................................. 10
Table 1.5 Labor Cost ...................................................................................... 11
Table 1.6 miscellaneous cost ............................................................................ 11
Table 1.7 summary of development cost .............................................................. 12
Table 2.1 Players in existing system .................................................................... 15
Figure 2.1 Birth certificate .............................................................................. 18
Figure2.2 Marriage certificate ........................................................................... 19
Figure 2.3 Death certificate ............................................................................. 20
Table 3.1 use case identification ....................................................................... 27
Table 3.2 login use case description.................................................................... 28
Table 3.3 registers resident use case description .................................................... 29
Table 3.4 request ID card use case description ....................................................... 30
Table 3.5 request certificate use case description ................................................... 31
Table 3.6 create resident account use case description............................................. 32
Table 3.7 search information use case description ................................................... 33
Table 3.8 update account use case description ....................................................... 33
Table 3.9 generate report use case description ...................................................... 34
Table 3.10 delete account use case description ...................................................... 35
Table 3.11 delete comment use case description ........................................................... 36
Figure 3.4 Sequence diagram for resident register ................................................... 40
Figure 3.5 Sequence diagram for search information ................................................ 41
Figure 3.6 Sequence diagram for request certificate ................................................ 42
Fig3.7 Sequence diagram for delete account ......................................................... 42
Figure 3.8 Sequence diagram for ID card request .................................................... 43
Figure 3.9 Sequence diagram for generate report.................................................... 43
Fig3.10 Sequence diagram for update account information. ....................................... 44
Fig 3.11 Sequence diagram for delete comment ..................................................... 45
Fig 3.12 Activity diagram for login page ............................................................... 47
Fig 3.13 Activity diagram for generate report ........................................................ 47
Figure 3.14 Activity diagram for resident registration ............................................... 48
Figure 3.15 Activity diagram for search information ................................................. 49
Figure3.16 Activity diagram for Request certificate ................................................. 50
Figure 3.18 Activity diagram for update account information ...................................... 51
Fig3.19 Activity diagram for delete account .......................................................... 52
Fig 3.20 Activity diagram for delete comment ........................................................ 52
Figure 3.21 user interface prototype ................................................................... 53
Figure 4.1 proposed software architecture ............................................................ 59
Figure 4.2 Hardware and software mapping for the proposed system ..................................... 60
Figure 4.4 Entity relationship diagram for the proposed system ................................... 63

iv | P a g e
Figure 4.5 User interface for Home Page .............................................................. 64
Figure 4.6 User interface Administrator page ......................................................... 65
Figure 4.7User interface for resident registration forum ............................................ 66
Figure 4.8 User interface for login page .................................................................... 67
Figure 1.1 structure of organization ..................................................................... 2
Table 1.1 team composition .............................................................................. 4
Table 1.2 development tools ............................................................................ 10
Table 1.3 Hardware Cost ................................................................................. 10
Table 1.4 Software Cost .................................................................................. 10
Table 1.5 Labor Cost ...................................................................................... 11
Table 1.6 miscellaneous cost ............................................................................ 11
Table 1.7 summary of development cost .............................................................. 12
Table 2.1 Players in existing system .................................................................... 15
Figure 2.1 Birth certificate .............................................................................. 18
Figure2.2 Marriage certificate ........................................................................... 19
Figure 2.3 Death certificate ............................................................................. 20
Table 3.1 use case identification ....................................................................... 27
Table 3.2 login use case description.................................................................... 28
Table 3.3 registers resident use case description .................................................... 29
Table 3.4 request ID card use case description ....................................................... 30
Table 3.5 request certificate use case description ................................................... 31
Table 3.6 create resident account use case description............................................. 32
Table 3.7 search information use case description ................................................... 33
Table 3.8 update account use case description ....................................................... 33
Table 3.9 generate report use case description ...................................................... 34
Table 3.10 delete account use case description ...................................................... 35
Table 3.11 delete comment use case description ........................................................... 36
Figure 3.4 Sequence diagram for resident register ................................................... 40
Figure 3.5 Sequence diagram for search information ................................................ 41
Figure 3.6 Sequence diagram for request certificate ................................................ 42
Fig3.7 Sequence diagram for delete account ......................................................... 42
Figure 3.8 Sequence diagram for ID card request .................................................... 43
Figure 3.9 Sequence diagram for generate report.................................................... 43
Fig3.10 Sequence diagram for update account information. ....................................... 44
Fig 3.11 Sequence diagram for delete comment ..................................................... 45
Fig 3.12 Activity diagram for login page ............................................................... 47
Fig 3.13 Activity diagram for generate report ........................................................ 47
Figure 3.14 Activity diagram for resident registration ............................................... 48
Figure 3.15 Activity diagram for search information ................................................. 49
Figure3.16 Activity diagram for Request certificate ................................................. 50
Figure 3.18 Activity diagram for update account information ...................................... 51
Fig3.19 Activity diagram for delete account .......................................................... 52
Fig 3.20 Activity diagram for delete comment ........................................................ 52
Figure 3.21 user interface prototype ................................................................... 53
Figure 4.1 proposed software architecture ............................................................ 59

v|Page
Figure 4.2 Hardware and software mapping for the proposed system ..................................... 60
Figure 4.4 Entity relationship diagram for the proposed system ................................... 63
Figure 4.5 User interface for Home Page .............................................................. 64
Figure 4.6 User interface Administrator page ......................................................... 65
Figure 4.7User interface for resident registration forum ............................................ 66
Figure 4.8 User interface for login page .................................................................... 67

ACRONOMY

HTML………………………...hypertext markup language

PHP…………………………...hypertext preprocessor

SQL…………………………..Structural query language

CSS……………………………Cascading style sheet

OOA………………………… Object oriented approach

XML………………………….Extensible Markup language

UC……………………………Use case

CD……………………………Compact disk

UML…………………………Unified modeling language

BR……………………………Business rule

SRS…………………………System requirement specification

ER………………………….entityrelationship

vi | P a g e
 Chapter one Introduction

1. BACKGROUND OF THE SYSTEM

Municipality is among the smallest administrative organs of Ethiopian People Republic
Democratic Federation. Municipality was established during the 18 century. The municipality
has very large number of people. Accordingly, municipality is empowered to handle almost all
services like population & house registration, issuance of ID cards and different certificates
(birth, marital & non-martial certificates), policing services, and collection of house rents,
ownership licensing and transfer of properties.

As a result, society of municipality has benefited from such an arrangement as most services are
brought closer to the community; there by avoiding lengthy bureaucratic procedures delays that
makes the number of days large to perform a job during the old system. One of these problems is
related to the poor filing system, which is seriously affecting the amount and quality of service
delivered to the Society at any level of municipality information.

Due to the poorly organized filing and recording or archiving system, the issuance of ID cards
have become problematic, i.e., personal files are lost or misplaced and hence cannot be easily
located if applicants want to get replacements for lost ID card. Moreover, individuals can
illegally obtain ID card due to lack of cross-checking or validation activities and
family/household particulars and population dynamics (immigration/ migration). In addition,
issuance of birth certificate, marriage certificate, Non-Marital certificate, Death Certificate and
Testimonial Letters, municipality house registration, Generation of different required report,
Information request answering service.

Much of the problems mentioned above could easily be avoided through a good filing system
and data management practices. In order to overcome such problems, so we initiate to develop an
automated web based municipality information management system which saves time and
energy to be spent on different tasks, minimize costs and errors, speed up operations, reduces
man power.

1|Page
Structure of Organization
Our project proposal system especially depends on statically and Vital information development
office system computerization in wolaita sodo city municipality information management
system.

Figure 1.1 structure of organization

2|Page
 2. Statement of The problem
There is already manual system at municipality. Everything is done with manual (paper) system.
So for any service a customer has to come to the municipal physically. To further describe the
problem for instance if a customer/resident of the municipal wants to get a new id card he/she
cannot contact the municipal unless he/she comes and take turns before getting service.
Residents also may want to see different types of information without coming physically. The
existing system takes a lot of hard copies. To hold a profile of one customer the existing system
consumes more than two papers. It is known that one paper costs more than 0.60birr at the
current situation and we can calculate how much the system costs to hold profile of thousands of
the people.

 The newly proposed system uses computers which are fast and less coasty. The problem
of existing manual system is stated below.
 The existing manual system the manual system has less security because resident file
stored on paper and every one access it.
 In existing manual system Personal files of municipal residences are lost or misplaced
 The manual system could not generate the reports as needed to the resident.
 In existing manual system resident Information requests are not handled and response
properly
 The manual System has multiple databases in different paper which are not integrated to
get Paper and manual works are much consumes time and budgets.
 The manual system is highly uses municipal resources

The problems stated above are some of the problems on the existing manual system other
problems are also available due to the most of the manual works and there are described in

greater detail on the existing manual system analysis part of the project.

3. TEAM COMPOSITION
The project team has 5 members for the accomplishment of Municipality information
management system for wolaita sodo town. Generally, the task of each member can be express in
a table form as follow:

3|Page
Table 1.1 team composition

Project Municipality information management system for wolaita sodo town

title

S.no name ID no Email address Responsibility

1. Tarekegn firew Ncs/R/485/05 [email protected] -Programmer

-Project manager

2. Gizatu Bekele Ncs/R/244/05 [email protected] -System designer

Group Members

3. Kedija Guye Ncs/R/1512/04 - -System analyst

4 Kuri kussia Ncs/R/301/05 Data collector

5 Alemitu chama Ncs/R/048/05 [email protected] system designer

4. OBJECTIVES OF THE PROJECTS

4.1 GENERAL OBJCTIVES
The general objective of this project is to develop web based or an automated system for
municipality information management system for Wolaita Sodo Town.

 Promote economic development for the society

 Maintain essential public services
 Manage growth or development
 To make comfortable environment for the sodo city residential people
 To make the sustainable environment for future
 To assist all the systems of municipality helped by new technology

4.2 SPECIFIC OBJECTIVES

 To study the existing system of the organization.
 To suggest possible solutions
 To select the best solutions

4|Page
  To specify the functional & non-functional requirements of the new system.
 To analyze of the proposed system using Object oriented.
 To design the proposed system using Object oriented.
 To test & deploy the developed system.
 To give training to users about the developed system

5. SCOPE OF THE PROJECT

There are very wide function of sodo municipal like cadastral system, construction and house
development system, statically and development system office, infrastructure and social
beatification system, land management system and others. But the project is focused on statically
and development office which is one service from sodo city municipal information management
system.As the project title indicates the scope of the system to be built municipality information
management system and related services for the customers. Based on the time and other issues
the scope of the project is limited to the following functionalities.

 Request birth, marital certificates.

 Resident registration
 Request Divorce, Death certificate
 Generate different required reports and manage user information in safe way for the
residents
 Manage, update and delete different accounts

5.1 Target Beneficiaries of the project

Resident

O Can easily access the information from anywhere at any time.

O can get up-to-date information concerning their municipal

O can get any tasks quickly with a great satisfaction

Employees

Can easily access any information through the system anywhere at any time easily
without any difficulty.

5|Page
  Municipal

Municipal information cannot be lost

Cost of labor will be reduced depend on economic feasibility

Due to customer’s satisfaction, the municipal can be selected as a model for deploying
electronic governance

 Project Team

Gain an indispensable knowledge of software development

Get experience in solving real life problem

Experiencing work together with group members

 Students

This project can be used as reference for the coming senior student for the system/project
development

6. Significance of the project

The benefits that are expected after the development of the system. The intervention of ICT in
government offices is very vital because ICT facilitates the services given to the residents. The
proposed system implements ICT, because it is a web based system.

The benefits are listed below:

 The system can save time for the user and resident.
 Gain information about the municipal easily accessible to any visitor of the website
 Reduce resource wastage
 Faster decision making due to the report generation functionality
 Creates Job satisfaction to the customers
 Supplies timely information for users

6|Page
7. Feasibility Analysis
In this phase we have seen different feasibility measures such as, operational feasibility,
technical feasibility, and economical feasibility and schedule feasibilities of the new system.

7.1 Technical Feasibility

The proposed system will be developed by using different languages such as PHP , CSS , html
and vb.net to develop the new system and the group members have enough capability to develop
the project. Since all the project team members are capable of the required technical skills, the
team concluded that the project will be technically feasible

7.2 Economic feasibility

The economic analysis revolves around current market trends; price and alternatives to have the
best option or even to improve on the current option. Therefore, these are discussed below from
the two perspectives tangible and intangible benefits and costs.

Tangible benefits:

O Small response time for various services

O The system can save time for the user and resident

O Easy and fast file management

O Reduced cost expenses for data management

O Easy update & retrieval on stored records

Intangible benefits:

O Reduction in customer complaints

O Better decision making

O Increase in competitiveness

O Increase security

O Improve employees moral

7|Page
O Increase satisfaction of customers

7.3 Operational feasibility

The proposed system can be used effectively after it has been developed. Users will not have any
difficulty with the new system, producing the expected benefits. System will be developed based
on the policies of the organization, it doesn’t require much training for users and the new system
will not place any new demands on users or require any operating changes.

7.4 Political Feasibility

The system behaviorally feasible cannot cause any harm in the environments. The project is
beneficial because it satisfies the objectives of the customer or the organization. The system was
developed user friendly and improves the working environment. It gives services for the people
effectively and efficiently, all the staff holders also agreed before the system developed. So the
government is profitable and the system will be politically feasible.

7.5 Schedule Feasibility

The project is supposed to undergo in a well-planned and organized manner without any time
delay. The proposed system can be implemented in an acceptable timeframe given below.
Project manager is also responsible for monitoring & controlling the project development based
on the schedule.

8|Page
 8. Methodology of the project

8.1 Data sources

The main data source for this project collected from wolaita sodo town municipality information
management system

8.2 Fact-finding Techniques

We would use different methods to collect all necessary data. Fact-finding Techniques is the
most important part of the project to find the main requirement of the system and to understand
how the system does. Among the methods, we use the following:

8.2.1 Document Analysis

We would try to discover all written documents about the organizational areas relevant to the
system. Such as:

O To get information about background of the Organization.

O Different forms used on the current system at municipality

8.2.2 Interview Technique

To have organized and structured system, we would interview some of the concerned groups of
the selected municipal In particular, we would interview the head of public relation office and
chairman of the municipal, to obtain crucial information we need for the project of main data
source for this project is wolaita sodo town municipality information management system.

8.5 System Analysis and Design Approach

We would use object oriented approach for analyzing the gathered data. The main reason behind
using OOA is:

O In order to check the reusability of the current municipality information management

system.

O In order to define new or modified objects that can be combined with the
current municipal information management systems.

9|Page
9. Development Tools to use
We would use various hardware and software in order to develop our system. Some of these are:

9.1 Development Tools.

Activities Tools/programs

Platforms MS windows

Database server SQL/MYSQL

Web server Apache

Server side scripting php

client side coding HTML/DHTML/XML

Client side scripting Java script

Table 1.2 development tools

10. Cost of the project

A. Hardware cost

Table 1.3 Hardware Cost

Required hardware unit Quantity Unit price Total price

computer number 2 10,000 20.000

printer number 1 20.000 20,000

Rewritable CD number 2 10 20

Flash disk number 1 160 160

TOTAL 41,800

B. Software cost

Table 1.4 Software Cost

10 | P a g e
Required software Quantity Unit price Total

Microsoft visual 1 3400 3,400.00

studio 2010

Window 7 profession 1 2500 25,00

Microsoft office2010 1 2500 2,500

SQL 1 300.00 3,000.00

Wamp/xamp 1 Free Free

Dreamweaver 1 FREE FREE

TOTAL 11400

C. Labor cost

Table 1.5 Labor Cost

Development Quantity Hour Cost hour Total

Software developer 2 1616:00 40 129,280

System analyzer 1 1212: 20 29,240.00

Database administers 2 3200: 25 10,000

System designer 1 1414: 20 20,000

Other/data entry 2 1500 10 123

Total 188643

D. Miscellaneous Cost

Table 1.6 miscellaneous cost

Name Quantity Unit price(birr) Total price(birr)

A4 sized paper ream 3 park 85 255.00

11 | P a g e
pen 5 4 20.00

Total 275.00

Summary of the development cost

Table 1.7 summary of development cost

Cause for expense Total price(birr)

Hardware 41800

software 11400

Labor cost 188643

Misleneuos cost 275.00

Total 242118

11. Limitation of the Project

Our project is limited to the followings

The project scope is limited to automate the existing system

The project scope does not automate the whole system of the municipality information
but especially focused on resident people information management in case of time shortage and
wideness of the system

It not works without internet availability.

It cannot automate land administration and tax administration of the system.

Without power there is no service

12. Tasks and scheduleTable1.8 Gantt chart table

tasks Months

No Steps octe Oct26- Nov15- Dec Jan14 Feb12- Mar

t nov 15 Dec15 15-

12 | P a g e
 17- Jan15 Feb- March h
26
15 12 21-

may

1 Proposal
preparation and

presentation

2 Data collection
and

requirement
specipection

3 System analysis

4 System design

5 implementation

6 Testing

7 documentation

Total Over all project

time

2. Chapter Two SYSTEM REQUIREMENTS SPESFICATION (SRS)

2.1 Description of the Existing System

In this section we briefly review the current manual system used by Wolaita Sodo municipality
information management system followed by a brief description of the problems associated with
the current manual system and a proposed system that aim to solve these problems. Currently,
the municipal has manual system. In order to give services, resident register, and collecting
required data from the residents, officers of municipal divide the municipal information into
many segments in order to minimize the boundary they go through house to house.

13 | P a g e
The municipal executive manager assigns representative for each segment. Each segment
representative has a skill, right to ask, collect information, and submit the required information
which is collected from the society to the municipal administration. The collected data should be
accumulate and fill in record office of municipal stastical department. Resident registration is the
most
Player Is part of the manual system?
Resident Yes
Record Officer 1 Yes
Record Officer 2 Yes
Financial Personnel Yes

important task and base for information to make plan for the society. In advance, it helps to
know the statistical data as a whole and have contribution on the development program of the
country. Mostly, resident registration helps:
 To give service for the resident
 To know total number of the residence.
Knowing the number of the residence has an advantage to give services such as:
 To safeguard the society(to assign security police for the municipal)
 To aid for HIV positive people
 To help poor families economically.
 To know educational background of the residence
 To know house number and collect land tax
The municipal knows each and every member by their Identification card (ID), house number
and their segment. When a member comes to the municipal office to get service or to attend
meeting or any other job, he/she must be the member and he/she can register his/her name and
house number with their family member.
.

2.1.1Players in existing system

14 | P a g e
 Table 2.1 Players in existing system

Resident
The resident does not interact with the computerized system rather he/she requests a service from
the record officers of the municipal. The resident then gives necessary information based on the
information needed from that resident. The resident gets his/her requested service from the
record officers.
Record Officer1
This record officer only relate with all services manually; like resident registration and giving
resident certificate card services. Here the record officer asks the residents information and fill
manually on a paper.
Record Officer 2
This record officer interacts with the Birth, Non-Marital, and Death Certificate services. Here the
record officer gives services for every resident of the municipal, who want to this service. In
addition to this, the resident is expected to give correct information to the record officer and
collects all the information then finally put all the collected information on the paper.
Manager
The Manager gets reports from the record officers manually. The reports help the manager to see
how services are given to the residents and predict future outcomes.
Financial Personnel
The financial personnel is the one who receive the payment from the resident. This is done
whenever the resident is approved to any kind of service and gets the provided service

2.1.1Major Function activities in current system

 Agreements and public record keeping department
o Resident Registration
o Giving Birth Certificate
o Giving Non Marital certificate
o Giving Death Certificate
o Divorce certificate
 Information and public relations office
o Telling the information for client provided by the municipal
o Giving the information when the user needed
 Main Executive office
15 | P a g e
 o Generate report
o Control the overall activity of the municipal

2.1.3 Business rules

NAME: - Request for Birth Certificate
ID: BR1 -
DESCRIPTION:-
 Every applicant must be a member of the municipal
 The resident must have one of the following
o a renewed id card with full information
o Refugee resident paper which can describe the nationality.
 Require a hospital evidence document to confirm whether the baby is born in
wolaita sodo town municipal office and evidence from embassy which approved
by ministry of foreign affairs.
 Required a legal evidence from ministry of women affairs for adoption makers
 The babies who don’t have a parent require a letter from the executive to approve
the baby parent had an Ethiopian nationality.

NAME: - Request for Non Marital or Marital Certificate

ID:BR2 -
DESCRIPTION:-
 requires a renewed id card with full information
 Present evidence which can confirm he/she has no marriage previously or after divorce or
after his/her wife/husband death.
 Present evidence which confirm that the person has no marital relationship status
 Required two passport size photograph which has been taken at most before a month
 Pay 50 birr for Ethiopian resident, 300 birr for foreign resident according to the current
municipal office.

NAME: - Request for Death Certificate

ID: BR3-

16 | P a g e
DESCRIPTION:-
 Present evidence document from hospital, workers social affairs and court decision with
photograph.
 Evidence from police station
 Evidence from organization which made a grave ceremony
 Required a written paper from embassy approved by ministry of foreign affairs.
 Pay 100 birr.

NAME: - Request for divorce Certificate

ID: BR4-
DESCRIPTION:-`
 The resident must bring a letter which describe he/she wants to the case of divorce
 The municipal may accept the resident based on the availability of house, if he/she wants
to come the judgment on their municipal
 The resident must finish all his/her agreement on their status

2.1.4Report generated in Existing System

Different reports are generated in the existing municipal information management system of
sodo town. Reports are generated based on the general information about a resident people in
sodo town. This report helps the municipal gathering and predicting information Other types of
reports are prepared monthly depending on Registered residents of the municipal per month and
annually. Reports and summaries are the fundamentals of any business organization. They tell
how the business is running at any given time with specified quires of the party that require those
reports and summaries and all the reports are in manual paper or orally.

2.1.5Forms and Other documents of Existing System

There are different forms and reports used by the municipal for various purposes. Among the
forms and reports used around the municipal information management system, all of them are
manual. And still some of the forms are used only in Amharic form only while others have
English too. Some of Forms are used manually and are not integrated into the existing
computerized system.

Some of those are:-

17 | P a g e
  Forms for generating Death and non-marital certificate
 Birth certificate
 Marital certificate
 death certificate
 Resident registration forum
 Divorce certificate

The following are some forms of the existing system

Figure 2.1 Birth certificate

18 | P a g e
Figure2.2 Marriage certificate

19 | P a g e
Figure 2.3 Death certificate

2.1.6Bottlenecks of the existing system

The problems of the existing system are described using the PIECES framework. This
framework is used to identify the problems within an existing system. Therefore the problems
indicated are dealing only with the existing manual system
Performance
We express the performance of existing system in terms of:-
 Throughput: – the current manual system has a low level of throughput because it can
only handle limited number of residents at a time.

20 | P a g e
  Response time: – the response time to a given task in the current manual system is
significantly low due to the time taken to get the accurate information of residents and
different organizational data takes much time.
Information (and Data)
 Outputs

 The manual system generates information on paper for clients; any other information
output is done manually.
 It is difficult to produce needed information at one time

 Inputs

 Data is not accurately captured( contains errors )

 Stored Data

 Data is not secure – anyone who opens the paper, can access all the contents of the
database
 Data is not well organized –data put different place within different paper
 Data is not flexible – not easy to meet new information needs from stored data
Only predefined reports can be generated from the stored data
 For instance, the manual system cannot store information such as resident relation with
government, history of residents, and role of the residents in their municipal.

Economics

 Costs

The manual System take much cost. Since a budget is set by the municipal once, if price changes
occur the manual system may be pushed to cut some of its functionalities.

 Profits

The Existing manual system is use labor force and hard copies, since it is not profitable.

21 | P a g e
 Control (and Security)
 Too little security or control
 Input data is not adequately edited
 Ethics are breached on data or information – refers to data or information getting to
unauthorized people
 Data privacy regulations or guidelines are being (or can be) violated
Efficiency

 Large human resources, waste time

 Information is unwontedly generated.

Service
 The manual system is inflexible to new or exceptional situations
 The manual system is inflexible to change The manual system

2.2Description of Proposed System

The new system deals with automating system of municipality. the newly proposed system is
efficient in facilitating different tasks like resident register, different types of municipal resident
people certificate, request marital and non-marital certificate, report generation and request
certificate and other certificate. The proposed system is also efficient in file handling system.
The major thing in the proposed system is authenticate users to use the system. Authorized users
only access the system. Unauthorized person is not allowed to access the system; they are
prohibited by user name and password mechanism.
The need to develop automated system of the municipality is that the current activities of the
municipal were time consuming due to manual system which results affects the development of
the municipal.
The proposed system also has request form to give certificate for the resident for the purpose
they need. It might be birth or marriage certificate and others. The proposed system has
computerized system to give automated service rather than manual system.
 Registrar system module incorporates: resident registering, report generating, and request
certificate and other letter.
 The system facilitates each registration done by the municipal at short period of time.

22 | P a g e
  In order to register each person, the system first checks if he/she resident but manual help
is needed.
 The system gives accelerated service for all users.
 The system can search required information.
 The system control customer information as needed
 The system can save for the user and resident.
 It is easy to update and delete information.
 It has secured, because the user can only enter into the system by login.
In addition, the system uses session control method for more secured working environment.
That means, any person who knows the URL of a specific form cannot get it directly without
login. The system identifies the unauthorized user by the incorrect entered user name and
password. Any unauthorized person can't enter in to the system. Automated system can manage
all database of the municipal System identifies registered person and unregistered person by
reading from database.

2.1.1Requirements of the proposed system

2.2.1.1. Functional Requirements

The functional requirements for the new system that will replace the existing manual system
include:
Data storage and retrieval: All the resident file record information should be kept properly in
well-organized data base; so that retrieving these files will be easy and faster.
 The system should provide password changing facility
 The system should provide user authentication mechanism.
 The system should be able to generate report.
Data entry:
This is the functionality that data is entered to the systems. The system serves different interface
that can manage data entry mechanisms in the municipal. The main data entries are the
following:

 Registration
 Data update
 Login

23 | P a g e
  Search information
Data processing
 The system on input data will provide the following data processing:
 Resident registration
 Verify the requested information
 Report generation

2.2.1.2Non Functional Requirements

User interface and human requirements

The system provides web based application user interfaces that are compatible with any
platforms.

Hardware Requirements
The municipal should have computers, printer and scanner having typical storage capacity and
processing speed.

Software requirements
The municipal should have Apache server on the computer having typical storage capacity and
processing speed. In addition, the municipal should have internet explorer, Mozilla and some
anti-spy wares in order to protect the database from spy.

Security issue
In order to make the system safe from unauthorized access and modification, the system uses a
login account to differentiate among the different users of the system on the organization side.

This enables the system to verify who has logged in using the correct logging account provided
and display the right form associated with that user.

Performance characteristics
The system is accessible by specified actors in the municipal. It should be given more emphasis
for the speed to access it.

24 | P a g e
Error handling
This system handles error. When the user enters wronginputs, the system send error message.

Quality issue
Information in database should be accurate, updated, delete.The system modifications
The system should be easily modifiable and recoverable by system

Chapter 3: System model

Introduction
This chapter is about Analysis of the proposed wolaita sodo town municipality Information
Management System. The system is analyzed using different UML analysis modeling
techniques, which, includes, use case diagram, use case documentation, sequence diagram,
activity diagram, and analysis class diagram.

3.1. Use case diagram

Designing the system use case diagram

A use case is a sequence of action that provides a measurable value to an actor. A use case
describes a way to which a real world to interacts with the system. An essential use case
sometimes called a business. The case is simplified, abstract, generalized use case that captures
the intention of the user in a technology and implementation independent manner.

The case models are used to document the behavioral (functional) requirement of a system.

 A use case describes a sequence of action that provides a measurable value to an actor
and draw as a horizontal ellipse.
 An actor is a person, organization, or external system that plays a role in one or more
interactions with the system and draw as stickman figure.
Relationship between actors and use cases exists whenever an actor is involved with an
interaction described by a use case and modeled as a line connecting use cases and actors.

25 | P a g e
 Register Resident

Manage
<<include>>
Request Certificate Acount
<<include>> Administrator
Generate
Login <<extend>>
<<include>> Report
<<include>> <<include>> <<include>>
Search information Manage User
Resident <<extend>> <<extend>>
<<include>> <<include>>

Delete
Creat Acount Update Acount Delete Acount Comment <<extend>>

Figure 3.1 use case diagram

3.1.1. Actor specification

An actor represents a coherent set of roles that are entities external to the system can play
in using the system, rather than representing a particular individual. An actor represents a
type of users of the system or external systems that the system interacts with

Those are:-

 Resident people
 System administrator

Use Case Identification

26 | P a g e
ID Use case name Include/uses
UC1 login UC1
UC2 Register resident UC1
UC3 Request certificate UC1

UC5 Create resident account UC1

UC6 Search organizational information UC1

UC7 Update information UC1

UC8 Generate report UC1

UC9 Manage user UC1

UC10 Delete Account UC1

Uc11 Delete comment UC1

Table 3.1 use case identification

3.1.2. Use Case Description

name login
ID UC1
Actors Resident, System Administrator,
description Resident will authenticated and taken to their
own Resident interface

Pre-condition Resident must get an account from the system

administrator

Post-condition Resident is authenticated and taken to his/her

own Resident interface

27 | P a g e
 1.The Resident opens the main home page by
writing the URL of the website
Basic course action 2.the system display the Main Home page
3.The user inputs user name, password and
submits
4. The system validates the account and
displays the user require information

A If the login name or password is invalid

4.The system displays invalid user name or
password message
Alternate course action
5.The user reenters the user name and
password
6.The use case continues from step 4 at three
times.

In this part of the project we described the use cases that are identified in the use case
identification and also drawn on Fig.

Table 3.2 login use case description

NAME Register Resident

28 | P a g e
ID Uc2
Actors System Administrator

description System administrator register resident.

Pre-condition The System Admin must log on to the system

Post- condition The Resident registers with full information

about himself/herself.

1. The system displays Admin Home

Page
2. Admin invoke the Register resident
page
Basic course action 3. System admin fills the necessary
information and
Marks on the accept obligation
check box and submit
4. The System displays “successfully
Registered” message
5. Use Case Ends

: If the submitted form is not filled

completely or invalid.
5.The system displays “unsuccessful”
Alternative course action
message and turn to step4
6.The resident fills the missing information
and corrects invalid inputs
7.The use case continues from step 5
Table 3.3 registers resident use case description

name Request ID card

ID UC 3
Actors resident
Description Resident request id card
Pre-condition Resident must log in the system

29 | P a g e
Post condition The Resident request waits for system
administer validation
uses login
Basic course action 1. The Resident invoke on the Request ID
card
2. The System displays the ID card
Service Page
3. The Resident fills the necessary
information and
Marks on the accept obligation check
box and submit
4. The System displays “Request sent ”
message
Use Case Ends

Alternative course action A: If the submitted form is not filled

completely or invalid.
A4.The system displays “unsuccessful”
message
A5.The resident fills the missing information
and corrects invalid inputs
A6.The system display “the Request is sent” message

Table 3.4 request ID card use case description

name Request certificate

ID UC4
Actors Resident
Description The Resident requests certificate
Pre-condition The Resident must log onto the system

30 | P a g e
Post-condition The Resident request waits for system admin
validation
uses login
1. The Resident invoke on the Request
Certificate
2. The System displays the Certificate
Service Page
Basic course of action
3. The Resident fills the necessary
information and
Marks on the accept obligation check
box and submit
4. The System displays “Request sent ”
message
Use Case End
If the submitted form is not filled completely
or invalid.
4.The system displays “unsuccessful” message
Alternative course of action
5.The resident fills the missing information
and corrects invalid inputs
6.The use case continues from step 4

Table 3.5 request certificate use case description

31 | P a g e
name Create resident account
ID UC5
Actors System Administrator

Description The System Administrator gives account for

different Resident

Pre-condition Residents must be a member of a municipal

and that resident information must be
registered, the Resident must be known by
the System Administrator

Post-condition A new user account will be created

uses Register Resident Information

The System Administrator records the

intended user name, password, selects from
when Resident registration time and submit.
Basic course action
2.The System display ” successful message
“ and the created account information to the
System Administrator
5.The Use Case Ends

Table 3.6 create resident account use case description

Name Search information

ID UC6
Actors Resident
Pre-condition
Post-condition The Resident get the intended information

. The Resident invokes on the search

32 | P a g e
 information and forward.
2.The System displays the search organization
Basic course action
information page
3. The Resident/Non Resident writes the search
query and forward the search
4.The System Displays the search output
5.Use Case End

Table 3.7 search information use case description

name Update account information

ID UC7
Actors System Administrator
Description System admin update information
Pre-condition The System administrator must login

Post-condition Update information

uses login
the System administrator Updates un updated
news and other information and submit
Basic course action
2.the system display the updated information to the
main Home

Table 3.8 update account use case description

name Generate report

ID UC7
Actor administrator
description use case to generate report
Pre-condition the manager he/she an employee and have
managerial skill about human resource and
should have skill to integrate different
information.
Post condition The system displays a report
uses LOGIN

33 | P a g e
Basic course action 1. Include login use case.
2. Manager activities the report interfaces.
3. Manager selects the report type from the
displayed report link.
4. System responds by responding criteria
form.
5. Manager set the criteria according to his
or her requirement and clicks the display
button.
6. System responds by displaying report
extracts from the data base.
7. Use case ends.
Table 3.9 generate report use case description

NAME MANAGE USER

ID UC9
Actor administrator
Description The System Manager manages Resident
accounts
Pre-condition The System Admin must log on to the system
Post-condition The System Admin will update accounts
includes login
Basic course action 1. The System Administrator wants to
manages Resident account
2.The System displays the System
Administrator Home Page
3.The System Admin selects the
account to be validated(activated)
4.The System Admin updates the
selected account
5. Use Case Ends

Name Delete Account

ID UC10

34 | P a g e
Actor Administrator
Description Describe in detail, Remove user account from
system if it is unnecessary

Precondition Administrator must be suitable to login and the

existed account is invalid or not functional

Post condition The account has been removed or deleted from

the system

Includes Login
1. The admin click on the delete account link on
Basic course action
2.the administrator page.
3. Select the account which is deleted then click
on delete.
4. The system validates the deletion.
5. The system displays the successful message.

6. Use case ends

Table 3.10 delete account use case description

Name Delete comment

ID UC11

Actor Administrator

Description Use case deletes the comment.

Precondition Manager able to delete the message after seeing

the message

Post condition The system displays the comment form

35 | P a g e
Includes Login
1. Include login use case.
Basic course action
2. Manager activates the delete form.
3. Manager selects the delete comment
link.
4. The system displays the prompt.
5. Manager clicks the delete button.
6. System responds the comment has been
deleted.
7. Use case ends

Table 3.11 delete comment use case description

3.2. Class modeling

Class diagrams are used to describe the structure of our system. Classes are abstractions
that specify the common structure and behavior of a set of objects in our new system. Class
diagrams which we are going to design describe the system in terms of objects, classes,
attributes, operations and their association. In the following section we will present the class
diagram with its corresponding objects.

36 | P a g e
 Administrator
Resident Rid varchar(10)
Fname varchar(15)
Rid varchar(10) +1 +n Mname varchar(15)
Fname varchar(15) User Acount
Mname varchar(15) Lname varchar(15)
Lname varchar(15) Username varchar() +1 Age int
Age int Password varchar() Sex varchar(5)
Sex varchar(5) Login() Nationality varchar(10)
Keble varchar(10)
+1 +1 Phone int
Birth_date int
House NO int Create()
Town varchar(10) Update()
Nationality satus Varchar(12) +1 Delete()
phone int View()
Register() +1 Request +n
Request()
Search() Rid varchar(7)
+n +1
Request type varchar(15) Request ID card
+1
Status varchar(9)
+n Date int Request ID Varchar (12)
Manager register() Fname varchar(15)
Mname varchar(15)
-memberNameRid varchar(10) Lname varchar(15)
Fname varchar(15) Sex varchar(5)
Mname varchar(15) +1 Age int
Lname varchar(15) birth date int
Age int Nationality varchar(12)
Sex varchar(5) Jobs varchar(10)
Keble varchar(10)
+1
Place of birth varchar(12)
Birth_date int
House NO int
Town varchar(10)
Nationality satus Varchar(12)
phone int
Search()
Figure 3.2 class diagram

37 | P a g e
 3.3. Dynamic model

3.3.1. Sequence Diagram

A sequence diagram is a UML interaction diagram. It represents the chronology of the passing
of messages between system objects and actors. It may be used to illustrate a possible scenario of
a use case, the execution of an operation, or simply an interaction scenario between classes of the
system.

You can use one or more sequence diagrams to pass a use case or to identify all the possibilities of a
complex behavior. A sequence diagrams conveys the same kind of information it concentrates on the
chronology of messages passing between the objects in place of their structure.

A sequence diagram shows actors, objects (instances of classes) and the messages sent between them. By
default, Power Designer provides an "interaction frame", which surrounds the objects in the diagram.
Messages can originate from or be sent to any point on the interaction frame, which acts as the exterior of
the system being modeled, and these gates can be used in place of actor objects.

38 | P a g e
 Administrator,Re
sident and
Manager can
responsible for
Login

figure 3.3 Sequence diagram for login page

39 | P a g e
 actor
Registration Regisrtation Registration
Administrator Database
link forum controller

1.select
Resident
registration link
Registration forum
2.Registration
request
3: dislpay
registration
forum
4: Fill
Registration
forum 6: check validate
7:validate
5:click on submit forum
button
8: invalid 9: step 4
registration continue
10:display
success
messege

Figure 3.4 Sequence diagram for resident register

40 | P a g e
 Resident
1.Resident
Resident activities
Search
Information

10.displays
retrived info

Figure 3.5 Sequence diagram for search information

41 | P a g e
 actor
Request Certicate Certificate
Resident Database
certificate link request forum request controller

1.select Request
Resident Request type from link
Certificate
2.Request
certificate forum
3: display
Certificate forum

4: Fill Certificate
forum
6: go to 7:validate
5:click submit controller

8 try again 9: step 4

continue

10:display
success
messege

Figure 3.6 Sequence diagram for request certificate

Fig3.7 Sequence diagram for delete account

42 | P a g e
 Figure 3.8 Sequence diagram for ID card request

Figure 3.9 Sequence diagram for generate report

43 | P a g e
Fig3.10 Sequence diagram for update account information.

44 | P a g e
Fig 3.11 Sequence diagram for delete comment

3.3.2. ACTIVITY DIAGRAM

An activity diagram illustrates the dynamic nature of a system by modeling the flow of control
from activity to activity. An activity represents an operation on some class in the system that
results in a change in the state of the system.

45 | P a g e
Typically, activity diagrams are used to model workflow or business processes and internal
operation. Because an activity diagram is a special kind of state chart diagram, it uses some of
the same modeling conventions.

Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities.These
additional capabilities include branching, parallel flow etc.

46 | P a g e
Fig 3.12 Activity diagram for login page

Fig 3.13 Activity diagram for generate report

47 | P a g e
 fill user name and
password
Select type of user

click on login Button

[Invalid]

[vaid]

System display
Admin UI

Click on Resident
registration Button

System display
Registration Form

Fill the form

[invalid]

[valid]
Syytsem display
success message

Figure 3.14 Activity diagram for resident registration

48 | P a g e
Figure 3.15 Activity diagram for search information

49 | P a g e
 Fill user name and
password
Select type of user

Click on login
button

[invalid]

[valid]

System display
Resident UI

Click on Request
Certificate Button

System display
certificate form

Fill the form

[invalid]

[valid]

System display
success message

Figure3.16 Activity diagram for Request certificate

50 | P a g e
Figure 3.18 Activity diagram for update account information

51 | P a g e
Fig3.19 Activity diagram for delete account

Fig 3.20 Activity diagram for delete comment

52 | P a g e
 3.4. User interface prototyping

HOME PAGE

LOGIN PAGE HOME PAGE RESIDENT ADIMINSTRATION

REGISTRATION PAGE
Home
PAGE
Home
Request
Check Home
certificate Home
Account Account
About Us Account Generatrepo
Account
registarion rtDelete
Account Certificate register comment
Generate Report
Account
registration Account
Search information Account
Resident register

Search
Maager
Login Login search
Update and
create account

Delete
Figure 3.21 user interface prototype

53 | P a g e
 4. CHAPTER FOUR SYSTEM DESIGN

4.1. Introduction
This chapter mainly concerned with the design part of the A Senior Project Proposal
On Municipality Information Management system in case of wolaita sodo town. In
order to make the implementation easy to develop. In this section we would see the
different type of class type architecture such as user interface layer, process/control
layer, business/domain layer, persistence layer and system layer and also different
types of system modeling techniques that are used for the implementation of the
system such as class modeling, state chart modeling, component modeling,
deployment modeling and also some system design techniques such as user interface
design are also to be covered in this design chapter.

The goal of system design according to the proposed project is to manage complexity by dividing the
system into smaller, manageable pieces and to increase the system:-

 Efficiency: the system doing something well and thoroughly without waste of money and
time.
 Flexibility : the system able to change to suite new condition or situation
 Security: the system should be secured, i.e. not allow unauthorized users to access the
system.
 Reliability: the system should be reliable

4.2. Over view of system design

Systems design is the process of defining the architecture, components, modules, interfaces,
and data for a system to satisfy specified requirements.

Systems design is therefore the process of defining and developing systems to satisfy
specified requirements of the user.

There are three overview of system design methods

54 | P a g e
Architectural design

The architectural design of a system emphasizes on the design of the systems architecture which
describes the structure, behavior, and more views of that system and analysis.

Logical design

The logical design of a system pertains to an abstract representation of the data flows, inputs and
outputs of the system. This is often conducted via modeling, using an over-abstract (and
sometimes graphical) model of the actual system. In the context of systems, designs are included.
Logical design includes entity-relationship diagrams (ER diagrams).

Physical design

The physical design relates to the actual input and output processes of the system. This is
explained in terms of how data is input into a system, how it is verified/authenticated, how it is
processed, and how it is displayed. In physical design, the following requirements about the
system are decided.

 Input requirement
 Output requirements
 Storage requirements
 Processing requirements
 System control and backup or recovery.

Put another way, the physical portion of systems design can generally be broken down into three
sub-tasks:

 User Interface Design

 Data Design
 Process Design

User Interface Design is concerned with how users add information to the system and with how
the system presents information back to them. Data Design is concerned with how the data is
represented and stored within the system. Finally, Process Design is concerned with how data

55 | P a g e
moves through the system, and with how and where it is validated, secured and/or transformed as
it flows into, through and out of the system.

At the end of the systems design phase, documentation describing the three sub-tasks is
produced and made available for use in the next phase.

Physical design, in this context, does not refer to the tangible physical design of an information
system. Database structure processor and a control processor. The personal specification is
developed for the proposed system.

4.3. Design goal

Design goals identify the qualities that our system should focus on. Many designing goals can be
inferred from the requirements of the system. Additionally designing goals are elicited from the
users. It is, however, necessary to state them explicitly such that every important design decision
can be made consistently following the same set criteria. The system should satisfy the
requirements of the user in a technically acceptable level.

The objectives of design are to model the system with high quality. Implementing of high quality
system depend on the nature of design created by the designer. If the system needs repair or
rebuilding then the whole process will be dependent on system design, so if the whole system is
designed effectively and precisely then it is easy to make change in the system.
The design goals include:-
Performance criteria:
Performance criteria reflect how the system is expected to behave under normal operating
condition. This includes the throughput and memory requirement of the system.
Throughput: The system can be accomplished by different users at the same time because of the
system designed is as client-server architecture. The database server reopened to each user based
on their request at the same time.
Memory requirement: The application will run on at least 250MB of RAM according to the
specification.

Dependability criteria

56 | P a g e
These criteria determine how much effort should be expanded in minimizing system crashes and
their consequence, and how available the system should.
Robustness: The software handles invalid user input. This can be done by using different type of
exception handling mechanism. This enables the software not to be suspend even if the user
insert invalid input.
Reliability: The system is expected to accept inputs and requests from the user and make the
necessary execution. The systems accept all valid user data and produce the expected output.
Fault tolerance: Fault may originate in a system level, in the system environment, or in the
interaction between user and the system. Some of the faults that may occur include: computer
failure, system failure due to virus, unauthorized user. The system tolerate the error occur due to
user-system interaction using proper execution handling methods.
Maintenance criteria
Maintenance criteria highlights how new functionalities can be added to the system in the future.
Modifiability: To realize this goal the system will be well-documented. Proper documentation
must be done at every phase of the system development. Documentation will include
Requirement Analysis Document, and System Design Document.
Portability: The system works in different plat form and operating system.
Readability: The code will be easily readable and understandable by other programmers. To
achieve this goal we will supplement the code by proper naming convention, proper indentation
and comment
Design goals and strategies
A Design Goal is a category that corresponds to a particular implementation goal. Each Design
Goal includes one or more Design Strategies. A Design Strategy contains process properties that
are set to achieve a Design Goal.

Balanced - provides a balanced implementation of timing performance and runtime. This

Setting

Is the default for all new projects and includes the default values for all process properties.

Minimum Runtime - attempts to meet timing constraints as well as reduce runtime.

57 | P a g e
 Power Optimization - attempts to meet timing constraints as well as reduce power
consumption.

Timing Performance - attempts to meet timing constraints as much as possible. It

performs additional optimization and uses higher effort levels to try to achieve timing
performance, based on your timing constraints. This extra effort will most likely increase
runtime.

4.4. The Proposed Software Architecture

Here we design the conceptual model for the proposed system that describes the relationship
major participant in the sodo town municipality information management system. There is Sodo
town resident people who are beneficiary of use a computerized sodo town municipality
information management service. The housing agency provides the necessary technical and
financial infrastructure to facilitate computerized condominium distribution and management
system. The system administrator registers all the users of the system and creates account for
them and specifies their privilege. After the registration of the users of the system the
municipality allows any type of certificate seeker to register online by opening the webpage and
the system checks all the information of the seeker by accessing the Keble database. The
proposed system has relation with other system like Keble administration to receive the list of
information that verify the information seeker is member of sodo city Keble administration and
access the data of the requesting system and check whether he/she can register for city
municipality. The high level description diagram for the proposed system look like the following

Municipality system: - is a system that contains all the basic data’s of each resident of the
members. The data it contains include the basic member recorded, the married data and the
certificate recorded of each resident in the town.

Wolaita sodo city municipality Management system architecture: The proposed software has
three layers of architecture. The layers are the following:-
 The application layer
 Logic/ connector layer
 Database layer

58 | P a g e
Application layer: Layer which provides graphical user interface and application specific entry
Forms to the user of the system. Application layer interact with logical layer through http
protocol.

Logic layer: Layer that used to implement business rules and data rules, which keep the data
structure consistent.
Database layer: This actual DBMS layer. Used to assist resource sharing and allow the client to
be configured with the help of ODBC driver.

Figure 4.1 proposed software architecture

Software architecture for wolaita sodo municipality information management

.system

59 | P a g e
4.5. Hardware/Software mapping
Wolaita sodo town municipality information Management System) is a web base application.
The web server can run on any computer that support PHP and its database can run on any
computer that supports MYSQL. The application server, web server and database can be run on
separate node or the same node in different configuration. The diagram below depicts the
hardware/software mapping of wolaita sodo city municipality information management.

Figure 4.2 Hardware and software mapping for the proposed system

60 | P a g e
4.6. PERSISTENT DATA MANAGEMENT
Persistent data management is all about permanent data that are stored and how they should be
managed. The Certificate and information seeker data should be permanently store. The Resident
people data must be stored permanently because it is used to check whether the information
asker is sodo city resident or not. The user name and password of each user must be registered
permanently to identify the user is system administrator, city resident or user of the system. The
details of residents’ information also stored in permanently.

4.6.1. Database design

Database design is transforming an E-R model and their data specifications design into a
normalized relation. A relation is a named, two _ two _ dimensional tables of data, having set of

Named columns and an arbitrary number of unnamed rows, each column in a relation
corresponds to an attribute of that relation and each row of a relation corresponds to records that
contain data values for an entity. Well-structured relation corresponds to records that contain a
minimum amount of redundancy and allows users to insert, modify and delete the rows without
errors or inconsistencies. It is the process of converting complex data structures into simple,
stable data structures using a process called normalization.

61 | P a g e
Figure 4.3 Database design for the proposed system

62 | P a g e
4.6.2. Entity Relationship (ER DIAGRAM)

Figure 4.4 Entity relationship diagram for the proposed system

4.7. User Interface Design

63 | P a g e
Figure 4.5 User interface for Home Page

64 | P a g e
Figure 4.6 User interface Administrator page

65 | P a g e
Figure 4.7User interface for resident registration forum

66 | P a g e
Figure 4.8 User interface for login page

67 | P a g e
 Chapter Five:

Implementation and Testing

5.1 Introduction
In this chapter we mainly focuses on the implementation part, implementation concerned with
the type of material (Hardware and software required), user manual preparation, techniques to
develop the system, algorithm for the system, code samples of the system, data preparation, how
to install the system, some testing techniques, start up strategy for the new installed system are
briefly described in this part of documentation.

5.2 Final Testing of the system

� To ensure that during operation the system will perform as per specification.
� To make sure that system meets the user requirements during operation
� To make sure that during the operation, incorrect input, processing and output will
Be detected
� To see that when correct inputs are fed to the system the outputs are correct

� To verify that the controls incorporated in the same system as intended

The software developed has been tested successfully using the following testing strategies and
any errors that are encountered are corrected and again the part of the program or the procedure
or function is put to testing until all the errors are removed

White Box Testing

White-box testing tests internal structures or workings of a program, as opposed to the
Functionality exposed to the end-user. In white-box testing an internal perspective of the system,
as well as programming skills, are used to design test cases. The tester chooses inputs to exercise
paths through the code and determine the appropriate outputs.
Black Box Testing
Black Box Testing attempts to find errors in following areas or categories, incorrect or missing
functions, interface error, errors in data structures, performance error and initialization and
Termination error. Here all the input data must match the data type to become a valid entry.
The following are the different tests at various levels:
Unit Testing

Unit testing is essentially for the verification of the code produced during the coding phase
and the goal is test the internal logic of the module/program. In the Generic code project,
the unit testing is done during coding phase of data entry forms whether the functions are
working properly or not. In this phase all the drivers are tested they are rightly connected or not

Integration Testing

68 | P a g e
All the tested modules are combined into sub systems, which are then tested. The goal is to
see if the modules are properly integrated, and the emphasis being on the testing interfaces
between the modules. In the generic code integration testing is done mainly on table
creation module and insertion module.

Validation Testing
This testing concentrates on confirming that the software is error-free in all respects. All the
specified validations are verified and the software is subjected to hard-core testing. It also aims at
determining the degree of deviation that exists in the software designed from the specification;
they are listed out and are corrected.
System Testing
This testing is a series of different tests whose primary goal is to fully exercise the
computerbased
system. This involves:
� Implementing the system in a simulated production environment and testing it.
� Introducing errors and testing for error handling.

5.2 Hardware software acquisitions

For the proper functioning of the system the following hardware and software are
required

 Hardware’s

 Computer

 CD/DVD disk

 Software’s

 Wamp server
 Internet explorer, Mozila Firefox,Baidu browser
 ,notepad++ ,Adobe dream weaver, CSS

5.3 User manual preparation

Steps1

 Activate wamp server from the Desktop or Start up Menu if it’s not
activated.

69 | P a g e
 Click on start - >wamp server

70 | P a g e
Step2

 From the start menu click on start->All programAccessories Run

Steps3

 In the run Dialog box type the URL of the page (example
http://localhost/municipal.php) and the click“OK”button

After the application have been installed and tested the system is ready to be functional and then
preparation could begin to place the new system in to operation. Hence, in order the new system
to be operational the new system should be loaded with the existing data from the old system.
The start-up strategy used is parallel conversion strategy, means the old system and the new
system will operate simultaneously for some time, because the defect of the new system will be
identified if any, before the old system is abandoned and until get user acceptance

71 | P a g e
 5.5 Training

During the deployment of the system, the project group members will give short time training for
the system administrators and wolaita sodo town resident peoples explaining how the system
works and in what way the user can use the automated system and
They can manage their system.

5.6 Installation Process

After installing both notepad++ and wamp server software do the following steps

Step1

 Get the folder “Final project “from the Developing Team.

Step 2

 Copy the folder to WWW folder in the c: \wamp\www

After doing these steps again, copy the folder “municipal data” from the Developing
Team then.

Step3

 Paste into the folder ”data “in the C: \Wamp\www\Data

Step4Installation is finished.

5.7 Start-up strategy

The current system will be in parallel with the new municipal information management system in the
wolaita sodo town for the resident people that do not
use the computerized system. In view of this fact the team recommends parallel startup strategy for the
System.

72 | P a g e
 Chapter Six:

Conclusions and Recommendation

6.1Conclusion
An effort has been made to study wolaita sodo town municipality information management
system as partial fulfillment of BSc degree in information Technology. In doing the study the
team has tried to follow object oriented system analysis and design methodology.

Since the success and failure of any system depends on gathering the right information through
different fact-finding techniques and user involvements, the team has made the best effort to
gather requirements. After a detail review and study of the existing system of HRM models have
been designed to reflect the new system that is suppose to solve problems.

Designing computerized wolaita sodo town municipality information management system helps
to maintain a computer based information management system.

In order to solve different problems existed the team has tried to propose a solution that at least
reduce the existed problems and model the proposed system using different tools and
methodologies. We believe that different tools and techniques has helped us a lot in capturing
real user requirements and model the right system for the users for their day to day transactions.
Thus it should have the precedence in know-how and experience in collecting, processing and
utilizing information.

6.2 Recommondations
As its obvious the use of and advantage of computerized systems over manual information
systems, we strongly recommend wolaita sodo town municipality information management
system to implement our new system in order to achieve capabilities like reliable data keeping
,fast data processing and transmissions , well defined communications among departments
,sharing a single database and so on.

It’s true that our country’s is yet developing country that most things are done manually which in
turn is affecting our economy, and new systems like our systems should be adopted so that it
highly reduces the burden of the municipal. And make the service recipient happy. Which clearly
notify the saying “simplicity is the ultimate sophistication.

73 | P a g e
 Appendix

HTML………………………...hypertext markup language

PHP…………………………...hypertext preprocessor

SQL…………………………..Structural query language

CSS……………………………Cascading style sheet

OOA………………………… Object oriented approach

XML………………………….Extensible Markup language

UC……………………………Use case

CD……………………………Compact disk

UML…………………………Unified modeling language

BR……………………………Business rule

SRS…………………………System requirement specification

ER………………………….entityrelationship

74 | P a g e
 Reference
1. J.Duncan System analysis and design 5th edition
2. Elmasri, Ramex. Fundamentals of database systems.2 nd .ed.Redwood city, CA:
Benjamin Cummings publication
3. [http://e-articles.info
4. Internet with important URL like http://www.w3schools.com/php
5. Internet with important project work in http://www.project work.com/writing

6. Project in information technology website.info/com

75 | P a g e
76 | P a g e
1|Page
2|Page
3|Page
4|Page
5|Page
6|Page