Автоматизация страховой деятельности. Автоматизация страхования: национальные особенности рынка

От того насколько хорошо автоматизирован процесс по заключению договоров страхования в страховых компаниях или у страховых брокеров зависят многие показатели:

• качество и скорость обслуживания страхователей при заключении договора страхования
• трудозатраты сотрудника на ввод информации в информационную систему
• качество введенной информации и возможность её обработки
• трудозатраты на информирование сотрудников компании об изменениях в условиях страхования
• разграничение конфиденциальной информации между сотрудниками компании
• механизмы контроля и мониторинга
• возможности быстрого получения необходимой информации

Основная цель автоматизации дейятельности страховой компании или страхового брокера - это создание единого информационного поля, в котором будет находиться вся необходимая информация, используемая в компании. Чем больше данное информационное поле и шире охват операций, тем эффективнее работает страховая компания или страховой брокер .

Давайте рассмотрим процесс и схему наиболее распространенного варианта учета договоров страхования :

Варианты схемы могут быть различными, но в большинстве случаях деятельность компаний полностью не автоматизирована, в связи, с чем остается так называемый "ручной труд". Он может проявляться в разных вариантах:

• ввод информации в систему оператором или агентом на основании заключенного договора страхования, либо загрузка из файлов, что требует дополнительных трудозатрат;
• передача методической информации о условиях и порядке расчета страховой премии по различным страховым продуктам;
• передача данных из информационной системы сотрудникам отдела продаж;
• двойная работа по отражению информации в различных базах данных (например в страховом учете и бухгалтерском).

В каждой конкретной ситуации возможны различные варианты, бывает, что информационная система вообще отсутствует и учет ведется подручными программами.

В результате, при экономии на автоматизации бизнес-процессов , компании ежедневно теряют в производительности труда, что проявляется на качестве предоставляемых ими услуг и как следствие, конкурентоспособности. Также снижается оперативность и качество принимаемых решений, из-за отсутствия в нужный момент финансовой и управленческой информации.

Давайте рассмотрим пример автоматизации страхового учета с использованием решения АДС: " Учет договоров страхования 8 .2" , который разработан компанией "АДС Софт" на основании многолетнего опыта работы по автоматизации деятельности страховых компаний и страховых брокеров.

Возможности программного решения :

• организация работы агентов в режиме on-line с информационной базой данных, даже при слабых каналах связи (достаточно скорости работы GPRS- соединение с мобильного телефона)
• учет договоров страхования (автострахование, имущество, НС, ОСАГО)
• автоматический расчет премии (калькулятор)
• автоматизация пролонгации договоров страхования
• печать полисов , заявлений и прочих бланков
• учет оплат и счетов на оплату по договорам страхования
• учет комиссионного вознаграждения
• учет бланков строгой отчетности (БСО) , закрепленных за ответственным сотрудником и местом хранения
• получение управленческой отчетности по договорам и статистике их заключения, оплатам и просроченным платежам , о необходимости пролонгации договоров , срок действия которых заканчивается, по местонахождению бланков и их количестве и прочей информации
• рассылка смс-сообщений (уведомлений)
• обмен данными с программой 1С: Бухгалтерия 8 в автоматическом режиме, или осуществление обмена с другими системами при помощи внешних файлов

С точки зрения безопасности и защиты конфиденциальной информации , решение позволяет организовать работу пользователей только со своими договорами страхования, которые они заключили. В свою очередь многоуровневая структура пользователей позволяет руководителем видеть информацию о договорах по подчиненным им сотрудникам. А механизмы настроенных ролей позволяют ограничить функции сотрудников, при работе с информационной системой.Зоны автоматизации страховой и бухгалтерской деятельности:

Процесс автоматизации страхового брокера или страховой компании , можно разделить на зоны и рассмотреть каждую:

1. Автоматизация процесса заключения договоров страхования
2. Автоматизация учета бланков строгой отчетности
3. Автоматизация страховой бухгалтерии

Автоматизация процесса заключения договоров страхования:

Описание процесса:

Процесс заключения договоров страхования всем известен и состоит из:

• Выбора страховой компании (при обращении к страховому брокеру)
• Сбора информации о страхователе, допущенных к управлению ТС и прочих контрагентов
• Создания ксерокопий всех необходимых документов
• Заполнения страхового полиса, квитанций А-7 и прочих бланков строгой отчетности
• Получения денежных средств от страхователя

Решение задачи:

Рассмотрим, каким образом можно автоматизировать работу страхового агента и фронт-офиса с использованием решения АДС: "Учет договоров страхования 8.2"

Благодаря возможности работы с базой данных через web-браузеры при минимальном канале связи , необходимость в двойной работе по оформлению и вводу информации в базу данных отпадает. При встрече с клиентом агент сразу вводит информацию в базу данных, на основании которой он может распечатать страховой полис, заявление или другую печатную форму предусмотренную продуктом страхования. Дополнительно, при заключении договора страхования ОСАГО, он может в автоматическом режиме рассчитать размер страховой премии.

При осуществлении оплаты договора страхования, агент выписывает страхователю квитанцию А-7 и принимает денежные средства. Факт приема денежных средств отражается в системе и моментально становится, виден руководителю. Кроме этого при вводе данных договора страхования в систему, происходит списание бланков строгой отчетности в автоматическом режиме, и как следствие не требует предоставления соответствующих отчетов от материально ответственного лица.

Учитывая, что вся информация введена в базу данных, ничего не мешает агенту и руководителям получать всю необходимую информацию о просроченных платежах, о договорах страхования, действие которых в скором времени будет прекращено, в режиме реального времени.

Ещё один плюсом можно считать, что при изменении условий страхования, или печатной формы, нет необходимости руководителю оповещать сотрудников об этом, для этого достаточно произвести необходимые настройки в информационной системе из бэк-офиса и актуальная информация сразу станет доступна. Дополнительная опция "Модуль СМС-информирования " позволит организовать информирование клиентов о пролонгации, напоминания по взносам или, к примеру, направлять поздравления.

Положительные выводы:

• отсутствует необходимость в двойной работе при заключении договора страхования;
• процесс ввода данных в систему выполняется на местах, при заключении договора;
• автоматическая печать полисов, сокращая время агента;
• автоматический расчет страховой премии (калькулятор), сокращает время агента;
• отражение изменений в условиях страхования осуществляется незамедлительно и без обязательного информирования агентов;
• руководители получают информацию в режиме реального времени;
• агентам предоставляется необходимая информация для работы с клиентами (пролонгация, оповещение о не уплаченном страховом взносе);
• автоматизирован процесс учета бланков строгой отчетности.

Автоматизация учета бланков строгой отчетности (БСО)

Описание процесса:

Процесс учет бланков строгой отчетности (учет БСО) доставляет неудобства, как для страховой компании, так и для страхового брокера. По причине большого количества бланков и их видов. Принципиальных отличий между учетом страховых компаний и брокеров нет, есть небольшие отличия в документообороте.

Наиболее сложный процесс - это инвентаризация, проводимая в компании, при отсутствии единой информации по бланкам данная процедура становится особенно тяжелой. Кроме этого желательно учитывать состояния каждого бланка строгой отчетности (чистый, испорченный и прочие).

Решение задачи:

Программный продукт " АДС: Учет договоров страхования 8.2" позволяет полностью автоматизировать процесс учета бланков строгой отчетности и отразить весь документооборот. В программе предусмотрена настройка для каждого вида бланков, например, информацию о полисах ОСАГО требуется хранить и проверять в разрезе состояний, таким образом, программа не пропустит списание бланка при заключении договора, который имеет статус "украден". Программа заблокирует данную операцию и предотвратит ввод невозможной информации. А для общенумерных бланков, например, можно убрать настройку проверок, т.к. особой ценности для компании они не представляют.

Программа предусматривает загрузку начальных остатков , с помощью специального механизма в автоматическом режиме, что облегчает ввод правильной информации при начале работы с системой.

Программа позволяет вести учет поступивших, перемещенных и списанных партий бланков, в разрезе каждого бланка или диапазона бланков. Кроме этого при заключении договора страхования агентом, списание бланка происходит автоматически , что не требует дополнительных действий со стороны агента.

Система отчетов позволяет просматривать информацию о местонахождении конкретного бланка или диапазона бланков, историю его движений, и остатках в разрезе каждого материально ответственного лица.

Положительные выводы:

• отражение любого перемещения бланков в единой системе в режиме on-line
• быстрый просмотр текущего количества и состояний бланков в разрезе каждого материально ответственного сотрудника
• возможность быстрого определения необходимости выдачи бланков
• контроль над операциями и невозможность некорректного отражения в системе
• автоматизация инвентаризации проводимой в компании
• сокращение трудозатрат сотрудников на поиск бланков

