1.

PROFILE OF THE PROBLEM Today, traditionally used agents information management methods are not sufficient for managing the many tasks in the design and development process. They do not take into account all the sources of change, the task interactions, and the necessity for distributed planning. They do not provide proper change notification. Process coordination is always most complex in domains that require artifact design and construction planning. This is particularly true when the artifacts are large and many people and software tools must be coordinated and managed. Mr.Devendra Kumar Sharma is an agent who works for LIC, and manages large number of peoples information and their policies. He has expanded his areas in not only in his own city only but also serves in the neighboring areas of his locality. As he is a big agent with the coverage over a large area he does a good business, but he wants to ease and make his work less hectic anyhow, as he thinks that this will not only reduce his work load but also help him in increasing his horizons, he also suggests doing so. Agent information management system which is under development can be helpful for Mr. Devendra Kumar Sharma this will be such a system that will try to meet all his needs. This will help him in managing and keeping the track of their activities from policy registration to claim processing. All their data, their commission, their policies status updates, etc. are taken care by this module. This system will help him in smooth functioning and making the processes faster and efficient. Here are the sub stories that we were able to get from the client: that technology being used today can help him in

The program accepts details entered by user. The program computes functions done by an agent. The program records all the information that agent wants to be in it.

 The program should also allow deletion and editing of data. The program should also give notifications.

2 EXISTING SYSTEM:

Existing systems has many pitfalls. These pitfalls are going to be covered as given in down sections. 2.1 INTRODUCTION In the existing system, the billing process, policy order from policy holders and policy. Details are maintained through manual records. Whenever a policy holder makes a demand for policy it is recorded in a separate notebook and if any policy holder asks for his/her detail, then the previous information is searched, like if a policy holder wants to know about the amount which he has t pay, then it has to be calculated manually. The orders that an agent gets can be for various policies. The billing is done based on the above types of policies and the rate is charged. Then the stock of policies is also maintained in manual records. So while billing this also has to be taken into account and billed. So this involves a great process and the time is also wasted. 2.2 EXISTING SOFTWARE Insurancepro is going to be the existing software which will be studied by us to know the extent of computerization required, it is a software that manages the information that an agent or agency needs to manage. Therefore, a detailed analysis of the existing system should be conducted. For this purpose, system should be broken down into various subsystems and these subsystems should be analysed closely to identify the problem areas. As we studied the existing system, it was found that there is a file management system which gives the facility for accessing the employee details. In a File Management all works are

done manually. The main problem of the manual operation is, it is time consuming and error prone than the computerized system. This phase provides the overall requirement for the system what is to be done. Input for this phase is the information collected through several data collecting schemes such as survey, cross-questioning-answering etc. and the raw data obtained which is not properly ordered and not in the precise manner. So here this raw data is converted into useful information written in precise manner and thus output is a formal document. After collecting all the information and requirements, they were verified from the concerned persons. The points missing were added to the system specifications for the desired system. So this final document provides the system requirement specifications for the desired system. It helps in reducing the total development cost and also establishes the various points for validation and verification.

2.2.1 Problem With Existing System

Existing software is based on standalone system. The decision for appraisal of assigning next project to the employee or to train him/her to enhance the skills where lies with proper projection. Existing System is not much user-friendly. The current system is very time consuming. It is very difficult to analyze the operation to be done manually. So if this manual process is automated using a software application that is network

enabled the tedious task can be made easy and more effective. 2.2.2 PROPOSED SYSTEM In the proposed system, the process of billing and maintaining the stock, database of policy holders are all made computerized. Since whenever a policy holder makes a demand about his account through phone call or by personal, it is received and immediately checked by billing. The policy holders name, address, last date of payment made is all maintained in the

database. So when the policy holders enquiry is received, the system automatically calculates the number of days from the previous payment made, if timing of making new payment has arrived, billing can be done, if not the billing cannot be done and the policy holder can be informed about it. So the manual process of recording and billing is done easily without any paper work. The stock of policy that is recorded and maintained manually is made computerized. Whenever a new person or an already policy holder wishes to buy another policy, agent can be contacted and using this system that agent can tell the enquirer that the policy is available with him or not.

2.2.3 The objective of the system would be

The aim of this project is to deliver a verified & validated data retrieval system.
The primary objective of design & development of this system is to simplify the process of

information management generation. It should provide correct data in the reports independent of the objects & conditions used. Should reduce the time for provisioning of requested data.
The enterprise agents can easily get data for analysis purposes.

To reduce the paper work involved in managing the information.

To reduce the time constraint involved.

2.3 DFD for Present System

Policy Holder/Enquire r

Amount

Complete Policy Information

Info

Agent

Policy holders id,

Detail to be shown

Display Details of Policy Holder

Show

Update Database

Valid

Generate

