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

Федеральное государственное бюджетное образовательное учреждение высшего образования «Югорский государственный университет»

Институт (НОЦ) технических систем и информационных технологий

Кафедра систем обработки информации, моделирования и управления

КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование АСОИУ»

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

Выполнил:

студент 1131б группы

Грищенко М.Ю.

Руководитель проекта:

старший преподаватель

Гончаренко О.В.

Ханты-Мансийск

2017 г.



Содержание

Введение

1. Анализ требований к программному обеспечению

1.1 Требования к функциональным характеристикам программного обеспечения

1.2 Сценарии использования программного обеспечения в предметной среде

1.3 Разработка концептуальной модели предметной среды

2. Проектирование программного обеспечения информационной системы

2.1 Логическая модель проектируемого программного обеспечения

2.2 Моделирование поведения проектируемого программного обеспечения

3. Проектирование физической структуры программного обеспечения информационной системы

3.1. Проектирование компоновки программного обеспечения информационной системы

Заключение

Список использованной литературы

Приложение 1. Техническое задание

Приложение 2. Словарь понятий/терминов предметной среды



Введение

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

Для достижения цели необходимо решить ряд задач:

1. Проанализировать предметную область организации;

2. Изучить иерархическую структуру компании;

3. Выявить корпоративные процессы, нуждающиеся в автоматизации.

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

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

· систематизации большого набора входных данных;

· ускорению процесса заключения договора;

· исключению ошибок, связанных с расчетом страховых тарифов;

· обеспечению надежного хранения данных;

· снижению трудозатрат, связанных с составлением документов.



1. Анализ требований к программному обеспечению

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

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

1. Единая информационная среда предприятия;

2. Гибкая настройка параметров страхования;

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

4. Надежное хранение данных;

5. Интеграция с популярным в офисной среде программным обеспечением (линейка Windows от Microsoft).

1.1 Требования к функциональным характеристикам программного обеспечения

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

Возможность заключать страховые договора по следующему списку видов страхования:

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

1.1. Страхование ОСАГО

1.2. Страхование КАСКО

2. Страхование домашнего имущества в пределах 1 000 000р.

3. Добровольное медицинское страхование

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

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

· возможность просмотра заключенных договоров с помощью сервиса

· хранение заключенных договоров в базе данных

· обязательная авторизация пользователя

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

1.2 Сценарии использования программного обеспечения в предметной среде

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

Работник страховой компании (далее - страховщик), авторизовавшись в приложении, развернутом внутри корпоративной среды, заполняет входные данные нового контракта, основываясь на пожеланиях клиента. Ключевые параметры договорасохраняются в базе данных, и договор переходит в статус «черновик». Затем, менеджер по продажам просматривает сохраненный договор, и принимает решение - либо продать контракт, либо вернуть на корректировку. В первом случае договору выставляется статус «продан», страхователю распечатывается полис, автоматически сгенерированный системой с реквизитами, по которым осуществляется оплата. Во втором случае договор переходит в статус «необходима корректировка», и страхователю необходимо внести корректировки в контракт, а затем снова передать менеджеру по продажам для рассмотрения.

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

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

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

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

Вариант использования (прецедент, usecase) -- описание множества последовательности действий (включая варианты), выполняемых системой для того, чтобы актор мог получить определенный результат [1,2].

На основании анализа предметной среды были определеныследующие компоненты системы. Акторами разрабатываемого сервиса являются:

· страхователь

· страховщик

· менеджер по продажам

Прецедентамисервиса являются:

1. Посмотреть статистику продаж;

2. Авторизация;

3. Просмотреть список предыдущих контрактов;

4. Создать новый контракт;

5. Сохранить контракт в БД;

6. Вернуть на корректировку;

7. Открыть сохраненный контракт;

8. Удалить контракт;

9. Редактировать контракт;

10. Обновить данные в БД;

11. Продать контракт;

12. Распечатать договор;

13. Внести данные для сбора статистики.

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

Для описания потока событий был выбран основной прецендент «Продать контракт», так как он является основным для разрабатываемого сервиса. Последовательность потока событий прецендента «Продать контракт»:

1. Прецендент начинается с авторизации страховщика.

