1. Актуальность и постановка проблемы исследования

Скорость и качество обработки заявок абонентов — ключевое конкурентное преимущество сервисных предприятий сферы ЖКХ. Однако значительная часть малого и среднего бизнеса продолжает эксплуатировать устаревшие («legacy») информационные системы на файловых СУБД, что сопряжено с низкой отказоустойчивостью и высокой зависимостью работоспособности от компетенций одного специалиста [1].

Исследование выполнено на примере компании, оказывающей услуги по установке, ремонту и обслуживанию систем контроля доступа в многоквартирных домах (далее — Компания X), информационная инфраструктура которой базировалась на файл-серверной архитектуре и процедурных скриптах. Такая ситуация типична для отрасли: отсутствие веб-доступа исключает оперативное взаимодействие диспетчерской службы и выездного персонала, а отсутствие транзакционного контроля создает риск потери финансовых данных. Актуальность исследования — в необходимости воспроизводимого методического подхода к переходу от подобных систем к многозвенным архитектурам, применимого к широкому классу малых сервисных компаний.

Объект исследования — процессы операционного управления сервисной компанией; предмет — методика проектирования модуля автоматизации, обеспечивающего замену унаследованной системы и безопасную миграцию данных. Цель — разработка и апробация такого подхода, обеспечивающего повышение отказоустойчивости, сокращение времени обработки заявок и целостность данных при миграции.

Исследовательские вопросы:

1. какие потери возникают при обработке заявок в унаследованной инфраструктуре и как их формализовать для проектирования;
2. какая комбинация методов моделирования обеспечивает переход к многозвенной архитектуре без потери исторических данных;
3. как верифицировать эффективность подхода на практике.

2. Методология исследования

Использован комплексный методологический подход, сочетающий структурный анализ бизнес-процессов (нотация BPMN) — для формализации жизненного цикла заявки и выявления узких мест процесса, — и архитектурное моделирование. Для проектирования архитектуры выбрана комбинация C4 Model [2] и UML (ISO/IEC 19505) [3]: совместное применение этих методов позволяет строить иерархию моделей разной степени детализации (от системного контекста до компонентов), избегая перегруженности диаграмм и неоднозначности трактовки решений.

Структура хранения данных проектировалась методом «сущность–связь» в нотации Crow's Foot с нормализацией до третьей нормальной формы [4], что устраняет дублирование и аномалии обновления, характерные для исходной файловой структуры. Для безопасного переноса исторических данных применен подход ETL (Extract, Transform, Load) — стандартный метод миграции между разнородными по структуре и кодировке источниками.

Формализация требований опиралась на ГОСТ 19.201–78 [5], обеспечивающий полноту и однозначность их описания. Верификация результатов проектирования проводилась посредством модульного тестирования по паттерну AAA (Arrange — Act — Assert) [6], интеграционного тестирования API и сквозного (end-to-end) тестирования.

3. Организация исследования: анализ предметной области

На первом этапе выполнен анализ бизнес-процессов Компании X с выделением трех контуров: коммерческого, операционно-технического и финансового. Формализация жизненного цикла заявки показала, что наиболее критичное узкое место — разрыв между регистрацией заявки диспетчером и её передачей мастеру: распределение заявок происходило пакетно, а не в реальном времени, вызывая задержку реакции на инциденты.

На втором этапе проведен сравнительный анализ универсальной CRM-платформы и специализированного отраслевого решения по пяти критериям (табл. 1).

Таблица 1

Сравнительный анализ подходов к автоматизации операционных процессов сервисной компании

Анализ показал: универсальные CRM ориентированы на модель «сделка/лид», плохо адаптируемую к иерархии объектов обслуживания; отраслевые решения избыточны либо экономически нецелесообразны; инструментов контролируемой миграции исторических данных не предоставляет ни одно из решений. Это подтвердило целесообразность разработки собственного модуля как объекта апробации методики. Результаты анализа формализованы в виде требований в соответствии с [5] и легли в основу архитектурного проектирования.

4. Применение методики: проектирование архитектуры и структуры данных