2.4 WHATS NEW IN THE SYSTEM TO BE DEVELOPED In the new system what actually is developing that there would be bunch of new features which will make the work load of the organisation quite easy and reliable enough. As it is an application it can be accessed by multiple users at a time. The Proposed system provides login facility so no need to remember user id and password. The new software is very fast and accurate. As there is no need of any extra manual effort, so, just need a little knowledge to operate the system. It doesnt require extra hardware devices. Existing hardware can be used to work with new software. The Proposed system solves problems related to data accessing problems, because it help the user to add details of the employee to the firm database easily, improving data recovery speed, easy searching and also provide editing of datas in the database.

2.4.1 The needs for the New System are following

The proposed system the policy holders can track their status and also they can have a check on agents, in case of being aware of frauds done by agent. The Proposed system provides domain login as per organization requirement so no need to remember user id or password, it also makes system so secure, that no one other than agent can access the system.

The proposed system provides detail general information about the customers/policy holders along personal details. It enhances the management in adding, viewing and updating details and generates various reports regarding customer/policy holder.

3 PROBLEM ANALYSES 3.1 PRODUCT DEFINITION The most important modules of the design are the customer/policy holder data, their records and status. For the customer/policy holder data module, we had to keep track of the identification number, name, policy type, amount agreement and status of customer/policy holder. We also had to link these to a general module that will hold the other entire customer/policy holder. There had to be a means of storing all these data retrieving them, adding data and deleting data without giving any errors. The records have to contain the number of policies that the customer/policy holder has worked and with what rate the interest is to be calculated. The records also had to contain the customer/policy holders payment date, that is, the date on which he has to make the payment. There was lot of paper work involved in managing the information about various facts and figures in existing system like managing the customer/policy holders information, various types of reports. Agents of the firm have to manually share their ideas which were time consuming process which makes the communication not easy and slow.

3.2 FEASIBILITY ANALYSIS

An important outcome of the preliminary investigation is the determination that the system on which we are working is feasible that is possible in reality or not. Generally, it is done by a small group of people who are familiar with system. It is an analytical tool that includes recommendation and limitations which are utilized to assist the decision makers when determining if the project is viable. This analytical tool used during the project planning process shows how a system would operate under a set of assumptions the technology used (the facilities, equipment, production process, etc.) and the financial aspects (capital needs, volume, cost of goods, wages etc.). The study is the first time in a project development process that the pieces are assembled to see if they perform together to create a technical and economically feasible concept. The study also shows the sensitivity of the business to changes in these basic assumptions. Feasibility test is done in three steps:

3.2.1 TECHNICAL FEASIBILITY

It is the process of proving that the concept is technically possible. The Technical Feasibility study assesses the details of how you will deliver a product or service. Here, in our project we are using the .net platform and some basic technical needs for making the project. Since the .net platform is easily available, the project is technical feasible. The project also, is giving the desired output till now, in as much as coding done till now. The objective of the technical feasibility step is to confirm that the product will perform and to verify that there are no production barriers. The technical feasibility step generates knowledge about the product or process's design, performance, production requirements, and preliminary production costs.

3.2.2 ECONOMICAL FEASIBILITY

A system that can be developed technically and that will be used if installed must be a good investment. The benefits should be either equal or more than the cost invested into it. To determine cost of ownership, the analyst must estimate cost in areas like people (include IT staff and user), hardware and equipment, software, house development, purchase from vendors, formal and informal training, licenses and feeds, consulting expenses, facility costs, tangible benefits and intangible benefits. An evaluation of development cost is weighted against the ultimate income or benefits derived from the developed system. There was no need of extra hardware and software for development of this project. Hence this project has economically justified for development in this organization. The cost invested in this project can be determined as: Cost of hardware and software for this will be simple cost of a computer or a laptop on which it will be run and downloading charges for the .net platform.

3.2.3 OPERATIONAL FEASIBILITY

Proposed projects are feasible only if it meets the operating requirements. If the system is developed, will it be used? A system can be said operational feasible if it is accepted by the end user, what harm can the system cause and. Our project is sufficient operational feasible to meet the requirement.

3.3 PROJECT PLAN

The planning of the project development can be summarized as follows: The process that would be implemented in building of agent information management software is the sequential process model in which we use the number of increments to develop the project phase by phase. Since this is a quite large project consisting of several modules being developed in .net framework. So, the strategy is used here to develop the project module wise like here we have different tasks in the project to perform e.g. Register User, Login Process, Authenticate User, Account Operations, Database Design, Creating Database, and Generating Progress Report. Sticking to this plan we have designed and developed:

Agent login process which includes admin user login into system. Design of all most all account operations by agent. Design of system features controlled by the agent. Design of personal account operation by agent.

SOFTWARE REQUIREMENT SPECIFICATION

A Software Requirements Specification (SRS) a requirements specification for a software system is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Nonfunctional requirements are requirements which impose constraints on the design or implementation.

4.1 Introduction

When interviewed Mr. about the current pattern of his working with the management of information and the other items he has to deal with, he said that he has to still rely upon the same pen and paper usage. He also said that he has an ample knowledge of computers but still he has no software or any compatible thing which can get him rid of pen and paper. He said that provided software which can manage his all information and remind him about his things to do, like giving a reminder about collection of amount from any policy holder, he will use that software. A few questions were asked to Mr. Dewendra Kumar Sharma in order to understand the problem which he faces in doing his work. This was done to understand his problem and it would also let us visualize little bit that what kind of software should be developed that may meet his requirements. Following questions were asked to him:
Why does he want software to be developed for him?

