15
статусов ремонтируемой техники для диспетчера. Техническая архитектура ИС
представлена на рисунке 1.2
Рисунок 1.2 – Схема представления технической архитектуры
Все данные о записях на ремонт или обслуживание, статусы техники при
ремонте или обслуживании хранятся в базе данных. При записи на ремонт или
обслуживание выбирается специализация дата приема, предполагаемая дата
окончания ремонта или обслуживания, потом выбирается доступный механик на
этот период времени.
В качестве устройства подключения к ИС можно использовать переносные
(ноутбук) и стационарные (компьютер).
Возможности диспетчера:
‒ просмотр перечня техники;
‒ просмотр и редактирование перечня техники;
‒ возможность создания записи на обслуживание или ремонт техники.
Возможности механика:
16
‒ просмотр записанной к нему на ремонт/обслуживание техники;
‒ обновление статусов ремонта/обслуживания.
Возможности администратора;
‒ просмотр и редактирование списка механиков и диспетчеров;
‒ развертывание ИС и восстановление базы данных.
В процессе выполнения работ, составляются учетные документы, указанные
в Таблица 1.2.
Таблица 1.2 – Документы, которые составляются в процессе выполнения работ
Название документа
Периодичность
составления
Основная информация в
документе.
Путевой лист
Ежедневно
Водитель, объект, количество
машино-часов, количество
заправленного ГСМ, фамилия
механика и медика,
выпустивших на рейс.
Табель учета
рабочего времени
Ежедневно
Дата, перечень рабочих,
явка/неявка
Реестр работы
спецтехники
Ежемесячно/по
завершению работ
Период, транспорт, количество
отработанных машино-часов.
Реестр питания
Ежемесячно/по
завершению работ
Период, количество питания,
стоимость 1 ед. Сумма
Реестр проживания
Ежемесячно/по
завершению работ
Период, ч/дней проживания,
стоимость 1 суток, сумма
Ведомость прочих
оказанных услуг
Ежедневно
Дата, ФИО сотрудника,
описание услуги, стоимость
Заправочная
ведомость
Ежемесячно/по
завершению работ.
Период, дата, гос.номер, №
путевого листа, Водитель,
марка топлива, заказ л., факт.
Л., заправщик.
17
Ведением учетной документации, которая перечислена в таблице 1.2,
занимается диспетчер, который находится непосредственно на объекте
строительных работ. Так как обычно место проведения работ находится в
значительном удалении от офиса компании, диспетчер привозит документы в
конце каждого месяца.
1.2. Характеристика комплекса задач, задачи и обоснование
необходимости автоматизации
1.2.1. Выбор комплекса задач автоматизации и характеристика
существующих бизнес-процессов
Наиболее подходящим языком моделирования бизнес-процессов является
IDEF0, где система представляется как объединение взаимодействующих работ
или функций. IDEF0-модель описывает: что система делает, что она создает, какие
данные используются для управления, какие ресурсы и методы применяются для
исполнения ее функций.
Одним из преимуществ IDEF0-моделей является то, что они обеспечивают
возможность обмена данными о рассматриваемом объекте на языке, понятном не
только аналитику и разработчику системы, но и специалисту-эксперту в
предметной области, пользователю, руководителю (Д. Росс назвал технику
структурного анализа языком для передачи понимания). В основе метода IDEF0
лежат следующие концептуальные положения:
графическое описание модели в виде иерархии диаграмм, обеспечивающее
наименьшую плотность изображения информации;
наибольшая выразительность, т.е. возможность наиболее предпочтительным
образом обеспечить «понимаемость» модели;
строгость и точность представления;
пошаговые процедуры разработки модели, ее просмотра и объединения;
18
отделение организации от функции исключение влияния организационной
структуры на функциональную модель.
IDEF0-модель создается из диаграмм, которые составлены в иерархическом
порядке и постепенно показывают уровни все более подробных описаний функций
и их интерфейсов в пределах системы. Наивысшая диаграмма модели объединяет
всю рассматриваемую систему. Диаграммы 1-го уровня представляют наиболее
важные подсистемы с их взаимосвязями, а диаграммы последнего уровня
представляют детализированные функции, с помощью которых, собственно, и
работает система.
Можно назвать три основных типа диаграмм, используемых в IDEF0-
моделях: графические, текстовые и глоссарии.
Графические диаграммы главный компо нент модели определяют функции и
функциональные отношения. Эти функции в дальнейшем декомпозируются
(разбиваются) на более детальные диаграммы, пока подсистема не будет описана
на уровне, удовлетворяющем цели проекта.
Текстовые диаграммы и глоссарии (словари) обеспечивают дополнительную
информацию для графических диаграмм. Кроме того, могут использоваться и так
называемые поясняющие диаграммы FEO.
Результатом применения этого метода является модель, которая состоит из
диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
Диаграммы - главные компоненты модели, все функции организации и интерфейсы
на них представлены как блоки и дуги соответственно. Одной из наиболее важных
особенностей метода IDEF0 является постепенное введение все больш их уровней
детализации по мере создания диаграмм, отображающих модель. Модели AS-IS и
ТО-ВЕ. Чаще всего сначала строится модель существующей организации работы –
AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся
наиболее слабые места, в чем будут состоять преимущества новых бизнес-
процессов и насколько глубоким изменениям подвергнется существующая
структура организации бизнеса. Детализация бизнес-процессов позволяет выявить
недостатки организации даже там, где функциональность на первый взгляд кажется
19
очевидной. Найденные в модели AS-IS недостатки можно исправить при создании
модели ТО-ВЕ (как будет) – модели новой организации бизнес-процессов.
Технология проектирования ИС подразумевает сначала создание модели AS-
IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и
только на основе модели ТО-ВЕ строится модель данных, прототип и затем
окончательный вариант ИС.
Иногда текущая AS-IS и будущая ТО-ВЕ модели могут различаться очень
сильно, так что переход от начального к конечному состоянию становится
неочевидным. В этом случае необходима третья модель, описывающая процесс
перехода от начального к конечному состоянию системы, поскольку такой переход
– это тоже бизнес-процесс.
Процесс создания модели системы в IDEF0 начинается с создания
контекстной диаграммы – диаграммы наиболее абстрактного уровня описания
системы в целом, содержащей определение субъекта моделирования, цели и точки
зрения на модель.
Контекстная диаграмма для автоматизированной информационной с истемы
представлена на рисунке 1.3.
20
Рисунок 1.3 – Общая контекстная диаграмма процесса «Постановки техники на
ремонт/обслуживание»
Входными (Input) данными для системы являются:
данные о механике;
данные по авторизации;
данные о технике.
Управляющей (Control) информацией является:
правила заполнения заявок.
Выходной (Output) информацией является:
данные по ремонту.
В качестве ресурса (Mechanism) системы выступает:
механик;
база данных;
диспетчер.
21
Декомпозиция контекстной диаграммы представлена на Рисунок 1.41.4.
Диаграмма бизнес-процесса разделяется на 4 работы:
авторизация;
реестр механиков;
реестр техники;
оформление техники на ремонт.
Рисунок 1.4 – Декомпозиция контекстной диаграммы
Работа «Авторизация» разделяется на 2 работы (рисунок 1.5):
ввод данных;
проверка данных.
22
Рисунок 1.5 – Декомпозиция работы «Авторизация»
Работа «Реестр техники» разделяется на 3 работы (Рисунок 1.1.6):
добавление техники;
изменение техники;
удаление техники.
Рисунок 1.6 – «Контекстная диаграмма работы «Реестр техники»
Работа «Реестр механиков» разделяется на 3 работы (Рисунок 1.1.7):
добавление механика;
изменение механика;
23
удаление механика.
Рисунок 1.7 – «Контекстная диаграмма работы «Реестр механиков»
Работа «Оформление техники на ремонт» разделяется на 5 работ (Рисунок
1.1.8):
выбор механика;
проверка на занятость механика;
выбор техники;
оформление ремонта;
проведение ремонта.
24
Рисунок 1.8 – Контекстная диаграмма работы «Оформление техники на ремонт»
На диаграмме представлены процесс составления маршрута ремонта или
обслуживания техники, входные процессы, передающие информацию о списках
механиков и техники.
Результатом работы процесса выхода является статус ремонтируемой или
обслуживаемой техники.
1.2.2. Определение места проектируемой задачи в комплексе задач и ее
описание
Система является открытой, модульной и неоднородной системой.
Для добавления в систему новых возможностей и функций, обновление
существующих не нуждается в переработке всей системы. Это, с одной стороны,
позволяет значительно быстрее и с наименьшими затратами улучшать. Но, с
другой стороны, возможно привлекать к проектированию и разработке
дополнительных модулей разных заказчиков, что, в какой-то степени, создаѐт
конкурентную среду и возможность специализации разработчиков программного и