Автоматизация страховой бухгалтерии

Описание процесса:

Очень часто страховой учет ведется отдельно от бухгалтерского учета. При данной схеме существуют процессы, требующие автоматизации:

• отражение договоров страхования
• отражение оплат по договорам страхования
• начисление комиссионного вознаграждения
• отражение операций по бланкам строгой отчетности

Зачастую данные операции производятся в "ручном режиме", что требует трудозатрат со стороны бухгалтера.

Решение задачи:

В прикладном решении "АДС: Учет договоров страхования 8.2" данные процессы автоматизированы для работы с программой 1С:Бухгалтерия 8 , с помощью планов обмена (аналогично механизму обмена данными между программами 1С:Бухгалтерия 8 и 1С:Управление торговлей или 1С:Зарплата и управление персоналом ). Таким образом, например, при получения платежа через систему клиент-банк, после загрузки его в систему 1С: Бухгалтерия 8, информация о данном платеже, с обменом данными, мигрирует в информационную базу данных АДС: Учет договоров страхования 8.2. Или в обратную сторону будет мигрирована информация по договорам страхования, размеру комиссионного вознаграждения.

Положительные выводы:

• страховая информация автоматически отражается в бухгалтерской программе и снимается нагрузка с работы бухгалтера
• исключаются ошибки, вызванные человеческим фактором
• информация отражается по мере её поступления и напрямую не зависит от работы бухгалтера

Таким образом, использование решения учет договоров страхования на платформе 1С: Предприятие 8.2, в качестве единой информационной системы для учета страховых операций , откроет перед страховой компанией или страховым брокером новые возможности по контролю и получению информации в режиме реального времени.

Внедрение данного решения позволит:

• получать управленческую отчетность и осуществлять контроль над деятельностью компании в режиме реального времени;
• автоматизировать процесс заключения договоров страхования и избавиться от двойного труда;
• разграничить конфиденциальную информацию о договорах страхования;
• автоматизировать учет бланков строгой отчетности, отражения взносов и комиссионного вознаграждения;
• автоматизировать обмен данными между страховым и бухгалтерским учетом;
• предоставить инструменты руководителям и агентам для работы с клиентами компании;
• предоставить новый сервис клиентам в виде "смс-информирования";

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

• Содержание
• Постановка задачи
• Введение
• 1. Системное проектирование
• 1.1 Страхование, его место в социально-экономической политике государства
• 1.2 Договор страхования
• 1.3 Особенности построения тарифов по страхованию
• 2. Функциональное проектирование
• 2.1 Обоснование выбора методов и средств разработки
• 2.2 Разработка приложения
• 2.2.1 Разработка диаграмм UML
• 2.2.2 Построение диаграммы использования
• 2.2.3 Построение диаграммы последовательности
• 2.2.4 Разработка диаграммы классов
• 2.3 Разработка и построение функциональной модели
• 2.4 Разработка информационной модели
• 2.5. Руководство пользователя
• Заключение
• Список использованных источников
• Приложение 1. Листинг программного кода

Постановка задачи

Курсовая работа представляет собой систему для автоматизации работы страховой компании. Основной характеристикой, необходимой для использования системы пользователям, являются логин и пароль. Пользователи делятся на три группы, в зависимости от уровня доступа к различным операциям:

· администратор - имеет доступ ко всем возможным операциям;

· агент - имеет доступ ко всем операциям по работе с документами (клиенты, страховые полисы);

· пользователь - имеет ограниченный доступ к данным (только поиск и чтение документов).

Имеется следующий набор документов и действий над ними.

Документы:

· информация о клиенте;

· страховой полис клиента;

· информация о зарегистрированном пользователе.

Действия:

· создание, редактирование, удаление документов;

· поиск документов;

· просмотр списка документов;

· восстановление удаленных документов;

· импортирование статистических данных;

· расчет различных показателей работы страховых компании на основе имеющихся документов и статистических данных.

Все данные хранятся на сервере в базе данных. Доступ к информации могут осуществлять одновременно несколько пользователей. Так как приложение предназначено для использования в Интернете, то оно представляет собой клиент-серверное приложение, обмен данными происходит по HTTP протоколу. Клиентской частью является HTML страница, содержащая в себе информацию. Серверной часть проекта является приложение, реализованное с использованием сервлетов, которые обрабатывают приходящие со страницы данные и формируют ответ. Функционал для расчета параметров реализован в виде отдельных компонентов, которые являются сторонним продуктом и могут добавляться в программу в виде расширения с помощью конфигурационного файла.

Введение

В современном мире Интернет стал неотъемлемой частью жизни многих людей. Руководители предприятий, сотрудники фирм, служащие, студенты, школьники проводят значительную часть своего рабочего и свободного времени в сети. Интернет дает возможность производить денежные операции, покупки, общаться с друзьями, знакомиться. Также Интернет является источником всесторонней информации, там можно найти ответ практически на любой вопрос.

В настоящее время Интернет доступен практически для любого человека и в любом месте. Поэтому большое распространение получили системы, представляющие собой Интернет приложения, позволяющие получить доступ к данным тогда, когда в этом есть необходимость.

С появлением новых технологий и языка программирования JAVA в частности, ориентированного на Интернет, осуществление данных потребностей становиться легче, а также появляются новые возможности и пространство для реализации всех задумок.

Данная курсовая работа представляет собой систему автоматизации работы страховой компании. С помощью этой системы работа страховой компании становится более простой, она облегчает работу страховых агентов, так как теперь нет необходимости обращаться в агентство для того, чтобы получить страховку, теперь агент может приехать в любое удобное для Вас место и заключить договор. Так же система позволяет вести статистику и производить анализ деятельности страховой компании, что делает работу страховой компании более продуктивной, так как наглядно видны показатели работы компании, на основе которых можно корректировать дальнейшую работу, для того, чтобы повысить прибыль и своевременно исправлять допущенные ранее ошибки.

1. С истемное проектирование

1.1 Страхование, его место в социально-экономической политике государства

Страхование - это договор, по которому одна сторона (называемая страховщиком) в обмен на вознаграждение (называемое премией) берет на себя обязательство уплатить другой стороне (называемой страхователем) определенную сумму денег или ее эквивалент в натуре после наступления определенного события, ущемляющего интерес страхователя. Экономическая сущность страхования состоит в образовании специализированными организациями - страховыми компаниями формируемого из взносов страхователей (премия) страхового фонда, из которого возмещаются убытки, понесенные страхователями в результате страховых случаев, покрытых страхованием. Страхование делится на имущественное, личное и страхование ответственности перед третьими лицами и может носить обязательную форму, возникающую в силу закона, или добровольную форму, облаченную в договор страхования между страхователем и страховщиком.

1 .2 Договор страхования

Договор страхования - двусторонняя сделка, в которой одной из сторон является гражданин (страхователь), а другой - страховая организация, имеющая право на заключение сделок такого рода. Договор страхования заключается в простой письменной форме, причем независимо от размера страховой суммы нотариального удостоверения не требуется.

По договору личного страхования одна сторона (страховщик) обязуется за обусловленную договором плату (страховую премию), уплачиваемую другой стороной (страхователем), выплатить единовременно или выплачивать периодически обусловленную договором сумму (страховую сумму) в случае причинения вреда жизни или здоровью самого страхователя или другого названного в договоре гражданина (застрахованного лица), достижения им определенного возраста или наступления в его жизни иного предусмотренного договором события (страхового случая).

Право на получение страховой суммы принадлежит лицу, в пользу которого заключен договор.

Договор личного страхования считается заключенным в пользу застрахованного лица, если в договоре не названо в качестве выгодоприобретателя другое лицо. В случае смерти лица, застрахованного по договору, в котором не назван иной выгодоприобретатель, выгодоприобретателями признаются наследники застрахованного лица.

Договор личного страхования в пользу лица, не являющегося застрахованным лицом, в том числе в пользу не являющегося застрахованным лицом страхователя, может быть заключен лишь с письменного согласия застрахованного лица. При отсутствии такого согласия договор может быть признан недействительным по иску застрахованного лица, а в случае смерти этого лица по иску его наследников.

Договоры смешанного страхования жизни заключаются с лицами в возрасте от 16 до 65 лет, страхования детей - без ограничения возраста, страхования к бракосочетанию - от 20 до 67 лет. Возраст страхователя в заявлении о страховании указывается в полных годах, документального подтверждения возраста от страхователя не требуется.

Возраст лица, в пользу которого заключается договор смешанного страхования жизни, не имеет значения. Иное дело возраст третьих лиц, т. е. детей, в пользу которых заключаются договоры страхования детей и страхования к бракосочетанию. Он обязательно должен быть записан в заявлении о страховании.