He said that he is fed of working on the pattern of pen and paper.

 All the calculations regarding his work are done by him, this is not only very

much time taking but there are also chances of errors to occur. He also told that he sometimes forget about updating his policy holders about their account, which causes loss to his policy holders and his own commission also has to suffer.

Why is it important to have that software?

According to him it is important to solve this problem because he wants to use the

new technology like computers and their software in his profession and take their advantage. He wants a system for him which may perform all the long calculations which he has to deal with. He also wishes to be reminded about the status of his policy holders, so that he may provide them as much as profit possible from the companies. He wants to have a feature of telling the policies which he has.

4.2 SPECIFIC REQUIREMENTS

4.2.1 Hard Ware Requirements Processor Clock Speed RAM Hard disk space: : : : Dual Core 450 MHz 700 MHz 512 MB 1GB. 30 GB.

Monitor Mouse Keyboard CD drive

: : : :

15. 3 buttons Standard 102 keys for installation

4.2.2 Software Requirements

Environment Framework OS Backend

: : : :

C#, Visual Studio .NET 2002. Version 1.0 Microsofts Windows XP, 7. MS Sql Server.

5 SYSTEM DESIGN

Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering. Here system design will contain: Data Flow Diagram. Flow Chart. Entity-Relationship Diagram.

5.1 Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel

5.1.1 0-level DFD:

This DFD contains only one process. This DFD simply shows how agent and customers will be related to each other. There is only one process between them and storage.

Agent

Customer Info Entry

Agents Information Management System

Give Info / Enquiry

Policy Holder

Customer Info

Agent Data/ Customer Status

5.1.2 Single-level DFD This DFD has 3-7 processes. In this DFD we have four processes and two storages.

Enter Policy Number

Show

Valid

Agent Management System

Generate

Status Report

Addition Update Premium Upd. Premium Paid Policy Holders Detail

Data Entry Operator

Change

Generate

Deposit Amount

Id & pwd.

Login

Policy Holder Information Updating

Policy Holders Account Info

Access

In the above given DFD we can analyze that data entry operator/agent when logins with his user id and password he gets access to update the policy holders information, which will be saved in the policy holders detail later. The agent can also enter the policy number and see the status of that policy. The agent can also take the sum of money and directly add it into his account, and then can see status report. Agent can also enter policy holders account no. and access the status report of it.

5.1.3 Symbols of DFD

Source/Destination

Process

Dataflow

Storage

5.2 ENTITY-RELATIONSHIP DIAGRAM

In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, and its requirements in a top-down fashion. Diagrams created by this process are called entityrelationship diagrams, ER diagrams, or ERDs. The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: owns relationship between a company and a computer, supervises relationship between an employee and a department. The entity-relationship diagram for our system developed till now is given on the next page.

Name Phone Email id Agent id Agent Type

Price

Policy_nu m Coverage Policy Issuing Date

Sells Policy Type Goes

Agent Custo mer

Policy Sold

Is bought Buys Owns

Name Works At P.H._Id

Policy Holder

D.O.B. Age

Phone Resides

Office
Lives In

Policy Payme nt

Pay of

Area

Address Payment State Street No. Date

This ER diagram tells us that how entities of our project are related to each other.
City Zip Amount

 We can see that the agent is related to the customer/policy holder through the agent customer relation. The customer is related to the policy by the policy sold. Both agent and the customer are related to the address by their work and living address respectively.

Policy and payment are related to each other by policy payment relationship. Attributes of each entity has also been shaped in the ovals.

5.2.1 SYMBOLS OF THE ER DIAGRAM

Attributes

Entity

Relationship

PSEUDO CODE OF PROJECT DONE TILL NOW TO START Display the login screen. Input Password. If password matches then allow entry else Display password did not match. Display The screen having buttons of ADD/DELETE/SEARCH/EDIT/UPDATE. Select the button, required. SUPPOSE ADD BUTTON IS PRESSED Input Policy id, Policy holders name, Policy holders id, Policy no., Nominee, D.O.C., D.O.M., D.O.L.P., and Sum assured. Then Press save button. Then Display Data Saved. SUPPOSE DELETE BUTTON IS PRESSED Input Policy holders id. Display the details of that id. Press delete button.

Display Are you sure? Then Press yes button Display Data deleted. SUPPOSE SEARCH BUTTON IS PRESSED Input Policy holders id. Display all the information about that id.

SUPPOSE EDIT BUTTON IS PRESSED Input Policy holders id. Display all the information of that id. Then Make changes. Then Press save button. Display edited data saved.

SUPPOSE UPDATE BUTTON IS PRESSED Input Policy holders id. Make changes Set interest % from 8 to 9. Then

Interest = (P*R*T)/100. P= Principal Amount, R= Rate, T= Time.