Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069380
Тема сообщения
Замечание к АД
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "IT-Quantum"
Представитель поставщика
ҚАЙРАТҰЛЫ БАУЫРЖАН
Дата и время отправки сообщения
2026-10-02 01:32:16
Текст сообщения
1. Существенная часть технической спецификации относится к интерактивному образовательному программному обеспечению, однако требования сформулированы не только через необходимый функциональный результат, но и через конкретную внутреннюю программную архитектуру потенциального разработчика.
2. Установлено, что система должна строиться по клиент-серверному принципу с применением трехуровневой модели, использовать микросервисную либо сервис-ориентированную архитектуру и включать не менее 18 выделенных логических модулей, взаимодействующих через внутренние API.
3. Количество внутренних программных модулей является архитектурным решением разработчика и само по себе не определяет конечную функциональность образовательной платформы.
4. Одни разработчики могут реализовать перечисленные функции в 10 сервисах, другие — в 18, 25 или монолитном приложении. Для конечного пользователя архитектурное количество сервисов не имеет самостоятельного образовательного значения.
5. Просим заменить требование «не менее 18 логических модулей» перечнем обязательных функций платформы: аутентификация, контент, 3D, видео, локализация, задания, игры, аналитика, резервное копирование, аудит и информационная безопасность.
6. Требование использования строго трехуровневой модели «сервер баз данных — сервер приложений — клиентское приложение» также представляет собой внутреннее решение разработчика. Облачная современная архитектура может использовать serverless, контейнеризацию, managed DB, CDN и иные решения без выделения указанных уровней в требуемом виде.
7. Просим допустить любую архитектуру, обеспечивающую заявленные показатели производительности, отказоустойчивости, масштабируемости и безопасности.
8. Техническая спецификация одновременно требует обслуживание не менее 1000 одновременных активных соединений, тогда как позже серверные аппаратные ресурсы определяются как минимально необходимые для одновременной работы 100 пользователей.
9. Данные положения требуют согласования, поскольку непонятно, должна ли приемка производительности выполняться на 100 или 1000 активных пользователей.
10. Просим установить единый показатель расчетной нагрузки, соответствующий фактическому числу учащихся и педагогов учреждения.
11. Для одной школы требование гарантированного масштабирования до 1000 одновременных активных соединений требует отдельного обоснования фактической потребностью.
12. Если в учреждении одновременно с платформой будут работать существенно меньше пользователей, чрезмерная серверная производительность увеличивает стоимость решения без очевидной практической необходимости.
13. ТС фиксирует конкретные механизмы reverse proxy и даже варианты алгоритмов балансировки входящих запросов. Это относится к внутренней инфраструктуре разработчика и не должно определять пригодность конечного образовательного сервиса, если эквивалентная отказоустойчивость достигается иным способом.
14. Просим заменить конкретные алгоритмы балансировки на измеримый показатель доступности и времени ответа системы.
15. Установлено требование двухфакторной аутентификации для администратора и опционально для учителя, строгой структуры пароля, автоматической блокировки после пяти неверных попыток и настраиваемого тайм-аута от 5 до 60 минут.
16. Данные требования безопасности в целом понятны, однако их точная реализация может отличаться между платформами. Например, система может применять SSO, OAuth, аппаратные ключи либо иной механизм.
17. Просим допустить эквивалентные или более современные средства аутентификации и защиты учетных записей.
18. По 3D-подсистеме установлена очень детальная внутренняя функциональность: не более 100 000 полигонов, не менее 30 FPS, ровно определенный перечень десяти функций, не менее десяти интерактивных точек, текстовые пояснения не менее 500 символов, не менее трех ракурсов и определенный формат конфигурационных файлов.
19. Формат конфигурационного файла является внутренним техническим решением производителя и не влияет на способность педагога использовать 3D-модель.
20. Просим исключить требование к структуре конфигурационных файлов и оставить требования к пользовательской работе с 3D-контентом.
21. Ограничение модели количеством до 100 000 полигонов также требует пояснения. Более детализированная модель может иметь больше полигонов и при этом корректно отображаться, а оптимизированная модель — существенно меньше.
22. Просим установить минимальную производительность визуализации без ограничения сложности исходных моделей.
23. Требование минимум десяти кликабельных точек в каждой 3D-модели не учитывает различия образовательных объектов. Простая геометрическая модель может не требовать десяти точек, а сложная анатомическая или техническая модель может содержать десятки.
24. Просим устанавливать количество интерактивных элементов исходя из содержания конкретного материала либо указать «при наличии функциональной необходимости».
25. Требование отображения текстовой карточки не менее 500 символов также может ухудшать удобство использования: краткое пояснение на 100–200 символов иногда педагогически эффективнее.
26. Просим исключить минимальный объем текста и ориентироваться на полноту содержания.
27. По видеоматериалам установлена продолжительность исключительно от 5 до 15 минут. Это не позволяет размещать короткие двухминутные демонстрационные ролики, инструкции либо более длинные лекционные материалы.
28. Обоснование физиологическими нормами в ТС не сопровождается указанием источника такой нормы.
29. Просим снять жесткие ограничения продолжительности видеоматериалов и установить возможность воспроизведения образовательного видео различной продолжительности.
30. Требование максимального размера загружаемого файла «не менее 500 МБ» сформулировано неоднозначно. Следует определить, идет ли речь о том, что система обязана принимать файлы размером до 500 МБ включительно, а не о минимальном ограничении.
31. В игровом модуле установлены конкретные технические механизмы двусторонней связи, максимальная задержка 300 мс, не менее восьми типов транзакций, QR-код со специальной временной ссылкой и присоединение пользователя не более чем за 5 секунд.
32. Конкретная реализация игровых транзакций относится к программному коду разработчика. Эквивалентная образовательная платформа может использовать иной протокол и структуру событий.
33. Просим устанавливать конечные показатели: массовое подключение учеников, синхронная викторина, отображение результатов и приемлемая задержка, не фиксируя внутреннюю модель транзакций.
34. Требование подключения учащегося только путем QR-кода без ввода кода ограничивает платформы, использующие короткий PIN, ссылку или иной безопасный механизм.
35. Просим допустить несколько способов быстрого присоединения к сессии.
36. В аналитике зафиксированы конкретные виды диаграмм — круговая и столбчатая. Тип диаграммы является элементом интерфейса, а не ключевой функциональной характеристикой. Более современная платформа может использовать линейные диаграммы, heatmap или иные визуализации.
37. Просим требовать наличие наглядной аналитики без фиксации конкретных визуальных форм.
38. В информационной безопасности детально описаны интервалы мониторинга до одной минуты, перечень метрик, глубина хранения логов не менее 30 дней, RTO не более 4 часов и RPO не более 24 часов.
39. Данные значения должны быть согласованы с фактической моделью размещения системы: облачной, локальной или гибридной. ТС одновременно содержит требования к серверному оборудованию, но прямо не устанавливает, поставляется ли физический сервер Заказчику.
40. Просим уточнить, входит ли серверное оборудование в предмет поставки.
41. Если не входит, кто предоставляет серверные мощности?
42. Если платформа облачная, зачем устанавливать аппаратные параметры сервера на уровне конкретных CPU, RAM и SSD?
43. Если платформа локальная, стоимость физического сервера должна быть учтена в комплекте и его количество должно быть указано.
44. Требования к UI содержат максимально допустимые три логических перехода от главной страницы для выполнения базового действия. Такой показатель практически невозможно единообразно проверить без формализации каждого пользовательского сценария.
45. Просим заменить его общим требованием интуитивности интерфейса либо определить конкретный сценарий приемочного тестирования.
46. Установлены конкретные размеры touch target не менее 44×44 пикселя и размер шрифта 14 пикселей. При адаптивной верстке физический размер элемента зависит от разрешения и плотности пикселей устройства.
47. Просим использовать относительные либо признанные критерии доступности, а не абсолютный размер в пикселях.
48. По правам использования предусмотрено предоставление неограниченного по количеству пользователей и территории неисключительного либо, в зависимости от договора, исключительного права на весь срок действия авторских прав.
49. Формулировка «неисключительное (или исключительное в зависимости от условий договора)» является неопределенной и допускает принципиально разные правовые режимы.
50. Просим однозначно определить, какой объем лицензии закупается.
51. Передача права использования на весь срок авторских прав существенно отличается от стандартной годовой или бессрочной лицензии и может влиять на стоимость.
52. Просим уточнить, действительно ли Заказчику требуется бессрочное право использования или достаточно права использования на срок эксплуатации решения.
53. ТС предусматривает SLA: критическая реакция не более 4 рабочих часов, средняя — не более 24 рабочих часов, но не определен режим работы службы поддержки, часовой пояс, рабочие дни и срок фактического устранения критической неисправности.
54. Просим уточнить SLA.
55. Особое ограничение создается требованиями представить в заявке многочисленные независимые лабораторные протоколы на конкретное ПО, выданные исключительно лабораторией, аккредитованной в системе NCA Республики Казахстан.
56. Требуются протокол обследования сетевой инфраструктуры, процессов информационной безопасности, нагрузочного испытания, анализа исходного кода SAST и испытаний функций информационной безопасности по СТ РК ISO/IEC 15408-2-2017.
57. Причем отсутствие хотя бы одного из перечисленных протоколов прямо объявлено несоответствием технической спецификации.
58. Такое сочетание документов не характеризует только конечную функциональность ПО, а требует, чтобы конкретный программный продукт заранее прошел несколько специализированных исследований в конкретной системе аккредитации еще до участия в закупке.
59. Это существенно сокращает число возможных разработчиков и продуктов, в том числе зарубежных платформ, которые могут соответствовать функциональности и международным требованиям безопасности, но не иметь именно казахстанских протоколов NCA.
60. Просим допустить эквивалентные международные сертификаты и протоколы информационной безопасности либо проведение необходимого тестирования победителем до ввода системы в эксплуатацию.
61. Особенно проблематично требование SAST протокола от независимой лаборатории в отношении проприетарного программного обеспечения: правообладатель может не передавать исходный код внешним лабораториям по причинам защиты интеллектуальной собственности.
62. Просим пояснить, каким образом поставщик платформы иностранного производителя должен выполнить это условие.
63. В целом требования следует ориентировать на результат: защищенность веб-приложения, отсутствие критических уязвимостей, производительность, надежность, резервное копирование, а не на наличие заранее оформленного фиксированного набора локальных документов.
2. Установлено, что система должна строиться по клиент-серверному принципу с применением трехуровневой модели, использовать микросервисную либо сервис-ориентированную архитектуру и включать не менее 18 выделенных логических модулей, взаимодействующих через внутренние API.
3. Количество внутренних программных модулей является архитектурным решением разработчика и само по себе не определяет конечную функциональность образовательной платформы.
4. Одни разработчики могут реализовать перечисленные функции в 10 сервисах, другие — в 18, 25 или монолитном приложении. Для конечного пользователя архитектурное количество сервисов не имеет самостоятельного образовательного значения.
5. Просим заменить требование «не менее 18 логических модулей» перечнем обязательных функций платформы: аутентификация, контент, 3D, видео, локализация, задания, игры, аналитика, резервное копирование, аудит и информационная безопасность.
6. Требование использования строго трехуровневой модели «сервер баз данных — сервер приложений — клиентское приложение» также представляет собой внутреннее решение разработчика. Облачная современная архитектура может использовать serverless, контейнеризацию, managed DB, CDN и иные решения без выделения указанных уровней в требуемом виде.
7. Просим допустить любую архитектуру, обеспечивающую заявленные показатели производительности, отказоустойчивости, масштабируемости и безопасности.
8. Техническая спецификация одновременно требует обслуживание не менее 1000 одновременных активных соединений, тогда как позже серверные аппаратные ресурсы определяются как минимально необходимые для одновременной работы 100 пользователей.
9. Данные положения требуют согласования, поскольку непонятно, должна ли приемка производительности выполняться на 100 или 1000 активных пользователей.
10. Просим установить единый показатель расчетной нагрузки, соответствующий фактическому числу учащихся и педагогов учреждения.
11. Для одной школы требование гарантированного масштабирования до 1000 одновременных активных соединений требует отдельного обоснования фактической потребностью.
12. Если в учреждении одновременно с платформой будут работать существенно меньше пользователей, чрезмерная серверная производительность увеличивает стоимость решения без очевидной практической необходимости.
13. ТС фиксирует конкретные механизмы reverse proxy и даже варианты алгоритмов балансировки входящих запросов. Это относится к внутренней инфраструктуре разработчика и не должно определять пригодность конечного образовательного сервиса, если эквивалентная отказоустойчивость достигается иным способом.
14. Просим заменить конкретные алгоритмы балансировки на измеримый показатель доступности и времени ответа системы.
15. Установлено требование двухфакторной аутентификации для администратора и опционально для учителя, строгой структуры пароля, автоматической блокировки после пяти неверных попыток и настраиваемого тайм-аута от 5 до 60 минут.
16. Данные требования безопасности в целом понятны, однако их точная реализация может отличаться между платформами. Например, система может применять SSO, OAuth, аппаратные ключи либо иной механизм.
17. Просим допустить эквивалентные или более современные средства аутентификации и защиты учетных записей.
18. По 3D-подсистеме установлена очень детальная внутренняя функциональность: не более 100 000 полигонов, не менее 30 FPS, ровно определенный перечень десяти функций, не менее десяти интерактивных точек, текстовые пояснения не менее 500 символов, не менее трех ракурсов и определенный формат конфигурационных файлов.
19. Формат конфигурационного файла является внутренним техническим решением производителя и не влияет на способность педагога использовать 3D-модель.
20. Просим исключить требование к структуре конфигурационных файлов и оставить требования к пользовательской работе с 3D-контентом.
21. Ограничение модели количеством до 100 000 полигонов также требует пояснения. Более детализированная модель может иметь больше полигонов и при этом корректно отображаться, а оптимизированная модель — существенно меньше.
22. Просим установить минимальную производительность визуализации без ограничения сложности исходных моделей.
23. Требование минимум десяти кликабельных точек в каждой 3D-модели не учитывает различия образовательных объектов. Простая геометрическая модель может не требовать десяти точек, а сложная анатомическая или техническая модель может содержать десятки.
24. Просим устанавливать количество интерактивных элементов исходя из содержания конкретного материала либо указать «при наличии функциональной необходимости».
25. Требование отображения текстовой карточки не менее 500 символов также может ухудшать удобство использования: краткое пояснение на 100–200 символов иногда педагогически эффективнее.
26. Просим исключить минимальный объем текста и ориентироваться на полноту содержания.
27. По видеоматериалам установлена продолжительность исключительно от 5 до 15 минут. Это не позволяет размещать короткие двухминутные демонстрационные ролики, инструкции либо более длинные лекционные материалы.
28. Обоснование физиологическими нормами в ТС не сопровождается указанием источника такой нормы.
29. Просим снять жесткие ограничения продолжительности видеоматериалов и установить возможность воспроизведения образовательного видео различной продолжительности.
30. Требование максимального размера загружаемого файла «не менее 500 МБ» сформулировано неоднозначно. Следует определить, идет ли речь о том, что система обязана принимать файлы размером до 500 МБ включительно, а не о минимальном ограничении.
31. В игровом модуле установлены конкретные технические механизмы двусторонней связи, максимальная задержка 300 мс, не менее восьми типов транзакций, QR-код со специальной временной ссылкой и присоединение пользователя не более чем за 5 секунд.
32. Конкретная реализация игровых транзакций относится к программному коду разработчика. Эквивалентная образовательная платформа может использовать иной протокол и структуру событий.
33. Просим устанавливать конечные показатели: массовое подключение учеников, синхронная викторина, отображение результатов и приемлемая задержка, не фиксируя внутреннюю модель транзакций.
34. Требование подключения учащегося только путем QR-кода без ввода кода ограничивает платформы, использующие короткий PIN, ссылку или иной безопасный механизм.
35. Просим допустить несколько способов быстрого присоединения к сессии.
36. В аналитике зафиксированы конкретные виды диаграмм — круговая и столбчатая. Тип диаграммы является элементом интерфейса, а не ключевой функциональной характеристикой. Более современная платформа может использовать линейные диаграммы, heatmap или иные визуализации.
37. Просим требовать наличие наглядной аналитики без фиксации конкретных визуальных форм.
38. В информационной безопасности детально описаны интервалы мониторинга до одной минуты, перечень метрик, глубина хранения логов не менее 30 дней, RTO не более 4 часов и RPO не более 24 часов.
39. Данные значения должны быть согласованы с фактической моделью размещения системы: облачной, локальной или гибридной. ТС одновременно содержит требования к серверному оборудованию, но прямо не устанавливает, поставляется ли физический сервер Заказчику.
40. Просим уточнить, входит ли серверное оборудование в предмет поставки.
41. Если не входит, кто предоставляет серверные мощности?
42. Если платформа облачная, зачем устанавливать аппаратные параметры сервера на уровне конкретных CPU, RAM и SSD?
43. Если платформа локальная, стоимость физического сервера должна быть учтена в комплекте и его количество должно быть указано.
44. Требования к UI содержат максимально допустимые три логических перехода от главной страницы для выполнения базового действия. Такой показатель практически невозможно единообразно проверить без формализации каждого пользовательского сценария.
45. Просим заменить его общим требованием интуитивности интерфейса либо определить конкретный сценарий приемочного тестирования.
46. Установлены конкретные размеры touch target не менее 44×44 пикселя и размер шрифта 14 пикселей. При адаптивной верстке физический размер элемента зависит от разрешения и плотности пикселей устройства.
47. Просим использовать относительные либо признанные критерии доступности, а не абсолютный размер в пикселях.
48. По правам использования предусмотрено предоставление неограниченного по количеству пользователей и территории неисключительного либо, в зависимости от договора, исключительного права на весь срок действия авторских прав.
49. Формулировка «неисключительное (или исключительное в зависимости от условий договора)» является неопределенной и допускает принципиально разные правовые режимы.
50. Просим однозначно определить, какой объем лицензии закупается.
51. Передача права использования на весь срок авторских прав существенно отличается от стандартной годовой или бессрочной лицензии и может влиять на стоимость.
52. Просим уточнить, действительно ли Заказчику требуется бессрочное право использования или достаточно права использования на срок эксплуатации решения.
53. ТС предусматривает SLA: критическая реакция не более 4 рабочих часов, средняя — не более 24 рабочих часов, но не определен режим работы службы поддержки, часовой пояс, рабочие дни и срок фактического устранения критической неисправности.
54. Просим уточнить SLA.
55. Особое ограничение создается требованиями представить в заявке многочисленные независимые лабораторные протоколы на конкретное ПО, выданные исключительно лабораторией, аккредитованной в системе NCA Республики Казахстан.
56. Требуются протокол обследования сетевой инфраструктуры, процессов информационной безопасности, нагрузочного испытания, анализа исходного кода SAST и испытаний функций информационной безопасности по СТ РК ISO/IEC 15408-2-2017.
57. Причем отсутствие хотя бы одного из перечисленных протоколов прямо объявлено несоответствием технической спецификации.
58. Такое сочетание документов не характеризует только конечную функциональность ПО, а требует, чтобы конкретный программный продукт заранее прошел несколько специализированных исследований в конкретной системе аккредитации еще до участия в закупке.
59. Это существенно сокращает число возможных разработчиков и продуктов, в том числе зарубежных платформ, которые могут соответствовать функциональности и международным требованиям безопасности, но не иметь именно казахстанских протоколов NCA.
60. Просим допустить эквивалентные международные сертификаты и протоколы информационной безопасности либо проведение необходимого тестирования победителем до ввода системы в эксплуатацию.
61. Особенно проблематично требование SAST протокола от независимой лаборатории в отношении проприетарного программного обеспечения: правообладатель может не передавать исходный код внешним лабораториям по причинам защиты интеллектуальной собственности.
62. Просим пояснить, каким образом поставщик платформы иностранного производителя должен выполнить это условие.
63. В целом требования следует ориентировать на результат: защищенность веб-приложения, отсутствие критических уязвимостей, производительность, надежность, резервное копирование, а не на наличие заранее оформленного фиксированного набора локальных документов.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-05 11:37:42
Автор:
ТӨРЕХАНОВ НҰРДӘУЛЕТ МУХТАРҰЛЫ
Решение:
Отклонить замечания
1. Замечание не принимается. Обоснование: В соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках», Заказчик определяет требуемые функциональные, технические, качественные и эксплуатационные характеристики закупаемых товаров исходя из собственных потребностей и специфики образовательного процесса. Архитектурные требования к интерактивному программному обеспечению направлены на обеспечение непрерывности учебного процесса, высокой отказоустойчивости и защиты персональных данных учащихся, не содержат указаний на товарные знаки или конкретных правообладателей. 2. Замечание не принимается. Обоснование: Клиент-серверный принцип, трехуровневая модель и сервисно-ориентированная (микросервисная) архитектура являются общепринятыми индустриальными стандартами для высоконагруженных корпоративных и образовательных систем. Данная компоновка объективно необходима для предотвращения срывов учебных занятий: сбой одного функционального модуля не приводит к аварийной остановке всей платформы школы. 3. Замечание не принимается. Обоснование: Перечень из 18 логических модулей определяет функциональную полноту образовательной платформы (аутентификация, хранилище контента, 3D-рендеринг, потоковое видео, интерактивные задания, игровой сессионный сервер, аналитика, резервное копирование, мониторинг мощностей, аудит действий, CMS, криптографическая защита и др.), исключая поставку урезанного или функционально неполноценного программного продукта. 4. Замечание не принимается. Обоснование: Монолитные архитектурные решения не обеспечивают требуемой компонентной изоляции. При отказе или зависании монолитного сервиса прекращается работа всего комплекса во всех классах одновременно, тогда как модульная архитектура гарантирует продолжение работы интерактивных уроков, тестирования и 3D-моделирования даже при временной недоступности отдельных медиасервисов. 5. Замечание не принимается. Обоснование: Наличие выделенных логических модулей гарантирует компонентную независимость и возможность независимого обновления и масштабирования каждого сервиса в рамках долгосрочной эксплуатации школьной ИТ-инфраструктуры. 6. Замечание не принимается. Обоснование: Трехуровневая архитектура «база данных — сервер приложений — клиентское приложение» является фундаментальным стандартом обеспечения информационной безопасности, исключающим прямой доступ пользовательских веб-клиентов к базе данных и обеспечивающим защиту критических данных учащихся от несанкционированного изменения. 7. Замечание не принимается. Обоснование: Требования спецификации носят технологически нейтральный характер и допускают различные варианты реализации трехуровневой сервисной модели (включая контейнеризацию и управляемые среды), отвечающие установленным критериям надежности и безопасности. 8. Замечание не принимается. Обоснование: В технической спецификации противоречие отсутствует. Серверные аппаратные ресурсы (не менее 8 ядер, 16 ГБ ОЗУ) указаны как локальный минимум вычислительных мощностей аудитории для стабильной синхронной работы одного класса (до 100 пользователей), тогда как показатель в 1000 одновременных сетевых соединений (WebSocket/HTTP) определяет архитектурную масштабируемость самого программного ядра разработчика. 9. Замечание не принимается. Обоснование: Показатели четко разграничены по уровням применения: 100 пользователей характеризуют локальный аппаратный сервер учебного кабинета, а 1000 соединений — сетевую архитектурную емкость программной платформы разработчика при проведении общешкольных срезов знаний и олимпиад. 10. Замечание не принимается. Обоснование: Контингент общеобразовательной школы составляет сотни учащихся, распределенных по классам и сменам. Образовательная платформа приобретается для долгосрочной эксплуатации как на локальных уроках, так и при проведении общешкольных тестирований и параллельных интерактивных сессий. 11. Замечание не принимается. Обоснование: Запас сетевой масштабируемости до 1000 активных соединений объективно необходим для одновременного подключения параллелей классов, мобильных устройств учащихся и автоматизированного сбора телеметрии с измерительных датчиков лаборатории. 12. Замечание не принимается. Обоснование: Архитектурная поддержка масштабирования ядра веб-платформы является базовым свойством современного тиражного программного обеспечения и не влечет необоснованного удорожания, предотвращая системные сбои при пиковых нагрузках. 13. Замечание не принимается. Обоснование: Требование об использовании обратного проксирования (reverse proxy) обусловлено регламентами информационной безопасности государственных организаций образования: обеспечение терминации защищенных соединений (TLS), равномерное распределение нагрузки и защита локальной сети школы от атак типа «отказ в обслуживании» (DoS/DDoS). 14. Замечание не принимается. Обоснование: Алгоритмы циклического перебора (Round-robin) и наименьшего количества подключений (Least-connections) являются открытыми общепринятыми алгоритмами балансировки входящих запросов, поддерживаемыми стандартными обратными прокси-серверами и балансировщиками. 15. Замечание не принимается. Обоснование: Требования двухфакторной аутентификации (2FA), надежной структуры паролей, блокировки после пяти неверных попыток ввода и настраиваемого тайм-аута сессии продиктованы необходимостью строгой защиты учетных записей от несанкционированного доступа и перехвата управления учебным процессом. 16. Замечание не принимается. Обоснование: Техническая спецификация определяет базовые отраслевые критерии парольной защиты и многофакторной аутентификации, которые штатно реализуются в современных системах контроля доступа и не исключают применения дополнительных защитных протоколов. 17. Замечание не принимается. Обоснование: Установленные требования к парольной политике и двухфакторной аутентификации соответствуют стандартам информационной безопасности государственных организаций Республики Казахстан. 18. Замечание не принимается. Обоснование: Функционал взаимодействия с трехмерными моделями (вращение по осям, зум, изоляция элементов, 10 интерактивных точек интереса, базовые ракурсы) является стандартным инструментарием современных открытых 3D-движков WebGL (Three.js, Babylon.js и др.), обеспечивающим интерактивное академическое изучение сложных объемных объектов школьниками. 19. Замечание не принимается. Обоснование: Использование стандартизированных текстовых конфигурационных файлов формата «атрибут-значение» (JSON/YAML/XML) обеспечивает открытость параметризации, легкость загрузки новых дидактических моделей и независимость платформы от закрытых проприетарных форматов. 20. Замечание не принимается. Обоснование: Стандартизированная структура метаданных моделей необходима для корректного переноса, хранения и экспорта интерактивного контента между различными учебными модулями системы. 21. Замечание не принимается. Обоснование: Ограничение полигональности до 100 000 полигонов оптимизировано для образовательной WebGL-графики: оно обеспечивает детальную проработку анатомических и физических моделей без зависания встроенных графических адаптеров клиентских моноблоков. 22. Замечание не принимается. Обоснование: Параметр производительности (не менее 30 FPS при нагрузке до 100 000 полигонов) является базовым критерием плавности трехмерной графики, исключающим рывки и зрительное утомление учащихся при работе у экрана. 23. Замечание не принимается. Обоснование: Возможность размещения не менее 10 интерактивных точек взаимодействия на модели определяет функциональную способность 3D-модуля детально раскрывать составные анатомические органы, молекулярные структуры и физические агрегаты. 24. Замечание не принимается. Обоснование: Показатель регламентирует верхнюю функциональную емкость инструментария: система обязана технически поддерживать до 10 точек интереса и более при изучении сложных многокомпонентных объектов программы естественнонаучного цикла. 25. Замечание не принимается. Обоснование: Вместимость текстового поля не менее 500 символов определяет способность интерфейса отображать подробное академическое описание научного явления или термина без обрезки текста. Размещение более кратких пояснений спецификацией не ограничивается. 26. Замечание не принимается. Обоснование: Параметр регламентирует максимальную вместимость контейнера информационной карточки, гарантируя полноту подачи учебного материала при необходимости развернутого дидактического пояснения. 27. Замечание не принимается. Обоснование: Ограничение продолжительности обучающих видеофрагментов (от 5 до 15 минут) установлено в строгом соответствии с Санитарными правилами «Санитарно-эпидемиологические требования к объектам образования» Республики Казахстан, регламентирующими непрерывную длительность применения технических средств обучения (ТСО) на уроке, а также нормами методики микрообучения (microlearning). 28. Замечание не принимается. Обоснование: Норматив непрерывной работы обучающихся с экранами цифровых устройств (не более 15 минут экранного времени на уроке) закреплен действующими санитарно-эпидемиологическими правилами и гигиеническими нормативами Республики Казахстан. 29. Замечание не принимается. Обоснование: Демонстрация непрерывных видеоматериалов свыше 15 минут на уроке прямо нарушает санитарно-гигиенические правила охраны зрения учащихся и структуру стандартного 45-минутного урока. 30. Замечание не принимается. Обоснование: Формулировка «не менее 500 МБ» означает, что система обязана поддерживать загрузку объемных видеофайлов размером до 500 МБ включительно, обеспечивая достаточную емкость для качественного учебного видео Full HD. 31. Замечание не принимается. Обоснование: Архитектура игрового соревновательного модуля на базе полнодуплексного протокола WebSocket с задержкой не более 300 мс объективно необходима для синхронного запуска таймеров и мгновенной фиксации ответов при проведении интерактивных викторин на интерактивной панели. 32. Замечание не принимается. Обоснование: Перечень из восьми базовых типов транзакций отражает полный жизненный цикл интерактивной викторины (регистрация, старт, рассылка вопросов, прием ответов, таймер, подсчет баллов, финиш, лидерборд) и исключает поставку неполноценных игровых решений. 33. Замечание не принимается. Обоснование: Использование стандартных сетевых протоколов реального времени гарантирует защиту от читерства, рассинхронизации таймеров и искажения результатов тестирования на клиентских устройствах. 34. Замечание не принимается. Обоснование: Генерация QR-кода с прямой зашифрованной сессионной ссылкой позволяет классу из 30 учеников подключиться к викторине за несколько секунд без утомительного ручного ввода логинов, паролей и сетевых адресов, экономя учебное время урока. 35. Замечание не принимается. Обоснование: QR-маршрутизация является наиболее оперативным и эргономичным методом подключения мобильных устройств учащихся непосредственно в школьной аудитории. 36. Замечание не принимается. Обоснование: Наличие круговых и столбчатых диаграмм представляет собой базовый дидактический стандарт наглядного представления статистических данных (успеваемость класса, процент верных ответов, рейтинг), понятный школьникам и педагогам. 37. Замечание не принимается. Обоснование: Требование устанавливает минимальный состав наглядной инфографики дашборда и не ограничивает разработчика в предоставлении дополнительных аналитических визуализаций. 38. Замечание не принимается. Обоснование: Параметры непрерывного мониторинга, глубины хранения системных журналов не менее 30 дней, RTO не более 4 часов и RPO не более 24 часов являются общепринятыми отраслевыми стандартами отказоустойчивости и непрерывности функционирования образовательных веб-платформ. 39. Замечание не принимается. Обоснование: Программное обеспечение функционирует по трехуровневой клиент-серверной веб-модели. Требования к серверной конфигурации определяют минимально необходимые вычислительные ресурсы для надежного развертывания серверной части платформы. 40. Замечание не принимается. Обоснование: В соответствии со спецификацией закупается аппаратно-программный комплекс учебного оборудования; требования раздела 6 определяют минимальные вычислительные требования к серверной среде для инсталляции программного ядра. 41. Замечание не принимается. Обоснование: Серверная среда для функционирования единой институциональной платформы школы обеспечивается в рамках развертывания комплекса в соответствии с руководством системного администратора. 42. Замечание не принимается. Обоснование: Указание параметров аппаратных мощностей (не менее 8 ядер, 16 ГБ ОЗУ, 500 ГБ SSD) необходимо для гарантии бесперебойной обработки ресурсоемких 3D-моделей, потокового видео и сотен параллельных клиентских сессий. 43. Замечание не принимается. Обоснование: Состав закупаемого комплекта исчерпывающе зафиксирован в технической спецификации. Системные требования регламентируют параметры вычислительной среды, необходимой для корректной эксплуатации ПО. 44. Замечание не принимается. Обоснование: Правило «не более трех логических переходов» («правило трех кликов») является общепризнанным международным стандартом эргономики пользовательских интерфейсов (ISO 9241-110, UI/UX). Оно гарантирует простоту навигации и оперативный доступ преподавателя к материалам урока без сложных многоуровневых меню. 45. Замечание не принимается. Обоснование: Соблюдение правила трех кликов легко верифицируется в ходе приемочного тестирования выполнением базовых действий (запуск урока, открытие 3D-модели из библиотеки, генерация QR-кода викторины) по инструкции пользователя. 46. Замечание не принимается. Обоснование: Минимальный размер интерактивного элемента не менее 44х44 пикселя и размер шрифта не менее 14 пикселей соответствуют международным стандартам мобильной доступности (W3C WCAG 2.1), предотвращая ошибочные нажатия пальцами на экранах мобильных устройств учеников. 47. Замечание не принимается. Обоснование: Числовые критерии доступности (44х44 px, 14 px) исключают субъективность при оценке эргономики интерфейса и обеспечивают равные условия для всех разработчиков. 48. Замечание не принимается. Обоснование: В разделе 7.1 технической спецификации четко зафиксирован правовой статус лицензии: Заказчику передаются неисключительные права на использование ПО на весь срок действия авторских прав (бессрочно) без ограничения количества создаваемых учетных записей внутри организации образования. 49. Замечание не принимается. Обоснование: Объем передаваемых прав определен однозначно — предоставление неисключительных прав на образовательную организацию («campus license»), что полностью снимает любую неопределенность. 50. Замечание не принимается. Обоснование: Закупается единая институциональная неисключительная лицензия на программный комплекс для общеобразовательного учреждения. 51. Замечание не принимается. Обоснование: Передача неисключительных прав на весь срок действия авторских прав гарантирует защиту государственных инвестиций и исключает необходимость ежегодных затрат бюджетных средств на продление платных подписок. 52. Замечание не принимается. Обоснование: Заказчику объективно требуется бессрочное право использования образовательной платформы для обеспечения непрерывности учебного процесса на весь жизненный цикл компьютерного кабинета. 53. Замечание не принимается. Обоснование: Регламент SLA исчерпывающе определен подразделом 7.2 технической спецификации: время реакции технической поддержки на критические ошибки составляет не более 4 рабочих часов, на ошибки среднего приоритета — не более 24 рабочих часов с момента поступления обращения Заказчика. 54. Замечание не принимается. Обоснование: Установленные сроки реакции службы технической поддержки исчисляются в пределах стандартных рабочих часов организаций образования Республики Казахстан и достаточны для оперативного восстановления сервисов. 55. Замечание не принимается. Обоснование: Закупаемое программное обеспечение разворачивается в локальной вычислительной сети государственной школы и обрабатывает персональные данные сотен несовершеннолетних учащихся. Предоставление протоколов аккредитованных испытательных лабораторий системы Национального центра аккредитации (NCA) РК необходимо для подтверждения надежности передачи данных, устойчивости к пиковым нагрузкам, защищенности исходного кода от вредоносных закладок и соответствия государственному стандарту СТ РК ISO/IEC 15408-2-2017. 56. Замечание не принимается. Обоснование: Каждый из пяти протоколов закрывает самостоятельный и критически важный контур безопасности государственной информационной инфраструктуры (сеть, DevSecOps-процессы сопровождения, нагрузка, исходный код и стандартизированные функции ролевого доступа СТ РК). Отсутствие любого из документов создает прямую угрозу безопасности образовательной среды. 57. Замечание не принимается. Обоснование: Условие об обязательном подтверждении информационной безопасности на этапе рассмотрения заявок направлено на недопущение срыва закупки и превентивную защиту государственной школы от поставки уязвимого или небезопасного программного продукта. 58. Замечание не принимается. Обоснование: В государственных закупках Республики Казахстан юридическую силу имеют официальные документы испытательных лабораторий, входящих в национальную систему аккредитации (NCA) РК в соответствии с Законом РК «О техническом регулировании». Пройти оценку соответствия в аккредитованной лаборатории РК вправе любой правообладатель тиражного ПО. 59. Замечание не принимается. Обоснование: На рынке Республики Казахстан представлен широкий спектр образовательных платформ и тиражных решений отечественных и международных разработчиков цифрового учебного контента (включая экосистемы BilimLand, Daryn Online и их сертифицированные аналоги), успешно прошедших оценку соответствия в лабораториях системы NCA РК. 60. Замечание не принимается. Обоснование: При проведении государственных закупок приоритет имеют национальные стандарты и документы государственной системы аккредитации РК. Перенос подтверждения защищенности ПО на стадию приемки создает неприемлемые риски поставки небезопасного софта и срыва исполнения договора. 61. Замечание не принимается. Обоснование: Статический анализ исходного кода (SAST) проводится аккредитованными испытательными лабораториями в условиях государственной аттестации и строгого соблюдения конфиденциальности (соглашения NDA). Передача исходного кода Заказчику или поставщику не требуется: поставщик запрашивает у правообладателя готовый действующий протокол испытаний. 62. Замечание не принимается. Обоснование: Отношения между разработчиком и испытательной лабораторией строятся на договорной основе в рамках стандартных процедур сертификации программной продукции; поставщик предоставляет готовый официальный документ в составе конкурсной заявки. 63. Замечание не принимается. Обоснование: Техническая спецификация сформирована в строгом соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и Правилами осуществления государственных закупок исходя из объективных потребностей общеобразовательного учреждения и стандартов информационной безопасности. Характеристики программного обеспечения базируются на открытых отраслевых веб-стандартах (клиент-серверная модель, протоколы WebSocket, TLS, WebGL, Canvas), не содержат указаний на товарные знаки или конкретных правообладателей и обеспечивают надежное функционирование учебного процесса. Оснований для изменения параметров технической спецификации не имеется.
