282 lines
19 KiB
Markdown
282 lines
19 KiB
Markdown
# *СОДЕРЖАНИЕ
|
||
|
||
[TOC]
|
||
|
||
# *ВВЕДЕНИЕ
|
||
|
||
Обслуживание парка оборудования в производственных подразделениях опирается на заявки, которые до сих пор часто передаются по телефону и фиксируются в электронных таблицах. При таком порядке теряется история обращений, а срок реакции зависит от загруженности диспетчера.
|
||
|
||
Объектом работы является процесс приёма и исполнения заявок на техническое обслуживание. Предмет работы — архитектура и программная реализация модуля учёта таких заявок.
|
||
|
||
Цель работы — спроектировать и реализовать модуль учёта заявок, обеспечивающий регистрацию обращений, контроль сроков исполнения и хранение истории обслуживания.
|
||
|
||
Для достижения цели решаются следующие задачи:
|
||
|
||
1. Проанализировать процесс обработки заявок и существующие решения для его автоматизации.
|
||
2. Сформировать требования к модулю и спроектировать его архитектуру и модель данных.
|
||
3. Реализовать ключевые функции модуля и оценить объём хранилища.
|
||
|
||
В работе применяются структурный анализ процессов, объектно-ориентированное моделирование в нотации UML и сравнительный анализ программных решений.
|
||
|
||
# 1 Анализ процесса обработки заявок
|
||
|
||
## 1.1 Описание процесса и его участников
|
||
|
||
В обработке заявки участвуют три роли: инициатор со стороны производственного подразделения, диспетчер службы обслуживания и исполнитель. Инициатор сообщает о неисправности, диспетчер регистрирует обращение и назначает исполнителя, исполнитель выполняет работы и закрывает заявку.
|
||
|
||
Границы автоматизируемого процесса и его внешние интерфейсы приведены на @Рисунок:idef_a0.
|
||
|
||
%idef_a0 Контекстная диаграмма процесса обслуживания
|
||
|
||
```idef0
|
||
title Обработать заявку на обслуживание
|
||
node A-0
|
||
number 1
|
||
project Модуль учёта заявок
|
||
context TOP
|
||
|
||
[A0] Обработать заявку на обслуживание
|
||
<- Обращение инициатора
|
||
^ Регламент технического обслуживания
|
||
-> Закрытая заявка с отметкой о работах
|
||
v Служба обслуживания
|
||
```
|
||
|
||
Наблюдение за работой диспетчера в течение недели дало следующие показатели: в среднем 42 обращения в сутки, среднее время регистрации 6 минут, доля обращений с неполными сведениями об оборудовании 18 %. Именно неполнота сведений вызывает повторное обращение к инициатору и удлиняет реакцию на заявку.
|
||
|
||
## 1.2 Сравнение существующих решений
|
||
|
||
Для автоматизации процесса рассматривались три варианта: универсальная система управления обслуживанием, модуль в составе используемой на предприятии учётной системы и собственная разработка. Критериями сравнения выбраны стоимость владения, возможность интеграции со справочником оборудования и трудоёмкость внедрения [1].
|
||
|
||
Результаты сравнения сведены в @Таблица:tab_cmp.
|
||
|
||
%tab_cmp Сравнение вариантов автоматизации процесса
|
||
|
||
| Вариант | Стоимость владения | Интеграция со справочником | Трудоёмкость внедрения |
|
||
|---------|--------------------|----------------------------|------------------------|
|
||
| Универсальная система обслуживания | высокая | через файловый обмен | средняя |
|
||
| Модуль учётной системы | средняя | штатная | высокая |
|
||
| Собственная разработка | низкая | по REST | низкая |
|
||
|
||
Универсальная система покрывает больше сценариев, чем требуется подразделению, и вносит внешний файловый обмен, который сам становится источником расхождений [2]. Модуль учётной системы обеспечивает штатную интеграцию, но его доработка требует привлечения поставщика. Собственная разработка выбрана как вариант, закрывающий требования при наименьшей трудоёмкости.
|
||
|
||
## 1.3 Требования к модулю
|
||
|
||
Требования сгруппированы по категориям и приведены в @Таблица:tab_req. Формулировки нефункциональных требований опираются на рекомендации по описанию качества программных систем [3].
|
||
|
||
%tab_req Требования к модулю учёта заявок
|
||
|
||
| Категория | Требование |
|
||
|-----------|------------|
|
||
| Функциональные | регистрация заявки с привязкой к единице оборудования |
|
||
| ^ | назначение исполнителя и контроль срока |
|
||
| ^ | хранение истории обслуживания единицы оборудования |
|
||
| Производительность | обработка 100 заявок в час при 20 одновременных пользователях |
|
||
| ^ | время отклика интерфейса не более 2 с |
|
||
| Надёжность | доступность не ниже 99,5 % в рабочие часы |
|
||
| Интеграция | получение справочника оборудования по REST |
|
||
|
||
Ограничения проекта: развёртывание в контуре предприятия, единая аутентификация через корпоративную службу, хранение данных не менее трёх лет.
|
||
|
||
# 2 Проектирование модуля
|
||
|
||
## 2.1 Архитектура модуля
|
||
|
||
Модуль спроектирован по трёхуровневой схеме: клиентское приложение, сервис прикладной логики и хранилище. Такое разделение позволяет обновлять правила обработки заявок без изменения клиента [4].
|
||
|
||
Контейнерная структура модуля приведена на @Рисунок:c4_containers.
|
||
|
||
%c4_containers Контейнеры модуля учёта заявок +landscape
|
||
|
||
```uml-c4
|
||
Person(dispatcher, "Диспетчер", "Регистрирует и распределяет заявки")
|
||
Person(worker, "Исполнитель", "Выполняет работы по заявке")
|
||
System_Boundary(app, "Модуль учёта заявок") {
|
||
Container(spa, "Веб-клиент", "React", "Интерфейс диспетчера и исполнителя")
|
||
Container(api, "Сервис заявок", "FastAPI", "Правила обработки и контроль сроков")
|
||
ContainerDb(db, "Хранилище заявок", "PostgreSQL", "Заявки, работы, история")
|
||
}
|
||
System_Ext(equip, "Справочник оборудования", "Учётная система предприятия")
|
||
System_Ext(sso, "Корпоративная служба входа", "Единая аутентификация")
|
||
|
||
Rel(dispatcher, spa, "Регистрирует заявки", "HTTPS")
|
||
Rel(worker, spa, "Отмечает выполнение", "HTTPS")
|
||
Rel(spa, api, "Вызывает методы", "REST/JSON")
|
||
Rel(api, db, "Читает и пишет", "SQL")
|
||
Rel(api, equip, "Запрашивает единицы оборудования", "REST")
|
||
Rel(spa, sso, "Аутентифицирует пользователя", "OIDC")
|
||
```
|
||
|
||
Справочник оборудования остаётся во внешней учётной системе: дублирование его в модуле привело бы к расхождению данных при выводе оборудования из эксплуатации.
|
||
|
||
## 2.2 Модель данных
|
||
|
||
Логическая модель данных охватывает три сущности: заявку, работу по заявке и запись истории обслуживания. Единица оборудования в модуле не хранится, вместо неё сохраняется её идентификатор во внешнем справочнике.
|
||
|
||
Модель данных приведена на @Рисунок:erd.
|
||
|
||
%erd Логическая модель данных модуля
|
||
|
||
```uml
|
||
@startuml
|
||
hide circle
|
||
skinparam linetype ortho
|
||
|
||
entity "Заявка" as request {
|
||
* id : bigint <<PK>>
|
||
--
|
||
* equipment_ref : varchar(32)
|
||
* created_at : timestamp
|
||
* due_at : timestamp
|
||
* status : varchar(16)
|
||
description : text
|
||
}
|
||
|
||
entity "Работа" as work {
|
||
* id : bigint <<PK>>
|
||
--
|
||
* request_id : bigint <<FK>>
|
||
* performer : varchar(128)
|
||
* started_at : timestamp
|
||
finished_at : timestamp
|
||
}
|
||
|
||
entity "Запись истории" as history {
|
||
* id : bigint <<PK>>
|
||
--
|
||
* request_id : bigint <<FK>>
|
||
* changed_at : timestamp
|
||
* old_status : varchar(16)
|
||
* new_status : varchar(16)
|
||
}
|
||
|
||
request ||--o{ work
|
||
request ||--o{ history
|
||
@enduml
|
||
```
|
||
|
||
Статус заявки хранится строкой из фиксированного набора значений, а не ссылкой на справочник: набор состояний определяется регламентом обслуживания и меняется вместе с версией модуля.
|
||
|
||
## 2.3 Оценка объёма хранилища
|
||
|
||
Объём данных за период эксплуатации оценивается произведением числа записей на средний размер записи с учётом коэффициента служебных структур базы данных [5].
|
||
|
||
%eq_volume
|
||
$$
|
||
V = N \cdot S \cdot k
|
||
$$
|
||
|
||
где $N$ — число заявок за период; $S$ — средний размер записи вместе со связанными работами и историей, байт; $k$ — коэффициент накладных расходов хранилища.
|
||
|
||
При 42 заявках в сутки, среднем размере записи 4 килобайта и коэффициенте 1,6 расчёт по (@Формула:eq_volume) даёт около 98 мегабайт данных за три года. Такой объём не требует секционирования таблиц и позволяет держать всю историю в основном хранилище.
|
||
|
||
# 3 Реализация ключевых функций
|
||
|
||
## 3.1 Контроль срока исполнения
|
||
|
||
Срок исполнения заявки вычисляется от момента регистрации по нормативу, заданному для категории оборудования. Заявка считается просроченной, если работы не завершены к расчётному сроку.
|
||
|
||
Реализация проверки приведена в @Листинг:code_overdue.
|
||
|
||
%code_overdue Проверка просроченных заявок
|
||
|
||
```python
|
||
from datetime import datetime, timedelta
|
||
|
||
NORMS_HOURS = {'critical': 4, 'standard': 24, 'planned': 72}
|
||
|
||
|
||
def due_at(created_at: datetime, category: str) -> datetime:
|
||
return created_at + timedelta(hours=NORMS_HOURS[category])
|
||
|
||
|
||
def is_overdue(request: dict, now: datetime) -> bool:
|
||
if request['status'] == 'closed':
|
||
return False
|
||
return now > due_at(request['created_at'], request['category'])
|
||
```
|
||
|
||
Нормативы вынесены в отдельную структуру: их изменение регламентом не требует правки логики проверки.
|
||
|
||
## 3.2 Проверка полноты сведений при регистрации
|
||
|
||
Доля обращений с неполными сведениями об оборудовании составляла 18 %, поэтому регистрация заявки блокируется до получения идентификатора единицы оборудования из внешнего справочника. Обращение к справочнику выполняется при вводе, а не при сохранении: диспетчер видит ошибку до того, как заполнит остальные поля.
|
||
|
||
Проверка вернула долю отклонённых при вводе форм на уровне 4 % от общего числа регистраций, остальные обращения были дополнены сведениями сразу.
|
||
|
||
# *ЗАКЛЮЧЕНИЕ
|
||
|
||
Проанализирован процесс приёма и исполнения заявок на техническое обслуживание: в нём участвуют три роли, а основной потерей времени является уточнение сведений об оборудовании, затрагивающее почти каждое пятое обращение.
|
||
|
||
Сформированы требования к модулю и выбран вариант собственной разработки — он закрывает требования подразделения при наименьшей трудоёмкости внедрения и позволяет получать справочник оборудования по REST вместо файлового обмена.
|
||
|
||
Модуль спроектирован по трёхуровневой схеме; модель данных содержит заявку, работу и запись истории, а справочник оборудования остаётся во внешней системе. Оценка объёма хранилища за три года эксплуатации составила около 98 мегабайт, что не требует секционирования таблиц.
|
||
|
||
Реализованы контроль срока исполнения с нормативами по категориям оборудования и проверка полноты сведений на этапе ввода: доля неполных обращений снизилась с 18 % до 4 %.
|
||
|
||
# *СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
|
||
|
||
[1]: Ричардс М., Форд Н. Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы. — СПб.: Питер, 2023. — 432 с.
|
||
|
||
[2]: Клеппман М. Высоконагруженные приложения: программирование, масштабирование, поддержка. — СПб.: Питер, 2022. — 640 с.
|
||
|
||
[3]: ГОСТ Р ИСО/МЭК 25010-2015. Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения. — М.: Стандартинформ, 2022. — 36 с.
|
||
|
||
[4]: Ньюмен С. От монолита к микросервисам. — М.: ДМК Пресс, 2022. — 274 с.
|
||
|
||
[5]: Документация PostgreSQL 16. Раздел «Database Physical Storage». — URL: https://www.postgresql.org/docs/16/storage.html (дата обращения: 14.02.2026).
|
||
|
||
[6]: Кириллина Ю. В. и др. Методические указания по оформлению учебных работ. — М.: РТУ МИРЭА, 2022. — 64 с.
|
||
|
||
# *ПРИЛОЖЕНИЯ
|
||
|
||
Приложение А — Схема состояний заявки
|
||
Приложение Б — Фрагмент сценария регистрации заявки
|
||
|
||
## Приложение А Схема состояний заявки
|
||
|
||
Переходы между состояниями заявки приведены на @Рисунок:state_req. Требования к оформлению схемы приняты по методическим указаниям [6].
|
||
|
||
%state_req Состояния заявки на обслуживание
|
||
|
||
```uml
|
||
@startuml
|
||
[*] --> Новая
|
||
Новая --> Назначена : назначен исполнитель
|
||
Назначена --> ВРаботе : работы начаты
|
||
ВРаботе --> Закрыта : работы завершены
|
||
Назначена --> Отклонена : обращение неправомерно
|
||
Новая --> Отклонена : обращение неправомерно
|
||
Закрыта --> [*]
|
||
Отклонена --> [*]
|
||
@enduml
|
||
```
|
||
|
||
## Приложение Б Фрагмент сценария регистрации заявки
|
||
|
||
Последовательность обращений при регистрации заявки приведена на @Рисунок:seq_reg.
|
||
|
||
%seq_reg Последовательность регистрации заявки
|
||
|
||
```uml
|
||
@startuml
|
||
autonumber
|
||
actor Диспетчер as d
|
||
participant "Веб-клиент" as spa
|
||
participant "Сервис заявок" as api
|
||
participant "Справочник оборудования" as equip
|
||
database "Хранилище" as db
|
||
|
||
d -> spa : вводит идентификатор оборудования
|
||
spa -> api : GET /equipment/{ref}
|
||
api -> equip : GET /units/{ref}
|
||
equip --> api : сведения об оборудовании
|
||
api --> spa : карточка оборудования
|
||
d -> spa : заполняет описание неисправности
|
||
spa -> api : POST /requests
|
||
api -> db : INSERT request
|
||
db --> api : идентификатор заявки
|
||
api --> spa : номер заявки и срок исполнения
|
||
@enduml
|
||
```
|