Практическое применение методики выполнено на примере проектирования модуля для Компании X. Выбрана многозвенная клиент-серверная архитектура, разделяющая интерфейс, бизнес-логику и хранение данных. Проектирование велось на трех уровнях нотации C4: контексте (границы системы, пользователи, интеграция с банковской системой и унаследованной БД), контейнерах (веб-приложение, сервер приложений с REST-интерфейсом, сервер БД с ACID-целостностью [9]) и компонентах (рис. 1).

Рис. 1. Архитектура программного модуля на уровне контейнеров (C4 Container, по [2])

Для серверной части выбран шаблон Vertical Slice Architecture [7]: код группируется не по техническому назначению, а по бизнес-сценариям («функциональным срезам»), что, в отличие от традиционной многослойной архитектуры [8], повышает связность кода и снижает риск перегруженных классов. Структура данных спроектирована в 3НФ [4] для устранения избыточности исходной базы; безопасный перенос данных обеспечивает ETL-модуль (извлечение, нормализация и конвертация кодировки, загрузка с восстановлением связей).

Динамика формализована диаграммами последовательностей UML (регистрация и маршрутизация заявки) и диаграммой состояний жизненного цикла заявки («Новая», «Назначена», «В работе», «Выполнена»/«Отменена»). Это устранило влияние человеческого фактора и перевело маршрутизацию в реальное время, отвечая на второй исследовательский вопрос.

5. Апробация и оценка результатов

Апробация методики включала три уровня верификации. Модульное тестирование серверной логики проводилось по паттерну AAA [6] на изолированной базе в памяти: проверялись позитивные (успешное создание сущности) и негативные (отклонение запроса при некорректных данных) случаи; результаты подтвердили корректность алгоритмов на уровне кода.

Интеграционное тестирование API подтвердило корректность обработки некорректных данных (400 Bad Request) и сохранение транзакций (201 Created). Сквозное тестирование, имитирующее действия диспетчера в веб-интерфейсе, подтвердило реактивность интерфейса и целостность связки «клиент — сервер — база данных».

Результаты показывают, что методика — сочетание моделирования C4/UML, нормализованного проектирования данных и ETL-миграции — обеспечивает не только корректность реализации, но и устранение узких мест, выявленных при анализе предметной области: коммуникационного разрыва и рисков целостности финансовых данных.

6. Заключение

Исследование позволило сформулировать и апробировать методический подход к проектированию программного модуля автоматизации операционных процессов сервисной компании при переходе от унаследованной системы к многозвенной архитектуре. Научная новизна — в сочетании структурного анализа процессов, иерархического моделирования C4/UML, нормализованного проектирования данных и ETL-миграции в единую воспроизводимую методику, применимую к широкому классу малых и средних сервисных предприятий с унаследованными системами.

Апробация на примере Компании X подтвердила практическую состоятельность подхода: тестирование на трех уровнях показало корректность решений, а формализация жизненного цикла заявки устранила зависимость процесса от человеческого фактора. Ограничение исследования — апробация на примере одного предприятия, что определяет направление дальнейших исследований: верификацию подхода на выборке компаний со схожей проблематикой.

Литература:

1. Зарипова В. М., Петрова И. Ю. Унаследованные информационные системы. Проблемы и решения // Инженерно-строительный вестник Прикаспия. 2022. № 2 (40).
2. Brown S. The C4 model for visualising software architecture [Электронный ресурс] // URL: https://c4model.com/
3. ISO/IEC 19505–1:2012. Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 1: Infrastructure.
4. Коннолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. / Т. Коннолли, К. Бегг. — 3-е изд. — М.: Вильямс, 2003. — 1436 с.
5. ГОСТ 19.201–78. Техническое задание. Требования к содержанию и оформлению.
6. Хориков В. Принципы юнит-тестирования. — СПб.: Питер, 2021. — 320 с.
7. Bogard J. Vertical Slice Architecture // Jimmy Bogard's Blog. [Электронный ресурс] // URL: https://jimmybogard.com/vertical-slice-architecture/
8. Фаулер М. Архитектура корпоративных программных приложений. — М.: Вильямс, 2006. — 544 с.
9. Костенко И. П., Ступина М. В. Обеспечение требований ACID для высоконагруженных СУБД // Молодой исследователь Дона. 2023. № 3 (42).