Е1. Неверно указан пароль или логин страховщика.

А1. Страховщик проходит регистрацию.

2. Страховщик создает новый контракт, заполняет все его формы.

Е2. Заполнены не все ключевые поля контракта.

3. Данные контракта сохраняется в БД, сам контракт переходит в статус «черновик». Необходимый тариф рассчитывается автоматически.

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

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

4. Менеджер по продажам, сверившись со статистикой, продает контракт, присваивая ему статус «продан».

Альтернативные потоки:

А1. Страховщик проходит регистрацию.

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

2. Поток возвращается к шагу 1.

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

1. Менеджер по продажам переводит контракт в статус «нуждается в корректировке», указывается причина невозможности его продажи.

2. Страховщик уточняет данные, звоня страхователю для уточнения.

3. Страховщик вносит правки в контракт, сохраняет его, снова присваивая ему статус «черновик».

Потоки ошибок:

Е1. Неверно указан пароль или логин страховщика.

1. Система просит пользователя заново ввести пароль и повторный пароль.

2. Поток возвращается к шагу 1.

Е2. Заполнены не все ключевые поля контракта.

1. Сервис выводит на экран сообщение о необходимости заполнить поля.

2.Поток возвращается к шагу 2.

Рисунок 1.1 - Диаграмма вариантов использования

1.3 Разработка концептуальной модели предметной среды

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

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

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

Основными элементами нотации диаграмм классов являются следующие.

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

· Состояниеобъекта - это одно из условий, в котором он может находиться. Обычно изменяется со временем и характеризуется набором свойств, которые называются атрибутами.

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

· Индивидуальностьозначает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта.

Для группировки объектов используются классы.

Класс - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой.

Каждый класс является шаблоном для создания объекта. А каждый объект - это экземпляр класса.

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

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



2. Проектирование программного обеспечения информационной системы

2.1 Логическая модель проектируемого программного обеспечения

Логическая модель, а именно диаграмма классов, занимает основное место в проектировании программного обеспечения.

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

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

Пакеты было решено составить по принципу проектирования программного обеспечения model-view-controller (MVC). Данный принцип разграничивает области ответственности программного обеспечения на определенные сегменты. Модель (model) отвечает за хранящиеся данные в приложении, представление (view) обрабатывает то, что видит на своем экране пользователь, а контроллер (controller) содержит в себе внутреннюю логику приложения. В результате были определены следующие пакеты:

1. Интерфейс пользователя;

2. Внутренняя логика приложения;

3. База данных.

Внутри пакетов расположены классы, представляющие конкретный сегмент приложения:

Таблица 2.1. - Разделение классов по пакетам.

Пакет	Интерфейс пользователя	Внутренняя логика приложения	База данных
Классы	Форма страховщика Форма менеджера Форма авторизации Запрос на получение данных Журнал договоров	Сервис обработки статистических данных RequestHandler (обработчик запросов) Сервис печати данных Очередь запросов к БД	Контракт Пользователь

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

Рисунок 2.1 - Диаграмма классов

2.2 Моделирование поведения проектируемого программного обеспечения

2.2.1 Диаграмма деятельности

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

Построим диаграмму деятельности для варианта использования «Продать контракт», поскольку в нём сосредоточен основной функционал проектируемого сервиса.

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

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

Сформированная диаграмма деятельности представлена на рисунке 2.2.

Рисунок 2.2 - Диаграмма классов

2.2.2 Диаграмма последовательности

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

Составим диаграмму последовательности для варианта использования «Продажа контракта».

Объекты, используемые для построения диаграммы последовательности:

1. Страховщик;

2. Веб-сервис;

3. Менеджер по продажам.

Сформированная диаграмма последовательности представлена на рисунке 2.3.

Рисунок 2.3 - Диаграмма последовательности

2.2.3 Диаграмма кооперации

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

Сформированная диаграмма кооперации представлена на рисунке 2.4.

Рисунок 2.4 - Диаграмма кооперации

2.2.4 Диаграмма состояний

Диаграмма состояний показывает объект с момента его создания и до его уничтожения.

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

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

Рисунок 2.4 - Диаграмма состояний контракта



