Испытания программного обеспечения в области гидрометеорологии — это документированная проверка программ и программных модулей, которые участвуют в наблюдениях за состоянием окружающей среды, получают данные от технических средств, выполняют расчёты и контроль качества, формируют архивы, передают сведения во внешние системы и создают информационную продукцию. Цель работ — подтвердить характеристики конкретной идентифицированной версии ПО и установить, что её функции, алгоритмы и способы работы с данными соответствуют заявленной документации и выбранным требованиям.
Испытания ПО не заменяют лицензию и не создают её автоматически
Протокол испытаний или добровольный сертификат подтверждают только те характеристики программного обеспечения, которые фактически проверены по согласованной методике. Необходимость лицензии, состав лицензионного дела и достаточность конкретного документа определяются действующим регулированием, заявленными видами работ и решением лицензирующего органа. До начала проекта важно определить, для какой процедуры и в каком качестве будет использоваться результат испытаний.
Что охватывают испытания программного обеспечения в гидрометеорологии
Гидрометеорологическая информационная цепочка обычно включает датчики и средства измерений, контроллеры, каналы связи, программы первичного сбора, расчётные модули, базы данных, средства контроля качества, архивы, интерфейсы операторов и системы предоставления информации потребителям. Ошибка на любом программном уровне может изменить результат наблюдения, нарушить временную привязку, скрыть пропуск данных или сформировать некорректную информационную продукцию.
Поэтому испытания строятся не вокруг общего вопроса «работает ли программа», а вокруг конкретных функций и рисков. Для каждой функции устанавливаются исходные данные, ожидаемое поведение, критерии оценки и доказательства результата. В зависимости от задачи объектом может быть самостоятельное приложение, встроенное ПО технического средства, программно-аппаратный комплекс, отдельный расчётный модуль либо распределённая система наблюдений.
Наблюдение
Получение первичных значений, опрос каналов, синхронизация, диагностика датчиков и регистрация состояния оборудования.
Обработка
Преобразование единиц, фильтрация, усреднение, коррекция, восстановление пропусков, расчёт производных показателей и контроль качества.
Хранение
Запись в базы и архивы, сохранение метаданных, резервное копирование, сроки хранения, восстановление и контроль целостности.
Предоставление данных
Визуализация, отчёты, выгрузки, API, передача в ведомственные и корпоративные системы, формирование информационной продукции.
Почему программное обеспечение критично для достоверности наблюдений
Современный автоматизированный пост может круглосуточно работать без постоянного присутствия оператора. Программа самостоятельно опрашивает каналы, проверяет диапазоны, присваивает метки времени, применяет коэффициенты, формирует сообщения и передаёт результаты. Если алгоритм или конфигурация изменены, итоговые данные могут отличаться даже при неизменном датчике.
Риски связаны не только с ошибкой формулы. На качество информации влияют неверная размерность, смещение часового пояса, несогласованность системного времени, повторная запись пакета, перепутанный канал, устаревший коэффициент, потеря признака качества, незаметная интерполяция, обрыв передачи, ошибочное округление, изменение справочника либо восстановление базы из неполной копии.
Документированная проверка связывает конкретную версию ПО с проверенными функциями и условиями применения. Это создаёт основу для воспроизводимости результатов, управления изменениями и обоснованного использования программного средства в рабочем процессе.
Связь испытаний программного обеспечения с лицензированием гидрометеорологической деятельности
Лицензирование деятельности в области гидрометеорологии и смежных с ней областях регулируется постановлением Правительства Российской Федерации от 16 ноября 2020 года № 1845. Документ распространяется на перечисленные в нём работы, за исключением соответствующей деятельности, выполняемой в ходе инженерных изысканий для подготовки проектной документации, строительства и реконструкции объектов капитального строительства.
Важное изменение регулирования в 2026 году
В более ранней редакции постановления № 1845 среди приложений к заявлению прямо назывались копии документов на программные средства, «аттестованные в установленном порядке». В редакции, действующей с 2 августа 2026 года, эта формулировка исключена из перечня прилагаемых документов. Поэтому испытания или добровольную сертификацию ПО нельзя представлять как универсально обязательное условие получения лицензии только на основании прежнего текста постановления.
Практическая потребность в подтверждении программного обеспечения сохраняется, если она следует из характеристик технического средства, требований к средствам измерений, программы наблюдений, технического задания, договора, внутренней системы качества, требований заказчика или необходимости доказать корректность обработки и передачи данных. Результат испытаний может включаться в лицензионное или техническое досье как обосновывающий документ, однако окончательную оценку его достаточности выполняет заявитель совместно с лицензирующим органом.
Постановление № 1845 неоднократно изменялось и действует до 1 января 2027 года. Перед подачей заявления необходимо проверить актуальную редакцию, состав сведений на Едином портале государственных услуг и разъяснения Росгидромета. Полезные источники: текущая редакция постановления № 1845, раздел лицензирования Росгидромета и официальные разъяснения по оценке соответствия.
Какие виды деятельности относятся к области гидрометеорологии и смежным областям
Постановление № 1845 связывает лицензируемую деятельность не с названием программы, а с выполняемыми работами и получаемой информацией. В их числе наблюдения, сбор, обработка, хранение, предоставление и распространение информации и информационной продукции для определения:
Атмосфера
Метеорологические и авиационные метеорологические характеристики, аэрологические параметры и процессы в атмосфере.
Водная среда
Гидрологические и океанологические характеристики, состояние водных объектов и связанные информационные продукты.
Земная поверхность и агросфера
Агрометеорологические характеристики, состояние почв, условия для сельскохозяйственного производства и природных процессов.
Космическая погода
Гелиогеофизические характеристики, включая параметры околоземного космического пространства.
Химическое загрязнение
Уровни загрязнения атмосферного воздуха, почв и водных объектов, в том числе по гидробиологическим показателям.
Радиоактивное загрязнение
Уровни радиоактивного загрязнения атмосферного воздуха, почв и водных объектов.
Для программного обеспечения это означает необходимость проследить, какие данные оно получает, какие преобразования выполняет, как формируется признак качества и каким образом результат становится частью отчёта, сообщения, архива либо информационной продукции.
Когда требуется испытание или независимая оценка ПО
Испытания целесообразны, когда программное обеспечение:
- управляет автоматизированной станцией, постом наблюдений или программно-аппаратным комплексом;
- получает данные от средств измерений, преобразователей, контроллеров или внешних сервисов;
- выполняет расчётные, статистические, прогностические или классификационные алгоритмы;
- проводит автоматический контроль качества и присваивает флаги достоверности;
- усредняет, фильтрует, интерполирует, корректирует или агрегирует наблюдения;
- формирует архивы, отчёты, бюллетени, предупреждения и информационную продукцию;
- передаёт сведения в ведомственную, корпоративную или государственную информационную систему;
- применяется в составе средства измерений или измерительной системы;
- должно быть принято заказчиком по техническому заданию или внутреннему регламенту;
- изменилось после внедрения: обновлена версия, алгоритм, модель, база данных, интерфейс или аппаратная платформа.
Перед началом работ определяется цель: испытания по договорным требованиям, добровольная сертификация, подготовка доказательств для приёмки, подтверждение версии, проверка расчётного модуля либо оценка ПО в составе метрологической процедуры.
Какие программные средства могут быть объектом испытаний
Автоматизированные станции
ПО метеорологических станций, гидрологических постов, аэрологических комплексов, буёв, морских платформ и автономных пунктов наблюдений.
Экологический мониторинг
Системы контроля загрязнения воздуха, почв и вод, радиационного контроля, лабораторной и полевой регистрации результатов.
Сбор и телеметрия
Программы контроллеров, шлюзов, регистраторов, серверов опроса, брокеров сообщений и каналов передачи данных.
Обработка и контроль качества
Модули фильтрации, усреднения, интерполяции, проверки физических ограничений, сопоставления каналов и присвоения признаков качества.
Расчёты и прогнозы
Расчётные библиотеки, статистические модули, модели распространения загрязнений, прогностические и аналитические системы.
Архивы и информационные системы
Базы наблюдений, электронные архивы, геоинформационные системы, кабинеты пользователей, API и сервисы предоставления данных.
Отчётность и информационная продукция
Программы подготовки таблиц, карт, бюллетеней, предупреждений, протоколов, выгрузок и машиночитаемых наборов.
Встроенное и облачное ПО
Прошивки технических средств, мобильные клиенты, веб-приложения, облачные сервисы и распределённые компоненты при определяемой конфигурации.
Как устанавливаются границы программного объекта
Наименование пользовательской программы редко описывает всю значимую конфигурацию. В состав объекта могут входить прошивки датчиков и контроллеров, драйверы, конфигурационные файлы, базы коэффициентов, справочники станций, библиотеки расчётов, планировщики, сервисы обмена, скрипты обработки, шаблоны отчётов и внешние API.
Для каждого компонента определяется его роль:
- получает ли он первичные данные или метаданные;
- может ли изменить числовой результат или признак качества;
- задаёт ли коэффициенты, единицы, интервалы усреднения и правила округления;
- влияет ли на временную привязку, порядок пакетов или идентификатор пункта наблюдений;
- участвует ли в хранении, восстановлении, передаче и отображении результата;
- может ли его изменение остаться незаметным для пользователя.
Результатом является перечень значимых компонентов с версиями и цифровыми идентификаторами. Для непрерывно обновляемых веб-сервисов дополнительно фиксируются релиз, конфигурация, используемые модели и зависимости, которые определяют проверенное состояние.
Что проверяется при испытаниях программного обеспечения
Состав операций определяется индивидуальной методикой. В общем случае оценка охватывает:
Документацию
Назначение, архитектуру, функции, алгоритмы, интерфейсы, форматы данных, эксплуатацию, идентификацию, защиту и обновление.
Идентификацию
Наименование и номер версии, состав файлов и модулей, контрольные суммы, конфигурации, модели и способ проверки пользователем.
Функции
Сбор, контроль, расчёт, отображение, архивирование, передача и формирование информационной продукции по заявленным сценариям.
Алгоритмы
Формулы, коэффициенты, единицы, условия применения, границы диапазонов, округление, обработку пропусков и контрольные расчёты.
Данные
Структуру записей, метаданные, признаки качества, временную привязку, полноту, целостность и прослеживаемость преобразований.
Интерфейсы
Пользовательские и сервисные интерфейсы, протоколы связи, импорт, экспорт, API, сообщения об ошибках и диагностические функции.
Защиту
Разграничение прав, журналирование, контроль конфигурации, защиту значимых модулей и данных от случайного или несанкционированного изменения.
Надёжность
Реакцию на пропуски, сбои, потерю связи, недоступность хранилища, перезапуск и восстановление после нарушения штатного режима.
Проверка алгоритмов обработки и качества гидрометеорологических данных
Алгоритмы проверяются не только на одном «правильном» примере. Методика должна учитывать область допустимых входных данных, физический смысл величин, режимы работы, точность исходной информации и требования к конечному продукту.
В программу испытаний могут включаться:
- прямое сопоставление с формулами и правилами, указанными в документации;
- независимые контрольные расчёты;
- проверка единиц величин, масштабных коэффициентов и знаков;
- граничные, нулевые, отрицательные и физически невозможные значения;
- пропуски, повторные записи, выбросы и нарушение последовательности данных;
- проверка интервалов усреднения и правил включения наблюдений в выборку;
- проверка фильтрации, интерполяции и восстановления пропущенных значений;
- формирование и сохранение признаков качества;
- повторяемость результата при одинаковом наборе исходных данных;
- проверка статистических и прогностических показателей в пределах заявленной методики.
Если используются модели машинного обучения, дополнительно фиксируются версия модели, набор входных признаков, конфигурация, правила предобработки, показатели качества и границы применимости. Сертификация модели не означает, что все будущие результаты будут безошибочными: подтверждается соответствие проверяемой версии установленным критериям и сценариям.
Метки времени, метаданные и прослеживаемость результата
Для наблюдений важна возможность восстановить происхождение каждой записи. Одного числового значения часто недостаточно: требуется знать пункт наблюдений, канал, время измерения, время приёма, единицу, коэффициент, состояние оборудования, признак качества и версию алгоритма обработки.
При испытаниях могут проверяться:
- источник системного времени и синхронизация компонентов;
- учёт часового пояса и переходов календарного времени;
- монотонность и уникальность меток времени;
- различение времени наблюдения, приёма, обработки и публикации;
- сохранение идентификаторов станции, канала и средства измерений;
- связь исходной записи с обработанным и опубликованным результатом;
- регистрация версии программы, справочника и конфигурации;
- возможность установить автора или автоматический процесс, изменивший данные.
Хранение, архивирование и передача информации
Проверка хранения и передачи направлена не только на отсутствие технической ошибки. Важно подтвердить, что значение и его контекст не теряются при переходе между компонентами.
- Базы данных. Типы полей, точность представления, обязательность метаданных, транзакционность и ограничения целостности.
- Архивы. Правила формирования, сроки хранения, резервное копирование, контроль копий и восстановление.
- Форматы обмена. Кодировка, разделители, единицы, схемы XML/JSON, бинарные протоколы, версии справочников.
- Передача. Подтверждение доставки, повторная отправка, защита от дублей, очередность пакетов и обработка разрыва связи.
- Экспорт и отчётность. Соответствие выгруженных значений базе, корректность округления и полнота служебной информации.
- Восстановление. Сохранение последних подтверждённых данных, повторная синхронизация и документированное поведение после сбоя.
При интеграции с внешней системой граница ответственности фиксируется в методике: какие данные считаются входом, какие — результатом, каким способом подтверждается их неизменность и где сохраняется журнал обмена.
Защита программного обеспечения и данных
Защита рассматривается в объёме, связанном с достоверностью наблюдений и заявленными функциями. Испытания не подменяют обязательную оценку средств защиты информации, если она требуется по законодательству, но позволяют проверить реализованные механизмы конкретного продукта.
В зависимости от архитектуры оцениваются:
- роли оператора, администратора, поверителя, инженера и сервисного специалиста;
- защита коэффициентов, уставок, справочников и правил контроля качества;
- контроль установки и обновления программных модулей;
- журналы входа, изменения конфигурации, удаления и корректировки данных;
- контроль целостности значимых файлов и базы;
- резервное копирование и защита резервных копий;
- защищённость сервисных интерфейсов и удалённого доступа;
- обнаружение и регистрация нештатных действий;
- порядок отзыва доступа и смены учётных данных.
Негативные сценарии, отказоустойчивость и восстановление
Штатная демонстрация не показывает, как система ведёт себя при нарушении входных условий. Поэтому для значимых функций предусматриваются управляемые негативные сценарии:
- потеря одного или нескольких каналов наблюдений;
- значение вне физически допустимого или настроенного диапазона;
- обрыв, задержка или искажение сообщения;
- дублирование пакетов и нарушение их последовательности;
- ошибка идентификатора станции или канала;
- рассинхронизация времени;
- недоступность базы данных, файлового архива или внешней системы;
- заполнение диска или переполнение очереди;
- отключение питания и перезапуск;
- повреждение конфигурационного файла или несовместимость версий;
- попытка изменения защищённого параметра;
- восстановление связи и повторная передача накопленных данных.
Ожидаемая реакция должна быть заранее определена документацией: отклонение значения, присвоение признака качества, переход в ограниченный режим, сохранение необработанных данных, формирование сообщения или остановка публикации. Лаборатория проверяет соответствие фактической реакции установленному требованию, а не назначает поведение произвольно.
Нормативная и методическая основа испытаний
Единственного универсального стандарта, который полностью описывает испытания любого гидрометеорологического ПО, нет. Набор требований формируется из назначения системы, применимого регулирования, документов на технические средства, требований заказчика и характеристик программного продукта.
При применении средств измерений учитываются требования законодательства об обеспечении единства измерений и документы конкретного типа СИ. Для наблюдений, обработки и предоставления информации Росгидромет также указывает на требования, утверждённые приказами Минприроды России от 30 июля 2020 года № 523, № 524 и № 510. Их применимость определяется заявленным видом деятельности и функциями системы.
Какие документы и материалы желательно предоставить
| Группа материалов | Что желательно представить |
|---|---|
| О программном продукте | Наименование, назначение, область применения, разработчик, версия, состав модулей, архитектура и системные требования. |
| О технических средствах | Описание станции, поста, измерительной системы, контроллеров, каналов, средств измерений и внешних интерфейсов. |
| Функциональная документация | Руководства пользователя и администратора, описание функций, экранов, команд, сообщений, журналов и регламентов эксплуатации. |
| Алгоритмы | Формулы, коэффициенты, блок-схемы, единицы, диапазоны, правила усреднения, фильтрации, контроля качества и округления. |
| Данные и обмен | Форматы входных и выходных данных, структуры баз, протоколы связи, API, справочники, примеры файлов и схемы информационных потоков. |
| Идентификация и защита | Номер версии, перечень файлов, контрольные суммы, порядок обновления, роли пользователей, журналы изменений и резервное копирование. |
| Испытательные материалы | Контрольные наборы, ожидаемые результаты, типовые и негативные сценарии, доступ к экземпляру ПО или испытательному стенду. |
| Цель оценки | Техническое задание, договорные требования, внутренний регламент, перечень нормативных документов и требуемый вид выходного документа. |
Если комплект неполный, работа может начинаться с предварительного аудита. По его результатам формируется перечень недостающих сведений и предлагается структура методики. Исходный код не требуется автоматически для каждого проекта; вопрос решается по сложности алгоритмов и достаточности иных доказательств.
Порядок проведения работ
- Предварительное обращение. Заказчик направляет описание ПО, технических средств, области применения и требуемого результата.
- Определение цели. Уточняется связь с лицензированием, приёмкой, добровольной сертификацией, метрологической процедурой или требованиями договора.
- Установление границ объекта. Формируется перечень значимых программ, модулей, конфигураций, моделей, справочников и внешних систем.
- Анализ документов. Проверяется достаточность описания функций, алгоритмов, данных, интерфейсов, защиты и эксплуатации.
- Выбор требований. Определяются применимые нормативные, технические и договорные положения и критерии результата.
- Оформление договора. Согласуются объём, сроки, стоимость, место работ, испытательный стенд и условия конфиденциальности.
- Разработка методики. Описываются сценарии, исходные данные, контрольные расчёты, средства регистрации и критерии оценки.
- Идентификация версии. Фиксируются состав, версии, конфигурации и цифровые идентификаторы значимых компонентов.
- Проведение испытаний. Выполняются функциональные, расчётные, интерфейсные, защитные, негативные и восстановительные проверки.
- Анализ результатов. Сопоставляются фактические данные и критерии, документируются замечания и несоответствия.
- Оформление документов. Подготавливаются протокол и иные материалы в соответствии с договором и выбранной процедурой.
Какие документы получает заказчик
В зависимости от цели работ комплект может включать:
- программу или методику испытаний;
- протокол испытаний программного обеспечения;
- перечень версий, модулей, конфигураций и контрольных сумм;
- таблицу применимых требований и выполненных проверок;
- результаты контрольных расчётов и наборы тестовых данных;
- перечень выявленных замечаний и рекомендации по их устранению;
- заключение по результатам анализа документации;
- сертификат соответствия и приложение — при проведении добровольной сертификации в СДС ПО СИ;
- материалы для внутренней приёмки, технического досье, сопровождения лицензирования или взаимодействия с заказчиком.
Если оформляется добровольный сертификат, сведения о программном продукте размещаются в открытом реестре сертификатов. Объём подтверждённых характеристик определяется сертификатом, приложением, перечнем версий и протоколом.
Как выбрать форму подтверждения программного обеспечения
| Форма работ | Когда применяется | Результат |
|---|---|---|
| Испытания по согласованной методике | Нужно подтвердить конкретные функции, алгоритмы, интерфейсы, данные или требования технического задания. | Методика и протокол с результатами проверок. |
| Добровольная сертификация | Требуется независимый сертификат на программный продукт или программно-аппаратный комплекс. | Сертификат, приложение, перечень версий и запись в реестре СДС ПО СИ. |
| Проверка ПО в составе средства измерений | ПО влияет на метрологические характеристики СИ, применяемого в сфере государственного регулирования. | Материалы испытаний в целях утверждения типа или иной установленной метрологической процедуры. |
| Приёмочные испытания | Заказчик принимает систему по техническому заданию, контракту или внутреннему регламенту. | Протокол, акт или заключение в согласованной форме. |
| Лицензирование | Организация заявляет лицензируемые виды гидрометеорологических работ. | Лицензию предоставляет Росгидромет; документы на ПО могут входить в обоснование, но не заменяют решение лицензирующего органа. |
Изменение версии, алгоритмов и конфигурации ПО
Результаты испытаний относятся к идентифицированному состоянию. После обновления необходимо определить, затронуты ли:
- алгоритмы расчёта, фильтрации, контроля качества или прогнозирования;
- коэффициенты, справочники, единицы и диапазоны;
- структуры баз данных и форматы обмена;
- синхронизация времени и метаданные;
- интерфейсы связи и внешние API;
- права доступа, журналы, защита и резервное копирование;
- операционная система, контроллер, сервер или облачная инфраструктура;
- версия модели машинного обучения и правила подготовки данных.
По результатам анализа влияния выбирается объём повторной оценки: документальное подтверждение неизменности значимых функций, выборочные регрессионные проверки, дополнительные испытания либо сертификация новой версии. Само изменение номера сборки не всегда требует полного повторения работ, но решение должно быть обосновано и зафиксировано.
Частые вопросы
Обязательна ли сертификация ПО для получения лицензии Росгидромета?
Нельзя утверждать это универсально. В редакции постановления № 1845, действующей с 2 августа 2026 года, прежняя формулировка о копиях документов на аттестованные программные средства исключена из перечня приложений. Необходимость конкретного документа определяется актуальными требованиями, видом деятельности, техническими средствами и позицией лицензирующего органа.
Чем испытания отличаются от добровольной сертификации?
Испытания подтверждают результаты проверок по методике и завершаются протоколом. Добровольная сертификация включает испытания, экспертизу материалов и решение органа по сертификации с выдачей сертификата и внесением сведений в реестр.
Можно ли проверить только расчётный модуль?
Да, если его границы, входные и выходные данные, версия, зависимости и критерии оценки определены однозначно. В протоколе будет указано, что вывод относится именно к этому модулю, а не ко всей информационной системе.
Нужно ли предоставлять исходный код?
Обычно проверку можно провести по документации, исполняемой версии, контрольным данным и наблюдаемым результатам. Код или его фрагменты могут потребоваться, если значимый алгоритм, скрытое преобразование или механизм защиты нельзя подтвердить иным способом.
Можно ли проводить испытания удалённо?
Да, когда удалённый доступ позволяет контролировать конфигурацию, задавать исходные данные, наблюдать результат и сохранять доказательства. Проверка встроенного ПО или реальных измерительных каналов может потребовать стенда или выезда.
Как испытывается облачный сервис?
Фиксируются релиз, конфигурация, зависимости, используемые модели, интерфейсы и среда развёртывания. Необходимо обеспечить воспроизводимое тестовое состояние и документированный порядок управления обновлениями.
Что делать при неполной программной документации?
Можно начать с предварительного аудита. Лаборатория сопоставит имеющиеся документы с архитектурой и функциями и сформирует перечень недостающих описаний, контрольных примеров и идентификационных сведений.
Можно ли использовать протокол для лицензионного дела?
Протокол может использоваться как документ, подтверждающий проверенные характеристики ПО. Решение о его необходимости и достаточности в конкретном лицензионном деле принимает заявитель совместно с Росгидрометом; лаборатория не гарантирует предоставление лицензии.
Как проверяется программное обеспечение с машинным обучением?
Фиксируются версия модели, входные признаки, конфигурация, данные и метрики. Методика задаёт проверяемые сценарии и границы применимости. Результат относится к испытанному состоянию и не является безусловной гарантией любых будущих прогнозов.
От чего зависят сроки и стоимость?
От числа программных компонентов, сложности алгоритмов, количества каналов и форматов данных, полноты документации, необходимости стенда, разработки методики, негативных сценариев и выбранного вида выходных документов. Оценка формируется после предварительного анализа.
Как начать работу
Для предварительной оценки направьте краткое описание программного обеспечения, сведения о технических средствах или системе наблюдений, номер версии, назначение, перечень основных функций, имеющуюся документацию и цель получения результата.
Желательно отдельно указать:
- для какой деятельности или проекта применяется ПО;
- связана ли задача с лицензированием, приёмкой, утверждением типа или добровольной сертификацией;
- какие данные программа получает и какой результат формирует;
- где доступен экземпляр ПО или испытательный стенд;
- какие сроки и форма выходного документа требуются.
После анализа материалов специалисты лаборатории определят границы объекта, возможный состав проверок, недостающие документы, формат проведения испытаний и порядок дальнейшего взаимодействия.
Материал актуализирован 4 сентября 2026 г..
Направьте назначение, версию и имеющуюся документацию. Специалисты лаборатории определят возможный состав работ, перечень исходных материалов и порядок дальнейшего взаимодействия.
Обсудить задачу