Родителям (усыновителям), родственникам ребенка и его опекунам предлагается право заключить договор страхования к бракосочетанию, если возраст ребенка не менее 2 и не более 15 лет. Договоры страхования детей заключаются при условии, что ребенку не более 15 лет.

Заявление о страховании - важный юридический документ, который, как правило, заполняется страховым агентом (инспектором), но со слов страхователя. Нельзя принимать заявление о страховании, если оно подписано не тем лицом, от имени которого подается, так как в этом случае договор страхования признается недействительным.

Страховая организация не перепроверяет указанные страхователем в заявлении сведения о возрасте, состоянии здоровья, отсутствии группы инвалидности и др., но имеет право в определенных случаях проверить данные страхователем сведения.

В заявлении о страховании необходимо указать месяц, в котором страхователь обязался уплатить первый страховой взнос, и форму уплаты в дальнейшем (по безналичному расчету или наличными деньгами). Договоры смешанного страхования жизни не заключаются с инвалидами I и II групп и с лицами, страдающими такими заболеваниями, как: все виды пороков сердца, гипертоническая болезнь, стенокардия, инфаркт миокарда, язвенная болезнь желудка и 12-перстной кишки, туберкулез, злокачественные опухоли и т. д. Эти заболевания включены в противопоказания потому, что они могут привести к преждевременной смерти страхователя.

Договор личного страхования по своей юридической природе является договором в пользу третьего лица. Поэтому страхователю предоставляется неоспоримое право указать в заявлении о смешанном страховании жизни любое лицо (или несколько лиц), которое он назначает для получения страховой суммы в случае своей смерти. Однако в качестве третьего лица могут быть только физические лица (граждане).

Для каждого вида страхования устанавливаются различные сроки страхования, т. е. сроки, в течение которых страховая организация выполняет принятые на себя обязательства. Договоры смешанного страхования жизни заключаются на точно установленный срок - 5, 10, 15 или 20 лет. По договорам страхования детей, так же как и по договорам страхования к бракосочетанию, заранее установленных сроков страхования нет. Однако по договорам страхования детей максимальный срок страхования не может превышать 18 лет.

По договору смешанного страхования жизни размер взносов устанавливается в зависимости от срока страхования, страховой суммы и возраста страхователя, а по договорам страхования детей размер взносов зависит от возраста ребенка, страховой суммы, срока страхования и продолжительности уплаты взносов.

Условиями всех видов страхования жизни установлена ежемесячная уплата взносов, а по договорам страхования детей и смешанного страхования жизни они могут быть внесены единовременно. Как правило, ежемесячные взносы должны уплачиваться в течение всего срока страхования, однако по договорам страхования детей они могут быть внесены и в сокращенный период, который зависит от возраста ребенка.

Уплата взносов в сокращенный период не дает права на получение страховой суммы ранее, чем истечет срок, на который заключен договор страхования. Страхователь лишь освобождается от необходимости уплачивать взносы в течение оставшихся до конца срока страхования лет и гарантирует ребенку получение страховой суммы даже в случае своей смерти.

Началом срока страхования считается 1-ое число того месяца, в котором страхователь обязался уплатить первый (или единовременный) взнос, а окончанием - последнее число предшествующего месяца через столько лет, на сколько заключен данный договор страхования.

Начало течения срока страхования следует отличать от вступления договора страхования в силу. Оформление заявления о страховании и выписка страхового свидетельства означает лишь факт заключения договора страхования, для того же, чтобы по такому договору страхования возникли обязательства страховой организации, связанные с выплатой страховой суммы, необходимо, чтобы он вступил в силу.

По договорам смешанного страхования жизни и страхования детей страхователям предоставляется право в любое время уменьшить размер страховой суммы и в связи с этим уплачивать взносы в меньшем размере. Для этого страхователь должен подать соответствующее заявление с приложением страхового свидетельства.

При уменьшении страховой суммы часть ранее уплаченных взносов (резерв) оказывается свободной, поскольку по истечении срока страхования страховой организации предстоит выплатить меньшую сумму, чем предполагалось при заключении договора. Эта часть взносов не возвращается страхователю, но засчитывается в счет уплаты будущих взносов. В том случае, если свободного резерва взносов оказывается достаточно, чтобы оплатить договор страхования до конца срока и даже оказывается излишек, то последний возвращается страхователю, а договор продолжает действовать в уменьшенной страховой сумме до истечения указанного в нем срока, но уже без уплаты взносов. Уменьшение страховой суммы может быть произведено не только с того месяца, в котором об этом подано заявление, но и с любого другого по желанию страхователя.

Договоры смешанного страхования жизни в определенных случаях могут быть досрочно прекращены. Договор страхования, хотя и является добровольным соглашением двух контрагентов - страхователя и страховой организации, - досрочно может быть прекращен только по инициативе одной стороны - страхователя. Страховая организация такого права не имеет.

1.3 Особенности построения тарифов по страхованию

Построение тарифов по страхованию жизни имеет следующие особенности:

1. Расчеты производятся с использованием демографической статистики и теории вероятности.

2. При расчетах применяются способы долгосрочных финансовых исчислений.

3. Тарифные ставки-нетто состоят из нескольких частей, каждая из которых призвана сформировать страховой фонд по одному из видов страховой ответственности, включенных в условия страхования.

Сочетание математических методов, применяемых в статистике, теории вероятности и долгосрочных финансовых исчислений породило особую отрасль науки -- теорию актуарных расчетов, на основе которой устанавливаются тарифные ставки и резерв взносов по страхованию жизни. Актуарные расчеты -- это система математических и статистических методов, с помощью которых определяются финансовые взаимоотношения страховщика и страхователя по долгосрочному страхованию жизни.

Тарифная ставка определяет, сколько денег каждый из страхователей должен внести в общий страховой фонд с единицы страховой суммы. Поэтому тарифы должны быть рассчитаны так, чтобы сумма собранных взносов оказалась достаточной для выплат, предусмотренных условиями страхования. Таким образом, тарифная ставка -- это цена услуги, оказываемой страховщиком населению, т.е. своеобразная цена страховой защиты. От чего же зависят ее размеры, как установить цену на тот или иной вид страхования жизни?

Полная тарифная ставка называется брутто-ставкой. Она состоит из нетто-ставки и нагрузки. Задача нетто-ставки -- обеспечить выплаты страховых сумм, т.е. выполнение финансовых обязательств страховщика по договорам страхования. Нагрузка предназначена компенсировать расходы на ведение страховых операций.

Своеобразие операций страхования жизни проявляется при построении нетто-ставки. Условия страхования жизни обычно предусматривают выплаты в связи с дожитием застрахованного до окончания срока действия договора страхования или в случае его смерти в течение этого срока. Кроме того, предусматриваются выплаты в связи с потерей здоровья вследствие травмы и некоторых болезней.

Таким образом, для исчисления объема страхового фонда нужно располагать сведениями о том, сколько лиц из числа застрахованных доживет до окончания срока действия их договоров страхования и сколько из них каждый год может умереть, у скольких из них и в какой степени наступит потеря здоровья. Количество выплат, помноженное на соответствующие страховые суммы, позволит определить размеры предстоящих выплат, т.е. появится возможность узнать, в каких размерах нужно будет аккумулировать страховой фонд.

Продолжительность жизни отдельных людей колеблется в широких пределах. Она относится к категории случайных величин, численное значение которых зависит от многих факторов, настолько отдаленных и сложных, что, казалось бы, их невозможно выявить и изучить. Теория вероятности и статистика исследуют случайные явления, имеющие массовый характер, в том числе смертность населения. Установлено, что демографический процесс смены поколений, выражаемый в изменении уровня повозрастной смертности, подчинен закону больших чисел, сталь однообразному в своих проявлениях и столь достоверному в результатах, что он в состоянии служить основой финансовых расчетов в страховании.

Демографической статистикой выявлена и выражена с помощью математических формул зависимость смертности от возраста людей. Разработана специальная методика составления так называемых таблиц смертности, где на конкретных цифрах показывается последовательное изменение смертности вслед за возрастом. Этими таблицами страховые организации пользуются для расчета тарифов.

Кроме закономерностей, связанных с процессом доживаемости и смертности, при построении тарифов учитывается долгосрочный характер операций страхования жизни, поскольку эти договоры заключаются на длительные сроки: 3 и более лет. В течение всего времени их действия (или в самом начале срока страхования при единовременной уплате) страховые органы получают взносы. Выплаты же страховых сумм производятся на протяжении срока страхования или по истечении определенного периода от начала действия договора, если наступит смерть застрахованного или он утратит здоровье.

