Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1070038
Тема сообщения
ТС ФАКТИЧЕСКИ ОПИСЫВАЕТ РАЗРАБОТКУ КОНКРЕТНОГО ПО
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-10-09 01:11:57
Текст сообщения
1. Раздел «Программное обеспечение для интерактивного обучения» необходимо полностью переработать, поскольку текущая редакция выходит далеко за пределы описания требуемого образовательного результата и фактически устанавливает внутреннюю архитектуру, технологический стек, структуру модулей и элементы пользовательского интерфейса конкретного программного продукта.
2. Заказчику объективно может требоваться интерактивная образовательная платформа с 3D-контентом, видео, тестами, статистикой и возможностью подключения учащихся.
3. Однако способ программной реализации данных функций не должен быть жестко установлен, если он не влияет на конечный образовательный результат.
4. ТС требует клиент-серверную архитектуру с трехуровневой моделью: сервер базы данных, сервер приложений и клиентское приложение.
5. Дополнительно архитектура должна быть микросервисной либо сервис-ориентированной.
6. Просим исключить обязательный тип внутренней архитектуры.
7. Монолитное, модульное, облачное, контейнеризованное либо иное решение может обеспечивать идентичные функции и показатели надежности.
8. Заказчик должен устанавливать SLA и производительность, а не способ написания программы.
9. Далее система должна включать не менее 18 выделенных логических модулей.
10. Перечисляется фактически внутренняя схема продукта: авторизация, токены, хранилище, 3D, потоковое видео, субтитры, игровой сервер, двусторонняя связь, QR, статистика, резервное копирование, мониторинг, логирование, CMS, маршрутизация, статические ресурсы, криптографическая защита.
11. Аналогичные функции другой системы могут быть реализованы в 6, 10, 20 или 30 внутренних компонентах.
12. Пользователь не видит количество программных модулей.
13. Число «18» не характеризует качество обучения.
14. Просим заменить требование перечнем функций без требования к числу внутренних сервисов.
15. Еще более специфично условие обязательного применения механизма reverse proxy.
16. Указывается терминирование защищенных соединений.
17. Распределение запросов между внутренними сервисами по round-robin либо least connections.
18. Защита от DoS/DDoS.
19. Заказчику объективно необходима защищенность и устойчивость системы.
20. Но выбор reverse proxy, API gateway, cloud load balancer, ingress controller, CDN/WAF или другой схемы относится к архитектурным решениям разработчика.
21. Просим оставить результат: балансировку, защищенное соединение, отказоустойчивость и защиту от сетевых атак.
22. Удалить конкретный внутренний механизм.
23. Требование не менее 1000 одновременно активных соединений также требует обоснования.
24. Далее в системных требованиях серверные ресурсы описаны как минимально необходимые для одновременной работы до 100 пользователей.
25. Возникает несоответствие между расчетной нагрузкой 100 пользователей и обязательной способностью обслуживать 1000 активных соединений.
26. Просим указать предполагаемое фактическое количество пользователей школы и пиковую нагрузку.
27. Не следует завышать масштабирование в 10 раз без подтвержденной потребности.
28. В ТС установлен показатель простоя не более 1% в год.
29. Просим выразить его стандартным SLA доступности и указать порядок расчета.
30. Непонятно, исключаются ли плановые профилактические работы.
31. По 3D-модулю ТС фактически описывает 3D-движок.
32. Устанавливаются типы освещения.
33. диффузные текстуры.
34. карты нормалей.
35. матричные координатные преобразования.
36. модель до 100 000 полигонов.
37. не менее 30 FPS.
38. десять конкретных пользовательских операций.
39. минимум десять интерактивных точек.
40. всплывающий текст минимум 500 символов.
41. минимум три сохраненных ракурса.
42. подсветка контура.
43. возврат одной кнопкой.
44. автоматическое вращение по вертикальной оси.
45. Большинство перечисленного представляет способ реализации конкретного 3D-просмотрщика.
46. Другая образовательная система может использовать современные форматы glTF, WebGL/WebGPU или собственный движок с иной логикой и обеспечить более качественную визуализацию.
47. Просим оставить только возможность интерактивно просматривать, вращать, масштабировать и изучать составные части 3D-моделей.
48. Количество полигонов само по себе не является показателем качества.
49. Модель на 60 000 полигонов с оптимизированными текстурами может выглядеть лучше модели на 100 000.
50. Аналогично 500 символов пояснения к каждой точке — это не минимальная педагогическая необходимость.
51. По видеомодулю ограничение продолжительности каждого файла от 5 до 15 минут является необоснованным техническим фильтром.
52. Учебный ролик может длиться 3 минуты и эффективно раскрывать тему.
53. Может длиться 20 минут и быть методически обоснован.
54. Просим убрать нижнюю и верхнюю границу либо оставить рекомендованные значения.
55. Указанная в ТС ссылка на «физиологические нормы удержания внимания» не содержит конкретного нормативного документа.
56. Просим предоставить нормативное основание именно диапазона 5–15 минут.
57. Требование встроенного видеоплеера ровно с определенным набором восьми функций также является UI-ориентированным.
58. Если другой плеер дополнительно имеет регулировку скорости, выбор разрешения, закладки и другие функции, он не должен исключаться из-за иной компоновки интерфейса.
59. Графическая панель описана еще более детально.
60. Требуются минимум десять инструментов.
61. десять базовых цветов.
62. возможность HEX.
63. 16 миллионов оттенков.
64. минимум пять толщин линий.
65. определенный набор геометрических фигур.
66. история минимум из десяти шагов.
67. векторное хранение аннотаций именно в памяти клиентского устройства.
68. Просим исключить требования к внутреннему месту и формату хранения аннотаций.
69. Важно лишь, чтобы учитель мог делать пометки, сохранять их в рамках занятия и при необходимости отменять действия.
70. Игровой модуль также детализирован до уровня программной реализации.
71. Указывается мастер-страница и страницы игроков.
72. полнодуплексный событийный протокол.
73. восемь видов транзакций.
74. конкретная логика QR-подключения.
75. время подключения не более пяти секунд.
76. конкретные диапазоны таймера.
77. динамическое начисление баллов.
78. рейтинг после каждого раунда.
79. Возможны десятки иных UX-сценариев, обеспечивающих тот же образовательный результат.
80. Просим оставить возможность интерактивного тестирования учащихся, автоматического подсчета результатов и групповой статистики.
81. Отдельное замечание касается формулировки, что QR-код должен содержать именно зашифрованную гиперссылку.
82. Можно использовать одноразовый код, room ID, NFC, короткую ссылку или другой безопасный способ присоединения.
83. Просим не ограничивать технологию подключения.
84. UI/UX-раздел также доходит до количества кликов, семейства шрифтов, одинакового радиуса скругления графических элементов и точного размера touch target 44×44 пикселя.
85. Доступность интерфейса является обоснованной целью.
86. Однако требование идентичного радиуса скругления не имеет функционального значения.
87. Оно описывает дизайн-систему продукта.
88. Максимум три клика до любого базового действия также невозможно объективно применить ко всем сценариям.
89. Просим заменить на общий критерий удобства и адаптивности.
90. ТС должна быть нейтральной к технологии реализации.
91. Требования к архитектуре базы данных, API, числу сервисов, способу маршрутизации запросов, формату внутренних конфигурационных файлов и месту хранения аннотаций должны быть исключены.
92. Заказчику следует контролировать конечный результат: доступность, скорость, безопасность, функционал, поддержку пользователей и образовательный контент.
93. Особенно недопустимо сочетать столь уникальное архитектурное описание с авторизационным письмом производителя и пакетом специальных испытательных протоколов.
94. Такое сочетание объективно снижает вероятность участия разработчиков альтернативных платформ.
95. Просим установить функционально нейтральную редакцию, допускающую различное программное обеспечение, обеспечивающее необходимый образовательный результат.
2. Заказчику объективно может требоваться интерактивная образовательная платформа с 3D-контентом, видео, тестами, статистикой и возможностью подключения учащихся.
3. Однако способ программной реализации данных функций не должен быть жестко установлен, если он не влияет на конечный образовательный результат.
4. ТС требует клиент-серверную архитектуру с трехуровневой моделью: сервер базы данных, сервер приложений и клиентское приложение.
5. Дополнительно архитектура должна быть микросервисной либо сервис-ориентированной.
6. Просим исключить обязательный тип внутренней архитектуры.
7. Монолитное, модульное, облачное, контейнеризованное либо иное решение может обеспечивать идентичные функции и показатели надежности.
8. Заказчик должен устанавливать SLA и производительность, а не способ написания программы.
9. Далее система должна включать не менее 18 выделенных логических модулей.
10. Перечисляется фактически внутренняя схема продукта: авторизация, токены, хранилище, 3D, потоковое видео, субтитры, игровой сервер, двусторонняя связь, QR, статистика, резервное копирование, мониторинг, логирование, CMS, маршрутизация, статические ресурсы, криптографическая защита.
11. Аналогичные функции другой системы могут быть реализованы в 6, 10, 20 или 30 внутренних компонентах.
12. Пользователь не видит количество программных модулей.
13. Число «18» не характеризует качество обучения.
14. Просим заменить требование перечнем функций без требования к числу внутренних сервисов.
15. Еще более специфично условие обязательного применения механизма reverse proxy.
16. Указывается терминирование защищенных соединений.
17. Распределение запросов между внутренними сервисами по round-robin либо least connections.
18. Защита от DoS/DDoS.
19. Заказчику объективно необходима защищенность и устойчивость системы.
20. Но выбор reverse proxy, API gateway, cloud load balancer, ingress controller, CDN/WAF или другой схемы относится к архитектурным решениям разработчика.
21. Просим оставить результат: балансировку, защищенное соединение, отказоустойчивость и защиту от сетевых атак.
22. Удалить конкретный внутренний механизм.
23. Требование не менее 1000 одновременно активных соединений также требует обоснования.
24. Далее в системных требованиях серверные ресурсы описаны как минимально необходимые для одновременной работы до 100 пользователей.
25. Возникает несоответствие между расчетной нагрузкой 100 пользователей и обязательной способностью обслуживать 1000 активных соединений.
26. Просим указать предполагаемое фактическое количество пользователей школы и пиковую нагрузку.
27. Не следует завышать масштабирование в 10 раз без подтвержденной потребности.
28. В ТС установлен показатель простоя не более 1% в год.
29. Просим выразить его стандартным SLA доступности и указать порядок расчета.
30. Непонятно, исключаются ли плановые профилактические работы.
31. По 3D-модулю ТС фактически описывает 3D-движок.
32. Устанавливаются типы освещения.
33. диффузные текстуры.
34. карты нормалей.
35. матричные координатные преобразования.
36. модель до 100 000 полигонов.
37. не менее 30 FPS.
38. десять конкретных пользовательских операций.
39. минимум десять интерактивных точек.
40. всплывающий текст минимум 500 символов.
41. минимум три сохраненных ракурса.
42. подсветка контура.
43. возврат одной кнопкой.
44. автоматическое вращение по вертикальной оси.
45. Большинство перечисленного представляет способ реализации конкретного 3D-просмотрщика.
46. Другая образовательная система может использовать современные форматы glTF, WebGL/WebGPU или собственный движок с иной логикой и обеспечить более качественную визуализацию.
47. Просим оставить только возможность интерактивно просматривать, вращать, масштабировать и изучать составные части 3D-моделей.
48. Количество полигонов само по себе не является показателем качества.
49. Модель на 60 000 полигонов с оптимизированными текстурами может выглядеть лучше модели на 100 000.
50. Аналогично 500 символов пояснения к каждой точке — это не минимальная педагогическая необходимость.
51. По видеомодулю ограничение продолжительности каждого файла от 5 до 15 минут является необоснованным техническим фильтром.
52. Учебный ролик может длиться 3 минуты и эффективно раскрывать тему.
53. Может длиться 20 минут и быть методически обоснован.
54. Просим убрать нижнюю и верхнюю границу либо оставить рекомендованные значения.
55. Указанная в ТС ссылка на «физиологические нормы удержания внимания» не содержит конкретного нормативного документа.
56. Просим предоставить нормативное основание именно диапазона 5–15 минут.
57. Требование встроенного видеоплеера ровно с определенным набором восьми функций также является UI-ориентированным.
58. Если другой плеер дополнительно имеет регулировку скорости, выбор разрешения, закладки и другие функции, он не должен исключаться из-за иной компоновки интерфейса.
59. Графическая панель описана еще более детально.
60. Требуются минимум десять инструментов.
61. десять базовых цветов.
62. возможность HEX.
63. 16 миллионов оттенков.
64. минимум пять толщин линий.
65. определенный набор геометрических фигур.
66. история минимум из десяти шагов.
67. векторное хранение аннотаций именно в памяти клиентского устройства.
68. Просим исключить требования к внутреннему месту и формату хранения аннотаций.
69. Важно лишь, чтобы учитель мог делать пометки, сохранять их в рамках занятия и при необходимости отменять действия.
70. Игровой модуль также детализирован до уровня программной реализации.
71. Указывается мастер-страница и страницы игроков.
72. полнодуплексный событийный протокол.
73. восемь видов транзакций.
74. конкретная логика QR-подключения.
75. время подключения не более пяти секунд.
76. конкретные диапазоны таймера.
77. динамическое начисление баллов.
78. рейтинг после каждого раунда.
79. Возможны десятки иных UX-сценариев, обеспечивающих тот же образовательный результат.
80. Просим оставить возможность интерактивного тестирования учащихся, автоматического подсчета результатов и групповой статистики.
81. Отдельное замечание касается формулировки, что QR-код должен содержать именно зашифрованную гиперссылку.
82. Можно использовать одноразовый код, room ID, NFC, короткую ссылку или другой безопасный способ присоединения.
83. Просим не ограничивать технологию подключения.
84. UI/UX-раздел также доходит до количества кликов, семейства шрифтов, одинакового радиуса скругления графических элементов и точного размера touch target 44×44 пикселя.
85. Доступность интерфейса является обоснованной целью.
86. Однако требование идентичного радиуса скругления не имеет функционального значения.
87. Оно описывает дизайн-систему продукта.
88. Максимум три клика до любого базового действия также невозможно объективно применить ко всем сценариям.
89. Просим заменить на общий критерий удобства и адаптивности.
90. ТС должна быть нейтральной к технологии реализации.
91. Требования к архитектуре базы данных, API, числу сервисов, способу маршрутизации запросов, формату внутренних конфигурационных файлов и месту хранения аннотаций должны быть исключены.
92. Заказчику следует контролировать конечный результат: доступность, скорость, безопасность, функционал, поддержку пользователей и образовательный контент.
93. Особенно недопустимо сочетать столь уникальное архитектурное описание с авторизационным письмом производителя и пакетом специальных испытательных протоколов.
94. Такое сочетание объективно снижает вероятность участия разработчиков альтернативных платформ.
95. Просим установить функционально нейтральную редакцию, допускающую различное программное обеспечение, обеспечивающее необходимый образовательный результат.
