Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 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. В целом требования следует ориентировать на результат: защищенность веб-приложения, отсутствие критических уязвимостей, производительность, надежность, резервное копирование, а не на наличие заранее оформленного фиксированного набора локальных документов.
