WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEM

Project Title: - Ethiopian Insurance Information Management

System for Wolikite Branch

Prepared By:

Name ID No.

1. Dawit Berehana CIR/038/05

2. Dechasa Tesfaye CIR/035/05
3. Getahune Addis CIR/061/05
4. Getaneh Megeresa CIR/062/05
5. Mekuanenet Lamesgen CIR/082/05

Advisor Mr. Fasil

Wolkite, Ethiopia February 2016

 APPROVAL SHEET
WOLKITE UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS
DEPARTMENT OF INFORMATION SYATEM
Title:-
This Senior Group Project en-titled Ethiopian Insurance Management System for Wolkite
Branch Documentation has been read and approved as meeting Senior Group Project
requirements of the Department of ___________ in partial fulfillment for the award of the degree
of Bachelor in __________________, Wolkite University, Wolkite, Ethiopia.

This Senior Group Project has been approved with the signature of advisor and Department of
_______________________________.
Name and signature of Members of the evaluator of advisor and Department.

Name Title Signature Date

_________________________ Advisor, _______________ ________________

______________________Department head ______________ _________________

 Acknowledgement
First of all we would like to thank GOD keeping us healthy to do this project. Next thanks to our
adviser Mr. Fasil for his advising, guiding and gives necessary comments until the completion of
the documentation of the project. And also we would like to say thanks Mr. Gashew for his
support and his guiding for the developing of this project documentation. Deeply would like to
say thanks Ethiopian insurance employees in Wolkite Brach for giving us full information about
how the current system work. Finally thanks to group members and other peoples who support us
for our project document completion.

i
Table of content
Acknowledgement ..................................................................................................... i
List of figure...............................................................................................................v
List of table .............................................................................................................. vi
Abbreviations .......................................................................................................... vii
Abstract .................................................................................................................. viii
CHAPTER ONE ........................................................................................................1
1. Introduction .........................................................................................................1
1.1Back ground of the organization........................................................................1
1.2 Statement of problem ........................................................................................2
1.3 Objective of the project.....................................................................................2
1.3.1 General objective ........................................................................................2
1.3.2 Specific objective........................................................................................2
1.4 Scope of the project ..........................................................................................3
1.4.1. In scope ......................................................................................................3
1.4.2 .Out scope ...................................................................................................3
1.4.3 Limitation of the project .............................................................................3
1.5 Significance and beneficiary of the project ......................................................3
1.5.1 Significant of the project ............................................................................3
1.5.2 Target beneficiaries of the system ..............................................................4
1.5.2 .1 Institution .............................................................................................4
1.5.2 .2 Developer team ....................................................................................4
1.5.2 .3 User of the system ...............................................................................4
1.6 Methodology .....................................................................................................5
1.6.1 Method of data collection ...........................................................................5
1.6.2 System development methodology.............................................................5
1.6.3 Development tool........................................................................................5
1.6.3.1 Hardware tools required .......................................................................5
1.6.3.2 Software tools required.........................................................................6

ii
 1.6.4 System evaluation procedure ......................................................................6
1.7 Feasibility of the project ...................................................................................6
1.7.1 Technical feasibility....................................................................................6
1.7.2. Economic feasibility ..................................................................................7
1.7.3. Operational feasibility ...............................................................................7
1.7. 4 Schedule feasibility....................................................................................7
1.7.5 Political Feasibility .....................................................................................8
1.9. Project Schedule ..............................................................................................8
1.10 Project team management ...............................................................................8
1.11 Organization of the study................................................................................9
CHAPTER TWO ...................................................................................................11
2. Current system ..................................................................................................11
2.1Description of current system .......................................................................11
2.2 Strength in the existing system ....................................................................11
2.3 Weakness in the Existing system.................................................................11
2.4Business rules ...............................................................................................12
2.5 Expected outcome of the project .................................................................13
CHAPTER THREE ...............................................................................................14
3. Proposed system ...............................................................................................14
3.1 Overview of the proposed system ...............................................................14
3.2Functional requirements ...............................................................................14
3.3 Nonfunctional requirements ........................................................................15
3.4 Hardware Requirement ................................................................................15
3.5 Software Requirement .................................................................................15
3.6. Security and Safety Procedure ....................................................................16
3.6.1 Security Procedure.................................................................................16
3.6.2 Safety Procedure ....................................................................................16
CHAPTER FOUR ..................................................................................................17
4. System Analysis and designing ........................................................................17

iii
 4.1 System models .............................................................................................17
4.1.1Scenarios .................................................................................................17
4.1 .2 Use case diagram ..................................................................................17
4.1.3 Use Case Description ............................................................................20
4.1.4 Class diagram (conceptual modeling) ...................................................31
4.1.5 ER (EER) diagram (conceptual modeling) ...........................................32
4.1.5.1 Normalized table (3rd) .....................................................................33
4.2 Dynamic model ............................................................................................37
4.2.1 Sequence diagram ..................................................................................37
4.2.2 Activity Diagram ...................................................................................47
4.2.3 State chart diagram ................................................................................52
4.2.4 Component Modeling ............................................................................55
4.2.5 Deployment modeling ...........................................................................56
4.2.6 Architecture of the system .....................................................................57
4.2.6.1 Subsystem decomposition ...............................................................58
4.2.7 User interface (navigational phase and screen markups) ......................60
4.2.8 User interface design .............................................................................61
References ................................................................................................................64

