Файл: Цель и назначение создания или модернизации модулей или сервисов информационной системы.pdf
Добавлен: 16.05.2023
Просмотров: 608
Скачиваний: 5
СОДЕРЖАНИЕ
1.1 Выбор комплекса задач автоматизации
1.2 Характеристика существующих бизнес –процессов
1.3 Характеристика документооборота, возникающего при решении задачи
2.1 Информационная модель и её описание
2.2 Характеристика нормативно-справочной, входной и оперативной информации
2.3 Характеристика результатной информации
2.4 Общие положения (дерево функций и сценарий диалога)
2.5 Характеристика базы данных
2.6 Структурная схема пакета (дерево вызова процедур и программ)
Рисунок 2.6 - ER-модель разрабатываемой базы данных
Таблица 2.11 - Структура таблицы «History»
|
№ |
Наименование поля |
Идентификатор |
Тип |
Примечание |
|
1. |
Код записи |
idh |
int(11) |
auto_increment |
|
2. |
Код сотрудника |
idsh |
int(4) |
|
|
3. |
Дата и время в систему |
hist |
varchar(30) |
Таблица 2.12 - Структура таблицы «Tip»
|
№ п/п |
Наименование поля |
Идентификатор |
Тип |
Примечание |
|
1) |
Код типа документа |
idtip |
int(11) |
|
|
2) |
Наименование типа документа |
namet |
varchar(10) |
Таблица 2.13 - Структура таблицы «Klient»
|
№ |
Наименование поля |
Идентификатор |
Тип |
Примечание |
|
1. |
Код клиента |
idK |
int(11) |
auto_increment |
|
2. |
фамилия |
forname |
varchar(25) |
|
|
3. |
Имя |
name |
varchar(25) |
|
|
4. |
Отчество |
otch |
varchar(25) |
|
|
5. |
Дата рождения |
dateb |
date |
|
|
6. |
Место рождения |
mesob |
text |
|
|
7. |
Код гражданства |
idstrana |
Int(11) |
|
|
8. |
Код пола |
idpol |
Int(11) |
|
|
9. |
Номер паспорта |
passnom |
varchar(25) |
|
|
10. |
Серия паспорта |
passser |
varchar(6) |
|
|
11. |
Наименование органа, выдавшего паспорт |
passvid |
text |
|
|
12. |
Код подразделения |
passkod |
varchar(25) |
|
|
13. |
Дата выдачи паспорта |
passdate |
varchar(25) |
|
|
14. |
Адрес фактического местожительства |
adressfakt |
text |
|
|
15. |
Место работы |
namerab |
text |
|
|
16. |
Рабочий телефон |
telrab |
varchar(15) |
|
|
17. |
Телефон по мету жительства |
adressfaktTel |
varchar(15) |
|
|
18. |
Дата регистрации |
date |
timestamp |
CURRENT_TIMESTAMP |
|
19. |
Дата выдачи ВУ |
datevu |
date |
Таблица 2.14 - Структура таблицы «Dokument»
|
№ п/п |
Наименование поля |
Идентификатор |
Тип |
Примечание |
|
1. |
Код документа |
idd |
int(11) |
|
|
2. |
Код сотрудника |
ids |
int(5) |
|
|
3. |
Наименование |
named |
varchar(45) |
|
|
4. |
Код типа |
idkd |
int(5) |
|
|
5. |
Дата подготовки |
datepod |
varchar(45) |
|
|
6. |
Дата и время регистрации |
datez |
timestamp |
|
|
7. |
Количество страниц |
kolvostr |
varchar(45) |
|
|
8. |
Примечание |
prim |
varchar(45) |
|
|
9. |
Адресат |
otkuda |
varchar(45) |
|
|
10. |
Ссылка на документ |
link |
text |
|
|
11. |
Статус |
status |
int(1) |
|
|
12. |
Флаг помещения в архив |
archiv |
int(1) |
|
|
13. |
Флаг резолюции начальника отдела |
rnp |
int(1) |
2.6 Структурная схема пакета (дерево вызова процедур и программ)
Состоит система из двух модулей – из БД MySQL, а также приложения для взаимодействия с БД, которое реализовано на языке PHP c использованием HTML.
Осуществляется работа с системой при помощи любого браузера. Необходимо для работы установить локальный сервер в локальной сети страховой компании, где также будет располагаться БД. Осуществляется доступ к базе данных путем набора адреса в адресной строке браузера. Структурная схема пакета изображена на рис. 2.6.
Рисунок 2.6 - Структурная схема пакета
2.7 Описание программных модулей
В соответствии с представленной схемой, структурно пакет содержит следующие модули: модуль авторизации; модуль регистрации (клиентов и документов); модуль работы с документами; модуль работы с архивом; модуль поиска.
На рисунке 2.10 наглядно представлена блок-схема описания данных модулей.
Рисунок 2.10 - Технологическая схема регистрации клиентов и документов системы
2.11 Контрольный пример реализации проекта и его описание
Часть программы, которая расположена на виду у всех, называется интерфейсом пользователя. Отдельные программисты оставляют на потом дизайн интерфейса пользователя и считают подлинным преимуществом приложения его программный код, которому они уделяют большое внимание. Нередко у пользователей появляется недовольство из-за малопонятного содержимого экрана и скорости его прорисовывания, неумело подобранных шрифтов, поэтому к работе над интерфейсом также следует относиться со всей серьезностью. Программного кода пользователь не видит, но интерфейс (плохой или хороший) перед ним всегда.
Формы являются строительными блоками интерфейса пользователя. Отличный дизайн форм представляет нечто большее, чем просто программирование процедур обработки событий и добавление элементов управления.
Формы, которые предназначены для ввода данных являются особым видом форм. Они дают возможность пользователю, не оглядываясь на программиста, идти в необходимом для него темпе. Главное правило и общий смысл: если пользователю необходимо внести 10000 записей в базу данных, естественно ввод каждой записи он подтверждать не хочет.
В форме ввода данных следует максимально использовать свободное пространство, так как закрытие и открытие дополнительных форм значительно замедляет работу. Основное внимание при разработке форм ввода данных требуется уделять скорости их работы.
В ходе проектирования пользовательского интерфейса разработаны макеты экранных форм. Для администраторской части выбрано следующее расположение элементов форм (рисунок 2.11):
- Сверху по центру – заголовок и служебная информация;
- Ниже – меню;
- Еще ниже - основная часть.
Рисунок 2.11 - Макет экранной формы для пользователя
Для корректной работы администратора в системе разработано меню, которое всегда находится в средней части страницы и представляет собой строку с выпадающими списками.
В разрабатываемой систем необходимо применять следующие виды форм:
- форма регистрации сотрудников и тому подобное;
- форма авторизации;
-форма ввода данных;
- форма поиска;
- форма получения результатных данных.
Эскизы форм представлены на рисунках ниже.
Рисунок 2.12 - Эскиз формы регистрации пользователя
Рисунок 2.13 - Эскиз формы авторизации
Рисунок 2.14 - Эскиз формы ввода данных
Рисунок 2.15 - Эскиз формы получения результатной информации
Работа с системой начинается со страницы авторизации.
Рисунок 2.16 – Страница авторизации
После успешной авторизации перед пользователем открывается страница регистрации документа:
Рисунок 2.17 - Страница регистрации документа
Для регистрации документа необходимо заполнить все поля, выбрать файл и нажать кнопку «Загрузить».
Для резолюции документов необходимо выбрать соответствующий пункт меню:
Рисунок 2.18 – Страница резолюции документов
В пункте меню «Документы» доступны списки документов.
Рисунок 2.19 - Списки документов
В архиве приводятся списки документов, находящихся в архиве, с разделением по их типам.
Рисунок 2.20 - Архив
На странице поиска необходимо указать один или несколько признаков документа:
Рисунок 2.21 – Страница поиска
Поиск будет осуществлен в соответствии с ними:
Рисунок 2.22 – Поиск документов
Этими возможностями владеет сотрудник компании. Панель администратора отличается от сотрудника возможностью регистрации пользователей и смены им пароля.
Рисунок 2.23 – Панель администратора
Панель начальника отличается от панели сотрудника возможностью выполнения резолюции документов и контроля выполнения.
Рисунок 2.24 – Панель начальника документооборота
ЗАКЛЮЧЕНИЕ
В данной работе был проведен анализ деятельности страховой компании «Югория». В ходе анализа деятельности были рассмотрены организационно-штатная структура страховой компании, дана характеристика основных бизнес-процессов. Выяснено, что один из основных процессов – документооборот, в настоящее время не автоматизирован и является источником повышенных трудозатрат персонала, а также одной из возможных причин понижения эффективности деятельности ГСК «Югория».
На сегодняшний день применяются две ключевых стратегии автоматизации: подгонка имеющегося программного продукта под бизнес-процессы компании и создание новой автоматизированной системы, оптимизированной под существующие бизнес процессы. Выбор стратегии автоматизации зависит от целей развития компании и ее долгосрочных экономических возможностей.
Для страховой компании «Югория» наиболее подходит вариант с разработкой собственной информационной системы под выделенный в результате анализа деятельности компании бизнес-процесс. Такой вариант не требует значительных денежных затрат, так как СК располагает собственными финансовыми средствами для создания и поддержки созданного программно-аппаратного комплекса.
В ходе проектирования информационной системы были приняты решения по ее информационному, техническому, программному обеспечению. В процессе разработки системы использовались система управления базами данных MySQL и язык программирования PHP.
В результате была разработано автоматизированное рабочее место, позволяющее автоматизировать учет и получение отчетности по документам, используемы в страховой компании.
В результате проектирования были также разработаны информационная модель информационной системы, выделены и описаны применяемые системы кодирования и классификаторы, описана ER-диаграмма базы данных, указаны схемы технологического процесса обработки, сбора и выдачи информации.
Разработанная информационная система является законченной и универсальной. Она может подлежать внедрению в любой организации с аналогичными бизнес-процессами,
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2000. - 848 с.;
2. Гаджинский А.М. Основы логистики: Учеб.пособие/ Инфоpм.-внедpен.центp "Маpкетинг".- М., 2005.- 121, с.: ил., табл.