Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069933
Тема сообщения
техническая спецификация
Тип сообщения
Замечание к АД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-10-08 16:17:01
Текст сообщения
1. Требования к программному обеспечению для интерактивного обучения и комплексу беспроводных датчиков имеют выраженные признаки описания заранее созданной программно-аппаратной экосистемы конкретного разработчика.
2. ТС определяет не только конечные образовательные функции, но и внутреннюю архитектуру ПО.
3. Установлен обязательный клиент-серверный принцип.
4. Обязательная трехуровневая модель: сервер базы данных, сервер приложений, клиентское приложение.
5. Обязательная микросервисная либо сервис-ориентированная архитектура.
6. Требуется не менее 18 выделенных логических модулей.
7. Заказчик фактически перечисляет внутреннюю декомпозицию программного продукта: авторизация, управление сессиями и токенами, файловое хранилище, 3D-рендеринг, видео, субтитры, задания, игровой сервер, постоянное двустороннее соединение, QR, статистика, резервное копирование, мониторинг серверов, централизованное логирование, CMS, маршрутизация, статические ресурсы и криптографическая защита.
8. Количество внутренних сервисов не характеризует качество образовательного результата.
9. Система с 10 модулями может выполнять тот же функционал.
10. Система с монолитной архитектурой может быть надежнее и проще в сопровождении.
11. И наоборот, система с 30 микросервисами не является автоматически лучше.
12. Следовательно, обязательность не менее 18 внутренних модулей ограничивает архитектурно и не связана напрямую с потребностями лицея.
13. Аналогично обязательный reverse proxy и конкретные алгоритмы распределения нагрузки относятся к реализации серверной инфраструктуры разработчиком.
14. Заказчику объективно важны доступность, производительность и безопасность, а не способ внутренней маршрутизации HTTP-запросов.
15. Отдельно требуется масштабирование до не менее 1000 одновременно активных подключений.
16. При этом в поставке предусмотрено 29 моноблоков.
17. Не раскрыто, почему одному учебному комплекту требуется одновременно 1000 активных пользователей.
18. Далее системные требования самого сервера отдельно сформулированы для одновременной работы до 100 пользователей.
19. Возникает внутренний вопрос: архитектура должна выдерживать 1000 пользователей, однако минимальный сервер рассчитывается только на 100.
20. Просим определить фактически требуемую нагрузку и методику ее проверки.
21. Если речь идет о 29 учебных рабочих местах, достаточный запас должен определяться разумным коэффициентом, а не характеристикой корпоративной платформы на 1000 подключений.
22. Требования к 3D-подсистеме также чрезмерно подробны.
23. 3D-модель должна иметь не более 100 000 полигонов.
24. Частота — минимум 30 кадров/с.
25. Не менее 10 конкретных функций взаимодействия.
26. Не менее 10 интерактивных точек.
27. Текстовые карточки минимум 500 символов.
28. Не менее трех заранее сохраненных ракурсов.
29. Формат конфигурации описан через иерархическую структуру «атрибут-значение».
30. Такие требования скорее описывают внутренний формат существующего контента.
31. Например, модель с 150 000 оптимизированных полигонов может визуально быть качественнее и работать быстрее на современном GPU, но формально выходит за ограничение.
32. Неясно, почему максимальное количество полигонов вообще является требованием к поставщику, если ключевой результат — стабильные 30 FPS.
33. Просим оставить производительность и функциональность, исключив внутреннюю структуру 3D-контента.
34. Видеоролики должны иметь продолжительность строго от 5 до 15 минут.
35. ТС утверждает, что диапазон обусловлен физиологическими нормами удержания внимания.
36. Однако нормативный документ либо исследование не указаны.
37. Учебный ролик продолжительностью 4 минуты либо 16 минут формально становится несоответствующим.
38. Просим предоставить нормативное основание либо убрать жесткий диапазон.
39. Ограничение максимального размера видео установлено «не менее 500 МБ», что также сформулировано неоднозначно.
40. Если это максимальный допустимый размер загрузки, корректно требовать способность загружать файл размером не менее 500 МБ.
41. Просим отредактировать формулировку.
42. Игровой сервер должен обеспечивать задержку не более 300 мс.
43. Подключение учащегося после QR-сканирования — не более 5 секунд.
44. При этом условие связано со «стабильным интернет-соединением», параметры которого не определены.
45. Не указана скорость.
46. Не указан ping.
47. Не указан packet loss.
48. Не указано, кто предоставляет Интернет при приемке.
49. Невозможно возлагать на ПО ответственность за 5 секунд, если интернет-канал Заказчика не нормирован.
50. Еще более спорна интеграция с аппаратно-программным комплексом беспроводных датчиков.
51. Требуется не менее 15 различных типов датчиков.
52. Приемник обязан сам формировать Wi-Fi Access Point.
53. Каждый датчик обязан быть Wi-Fi Station.
54. Подключение за максимум 10 секунд.
55. Переподключение каждые максимум 5 секунд.
56. Обмен должен осуществляться строго WebSocket RFC 6455.
57. Все сообщения должны быть именно JSON.
58. Это конкретная программная архитектура.
59. Альтернативная система на MQTT, HTTP/2, BLE, Zigbee либо собственном защищенном бинарном протоколе может иметь меньшую задержку, лучшую автономность и большую устойчивость.
60. Использование WebSocket и JSON само по себе не является образовательным результатом.
61. Просим заменить их требованием к задержке, надежности и совместимости.
62. Каждый датчик должен иметь ID минимум 8 символов, передавать RSSI и заряд аккумулятора.
63. Почему ID из 6 либо 16 символов хуже — не раскрыто.
64. Аккумулятор каждого датчика должен быть минимум 1000 мА·ч.
65. Однако ключевой результат уже установлен — автономность минимум 24 часа при передаче каждую секунду.
66. При одинаковой автономности датчик с энергоэффективной электроникой и АКБ 800 мА·ч не должен считаться хуже.
67. Просим оставить автономность и исключить минимальную емкость как внутреннюю конструкцию.
68. В ТС установлен строго определенный перечень 15 каналов: температура, влажность, давление, скорость ветра, освещенность, газ, уровень сигнала, напряжение, заряд внешней батареи, универсальный канал, гироскоп, магнитометр, акселерометр, звук, спектральный/ИК-датчик.
69. Просим указать образовательную методику и лабораторные работы, для которых требуются именно все 15 каналов.
70. Особенно неясен «датчик уровня сигнала» в форме радиочастотного монитора либо специализированного микрофона/анализатора радиоэфира.
71. Радиочастотный уровень в дБ и акустический уровень являются физически различными величинами.
72. Формулировка «радиочастотный монитор или специализированный микрофон» смешивает принципиально разные измерительные устройства.
73. Просим исправить.
74. Оптический канал также назван спектральным либо инфракрасным датчиком, но измеряемая величина указывается в люксах.
75. Люкс является единицей освещенности, а не универсальной спектральной характеристикой.
76. Не определено, какие именно спектральные данные должен измерять канал.
77. Просим конкретизировать либо оставить обычный измеримый функционал.
78. Интерфейс датчиков описан буквально по дизайну.
79. Обязательна Dark Theme.
80. Черный/темно-серый фон.
81. Название наподобие Sensor Hub.
82. Пиктограмма микрочипа.
83. Ровно 15 карточек в Grid-layout.
84. Иконка в левом верхнем углу.
85. Номер канала справа сверху в овале либо круге.
86. Значение по центру.
87. График за 10 минут.
88. Статус «НЕАКТИВЕН» строго на красном фоне в форме стилизованной таблетки/кнопки.
89. Это прямое описание визуального интерфейса конкретного продукта.
90. Цвет и форма кнопки не влияют на точность измерения датчика.
91. Поставщик с более современным либо светлым интерфейсом формально будет отклонен.
92. Просим исключить дизайн и оставить обязательность отображения показания, единицы измерения, графика, заряда, связи и статуса.
93. Существенно ограничивают конкуренцию и обязательные документы.
94. Участник обязан предоставить авторизационное письмо производителя на право поставки.
95. Письмо должно содержать QR-код/ссылку для проверки на официальном сайте.
96. Дополнительно требуются документы о праве реализации/распространения, при этом прямо упоминается авторское право на исходный код ПО.
97. Для иностранной продукции официальный представитель либо дистрибьютор в Казахстане должен подтвердить право представлять иностранную компанию.
98. Замена документов гарантийным письмом участника прямо запрещена.
99. ТС прямо указывает, что письма должны существовать уже на стадии рассмотрения заявок и выдаются производителем, правообладателем либо дистрибьютором по предварительному запросу участника.
100. Это означает прямую зависимость допуска к закупке от коммерческого решения третьего лица.
101. Помимо этого потенциальный поставщик должен предоставить сразу пять специальных протоколов от независимой испытательной лаборатории, аккредитованной NCA РК.
102. Протокол обследования сетевой инфраструктуры.
103. Протокол обследования процессов обеспечения информационной безопасности.
104. Протокол нагрузочного испытания.
105. Протокол анализа исходных кодов SAST.
106. Протокол испытаний функций информационной безопасности по СТ РК ISO/IEC 15408-2-2017.
107. Непредоставление хотя бы одного документа прямо объявлено основанием несоответствия.
108. Такая совокупность способна идентифицировать конкретный заранее протестированный продукт.
109. Новый либо иностранный программный продукт с высоким уровнем безопасности не сможет участвовать, если именно на него ранее не проведен весь набор испытаний в аккредитованной в РК лаборатории.
110. Особо ограничивающим является SAST-протокол.
111. Для проведения анализа исходного кода разработчик должен предоставить лаборатории доступ к исходному коду.
112. Независимый дилер или интегратор не распоряжается исходным кодом и не может самостоятельно заказать такое испытание без участия разработчика.
113. Следовательно, возможность участия опять зависит от правообладателя.
114. Просим Заказчика назвать не менее трех независимых программных продуктов разных разработчиков, по каждому из которых уже существуют все пять действующих протоколов NCA РК и которые одновременно отвечают 18-модульной архитектуре, 1000 подключениям и комплексу 15 датчиков.
115. Если таких минимум трех решений нет, просим исключить либо существенно смягчить требования, фактически фиксирующие заранее протестированный продукт и конкретную архитектуру.
2. ТС определяет не только конечные образовательные функции, но и внутреннюю архитектуру ПО.
3. Установлен обязательный клиент-серверный принцип.
4. Обязательная трехуровневая модель: сервер базы данных, сервер приложений, клиентское приложение.
5. Обязательная микросервисная либо сервис-ориентированная архитектура.
6. Требуется не менее 18 выделенных логических модулей.
7. Заказчик фактически перечисляет внутреннюю декомпозицию программного продукта: авторизация, управление сессиями и токенами, файловое хранилище, 3D-рендеринг, видео, субтитры, задания, игровой сервер, постоянное двустороннее соединение, QR, статистика, резервное копирование, мониторинг серверов, централизованное логирование, CMS, маршрутизация, статические ресурсы и криптографическая защита.
8. Количество внутренних сервисов не характеризует качество образовательного результата.
9. Система с 10 модулями может выполнять тот же функционал.
10. Система с монолитной архитектурой может быть надежнее и проще в сопровождении.
11. И наоборот, система с 30 микросервисами не является автоматически лучше.
12. Следовательно, обязательность не менее 18 внутренних модулей ограничивает архитектурно и не связана напрямую с потребностями лицея.
13. Аналогично обязательный reverse proxy и конкретные алгоритмы распределения нагрузки относятся к реализации серверной инфраструктуры разработчиком.
14. Заказчику объективно важны доступность, производительность и безопасность, а не способ внутренней маршрутизации HTTP-запросов.
15. Отдельно требуется масштабирование до не менее 1000 одновременно активных подключений.
16. При этом в поставке предусмотрено 29 моноблоков.
17. Не раскрыто, почему одному учебному комплекту требуется одновременно 1000 активных пользователей.
18. Далее системные требования самого сервера отдельно сформулированы для одновременной работы до 100 пользователей.
19. Возникает внутренний вопрос: архитектура должна выдерживать 1000 пользователей, однако минимальный сервер рассчитывается только на 100.
20. Просим определить фактически требуемую нагрузку и методику ее проверки.
21. Если речь идет о 29 учебных рабочих местах, достаточный запас должен определяться разумным коэффициентом, а не характеристикой корпоративной платформы на 1000 подключений.
22. Требования к 3D-подсистеме также чрезмерно подробны.
23. 3D-модель должна иметь не более 100 000 полигонов.
24. Частота — минимум 30 кадров/с.
25. Не менее 10 конкретных функций взаимодействия.
26. Не менее 10 интерактивных точек.
27. Текстовые карточки минимум 500 символов.
28. Не менее трех заранее сохраненных ракурсов.
29. Формат конфигурации описан через иерархическую структуру «атрибут-значение».
30. Такие требования скорее описывают внутренний формат существующего контента.
31. Например, модель с 150 000 оптимизированных полигонов может визуально быть качественнее и работать быстрее на современном GPU, но формально выходит за ограничение.
32. Неясно, почему максимальное количество полигонов вообще является требованием к поставщику, если ключевой результат — стабильные 30 FPS.
33. Просим оставить производительность и функциональность, исключив внутреннюю структуру 3D-контента.
34. Видеоролики должны иметь продолжительность строго от 5 до 15 минут.
35. ТС утверждает, что диапазон обусловлен физиологическими нормами удержания внимания.
36. Однако нормативный документ либо исследование не указаны.
37. Учебный ролик продолжительностью 4 минуты либо 16 минут формально становится несоответствующим.
38. Просим предоставить нормативное основание либо убрать жесткий диапазон.
39. Ограничение максимального размера видео установлено «не менее 500 МБ», что также сформулировано неоднозначно.
40. Если это максимальный допустимый размер загрузки, корректно требовать способность загружать файл размером не менее 500 МБ.
41. Просим отредактировать формулировку.
42. Игровой сервер должен обеспечивать задержку не более 300 мс.
43. Подключение учащегося после QR-сканирования — не более 5 секунд.
44. При этом условие связано со «стабильным интернет-соединением», параметры которого не определены.
45. Не указана скорость.
46. Не указан ping.
47. Не указан packet loss.
48. Не указано, кто предоставляет Интернет при приемке.
49. Невозможно возлагать на ПО ответственность за 5 секунд, если интернет-канал Заказчика не нормирован.
50. Еще более спорна интеграция с аппаратно-программным комплексом беспроводных датчиков.
51. Требуется не менее 15 различных типов датчиков.
52. Приемник обязан сам формировать Wi-Fi Access Point.
53. Каждый датчик обязан быть Wi-Fi Station.
54. Подключение за максимум 10 секунд.
55. Переподключение каждые максимум 5 секунд.
56. Обмен должен осуществляться строго WebSocket RFC 6455.
57. Все сообщения должны быть именно JSON.
58. Это конкретная программная архитектура.
59. Альтернативная система на MQTT, HTTP/2, BLE, Zigbee либо собственном защищенном бинарном протоколе может иметь меньшую задержку, лучшую автономность и большую устойчивость.
60. Использование WebSocket и JSON само по себе не является образовательным результатом.
61. Просим заменить их требованием к задержке, надежности и совместимости.
62. Каждый датчик должен иметь ID минимум 8 символов, передавать RSSI и заряд аккумулятора.
63. Почему ID из 6 либо 16 символов хуже — не раскрыто.
64. Аккумулятор каждого датчика должен быть минимум 1000 мА·ч.
65. Однако ключевой результат уже установлен — автономность минимум 24 часа при передаче каждую секунду.
66. При одинаковой автономности датчик с энергоэффективной электроникой и АКБ 800 мА·ч не должен считаться хуже.
67. Просим оставить автономность и исключить минимальную емкость как внутреннюю конструкцию.
68. В ТС установлен строго определенный перечень 15 каналов: температура, влажность, давление, скорость ветра, освещенность, газ, уровень сигнала, напряжение, заряд внешней батареи, универсальный канал, гироскоп, магнитометр, акселерометр, звук, спектральный/ИК-датчик.
69. Просим указать образовательную методику и лабораторные работы, для которых требуются именно все 15 каналов.
70. Особенно неясен «датчик уровня сигнала» в форме радиочастотного монитора либо специализированного микрофона/анализатора радиоэфира.
71. Радиочастотный уровень в дБ и акустический уровень являются физически различными величинами.
72. Формулировка «радиочастотный монитор или специализированный микрофон» смешивает принципиально разные измерительные устройства.
73. Просим исправить.
74. Оптический канал также назван спектральным либо инфракрасным датчиком, но измеряемая величина указывается в люксах.
75. Люкс является единицей освещенности, а не универсальной спектральной характеристикой.
76. Не определено, какие именно спектральные данные должен измерять канал.
77. Просим конкретизировать либо оставить обычный измеримый функционал.
78. Интерфейс датчиков описан буквально по дизайну.
79. Обязательна Dark Theme.
80. Черный/темно-серый фон.
81. Название наподобие Sensor Hub.
82. Пиктограмма микрочипа.
83. Ровно 15 карточек в Grid-layout.
84. Иконка в левом верхнем углу.
85. Номер канала справа сверху в овале либо круге.
86. Значение по центру.
87. График за 10 минут.
88. Статус «НЕАКТИВЕН» строго на красном фоне в форме стилизованной таблетки/кнопки.
89. Это прямое описание визуального интерфейса конкретного продукта.
90. Цвет и форма кнопки не влияют на точность измерения датчика.
91. Поставщик с более современным либо светлым интерфейсом формально будет отклонен.
92. Просим исключить дизайн и оставить обязательность отображения показания, единицы измерения, графика, заряда, связи и статуса.
93. Существенно ограничивают конкуренцию и обязательные документы.
94. Участник обязан предоставить авторизационное письмо производителя на право поставки.
95. Письмо должно содержать QR-код/ссылку для проверки на официальном сайте.
96. Дополнительно требуются документы о праве реализации/распространения, при этом прямо упоминается авторское право на исходный код ПО.
97. Для иностранной продукции официальный представитель либо дистрибьютор в Казахстане должен подтвердить право представлять иностранную компанию.
98. Замена документов гарантийным письмом участника прямо запрещена.
99. ТС прямо указывает, что письма должны существовать уже на стадии рассмотрения заявок и выдаются производителем, правообладателем либо дистрибьютором по предварительному запросу участника.
100. Это означает прямую зависимость допуска к закупке от коммерческого решения третьего лица.
101. Помимо этого потенциальный поставщик должен предоставить сразу пять специальных протоколов от независимой испытательной лаборатории, аккредитованной NCA РК.
102. Протокол обследования сетевой инфраструктуры.
103. Протокол обследования процессов обеспечения информационной безопасности.
104. Протокол нагрузочного испытания.
105. Протокол анализа исходных кодов SAST.
106. Протокол испытаний функций информационной безопасности по СТ РК ISO/IEC 15408-2-2017.
107. Непредоставление хотя бы одного документа прямо объявлено основанием несоответствия.
108. Такая совокупность способна идентифицировать конкретный заранее протестированный продукт.
109. Новый либо иностранный программный продукт с высоким уровнем безопасности не сможет участвовать, если именно на него ранее не проведен весь набор испытаний в аккредитованной в РК лаборатории.
110. Особо ограничивающим является SAST-протокол.
111. Для проведения анализа исходного кода разработчик должен предоставить лаборатории доступ к исходному коду.
112. Независимый дилер или интегратор не распоряжается исходным кодом и не может самостоятельно заказать такое испытание без участия разработчика.
113. Следовательно, возможность участия опять зависит от правообладателя.
114. Просим Заказчика назвать не менее трех независимых программных продуктов разных разработчиков, по каждому из которых уже существуют все пять действующих протоколов NCA РК и которые одновременно отвечают 18-модульной архитектуре, 1000 подключениям и комплексу 15 датчиков.
115. Если таких минимум трех решений нет, просим исключить либо существенно смягчить требования, фактически фиксирующие заранее протестированный продукт и конкретную архитектуру.