iv
List of figure
Figure 1 use case diagram ........................................................................................................................... 19
Figure 2 class diagram (conceptual modeling) ........................................................................................... 31
Figure 3 ER diagram .................................................................................................................................. 32
Figure 4 login sequence diagram ............................................................................................................... 37
Figure 5 Insured registration sequence diagram ......................................................................................... 38
Figure 6 update insured sequence diagram ................................................................................................ 39
Figure 7 Record payment sequence diagram ............................................................................................ 40
Figure 8 renew insurance sequence diagram ............................................................................................. 41
Figure 9 post notice sequence diagram ...................................................................................................... 42
Figure 10 generate report sequence diagram .............................................................................................. 43
Figure 11 delete insured sequence diagram ................................................................................................ 44
Figure 12 view accident sequence diagram ............................................................................................... 45
Figure 13 create account sequence diagram ............................................................................................... 46
Figure 14 login activity diagram ................................................................................................................ 47
Figure 15 registration activity diagram ...................................................................................................... 47
Figure 16 update insured activity diagram .................................................................................................. 48
Figure 17 record payment activity diagram ................................................................................................ 48
Figure 18 generate report activity diagram ................................................................................................ 49
Figure 19 delete insured activity diagram ................................................................................................... 49
Figure 20 view accident activity diagram ................................................................................................... 50
Figure 21 Create account activity diagram ................................................................................................. 50
Figure 22 post notice activity diagram....................................................................................................... 51
Figure 23 login state chart diagram............................................................................................................ 52
Figure 24 Register insured state chart diagram ........................................................................................... 52
Figure 25 Update insured state chart diagram............................................................................................. 53
Figure 26 delete insured state chart diagram .............................................................................................. 53
Figure 27 post notice state chart diagram .................................................................................................. 54
Figure 28 Component diageram.................................................................................................................. 55
Figure 29 deployment diagram .................................................................................................................. 56
Figure 30 architecture of the system diagram ............................................................................................ 57
Figure 31 subsystem decomposition diagram ............................................................................................. 59
Figure 32 navigational phase and screen markups diagram........................................................................ 60
Figure 33 home page user interface ........................................................................................................... 61
Figure 34 create account user interface...................................................................................................... 61
Figure 35 login user interface ..................................................................................................................... 62
Figure 36 insured registration user interface............................................................................................... 62
Figure 37 feedback user interface .............................................................................................................. 63

v
List of table
Table 1 cost estimation ................................................................................................................... 7
Table 2 project eschedule................................................................................................................ 8
Table 3 login use case description ............................................................................................... 20
Table 4 insured registration use case description ......................................................................... 21
Table 5 payment record use case description ............................................................................... 22
Table 6 update insured use case description ................................................................................. 23
Table 7 generate report use case description ............................................................................... 24
Table 8 post notice use case description ....................................................................................... 25
Table 9 delete insured use case description ................................................................................. 26
Table 10 generate report use case description .............................................................................. 27
Table 11 renew insurance ............................................................................................................ 28
Table 12 create account ............................................................................................................... 29
Table 13 view accident ................................................................................................................ 30

vi
 Abbreviations
CD---------------------- Compact Disk
DVD---------------- digital versatile disk
MS SQL------------------Microsoft structural query language
MS word------------ -Microsoft Word
NIC--------------------Network Interface Card
OOSAD--------------- Object Oriented system analysis and Design
PC------------------personal computer
RAM------------------Random Access Memory
UML------------------Unified Modeling Language
Xampp-------------- cross-platform, Apache, MySQL, PHP and Perl

vii
 Abstract
The project is developing a web Ethiopian insurance information management system for Wolkite
branch. The main objective of the project is solving problems by identifying problems the existing
system and we analyses the problem, gather requirements and designing of the system to solve
existing problem . This project can perform many functions like insured management, account
management, and report generating, payment management. The project is web based so it is user
friendly system and it provide more significant for the user, developer, and the organization.

viii
 CHAPTER ONE
1. Introduction
Insurance system is one of the important organization in the world that are becoming more spread
from time to time. Insurance system is a system in which one makes agreement to pay money to a
company and the company pays back if an accident or injury happens to the members of the
organization. The one that pays money to the company is called insured and the one that pays back
if an accident or injury happens is insurer. In other words, insured pays money to insurer. The
insured receives a contract or insurance policy which details the conditions and circumstances
under which the insured will be financially compensated. Insurance involves pooling funds from
many insured entities to pay for the losses that some may incur. The insured entities are therefore
protected from risk for a fee, with the fee or premium being dependent upon the frequency and
severity of the event occurring on the members of the organization .There are different types of
insurances given by companies such as life insurance, health insurance, auto or vehicle insurance
etc. For example, in auto insurance it will typically cover both the property risk (damage or theft
to the vehicle) and liability risk legal claims arising from an accident.

1.1Back ground of the organization

