Эволюция проектирования и проекты интернета вещей
Приложение. Проблемные ситуации в разработке гибридных и IoT-систем
Проблемы можно разделить на три фундаментальных уровня, которые часто взаимосвязаны и усугубляют друг друга.
Уровень 1: Продуктово-архитектурный (ЧТО мы делаем?)
Эти проблемы возникают из-за ошибок в концепции, архитектуре и проектировании самого продукта, когда не учитывается синергия и противоречия между его физической и программной частями.
1. Антипаттерн: "Раздельная разработка компонентов"
- Суть: Аппаратная и программная части разрабатываются изолированно, как два независимых продукта.
- Типичные сценарии:«Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.«Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.
- «Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.
- «Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.
2. Антипаттерн: "Неправильная абстракция реальности"
- Суть: Использование моделей (макетов, эмуляторов, симуляторов), которые недостаточно точно отражают поведение системы в реальных условиях.
- Типичные сценарии:«Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.
- «Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.
3. Антипаттерн: "Нежизнеспособная архитектура системы"
- Суть: Продукт проектируется без учёта его места в более крупной экосистеме и реального жизненного цикла.
- Типичные сценарии:«Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.«Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.«Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.
- «Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.
- «Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.
- «Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.
Уровень 2: Процессуально-организационный (КАК мы работаем?)
Эти проблемы связаны с неэффективной организацией команд, процессов их взаимодействия и управления проектом.
1. Антипаттерн: "Водопадный разрыв между командами"
- Суть: Команды работают последовательно, передавая друг другу "результат" по принципу эстафеты. Это самая частая причина сбоев.
- Типичные сценарии:«Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.«Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".
- «Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.
- «Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".
2. Антипаттерн: "Организационный silo (Изолированные команды)"
- Суть: Команды работают в своих "башнях из слоновой кости", со своими целями, терминологией и процессами.
- Типичные сценарии:«Переводческий хаос»: Менеджер тратит всё время на "перевод" требований между командами, что приводит к искажениям.«Модульный разрыв»: Каждая команда оптимизирует свой модуль, но при интеграции они не стыкуются.«Изолированная экспертиза по вещам»: Эксперт предметной области (нефтяник, агроном) и IT-команда не понимают ограничений и возможностей друг друга.
- «Переводческий хаос»: Менеджер тратит всё время на "перевод" требований между командами, что приводит к искажениям.
- «Модульный разрыв»: Каждая команда оптимизирует свой модуль, но при интеграции они не стыкуются.
- «Изолированная экспертиза по вещам»: Эксперт предметной области (нефтяник, агроном) и IT-команда не понимают ограничений и возможностей друг друга.
3. Антипаттерн: "Методологический конфликт"
- Суть: Конфликт культур и подходов к разработке. "Железные" инженеры часто работают по классическим каскадным моделям (V-model), а программисты — по гибким (Agile).
- Типичные сценарии:«Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.«Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.
- «Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.
- «Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.
4. Антипаттерн: "Дисбаланс экспертиз"
- Суть: Одна из дисциплин (механика, электроника, программирование) доминирует над другими, навязывая свои ограничения как догму.
- Типичные сценарии:«Доминирование одной экспертизы»: Либо инженеры диктуют "незыблемые" рамки, в которые программисты не могут уложиться, либо программисты требуют от инженеров невозможного.«Доминирование IT-логики»: Архитектор из IT-мира проектирует систему, игнорируя физические и экономические ограничения "железного" мира.
- «Доминирование одной экспертизы»: Либо инженеры диктуют "незыблемые" рамки, в которые программисты не могут уложиться, либо программисты требуют от инженеров невозможного.
- «Доминирование IT-логики»: Архитектор из IT-мира проектирует систему, игнорируя физические и экономические ограничения "железного" мира.
Уровень 3: Экосистемный и эксплуатационный (В КАКОМ МИРЕ это будет жить?)
Эти проблемы связаны с недооценкой контекста, в котором будет работать система: инфраструктура, пользователи, другие системы и реальные физические условия.
1. Антипаттерн: "Игнорирование физического контекста"
- Суть: Продукт тестируется в "стерильных" лабораторных условиях без учёта реальной среды.
- Типичные сценарии:«Недооценка физических ограничений»: Вибрации, температура, влажность, EM-помехи кардинально меняют поведение системы.«Переоценка возможностей существующей инфраструктуры»: Расчет на идеальный Wi-Fi, стабильное электропитание или широкополосный канал связи, которых нет в реальности.
- «Недооценка физических ограничений»: Вибрации, температура, влажность, EM-помехи кардинально меняют поведение системы.
- «Переоценка возможностей существующей инфраструктуры»: Расчет на идеальный Wi-Fi, стабильное электропитание или широкополосный канал связи, которых нет в реальности.
2. Антипаттерн: "Игнорирование человеческого фактора"
- Суть: Система проектируется для идеального пользователя, который всегда действует по инструкции.
- Типичные сценарии:«Игнорирование эксплуатационного контекста»: Сложный интерфейс, который персонал не хочет или не может использовать, сводя на нет все преимущества системы.
- «Игнорирование эксплуатационного контекста»: Сложный интерфейс, который персонал не хочет или не может использовать, сводя на нет все преимущества системы.
3. Антипаттерн: "Наивная интеграция"
- Суть: Предположение, что стандартов и протоколов достаточно для бесшовного соединения компонентов от разных вендоров.
- Типичные сценарии:«Мультивендорная интеграция без координации»: Компоненты формально совместимы, но из-за тонких различий в реализации система работает неэффективно или нестабильно.«Недооценка сложности данных»: Ожидание "чистых" и стандартизованных данных с датчиков, в то время как реальные данные — зашумленные, неполные и разноформатные.
- «Мультивендорная интеграция без координации»: Компоненты формально совместимы, но из-за тонких различий в реализации система работает неэффективно или нестабильно.
- «Недооценка сложности данных»: Ожидание "чистых" и стандартизованных данных с датчиков, в то время как реальные данные — зашумленные, неполные и разноформатные.
Ключевой вывод
Все эти проблемы проистекают из одной фундаментальной ошибки — попытки управлять трехкомпонентной системой ("Вещь" + "Сеть" + "Данные/Софт") методами, разработанными для систем двухкомпонентных ("Материал" + "Информация" или "Железо" + "Софт").
Успешная разработка гибридных и IoT-систем требует интегрального подхода, где:
- Архитектура с самого начала проектируется как единое целое.
- Процессы и команды тесно интегрированы и синхронизированы.
- Контекст эксплуатации и экосистема являются первичными источниками требований, а не второстепенными факторами.
техпред_мфти