Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069840
Тема сообщения
ПО НА 18 МОДУЛЕЙ, 1000 ПОЛЬЗОВАТЕЛЕЙ, СЕРВЕРНАЯ АРХИТЕКТУРА И 15 ДАТЧИКОВ
Тип сообщения
Замечание к АД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-10-07 19:50:17
Текст сообщения
1. Раздел технической спецификации, посвященный интерактивному образовательному программному обеспечению и аппаратно-программному комплексу датчиков, содержит признаки описания заранее сформированного программного продукта и его внутренней архитектуры вместо определения необходимого образовательного результата.
2. Заказчик требует не просто образовательную платформу с 3D-контентом, видео, тестированием и аналитикой.
3. ТС фактически определяет внутреннюю программную архитектуру разработчика.
4. Система должна быть построена по клиент-серверному принципу.
5. Должна использовать трехуровневую модель.
6. Отдельно указаны сервер базы данных, сервер приложений и клиентское приложение.
7. Требуется микросервисная либо сервис-ориентированная архитектура.
8. Система должна включать не менее 18 выделенных логических модулей.
9. Модули должны взаимодействовать через внутренние API.
10. Поименован каждый модуль.
11. Авторизация.
12. Управление сессиями и токенами.
13. Файловое хранилище.
14. 3D-рендеринг.
15. Потоковое видео.
16. Мультиязычные субтитры.
17. Интерактивные задания.
18. Игровой сервер.
19. Постоянное двустороннее соединение.
20. QR-генератор.
21. Статистика.
22. Резервное копирование.
23. Мониторинг серверных мощностей.
24. Централизованное логирование.
25. CMS.
26. Маршрутизация запросов.
27. Обработка статических ресурсов.
28. Криптографическая защита.
29. Для конечного пользователя принципиальное значение имеет наличие нужного функционала, а не то, разделил разработчик программу на 18, 20, 12 либо 30 внутренних логических модулей.
30. Разработчик альтернативного решения может реализовать тот же функционал в монолитной архитектуре либо ином количестве сервисов.
31. Это не делает его продукт хуже с точки зрения образовательной задачи.
32. Требование к внутренней архитектуре ограничивает эквивалентные программные решения.
33. Просим убрать количество внутренних модулей и требования к способу программной декомпозиции.
34. Аналогично необоснованно жестко установлена производительность не менее 1000 одновременно активных подключений.
35. Закупается один школьный учебный кабинет.
36. В самом комплекте предусмотрено 15 двухместных ученических парт, то есть ориентировочно 30 ученических мест.
37. Не раскрыто, зачем одному кабинету способность единовременно обслуживать 1000 активных соединений.
38. Требование почти в десятки раз превышает фактический размер аудитории.
39. Оно увеличивает инфраструктурную сложность и может служить характеристикой заранее существующего корпоративного продукта.
40. Просим установить нагрузку исходя из фактического количества пользователей кабинета с разумным запасом.
41. Например, не менее количества фактически предусмотренных ученических и преподавательских рабочих мест.
42. Не менее спорны требования к игровой подсистеме.
43. Сигнальная задержка должна составлять не более 300 мс.
44. Присоединение по QR-коду — не более 5 секунд.
45. Обязательно определенное количество типов транзакций.
46. Ответы, таймер, рейтинг, пересчет баллов и прочие процессы описаны фактически на уровне программной реализации.
47. Для системы аналитики жестко определено не менее шести метрик.
48. Предписаны именно круговые и столбчатые диаграммы.
49. Для интерфейса установлено не более трех логических переходов до ключевой функции.
50. Минимальный размер шрифта на мобильном устройстве — 14 пикселей.
51. Touch target — 44×44 пикселя.
52. Это фактически UX-спецификация конкретного программного решения.
53. Еще более специфичен аппаратно-программный комплекс беспроводных датчиков.
54. Требуется ровно/не менее 15 типов датчиков.
55. Приемник должен самостоятельно создавать локальную Wi-Fi сеть.
56. Точка доступа должна запуститься не более чем за 60 секунд.
57. Дальность на открытой местности — минимум 50 м.
58. Каждый датчик должен подключаться максимум за 10 секунд.
59. При потере связи повторное подключение должно происходить с интервалом не более 5 секунд.
60. Обмен данными должен осуществляться строго по WebSocket RFC 6455.
61. Каждое сообщение должно быть именно в JSON.
62. Задержка передачи данных должна составлять не более 500 мс.
63. Каждый модуль обязан иметь уникальный ID минимум из восьми символов.
64. Передавать заряд аккумулятора.
65. Передавать RSSI.
66. Иметь аккумулятор минимум 1000 мА·ч.
67. Работать минимум 24 часа при передаче данных каждую секунду.
68. Указанный набор описывает конкретную архитектуру комплекса.
69. Альтернативный образовательный измерительный комплекс может использовать MQTT, HTTP/2, BLE, Zigbee, собственный защищенный протокол либо бинарный формат данных.
70. При одинаковом конечном результате такой продукт формально не соответствует из-за отсутствия WebSocket/JSON.
71. Не приведено обоснование, почему именно WebSocket является единственным допустимым способом.
72. Не приведено обоснование, почему именно JSON является обязательным форматом.
73. Заказчику должен быть важен конечный результат: надежная передача показаний в реальном времени, допустимая задержка, автономность и возможность одновременной работы датчиков.
74. Протокол может быть технологически нейтральным.
75. Чрезмерно специфичен и интерфейс комплекса.
76. Он должен быть именно в темной цветовой схеме.
77. В шапке требуется наименование вроде Sensor Hub.
78. Требуется пиктограмма микрочипа.
79. Должно быть ровно 15 карточек.
80. У каждой карточки определенное расположение иконки, номера канала, текущего значения и графика.
81. Статус «НЕАКТИВЕН» должен отображаться в виде стилизованной таблетки/кнопки на красном фоне.
82. Такие требования описывают внешний вид конкретного интерфейса, а не образовательную функцию.
83. Поставщик с более понятным и современным интерфейсом иной цветовой схемы формально может быть отклонен.
84. Просим оставить требования к отображаемым данным, состоянию датчика и графику, но исключить конкретные цвета, позиции элементов и форму визуальных индикаторов.
85. Отдельно перечень измерительных модулей крайне разнороден.
86. Температура.
87. Влажность.
88. Атмосферное давление.
89. Скорость ветра.
90. Освещенность.
91. Газ.
92. Радиочастотный сигнал.
93. Напряжение.
94. Заряд батареи.
95. Логическое состояние.
96. Гироскоп.
97. Магнитометр.
98. Акселерометр.
99. Уровень звука.
100. Спектральный либо ИК-датчик.
101. Просим пояснить, к каким конкретным разделам школьной образовательной программы относится каждый из 15 модулей.
102. Особое сомнение вызывает датчик «сигнала» в виде внешнего радиочастотного монитора либо анализатора радиоэфира.
103. Для школьного кабинета необходимо определить его педагогическое назначение и безопасность применения.
104. По программной платформе также установлены RTO не более 4 часов, RPO не более 24 часов, серверный мониторинг каждую минуту, защищенность от XSS/SQL injection/CSRF, TLS 1.2, отдельный reverse proxy и иные корпоративные серверные требования.
105. Одновременно предмет закупки — один учебный кабинет стоимостью 9,1 млн тенге.
106. Просим обосновать соразмерность столь сложной серверной архитектуры фактическим образовательным потребностям одной школы.
107. В отсутствие такого обоснования просим заменить архитектурные параметры требованиями к функциональному результату, безопасности, производительности и доступности системы.
108. Просим также назвать минимум три независимых разработчика, продукты которых без индивидуальной доработки полностью соответствуют требованиям к 18 модулям, 1000 подключениям, игровому серверу, аналитике, 15 Wi-Fi датчикам, WebSocket/JSON и заданному интерфейсу.
109. Если таких продуктов нет, совокупность условий имеет выраженные признаки привязки к конкретному разработчику.
2. Заказчик требует не просто образовательную платформу с 3D-контентом, видео, тестированием и аналитикой.
3. ТС фактически определяет внутреннюю программную архитектуру разработчика.
4. Система должна быть построена по клиент-серверному принципу.
5. Должна использовать трехуровневую модель.
6. Отдельно указаны сервер базы данных, сервер приложений и клиентское приложение.
7. Требуется микросервисная либо сервис-ориентированная архитектура.
8. Система должна включать не менее 18 выделенных логических модулей.
9. Модули должны взаимодействовать через внутренние API.
10. Поименован каждый модуль.
11. Авторизация.
12. Управление сессиями и токенами.
13. Файловое хранилище.
14. 3D-рендеринг.
15. Потоковое видео.
16. Мультиязычные субтитры.
17. Интерактивные задания.
18. Игровой сервер.
19. Постоянное двустороннее соединение.
20. QR-генератор.
21. Статистика.
22. Резервное копирование.
23. Мониторинг серверных мощностей.
24. Централизованное логирование.
25. CMS.
26. Маршрутизация запросов.
27. Обработка статических ресурсов.
28. Криптографическая защита.
29. Для конечного пользователя принципиальное значение имеет наличие нужного функционала, а не то, разделил разработчик программу на 18, 20, 12 либо 30 внутренних логических модулей.
30. Разработчик альтернативного решения может реализовать тот же функционал в монолитной архитектуре либо ином количестве сервисов.
31. Это не делает его продукт хуже с точки зрения образовательной задачи.
32. Требование к внутренней архитектуре ограничивает эквивалентные программные решения.
33. Просим убрать количество внутренних модулей и требования к способу программной декомпозиции.
34. Аналогично необоснованно жестко установлена производительность не менее 1000 одновременно активных подключений.
35. Закупается один школьный учебный кабинет.
36. В самом комплекте предусмотрено 15 двухместных ученических парт, то есть ориентировочно 30 ученических мест.
37. Не раскрыто, зачем одному кабинету способность единовременно обслуживать 1000 активных соединений.
38. Требование почти в десятки раз превышает фактический размер аудитории.
39. Оно увеличивает инфраструктурную сложность и может служить характеристикой заранее существующего корпоративного продукта.
40. Просим установить нагрузку исходя из фактического количества пользователей кабинета с разумным запасом.
41. Например, не менее количества фактически предусмотренных ученических и преподавательских рабочих мест.
42. Не менее спорны требования к игровой подсистеме.
43. Сигнальная задержка должна составлять не более 300 мс.
44. Присоединение по QR-коду — не более 5 секунд.
45. Обязательно определенное количество типов транзакций.
46. Ответы, таймер, рейтинг, пересчет баллов и прочие процессы описаны фактически на уровне программной реализации.
47. Для системы аналитики жестко определено не менее шести метрик.
48. Предписаны именно круговые и столбчатые диаграммы.
49. Для интерфейса установлено не более трех логических переходов до ключевой функции.
50. Минимальный размер шрифта на мобильном устройстве — 14 пикселей.
51. Touch target — 44×44 пикселя.
52. Это фактически UX-спецификация конкретного программного решения.
53. Еще более специфичен аппаратно-программный комплекс беспроводных датчиков.
54. Требуется ровно/не менее 15 типов датчиков.
55. Приемник должен самостоятельно создавать локальную Wi-Fi сеть.
56. Точка доступа должна запуститься не более чем за 60 секунд.
57. Дальность на открытой местности — минимум 50 м.
58. Каждый датчик должен подключаться максимум за 10 секунд.
59. При потере связи повторное подключение должно происходить с интервалом не более 5 секунд.
60. Обмен данными должен осуществляться строго по WebSocket RFC 6455.
61. Каждое сообщение должно быть именно в JSON.
62. Задержка передачи данных должна составлять не более 500 мс.
63. Каждый модуль обязан иметь уникальный ID минимум из восьми символов.
64. Передавать заряд аккумулятора.
65. Передавать RSSI.
66. Иметь аккумулятор минимум 1000 мА·ч.
67. Работать минимум 24 часа при передаче данных каждую секунду.
68. Указанный набор описывает конкретную архитектуру комплекса.
69. Альтернативный образовательный измерительный комплекс может использовать MQTT, HTTP/2, BLE, Zigbee, собственный защищенный протокол либо бинарный формат данных.
70. При одинаковом конечном результате такой продукт формально не соответствует из-за отсутствия WebSocket/JSON.
71. Не приведено обоснование, почему именно WebSocket является единственным допустимым способом.
72. Не приведено обоснование, почему именно JSON является обязательным форматом.
73. Заказчику должен быть важен конечный результат: надежная передача показаний в реальном времени, допустимая задержка, автономность и возможность одновременной работы датчиков.
74. Протокол может быть технологически нейтральным.
75. Чрезмерно специфичен и интерфейс комплекса.
76. Он должен быть именно в темной цветовой схеме.
77. В шапке требуется наименование вроде Sensor Hub.
78. Требуется пиктограмма микрочипа.
79. Должно быть ровно 15 карточек.
80. У каждой карточки определенное расположение иконки, номера канала, текущего значения и графика.
81. Статус «НЕАКТИВЕН» должен отображаться в виде стилизованной таблетки/кнопки на красном фоне.
82. Такие требования описывают внешний вид конкретного интерфейса, а не образовательную функцию.
83. Поставщик с более понятным и современным интерфейсом иной цветовой схемы формально может быть отклонен.
84. Просим оставить требования к отображаемым данным, состоянию датчика и графику, но исключить конкретные цвета, позиции элементов и форму визуальных индикаторов.
85. Отдельно перечень измерительных модулей крайне разнороден.
86. Температура.
87. Влажность.
88. Атмосферное давление.
89. Скорость ветра.
90. Освещенность.
91. Газ.
92. Радиочастотный сигнал.
93. Напряжение.
94. Заряд батареи.
95. Логическое состояние.
96. Гироскоп.
97. Магнитометр.
98. Акселерометр.
99. Уровень звука.
100. Спектральный либо ИК-датчик.
101. Просим пояснить, к каким конкретным разделам школьной образовательной программы относится каждый из 15 модулей.
102. Особое сомнение вызывает датчик «сигнала» в виде внешнего радиочастотного монитора либо анализатора радиоэфира.
103. Для школьного кабинета необходимо определить его педагогическое назначение и безопасность применения.
104. По программной платформе также установлены RTO не более 4 часов, RPO не более 24 часов, серверный мониторинг каждую минуту, защищенность от XSS/SQL injection/CSRF, TLS 1.2, отдельный reverse proxy и иные корпоративные серверные требования.
105. Одновременно предмет закупки — один учебный кабинет стоимостью 9,1 млн тенге.
106. Просим обосновать соразмерность столь сложной серверной архитектуры фактическим образовательным потребностям одной школы.
107. В отсутствие такого обоснования просим заменить архитектурные параметры требованиями к функциональному результату, безопасности, производительности и доступности системы.
108. Просим также назвать минимум три независимых разработчика, продукты которых без индивидуальной доработки полностью соответствуют требованиям к 18 модулям, 1000 подключениям, игровому серверу, аналитике, 15 Wi-Fi датчикам, WebSocket/JSON и заданному интерфейсу.
109. Если таких продуктов нет, совокупность условий имеет выраженные признаки привязки к конкретному разработчику.