As we know Ethiopian Insurance is one of the earliest established institutes in Ethiopia. It
established its branch in Wolkite in 2004 E.C .The establishment of these institutes is expected to
give much to the ongoing development of the country in general. This system is still operate
manually .It operates all functions manually like registering, searching, reporting, editing, adding
details of information of the insured members of the institution. So this manual operation face
different types problems like it takes time for the operation, ineffective file, data inconsistent, data
not secure, etc. This is the general idea current Ethiopian insurance organization operation and
information management.

Page | 1
 1.2 Statement of problem
Ethiopian Insurance Information management system have many problems because it perform
its operations manually. Due to this reason the institution face too many problems. More specific
problems are listed as follows:

- To search data from the manually recorded take more time and difficult.
- Less availability.
- Less secure (data can be accessed by unauthorized users or agents).
- It require higher cost.
- Difficult to handle error and input data is not validated.
- Data duplication: the same data gets repeated over and over since the workers find
it hard to keep track of the documents, information and transactions
- Inconsistency of data: there will be unavailability for future use, since data might get
misplaced during manual filing. So data wont be preserved properly for future use.
- Files cannot be shared easily in the institution.

1.3 Objective of the project

1.3.1 General objective
To develop computerized (automated) Insurance Information Management System for Ethiopian
Insurance in Wolikite branch.

1.3.2 Specific objective

Specific objectives are objectives that used to achieve specified general objective. The following
are specific objectives.

- Study the existing system and identifying the problems under the existing system.
- Requirement analysis of the existing system with respect to functional and nonfunctional
requirement.
- Design new system based on the requirement analysis of the existing system.
- Implementing the new system.

- Testing the system using different testing methodology.

- Deploying the system the system after the system is tested.

Page | 2
 - Maintain and update the system when needed.
1.4 Scope of the project
This project will be developing a web based Ethiopian Insurance information Management
System for Wolikite branch. The project is enable fast and available service for the insured of the
Ethiopian Insurance.

1.4.1. In scope
- This project can do the following insurance types.
Vichel (motor) insurance.
Fire and lightning insurance.

1.4.2 .Out scope

- The project cant do the following insurance types.
Life insurance.
Medical insurance.

1.4.3 Limitation of the project

Our project have the following limitations:-

- Shortage of data: there is no enough information about other insurance types. Because of
this we cannot include other types of insurance.
- Shortage of time: We have shortage of time to complete the project in one semester. This
enforces our project team to minimize the project scope.

1.5 Significance and beneficiary of the project

1.5.1 Significant of the project

Reduced costs & time consumption.
Speed up the operation
Avoiding data loss.
Increase security
Add new knowledge.
Increase competency

Page | 3
 1.5.2 Target beneficiaries of the system
- The following bodies that will get benefit from the proposed system.

1.5.2 .1 Institution
Speed up the business operation.
Increase competency.
Control customers records.

1.5.2 .2 Developer team

Add new knowledge.
Get problem solving skill.

1.5.2 .3 User of the system

Save their time and Reduce workloads.
Easily access customers information from organized database.
Reduce data redundancy
Reduce complexity

Page | 4
 1.6 Methodology
1.6.1 Method of data collection
There are different methods of data collection methods. From those we used the following methods
respectively to collect data from the organization.
Direct Observation: use this method to get the right information about the
organization and also understand by viewing how the existing system works.
Interview: through interviewing the manager and another employee of the
organization and we get enough and reliable data which is important to do the project.
Document analysis: we analyzing the manual resources of the organization how the
current system operates.

1.6.2 System development methodology

There are different types of software development methodologies from this we used:-

Object oriented system analysis and design methodology: Is software development

methodology by building self-contained modules or objects. This methodology have the
following futures increased reusability, increased extensibility, proved quality, and
reduced maintenance burden and managed complexity .due to this we select OOSAD
methodology.
Software development model: we use is iterative model because in iterative model you
can iterate back if error are occurs in one phase and we can return back to other phase to
fix errors at any phase of the project life cycle.

1.6.3 Development tool

1.6.3.1 Hardware tools required
Personal computer (PC): almost all tasks of our project are performed on
computer.
Flash disk: required for data movement to store & transfer data from one PC to
another PC.
Disks (CD, DVD): necessary for the movement, backup and recovery mechanism
of relevant data.

Page | 5
 Paper and pen: for writing all necessary documentations associated with the
project.

1.6.3.2 Software tools required

Windows 8.1 Operating system: will be used for the system since it is readily
available in laboratories.
Firefox, chrome browsers: -since our system is web based, it is very
necessary requirement.
Microsoft office Word 2013:-for documenting the corresponding deliverables
associated with the project
Edraw max 6.8: -for designing Unified Modeling Language (UML) diagrams.

Xampp Server: - to test the system.

1.6.4 System evaluation procedure

There are different types of evaluation procedures used for testing a system. This evaluation are
relevant for is the system is go on the specified user requirement and perform all expected function
as well as to find the system gape. For our project we will use different evaluation procedures from
which.
Unit testing - individual components are tested independently. Components may be functions or
objects or coherent groupings of these entities. This used for testing each component of system
and best for finding system failure.
System testing -testing of the system as a whole. Testing of emergent properties is particularly
important.
1.7 Feasibility of the project
Feasibility study is used to investigate the proposed system in multiple dimensions. It is used to
indicate whether the system is feasible or not.

