WOLKITE UNIVERSITY COLLEGE OF COMPUTING AND INFORMATICS DEPARTMENT OF INFORMATION SYSTEM
Project Title: - Ethiopian Insurance Information Management System for Wolikite Branch
Prepared By:
Name 1. Dawit
ID No. 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 _________________________ Advisor,
Signature _______________
Date ________________
______________________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 (3 rd) .....................................................................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 ............................................................................................. 53 Figure 25 Update insured state chart diagram 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 thesystem diagram ............................................................................................ 57 Figure 31 subsystem decomposition diagram............................................................................................. 59 ........................................................................ 60 Figure phase and screen markups diagram ........................................................................................................... 61 Figure 32 33 navigational home page user interface 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 won’t 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 can’t 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 customer’s 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 technology’s 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
Hardware costs
Computer Flash(8 GB) Paper
Software costs
Total price (in Birr)
1 1 1 packet
Unit price (in Birr) 8000 180 100
Printing and binding
3(copies)
100
300
Xampp server Microsoft office 20013
1 1
Free Free
Free Free
Notepad++ Windows 8.1 OS
1 1
Free Free
Free Free 200 10080
Requirement analysis Total
8000 180 100
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
123 4
12 3 4
1
6 week
3
4
1
2 34
1 2 34
1
2
34
1 2 34
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
2
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 country’s 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) core™i3, CPU 2GHz and more than this is possible.
o
o
RAM: 2GB and above possible. Disks (CD, DVD) drivers.
o
250GB Hard-disk and above. Printer: required for printing the documents of the project.
o
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
step1.the user click the login link
step 2.the system display the login form that
Step 3. The user fill the valid user name and password.
contains user name and password Step 4. the system verify user name and password Step 5. the system display user page step 6.usecase end
Alternative course action
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.
Post condition
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)
Actor
to get service. Insured, operation officer
Basic course of action
Actor Action
System Response
Step 1. The insured or operation
Step 2. The system display the registration
Officer click the register link.
page.
Step 3. The insured or operation officer
Step 4.The system validate the form input
fill the form and submit.
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
Step 1. Casher login to the system.
Step 2. The system display home
action
Step 3. The casher click pay link
page. 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
Step 2.the system display home page
to the system.
step4. the system display update form
Step 3. Operation officer click on update link.
Step 6 the system display the information Step 8. The system store update
Step 5. Search the update
information to the data base.
information using ID
step 9.usecase end
Step7. Fill the update data and submit. 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
Step 2.the system display home
system.
page of the system
Step 3. The Operation officer click post link.
Step 4. the system display page Step 6. The system upload the file
Post condition
Step 5 the Operation officer fill the upload
and return success message.
file
Step 7.Use case end
Post is success.
Table 8 post notice use case description
Page | 25
Use Case Id Use Case Name Description
UC07 Delete insured 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 and submit
Step 7.use case end
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
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
action
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 Step 1. The Administrator click
System Response Step 2. The system displays the
create account link.
registration form.
Step 3. Administrator fill the
Step 4.System validate entered data.
registration form and submit.
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 Insured Client ID
Description
Name
Sex
Address
Contact person
Insurance type
Object Object Id
Object Name
Object type
Insured value
Year
Payment Payment id
Amount
Accident Accident Id
Type
Date
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 ID
First name
Last name
sex
Contact person
country Region
zone
city
Keble
Mobile number
Page | 33
Insurance type
Object Object Id
Object Name
Accident Accident Id
Type
Object type
Reason
Insured value
Location
Year
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 ID
First name
Last name
sex
Contact person
country Region
zone
city
Keble
Mobile number
Object Object Id
Object Name
Accident Accident Id
Type
Object type
Reason
Insured value
Location
Year
Date
Policy Policy No
Branch country Region zone
city
Keble
Policy No
Premium value
Page | 34
Insurance type
Report Report Id
Report type
Description
Date
rd
3 normal form -
Avoid transitive property
Insurance Insurance type
Description
Insured Client ID
First name
Last name
sex
Contact person
country Region
zone
city
Keble
Mobile number
Object Object Id
Object Name
Accident Accident Id
Type
Object type
Reason
Object type
Year
Location
Insured value
Date
Policy Policy No
Branch country Region zone
city
Keble
Policy No
Premium value
Report Report Id
Report type
Description
Date
Page | 35
Insurance type
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
