Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069226
Тема сообщения
Нарушения в ТС, требуем рассмотреть
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-10-01 09:14:48
Текст сообщения
1. Раздел программного обеспечения сформирован не только через требуемый образовательный функционал, но и через конкретную внутреннюю программную архитектуру продукта.
2. Установлено, что система должна обязательно использовать клиент-серверный принцип, трехуровневую модель, микросервисную либо сервис-ориентированную архитектуру и включать не менее 18 отдельных логических модулей.
3. Количество внутренних программных модулей не характеризует качество продукта. Один разработчик может реализовать тот же функционал в 10 сервисах, другой — в 18, третий — в 30.
4. Для Заказчика существенным является конечный результат: стабильная авторизация, работа 3D-контента, видеоматериалов, интерактивных заданий, игровых сценариев, аналитики, резервного копирования и информационной безопасности.
5. Обязательность именно 18 модулей является требованием к внутреннему устройству исходного программного продукта и способу разработки, а не к результату эксплуатации.
6. Аналогично ТС предписывает применение reverse proxy и даже конкретные способы распределения запросов между внутренними сервисами. Аналогичные задачи могут решаться посредством API Gateway, cloud load balancer, ingress controller, WAF/CDN и иных технологий.
7. В технической спецификации установлена способность системы обслуживать не менее 1000 одновременных активных соединений. Одновременно аппаратные требования к серверу прямо определены как минимальные для одновременной работы до 100 пользователей.
8. Следовательно, присутствуют два различных показателя расчетной нагрузки — 100 и 1000. Не определено, какой из них должен подтверждаться участником и проверяться при приемке.
9. Необходимо четко определить фактическое количество пользователей школы, количество одновременных подключений и методику нагрузочного испытания.
10. Избыточно детализированы и отдельные пользовательские функции: для каждой 3D-модели требуется не менее 10 интерактивных функций, минимум 10 кликабельных точек, текстовые карточки минимум 500 символов и минимум три фиксированных ракурса.
11. Длина образовательного описания должна определяться содержанием конкретного объекта. Требование не менее 500 символов не является универсальным показателем качества.
12. Видеоматериалы ограничиваются продолжительностью от 5 до 15 минут со ссылкой на физиологические нормы, однако конкретный обязательный нормативный документ не указан.
13. Ограничение не позволяет применять короткие объясняющие ролики продолжительностью 2–4 минуты либо развернутые учебные видео более 15 минут.
14. Наиболее значительные ограничения содержатся в документарной части. Участник обязан предоставить несколько действующих протоколов независимых испытательных лабораторий, аккредитованных NCA РК, включая протокол исследования сетевой инфраструктуры, процессов информационной безопасности, нагрузочных испытаний, SAST исходного кода и испытаний по СТ РК ISO/IEC 15408-2-2017.
15. Непредоставление хотя бы одного из перечисленных документов прямо определено как несоответствие предложения.
16. Для выполнения SAST коммерческого программного продукта разработчику необходимо предоставить лаборатории доступ к исходному коду. Иностранный либо крупный правообладатель может принципиально не передавать исходный код сторонней лаборатории, несмотря на наличие собственных международных аудитов безопасности.
17. Просим допустить эквивалентные способы подтверждения информационной безопасности либо проведение приемочного аудита предлагаемого программного обеспечения.
18. Кроме того, требуется авторизационное письмо с QR-кодом, причем дата письма не может предшествовать публикации текущей закупки. Таким образом, даже действующий долгосрочный дилерский договор или партнерская авторизация могут быть формально недостаточны.
19. Просим переработать требования к ПО через конечные функциональные показатели, исключив обязательное количество внутренних модулей, конкретные архитектурные решения и чрезмерно специфический набор документов конкретного формата.
2. Установлено, что система должна обязательно использовать клиент-серверный принцип, трехуровневую модель, микросервисную либо сервис-ориентированную архитектуру и включать не менее 18 отдельных логических модулей.
3. Количество внутренних программных модулей не характеризует качество продукта. Один разработчик может реализовать тот же функционал в 10 сервисах, другой — в 18, третий — в 30.
4. Для Заказчика существенным является конечный результат: стабильная авторизация, работа 3D-контента, видеоматериалов, интерактивных заданий, игровых сценариев, аналитики, резервного копирования и информационной безопасности.
5. Обязательность именно 18 модулей является требованием к внутреннему устройству исходного программного продукта и способу разработки, а не к результату эксплуатации.
6. Аналогично ТС предписывает применение reverse proxy и даже конкретные способы распределения запросов между внутренними сервисами. Аналогичные задачи могут решаться посредством API Gateway, cloud load balancer, ingress controller, WAF/CDN и иных технологий.
7. В технической спецификации установлена способность системы обслуживать не менее 1000 одновременных активных соединений. Одновременно аппаратные требования к серверу прямо определены как минимальные для одновременной работы до 100 пользователей.
8. Следовательно, присутствуют два различных показателя расчетной нагрузки — 100 и 1000. Не определено, какой из них должен подтверждаться участником и проверяться при приемке.
9. Необходимо четко определить фактическое количество пользователей школы, количество одновременных подключений и методику нагрузочного испытания.
10. Избыточно детализированы и отдельные пользовательские функции: для каждой 3D-модели требуется не менее 10 интерактивных функций, минимум 10 кликабельных точек, текстовые карточки минимум 500 символов и минимум три фиксированных ракурса.
11. Длина образовательного описания должна определяться содержанием конкретного объекта. Требование не менее 500 символов не является универсальным показателем качества.
12. Видеоматериалы ограничиваются продолжительностью от 5 до 15 минут со ссылкой на физиологические нормы, однако конкретный обязательный нормативный документ не указан.
13. Ограничение не позволяет применять короткие объясняющие ролики продолжительностью 2–4 минуты либо развернутые учебные видео более 15 минут.
14. Наиболее значительные ограничения содержатся в документарной части. Участник обязан предоставить несколько действующих протоколов независимых испытательных лабораторий, аккредитованных NCA РК, включая протокол исследования сетевой инфраструктуры, процессов информационной безопасности, нагрузочных испытаний, SAST исходного кода и испытаний по СТ РК ISO/IEC 15408-2-2017.
15. Непредоставление хотя бы одного из перечисленных документов прямо определено как несоответствие предложения.
16. Для выполнения SAST коммерческого программного продукта разработчику необходимо предоставить лаборатории доступ к исходному коду. Иностранный либо крупный правообладатель может принципиально не передавать исходный код сторонней лаборатории, несмотря на наличие собственных международных аудитов безопасности.
17. Просим допустить эквивалентные способы подтверждения информационной безопасности либо проведение приемочного аудита предлагаемого программного обеспечения.
18. Кроме того, требуется авторизационное письмо с QR-кодом, причем дата письма не может предшествовать публикации текущей закупки. Таким образом, даже действующий долгосрочный дилерский договор или партнерская авторизация могут быть формально недостаточны.
19. Просим переработать требования к ПО через конечные функциональные показатели, исключив обязательное количество внутренних модулей, конкретные архитектурные решения и чрезмерно специфический набор документов конкретного формата.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-02 16:52:55
Автор:
ТӨРЕХАНОВ НҰРДӘУЛЕТ МУХТАРҰЛЫ
Решение:
Внести изменения и (или) дополнения в проект аукционной документации
1. Замечание не принимается. Обоснование: В соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках», Заказчик в технической спецификации указывает требуемые функциональные, технические, качественные и эксплуатационные характеристики закупаемых товаров исходя из собственных потребностей и специфики образовательного процесса. Архитектурные требования к программному обеспечению направлены на обеспечение непрерывности учебного процесса, отказоустойчивости и защиты данных учащихся, не содержат указаний на товарные знаки или конкретных правообладателей. 2. Замечание не принимается. Обоснование: Трехуровневая клиент-серверная модель и микросервисный/сервисно-ориентированный подход являются базовыми общепринятыми отраслевыми стандартами надежности. Данная архитектура объективно необходима Заказчику для обеспечения бесперебойного учебного процесса: она позволяет обновлять отдельные дидактические модули (3D-библиотеки, модуль видеохостинга, игровые сессии) без полной остановки работы всей школьной платформы (минимизация времени простоя до уровня менее 1% в год). Монолитные решения не обеспечивают требуемой отказоустойчивости при пиковых нагрузках. 3. Замечание не принимается. Обоснование: Перечень из 18 логических модулей определяет функциональную полноту программного комплекса (аутентификация, сессии, хранилище материалов, 3D-рендеринг, потоковое видео, локализация, интерактивные задания, игровой сервер, постоянное соединение, генерация QR-кодов, статистика и отчеты, бэкап, мониторинг мощностей, аудит действий, CMS, маршрутизация, обработка статики, криптографическая защита). Требование гарантирует поставку законченного образовательного продукта, покрывающего утвержденную программу обучения. 4. Замечание не принимается. Обоснование: Архитектура программной платформы непосредственно определяет качество и надежность конечного результата. Архитектурная изоляция сервисов предотвращает сбои всей системы во время проведения синхронных уроков, исключает зависания при тестировании классов и утечки конфиденциальных данных. 5. Замечание не принимается. Обоснование: Условие «не менее 18 логических модулей» фиксирует компонентную независимость системы. В случае временной недоступности модуля видеоконтента модули интерактивного тестирования, работы с датчиками и 3D-моделирования продолжают штатную работу, что критически важно для учебного процесса. 6. Замечание не принимается. Обоснование: Требование об использовании обратного проксирования (reverse proxy) и алгоритмов балансировки нагрузки продиктовано требованиями информационной безопасности государственной организации образования: обеспечение терминации защищенных соединений (TLS), равномерное распределение сетевой нагрузки и защита локальной вычислительной сети школы от атак типа «отказ в обслуживании» (DoS/DDoS). 7. Замечание не принимается. Обоснование: В технической спецификации противоречие отсутствует. Серверные требования (не менее 8 ядер, 16 ГБ ОЗУ) указаны как локальный минимум аппаратных ресурсов для одновременной работы одного учебного класса (до 100 пользователей), тогда как показатель масштабируемости до 1000 одновременных соединений (WebSocket/HTTP) определяет архитектурную емкость самого программного ядра при проведении общешкольных олимпиад, срезов знаний и параллельных уроков. 8. Замечание не принимается. Обоснование: Показатели четко разграничены: 100 пользователей характеризуют локальный аппаратный сервер аудитории, а 1000 соединений — сетевую масштабируемость программной платформы разработчика. Способность ядра ПО обрабатывать пиковые нагрузки подтверждается предоставлением в составе заявки протокола нагрузочного тестирования. 9. Замечание не принимается. Обоснование: Контингент общеобразовательной школы составляет сотни учащихся. Платформа приобретается для долгосрочной эксплуатации и проведения как локальных занятий, так и общешкольных мероприятий. Методика проверки нагрузки стандартизирована и проводится независимой лабораторией с использованием программных генераторов трафика. 10. Замечание не принимается. Обоснование: Функционал взаимодействия с 3D-моделями (вращение по осям, зум, изоляция элементов, интерактивные точки интереса, базовые ракурсы) представляет собой стандартный инструментарий открытых 3D-движков WebGL (Three.js, Babylon.js и др.). Требование направлено на полноценное интерактивное изучение объемных объектов школьниками и не указывает на конкретного разработчика. 11. Замечание не принимается. Обоснование: Вместимость текстового контейнера не менее 500 символов определяет способность интерфейса отображать подробное академическое описание физического явления, анатомического органа или химического процесса без обрезки текста. Размещение более кратких пояснений спецификацией не ограничивается. 12. Замечание не принимается. Обоснование: Ограничение длительности видеофрагментов (от 5 до 15 минут) установлено в строгом соответствии с Санитарными правилами «Санитарно-эпидемиологические требования к объектам образования» Республики Казахстан, регламентирующими непрерывную продолжительность применения технических средств обучения (ТСО) на уроке, а также психолого-педагогическими нормами удержания внимания школьников. 13. Замечание не принимается. Обоснование: Демонстрация непрерывного видеоролика продолжительностью более 15 минут на уроке прямо нарушает санитарно-гигиенические нормы экранного времени для учащихся. Диапазон 5–15 минут оптимален для методики микрообучения (microlearning) в рамках 45-минутного занятия. 14. Замечание не принимается. Обоснование: Закупаемое программное обеспечение функционирует в локальной вычислительной сети государственной школы и обрабатывает персональные данные сотен несовершеннолетних учащихся. Предоставление протоколов аккредитованных испытательных лабораторий системы NCA РК необходимо для подтверждения надежности сетевого взаимодействия, защищенности исходного кода от вредоносных закладок и юридически значимого соответствия государственному стандарту СТ РК ISO/IEC 15408-2-2017. 15. Замечание не принимается. Обоснование: Каждый из пяти протоколов закрывает самостоятельный и критически важный контур безопасности (сеть, регламенты сопровождения, нагрузочная устойчивость, программный код и стандартизированные функции ролевого доступа). Отсутствие любого из документов создает прямую угрозу безопасности информационной инфраструктуры школы. 16. Замечание не принимается. Обоснование: Статический анализ исходного кода (SAST) проводится аккредитованными испытательными лабораториями в условиях государственной аттестации и строгого соблюдения конфиденциальности (NDA), что исключает риски разглашения коммерческой тайны. Данный аудит подтверждает отсутствие недокументированных возможностей и критических уязвимостей в поставляемом софте. 17. Замечание не принимается. Обоснование: При проведении государственных закупок в Республике Казахстан приоритет имеют национальные стандарты и документы государственной системы аккредитации РК. Перенос подтверждения защищенности ПО на этап приемки создает неприемлемые риски поставки небезопасного продукта и последующего срыва исполнения договора. Квалификация и безопасность решения должны подтверждаться на этапе подачи заявок. 18. Замечание принимается в части. Обоснование: Заказчиком принято решение об исключении из технической спецификации требований о том, что авторизационное письмо должно быть адресовано конкурсной комиссии и содержать номер и наименование конкурса, номер лота, а также требования о том, что дата выдачи письма не должна предшествовать дате публикации объявления о проведении текущего конкурса. В техническую спецификацию будут внесены соответствующие изменения. Потенциальный поставщик вправе предоставить любое действующее официальное авторизационное/дилерское/партнерское письмо производителя либо его официального представителя на территории РК в пределах срока его действия. Само требование о наличии авторизационного документа и QR-кода для оперативной онлайн-проверки подлинности сохраняется в целях подтверждения легальности канала поставки и защиты государственной организации от контрафактной продукции. 19. Замечание не принимается. Обоснование: Техническая спецификация сформирована в строгом соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и Правилами осуществления государственных закупок исходя из объективных потребностей учебного заведения и стандартов информационной безопасности. Модульная структура, открытая веб-архитектура и установленные критерии безопасности программного обеспечения непосредственно определяют надежность функционирования платформы во время уроков и защиту персональных данных учащихся. Исключение указанных параметров несет риск поставки неполноценного или незащищенного программного продукта, неспособного обеспечить непрерывность учебного процесса. Основания для изменения технических требований отсутствуют.