1.7.1 Technical feasibility

Technical feasibility is the measure of practicality of the specific technical support and the
availability of technical resources and expertise to use the system. The proposed system can be
easily maintained and repaired without requiring high Experts or technical supports, because the
system will be installed in adaptable technologys and the employee of the organization have

Page | 6
 some knowledge about technology by providing training and help how to use the system and can
use the system easily . So the system is technically feasible.

1.7.2. Economic feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated with
the project being developed. So the project is economically feasible because the project reduce
the cost of the resources. But Economic Feasibility is expressed as cost- benefit analysis.
Costs- our system use new technology and have centralized database cannot need more
resources. It require minimum amount of cost. The estimate cost of resources that we use to
Develop this project.
Types of costs Tool name Quantity Unit price (in Total price (in Birr)
Birr)
Hardware costs Computer 1 8000 8000
Flash(8 GB) 1 180 180
Paper 1 packet 100 100

Printing and binding 3(copies) 100 300

Software costs Xampp server 1 Free Free
Microsoft office 20013 1 Free Free
Notepad++ 1 Free Free
Windows 8.1 OS 1 Free Free
Requirement analysis 200
Total 10080

Table 1 cost estimation

1.7.3. Operational feasibility

The system perform all operations to achieve the specified objective, User friendly and
interactive with the environment and the system will perform all operation that the organization
runs. And it will not have any difficulty or procedures to perform the operation of the system.
So the project is operational feasible.

1.7. 4 Schedule feasibility

The system after development may give efficient and effective services in short period of time.
And also the tasks may be scheduled for effective use of the system. The project will be finish at
the schedule time. So the project is Schedule feasible

Page | 7
 1.7.5 Political Feasibility
The project built without violating rules and regulations of the governments as well as the
organization. The system being built is for the sake of service of the organization, so that the
project is legally feasible.

1.9. Project Schedule

Task name month oct2015 Nov2015 Dec2015 Jan2016 Feb201 Mar2016 Api2016 Jun2016
6
week 3 4 1 2 34 1 2 34 1 2 34 1 2 34 123 4 12 3 4 1 2
Project proposal

Requirement
analysis
Design
Implementation
Testing

Table 2 project schedule

1.10 Project team management

Each part of tasks of the project will be delivered by collaborating with each of the group
members. Each group members has their own responsibility to complete the project successfully.
The group members and responsibility are:

ID NAME RESPONSIBILITY
CIR/082/05 Mekuanenet Lamesgen Write proposal and implementation
CIR/062/05 Getaneh Megeresa System Analyst
CIR/061/05 Getahune Addis System Design
CIR/035/05 Dechasa Tesfaye System Analyst
CIR/038/05 Dawit Berehana System Design

Table 3 project team management

Page | 8
1.11 Organization of the study
Our project study organized from project contents that performed in each chapter of the project
and the purpose of this to show activists and its sequences in each chapter. Activates are shown
below.

Chapter one: this chapter deals about identification of problems in the existing system by
gathering information from the organization.

Determine objective: based on the identified problem we design the general objective and
specific objective of the project to be achieved.

Determine Scope of the project: we set the project coverage area and what the project do with
three perspectives, in scope, out scope, limitation of the project.

Set methodology of the project: we determine the methodology that we are used for the project
this are, data collection method, development tools and evaluation procedures for our project.

Determine the feasibility of the project: we set project feasibility with different perspectives and
criteria. We determine technical feasibility, operation feasibility, economic feasibility, political
feasibility of the project.

Determine significance of the project: we describe the significance that the system provide after
finishing.

Chapter two: this chapter deals about description of the current system: we dealing about current
system and the strength of existing system as well as the weakness of the existing system .we
identify the business rule that the existing system follow. Next to this we set the expected
outcome of our project after finishing.

Chapter three: this chapter deals about we explain what the proposed system is and identify
functional requirement, nonfunctional requirement, hardware requirement and software that the
proposed system is to do. Determine security and safety procedures for our project.

Chapter four: this chapter deals about we define system analysis and design for our projects
using system designing model and we use UML modeling system. Designed our system with two
model these model. The first is system model in this model we define and design our project
scenarios, use case diagram, and use case description, class diagram, (EER) diagram and

Page | 9
normalization of table. Second we design our dynamic model of our system and this includes
sequence diagram, activity diagram, component diagram, and deployment diagram, architecture
of the system, subsystem decomposition, and user interface of the project. This is our project
organization study until chapter four.

Page | 10
 CHAPTER TWO
2. Current system
2.1 Description of current system
Wolikite Branch Ethiopian Insurance in is one of the institution in Ethiopia. This institution
perform many operations and the aim is giving guarantees for the insured of the organization .the
organization have many types of insurance .The functions performed in the organization are
manage events occurred in the insured, renew information, and handle payment. The institution
revises its policies regularly and produces new policies based on the countrys current economic
development and the demand of customers. The organization have seven employees this
employees have its own responsibility and the institution provide insurance for objects insured
value is less than or equals to one million birr. The major property and liability insurance services
given by the institution are, fire and lighting insurance, money insurance, auto insurance.
2.2 Strength in the existing system
Even if the existing system have its own weakness it have its own strength. The following are the
strength.

