Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069058
Тема сообщения
Нарушение законодательства по закупкам (Растрата и возможное хищение бюджетных средств!)
Тип сообщения
Замечание к АД
Поставщик
АРУЖАН
Представитель поставщика
КУЛАКОВ БЕЙБИТ МАДАТАЕВИЧ
Дата и время отправки сообщения
2026-09-28 23:05:06
Текст сообщения
ЗАМЕЧАНИЯ
1. Требования к программному обеспечению для интерактивного обучения чрезмерно детализируют внутреннюю архитектуру программного продукта вместо конечного функционального результата.
2. Система должна быть построена по клиент-серверному принципу с трехуровневой моделью, использовать микросервисную или сервис-ориентированную архитектуру. Архитектура является внутренним техническим решением разработчика. Аналогичный образовательный функционал может быть реализован монолитным приложением, контейнерной платформой, serverless-архитектурой либо иным способом.
3. Установлено требование не менее 18 отдельных логических модулей, взаимодействующих посредством API. Количество внутренних модулей не характеризует качество программного обеспечения. Один разработчик может реализовать перечисленные функции в 12 сервисах, другой — в 30, третий — в одном приложении.
4. Просим исключить обязательное количество внутренних модулей и оставить сами пользовательские функции.
5. Обязательность reverse proxy и конкретных алгоритмов распределения входящих запросов также относится к внутренней серверной инфраструктуре разработчика. Необходимый уровень производительности и безопасности может обеспечиваться иными техническими средствами.
6. Требуется масштабирование системы минимум до 1000 одновременно активных соединений. При этом далее серверная конфигурация определяется как минимально необходимая для одновременной работы до 100 пользователей. Просим устранить прямое внутреннее несоответствие расчетной нагрузки.
7. Просим указать фактическое количество пользователей школы, которые планируется подключать одновременно. Необоснованное требование на 1000 активных соединений может искусственно увеличивать стоимость продукта.
8. Ожидаемый результат в виде подготовки интерактивных материалов к уроку не более чем за 15 минут не является объективной характеристикой ПО, так как зависит от квалификации педагога, сложности материала и объема контента.
9. Требование использовать мультимедийные технологии минимум 40% времени урока также зависит исключительно от методики преподавания.
10. Гарантировать вовлечение 100% присутствующих учащихся в соревновательный процесс программный продукт объективно не может. Это организационный, а не программно-технический показатель.
11. По 3D-визуализации установлено, что модель до 100 000 полигонов должна отображаться минимум с 30 FPS. Данный показатель непосредственно зависит от устройства пользователя, браузера, разрешения экрана, графического адаптера, текстур и сложности сцены.
12. Для каждого 3D-объекта регламентировано минимум 10 различных функций взаимодействия, минимум 10 интерактивных точек, текстовые карточки минимум 500 символов и минимум 3 базовых ракурса. Такая детализация описывает структуру конкретной существующей библиотеки 3D-контента.
13. Требование минимум 500 символов текста для карточки интересующей точки не имеет очевидного педагогического обоснования. Полноценное описание конкретного элемента может состоять из 50–200 символов.
14. Продолжительность загружаемых видео жестко ограничена диапазоном 5–15 минут со ссылкой на физиологические нормы удержания внимания. При этом нормативный источник в ТС не указан. Платформа должна технически допускать и короткие, и более длительные учебные материалы.
15. Видеоплеер должен содержать не менее 8 конкретно перечисленных функций. Это фактически регламентация пользовательского интерфейса конкретного решения.
16. Панель рисования должна содержать не менее 10 инструментов, не менее 10 базовых цветов, 16 млн оттенков с вводом HEX, минимум 5 толщин линии и историю минимум из 10 действий. Просим оценивать наличие необходимых инструментов, не фиксируя дизайн и количество элементов конкретного интерфейса.
17. Установлено время рисования линии не более 50 мс. Просим определить методику измерения и тестовую конфигурацию клиентского оборудования.
18. Архитектура игрового модуля также описывается через управляющую master-page и подчиненные страницы игроков, постоянный full-duplex обмен, минимум 8 транзакций и задержку максимум 300 мс.
19. Просим заменить внутреннее описание на конечную возможность проводить интерактивные соревнования и викторины в реальном времени.
20. Подключение ученика по QR-коду должно занимать максимум 5 секунд. На данный показатель влияют модель и камера смартфона, скорость Wi-Fi, загрузка сервера, качество интернета и действия пользователя. Поставщик не может гарантировать фиксированные 5 секунд при любых условиях.
21. Ограничение максимального времени ответа на вопрос пятью минутами также не имеет универсального педагогического основания.
22. Интерфейс должен обеспечивать выполнение базового действия не более чем за три логических перехода. Просим определить методику подсчета переходов либо сделать данное условие рекомендательным.
23. Таким образом, значительная часть требований описывает не функциональный результат, а программную архитектуру, структуру базы контента и UI/UX конкретного продукта. Просим переработать данный раздел с использованием технологически нейтральных требований.
1. Требования к программному обеспечению для интерактивного обучения чрезмерно детализируют внутреннюю архитектуру программного продукта вместо конечного функционального результата.
2. Система должна быть построена по клиент-серверному принципу с трехуровневой моделью, использовать микросервисную или сервис-ориентированную архитектуру. Архитектура является внутренним техническим решением разработчика. Аналогичный образовательный функционал может быть реализован монолитным приложением, контейнерной платформой, serverless-архитектурой либо иным способом.
3. Установлено требование не менее 18 отдельных логических модулей, взаимодействующих посредством API. Количество внутренних модулей не характеризует качество программного обеспечения. Один разработчик может реализовать перечисленные функции в 12 сервисах, другой — в 30, третий — в одном приложении.
4. Просим исключить обязательное количество внутренних модулей и оставить сами пользовательские функции.
5. Обязательность reverse proxy и конкретных алгоритмов распределения входящих запросов также относится к внутренней серверной инфраструктуре разработчика. Необходимый уровень производительности и безопасности может обеспечиваться иными техническими средствами.
6. Требуется масштабирование системы минимум до 1000 одновременно активных соединений. При этом далее серверная конфигурация определяется как минимально необходимая для одновременной работы до 100 пользователей. Просим устранить прямое внутреннее несоответствие расчетной нагрузки.
7. Просим указать фактическое количество пользователей школы, которые планируется подключать одновременно. Необоснованное требование на 1000 активных соединений может искусственно увеличивать стоимость продукта.
8. Ожидаемый результат в виде подготовки интерактивных материалов к уроку не более чем за 15 минут не является объективной характеристикой ПО, так как зависит от квалификации педагога, сложности материала и объема контента.
9. Требование использовать мультимедийные технологии минимум 40% времени урока также зависит исключительно от методики преподавания.
10. Гарантировать вовлечение 100% присутствующих учащихся в соревновательный процесс программный продукт объективно не может. Это организационный, а не программно-технический показатель.
11. По 3D-визуализации установлено, что модель до 100 000 полигонов должна отображаться минимум с 30 FPS. Данный показатель непосредственно зависит от устройства пользователя, браузера, разрешения экрана, графического адаптера, текстур и сложности сцены.
12. Для каждого 3D-объекта регламентировано минимум 10 различных функций взаимодействия, минимум 10 интерактивных точек, текстовые карточки минимум 500 символов и минимум 3 базовых ракурса. Такая детализация описывает структуру конкретной существующей библиотеки 3D-контента.
13. Требование минимум 500 символов текста для карточки интересующей точки не имеет очевидного педагогического обоснования. Полноценное описание конкретного элемента может состоять из 50–200 символов.
14. Продолжительность загружаемых видео жестко ограничена диапазоном 5–15 минут со ссылкой на физиологические нормы удержания внимания. При этом нормативный источник в ТС не указан. Платформа должна технически допускать и короткие, и более длительные учебные материалы.
15. Видеоплеер должен содержать не менее 8 конкретно перечисленных функций. Это фактически регламентация пользовательского интерфейса конкретного решения.
16. Панель рисования должна содержать не менее 10 инструментов, не менее 10 базовых цветов, 16 млн оттенков с вводом HEX, минимум 5 толщин линии и историю минимум из 10 действий. Просим оценивать наличие необходимых инструментов, не фиксируя дизайн и количество элементов конкретного интерфейса.
17. Установлено время рисования линии не более 50 мс. Просим определить методику измерения и тестовую конфигурацию клиентского оборудования.
18. Архитектура игрового модуля также описывается через управляющую master-page и подчиненные страницы игроков, постоянный full-duplex обмен, минимум 8 транзакций и задержку максимум 300 мс.
19. Просим заменить внутреннее описание на конечную возможность проводить интерактивные соревнования и викторины в реальном времени.
20. Подключение ученика по QR-коду должно занимать максимум 5 секунд. На данный показатель влияют модель и камера смартфона, скорость Wi-Fi, загрузка сервера, качество интернета и действия пользователя. Поставщик не может гарантировать фиксированные 5 секунд при любых условиях.
21. Ограничение максимального времени ответа на вопрос пятью минутами также не имеет универсального педагогического основания.
22. Интерфейс должен обеспечивать выполнение базового действия не более чем за три логических перехода. Просим определить методику подсчета переходов либо сделать данное условие рекомендательным.
23. Таким образом, значительная часть требований описывает не функциональный результат, а программную архитектуру, структуру базы контента и UI/UX конкретного продукта. Просим переработать данный раздел с использованием технологически нейтральных требований.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-02 08:38:29
Автор:
КУРМАНБЕКОВА ДАНА ДАУЛЕТХАНОВНА
Решение:
Отклонить замечания
1. Замечание не принимается. Обоснование: В соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках», Заказчик в технической спецификации указывает требуемые функциональные, технические, качественные и эксплуатационные характеристики закупаемых товаров исходя из собственных потребностей и специфики образовательного процесса. Описание архитектурных параметров программного обеспечения обусловлено необходимостью поставки устойчивого, промышленного решения, способного интегрироваться с аппаратным комплексом кабинета, работать в режиме реального времени и обеспечивать безопасность данных учащихся. Требования не содержат ссылок на конкретные товарные знаки, патенты или разработчиков. 2. Замечание не принимается. Обоснование: Трехуровневая клиент-серверная модель и сервисно-ориентированный подход являются базовыми отраслевыми стандартами разработки корпоративных и образовательных платформ. Данная архитектура объективно необходима Заказчику для обеспечения бесперебойного учебного процесса: она позволяет обновлять отдельные учебные модули и 3D-библиотеки без остановки работы всей школьной системы (минимизация простоя до уровня менее 1% в год). Монолитные решения не обеспечивают требуемой отказоустойчивости при пиковых нагрузках сотен параллельных подключений. 3. Замечание не принимается. Обоснование: Перечень из 18 логических модулей определяет функциональную полноту платформы (аутентификация, хранилище, 3D-рендеринг, потоковое видео, сессионный игровой сервер, сбор телеметрии датчиков, криптографическая защита и др.). Требование устанавливает минимально необходимый состав функциональных сервисов, обеспечивающих выполнение утвержденной учебной программы естественнонаучного цикла, и исключает поставку неполноценного программного продукта. 4. Замечание не принимается. Обоснование: Условие «не менее 18 логических модулей» фиксирует модульность и компонентную архитектуру системы. Это исключает риски сбоя всей платформы при отказе одного из сервисов (например, при временной недоступности модуля видеоконтента модуль интерактивного тестирования и 3D-моделирования продолжают штатную работу). 5. Замечание не принимается. Обоснование: Требование о наличии обратного проксирования (reverse proxy) и алгоритмов балансировки нагрузки продиктовано требованиями информационной безопасности государственной организации образования. Данный механизм необходим для терминации защищенных соединений, предотвращения перегрузки серверов и защиты локальной вычислительной сети школы от атак типа «отказ в обслуживании» (DoS/DDoS). 6. Замечание не принимается. Обоснование: В технической спецификации отсутствует противоречие. Обслуживание до 100 пользователей определяет минимальные аппаратные ресурсы локального сервера аудитории для комфортной одновременной работы одного класса, тогда как архитектурный потенциал масштабирования платформы до 1000 активных сетевых соединений (WebSocket/HTTP) заложен для проведения общешкольных олимпиад, срезов знаний, параллельных уроков и родительских сессий без аппаратного коллапса. 7. Замечание не принимается. Обоснование: В общеобразовательной школе контингент учащихся превышает сотни человек. Платформа приобретается на долгосрочный период эксплуатации и должна технически обеспечивать возможность проведения синхронных срезов знаний и общешкольных мероприятий. Требование к масштабируемости до 1000 соединений является стандартной практикой построения масштабируемых веб-систем и не ведет к необоснованному удорожанию. 8. Замечание не принимается. Обоснование: Показатель «снижение времени на подготовку интерактивных материалов до значения не более 15 минут» указан в подразделе «Ожидаемые результаты от внедрения ПО» и определяет эргономическую эффективность программного комплекса. Система должна обладать интуитивным конструктором уроков и готовой библиотекой дидактических материалов, позволяющими учителю быстро формировать сценарий урока без привлечения IT-специалистов. 9. Замечание не принимается. Обоснование: Требование к доле использования мультимедийных технологий (не менее 40% времени урока) заложено в целевых показателях внедрения в соответствии с государственными программами цифровизации образования и методическими стандартами интерактивного обучения. ПО должно предоставлять достаточный объем интерактивных инструментов для удержания фокуса внимания школьников на протяжении занятия. 10. Замечание не принимается. Обоснование: Программный комплекс технически обязан поддерживать одновременное подключение всех находящихся в аудитории учащихся к соревновательной сессии. Требование гарантирует отсутствие программных лимитов на количество одновременных участников викторины внутри учебной группы, обеспечивая равный доступ каждого ученика к образовательному процессу. 11. Замечание не принимается. Обоснование: В технической спецификации прямо закреплено условие: «при условии соответствия клиентского устройства минимальным системным требованиям». Частота кадров не менее 30 FPS при нагрузке до 100 000 полигонов является базовым критерием плавности отображения трехмерной графики (WebGL), предотвращающим визуальные рывки, искажения и повышенную зрительную утомляемость школьников при изучении интерактивных моделей анатомии, физики и химии. 12. Замечание не принимается. Обоснование: Набор функций взаимодействия с 3D-моделями (свободное вращение по осям, зум, изоляция элементов, интерактивные точки интереса, базовые ракурсы) представляет собой стандартный функционал современных открытых 3D-движков образовательного назначения (Three.js, Babylon.js и др.). Требование направлено на обеспечение интерактивного изучения объектов в объеме, а не на описание конкретного проприетарного продукта. 13. Замечание не принимается. Обоснование: Поддержка текстовых поясняющих карточек объемом не менее 500 символов определяет максимальную вместимость информационного поля интерфейса. Данный объем объективно необходим для размещения подробного академического описания анатомических органов, физических процессов или химических реакций. Размещение более кратких текстов (50–200 символов) спецификацией не ограничивается. 14. Замечание не принимается. Обоснование: Диапазон длительности видеофрагментов от 5 до 15 минут основан на санитарно-эпидемиологических требованиях к непрерывной работе учащихся с экранами цифровых устройств, а также на доказанных психолого-педагогических нормах удержания активного внимания детей (концепция микрообучения/microlearning). Демонстрация видеоматериалов свыше 15 минут на уроке недопустима согласно санитарным правилам для школ. 15. Замечание не принимается. Обоснование: Восемь функциональных элементов видеоплеера (пуск/пауза, таймлайн, регулятор громкости с режимом Mute, полноэкранный режим, качество, субтитры, переключение материала, контекстные всплывающие подсказки по таймкодам) являются стандартным базовым набором управления медиаконтентом (HTML5 Video API), критически необходимым педагогу для интерактивного проведения урока. 16. Замечание не принимается. Обоснование: Панель графического аннотирования предназначена для полноценной замены классической меловой доски при работе у интерактивного экрана. Наличие базовых пишущих инструментов, ластика, векторных фигур, палитры HEX и отмены действий — стандартный функционал графических библиотек рисования (Canvas), гарантирующий учителю возможность акцентировать внимание учеников на ключевых деталях контента. 17. Замечание не принимается. Обоснование: Время отклика при рисовании линии не более 50 мс является ключевым эргономическим показателем, исключающим визуальный эффект задержки цифрового следа (ink lag). Соответствие проверяется при приемо-сдаточных испытаниях путем тестового рукописного ввода стилусом на интерактивной панели из комплекта закупки при нормальной нагрузке системы. 18. Замечание не принимается. Обоснование: Архитектура соревновательного модуля с разделением на мастер-панель преподавателя и клиентские интерфейсы учеников на базе протокола WebSocket (полный дуплекс) с задержкой до 300 мс объективно необходима для синхронизации таймеров и мгновенной фиксации ответов. Стандартные протоколы HTTP Polling вызывают неприемлемые задержки, делающие невозможным проведение блиц-викторин и тестов на скорость реакции. 19. Замечание не принимается. Обоснование: Абстрактное указание «возможность соревнований» не гарантирует технической защиты от рассинхронизации результатов, фальсификации данных на стороне клиентов и сбоев при параллельной отправке ответов классом. Технические требования закрепляют необходимые критерии надежности и объективности контроля знаний. 20. Замечание не принимается. Обоснование: В спецификации прямо оговорено: «при наличии стабильного интернет-соединения». Требование регламентирует работу программного алгоритма: генерация зашифрованной временной гиперссылки в QR-коде позволяет учащимся подключаться к сессии мгновенно без утомительного ручного ввода логинов, паролей или длинных кодов, исключая нерациональную потерю времени урока. 21. Замечание не принимается. Обоснование: Спецификация предусматривает гибкую настройку времени ответа преподавателем: «в диапазоне не менее 10 секунд и не более 5 минут на каждый вопрос». Учитель самостоятельно выставляет длительность раунда в зависимости от сложности задания (от 15 секунд на тестовый вопрос до 5 минут на расчетную задачу). Диапазон полностью покрывает все возможные учебные сценарии. 22. Замечание не принимается. Обоснование: Правило «не более трех логических переходов» («правило трех кликов») является общепринятым международным стандартом эргономики пользовательских интерфейсов (ISO 9241-110, принципы UI/UX). Оно гарантирует простоту навигации для учителей с разным уровнем компьютерной грамотности и оперативный доступ к урокам без блуждания по сложным многоуровневым меню. 23. Замечание не принимается. Обоснование: Техническая спецификация сформирована в строгом соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и Правилами осуществления государственных закупок. Характеристики программного обеспечения сформулированы на основе общепринятых открытых отраслевых стандартов (клиент-серверная веб-архитектура, протоколы WebSocket и TLS, WebGL, QR-маршрутизация, Canvas-графика), не содержат указаний на товарные знаки, фирменные наименования, патенты или конкретных правообладателей. Любой добросовестный поставщик и разработчик тиражного образовательного ПО способен поставить программный продукт, отвечающий заявленным функциональным и качественным критериям Заказчика. Оснований для изменения технической спецификации не имеется.