3. Проектирование физической структуры программного обеспечения информационной системы

3.1 Проектирование компоновки программного обеспечения информационной системы

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

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

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

· Визуализации общей структуры исходного кода программной системы.

· Спецификации исполнимого варианта программной системы.

· Обеспечения многократного использования отдельных фрагментов программного кода.

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

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

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

Одни компоненты могут существовать только на этапе компиляции программного кода, другие -- на этапе его исполнения.

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

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

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

Рисунок 3.1 - Диаграмма размещения



Заключение

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

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



Список использованной литературы

1. Новиков Ф., Иванов Д. Моделирование на UML / - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.

2. Перерва А., Иванова В. Путь аналитика. Практическое руководство IT-специалиста / - СПб.: Питер, 2012 - 304 с.

3. Официальная страница StarUml[Электронный ресурс]. URL:staruml.io/

4. Брауде Э. Технология разработки программного обеспечения / Э. Брауде. - СПб.: Питер, 2004. - 655 с.

5. Проектирование информационных систем [Электронный ресурс]. URL: www.intuit.ru/studies/courses/2195/55/lecture/1640



Приложение 1. Техническое задание

«СОГЛАСОВАНО» «УТВЕРЖДАЮ»

Представитель заказчика Представитель исполнителя

(Руководитель курсового

проектирования)

_____________ / / ___________ / /

«___» __________ 20 ___ г. «___» __________ 20 ___ г.

Техническое задание на проектирование программного обеспечения

«АВТОМАТИЗАЦИЯ СИСТЕМЫ СОСТАВЛЕНИЯ СТРАХОВОГО ДОГОВОРА»

1. Введение

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

После составления договора, его просматривает менеджер по продажам. Он сверяется со статистическими показателями, и принимает решение о продаже договора

Затем страховщику распечатывается полис с реквизитами предприятия, по которым происходит оплата страховой услуги.

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

2. Основание для разработки программного обеспечения

Основанием для разработки является задание на курсовой проект.

3. Назначение программного обеспечения информационной системы

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

4. Требования к программному обеспечению информационной системы

4.1. Требования к функциональным характеристикам.

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

ѕ Возможность заключать страховые договора по следующему списку видов страхования:

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

1.

1.1. Страхование ОСАГО

1.2. Страхование КАСКО

2. Страхование домашнего имущества в пределах 1 000 000р.

3. Добровольное медицинское страхование

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

ѕ возможность просмотра заключенных договоров с помощью сервиса

ѕ хранение заключенных договоров в базе данных

ѕ обязательная авторизация пользователя

Организация входных и выходных данных:

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

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

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

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

Основной режим использования системы - ежедневная работа.

4.1. Требования к надежности.

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

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

4.2. Условия эксплуатации и требования к составу и параметрам технических средств

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

4.3. Требования к информационной и программной совместимости

Программа должна работать на платформах Windows (XP и выше).

4.4. Требования к транспортировке и хранению

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

4.5. Специальные требования.

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

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

5. Требования к программной документации программного обеспечения

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

6. Технико-экономические показатели

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

7. Порядок контроля и приемки

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

8. Этапы проектирования программного обеспечения

Название этапа	Сроки этапа	Контролируемые результаты завершения этапа
1. Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы.	15.01.2017 15.02.2017	Предложения по работе системы. Акт сдачи-приёмки
2. Разработка программного сервиса. 3. Проектирование и запуск в эксплуатацию базы данных	16.02.2017 29.04.2017	Программный комплекс. Разворачивание базы данных для сервиса.
4. Тестирование и отладка модуля. Внедрение системы в корпоративную сеть.	01.05.2017 19.05.2017	Готовый сервис разворачивается внутри корпоративной сети. Программная документация. Акт сдачи-приёма работ



Разработал студент гр. _______

____________ / /

(подпись)

«______» _____________ 20___



Приложение 2 - Словарь понятий/терминов предметной среды

ИС - информационная система;

UML - Unified Modeling Language (унифицированный язык моделирования);

БД - база данных;

СУБД - Система управления базами данных;

ТЗ - техническое задание.

Размещено на Allbest.ru

...