- The existing system is politically feasible.

- Organizational structure.
- Better for people who cannot get internet and computer access.
- Business rule of the existing system are good.
- More number of employee work on the existing system.

2.3 Weakness in the Existing system

The existing system have many problems .we classified the problem as follow.

Inputs
Data is not accurately captured if it contains errors.
Input data is not validated.
Outputs
Sometimes lack necessary and relevant information.
Sometimes Information is not in a useful format.
Information is not timely to its subsequent use.
Stored Data
Data is not flexible not easy to meet new information needs from stored data.
Data is not accessible easily.

Page | 11
 Costs (Budget of the office)
Stationary cost is increasing.
Service
The existing system is not that easy and it is uncomfortable to use.
The system is not easy to coordinate.
Security and Controls
Input data is not adequately edited.
Ethics are branched on data or information refers to data or information getting to
unauthorized people.
Redundantly stored data is inconsistent in different files.
Data privacy regulations or guidelines can be violated.
Processing errors are occurring by people.
Efficiency
Performance (Response time): the response time is less.
2.4 Business rules
-Business rules that the existing system follow.

BR1: New insured fill the registration form correctly and fill all the required information.

BR2: The insured renew annually their policy and the not renew the insurance the insurer
exclude the insured from the insurance and not accountable if any accident face. .

BR3: The insured register its object.

BR4: Insured pay the premium value of the object and insured not pay this not approved or not
provide any service from the insurer until the premium value played.

BR5: Insured must report accident immediately.

BR6: Insured who cannot renew his insurance policy is dismissed from the insurer.

BR7: Insurer check accidents of insured: the insurer immediately check the accident and provide
needed support to the insurer.

BR8: Insurer pay the value of object when accident is happen.

BR9: Insurer notify insured to renew their policy.

Page | 12
 2.5 Expected outcome of the project
The outcome of this project is generate good web based system that perform all expected
Functions with minimum resource, time and higher performance.

2.6Alternative solution

As we justifies above that the existing system have many problems. So the alternative solution to
reduce this problem replace the existing manual system to web based system this is the
alternative solution that we take to improve the existing system.

Page | 13
 CHAPTER THREE
3. Proposed system
3.1 Overview of the proposed system
The existing system has its own problem and drawbacks. So that, the project team tries to
develop a system which is better than the existing system in terms of time and cost efficiency.
The team tire to make the existing system that improve system performance .The proposed
system is capable of provides high security of data, capability of organizing all information in a
single client-server system, easy way of recording and accessing items information by its well
organized user-friendly interface. Generally the proposed system will improve the performance
of the existing system and reduce this problems, time wastage, Bring data security, data
inconsistency, Poor quality service delivery, and reduces wastage of paper.

3.2 Functional requirements

Functional requirements drive the application architecture of a system. Functional requirements
are the intended behaviors of the system. This behavior may be expressed as services, tasks or
functions that the system is required to perform. The functional requirements that the proposed
system Perform.

- Registration of the new insured

- Payment management
- Generating report
- Delete report
- View report
- Post notice
- Delete notice
- Renew insurance
- Update insured
- Manage accidents.
- View notice
- Manage accounts.
- Manage accidents.

Page | 14
 3.3 Nonfunctional requirements

Non-functional requirement is a requirement that describes about how the system will do the
functional requirements. It describes performance, maintainability, security, usability,
availability, accuracy, and reliability of proposed system.

Performance: The proposed system perform its operations within a minimum amount of time and
the user gets the expected result within a few seconds and the system is effective.
Accessibility: The system can be accessible based on the accessible privilege or based on
autontication.
Accuracy: proposed system will reduce error because all operation can be check correctly and
validate that whatever information is coming from the data base and input to the database.
Maintenance: our system can be easy maintainable and updateable, if the system get any failure.
Extensibility: - Adding features and carry-forward of customizations at next major version
upgrade along with the business re-engineering is possible.
Backup and recovery: to reduce data loss and other risks there shall be a frequent and full back
up mechanism to avoid any information loss and inconsistency using copy of the system to
restore when hard ware and software failure occur.
Resource: the proposed system cannot use more resources as current system because it have
centralized data base management system.

3.4 Hardware Requirement

-The hardware requirement that we use for developing this project are.
o Personal computer (PC).
o Intel(R) corei3, CPU 2GHz and more than this is possible.
o RAM: 2GB and above possible.
o Disks (CD, DVD) drivers.
o 250GB Hard-disk and above.
o Printer: required for printing the documents of the project.

3.5 Software Requirement

The software requirement that we use for developing this project are.
o 32 or 64 bit Windows 8.1 Operating system

Page | 15
 o Firefox, chrome browsers: -since our system is web based, it is very necessary
requirement and it use for front end.
o Microsoft office Word 2013:-for documenting the corresponding deliverables
associated with the project
o Edraw max 6.8: -for designing Unified Modeling Language (UML) diagrams.

o Xampp Server: - To test the system will be running.

3.6. Security and Safety Procedure

