- •Аннотация
- •Реферат
- •Оглавление
- •Введение
- •Объект исследования и проектирования
- •Характеристика деятельности организации оао «нэск-электросети»
- •Место и цели существования ремонтной службы оао «нэск-электросети»
- •Сценарий бизнес-процессов организации рассмотрения заявок абонентов об обесточивании в ремонтной службе оао «нэск-электросети»
- •Дискретно-событийная математическая модель процесса устранения обесточивания абонентов
- •Проблемы ремонтной службы оао «нэск-электросети»
- •Постановка цели и задачи дипломной работы
- •2 Оптимизация деятельности ремонтной службы оао «нэск-электросети»
- •Оптимизация математической модели процесса устранения обесточивания абонентов
- •Определение способа реализации оптимизированной математической модели
- •Case-средства моделирования, используемые в работе
- •Оптимизированная модель деятельности ремонтной службы оао нэск-электросети
- •Требования к проектируемой информационной системе ремонтной службы
- •3 Проектирование информационной системы мониторинга доступности ремонтных бригад оао «нэск-электросети»
- •Обзор информационных систем для мониторинга доступности и отправки заданий работникам в рамках ремонтной службы
- •Сравнительный анализ рассмотренных систем
- •Выбор архитектуры информационной системы
- •Проектирование структуры информационной системы мониторинга доступности ремонтных бригад
- •Проектирование модели данных для информационной системы сектора сопровождения отдела управления сетями связи
- •4 Реализация информационной системы мониторинга доступности ремонтных бригад ремонтной службы оао «нэск-электросети»
- •Выбор средств реализации
- •Выбор операционной системы.
- •Выбор субд
- •Выбор системы управления сайтом
- •Алгоритм работы информационной системы мониторинга доступности ремонтных бригад ремонтной службы оао «нэск-электросети»
- •5 Социальный аспект разработки
- •Заключение
Проектирование структуры информационной системы мониторинга доступности ремонтных бригад
Начнем проектирование информационной системы с описания ролей пользователей, которые будут созданы при реализации, и варианты использования системы для этих ролей.
В системе предусмотрены следующие роли:
Администратор. Отвечает за настройки системы, выдачу прав и ролей пользователям, наполнением справочников. Имеет доступ ко всем объектам системы (рисунок 3.2).
Рисунок 3.2 – Варианты использования информационной системы для администратора
Инициатор. Создает новую заявку, имеет доступ на просмотр своих открытых заявок, добавляет комментарии к своим открытым заявкам, а также меняет статус. После создания заявки ее статус становится «Открыта». Инициатор может закрыть свою заявку (рисунок 3.3).
Рисунок 3.3 – Варианты использования информационной системы для инициатора
Диспетчер. Заполняет дополнительные атрибуты заявки: классифицирует заявку, назначает приоритет и крайний срок, назначает исполнителей. После назначения исполнителя статус заявки становится «Назначен исполнитель». Диспетчер может зарыть заявку (рисунок 3.4).
Рисунок 3.4 – Варианты использования информационной системы для диспетчера
Исполнитель. Исполнитель может менять статус заявки на «Выполняется» и «На проверке», вносить комментарии. Получив или отредактировав заявку, исполнитель меняет ее статус на «Выполняется». Выполнив заявку, исполнитель меняет ее статус на «На проверке» (рисунок 3.5).
Рисунок 3.5 – Варианты использования информационной системы для исполнителя
Руководитель. Если у исполнителя есть флаг руководителя, то он может также менять приоритет, крайний срок, а также назначать других исполнителей (рисунок 3.6).
Рисунок 3.6 – Варианты использования информационной системы для руководителя
Следующий шаг – спецификация каждого варианта использования с помощью диаграммы деятельности. Чтобы решить эту задачу для начала обозначим через состояния маршрут прохождения заявки в системе (таблица 3.2).
Таблица 3.2 – Маршрут заявок
Зная все доступные состояния заявки рассмотрим теперь детально наиболее существенные варианты использования информационная система.
Начнем с процесса создания заявки (рисунок 3.7).
Рисунок 3.7 – Создание заявки в системе
Из рисунка видно, что весь процесс заполнения заявки выполняется с помощью системы по строго определенным ею правилам, что устраняет двусмысленность трактовки неисправности и позволяет инициатору наиболее полно описать проблему, даже если он не знает с чего начать.
Следующий процесс – обработка заявки диспетчером (рисунок 3.8)
Рисунок 3.8 – Обработка заявки диспетчером
Рисунок показывает, что у диспетчера остается существенный набор функций, что не лишает его работы и не дает простаивать на рабочем месте.
Следующий важный аспект – то, как обрабатывает заявку с помощью информационной системы руководитель (рисунок 3.9).
Рисунок 3.9 – Обработка заявки руководителем
Основная часть работы также выполняется руководителем с помощью информационной системы, что говорит о целесообразности его внедрения – чем больше функций покрыто реализуемым инструментом, тем он эффективнее с точки зрения использования.
Перейдем к рассмотрению того, как с помощью информационной системы обрабатывает заявку исполнитель (рисунок 3.10).
Рисунок 3.10 – Обработка заявки исполнителем
И последний аспект – то, как может быть обработана заявка по факту ее выполнения исполнителем (рисунок 3.11)
Рисунок 3.11 – Закрытие или возврат заявки на доработку
Вывод: Специфицированные варианты использования, роли и модели работы с заявками в системе позволяют наиболее полно представить программисту видение информационной системы и реализовать все намеченные требования.