Временно свободные средства, аккумулируемые страховой организацией, используются как кредитные ресурсы. За пользование ими уплачивается ссудный процент. Но если при сберегательной операции доход от процентов присоединяется ко вкладу, то в страховании на сумму этого дохода заранее уменьшаются (дисконтируются) подлежащие уплате взносы страхователя. Для того чтобы заранее понизить тарифные ставки на тот доход, который будет складываться в течение ряда лет, используются методы теории долгосрочных финансовых исчислений.

Тарифные ставки в страховании жизни состоят из нескольких частей. Возьмем для примера смешанное страхование жизни. В кем объединяются несколько видов страхования, которые могли бы быть и самостоятельными: 1) страхование на дожитие; 2) страхование на случай смерти; 3) страхование от несчастных случаев. По каждому из них при помощи тарифа создается страховой фонд, поэтому тарифная ставка в смешанном страховании состоит из трех частей, входящих в нетто-ставку, и четвертой части -- нагрузки. Аналогично складывается структура тарифных ставок и по другим видам страхования жизни.

2. Ф ункциональное проектирование

2. 1 Обоснование выбора методов и средств разработки

Для решения поставленной задачи был выбран язык программирования JAVA. Выбор данного языка программирования обуславливается следующими причинами:

- Данный язык программирования является кроссплатформенным, поэтому использование программного продукта, написанного на этом языке возможно на любой платформе и для любой операционной системы;

- Существует целый ряд стандартных библиотек, которые включают в себя набор классов, предназначенных для облегчения разработки приложения. Они включают в себя ряд часто встречающихся классов, таких как класс: реализующий работу с динамическим массивом, с хэш-таблицей, со строками и так далее;

- Язык программирования JAVA специально создавался для реализации Интернет приложений. Также существует множество различных технологий, которые позволяют сделать разработку проекта простым и приятным.

Курсовой проект представляет собой Интернет-приложение, поэтому для его написания использовалась такая технология, как JSP (Java Server Pages). Данная технология упрощает написание серверных приложений, так как позволяет совмещать в себе HTML тэги и код программы, написанный на языке программирования JAVA. Также существует возможность расширять набор стандартных компонентов, реализуя собственные.

Курсовой проект написан с использованием модели MVC (Model-View-Control). Данная технология позволяет создавать расширяемые программы, удобные для сопровождения. Такой подход позволяет объединить сервлеты, JSP и компоненты bean, с помощью чего можно разделить бизнес-объекты и уровень представления (JSP-документы), что очень важно для больших и сложных проектов, где бизнес логика постоянно претерпевает изменения.

Модель MVC построена на концепции Model 2. Согласно данной концепции все запросы обрабатываются одним сервлетом (так называемым servlet controller). Описание событий (actions) осуществляется с помощью конфигурационного файла, в котором содержится имя события и класс-обработчик данного события. Контроллер, при получении события, проверяет на наличие его в контейнере событий. Если событие есть, то контейнер создает соответствующий обработчик события и вызывает у него метод для обработки данного события.

В качестве средства разработки приложения использовалась среда разработки IntelliJ IDEA. Данный программный продукт имеет набор возможностей, предназначенных для облегчения процесса разработки: имеется довольно большое количество горячих клавиш; дополнительно к имеющимся встроенным возможностям данной среды разработки, существует целый набор утилит (plugins), предназначенных для расширения уже существующих возможностей среды.

2.2 Разработка приложения

2.2.1 Разработка диаграмм UML

UML (Unified Modeling Language) - унифицированный язык моделирования - стандартная нотация визуального моделирования программных средств.

Визуальное моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы.

При визуальном моделировании на UML используются семь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Рассмотрим диаграммы, использованные при моделировании данного курсового проекта.

2.2.2 Построение диаграммы использования

Диаграмма Использования (UseCase Diagram) - это диаграмма, описывающая функциональность информационной системы, которая будет видна пользователям системы.

Диаграмма Вариантов Использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

UseCase диаграмма используется для:

1. определения общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы;

2. формулировки общих требований к функциональному поведению проектируемой системы;

3. разработки исходной концептуальной модели системы для ее последующей детализации в форме логических и физических моделей;

4. подготовки исходной документации для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Проектируемая система представляется в виде множества сущностей или актёров, взаимодействующих с системой с помощью вариантов использования.

Варианты использования (прецеденты) и действующие лица (актёры) определяют сферу применения создаваемой системы (проекта). При этом варианты использования описывают все то, что происходит внутри системы, а действующие лица -- то, что происходит снаружи.

Актёром может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик.

Можно также заметить, что вариант использования служит для описания сервисов, которые система предоставляет актеру. Иными словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актёром.

Рис. 2.2.2.1 Диаграмма вариантов использования

При запуске приложения, пользователю предоставляется возможность авторизироваться для входа в систему. После входа в систему, определяется роль пользователя, на основе которой для него становится возможным определенный набор действий. После окончания работы с приложением, пользователь может покинуть приложение, возвратившись на страницу авторизации для того, чтобы дать возможность работать другим пользователям.

2 . 2 . 3 Построение диаграммы последовательности

Одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов, из которых образованы эти системы. Речь идет о том, что различные составные элементы систем не существуют изолированно, а оказывают определенное влияние друг на друга, что и отличает систему как целостное образование от простой совокупности элементов.

В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.

На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, как известно, представляет собой экземпляр класса.

Рис. 2.2.3.1 Диаграмма последовательности (авторизация пользователя).

В качестве примера на рис. 2.2.3.1 приводится диаграмма описания жизненного цикла и взаимодействие уровней приложения во время авторизации пользователя.

При вводе авторизационных данных, пользователь отправляет запрос приложению. Запрос поступает на контроллер действий (Controller), который контролирует работу обработчиков событий. Далее контроллер перенаправляет запрос на уровень бизнес логики (Model). Который выполняет необходимые действия для осуществления запроса (создание соединения с базой данных, формирование запроса, выполнение его, получение результата, анализа полученных данных, формирование результата на основе полученных данных). Далее результат возвращается назад контроллеру, который в зависимости от полученного результата перенаправляет ответ (response), на уровень представления (View), который реализует непосредственное отображение необходимой инфрмации пользователю.

2 . 2 . 4 Разработка диаграммы классов

Диаграмма классов - основная диаграмма для создания кода приложения. При помощи диаграммы классов создается внутренняя структура системы, описывается наследование и взаимное положение классов друг относительно друга. Здесь описывается логическое представление системы. На данной диаграмме не указывается информация о временных аспектах функционирования системы. Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы, которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.

Классы в проекте можно разделить на несколько частей по их функциональной нагрузке:

· классы реализующие DAL (data access layer);

· классы, реализующие уровень “Controller” для управления работой приложения;

· классы, реализующие обработку запросов (action handlers);

· классы, предназначенные для хранения и передачи данных между клиентом, сервером и уровнями приложения (beans);

· вспомогательные классы (helpers).

Рис. 2.2.4.1 Классы, реализующие уровень доступа к данным(DAL)

· IDataDAO - интерфейс, который должны реализовывать все классы, описывающие конкретную реализацию DAO уровня документа.

· PersonDataDAOImpl - реализация DAO уровня документа “Contact”.

· PolicyDataDAOImpl - реализация DAO уровня документа “Policy”.

· UserDataDAOImpl - реализация DAO уровня документа “User”.

· SearchDataDAOImpl - реализация DAO уровня логики поиска документов.

· ListDataDAOImpl - реализация DAO уровня логики формирования страниц отображения списка документов.

· ImportDataDAOImpl - реализация DAO уровня логики, реализующей импортирование статистических данных, которые используются для расчета параметров, характеризующих работу страховой компании.

· DataDAOHelper - класс, включающий в себя общую логику работы DAO уровня (открытие транзакции, создание экземпляра реализации DAO уровня для конкретного документа, описанного в конфигурации).

· UserDataDAOHelper - класс, расширяющий общую логику работы DAO уровня, включает в себя специфическую логику работы с документом “User”.

· SearchDataDAOHelper - класс, расширяющий общую логику работы DAO уровня, включает в себя специфику работы DAO уровня при осуществлении поиска.

Рис. 2.2.4.2 Controller layer

· ActionHelper - вспомогательный класс, предназначенный

· для работы с входными/выходными данными.

· ServletController - основной класс данного уровня,

· производит управление выполнением действий в зависимости от полученных данных от пользователя.

· ActionHandlerFactory - класс - фабрика, предназначенный

· для создания экземпляров обработчиков событий, которые описаны в конфигурационном файле.

Рис. 2.2.4.3 Классы, реализующие обработку запросов

· IActionHandler - интерфейс, который должны реализовывать все обработчики событий.

· LoginActionHandler - класс - обработчик событий, которые приходят со страницы авторизаии.

· HomeActionHandler - класс - обработчик событий, которые приходят со стартовой страницы приложения.

· AdminActionHandler - класс - обработчик событий, которые приходят со страницы администрирования.

