Диплом: Разработка автоматизированной системы по учету и выдачи страховых полисов компании "Арсеналь"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
72
центральный процессор,
cистемный BIOS,
дополнительный BIOS,
вектора прерываний INT 13 и INT 40,
CMOS, в том числе гибких дисков, жестких дисков и CD-ROM.
Целостность технического состава ЛВС должна обеспечиваться процедурой
усиленной аутентификации сети. Процедура должна выполняться на этапе
подключения проверенной ПЭВМ к сети и далее через заранее определенные
администратором безопасности интервалы времени.
Усиленная аутентификация должна выполняться с применением
рекомендованного варианта аппаратного датчика случайных чисел. Качество
работы датчика должно контролироваться системой рекомендованных тестов.
Контроль целостности системных областей и файлов ОС должен выполняться
контроллером до загрузки ОС, чем обеспечивается механизм чтения реальных
данных. Так как в электронном документообороте могут использоваться различные
ОС, то встроенное в контроллер ПО должно обеспечивать разбор наиболее
популярных файловых систем, а именно:
FAT 12, FAT 16, FAT32 (Dos, Win 3x, Win 95/98),
NTFS (Win NT),
HPFS (OS/2),
FreeBSd (Unix).
Целостность данного ПО должна гарантироваться технологией изготовления
контроллеров СЗИ.
Защита ПО от несанкционированных модификаций должна обеспечиваться
аппаратными средствами контроллера.
Для контроля целостности должна применяться известная (опубликованная)
хэш-функция, эталонное значение которой должно храниться в энергонезависимой
памяти контроллера, защищенной аппаратно от доступа из ПЭВМ.
73
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Построим модель информационных процессов заключения договора на
страхование граждан «как надо».
Контекстная диаграмма модели «как надо» не отличается от контекстной
диаграммы модели «как есть», поэтому проведем декомпозицию контекстной
диаграммы (рис 2.3) и рассмотрим отличия данной диаграммы, от диаграммы «Как
есть».
Из представленной диаграммы видно, что теперь программное обеспечение
по учету полисов страхования участвует в блоке «Оформления документов», с
целью снижения количества ошибок. Так же видно, что в блоке «Подготовка
реестров для сдачи в ТФОМС» так же участвует дополнительное программное
обеспечение, разработанное с целью автоматизации ручных операций.
Рисунок 2.3 – Декомпозиция контекстной диаграммы модели «как надо»
заключения договора на страхование.
Проведем декомпозицию блока «Оформление документов» (рис. 2.4) и
рассмотрим отличия данной диаграммы от диаграммы «Как есть».
74
Из представленной диаграммы видно, что предоставление программное
обеспечение по учету полисов страхования участвует в реализации процесса
предоставления страхователем списка работающих у него граждан.
Рисунок 2.4 – Декомпозиция блока «Оформление документов» модели «как надо».
Данный список, по желанию страхователя, может быть заполнен в
электронном виде, по стандартному шаблону. Заполнение данного шаблона может
вестись из уже имеющихся данных о работнике находящихся в бухгалтерских
программах (например, 1С Зарплата и Кадры). Заполненный шаблон может быть
загружен в базу данных, с автоматическим контролем введенной информации.
Данный механизм позволяет значительно сократить время выдачи полисов
страхования, снизить время заполнения списка работающих страхователем, а так же
провести автоматический контроль представленной информации, что приводит к
снижению ошибок.
Так же введено автоматизированное присвоение номера договора в
зависимости от филиала заключения. Это позволяет легко определять, в каком
филиале заключен договор, а так же избавиться от ошибок при ручном
формировании номера, так как номер договора состоит из 15 знаков.
75
Из данной диаграммы видно, что экземпляры оформленных документов
направляются в ТФОМС для дополнительного контроля, в том числе и на
регистрацию в налоговой инспекции по месту заключения договора.
Проведем декомпозицию блока «Регистрация страхователя» (рис. 2.5) и
рассмотрим отличия от диаграммы «Как есть».
Рисунок 2.5 – Декомпозиция блока «Регистрация страхователя» модели «как надо».
Информационная модель системы представлена на рис. 2.6
Введение информационной системы управления выдачей страховых полисов
позволяет сократить до минимума количество ручных операций, и тем самым
снизить количество возникающих ошибок, а так же время проведения
синхронизации баз данных.
Персона
Сотрудник
Проживает
Адрес
Содержит
Населенный
пункт
Паспорт
Данные
Место
работы
Стаж
Номер паспорта
Серия
Дата выдачи
Кем выдан
Фамилия
Имя
Отчество
Дата рождения
Индекс
Индекс
Улица
Дом
Квартира
Корпус
Город
Дата прихода
Дата ухода
Нпп
Ответственный
сотрудник
Клиент
Код персоны
Контакт
№ расчетного счета
Контактный телефон
Работа
Персонал
Фамилия директора
Фамилия бухгалтера
Количество сотрудников
Показатели
Год
Месяц
Количество
договоров
Финансы
Общий доход
Общая сумма выплат
по договорам
Средняя зарплата
сотрудников
Чистая прибыль
№ расчетного листа
Расположение
Условия
Премия
сотруднику
Договор
Страхование
Город
Тип страхованияНомер договора
Срок
страхования
Дата начала
Дата окончания
Информа
ция
СМИ
Тип СМИ
Название СМИ
Размеще
ние
Нпп
Периодичность
Сроки
рекламы
Реклама
Период
Код рекламы
Специфика рекламы
Дата первого выхода
Дата последнего выхода
Финансы
Стоимость
рекламы
Стоимость
Бюджет рекламной компании
Доля от прибыли
Срок
договора
Дата начала
Дата окончания
Карьера
Должность
Нпп
Название должности
Оклад
Филиал
Код филиала
Лицензия
Дата создания
Дата закрытия
№ расчетного счета
Рекламное
агентство
№ расчетного счета
Контакт
Нпп
Телефон
Номер
Тип
Сумма
Номер выплаты
Дата выхода решения о выплате
Дата выплаты
Размер выплаты
Способ выдачи
Пеня за задержку
Выплаты
Номер договора
Код ответственного сотрудника
Наличие претензий клиента
Сроки
Информация
Число дней задержки
Дата выхода решения о выплате
Дата выплаты
Контактный телефон
Размер страхового
платежа
Вид платежа
Рисунок 2.6 – Информационная модель системы
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
К нормативно-справочной информации, использующейся при работе
информационной системы, относятся:
законодательство РФ;
справочник пользователей;
должностные инструкции;
справочник сотрудников;
справочник договоров;
структура тарифных ставок.
Оценка страховых рисков и расчет страховых тарифов представляют для
отечественных страховщиков достаточно сложную задачу. В особенности трудно ее
решать начинающим страховую деятельность страховым организациям. Учитывая
названные обстоятельства, федеральная служба России по надзору за страховой
деятельностью с лета 1993 года рекомендовала страховщикам использовать в
практической работе Методики расчета тарифных ставок по рисковым видам
страхования.
В методике для характеристики структуры тарифной ставки использованы
следующие основные понятия.
Страховой тариф (брутто-тариф)ставка страхового взноса с единицы
страховой суммы или объекта страхования. Страховой тариф состоит из нетто-
ставки и нагрузки, что можно представить следующей формулой [1]:
Тб = Тн + Тзрп,
где Тб – страховой тариф (брутто-тариф); Тн – тарифная нетто-ставка; Тзрп –
нагрузка.
Нетто-ставка страхового тарифачасть страхового тарифа,
предназначенная для обеспечения текущих страховых выплат по договорам
страхования, которая в общем виде может быть выражена формулой:
Тн = Р(А)*К*100,
где А – страховой случай; Р(А) – вероятность страхового случая; К –
коэффициент отношения средней выплаты к средней страховой сумме на один
договор.
78
Нагрузка (Тзрп)часть страхового тарифа, предназначенная для покрытия
затрат на проведение страхования и создания резерва (фонда) предупредительных
мероприятий. В составе нагрузки может быть предусмотрена прибыль от
проведения страховых операций.
Основная задача, которая ставится при построении страховых тарифов по
имущественным рискам, связана с определением вероятной суммы ущерба,
приходящейся на каждого страхователя или на единицу страховой суммы.
При построении нетто-ставки принято исходить из равенства:
П=В,
где П – страховые платежи, соответствующие нетто-ставкам; В – страховое
возмещение.
При указанном равенстве, рассчитав его правую часть, получают искомую
величину страховых платежей.
К входной информации, использующейся для работы системы, относится:
Паспортные данные страховщика – содержит информацию о страховщике;
Пожелания страховщика – определяют вид страхования, размер страховой
сумы, срок страхования и т.п.;
Бланк договора.
2.2.3. Характеристика результатной информации
В результате работы системы формируется следующая результатная
информация:
отчет по выполненным заявкам;
отчет по невыполненным заявкам;
аналитический отчет;
отчет о заявках на выполнении;
отчет о заключенных договорах;
отчет о выданных страховых полисах.
На всех документах обязательно должна быть подпись руководителя
организации или его заместителя. Все документы составляются в 2-х экземплярах –
менеджеру по страхованию и клиенту
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
79
Дерево функций системы представляет декомпозицию функций системы и
формируется с целью детального исследования функциональных возможностей
системы и анализа совокупности функций, реализуемых на различных уровнях
иерархии системы. На базе дерева функций системы осуществляется формирование
структуры системы на основе функциональных модулей. В дальнейшем структура
на основе таких модулей покрывается конструктивными модулями (для технических
систем) или организационными модулями (для организационно-технических
систем). Таким образом, этап формирования дерева функций является одним из
наиболее ответственных не только при анализе, но и при синтезе структуры
системы.
Исходными данными для формирования дерева функций являются основные
и дополнительные функции системы.
Формирование дерева функций представляет процесс декомпозиции целевой
функции и множества основных и дополнительных функций на элементарные
функции, реализуемые на последующих уровнях декомпозиции.
При этом каждая из функций конкретно взятого i-ого уровня может
рассматриваться как макрофункция по отношению к реализующим ее функциям на
(i+1)-го уровня, и как элементарная функция по отношению к соответствующей
функции верхнего (i-1)-го уровня.
Все функции, реализуемые системой, могут быть условно разделены на три
группы:
˗ целевая функция;
˗ базисные функции системы;
˗ дополнительные функции системы.
Целевая функция системы соответствует ее основному функциональному
назначению, т.е. целевая (главная) функция – отражает назначение, сущность и
смысл существования системы.
Целевой функцией является работа информационной системы.
Основные функции отражают ориентацию системы и представляют собой
совокупность макрофункций, реализуемых системой. Эти функции обусловливают
существование системы определенного класса. Основные функции – обеспечивают
80
условия выполнения целевой функции (прием, передача приобретение, хранение,
выдача).
На рисунке 2.7 представлено дерево функций программных модулей,
используемых в ИС управления выдачей страховых полисов.
Рисунок 2.7 – Функциональная схема программы
Используемые в системе модули подразделяется на три типа:
˗ модули ввода первичной информации;
˗ модули обработки данных;
˗ модули хранения данных.
Анализируя функциональную схему программы, разработаем структуру
диалога, определим состав элементов диалога, содержание каждого элемента
и их соподчиненность. На рисунке 2.8 изображена структура диалога системы
в виде граф-схемы.
Дерево функций программных модулей
Печать
Ввод первичной
информации
Обработка
данных
Данные о
сотрудниках
Данные о
клиентах
Вход в систему
Главная форма
Справочники
Хранение
данных
БД
Просмотр и
редактирование
данных
Просмотр и
редактирование
данных
Выполнение заявок
Полисы
Заявки
81
Рисунок 2.8 – Структура диалога информационной системы
Вершины схемы пронумерованы, описание выполнено в соответствии с
нумерацией вершин, в качестве средств описания использованы таблицы.
2.3.2. Характеристика базы данных
Для описания структуры базы данных воспользуемся нотацией стандарта
IDEF1X.
IDEF1X является методом для разработки реляционных баз данных и
использует условный синтаксис, специально разработанный для удобного
построения схемы базы данных.
Идеология стандарта IDEF1X построена на понятиях «Сущность-связь».
Сущность в IDEF1X описывает собой совокупность или набор экземпляров
похожих по свойствам, но однозначно отличаемых друг от друга по одному или
нескольким признакам. Каждый экземпляр является реализацией сущности. Таким
образом, сущность в IDEF1X описывает конкретный набор экземпляров реального
мира. Каждый экземпляр сущности содержит какую-либо информацию о своих
свойствах. В IDEF1X модели эти свойства называются атрибутами сущности.
Каждый атрибут содержит только часть информации о сущности.
Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между
сущностями. Связи показывают, как соотносятся сущности между собой.
Добавление
Удаление
Просмотр
Сохранение
Действия
3.1. Клиенты
3.2. Сотрудники
3.3. Договора
3.4. Типы страхования
Вход в систему
1. Вход в систему
2. Файл
3. Справочники
4. Выполнение
заявок
Главная форма
Справочники
4.1. Заявки
4.2. Полисы
4.3. Выполнение заявок
Выполнение заявок
Расчет
Построение таблицы
Вывод на печать
Действия
Закрыть
Действия
2.1. Закрыть
Файл
Вывод на печать
Действия

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран