Проектирование реализации операций бизнес-процесса «Ведение договоров по страхованию автотранспортных средств».

Содержание:

ВВЕДЕНИЕ

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

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

Цель курсовой работы – проектирование информационной системы для реализации бизнес-процесса «Ведение договоров по страхованию автотранспортных средств» на примере компании «Альянс».

Для достижения поставленной цели необходимо решить следующие задачи:

• проанализировать текущую организацию бизнес-процесса «Ведение договоров по страхованию автотранспортных средств» и возникающего при его выполнении документооборота;
• выбрать и обосновать проектные решения по информационному и программному обеспечению;
• составить информационную модель проектируемой информационной системы;
• разработать базу данных и программные модули ИС;
• описать контрольный пример реализации проекта.

1 ГЛАВА. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Выбор комплекса задач автоматизации

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

На рисунке 1 изображена организационная схема компании «Альянс».

Рисунок 1. Организационная схема

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

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

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

Третий отдел в составе компании «Альянс» – финансовый отдел, данный отдел занимается организацией и контролем движения денежных средств как внутри компании, так и вне её. В функции отдела входит: прием оплаты, выплаты вознаграждений по договорам, выплаты и расчет заработной платы и прочие операции, непосредственно связанные с денежными средствами.

Четвертый отдел – отдел кадров, сотрудники которого принимают новых сотрудников на работу, ведут кадровый учет в компании

Пятый отдел – IT-отдел, главная задача которого – обеспечение корректно работающей компьютерной сферы предприятия.

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

1.2. Характеристика существующих бизнес-процессов

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

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

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

На первом этапе построения IDEF0 модели система представляется как единое целое. Основная цель данного этапа – выявить входные и выходные данные, а также механизмы и правила для данной системы. Диаграмма данного этапа называется контекстной. Контекстная диаграмма для бизнес-процесса «Ведение договоров по страхованию» изображена на рисунке 2 (для построения диаграмм использовалось CASE- средство AllFusion Process Modeler 7).

Рисунок 2. Контекстная диаграмма

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

Механизмом, осуществляющим рассматриваемую деятельность, является страховой агент, вся деятельность ведется в соответствии с законами Российской Федерации.

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

Рисунок 3. Диаграмма декомпозиции

Деятельность страховой компании состоит из трех бизнес-процессов:

• консультация клиента;
• формирование документов;
• прием оплаты.

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

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

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

1.3. Характеристика документооборота, возникающего при решении задачи

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

Рисунок 4. Схема документооборота

1.4. Обоснование проектных решений по информационному обеспечению

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

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

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

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

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

В качестве выходных данных – страховой договор и полис.

1.5. Обоснование проектных решений по программному обеспечению

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

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

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

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

Среда программирования Delphi обладает рядом преимуществ:

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

В качестве системы управления базой данных была выбрана СУБД MySQL.

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

2 ГЛАВА. ПРОЕКТНАЯ ЧАСТЬ

2.1. Информационная модель и её описание

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

Рисунок 5. Информационная модель

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

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

Таблица 1

Справочники информационной системы

№ п/п	Название справочника	Ответственный за ведение	Средний объём справочника в записях	Среднюю частоту актуализации	Средний объем актуализации, %
1	Пользователи	Администратор	25	1 раз в месяц	5
2	Типы документов	Администратор	10	1 раз в год	10

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

Реквизитный состав каждого справочника представлен в виде таблицы 2.

Таблица 2

Реквизитный состав справочников информационной системы

№ п/п	Наименование справочника	Перечень реквизитов
1	Пользователи	ФИО ФИО в родительном падеже Номер доверенности Дата выдачи доверенности пароль
2	Типы документов	Наименование

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

На рисунке 6 изображен макет формы для работы с записями справочника «Пользователи», а на рисунке 7 – справочника «Типы документов»

Рисунок 6. Макет формы «Пользователь»

Рисунок 7. Макет формы «Тип документа»

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

Рисунок 8. Макет формы для добавления данных о контрагенте