· ImportActionHandler - класс - обработчик событий, приходящих со страницы импортирования статистических данных.

· PersonActionHandler - обработчик событий при работе с документом “Contact”.

· PolicyActionHandler - обработчик событий при работе с документом “Policy”.

· UserActionHandler - обработчик событий при работе с документом “User”.

· AbstractSearchActionHandler - класс, содержащий в себе общую логику обработки событий при совершении поиска.

· PersonSearchActionHandler - класс - обработчик событий, происходящих при поиске документов типа “Contact”.

· PolicySearchActionHandler - класс - обработчик событий, происходящих при осуществлении поиска документов типа “Policy”.

· UserSearchActionHandler - обработчик событий, происходящих при осуществлении поиска документов типа “User”.

Рис. 2.2.4.3 Классы, предназначенные для хранения/передачи данных (Beans)

· IEntity - интерфейс, содержащий методы, которые необходимо реализовать в классах - контейнерах.

· PersonBean - класс, хранящий в себе данные документа типа “Contact”.

· PolicyBean - класс, хранящий данные документа типа “Policy”.

· UserBean - класс, хранящий данные документа типа “User”.

2 . 3 Разработка и построение функциональной модели

страхование проектирование диаграмма uml

Специализированным средством для создания и разработки функциональных моделей систем является пакет BPwin.

Модель в BPwin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс в виде разбиения его на шаги и подпроцессы. С помощью соединяющих дуг описываются объекты, данные и ресурсы, необходимые для выполнения функции.

Исходя из задания данного курсового проекта, целью моделирования системы является описание функциональности разрабатываемой системы для дальнейшего использования созданной модели при разработке информационной модели.

Диаграммы - это главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Диаграммы строятся при помощи блоков. Каждый блок описывает какое-либо законченное действие. Четыре стороны блока имеют различное предназначение:

– слева отображаются входные данные, исходные ресурсы для описываемой блоком функции;

– справа описываются выходные ресурсы - это результирующие ресурсы, полученные в результате выполнения описываемой блоком функции;

– сверху - управление - это то, что воздействует на процесс выполнения описываемой блоком функции и позволяет влиять на результат выполнения действия (правила, стратегии, процедуры или стандарты, которыми руководствуется работа);

– снизу - механизм - это то, посредствам чего осуществляется данное действие.

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария процесса в разных ракурсах:

1) диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD);

2) диаграммами Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

При моделировании курсового проекта использована только PFDD диаграмма.

Прямоугольники на диаграмме PFDD называютсяфункциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Стрелки или линии являются отображением перемещения информации между UOB-блоками в ходе процесса.

Перекрестки (Junction) используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.

В данной работе стандарт IDEF3 был использован для наглядной иллюстрации процессов работы с автоматизированной системой анализа финансовых операций по страхованию.

Рис. 2.3.1 Функциональная диаграмма «Автоматизация работы страховой компании»

Для входа в систему пользователю предоставляется возможность произвести авторизацию. После успешного входа в систему пользователю предоставляется набор действий (добавление новых данных, просмотр, поиск данных, расчет показателей). После совершения очередной операции пользователь может выбрать следующую операцию либо выйти из системы.

Рис. 2.3.2 Декомпозиция блока «Добавление новой информации»

Для добавления новых документов в базу данных пользователю необходимо заполнить предлагаемую форму, после этого происходит проверка корректности данных, если данные корректны, происходит сохранение, если данные некорректны, то пользователь получит соответствующее сообщение.

Рис. 2.3.3 Декомпозиция блока «Поиск данных»

Для осуществления поиска необходимой информации пользователь должен заполнить форму данными, по которым будет производиться поиск. После этого происходит проверка корректности данных, если данные корректны, то результат поиска отобразится на экране, если данные некорректны, то пользователь получит сообщение, в котором будет описано какие данные и почему некорректны.

2. 4 Разработка информационной модели

Данное приложение работает с большим количеством данных, поэтому существует необходимость в правильно построенной структуре хранения данных. Для решения этой проблемы использовалось CASE-средство Erwin.

ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.

Данное средство предоставляет ряд возможностей при проектировании, такие как:

- прямое подключение к базе данных: создание структуры базы данных

непосредственно из ERwin, восстановление модели существующей БД:

- переход от одной целевой базы данных к другой с использованием

взаимооднозначных соответствий особенностей СУБД;

- управление физическими характеристиками хранения данных (для

Oracle и Sybase - табличным пространством и сегментами соответственно);

- хранимые наборы параметров отображения для построения отчетов и

диаграмм;

- процедуры и триггеры описываются при построении модели и

автоматически создаются в БД при генерации;

- возможность манипулирования атрибутами;

- возможность хранения диаграммы в целевой базе данных или в DBF файлах:

- поддержка системы контроля версий IVCS;

- шрифтовое и цветовое выделение. Реализация моделирования и ERwin

базируется на теории реляционных баз данных и на методологии IDEF1X.

Методология IDEF1X определяет стандарт терминологии, используемой при информационном моделировании, и графического изображения типовых элементов на диаграммах.

Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый -- логический (точка зрения пользователя) -- описывает данные, задействованные в 6изнесе предприятия. Второй - физический -- определяет представление информации в БД. ERWIN объединяет их в единую диаграмму, имеющую несколько уровней представления.

Рис. 2.4.1 Логическое представление данных

Рассмотрим назначение таблиц базы данных данного приложения:

Таблица Contacts - таблица, предназначенная для хранения информации о клиентах. Она содержит в себе следующие данные:

· id - идентификатор записи (PK);

· firstName - имя клиента;

· lastName - фамилия клиента;

· middleName - отчество клиента;

· address - адрес клиента;

· phone - телефон клиента;

· email - электронный почтовый адрес клиента.

Таблица Policy - таблица, содержащая в себе информацию о страховых полисах. Структура:

· id - идентификатор страхового полиса (PK);

· contactID - идентификатор пользователя, для которого создан полис (FK);

· policyNumber - номер страхового полиса;

· activationDate - начало открытия страхового полиса;

· expirationDate - окончание действия страхового полиса;

· policyStatusID - идентификатор статуса данного полиса (FK);

· policySumm - страховая сумма данного полиса.

Таблица Users - таблица, которая хранит в себе информацию о пользователях данного приложения. Имеет следующую структуру:

· id - идентификатор пользователя (PK);

· login - регистрационное имя пользователя;

· password - пароль;

· firstName - имя пользователя;

· lastName - фамилия;

· roleID - идентификатор роли данного пользователя (FK).

Таблица Roles - содержит список текущих ролей пользователей системы. Имеет следующую структуру:

· id - идентификатор роли (PK).

· roleName - название данной роли.

Таблица Statuses - хранит список текущих статусов для страховых полисов. Структура:

· id - идентификатор статуса (PK);

· statusName - название статуса.

Таблица TempTables - хранит список временных таблиц, которые создаются для временного сохранения результатов поиска. Имеет следующий вид:

· id - идентификатор таблицы (PK);

· tableName - название временной таблицы;

· userName - имя сессии пользователя, для которого создавалась таблица

Таблица Statistics - хранит в себе статистические данные, которые используются для проведения анализа деятельности компании. Структура:

· id - идентификатор параметра (PK);

· name - название статистического параметра;

· value - значение статистического параметра.

Рис. 2.4.2 Физическое представление данных

2. 5 Руководство пользователя

Приложение имеет довольно удобный интерфейс и навигацию, поэтому при его использовании пользователь не будет иметь проблем. Принцип работы с различными типами документов одинаков, поэтому продемонстрируем работу приложения на примере документа “Contact”.

При запуске приложения появляется страница авторизации (Рис.2.5.1), на которой запрашивается идентификационные данные пользователя (login, password).

Рис.2.5.1 Страница авторизации пользователя

При успешной авторизации пользователь переходит на главную страницу приложения, на которой он может выбрать дальнейшее действие (Рис.2.5.2).

При выборе действия «Contacts» на экране появляется список существующих клиентов (Рис.2.5.3). Первоначальный размер станицы - 10 записей, однако по желанию можно выбрать другую размерность, так же если не все записи помещаются на страницу, появляются навигационные ссылки.

Рис.2.5.2 Главная страница приложения. Выбор действия

Любой контакт можно просмотреть (а если права пользователя позволяют, то и отредактировать или удалить), нажав на ссылку, которой является значение колонки First Name. После выбора конкретного клиента открывается форма просмотра (редактирования) данного контакта (Рис.2.5.4). На данной странице присутствуют ссылки Save&Close (сохранение с закрытием данного контакта и переходом на страницу выбора действия), Save (сохранение измененных данных), Delete (удаление данного контакта) и Cancel (отмена редактирование и закрытие данного контакта с переходом на страницу выбора действия).

Рис.2.5.3 Страница просмотра списка клиентов

Рис.2.5.4 Страница редактирования контакта

Рис.2.5.5 Страница создание нового контакта

При выборе действия “Create Contact” открывается страница с такой же формой, только с пустыми полями. После заполнения полей, пользователь имеет возможность выполнить три действия: сохранить данный контакт с закрытием формы и переходом на страницу выбора следующего действия; сохранить контакт и остаться на этой же странице (при этом появляется ссылка на новое действие «Delete») или отменить сохранение заполненных данных и перейти на страницу выбора очередного действия.

Если требуется найти набор контактов по какому-нибудь критерию (например, по адресу), можно воспользоваться страницей поиска контактов (Рис.2.5.6). Она представляет собой все ту же форму контакта, только пустую, после заполнения формы пользователю доступны следующие действия: начать поиск с переходом на страницу просмотра результата поиска или отменить поиск с переходом на страницу выбора действия.

Рис.2.5.6 Страница формирования поискового запроса

Рис.2.5.7 Страница просмотра результата поиска

При выборе действия “Search”, происходит переход на страницу просмотра результата (Рис.2.5.7), на которой доступны все те же действия, что и на странице просмотра списка клиентов.

З аключение

В результате написания курсового проекта было реализовано Интернет приложение, предназначенное для автоматизации работы страховой кампании. Приложение содержит все требования, имеет дружелюбный интерфейс, удобную навигацию. Проект реализован на языке программирования Java, поэтому приложение является кроссплатформенным, что позволяет устанавливать на серверы с любой операционной системой. В процессе разработки были учтены такие моменты как customization, refactoring, расширение функционала. Поэтому архитектура приложения имеет такую структуру и конфигурацию, что вышеперечисленные процессы будут проходить менее болезненно.

В приложении используется язык запросов SQL таким образом, чтобы он выполнялся для любой СУБД, поэтому переход на использование другой СУБД заключается только в изменении конфигурационного файла.

Конечный пользователь приложения - страховые компании и в частности страховые агенты (регистрация новых клиентов) и страховые аналитики (анализ деятельности компании на основе расчетов параметров).

Расчет актуарных параметров осуществляется сторонними компонентами (EJB), которые подключаются к приложению путем описания их в конфигурационном файле. Поэтому добавление новых расчетных компонентов может производится даже без переинсталяции приложения.

В качестве дальнейшей кастомизации возможно добавление новых расчетных компонентов, новых типов документов, новых типов страховок.

С писок использованных источников

1. Дэвид М. Гери «Java Server Pages», Москва 2002

2. Г. Шилд, П. Ноутон «Java 2».

4. С.Б. Дунаев «Доступ к базам данных из Java-программ»

5. Thinking in Java, 2nd Edition

6. С.А. Трофимов «Case-технологии. Практическая работа в Rational Rose»

7. Sun Microsystems “Enterprise JavaBeans TM Specification”

8. Life and Health Insurance / Kenneth Black, Jr., Harold D. Skipper, Jr. - 13 th ed. ISBN 0-13-891250-5.

9. Основы страховой деятельности под редакцией Т.А.Федоровой. М. Издательство БЕК, 2000г.

10. Медведев Г.А. Математические модели финансовых рисков. Часть 1. Риски из-за неопределенности процентных ставок. - Мн.: БГУ, 1999.

П риложение 1 . Л истинг программного кода

_____________________________________________________________

Конфигурационный файл параметров базы данных dbconfig.xml:

com.sybase.jdbc2.jdbc.SybDriver

jdbc:sybase:Tds:localhost:2638/insurance

dba

sql

Класс - парсер конфигурации DBConfigParser.java:

package insurance.utils;

import insurance.config.DBPropertiesContainer;

import org.apache.commons.digester.Digester;

import org.xml.sax.SAXException;

import java.io.IOException;

* Date: 21.4.2007

* Time: 23.37.37

public class DBConfigParser implements IConfigParser{

public void parse(String fileName) throws IOException, SAXException {

Digester digester = new Digester();

setRules(digester);

digester.parse(fileName);

private void setRules(Digester digester) {

digester.setValidating(false);

digester.push(DBPropertiesContainer.getInstance());

igester.addCallMethod("database/driver", "setDbDriver", 1);

digester.addCallParam("database/driver", 0);

digester.addCallMethod("database/url", "setUrl", 1);

digester.addCallParam("database/url", 0);

digester.addCallMethod("database/login", "setLogin", 1);

digester.addCallParam("database/login", 0);

digester.addCallMethod("database/password", "setPassword", 1);

digester.addCallParam("database/password", 0);

Класс, осуществляющий общие действия для работы с базой данных DataDAOHelper.java:

package insurance.dao;

import insurance.config.DAOContainer;

import insurance.dao.connector.DBConnector;

import java.sql.Connection;

import java.sql.SQLException;

* Date: 23.4.2007

* Time: 19.28.42

public class DataDAOHelper {

public void save(IEntity entity) throws SQLException, ClassNotFoundException {

dao.save(con, entity);

} catch (SQLException e) {

public void delete(String docType, int id) throws SQLException, ClassNotFoundException {

Connection con = DBConnector.getConnection();

dao.delete(con, id);

} catch (SQLException e) {

throw new SQLException(e.getSQLState());

public void undelete(String docType, int id) throws SQLException, ClassNotFoundException {

IDataDAO dao = getDAOByType(docType);

Connection con = DBConnector.getConnection();

dao.undelete(con, id);

} catch (SQLException e) {

throw new SQLException(e.getSQLState());

public void update(IEntity entity) throws SQLException, ClassNotFoundException {

IDataDAO dao = getDAOByType(entity.getEntityType());

Connection con = DBConnector.getConnection();

dao.update(con, entity);

} catch (SQLException e) {

throw new SQLException(e.getSQLState());

public void load(int id, IEntity entity) throws SQLException, ClassNotFoundException {

IDataDAO dao = getDAOByType(entity.getEntityType());

Connection con = DBConnector.getConnection();

dao.load(con, id, entity);

} catch (SQLException e) {

throw new SQLException(e.getSQLState());

public IDataDAO getDAOByType(String docType) {

DAOContainer container = DAOContainer.getInstance();

IDataDAO result = null;

Class dao = Class.forName(container.getDAOForEntity(docType));

result = (IDataDAO) dao.newInstance();

} catch (ClassNotFoundException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

} catch (InstantiationException e) {

e.printStackTrace();

public static String nullToEmpty(String value) {

return (value != null) ? value: "";

Реализация работы с базой данных для документа Contact:

package insurance.dao;

import insurance.beans.IEntity;

import insurance.beans.PersonBean;

import java.sql.Connection;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

* Date: 22.4.2007

public class PersonDataDAOImpl implements IDataDAO {

private final static String SAVE_QUERY = "INSERT INTO Person " +

"(FirstName, LastName, MiddleName, Address, Phone, Email, Version)" +

"VALUES (?, ?, ?, ?, ?, ?, ?)";

private final static String DELETE_QUERY = "UPDATE Person SET Version = -1 WHERE ID = ?";

private final static String UNDELETE_QUERY = "UPDATE Person SET Version = 1 WHERE ID = ?";

private final static String UPDATE_QUERY = "UPDATE Person SET FirstName = ?," +

"LastName = ?, MiddleName = ?, Address = ?, Phone = ?, email = ? WHERE id = ?";

private final static String LOAD_QUERY = "SELECT FirstName, LastName, MiddleName," +

"Address, Phone, Email, Version FROM Person WHERE id = ?";

public void save(Connection con, IEntity entity) throws SQLException {

PersonBean person = (PersonBean) entity;

PreparedStatement ps = null;

ps = con.prepareStatement(SAVE_QUERY);

ps.setString(1, person.getFirstName());

ps.setString(2, person.getLastName());

ps.setString(3, person.getMiddleName());

ps.setString(4, person.getAddress());

ps.setString(5, person.getPhone());

ps.setString(6, person.getEmail());

ps.setInt(7, person.getVersion());

ps.executeUpdate();

assert ps != null;

public void delete(Connection con, int id) throws SQLException {

PreparedStatement ps = null;

ps = con.prepareStatement(DELETE_QUERY);

ps.setInt(1, id);

ps.executeUpdate();

assert ps != null;

public void undelete(Connection con, int id) throws SQLException {

PreparedStatement ps = null;

ps = con.prepareStatement(UNDELETE_QUERY);

Подобные документы

Разработка функциональной модели предметной области. Построение UML диаграмм в среде Pacestar UML Diagrammer. Выбор программных средств разработки. Разработка логической и физической модели данных. Разработка клиентского приложения ИС в среде Access.

курсовая работа , добавлен 09.03.2011


Выбор, обоснование и особенности работы СУБД. Характеристика языков программирования. Разработка структурной и функциональной модели информационной системы аптеки. Проектирование программной среды АИС и ее интерфейса. Построение модели базы данных.

курсовая работа , добавлен 21.04.2012


Анализ входной информации и процессов, уровня автоматизации на предприятии. Выявление объекта и задачи автоматизации. Разработка концепции построения информационной модели информационной системы. Разработка структуры базы данных и клиентского приложения.

дипломная работа , добавлен 22.11.2015


Проектирование многопользовательской информационной системы для автоматизации работы диспетчера отдела грузоперевозок. Выбор среды программирования. Разработка программного обеспечения, таблиц базы данных АСОИ. Построение диаграмм классов и деятельности.

курсовая работа , добавлен 03.06.2014


Проектирование приложения для автоматизации процесса страхования, которое поможет страховым агентам сократить время на работу с документацией. Разработка прикладной программы доступа к базе данных в среде Delphi. Система управления базами данных.

курсовая работа , добавлен 14.01.2015


Создание информационной системы автоматизации процесса управления базами данных компании ООО "Роснефть". Требования к характеристикам технических средств. Обоснование выбора CASE-средства. Разработка программного обеспечения, расчет затрат цены и прибыли.

дипломная работа , добавлен 24.03.2012


Основы методологии проектирования информационной системы. Общая характеристика и классификация CASE-средств. Рассмотрение логической, функциональной и физической модели данных системы "Студент". Расчет трудоемкости разработки программного изделия.

дипломная работа , добавлен 16.03.2012


Анализ решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Обоснование выбора платформы. Взаимодействие приложения с источниками данных. Выбор жизненного цикла разработки программного обеспечения.

дипломная работа , добавлен 18.12.2010


Организация и продажа оргтехники. Цели автоматизированной системы и автоматизируемые функции. Характеристика функциональной структуры информационной системы. Проектирование функциональной части объекта автоматизации. Обоснование выбора подсистемы.

курсовая работа , добавлен 19.12.2010


Обзор принципов построения и эффективного применения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ возможностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.

Автоматизация страхового бизнеса в России весьма перспективна - во многих отечественных страховых компаниях лишь совсем недавно начали серьезно задумываться о необходимости развертывания комплексных корпоративных систем. Наступил момент, когда проблема выбора и внедрения эффективной системы встала во всей остроте - страховые компании развиваются, растет численность их клиентуры, обостряется внутренняя и внешняя конкуренция, появляется необходимость введения новых услуг.

Сфера страхового бизнеса в России моложе многих остальных отраслей экономики, отчасти поэтому здесь сегодня ощущается недостаток готовых решений. Однако страховые компании развиваются, растет численность их клиентуры, обостряется конкуренция, появляется необходимость введения новых услуг - все это требует совершенствования управления и обеспечения прозрачности бизнеса, что в современных условиях недостижимо без опоры на информационные технологии. В страховом обществе «РЕСО-Гарантия» уже почти шесть лет работает система автоматизации основного бизнеса, а недавно осуществлен масштабный проект по переходу на новую программно-аппаратную платформу.

Опыт информатизации страхования

Информационно-вычислительный центр компании «РЕСО-Гарантия» был образован в конце 1995 года. Его начальник, Алексей Чемисов рассказывает, что в процессе поиска решения по автоматизации в компании анализировали как состояние российского рынка, так и предложения западных разработчиков. Ситуация складывалась таким образом, что говорить о каком-либо выборе среди отечественных систем не приходилось - таковые просто отсутствовали, а западные решения требовали миллионных вложений, чего тогда в «РЕСО-Гарантии» позволить себе не могли. В итоге было принято решение разрабатывать систему собственными силами.

В «РЕСО-Гарантии» полагали, что отечественный страховой бизнес находится на этапе становления и не изобилует квалифицированными кадрами, способными выполнить полноценную постановку задачи, поэтому ставка была сделана на западных специалистов, имеющих многолетний опыт работы в страховании.

В некоторых видах бизнеса достаточно просто разграничить отдельные бизнес-процессы: бухгалтерию, логистику, склад и т.д., последовательно провести их автоматизацию и получать желаемый эффект на каждом очередном этапе развертывания информационной системы. В страховой компании ситуация иная - все бизнес-процессы сильно связаны и автоматизация отдельно взятой задачи практически ничего не даст, необходима сквозная автоматизация всех процессов в комплексе.

В страховом бизнесе основой всего является страховой продукт - услуга по различным видам страхования. Страховые продукты по одному и тому же виду страхования могут быть уникальными для разных страховых компаний, которые формируют и модифицируют свой набор условий, предлагаемых клиентам. Для того чтобы поддерживать различия и возможность постоянных изменений страховых продуктов, информационная система должна иметь гибкие средства настройки параметров договоров страхования. Все эти различия должны сразу же отражаться в подсистемах бухгалтерского и налогового учета. Система должна предоставлять разные данные для организации выплат по разным страховым продуктам и т.д. Получается, что реализация отдельных компонентов информационной системы для страховщиков мало влияет на повышение эффективности бизнеса, и даже способна создать дополнительные сложности. Необходимо сразу увязывать все элементы между собой, изначально делая ставку на комплексное решение с гибкими средствами адаптации к тем уникальным условиям страхования, которые данная страховая компания может предложить в конкретном страховом продукте.

Разработка комплексной системы, удовлетворяющей таким требованиям, в компании «РЕСО-Гарантия» началась в 1996 году с привлечением консультанта из Испании, отвечающего за постановку задачи. Сегодня Хосе Леон Лассерротт остается основным консультантом и членом совета директоров компании.

«РЕСО-Гарантия» - далеко не типичный для отечественного бизнеса случай, когда реализованная собственными силами информационная система удовлетворяла бы потребностям компании. Причина успеха, по мнению Чемисова, в грамотной постановке задачи, должном финансировании проекта и профессиональной команде разработчиков. Практически с первой версии системы, разрабатывавшейся около двух лет, удалось ввести в действие комплексное решение, поддерживающее основные бизнес-процессы компании. С течением времени добавлялись новые подсистемы, модифицировались существующие, но ставка на комплексное ядро системы, обеспечивающее взаимодействие страховых продуктов, выплат, перестрахования, бухгалтерии оправдала себя.

Сегодня информационная система страховой компании обслуживает 650 пользователей и включает следующие подсистемы:

Конструктор, обеспечивающий гибкую настройку всех функциональных модулей системы; это своего рода инструментарий для работы специалистов актуарно-методологического центра; с его помощью актуарии (специалисты по страховой математике) в кратчайшие сроки разрабатывают новые продукты и параметризируют все компоненты системы, поэтому два подразделения - актуарно-методологический центр и информационно-вычислительный центр - фактически составляют единый механизм;

Подсистема ведения полисов;

Подсистема бухгалтерского учета;

Подсистема выплат;

Подсистема перестрахования;

Подсистема бюджетирования;

Подсистема аналитической отчетности;

Подсистема администрирования;

Подсистема автоматической пролонгации полисов;

Подсистема "зарплата и кадры".

Платформа

За шесть лет страховая информационная система эволюционировала вслед за ростом компании и выходом на новые рынки. Помимо изменений, связанных с содержанием бизнеса компании, менялась и технологическая база. Первый качественный скачок был сделан при переходе с СУБД Interbase на платформу Oracle. В 1999 году стал ощущаться недостаток серверных мощностей: многократно выросли объемы данных и количество пользователей. После почти полугодовой проработки вопроса было принято решение о переходе с ПК-сервера на Unix-платформу компании Hewlett-Packard. Как объясняет Чемисов, выбор поставщика был обусловлен главным образом тем, что НР имеет в своем арсенале весь спектр необходимого оборудования, начиная с настольных систем и заканчивая дисковыми массивами и носителями для архивного хранения данных.

Следующий этап технологической эволюции был завершен совсем недавно. Зависимость бизнеса компании от нормальной работы информационной системы стала настолько велика, что ее простои уже абсолютно недопустимы. Для обеспечения бесперебойной работы был реализован проект по созданию кластера на базе серверов НР 9000. Помимо надежности, новый комплекс должен послужить платформой для перевода информационной системы на трехзвенную архитектуру. У компании 123 филиала по всей стране, и для того чтобы не распылять серверные мощности и упростить масштабирование, настройку, администрирование и освоение системы пользователями она изначально была реализована таким образом, что вся обработка данных сосредоточена в центре, а на местах функционируют только клиентские модули. Однако сегодня те же задачи масштабирования и повышения производительности требуют сделать архитектуру системы более эффективной, разделив бизнес-логику и логику данных. В отказоустойчивой конфигурации предусмотрены два узла кластера. В штатном режиме на одном из них функционирует сервер приложений BEA WebLogic, на другом сервер баз данных Oracle. В случае отказа одного из аппаратных серверов происходит перезапуск Oracle или WebLogic на другом сервере, и временно сервер баз данных и сервер приложений функционируют на одном узле кластера.

Помимо двухузлового кластера комплекс включает две территориально разнесенные дисковые подсистемы, на которые параллельно идет запись информации. Система хранения организована по принципам SAN с поддержкой резервного копирования и восстановления данных. Кроме обеспечения отказоустойчивости, аппаратная платформа предусматривает наращивание производительности основной системы без замены действующих серверов. Установленные серверы обладают большими возможностями для дальнейшего расширения путем установки дополнительных процессоров, модулей памяти и т.д. В результате потенциально с информационной системой РЕСО сможет работать несколько тысяч человек, что очень важно для обслуживания многочисленных агентов.

Проект реализован компанией TopsBI, с которой «РЕСО-Гарантия» сотрудничает около двух лет. Как объясняет Чемисов, в этом партнере привлекает, прежде всего, комплексность, а также возможность получить «из одних рук» услуги разного профиля, от поставок и технической поддержки оборудования до администрирования сервера базы данных. В РЕСО имеется собственный специалист по Oracle, а сотрудники информационно-вычислительного центра прошли обучение кластерным технологиям НР. Вместе с тем, объемы сервисного обслуживания, возложенные на TopsBI, позволяют говорить об аутсорсинге ИТ-инфраструктуры РЕСО.

Проблемы нового дня

Сегодня в страховом бизнесе страны происходят перемены, которые могут оказать существенное влияние на ситуацию с автоматизацией страховых компаний. Прежде всего, это вступление в силу закона «Об обязательном страховании автогражданской ответственности», который стимулирует резкий рост количества договоров на страхование. А это означает катастрофический рост объемов данных и появление других задач, решение которых невозможно без эффективных информационных систем. Еще один важный фактор - изменение правил бухгалтерского и налогового учета и движение в сторону международных стандартов учета и отчетности. Достижение большей финансовой прозрачности компании для акционеров и руководства требует освоения новых методологий учета и построения совершенной информационной платформы с развитой аналитической подсистемой.

В существующих автоматизированных банковских системах процессам страхования уделяется весьма поверхностное внимание. Однако круг решаемых задач отделов по работе со страховыми организациями широк и требует серьезных подходов к учету, мониторингу и отчетности. Четко отлаженные процессы страхового администрирования – это снижение рисков утраты или повреждения предмета залога.

Создание совместных продуктов очень перспективно и для страховых компаний, и для банков. Это доказывает международный опыт подобного сотрудничества.

Французский опыт показал, что при продажах страховых продуктов через банк — банки зарабатывают до 16% продаж в своих совокупных доходах.

Подобное сотрудничество становится очень перспективным и важным для банков, тогда как норма процентной маржи дохода банка падает.

Для Банка в первую очередь важен контроль своевременности заключения заемщиками договоров страхования и проведения уплаты страховых взносов по графику платежей. Превентивная работа с клиентами – заблаговременное информирование по удобным каналам связи (почта, обзвон, смс и т.д.), позволяет выстраивать отношения на качественно новом уровне и дает лучший результат из всех возможных.

На каждом из периодов просрочки планируются соответствующие мероприятия с целью мотивировать заемщиков к уплате взносов и пролонгации договоров. Учет страховых случаев в части утраты залога и контроль выплат возмещения страховыми организациями – также важнейший процесс, требующий внимания.

Цели внедрения системы

Уменьшение уровня просрочки оплаты страховых полисов от 10 до 30%, соответствующее снижение рисков, связанных с утратой залога.

Снижение операционных издержек по бизнес-процессам, связанным со страхованием, в среднем в 2 раза.

Сокращение количества ошибок в бизнес-процессах в 2-3 раза.

Получение дополнительной прибыли от агентского вознаграждения.

Повышение уровня удовлетворенности клиентов предоставляемым сервисом по страхованию.

Повышение уровня удовлетворенности контрагентов (страховых компаний, страховых брокеров, автодилеров и пр.) за счет экономии их рабочего времени и гибкой системы мотивации.

Информационная панель

Настраиваемые алгоритмы в виде дерева решений

Конструктор отчетов

Безопасность и контроль

Информационная панель руководителя

Информационная панель позволяет принимать управленческие решения на основе мониторинга ключевых показателей эффективности (KPI) и анализа трендов. Drill-down анализ дает возможность получать детальный отчет по отдельным показателям. Решение собирает статистические сведения с учетом истории и отображает их в виде индикаторов и диаграмм:

• Ключевые показатели

• Действующие договоры страхования

• Количество страховых случаев

• Пролонгации и Cоllection

• Доходы Банка от агентского вознаграждения за месяц

Ключевые преимущества системы

• Специализированное отраслевое решение для автоматизации именно банковского страхования

• Пользовательский интерфейс продуман и специально оптимизирован для быстрой и эффективной работы операторов

• Гибко настраиваемые алгоритмы расчетов позволяют быстро учесть последние изменения в бизнесе

• Информационная Панель Руководителя для мониторинга ключевых показателей и трендов помогает принимать верные управленческие решения

• История изменений данных, аудит операций, логирование и другие отличительные особенности (см. описание решения) гарантируют безопасность и управляемость

• Широкие возможности интеграции позволяют обмениваться данными с существующими учетными системами

• Гибкие возможности создания отчетов и импорта информации из обработанных отчетов автоматизируют документооборот и снижают операционные издержки

Поддерживаемые бизнес-процессы

• Оформление договоров страхования;

• Учет страховых полисов и страховых взносов по различным программам страхования;

• Контроль своевременности уплаты взносов и пролонгации договоров страхования;

• Учет страховых случаев;

• Контроль своевременности и учет выплат страховых возмещений страховыми компаниями;

• Вычисление агентского (комиссионного) вознаграждения для банка и контрагентов (мотивация страховых брокеров, автодилеров и т.д.);

• Согласование с филиалами страховых компаний процента агентского вознаграждения;

• Работы по пролонгациям договоров страхования;

• Взаимодействие с подразделением Collection с целью:

мотивировать просрочников к уплате взносов;

мотивировать просрочников к пролонгациям договоров страхования;

проанализировать результат работы Collection

Автоматизация страховых организаций для работы с банками

«Фогсофт Страхование» – принципиально новое решение для автоматизации взаимодействия между страховой организацией и банками. В последнее время ценность страхования в Банках растет, и это уже касается не только страхования залогового имущества, но и рисков самих банков. Выгодное партнерство позволяет страховым организациям использовать Банк как успешный и перспективный канал продаж.

Решение позволит банкам легко продавать и оформлять страховые продукты Вашей компании через специальный раздел Вашего веб-сайта. Банки получат максимально удобный инструмент для управления жизненным циклом договоров страхования. Это, в том числе, проведение котировок и расчетов, печать пакета документов, подготовка списков договоров для очередной оплаты по графику и пролонгации, учет страховых случаев и страхового возмещения, регистрация мероприятий по взысканию задолженности, обмен документами и расчеты агентского вознаграждения.

Для банков наличие подобного сервиса означает уменьшение рисков утраты залога и снижение операционных издержек. Таким образом Вы сможете максимально повысить привлекательность Ваших услуг для банков, расширив партнерскую сеть и снизив затраты на каналы распространения услуг.

С помощью информационной панели руководителя Вы увидите всю картину по страхованию в целом в виде ключевых показателей, графиков и диаграмм.

Аналитика рынка показывает, что в лидеры банковского страхования страховые организации попадают во многом за счет более развитых IT-систем. Внедрение аналогичной системы в крупной страховой организации на Украине позволило вывести процент продаж через эту систему до 11% от общего объема продаж компании

Возможно, многие страховые компании уже внедрили основную учетную систему, и это потребовало упорного труда и немалых затрат. Наше решение «Фогсофт Страхование» позволяет провести интеграцию с уже имеющимися системами страховых организаций и банков.

В 2010 году рынок банковского страхования вырос на 17% за счет страхования жизни и здоровья заемщиков при потребительском кредитовании. По прогнозам аналитиков, в этом году объем рынка вырастет еще значительнее — на 25%, в том числе за счет ипотечного страхования. Также в прошлом году вырос объем рынка страхования жизни заемщиков на 128%, остальные виды розничного банковского страхования выросли незначительно, либо сократились. Бывший драйвер роста, автострахование, все больше уходит в дилерский канал.

Выгоды от внедрения

Аналитика рынка показывает, что лидеры банковского страхования — страховые организации попадают во многом за счет более развитых IT-систем. Решение «Фогсофт Страхование» позволяет провести интеграцию с уже имеющимися системами страховых организаций и банков.