Разработка информационной системы учёта страховых премий для строящегося жилья в страховой компании
Анализ и выбор программных средств разработки информационной системы учёта страховых премий для строящегося жилья в страховой компании. Внедрение и эксплуатация информационной системы. Проектирование и экономическая эффективность информационной системы.
| Рубрика | Банковское, биржевое дело и страхование |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 13.07.2011 |
| Размер файла | 3,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Система должна создаваться на основе действующих стандартов и норм. Унификация проектных решений должна обеспечиваться единообразным подходом к решению однотипных задач с созданием унифицированных объектно-ориентированных компонентов информационного, лингвистического, программного, технического и организационного обеспечения.
Единообразный подход к решению однотипных задач должен достигаться:
- унификацией функциональной структуры системы и входящих в неё подсистем в части её элементов (автоматизированных функций) и в части связей между её элементами (информационной связи между функциями);
- единым программно-техническим способом реализации одинаковых функций системы и единым операторским интерфейсом в системе (способами и правилами взаимодействия "человек-машина");
- унификацией компонентов математического обеспечения, использованием модульного принципа построения алгоритмов сбора, обработки, архивации и представления информации, типизацией алгоритмических модулей.
Унификация компонентов информационного обеспечения должна быть направлена:
- в части немашинной базы данных - на использование единой системы классификаторов документов и показателей, единых методов и средств подготовки, сбора, контроля, хранения и корректировки всех документированных сведений и сообщений, используемых в системе, а также на рациональное ограничение используемых форм документов;
- в части программно-реализованной БД - на использование унифицированных способов структуризации данных и построения баз данных, управления базами данных, доступа к базам данных и методов связывания программ и данных.
Унификация лингвистического и программного обеспечения должна быть направлена:
- в части лингвистического обеспечения - на использование рационального взаимодействия соответствующих категорий персонала с вычислительной техникой и способов организации этого диалога;
- в части системного программного обеспечения - на максимальное использование стандартных программных средств - пакетов системных и прикладных программ и программных модулей, СУБД, Web-серверов, OPC-серверов, SCADA-систем, а при необходимости - и на разработку новых проблемно-ориентированных пакетов;
- в части прикладного программного обеспечения - на использование методов объектно-ориентированного программирования, модульного принципа построения программных компонентов и на единообразные связи между программными модулями на основе единых программных интерфейсов.
Унификация компонентов технического обеспечения системы должна быть направлена на применение однотипных и стандартных средств вычислительной техники и организации сетевого взаимодействия, обладающих свойствами электрической, конструктивной, логической и информационной совместимости, имеющих единую систему интерфейсов и использующих единую систему протоколов.
§ 2.2. Проектирование информационной системы
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - организации, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.
В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений:
- представление предметной области в том виде, как она реально существует;
- как ее воспринимает человек (имеется в виду проектировщик базы данных);
- как она может быть описана с помощью символов.
Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- обследование предметной области, изучение ее информационной структуры;
- выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;
- моделирование и интеграция всех представлений.
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д. [12].
Различие уровней представления данных на каждом этапе проектирования представлено в табл.2.1
Таблица 2.1 Уровни проектирования
|
КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ · сущности · атрибуты · связи |
Представление аналитика |
|
|
ЛОГИЧЕСКИЙ УРОВЕНЬ · записи · элементы данных · связи между записями |
Представление программиста |
|
|
ФИЗИЧЕСКИЙ УРОВЕНЬ · группирование данных · индексы · методы доступа |
Представление администратора |
На основе разработанных требований к системе учёта страховых премия для строящихся квартир в строительной компании необходимо спроектировать ее. При этом необходимо определить:
1. Технологию системе учёта страховых премия для строящихся квартир.
2. Календарный план-график.
3. Определить бизнес-логику приложения и построить модели процессов.
4. Разработать структуру базы данных.
5. Разработать пользовательские интерфейсы.
Разработать структуру отчетов.
Технология разработки и внедрения ИС учёта страховых премий для строящихся квартир в страховой компании
Предполагается выполнить цикл работ по внедрению и поддержке ИС:
- анализ существующей модели бизнес-процессов организации, исследование возможностей автоматизации учёта страховых премий для строящихся квартир;
- разработка системы учёта страховых премий для строящихся квартир ее автоматизации;
- внедрение автоматизированных процессов расчётов страховых премия для строящихся квартир;
- обучение и консультирование персонала по эксплуатации и поддержке развернутых процессов.
Для преодоления перечисленных проблем была предложена спиральная модель жизненного цикла, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Описание архитектуры информационной системы
Информационная система автоматизации учёта страховых премий для строящихся квартир в страховой компании имеет двухуровневую клиент-серверную архитектуру, которая реализует многопользовательский режим работы и является распределенной. В этой модели архитектуры бизнес-логика разделена между клиентом и сервером. Сервер баз данных обеспечивает хранение и обработку данных, а клиентское приложение формирует запросы к базе данных и инициирует выполнение различных действий над данными. На сервере бизнес-логика реализована в виде хранимых процедур и триггеров -- специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены.
Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте.
Схематически архитектура системы представлена на рис.2.1
Рис.2.1 «Архитектура системы»
Описание информационной системы на концептуальном уровне
Первый уровень, концептуальный, заключается в определении общей структуры создаваемой системы. На данном этапе были спроектированы:
- cтандарт DFD;
- диаграмма прецедентов;
- стандарт IDEF3.
Стандарт DFD
На рис.2.2 представлен корневой уровень модели «Работы с системой для строящегося жилья», реализованной по стандарту DFD.
жилье страховой информационный компания учёт
Рис.2.2 Модель DFD
На схеме представлены пользователи и внешние объекты, влияющие на работу системы:
- сотрудники отдела по работе с клиентами;
- законодательство;
- руководящий состав.
Сотрудники отдела по работе с клиентами - юридическое лицо, специально созданное для осуществления страховой деятельности и получившее в установленном порядке государственную лицензию на осуществление страховой деятельности на территории РФ.
Руководящий состав - это совет директоров компании, которые по результатам, отраженным в отчетах, делают выводы и принимают управленческие решения.
Клиенты- покупают продаваемую продукцию, т.е страховые договоры.
На рис.2.2 представлена «Диаграмма информационных потоков системы учёта страховых премия для строящегося жилья», представлен корневой уровень модели «Учёта страховых премия для строящегося жилья», реализованной по стандарту DFD. Подробная схема по стандарту DFD представлена в Приложении 4.
Диаграмма прецедентов
Диаграмма прецедентов реализуется с помощью средства проектирования Rational Rouse и иллюстрирует работу участников системы с функциями системы.
Из рис.2.3 Диаграмма прецедентов видно, что основными пользователем системы являются сотрудники отдела по работе с клиентами и руководитель отдела по работе с клиентами.
Сотрудники отдела по работе с клиентами производят:
- ввод исходной информации;
- нормализуют исходную информацию;
- формирование отчётных данных.
В свою очередь и руководитель отдела по работе с клиентами:
- составляет отчеты;
- предоставляет их руководству.
На основе полученных данных руководитель может выбрать оптимальное решение в области управления компании.
Рис.2.3 Диаграмма прецедентов
Описание информационной системы на логическом уровне
(UML - модели)
Второй уровень проектирования логический, заключается в определении содержания системы и используемых в системе стандартов. На этом уровне определяется состав и характер базовых пространственных данных и базовых пространственных объектов. Этот уровень тесно связан с концептуальным уровнем, так как определяет, с чем будет работать система и на основе каких стандартов будет осуществлена универсальность и централизованность.[24] На этапе разработки логического уровня была спроектирована диаграммы классов (представлена в приложении) и модулей системы.
Диаграмма модулей системы иллюстрирует ее ключевые функции (рис.2.4 Диаграмма модулей системы):
- авторизация пользователя;
- настройки расчетов страховых премий;
- представление отчетных данных;
- заполнение справочников;
- формирование отчетов.
Рис.2.4 Диаграмма модулей системы
Описание информационной системы на физическом уровне (ER - модель)
Третий уровень проектирования технологический, заключается в определении технологий, используемых для внедрения системы, и окончательный вид системы. [19] На данном этапе формируется логическая и физическая модель ER модель базы данных. С их помощью проектируется структура и сущность организации метаданных, на основе которых будет построена база данных. Логическая ER модель базы данных представлена в приложении 5. Физическая модель учёта страховых премий для строящегося жилья представлена в приложении 6.
§ 2.3. Реализация компонентов информационной системы (реализация приложений)
Проектирование базы данных
В этом разделе рассматривается структура разработки БД. Важно рассмотреть основные проектные решения (выбор модели).
С помощью диаграммы можно разработать базу данных и установить нужные взаимосвязи между таблицами. Подобная практика позволяет выделить потоки данных и пункты обмена информацией, что совершенно необходимо для разработки системы. Отношения между таблицами представлены в виде схемы, которая включает несколько объектов. К этим объектам относятся таблицы, атрибуты и отношения. На рис.2.5 показана схема данных, отображающая требуемую структуру хранения информации. Каждый прямоугольник содержит столбцы, которые созданы для соответствующей таблицы.
Рис.2.5 Схема данных
Описание таблиц
Таблица Company - содержит информацию о строительной компании. Далее приведены поля этой таблицы.
- С_ID - номер строительной компании(ключ);
- K_ID - код таблицы категорий, по данному полю происходит связывание с таблицей Кategor;
- C_Name - название строительной компании;
- С_Phone - телефон строительной компании;
- С_Address - адрес строительной компании;
- С_Kat - Категория строительной компании.
Поле С_Kat - это поле выбора, содержащее все категории строительных компаний, из которого пользователь выбирает одно из наименований. Для формирования списка выбора используется поле K_Name таблицы Kategor, содержащей записи данных о категориях. Связь между двумя таблицами Company и Kategor осуществляется через их поля кода категории K_ID и K_ID соответственно. Использование поля выбора заключается в том, что пользователь выбирает значение в поле С_Kat, содержащем список, который построен на основании значений поля K_Name. После выбора значений поля С_Kat из поля связи K_ID таблицы Kategor автоматически заносится соответствующее значение в поле K_ID таблицы Company.
Таблица Kategor - содержит инормацию о категориях строительных компаний
- K_ID - номер категории(ключ);
- K_ Name - название категории;
- K_ pk - поправочный коэффициент.
Таблица Object - содержит информацию о строящихся объектах
- O_ID - номер объекта(ключ);
- С_ID - код строительной компании;
- D_ID - код района в котором находиться данный объект;
- M_ID - код материала из которого сделан объект;
- O_ Address - адрес объекта ;
- O_ Date - срок сдачи объекта;
- O_ Distr - район объекта(поле выбора, содержащее все районы. Связь между двумя таблицами Object и District осуществляется через их поля D_ID и D_ID соответственно. Для формирования списка выбора используется поле D_Name таблицы District);
- О_ Mat - строительный материала из которого сделан объект(поле выбора, содержащее строительные материалы. Связь между двумя таблицами Object и Material осуществляется через их поля M_ID и M_ID соответственно. Для формирования списка выбора используется поле M_Name таблицы Material);
- O_ Floor - этажность объекта;
- С_ Name - строительная компания, строящая данный объект.
Между таблицами Company и Object устанавливается связь «главный-подчиненный», при которой таблица Company является главной, а таблица Object - подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле С_ID уникального кода компании, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле С_ID, по которому построен индекс.
Таблица District - содержит все районы
- D_ID - номер района(ключ);
- D_ Name - специальные сокращения районов;
- District - полное название района.
Таблица Material - содержит все существующие стандартные материалы для строительства объектов
- M_ID - номер материала(ключ);
- M_Name - специальное сокращение материала;
- Material - полное название материала.
Таблица Float - содержит полную информацию о квартирах;
- F_ID - номер квартиры(ключ);
- O_ID - код строящегося объекта, в котором находится данная квартира;
- T_ID - код типа квартиры;
- P_ID - код планировки квартиры;
- F_ Col - количество комнат;
- F_ Pod - номер подъезда;
- O_ Floor - этажность объекта(заносится автоматически);
- F_ Floor - этаж на котором находится квартира;
- F_ Type - тип квартиры (поле выбора, содержащее тип квартиры. Связь между двумя таблицами Float и Type осуществляется через их поля T_ID и T_ID соответственно. Для формирования списка выбора используется поле T_Name таблицы Type);
- F_Plan - планировка квартиры (поле выбора, содержащее планировку квартиры. Связь между двумя таблицами Float и Plan осуществляется через их поля P_ID и P_ID соответственно. Для формирования списка выбора используется поле P_Name таблицы Plan);
- O_ Address - адрес строящегося объекта, в котором находится данная квартира(заполняется автоматически);
- F_ S_ obsh - общая площадь квартиры;
- F_ Cost_ Sr - средняя стоимость квартиры в рублях за м2;
- F_ Cost_ Toch - точная стоимость квартиры в рублях за м2;
- F_ StrahPrem - страховая премия в рублях(заполняется после подсчета);
- С_ Name - строительная компания, которая строит данный объект(заносится автоматически).
Между таблицами Float и Object устанавливается связь «главный-подчиненный», при которой таблица Object является главной, а таблица Float подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле О_ID уникального кода компании, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле О_ID, по которому построен индекс.
Таблица Type - содержит все существующие стандартные типы квартир.
- T_ID - номер типа(ключ);
- T_ Name - специальные сокращения типов квартир;
- Type - полное название типа квартиры.
Таблица Plan - содержит все существующие стандартные планы квартир.
- P_ID - номер плана(ключ);
- P_Name - специальные сокращения планов квартир;
- Plan - полное название плана
Разработка модуля данных
Модуль данных - это специализированная форма, которая предназначена для размещения используемых в проекте невизуальных компонентов доступа к данным. Используется во время разработки приложения. В общем случае на модуле данных можно разместить любой невизуальный компонент из палитры компонентов. Рекомендуется все типы Ttable, Tquery , TdateBase, используемые в проекте, хранить именно в модуле данных. Доступ к этим компонентам осуществляется путем включения имени файла модуля данных в секции Uses модуля. Одним из главных удобств является приписывание каждому набору данных правил по управлению данными. Такие правила называются бизнес-правилами. Они обычно определяют реакцию системы при добавлении, изменении, удалении данных, при вводе ошибочных значений и реализует блокировку действий, которые могут разрушить ссылочную смысловую целостность БД. Такие бизнес-правила, хранящиеся централизованно на уровне приложения, при использовании одного и того же набора данных в разных формах приложения, позволяют унифицировать поведение набора данных на уровне всего приложения.
Пример модуля данных изображен на рис.2.6
Рис.2.6 пример модуля данных
Разработка SQL-запросов.
Так как одной из целей дипломного проекта является поиск по различным критериям т.е. должен осуществляться отбор записи по сложным критериям, а это можно осуществить с помощью SQL-запросов, значит для решения данной задачи можно в качестве набора данных использовать компонент Query механизма BDE, позволяющие выполнить SQL-запросы.
Критерий отбора представляет собой логическое выражение, в котором можно использовать операции, перечисленные ниже
1. Сравнения.
- =(равно);
- > (больше) или < (меньше);
- >= (больше или равно) или <= (меньше или равно);
- <> или !<> (не равно);
- !> (не больше) или !<(не меньше).
2. BETWEEN (проверка на вхождения в диапазон).
3. LIKE (Сравнение по шаблону).
4. IS NULL (Проверка на нулевое значение).
5. IN (проверка на вхождение).
При создании сложных критериев отбора можно использовать несколько операций, задавая тем самым сложные критерии отбора записей.
Сложный критерий (логическое выражение) состоит из
1. Простых условий.
2. Логических операций:
- AND(логическое и);
- OR(логическое или);
- NOT(логическое не);
3. Круглых скобок.
По каким критериям будет осуществляться поиск зависит от пользователя, значит SQL-запрос должен быть динамическим, т.е. формироваться и изменяться при выполнении приложения.
Сортировка представляет собой упорядочивание записей по возрастанию или убыванию значений полей. Список полей, по которым выполняется сортировка, указывается в операнде ORDER BY. По умолчанию сортировка происходит в порядке возрастания значений полей. Для указания обратного порядка сортировки по какому-либо полю нужно указать после имени этого поля описатель DESC. [8].
В отличие от набора данных Table, средствами языка SQL можно выполнять сортировку для набора данных Query и по неиндексированным полям. Однако по индексированным полям таблицы сортировка выполняется быстрее.
Рассмотрим пример SQL-запроса, который выполняет сортировку для таблицы Company:
procedure TForm1.SortCompClick(Sender: TObject);
var s:string;
begin
DataModule2.QComp.Close;
DataModule2.QComp.SQL.Clear;
case RadioGroup2.ItemIndex of
0: s:='';
1: s:='DESC';
end;
case ComboBox2.ItemIndex of
0: s:=' C_ID ' +s;
1: s:=' C_Name ' +s;
2: s:=' C_Address ' +s;
3: s:=' C_Phone ' +s;
end;
DataModule2.QComp.SQL.Text:='SELECT * FROM Company '+
'ORDER BY ' +s;
DataModule2.QComp.Open;
end;
Данный SQL-запрос динамический, т.к. формируется и изменяется при выполнении приложения.
Удаление записей. Для удаление группы записей используется инструкция DELETE имеющая формат
DELETE FROM <Имя таблицы>
[WHERE <Условия отбора>];
В результате выполнения этой инструкции из таблицы, имя которой указано после слова FROM, удаляются все записи, которые удовлетворяют критерию отбора. Если критерий не задан, то из таблицы будут удалены все записи. Какая именно квартира будет удалена зависит от пользователя, значит SQL-запрос должен быть динамический, т.е. формироваться и изменяться при выполнении приложения.
Рассмотрим SQL-запрос на удаление текущей квартиры:
procedure TForm1.DelFloatClick(Sender: TObject);
var kv :integer;
begin
kv:=DataModule2.QFloat.FieldByName('F_ID').AsInteger;
begin
DataModule2.QFloat.RequestLive:=True;
DataModule2.QFloat.Close;
DataModule2.QFloat.SQL.Clear;
DataModule2.QFloat.SQL.Text:= 'DELETE FROM Float1 '+
'WHERE F_ID = '+ IntToStr(kv);
DataModule2.QFloat.ExecSQL;
Расчет страховой премии
Для вычисления страховой премии необходимо знать категорию застройщика (1категории, 2категория, 3категория, 4категория), этап строительства (4 этапа: от цокольного до 1/3 этажности дома, от 1/3 до 2/3 этажности дома, от 2/3 этажности дома до последнего, отделочные работы), срок страхования(на 1 год, от 1 до 1.5, от 1.5 до 2, от 2 до 3 лет) и тарифы на финансовые риски, которые зависят от срока страхования («Порча», «Остановка», «Банкротство», «Мошенничество», «Недооформление», «Форс-мажор»), пользователь может выбрать несколько финансовых рисков, все или один.
Страховая премия вычисляется по формуле:
Ст.Пр. = Ц_кв(р/м2) * Sобщ * (1.ТарифРиска%+..+ N.ТарифРиска%) * (Категория.ПК + Этап.ПК + Срок.ПК ),
где ПК - поправочный коэффициент
Ц_кв(р/м2) - Точная стоимость квартиры (р/м2);
Sобщ - Общая площадь квартиры (м2).
Для решения этой задачи было выполнено следующее:
Созданы таблицы поправочных коэффициентов и тарифов, рис.2.7
Рис.2.7 Схема таблиц
Таблица Srok - содержит поправочные коэффициенты. На каждый срок страхования свой поправочный коэффициент
- S_ID - номер срока страхования(ключ);
- S_Name - название срока;
- S_pk - поправочный коэффициент срока страхования.
Таблица Risk - содержит тарифы на финансовые риски в %.
- R_ID - номер тарифа(ключ);
- S_ID - номер срока;
- S_Name - наименование срока;
- R_Porcha - тариф на финансовый риск «Порча»;
- R_Ostan - тариф на финансовый риск «Остановка»;
- R_Bankr - тариф на финансовый риск «Банкротство»;
- R_Moshen - тариф на финансовый риск «Мошенничество»;
- R_Nedoofr - тариф на финансовый риск «Недооформление»;
- R_PolnPac - полный пакет.
Между таблицами Risk и Srok устанавливается связь «главный-подчиненный», при которой таблица Srok является главной, а таблица Risk - подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле S_ID уникального кода срока страхования, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле S_ID, по которому построен индекс.
Таблица Etap - содержит поправочные коэффициенты каждого этапа стройки:
- E_ID - номер этапа(ключ);
- E_ Name - название этапа;
- E_ pk- поправочный коэффициент.
Таблица Kategor - содержит поправочные коэффициенты категорий компаний
- K_ID - номер категории(ключ);
- K_ Name - название катигории;
- K_ pk - поправочный коэффициент.
Т.к поправочные коэффициенты со временем меняются, необходима возможность редактирование и добавление записей. На рис.2.8 показано как выглядит форма с БД
Рис.2.8 Форма поправочных коэффициентов и тарифов
Создаем форму, где менеджер должен самостоятельно выбрать этап строительства страхового объекта, категорию компании, срок страхования и выбрать из списка финансовые риски. При подсчете страховой премии используются данные из таблицы Квартиры(Float) , это точная стоимость квартиры и общая площадь квартиры. Все значения подставляются в формулу, вычисляется страховая премия. Смотрите на рис.2.9.
Рис.2.9 подсчет страховой премии
Описание интерфейса
Рабочая программа состоит из четырех разделов. В первом разделе, который называется «Компании» содержится вся информация о строительной компании. Во втором разделе под названием «Объекты» содержится вся информация о строящихся объектах , в третьем раздала «Квартиры» - все о квартирах и четвертом разделе «Расчет тарифа» содержатся все необходимые данные для подсчета стоимости страхования.
Выбор требуемого раздела производится путем выбора соответствующей закладки на главной форме рис.2.10
Рис.2.10 главная формы
Раздел «Компании»
Работа проводится с помощью формы, которая выбирается по нажатию соответствующей кнопки. При нажатии на кнопку «Добавить» открывается форма «Добавить компанию» рис.2.11
Рис.2.11 форма «Добавить компанию»
Необходимо внести данные о компании. Из списка «Категории» выбрать нужную категорию и нажать на кнопку «Добавить». После чего программа выведет следующее сообщение рис.2.12
Рис.2.12 сообщение о результате добавления
Для редактирования данных компании необходимо нажать на кнопку «Изменить», тогда вызовется форма под названием «Изменить ДАННЫЕ О КОМПАНИИ» рис2.13, которую можно также использовать как удобный просмотр данных компании, т.к. вся информация представлена в удобном для чтения виде и при нажатие на главную форму не закрывается, остается на главной формы в неактивном режиме. Форма будет показывать данные текущей компании.
Рис.2.13 форма «Изменить ДАННАЕ О КОМПАНИИ»
При удалении компании, необходимо нажать на кнопку «Удалить».
Перед удалением выполняется проверка на содержание объектов данной компании рис.2.14, если таких нет, программа предупреждает об удалении рис.2.15, в случае положительного ответа, компания удаляется
Рис.2.14 Предупреждение о существование объектов
Рис.2.15 подтверждение к удалению
Таблица может быть отсортирована. Критерий сортировки выбирается пользователем из списка панели «Сортировать по» рис.2.16
Рис.2.16 - Сортировка компаний
Раздел «Объекты».
Главная форма раздела «Объекты» представлена на рис.2.17.
Рис.2.17 - Главная формы, раздел «Объекты»
В данном разделе можно показать все объекты или объекты только определенной компании по желанию пользователя. Компания выбирается пользователем из списка панели «Показать» рис.2.18. При удалении, изменении, или добавлении компаний в базе данных состав списка соответственно изменяется.
Рис.2.18 - Вывод объектов компании Кварсис
Для того чтобы отсортировать данные объекта необходимо выбрать критерии сортировки из списка панели «Сортировать по», и задать направление сортировки рис.2.19
Рис.2.19 - Сортировка таблицы объектов
Для добавления объекта необходимо вызвать форму «Добавить объект». Для этого надо нажать на кнопку «Добавить» рис.2.20
Рис.2.20 - форма «Добавить объект»
Данная форма позволяет добавить объект в любую компанию. Строительная компания выбирается из списка, где отображены все компании существующей базы данных, также создан список для выбора района, где находится объект и строительного материала.
Для изменения данных объекта необходимо вызвать форму «Изменить ДАННЫЕ ОБЪЕКТА». Для этого надо нажать на кнопку «Изменить» рис.2.21
Рис.2.21- форма «Изменить ДАННЫЕ ОБЪЕКТА»
Для удаление записи объекта нужно нажать на кнопку «Удалить». Перед удалением программа предупреждает о том, что объект будет удален вместе с квартирами, находящимися в данном доме рис.2.22, в случае положительного ответа объект удаляется
Рис.2.22 - предупреждение об удалении объекта
Для поиска объекта, необходимо вызвать форму «Поиск ОБЪЕКТА». Для этого нужно нажать на кнопку «Поик» рис.2.23
Рис.2.23 - форма «Поиск ОБЪЕКТА»
Данная форма позволяет искать объект по различным критериям. Для поиска объекта необходимо напротив нужного критерия поставить галочку и заполнить соответствующие поля: выбрать (для полей «Компания» «Район» или Материал) нужное значения или ввести данные(в поля «Адрес», «Этажность » и «Срок сдачи») . Например рис.2.24
Рис.2.24 - Пример заполнения формы «Поиск ОБЪЕКТА»
После заполнения формы нужно нажать на кнопку «Искать», программа выдаст сообщение с результатом поиска.
Раздел «Квартиры»
Главная форма раздела «Квартиры»представлена на рис.2.25
Рис.2.25 - Главная форма Раздела «Квартиры»
В данном разделе можно показать все квартиры или квартиры только определенной компании определенного объекта по желанию пользователя. Компания и адрес объекта выбираются пользователем из списка панели «Показать». При изменении, удалении или добавлении компаний и принадлежащих им объектов в базу данных, состав списков соответственно изменяется рис.2.26
Рис.2.26 - выбор квартир по компании и дому.
Сортировка осуществляется аналогично сортировки предыдущих разделов рис.2.27
Рис.2.27- Сортировка таблицы квартиры
Для добавления квартиры необходимо вызвать форму «Добавить квартиру». Для этого надо нажать на кнопку «Добавить» рис.2.28
Рис.2.28 - Форма «Добавить КВАРТИРУ»
Данная форма позволяет добавить квартиру в любую компанию, в любой объект, принадлежащий выбранной компании. Данные выбираются из списка, компаний и списка объектов, причем в списке объектов, содержатся только те объекты, которые принадлежат выбранной компании. Также созданы списки для выбора района, где находится объект и строительного материала.
Аналогично с предыдущими разделами организовано изменение рис.2.29
Рис.2.29 - Форма «Изменить ДАННЫЕ О КВАРТИРЕ»
Что бы осуществить поиск квартиры, необходимо воспользоваться формой представленной на рис.2.30. В данной форме устанавливаются критерии поиска и после нажатия кнопки «искать» выдаётся результат.
Рис.2.30- Форма «поиск квартиры»
Для того, чтобы посчитать страховую премию необходимо вызвать форму «Страховая премия», которая вызывается с помощью нажатия кнопки «ПРЕМИЯ» рис.2.31
Рис.2.31 - Форма «Страховая премия»
Рассмотрим подсчет премии на конкретном примере:
Шаг 1:
- устанавливается категория застройщика (1категории, 2категория, 3категория, 4категория) (данная информация о категориях строительных компаний содержится в разделе «Компании»);
- выбирается стадия строительства объекта (4 этапа: от цокольного до 1/3 этажности дома, от 1/3 до 2/3 этажности дома, от 2/3 этажности дома до последнего, отделочные работы);
- выбирается срок страхования (на 1 год, от 1 до 1.5, от 1.5 до 2, от 2 до 3 лет)
Шаг 2: устанавливаются финансовые риски (выделяются риски от которых страхуется клиент и нажимается на кнопку «Установить»). На форме видно как посчитались проценты;
Шаг 3) нажимается кнопка «Посчитать», после чего программа выводит стоимость страховки.
При подсчете использовались таблицы раздела «Расчет тарифа» рис.2.32
Рис.2.32 - Форма «Расчет тарифа»
Формирование отчетов
Для анализа работы компании, для принятия управленческих решений необходимы отчеты страховых премий для строящегося жилья.
Для этого есть подраздел «Отчеты». На данный момент существует два отчета. Это отчёт по объектам и развёрнутый отчёт по объектам на конкретную дату. Развёрнуты отчёт по объектам представлен на рис.2.33
Рис.2.33 - Развёрнутый отчёт по объектам
Глава 3 Обоснование экономической эффективности и внедрение проекта
§ 3.1. Внедрение и эксплуатация информационной системы
Подготовка объекта внедрения
Подготовка объекта для внедрения системы учёта страховых премий для строящегося жилья в страховой компании предусматривает обеспечение надежной работы системы.
На стадии подготовки технических средств системы обеспечивается готовность рабочих помещений, предназначенных для размещения компьютерной техники в соответствии с действующими строительными нормами и санитарными правилами. В помещении, предназначенном для эксплуатации системы, предусматриваются противопожарные меры безопасности. При всех видах работ по техническому обслуживанию и ремонту КТС и его составных частей соблюдаются требования и меры по защите микросхем от разрушающего воздействия статического электричества.
Программный комплекс предусматривает одновременную работу нескольких клиентских рабочих мест с одной базой данных при наличии локальной сети (с пропускной способностью 100 Mb/s) по протоколу TCP/IP с учетом требований корпоративной вычислительной сети. Приложение распределяется по местам пользователей системы и защищено паролем.
3.1.2.Тестирование системы
В рамках внедрения системы предусмотрен ряд испытаний:
- предварительные испытания;
- опытная эксплуатация;
- приемочные испытания.
С целью определения работоспособности системы и решения вопроса о возможности приемки ее в опытную эксплуатацию были проведены предварительные испытания. В качестве эксперта был выбран пользователь системы - сотрудник отдела по работе с клиентами. [26]
Подготовленные и согласованные тесты на этапе предварительных испытаний обеспечили:
- полную проверку функций и процедур системы;
- необходимую точность вычислений;
- проверку основных временных характеристик функционирования программных средств;
- проверку надежности и устойчивости функционирования программных и технических средств.
В качестве исходной информации для теста был использован фрагмент реальной информации ЗАО СК «Фарт»в объеме, достаточном для обеспечения необходимой достоверности испытаний.
На основе результатов предварительных испытаний было принято решение о запуске системы в опытную эксплуатацию, которая будет происходить на территории отдела по работе с клиентами и включать в себя следующие виды работ:
- контроль качества выполняемых функций;
- оценка удобства технического обслуживания.
Продолжительность опытной эксплуатации составляет 2 недели. В ходе эксплуатации системы ведется рабочий журнал, в который заносятся сведения о результатах наблюдения за правильностью ее функционирования, об отказах, сбоях, аварийных ситуациях, корректировках технической документации.
Условия эксплуатации системы
Сохранность информации, создающейся в ходе функционирования системы принятия управленческих решений в страховой компании, а также целостность самой системы обеспечивается за счет периодического создания резервных копий соответствующих таблиц архивной базы данных с последующим их хранением на магнитных (магнитооптических, оптических) носителях.
Для обеспечения сохранности информации при потере электропитания, питание устройств осуществляется через источники бесперебойного питания.
Информационное обеспечение направлено на реализацию функций системы, важнейшими из которых является формирование аналитической отчетности.
Основу информационного обеспечения системы составляют:
- защита данных от разрушения в аварийных и сбойных ситуациях;
- защита данных от несанкционированного доступа.
С целью подготовки штатов к работе с системой организовано обучение обслуживающего персонала. Для качественной работы приложения необходимо:
- компьютер с процессором Pentium 233 МГц или более мощный, рекомендуется Pentium III;
- Microsoft Windows 2000 с Service Pack 3 или более поздней версии, или Microsoft Windows XP или операционная система более поздней версии;
- память: ОЗУ 128 Мбайт или как рекомендуется выше;
- 130 Мбайт памяти на жестком диске.
§ 3.2. Экономическая эффективность информационной системы
Расчет экономической эффективности информационной системы планирования бюджета движения денежных средств
Экономическая эффективность - это разность или соотношение стоимостного эффекта от внедрения автоматизированной системы и стоимости самой системы, затрат на ее создание и эксплуатацию за определенный период времени [23]. Обоснование экономической эффективности внедрения информационной системы позволяет:
- выявить необходимость и целесообразность затрат на создание и внедрение информационной системы на конкретном объекте;
- рассчитать срок окупаемости затрат на создание информационной системы и сравнить его с установленными нормативами;
- определить влияние внедрения новых технических средств в управление объектом на технико-экономические показатели его деятельности (себестоимость, рентабельность, производительность труда, и т. п.);
- выбрать экономически наиболее эффективные варианты построения информационного обеспечения информационной системы.
Во многих случаях, при автоматизации аналитических задач определение общей экономической эффективности не представляется возможным, такой вариант можно оценить лишь качественно. В этих случаях единственно целесообразной является количественная оценка экономичности выбираемого варианта решения задач. Для определения экономической эффективности информационных систем существует целый ряд типовых методик, используемых с учетом специфики данного органа управления и организации в нем процесса внедрения информационной системы [24]. Рассматриваемая ниже методика рассчитана на такую ситуацию, когда невозможно оценить общую эффективность автоматизации аналитической задачи. В основе этой методики лежит сопоставление показателей, полученных в дипломном проекте, с показателями ручного варианта обработки информации, выбранного в качестве базового [25].
Исследования в области программного моделирования расходов начались в 1965 г. К настоящему времени разработано много моделей и методов оценки затрат, но даже с их помощью сложно точно оценить размеры программных продуктов и трудоемкость их разработки.
Для оценки экономической эффективности информационной подсистемы «Учет продаж компьютерной техники» использовалась модель COCOMO II (Constructive Cost Model), которая является одной из самых популярных моделей. Это обусловлено сравнительной легкостью применения расчета затрат.
Модель СОСОМО II, опубликованная в 1995 г., состоит из трех подмоделей, каждая из которых применяется при определенных условиях: при сборке приложения из готовых компонентов, на этапе предварительного проектирования и после проектирования архитектуры приложения. Подмодели можно использовать совместно различными способами, наиболее подходящими для технологий, распространяемых на рынке на данный момент и перспективных.
Подмодель, применяемая при сборке приложений, - модель композиции приложений - предназначена для оценки трудозатрат и плана работ по проектам, где для ускоренной разработки приложений используется комплекс инструментальных средств разработки программ. Подмодель основывается на подсчете отчетов и модулей языка 3GL, созданных в приложении. При подсчете производится оценка сложности по трехбалльной шкале: простой модуль, средней сложности и сложный. Подобный упрощенный подход к оценке соответствует тому объему информации, который доступен на этапе планирования проектов, связанных со сборкой приложений из компонентов.
Подмодель, применяемая на этапе предварительного проектирования, проводит анализ возможных альтернатив архитектуре и функциональным возможностям системы. Обычно на этапе предварительного проектирования недостаточно информации для проведения детальной оценки на уровне мелких структурных единиц проекта. В основу модели положен метод балльной оценки сложности (если доступен исходный код, оценка сложности производится по числу строк в исходном коде), пять масштабных множителей и семь мультипликаторов трудозатрат.
Третья подмодель применяется на тех этапах, когда уже завершено высокоуровневое проектирование и доступны детальные сведения о проекте, а также определена и согласована архитектура приложения. Подмодель полностью оценивает цикл разработки и является детализированным дополнением ко второй подмодели. Метод балльной функциональной оценки и (или) строки исходного кода используются для вычисления параметра сложности, скорректированного с учетом разбиения и повторного использования кода. Используется также набор из семнадцати мультипликаторов трудозатрат и набор из пяти масштабных множителей, определяющих положительный или отрицательный экономический эффект масштаба при разработке.
Преимущества использования модели COCOMO II:
- это открытая модель (опубликованы все ее детали: уравнения для оценки расходов; все предположения, формируемые в модели; каждое определение, используемое в модели; затраты на оценку, определенные в явном виде);
- с использованием функциональных указателей модель может использоваться уже на ранних этапах разработки и трудоемкость оценки (при использовании специализированных программ для расчета) составляет 6-10 часов.
Модель хорошо специфицирована (получаемые оценки более объективны и воспроизводимы, чем оценки на основе патентованных моделей, и модель может быть скорректирована под конкретную среду разработки для получения более точных оценок).
Оценка объемов системы
Справочники
Для реализации данной задачи необходимо вести следующие справочники:
- строительные компании;
- категории строительной компании;
- строящиеся объекты;
- районы;
- материалы;
- квартиры;
- типы квартир;
- план квартиры;
Строительные компании- содержит информацию о строительной компании. Далее приведены поля этой таблицы (С_ID - номер строительной компании(ключ), K_ID - код таблицы категорий, по данному полю происходит связывание с таблицей Кategor, C_Name - название строительной компании, С_Phone - телефон строительной компании, С_Address - адрес строительной компании, С_Kat - Категория строительной компании).
Категории строительной компании- содержит инормацию о категориях строительных компаний (K_ID - номер категории(ключ), K_Name - название категории, K_pk - поправочный коэффициент).
Строящиеся объекты- содержит информацию о строящихся объектах (O_ID - номер объекта(ключ), С_ID - код строительной компании, D_ID - код района в котором находиться данный объект, M_ID - код материала из которого сделан объект, Address - адрес объекта, O_Date - срок сдачи объекта, O_Distr - район объекта, О_Mat - строительный материала из которого сделан объект, O_Floor - этажность объекта, С_Name - строительная компания, строящая данный объект).
Районы- содержит все районы (D_ID - номер района(ключ), D_Name - специальные сокращения районов, District - полное название района).
Материалы - содержит все существующие стандартные материалы для строительства объектов (M_ID - номер материала(ключ), M_Name - специальное сокращение материала, Material - полное название материала).
Квартиры - содержит полную информацию о квартирах (F_ID - номер квартиры(ключ), O_ID - код строящегося объекта, в котором находится данная квартира, T_ID - код типа квартиры, P_ID - код планировки квартиры, F_Col - количество комнат, F_Pod - номер подъезда, O_Floor - этажность объекта(заносится автоматически), F_Floor - этаж на котором находится квартира, F_Type - тип квартиры, F_Plan - планировка квартиры, O_Address - адрес строящегося объекта, в котором находится данная квартира(заполняется автоматически), F_S_obsh - общая площадь квартиры, F_Cost_Sr - средняя стоимость квартиры в рублях за м2 , F_Cost_Toch - точная стоимость квартиры в рублях за м2, F_StrahPrem - страховая премия в рублях(заполняется после подсчета), С_Name - строительная компания, которая строит данный объект(заносится автоматически).
Типы квартиры- содержит все существующие стандартные типы квартир (T_ID - номер типа(ключ), T_Name - специальные сокращения типов квартир, Type - полное название типа квартиры).
План квартиры- содержит все существующие стандартные планы квартир (P_ID - номер плана(ключ), P_Name - специальные сокращения планов квартир, Plan - полное название плана).
Формы
Для реализации выше перечисленных операции необходимо создать следующие формы
- форма для ввода компаний; уровень низкий;
- форма для ввода объектов; уровень средний;
- форма для ввода квартир ; уровень низкий;
- форма для ввода материала; уровень низкий;
- форма для ввода реквизитов компаний; уровень низкий;
- форма для ввода типов квартир; уровень низкий;
- форма для ввода плана квартир; уровень низкий;
- форма для ввода категории; уровень низкий;
- форма для ввода районов города; уровень низкий;
- форма для ввода этажности объекта; уровень низкий;
- форма для ввода срока сдачи объекта; уровень низкий;
- форма для ввода средней стоимости квартиры; уровень низкий;
- форма для ввода точной стоимости квартиры; уровень средний;
- форма для ввода площади квартиры; уровень сложный;
- форма для ввода поправочных коэффициентов; уровень сложный.
Отчёты
- движения денежных средств - уровень сложности средний;
- развернутый отчёт по объектам страхования- уровень сложности простой.
Операции
- расчёт страховой премии;
- поиск по квартирам;
- добавление компании застройщика;
- добавление объектов;
- добавление квартир;
- удаление компании застройщика;
- удаление объектов;
- удаление квартир;
- транзитные операции.
Запросы
Запросы, которые будут выполняться нашей системой:
- запрос на сумму страховой премию по каждому застройщика;
- запрос на сумму страховой премию по каждой компании;
- запрос на сумму страховой премию по каждой квартире.
3.2.1. Расчет функциональных показателей
Функционально-ориентированные указатели (метрики) косвенно измеряют программный продукт и процесс разработки.
Формула расчета функциональных указателей:
FP = метрика*(0,65+0,01*?Fi)
где метрика - общий вес оценок требований пользователей.
?Fi - сумма оценок четырнадцати специфических факторов.
Для расчета функциональных указателей необходимо проанализировать проект, исходя из требований пользователя (внешние вводы и выводы, доступ к базе данных, справочные данные других систем). Все эти требования классифицируются по сложности на 3 категории - «высокой сложности», «средней сложности» и «низкой сложности». Каждая комбинация получает индивидуальный вес.
- внешние вводы - всех вводов пользователя, по которым поступают прикладные данные.
- внешние выводы - всех выводов, по которым пользователю поступают результаты, вычисленные приложением.
- запросы - диалоговых вводов, которые приводят к немедленному программному ответу.
- внутренние логические файлы - всех логических групп данных, которые могут быть частью базы данных.
- внешние интерфейсные файлы - всех логических файлов, на которые ссылается данное приложение.
Таблица 3.1 Оценка сложности экранов
|
Характеристики |
Кол-во всего |
Ранг |
||||
|
Низкий |
Средний |
Высокий |
Всего |
|||
|
Внешние формы |
21 |
11*3=33 |
2*4=8 |
8*6=48 |
89 |
|
|
Внешние выводы |
11 |
4*4=16 |
5*5=25 |
2*7=14 |
55 |
|
|
Внешние запросы |
11 |
4*3=12 |
5*4=20 |
2*6=12 |
44 |
|
|
Внутренние логические файлы |
21 |
11*5=55 |
8*7=56 |
2*10=20 |
131 |
|
|
Итого |
- |
- |
- |
- |
319 |
Далее производится обоснование коэффициентов регулировки сложности. Коэффициент регулировки сложности может принимать следующие значения: 0 - нет влияния, 1 - случайное, 2 - небольшое, 3 - среднее, 4 - важное, 5 - основное.
Распределение коэффициентов регулировки сложности (Fi):
1. Параметр передачи данных - 2
2. Распределенная обработка данных - 4
3. Производительность - 5
4. Распространенность используемой конфигурации - 3.
5. Скорость транзакции-5.
6. Оперативный ввод данных - 4
7. Эффективность работы конечного пользователя - 4.
8. Оперативное обновление - 5
9. Сложность обработки - 4
10. Повторная используемость - 0
11. Легкость инсталляции - 1
12. Легкость эксплуатации - 4.
13. Разнообразие условий размещения - 10
14. Простота изменений - 1
Т.к. система не будет продаваться, то возможность изменений не предусмотрена.
Fi:=42
Вычисление количества функциональных указателей с учётом коэффициентов сложности производится по следующей формуле:
Подобные документы
Исследование динамики сбора страховых премий страховыми компаниями Украины за последние года. Изучение сущности страховой премии - платы за страхование, которую страхователь обязан внести страховщику в соответствии с договором страхования или законом.
контрольная работа [43,6 K], добавлен 12.05.2012Особенности бухгалтерского учета и отчетности в страховой компании. Понятие и назначение страховых резервов. Состав страховых резервов, правила их формирования. Анализ влияния страховых резервов на финансовое состояние и устойчивость страховой компании.
дипломная работа [168,9 K], добавлен 05.01.2011Проектирование работы страховой компании, порядок обоснование выбора. Особенности определения ущерба и страхового возмещения в имущественном страховании. Расчет страховых премий, их учет. Вычисление платежеспособности страховщика, устойчивости операций.
контрольная работа [72,1 K], добавлен 24.01.2010Изучение задач актуарных расчетов. Определение принципов страховой политики: совокупность, рентабельность операций, эквивалентность, доступность и стабильность тарифов. Рассмотрение показателей страховой статистики. Ознакомление с видами страховых премий.
контрольная работа [19,0 K], добавлен 22.05.2010Исследование финансово-хозяйственной деятельности страховой компании "Росгосстрах". Коэффициентный анализ ликвидности, платежеспособности и рентабельности страховой компании. Эффективность страховых операций компании на начало и конец отчетного периода.
курсовая работа [143,2 K], добавлен 31.07.2010Понятие и структура страховой компании. Организационные структуры по управлению и по сферам деятельности. Оплата труда страховых работников и их функциональные обязанности. Нештатные работники страховых компаний. Обеспечение устойчивого функционирования.
контрольная работа [17,0 K], добавлен 14.03.2009Общая характеристика деятельности страховой компании "КОМЕСТРА", история ее создания и развития, роль и значение на современном рынке страховых услуг России. Структура компании, основные элементы. Комплекс страховых услуг, характеристика и преимущества.
отчет по практике [21,5 K], добавлен 07.04.2009Изучение специфики страхового бизнеса и внедрения информационных технологий в этой сфере. Принцип работы онлайн-системы ГЕНПОЛИС, позволяющей оптимизировать процесс продажи страховых продуктов вне офиса страховой компании, обеспечить их первичный учет.
контрольная работа [51,8 K], добавлен 11.02.2011Теоретические основы формирования рынка страховых услуг. Проблемы развития рынка страховых услуг в России. Динамика страховых премий в разрезе продуктов. Определение надежности страховых компаний. Современное состояние российского рынка страховых услуг.
реферат [571,5 K], добавлен 02.02.2015Страхование как финансовый механизм возмещения ущерба и источник рефинансирования кредитного сектора. Основные макроэкономические показатели российского страхового рынка. Число страховых компаний в России. Общий объем страховых премий и их структура.
реферат [42,1 K], добавлен 01.03.2011