3.6.1 Security Procedure
In order to make the system secure from an authorized 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. The security service provided by the system
will maintain the security, confidentiality and integrity of the system. Users will have their own
autontication based on user name and password. Through which they could gain access to the
system.
3.6.2 Safety Procedure
To make our project safer from different risks and attacks we use different safety mechanism .so
the following safety mechanism.
We use backup for our project files using External Hard Disk and Flash Disk, if suddenly the
computer that contain the file is damaged.
We duplicate the same folder that contains our project into many folder in different drives.
We use antivirus that protect from attacks

Page | 16
 CHAPTER FOUR
4. System Analysis and designing
4.1 System models
4.1.1Scenarios
-The following are describe scenario of how the user use the systems to perform operations.

Scenario name: login

Participant actor Mr. Taddess

Mr. Taddess as user if he wants to login to the system first run the system then the system display
home page next Mr. Taddess click login link from home page. After that the system display
login form then Mr. Taddess fill login form and click login button and home page is display
next Mr. Taddess perform his authenticated operation and logout.

Scenario name: insured registration

Participant actor Mr. Edalew, Mr. Demeke.

Mr. Edalew as insured and Mr. Demeke as operation officer participate in the registration
process. To register for the first time. First run the system and click registration link in the
system home page, the system display the registration form then fill correctly and click
registration button if the data is incorrect the system display error message else registration is
success.

4.1 .2 Use case diagram

Use Cases: A use case is an interaction between users and a system. What operation the user do
in the system. Use case diagrams are used for capturing functional requirements of the system.It
is the functionality of the system or the service provided by the system. The following show list
of use case and who can interact with the use case (actors).

Page | 17
Use Case Interact

Register insured Insured, operation officer

Login Admin ,Insured, operation officer, casher
Delete insured operation officer
update insured operation officer
Generate report Casher
Post notice Operation officer
Login Insured, casher, admin, Operation officer
Renew insurance Insured
Delete notice Operation officer
Report accident Insured
Register payment Casher
Update payment Casher
View accident Admin
Create account Admin
Delete account Admin
Update account Operation officer, admin, insured and casher
View notice Insured
Delete notice Operation officer

Page | 18
Figure 1 use case diagram

Page | 19
 4.1.3 Use Case Description
It describes use case diagram and it contain use case Id, use case name, use case description,
basic course of action, alternative solution.

Use Case Id UC 01

Use case name Login

Description Allow the user enter to the system and perform operation in the system

Actor Admin, casher, and insured, operation officer.

Pre-condition The user must have valid username and password in the system

Basic course of action Actor Action System response

Alternative course action
Post condition
step1.the user click the login link step 2.the system display the login form that
contains user name and password
Step 3. The user fill the valid user
Step 4. the system verify user name and
name and password.
password
Step 5. the system display user page
step 6.usecase end
If user name and password incorrect
A.1 The system display invalid user name and password.
A.2 The user back to step 3 of basic course of action.
The login success and go to user page.

Table 3 login use case description

Page | 20
Use Case Id UC02
Use case name Register Insured
Description The insured register his/her information to become member of the institution (insurer)
to get service.
Actor Insured, operation officer
Basic course of action Actor Action System Response

Step 1. The insured or operation
Officer click the register link.
Step 3. The insured or operation officer
fill the form and submit.
Step 2. The system display the registration
page.
Step 4.The system validate the form input
Step 5. The system store the information
and display successful message.
Step 6. Use case end.

Alternative course If the form in puts are incorrect

action A.1 the system display error message.
A.2 The insured or operation officer back to step 3 of basic course of action.

Post condition The insured is register successfully.

Table 4 insured registration use case description

Page | 21
 Use Case Id UC03

Use Case Name Payment Record

Description The insured pay the premium value of the object for the insurer.

Actor Casher.

Pre-condition The insured is recorded in the data base.

Basic course of Actor Action System response

action
Step 1. Casher login to the system. Step 2. The system display home
page.
Step 3. The casher click pay link
step 4 the system display pay form
step.5 casher fill the form Step 6. the system verify the form
step 7.the system add the information
in to
Database.
step 8.Use case end
Alternative course If payment form input is incorrect
action A.1 The system informs the casher to reenter the input form.
A.2 The casher back step 5 of basic course of action.
Post condition The payment is success and the insured is approved.

Table 5 payment record use case description

Page | 22
 Use case Id UC04

Use case name Update Insured

Description Allow the operation officers to update the information of insured.

Actor Operation officer.

Pre-condition The information is available in the data base.

Basic course of action Actor Action System response

Step1.the operation officer login
to the system.
Step 3. Operation officer click
on update link.
Step 5. Search the update
information using ID
Step7. Fill the update data and
submit.
Step 2.the system display home page
step4. the system display update form
Step 6 the system display the
information
Step 8. The system store update
information to the data base.
step 9.usecase end

Alternative course If the update information is not found

action A.1 The system display error message
A.2 The operation officer back to step 5 of basic course of action.
Post condition The information is updated.

Table 6 update insured use case description

Page | 23
Use Case Id UC05
Use case Name Generate Report
Description Generating of report for the administrator how many insured are pay their
premium value and insured report accidents when occurred.
Actor Casher, insured

Precondition Request report from the administrator.