Рисунок 9. Макет формы для добавления данных о транспортном средстве

Рисунок 10. Макет формы для добавления данных о документе

Рисунок 11. Макет формы для добавления данных о договоре

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

2.3. Характеристика результатной информации

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

Подробное описание выходных данных в таблице 3.

Таблица 3

Описание результатной информации

Наименование	Полис	Договор страхования
Реквизиты	ФИО контрагента Реквизиты документа Адрес прописки Марка ТС Модель ТС Номерной знак ТС Идентификационный номер ТС Время начала страхования Дата начала Дата окончания Дата заключения Страхователь Документ Тип документа ФИО пользователя Номер доверенности Дата выдачи доверенности	ФИО контрагента Реквизиты документа Адрес прописки Марка ТС Модель ТС Номерной знак ТС Идентификационный номер ТС Время начала страхования Дата начала Дата окончания Дата заключения Страхователь Документ Тип документа ФИО пользователя Номер доверенности Дата выдачи доверенности
Таблицы, на основе которых формируется	Контрагенты Транспортные средства Типы документов Документы Договоры Пользователи	Контрагенты Транспортные средства Типы документов Документы Договоры Пользователи
Частота формирования	По мере необходимости	По мере необходимости
Способ доставки	Файл в формате doc	Файл в формате doc

2.4. Общие положения (дерево функций и сценарий диалога)

Базовый набор функций разработанной информационной системы можно изобразить в виде дерева, изображенного на рисунке 12.

Рисунок 12. Дерево функций

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

Рисунок 13. Сценарий диалога

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

2.5. Характеристика базы данных

В качестве системы управления базой данный для разрабатываемой информационной системы была выбрана СУБД MySQL.

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

Рисунок 14. ER-модель базы данных

Описание всех таблиц базы данных представлено в таблицах 4-9.

Таблица 4

Таблица documents (Документы)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
Id_transport	integer	FK	Транспортное средство, к которому относится документ	Да
Ser	varchar		Серия документа	Да
Num	varchar		Номер документа	Да
Vidan	varchar		Кем и когда выдан документ	Да
Id_Type	integer	FK	Тип документа	Да

Таблица 5

Таблица kontragents (Контрагенты)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
FIO	varchar		Фамилия Имя и Отчество клиента	Да
Doc	varchar		Данные документа	Да
Other	varchar		Примечание	Нет
adres	varchar		Адрес регистрации клиента	Да

Таблица 6

Таблица users (Пользователи)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
FIO	varchar		ФИО сотрудника-пользователя	Да
FIOgen	varchar		ФИО сотрудника-пользователя в родительном падеже (для корректного формирования договора)	Да
DovNum	datetime		Номер доверенности	Да
DovDate	datetime		Дата доверенности	Да
Password	varchar		Пароль для доступа к системе	Да

Таблица 7

Таблица transport (транспортные средства)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
id_kontr	integer	FK	Клиент, собственник ТС	Да
Marka	varchar		Марка ТС	Да
Model	varchar		Модель ТС	Да
GosZnak	varchar		Государственный регистрационный знак	Да
identnum	varchar		Идентификационный номер транспортного средства	Да

Таблица 8

Таблица polis (страховые договоры)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
id_kontr	integer	FK	Клиент, с которым заключен договор	Да
id_transport	integer	FK	Транспортное средство, относительного которого заключен договор	Да
Ntime	datetime		Время начала действия договора	Да
Ndate	datetime		Дата начала действия договора	Да
ODate	datetime		Дата окончания действия договора	Да
V1	boolean		Флаг, обозначающий выбор неограниченного количества лиц	Нет
V2	boolean		Флаг, обозначающий выбор определенного круга лиц, в отношении которых заключается договора	Нет
L1	varchar		ФИО первого лица	Нет
VU1	varchar		Данные водительского удостоверения (ВУ) первого лица	Нет
L2	varchar		ФИО второго лица	Нет
VU2	varchar		Данные водительского удостоверения (ВУ) второго лица	Нет
L3	varchar		ФИО третьего лица	Нет
VU3	varchar		Данные водительского удостоверения (ВУ) третьего лица	Нет
L4	varchar		ФИО первого лица	Нет
VU4	varchar		Данные водительского удостоверения (ВУ) четвертого лица	Нет
L5	varchar		ФИО первого лица	Нет
VU5	varchar		Данные водительского удостоверения (ВУ) четвертого лица	Нет
Other	text		Примечание к договору/дополнительные условия	Нет
Prem	varchar		Премия по договору	Да
id_user	integer	FK	Сотрудник, заключивший договор	Да
Zdate	datetime		Дата заключения договора	Да
id_doc	integer	FK	Документ на ТС, который обозначен в договоре	Да
Strah	varchar		Наименование страхователя	Да

Таблица 9

Таблица typedoc (типы документов)

Поле	Тип данных	Ключ	Описание	Обяз.
id	integer	PK	Первичный ключ таблицы	Да
type	varchar		Наименование типа документа	Да

2.6. Структурная схема пакета (дерево вызова программных модулей)

Проект программы состоит из восьми модулей:

• модуль Main.pas (главный модуль);
• модуль List.pas (просмотр списка данных);
• модуль Document.pas (работа с документом);
• модуль TypeDoc.pas (работа с типом документа);
• модуль Kontragent.pas (работа с контрагентом);
• модуль Polis.pas (работа с договором);
• модуль Auto.pas (работа с транспортным средством);
• модуль User.pas (работа с сотрудником).

Подробное описание модулей представлено в таблице 10.

Таблица 10

Описание модулей системы

№ п/п	Наименование модуля	Функции модуля
1	модуль Main.pas	содержит процедуры и функции, отвечающие за отображение главного окна программы и её главного меню
2	модуль List.pas	модуль содержит процедуры и компоненты для выполнения основных операций со справочниками информационной системы (просмотр, добавление, изменение, удаление записей)
3	модуль Document.pas	модуль содержит процедуры и компоненты для работы с данными документа
4	модуль TypeDoc.pas	модуль содержит процедуры и компоненты для работы с данными типа документа
5	модуль Kontragent.pas	модуль содержит процедуры и компоненты для работы с данными контрагента
6	модуль Polis.pas	модуль содержит процедуры и компоненты для работы с данными страхового полиса
7	модуль Auto.pas	модуль содержит процедуры и компоненты для работы с данными транспортного средства
8	модуль User.pas	модуль содержит процедуры и компоненты для работы с данными пользователя

Дерево вызова программных модулей приведено на рисунке 15.

Рисунок 15. Дерево вызова программных модулей

2.7 Описание программных модулей

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

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

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

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

В результате приложение обращается не прямо к источнику данных, а к объекту OLE DB, который «умеет» представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL.

Таблицы, расположенные на форме работы с данных (модуль List.pas), работают напрямую с таблицами базы данных, поэтому для их работы используется компонент AdoTable. Данный компонент представляет собой виртуальную копию таблицы базы данных, изменения в которой сразу передаются в связанную таблицу БД.

Для работы форм управления данными используется компонент AdoQuery. Данный компонент предназначен для отправки запросов к базе данных и обработки ответов на них. В приложении используются 3 вида запросов:

• запросы на выборку;
• запросы на добавление данных;
• запросы на обновление данных.

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

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

Для обновления данных, хранящихся в базе данных используется оператор UPDATE, для добавления новых – оператор INSERT.

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

Общий алгоритм работы системы представлен на рисунке 16.

Рисунок 16. Алгоритм работы программы

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

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

На рисунках 17-19 изображены блок-схемы алгоритмов подпрограмм.

Рисунок 17. Блок-схема алгоритм подпрограммы авторизации

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

На рисунке 18 изображена блок-схема алгоритма подпрограммы работы со справочниками.

Рисунок 18. Блок-схема алгоритма работы со справочниками

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

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

Рисунок 19. Блок-схема алгоритма регистрации нового договора

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

На рисунке 20 изображена блок-схема алгоритма работы подпрограммы работы с существующими договорами. Данный алгоритм имеет линейную структуру.

Рисунок 20. Блок-схема алгоритма работы с существующими договорами

2.8. Контрольный пример реализации проекта и его описание

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

Рисунок 21. Форма авторизации

Если веден неверный пароль, то отображается соответствующее сообщение об ошибке (Рисунок 22), если пароль введен верно, то отображается главное окно программы (Рисунок 23).

Рисунок 22. Сообщение о некорректном пароле

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

Рисунок 23. Главная форма программы

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

При выборе какого-либо справочника или таблицы с данными открывается стандартная форма для работы с таблицей (Рисунок 24).

Рисунок 24. Форма работы со справочником

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

Рисунок 25 – Форма добавления новой записи в таблицу

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

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

Рисунок 26. Подтверждение удаления

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

Рисунок 27. Форма для добавления нового договора

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

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

Рисунок 28. Сообщение об ошибке

После сохранения данных становятся видны кнопки для выгрузки в Word договора и страхового полиса (Рисунок 29).

Рисунок 29. Форма работы с договором после сохранения

Макеты выходных документов представлены в приложении А.

ЗАКЛЮЧЕНИЕ

В ходе проделанной работы были решены следующие задачи:

• была проанализирована текущая организация бизнес-процесса ведения договоров в компании «Альянс», были выделены основные этапы выполнения бизнес-процесса, изучен возникающий документооборот;
• были выбраны проектные решения как по информационному обеспечению, так и программному обеспечению: в качестве среды разработки была выбрана Delphi, а в качестве СУБД – MySQL;
• была составлена информационная модель информационной системы, которая отражает пути преобразования входной информации в выходную;
• была разработана база данных и программные модули, реализующие работу ИС.
• был описан контрольный пример реализации проекта.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

• ГОСТ 2.105 – 95. Общие требования к текстовым документам.
• ГОСТ 7.32 – 2001. Отчет по научно-исследовательской работе. Структура и правила оформления.
• ГОСТ 7.82-2001. Библиографическое описание электронных ресурсов.
• ГОСТ 24.702-85 Эффективность автоматизированных систем управления.
• ГОСТ Р 7.0.5-2008. Библиографическая запись. Библиографическое описание.
• Агальцов В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник. М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. 272 с.
• Гагарина Л.Г. Разработка и эксплуатация автоматизированных информационных систем: учебное пособие. М.: ИД «ФОРУМ»: ИНФРА-М, 2013. 384 с.
• Горбаченко В.И., Убиенных Г.Ф. Бобрышева Г.В. Проектирование информационных систем с СА Erwin Modeling Suite 7.3. Пенза: Изд-во ПГУ, 2012, 154 c.

1. Зуев Е.А. Программирование на языке Delphi 6.0,7.0. – М.: Радио и связь, Веста, 2016. - 186 с.

• Калмыков Ю.В. Учебно-методичское пособие по обучению программированию на языке Delphi для школ, 2014. – 100 с.
• Карпова И.П. Базы данных: Учебное пособие. – Спб.: Питер, 2013. – 240 с.
• Кузин А.В., Левонисова С.В. Базы данных: Учебное пособие для студ. высш. учеб. заведений. – М.: ИЦ Академия, 2012. – 320с.
• Культин Никита – Основы программирования в Delphi, 2015 – 232 с.
• Маклаков С. В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1) / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2013. – 340 c.
• Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2015. – 512 c.
• Тельнова, Ю.Ф. Проектирование экономических информационных систем: учеб. / под ред. Ю. Ф. Тельнова. М. : Горячая линия, 2015 — 345 c.
• Фуфаев Д.Э. Фуфаев Э.В. Разработка и эксплуатация автоматизированных информационных систем: учебник дя студ. М.: Издательский центр «Академия», 2013. 304 с.
• Шаньгин В.Ф. Информационная безопасность компьютерных системы и сетей: Учебное пособие. М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. 416 с.

ПРИЛОЖЕНИЯ

Приложение А Выходные документы

Страховой полис

Страховой договор