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

3.2.4. Построение DFD-диаграммы

     Для того чтобы документировать механизмы  передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для  наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0. [5] 
 
 
 
 
 
 
 

Диаграмма DFD показана на рис. 21:

Рис.21. DFD-диаграмма «Беседа с клиентом»

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

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

3.2.5. Построение диаграммы дерева узлов и FEO-диаграммы

     Дерево  узлов - представление отношений  между родительскими и дочерними  узлами модели IDEF0 в форме древовидного графа. Диаграмма узлов использует традиционное дерево иерархий, в котором верхний узел (блок) соответствует контекстной диаграмме, а нижний уровень — декомпозицию потомков. [9]

     Диаграмм деревьев узлов может быть в модели сколь  угодно много, поскольку дерево может  быть построено на произвольную глубину  и не обязательно с корня.  Диаграмма дерева узлов изображена на рис.22

      

       
 
 
 
 

Рис. 22 Диаграмма  дерева узлов

FEO-диаграмма — это диаграмма-иллюстрация отдельных фрагментов модели и для иллюстрации альтернативной точки зрения, либо для специальных целей, которые не поддерживаются явно синтаксисом IDEFO. FEO-диаграмма позволяет иллюстрировать различные сценарии, показывать различные точки зрения, отображать отдельные детали, которые явно не поддерживаются синтаксисом IDEF0. [4] FEO-диаграмма показана на рис. 23. 
 
 
 
 
 

     Рис. 23. FEO-диаграмма

3. Описание модели TO-BE

      Итак, в нашей  модели отражены все основные процессы для функционирования системы. Однако, существуют недочеты, в частности  в процессе проведения консультаций. На поиск нужной клиенту информации сотрудник затрачивает время, может потребоваться повторное обращение. Это не всегда может понравиться клиенту. Поэтому целесообразно введение процесса on-line консультаций, что значительно ускорит процесс (рис.24). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Рис. 24. Модель TO BE

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

 

ГЛАВА 4. Построение модели данных в Erwin

 

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

     4.1. Построение логической  и физической модели данных

     В Erwin существуют 2 уровня моделирования: логический и физический.

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

      Рис. 25. Логическая модель данных

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

     Таблица 5

 

     Для каждой сущности определим набор  атрибутов.

     Сущность  «Клиент» содержит следующие атрибуты: «идентификационный номер клиента» – первичный ключ; «№ автомобиля», «№ договора», «Код сотрудника»– внешние  ключи, а так же атрибуты «ФИО»,  «Дата рождения», «Адрес» и «Паспорт», описывающие личные данные клиента.

     Сущность  «Договор» содержит следующие атрибуты:

• № договора (первичный ключ);
• № автомобиля;
• Дата страхования
• Сумма страхования.

     Сущность  «Автотранспорт» содержит информацию о имеющемся автотранспорте клиента и включает следующие атрибуты:

• № авто (первичный ключ);
• Цвет;
• Марка авто;
• Год выпуска.

     Сущность  «Полис» включает следующий набор атрибутов:

• № полиса (Первичный ключ);
• № договора (Внешний ключ);
• Дата выдачи;
• Срок окончания.

     Сущность  «Сотрудник» содержит информацию о  штате сотрудников и включает следующие атрибуты:

• Код сотрудника (Первичный ключ);
• ФИО;
• Дата рождения;
• Паспорт.

     Сущность «Взносы» содержит следующие атрибуты:

• № квитанции (Первичный ключ);
• Дата взноса;
• Сумма;
• № договора (Внешний ключ).

     Приведем  пояснения к каждой связи между  сущностями.

     Тип связи между таблицами «Клиент» и  «Договор» - один к одному, т.е. один каждый клиент заключает по одному договору на каждый автомобиль.

     Тип связи между таблицами «Автотранспорт» и  «Клиент» - один к одному, т.е. каждый клиент имеет по 1 экземпляру автотранспорта для страхования по одному договору.

     Тип связи между таблицами «Договор» и  «Полис» - один к одному, т.е. по каждому договору клиенту выдается один полис.

     Тип связи между таблицами «Сотрудник» и  «Клиент» - неидентифицирующая. Каждый сотрудник может обслуживать несколько клиентов.

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

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

      Рис. 26. Физическая модель данных

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

     4.2. Прямое и обратное проектирование

 

       Процесс генерации физической  схемы базы данных из логической  модели данных называется прямым проектированием. Создадим пустую базу данных "Страхование" в СУБД MS Access. Основным назначением базы данных "Страхование" будет автоматизация функции по учету клиентов и заключения договоров. С помощью встроенных функций Erwin создадим базу «Страхование». База данных «Страхование» будет включать 6 таблиц. (Рисунок 27)

       
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Рис.27. База данных «Страхование» 

     Схема данных предметной области представлена на рисунке 28. 

        
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Рис. 28. Схема данных 
 

     Процесс генерации логической модели из физической базы данных называется обратным проектированием. Создадим новую логико-физическую модель в Erwin. При помощи меню Tools/ Reverse Engineer From можно задать источник обратного проектирования – базу данных. При помощи кнопки Browse выбираем файл, содержащий базу данных. [5]Результат обратного проектирования показан на рисунке 29. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

           Рис. 29. Обратное проектирование 

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

     Заключение

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

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

     В нотации IDEF0 мы показали все процессы в моделируемой системе и отразили взаимосвязи между ними. С помощью диаграммы IDEF3 была смоделирована последовательность действий при заключении договора страхования и осмотра автотранспорта. Встроенный механизм вычисления стоимости позволил нам оценить и проанализировать затраты на процесс страхования. На основе построенной модели нами были выявлены недостатки процесса и предложены улучшения – модель TO BE. Инструмент Erwin помог нам создать базу данных предметной области.

     Таким образом, все задачи поставленные в  курсовом проекте можно считать  выполненными.

     Итак, мы убедились в том, что инструменты BPwin и Erwin могут существенно облегчить работу при  проектировании и анализе бизнес-процессов.

 

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

     

1. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. – М.: Изд-во стандартов, 1990.
2. ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств»
3. ГОСТ Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования»
4. Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c.
5. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М.  Вендров – М.: Финансы и статистика, 2006. – 310 c.
6. Грекул, В.И. Проектирование информационных систем: учебное пособие [Текст]  /  В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: Интернет-Ун-т Информ. технологий, 2005. – 304 с.
7. Грей К.Ф., Ларсон Э.У. Управление проектами: практическое руководство. [Текст] / К.Ф. Грей, Э.У. Ларсон . М.: КНОРУС, 2005. – 528 с.
8. Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст]  / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с.
9. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. - 327 c.
10. Марка Д.А. Методология структурного анализа и проектирования. [Текст] /  Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с.
11. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с.
12. Титоренко Г.А.  Автоматизированные информационные технологии в экономике. [Текст] / Г.А.  Титоренко – М.: Компьютер, ЮНИТИ, 2004.– 369c.
13. Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст]  /  В.Е. Туманов,  С.В.  Маклаков – М.: Диалог-МИФИ, 2007.  - 333 с.
14. Федотова Д.Э. CASE-технологии: Практикум [Текст] / Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик– М.: Горячая линия-Телеком, 2005. – 157c.
15. Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.05.2010г.)
16. Верников Г.В. Основные методологии обследования организаций. [Электронный ресурс]/ Г.В. Верников (Режим доступа: http://www.cfin.ru. Дата просмотра: 15.05.2010г.)
17. Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 06.05.2010г.)
18. Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 16.05.2010г.)
19. Свечников  А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 05.05.2010г.)
20. Свечников  А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 01.05.2010г.)