52
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности
использования системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения:
• Полноценное тестирование и дополнение во время разработки
системы;
• Описание и занесение в документы всех технических условий
и их согласование.
Выводы:
Во второй главе выпускной квалификационной работы рассмотрены
существующие системы автоматизации работы с клиентами, определены
их особенности, а также достоинства и недостатки для использования
менеджером кинологического приемника. На основании ранее
сформулированных требований к разрабатываемой системе выбраны
средства разработки, в том числе язык программирования и система
управления базами данных, которыми в результате сравнения стали СУБД
MySQL и язык программирования Delphi 7. В процесс разработки
информационной системы возможны различные риски, которые подробно
описаны во второй главе выпускной квалификационной работы, а также
пути их минимизации.
53
3 ГЛАВА 3. РАЗРАБОТКА РЕКОМЕНДАЦИЙ ДЛЯ
АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА
МЕНЕДЖЕРА КИНОЛОГИЧЕСКОГО ПРИЕМНИКА
3.1 Характеристика входной и выходной информации
Опишем наиболее важные вопросы создания ИС и выбора СУБД, от
корректного выбора которых зависит успех всего проекта.
Создание БД. Основным этапом реализации ИС выступает этап
создания БД, целями которой будут:
• Описание данных и связей между ними, необходимых для
областей внедрения рассматриваемой системы и любых групп ее
пользователей;
• Подготовка модели данных, которая сможет поддержать
реализацию любых важных транзакций, связанных с анализом данных;
• Реализация предварительного варианта проекта, модель
которого будет отвечать всем требованиям, предъявляемым к скорости
функционирования системы.
Имеется 2 базовых подхода к созданию БД: снизу-вверх и сверху
вниз. Метод снизу-вверх отлично подойдет для создания простых БД с
небольшим числом атрибутов. Использование такого подхода
неприемлемо при создании БД с множеством атрибутов, реализовать среди
которых все доступные функциональные зависимости проблематично. При
создании сложных систем БД лучше всего применять подход сверху вниз,
который хорошо себя показывает в концепции модели «сущность-связь».
Тогда проект идет от выявления сущностей и связей между ними, которые
играют большую роль в процессе создания.
Весь процесс создания БД делят на 3 стадии: концепция, логическая
модель и прототип. Любая фаза состоит в реализации некой модели
данных, которая станет источником данных для следующей фазы. Основу
в этом процессе составляет концепция, реализуемая в рамках параметров,
54
указанных в спецификации требований пользователя. Подготовка
концепции БД не связана с такими нюансами реализации, как тип
применяемой целевой СУБД, тип используемой вычислительной
платформы и т.п., но уровень такой модели становится основополагающим
фактором, позволяющим минимизировать трудозатраты на реализацию
системы, ее скорость работы и последующий успех. Опыт создания и
внедрения ИС говорит о том, что ошибки, случающиеся на этом этапе,
выявить трудно и трудно устранить, поскольку проявляются они чаще
всего уже на следующих этапах создания системы – при разработке или
эксплуатации.
На этапе создания логической модели сама концептуальная модель
данных переходит в логическую модель, создаваемую в рамках модели
хранения данных исходной СУБД. Проще говоря, этот этап отражает,
какая СУБД используется в качестве целевой - иерархическая,
реляционная, сетевая или объектно-ориентированная. В данном этапе
убираются все остальные аспекты начальной СУБД – к примеру,
некоторые нюансы физической организации хранения данных. Логическая
модель, отражающая разницу представления о реализуемой системе
некоторых типов пользователей, переходит в глобальную логическую
модель. Имеются 2 базовых подхода для создания такой логической
модели данных: метод интеграции представлений или централизованный
метод. Если создается крупная ИС, лучше всего выбрать 1 подход, когда
глобальная логическая модель реализуется методом соединения
нескольких моделей, отражающих представления разных групп
пользователей.
В рамках создания физической модели принимаются решения о
методике реализации создаваемой БД. Поэтому реализация физической
модели связана с конкретной СУБД. Между логической и физической
моделью есть постоянная обратная связь, т.к. все решения, внедренные в
процессе построения физической модели для повышения эффективности
55
системы, также влияют на состояние логической модели. Основная цель
проектирования БД - выделение способа физической реализации
логической модели БД.
В качестве самой модели ИС подготовим ER-диаграмму
используемой БД.
В разрабатываемой ИС необходимо учесть следующие сущности с
реквизитами:
вид_регистрации;
должность;
животное;
заявка;
порода;
сообщение;
сотрудник;
статус_животного;
статус_заявки;
тип_пользователя;
услуга;
услуги_заявки.
Информационная модель представлена на рисунке 10.
Рисунок 10 Информационная модель системы
В информационной модели приведены следующие связи:
Между Заявка и Услуга связь «Один ко многим», так как одна заявка
может содержать несколько услуг;
Между Заявка и Статус заявки и Клиент связь «Один ко многим»,
так как одна заявка может содержать несколько статусов;
Между Животное и Вид регистрации и Склад связь «Один к
одному», так как одно Животное может быть только один раз
зарегистрированным;
Между Животное и Порода связь «Один ко многим», так как один
Порода может принадлежать множеству животных;
Между Заявка и Пользователь связь «Один ко многим», так как
одним пользователем может быть оформлено множество заявок;
Между Пользователь и Сообщение связь «Один ко многим», так как
пользователю может принадлежать множество сообщений.
3.2 Программное обеспечение задачи и характеристика базы
данных
Процедура создания БД включает в себя 3 фазы: создание
концепции, построение логической модели и физическое проектирование.
Каждая фаза включает разработку модели данных, которая становится
источником информации для следующей фазы. Основное значение в этом
процессе отдано концептуальной модели, базирующейся на основных
параметрах, указанных в спецификации требований пользователей.
Создание концепции БД не связано с такими тонкостями разработки, как
тип применяемой целевой СУБД, используемая вычислительная
платформа и т.п., но качество концептуальной модели тут выступает
основополагающим фактором, позволяющим отразить трудозатраты на
создание системы, ее скорость работы и текущий успех. Опыт создание и
внедрения ИС говорит, что ошибки, которые случаются на данном этапе,
58
одни из самых трудно выявляемых и трудно устраняемых, поскольку
встречаются они уже на следующих этапах создание системы – в процессе
кодирования или использования.
В рамках создания логической модели сама концепция данных
переходит в логическую модель, созданную в рамках выбранной модели
хранения размещения основной СУБД. Иначе говоря, этот этап отражает,
какая СУБД станет основной - сетевая, реляционная, иерархическая или
объектно-ориентированная. Также тут пропускаются все другие нюансы
основной СУБД - например, некие особенности физической реализации
хранения данных. Логическая модель, отражающая нюансы представлений
по реализуемой системе разных типов пользователей, переход в
логическую модель данных. Встречаются 2 типа разработки совокупной
логической модели данных: метод внедрения представлений и
централизованный метод. Если создается объемная ИС, лучше всего
применять подход второй, когда глобальная логическая модель данных
реализуется посредством объединения отдельных моделей, отражающих
типы разных групп пользователей.
В процессе финального проектирования выполняются решения о
методиках реализации требуемой БД. Потому физическое проектирование
и связано с конкретной СУБД. Между физическим проектированием и
логической моделью существует постоянная обратная связь, т.к. все
решения, используемые на этапе физического проектирования для
повышения отдачи системы, оказывают влияние и на структуру
логической модели. Основной целью физической разработки БД
становится описание методики физической реализации логического
проекта БД.
Схема базы данных приведена на рисунке 11.
Рисунок 11 Схема базы данных
Характеристика таблиц базы (перечень полей и их типов) данных
приведена в Приложении 1.
Таким образом, созданная база данных позволяет хранить данные
информационной системы , не образуя избыточность.
В разработанной информационной системе предусмотрено три вида
пользователей – администратор, менеджер, клиент. Дерево функций
информационной системы показано на рисунке приложения 2.
Основные функции в системе выполняет менеджер. К таким
функциям относятся регистрация заявок и их обработка, работа со
справочниками (добавление и редактирование информации в них),
формирование отчетных документов. Администратор обладает всеми
функциональными возможностями менеджера, но дополнительно
регистрирует данные о пользователях, а также управляет параметрами
системы.
Сценарии диалога формируются на основании приведенного дерева
функций и приведены на рисунках 12 - 14.
Главное меню
Справочники
Отчеты
Список заявок за период с
разбивкой по видам услуг,
порода
Заявки
Должности
Добавление
Редактирование
Удаление
Просмотр
Печать
Добавление
Редактирование
Удаление
Просмотр
Печать
Поиск
Сообщения
Входящие
Прочитать
Редактировать
Удалить
Исходящи е
Сформировать
Редактировать
Удалить
Формирование
Печать
Экспорт
Список заявок за период
Формирование
Печать
Экспорт
Список клиентов
Формирование
Печать
Экспорт
Список животных
Формирование
Печать
Экспорт
Договор на оказание
услуг (услуги)
Формирование
Печать
Экспорт
Заявка
Формирование
Печать
Экспорт
Отчет по
зарегистрированным
животным за период с
разбивкой по видам
регистрации и породам
Формирование
Печать
Экспорт
Отчет по выбывшим
животным за период с
разбивкой по видам
регистрации и породам
Форми рование
Печать
Экспорт
Отчет по выполненным
заявкам с разбивкой по
услугам за период
Формирование
Печать
Экспорт
Отчет по невыполненным
заявкам с разбивкой по
услугам за период
Формирование
Печать
Экспорт
Отчет по наиболее
популярным породам
Формирование
Печать
Экспорт
Финансовый отчет за
период по оказанным
услугам с разбивкой по
видам услу
Форми рование
Печать
Экспорт
Авторизация
Выход
Клиенты
Добавление
Редактирование
Удаление
Просмотр
Печать
Животные
Добавление
Редактирование
Удаление
Просмотр
Печать
Животные
Виды
регистрации
Статусы
Добавление
Редактирование
Удаление
Просмотр
Печать
Добавление
Редактирование
Удаление
Просмотр
Печать
Породы
Добавление
Редактирование
Удаление
Просмотр
Печать
Заявки
Статус заявки
Добавление
Редактирование
Удаление
Просмотр
Печать
Услуги
Добавление
Редактирование
Удаление
Просмотр
Печать
Пользователи
Типы
пользователей
Добавление
Редактирование
Удаление
Просмотр
Печать
Пользователи
Добавление
Редактирование
Удаление
Просмотр
Печать
Рисунок 12 Сценарий диалога администратора