Basic course of action Actor Action System response

Step 1.The casher and insured login Step 2.The system display the home page
to the system Step 4.The system display the form
Step 3. The casher and insured click Step 6. display successful message
the report link. Step 7. End of use case.
Step 5. fill the form
and click submit
Post condition Report is generated successfully.
Table 7 generate report use case description

Page | 24
Use Case Id UC06

Use case Name Post Notice

Description Post notifications for the insured to provide information from the insurer.

Actor Operation officer

Pre-condition The operation officer have notice to be post.

Basic course of action Actor Action System response

Step 1.the Operation officer login to the
system.
Step 3. The Operation officer click post link.
Step 5 the Operation officer fill the upload
file
Step 2.the system display home
page of the system
Step 4. the system display page
Step 6. The system upload the file
and return success message.
Step 7.Use case end

Post condition Post is success.

Table 8 post notice use case description

Page | 25
Use Case Id UC07

Use Case Name Delete insured

Description It Allows operation officer delete insured if the insurance is finished.

Actor operation officer
Pre-condition The insured is stored in the data base
Basic course of Actor action System response
action:
Step1.the operation officer login to the Step2.The system displays the home page
system
Step3.The operation officer click the delete Step4.The system display delete form
link Step6.The system deleted the insured from
Step5.the operation officer fill the delete database.
form Step7. The system displays confirm message.
Step8. The use case ends
Alternative course If the selected insured is not available.
action A.1. The system displays error message.
A.2. Go to step5 to select the insured again.

Post condition The insured is deleted from the database and not member of insurance

Table 9 delete insured use case description

Page | 26
Use Case Id UC 08

Use Case Name Report Accident

Description The insured can report the accident after the accident is takes place on his/her
Owen insurance type object occurs.
Actor Insured

Pre-condition The insured is member of the insurer.

Basic course of action Actor action System response

Step1. the insured login to the Step 2. the system display the home page
system Step 4. the system display the form
Step3. Click the report Step 6. the system save to the database and
accident link. display the successful message
Step 5. the insured fill the form Step 7.use case end
and submit

Post condition The report is generated. And view by authorized user

Table 10 generate report use case description

Page | 27
Use Case ID UC09

Use case Name Renew Insurance

Description The insured will renewed his/her insurance with in interval of time.
Actor Operation officer

Pre-condition The insured pay the annual premium value of their object value
Basic course of Actor action System response
action
Step 1. the Operation officer Step 2. The system display the homepage
login to system Step 4. the system display the form
Step 3.the Operation officer Step 5. the system save to the database and display the
click the renewed link successful message
Step 6 .the Operation officer fill Step 7.use case end
and submit
Alternative course If the renewed input data is not correct.
action A.1 The system informs the operation officer to reenter the correct data.
A.2 Operation officer back step 6 of basic course of action.
Post condition the insurance of the insured is renewed

Table 11 renew insurance

Page | 28
 Use Case Id UC010

Use Case Name Create Account

Description It describes the process of creating a new account for the user.

Actor Administrator

Pre-Condition Administrator login to the system.

Basic course of action Actor Action System Response

Step 1. The Administrator click
create account link.
Step 3. Administrator fill the
registration form and submit.
Step 2. The system displays the
registration form.
Step 4.System validate entered data.
Step5. The system save in to data base
display success message.
Step 6. Use case end.

Alternative Action If the input data is not correct.

A.1 the system notify invalid input message.
A.2 the administrator back to step 3 of basic course of action.
Post condition Account is created successfully.
Table 12 create account

Page | 29
 Use Case Id UC011

Use Case Name View Accident

Description Administrator can view accident occurred in different time as needed.

Actor Administrator

Pre-condition Accidents must store in database.

Basic course of action Actor Action System Response
Step. The administrator login to the Step 2.The system display the
system. homepage
Step 3.the Administrator Step 4.The system display all
Clicks the view link. accidents
Step 5. use case end
Post condition The Administrator view the accident on time.

Table 13 view accident

Page | 30
 4.1.4 Class diagram (conceptual modeling)

Figure 2 class diagram (conceptual modeling)

Page | 31
4.1.5 ER (EER) diagram (conceptual modeling)

Figure 3 ER diagram

Page | 32
 4.1.5.1 Normalized table (3rd)
Tables
Insurance

Insurance type Description

Insured
Client ID Name Sex Address Contact person Insurance type

Object
Object Id Object Name Object type Insured value Year

Payment
Payment id Amount Date

Accident
Accident Id Type Reason Location Date

Policy
Policy No Branch Address Premium value

Report
Report Id Report type Description Date

1st normal form for the above table

- Eliminating multivalued attribute
- Identify primary key attribute
Insurance

Insurance type Description

Insured
Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type

Page | 33
 Object
Object Id Object Name Object type Insured value Year

Accident
Accident Id Type Reason Location Date

Policy
Policy No Branch country Region zone city Keble Premium value

Report
Report Id Report type Description Date
2nd normal form
- Avoid partial dependency
Insurance

Insurance type Description

Insured
Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type

Object
Object Id Object Name Object type Insured value Year

Accident
Accident Id Type Reason Location Date

Policy
Policy Branch country Region zone city Keble Policy No Premium value
No

