Введение:
*Летом 2025 я опубликовала первую версию этого задания. С тех пор утекло много воды и появился FPF, теперь уже в N-ной версии.
Я пересмотрела старый текст, но не остановилась на том, чтобы переделать его с опорой на FPF, а ещё отдельно задала bounded contexts. Причём если по осени при поиске “вещи” первым BC я рассматривала как раз создание самого ПО (его design-time), то сейчас, описывая продукт для внешних ролей, я решила отдельно выделить intent и переход от него к работе уже непосредственно с инструментом. *
В рамках проекта мы создаём программное обеспечение как эпистемическую систему, эксплуатация которой позволяет создать (инстанцировать) целевую физическую систему в реальном мире.
Под инстанцированием понимается переход от описаний и моделей к единственной физической системе, существующей в пространстве и времени, осуществляемый внешними агентами.
Важно сразу зафиксировать:
целевой системой является не ПО и не цифровая модель, а реально установленная и работающая Wi-Fi-сеть на конкретном физическом объекте.
Мы сознательно не используем термины «цифровой двойник» или «цифровая тень»:
ПО не управляет физической системой и не поддерживает её непрерывную синхронизацию.
Результатом работы ПО является описание и модель, а не сама сеть.
Что представляет собой целевая физическая система
Целевая физическая система включает:
- «флот» Wi-Fi точек доступа конкретных моделей и производителей
(вплоть до конкретных экземпляров оборудования), - установленных на конкретном физическом объекте
(склад, завод, медицинское учреждение, школа и т.п.), - с учётом физического распространения радиоволн в пространстве и времени,
- с обслуживанием различных классов клиентских устройств,
- с эксплуатацией сети различными группами пользователей, каждая из которых имеет свои требования и ограничения.
Эта система существует только после физической установки оборудования.
До этого момента существует лишь эпистемическое описание будущей сети.
Три перехода от замысла к работающей Wi-Fi-сети
Создание такой системы происходит не за один шаг, а через три принципиально различных перехода, каждый из которых относится к своему ограниченному контексту.
Смешение этих переходов — одна из ключевых причин недопонимания и ошибок в реальных проектах.
Переход 1. От проектного намерения к эпистемической работе
На первом этапе существует только намерение:
- создать новую или модернизировать существующую Wi-Fi-сеть,
- обеспечить определённый уровень покрытия и характеристик,
- учесть тип объекта, сценарии использования и классы устройств.
На этом этапе нет RF-модели, измерений, физической системы. Есть лишь проектное намерение и понимание того, какими методами будет вестись работа.
Этот переход заключается в выборе и активации методической рамки:
какие измерения проводить, какие модели применять, какие допущения допустимы.
На этом этапе агенты (пользователи ПО или их ассистенты) собирают планы объектов, определяют цели обследований/моделей, возможные жалобы на существующие сети, пожелания и планы на будущую эксплуатацию, какие клиентские устройства и сценарии планируются.
Физический мир на этом этапе не затрагивается.
Переход 2. От эпистемической работы к RF-модели
На втором этапе, во время работы ПО: выполняются измерения, производятся расчёты, строятся RF-модели, формируются визуализации и отчёты, фиксируются допущения и ограничения модели.
Результатом является RF-модель как эпистема — описание того, как Wi-Fi сеть должна или может работать в заданных условиях.
Важно, что на этом этапе все изменения обратимы, модели можно пересчитывать и сравнивать, ошибки не приводят к физическому ущербу.
Этот переход полностью происходит внутри эпистемической области.
Переход 3. От RF-модели к физической Wi-Fi-системе
Третий переход — это инстанцирование физической системы.
Он осуществляется внешними по отношению к ПО агентами: монтажниками, инженерами по установке через физическую установку точек доступа, ориентацию антенн, прокладку кабелей, конфигурацию оборудования.
Именно здесь ресурсы затрачиваются необратимо, ошибки становятся дорогими, модель превращается в единственную конкретную сеть.
ПО не выполняет этот переход, но определяет его качество.
Почему целевая система важна
Сама по себе Wi-Fi-сеть редко является конечной целью. Она является подсистемой более крупных физических и организационных систем:
- на складе — влияет на скорость учёта и перемещения ТМЦ,
- в больнице — на мобильность персонала и доступ к системам,
- на заводе — на стабильность производственных процессов,
- в школе — на доступность цифровых инструментов обучения.
Если Wi-Fi-сеть работает плохо, это проявляется не просто как “плохой Wi-Fi”, а как деградация процессов более высокого уровня, вплоть до экономических потерь.
Что будет, если проект закрыть:
Если разработка и использование нашего ПО прекратятся, то Wi-Fi-сети продолжат устанавливаться. Однако, значительная часть целевых систем будет создаваться без корректного радиопланирования, без учёта ограничений клиентских устройств, без обоснованных ожиданий по характеристикам сети.
В результате будут существовать физические сети, которые формально установлены, но функционально не выполняют свою роль, «висит груша — нельзя скушать». Например, если при наличии очень важного, но старого оборудования, которое поддерживает только 2,4 ГГц, строят новую современную сеть, которая будет работать только а диапазоне 5 ГГц.
Какие проблемы мы уже видим и над чем работаем
Практика эксплуатации и технической поддержки показывает типовые проблемы:
- разрыв между RF-моделью и физической установкой (недостаточная детализация позиционирования и ориентации оборудования),
- недостаточное понимание методики у пользователей, что приводит к некорректному выполнению эпистемической работы,
- неявные ожидания относительно того, что модель «гарантирует» результат (на самом деле нет)
Часть этих проблем уже решается развитием базы знаний, улучшением отчётов и проектных артефактов, более явным описанием ограничений и допущений моделей.