Page | 34
 Report
Report Id Report type Description Date
3rd normal form
- Avoid transitive property
Insurance

Insurance type Description

Insured
Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type

Object
Object Id Object Name Object type Year Object type Insured value

Accident
Accident Id Type Reason Location Date

Policy
Policy No Branch country Region zone city Keble Policy No Premium value

Report
Report Id Report type Description Date

Page | 35
 Foreign key primary key relationship (Mapping table)
Insurance
Insurance type Description

Insured
Client ID FK insurance type Name Sex Address Contact person

Object
FK Insured id Object Id Object Name Object type Insured value Year

Payment

FK Insured id FK Object Id Payment id Amount Date

Accident
FK Insured id Accident Id Type Reason Location Date

Policy
FK Insured id Policy No Branch Address Premium value

Report
Report Id Report type Description Date

Page | 36
4.2 Dynamic model
4.2.1 Sequence diagram
Sequence diagram showing the sequence of interactions among objects and used to represent or
model the flow of messages, events and actions between the objects or components of a system.
Sequence Diagrams are also used primarily to design, document and validate the architecture and
interfaces of the system by describing the sequence of actions that need to be performed to
complete a task or scenario.

Figure 4 login sequence diagram

Page | 37
Figure 5 Insured registration sequence diagram

Page | 38
Figure 6 update insured sequence diagram

Page | 39
-

Figure 7 Record payment sequence diagram

Page | 40
Figure 8 renew insurance sequence diagram

Page | 41
Figure 9 post notice sequence diagram

Page | 42
Figure 10 generate report sequence diagram

Page | 43
Figure 11 delete insured sequence diagram

Page | 44
-

Figure 12 view accident sequence diagram

Page | 45
Figure 13 create account sequence diagram

Page | 46
4.2.2 Activity Diagram

Figure 14 login activity diagram

Figure 15 registration activity diagram

Page | 47
Figure 16 update insured activity diagram

Figure 17 record payment activity diagram

Page | 48
Figure 18 generate report activity diagram

Figure 19 delete insured activity diagram

Page | 49
Figure 20 view accident activity diagram

Figure 21 Create account activity diagram

Page | 50
Figure 22 post notice activity diagram

Page | 51
4.2.3 State chart diagram

Figure 23 login state chart diagram

Figure 24 Register insured state chart diagram

Page | 52
Figure 25 Update insured state chart diagram

Figure 26 delete insured state chart diagram

Page | 53
Figure 27 post notice state chart diagram

Page | 54
4.2.4 Component Modeling
In this modeling components of the system will be wired showing that there is relation among
components, this in some extent shows which components or objects will be accessed by whom.

Figure 28 Component diageram

Page | 55
4.2.5 Deployment modeling
Deployment modeling used to show the hardware of the system, the software that is installed in
the hardware and also the middleware that is used to connect the different machines to one and
other. It also shows how the software and the hardware components work together.

Figure 29 deployment diagram

Page | 56
4.2.6 Architecture of the system

Figure 30 architecture of the system diagram

Page | 57
4.2.6.1 Subsystem decomposition
Subsystem decompositions will help reduce the complexity of the system. The sub systems that
we take the classes that our system contain and the operation performed in the class. The
following are sub systems

Insured management sub system: this subsystem used for managing insured information
and have the following operations.
Register new insured
Delete insured
Update insured
Approved insured
View insured
Report management sub system: This subsystem allows for managing information and
perform this operation.
Generate report
Approve report
Delete report
View report
Manage account subsystem: in this subsystem managing of information regard to account
and perform.
Create account
Delete account
Update account
Payment management sub system: in this sub system manage information of payments
and perform.
Record payment
Calculate payment
Update payment
Accident management sub system: this sub system holds information of accidents.
Register accident
View accident

Page | 58
 Notice Managing sub system: this sub system handles information of notice and perform.
Post notice
View notice
Delete notice
Database Connection Subsystem: this subsystem used for established connection between
business class and database management system.
Insurance management subsystem: this sub system handles information of insurance and
perform.
Add insurance
View insurance
Delete insurance

Figure 31 subsystem decomposition diagram

Page | 59
4.2.7 User interface (navigational phase and screen markups)

Figure 32 navigational phase and screen markups diagram

Page | 60
4.2.8 User interface design

Figure 33 home page user interface

Figure 34 create account user interface

Page | 61
Figure 35 login user interface

Figure 36 insured registration user interface

Page | 62
Figure 37 feedback user interface

Page | 63
References
[1] C. Curescu, Object Oriented Analysis and Design andSoftware Development Process, England:
Addison-Wesley., 2006.

[2] D. Bell, "futhers," IBM, 04 septamber 2003. [Online]. Available: http://www.uml.org. [Accessed 06
january 2008].

[3] S. L. John Wiley, Object-Oriented Analysis and Design, England: London W1T 4LP, 1998.

[4] O. M. Group, "Tutorialspoint," January 1997. [Online]. Available: http://www.tutorialspoint.com/uml.

[Accessed 10 january 2008].

[5] Mr.Ahmmed, Interviewee, Current system operation and problems. [Interview]. 20 october 2008.

Page | 64
Page | 65