Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1068677
Тема сообщения
Замечание к АД
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-09-24 19:10:01
Текст сообщения
1. Требования к лицензированному программному обеспечению для учебного процесса сформированы не через общую педагогическую задачу, а через чрезвычайно подробное описание содержания и пользовательского интерфейса конкретного программного продукта.
2. Программное обеспечение должно использоваться для изучения биологии.
3. Интерфейс должен быть не менее чем на русском, казахском и английском языках.
4. Весь образовательный контент также должен быть представлен минимум на трех языках.
5. Звуковое сопровождение должно быть на трех языках.
6. Само по себе требование трехъязычности может быть обосновано образовательными задачами.
7. Однако далее ТС содержит многосотенный перечень конкретных моделей, объектов, организмов, процессов, заболеваний, вирусов, бактерий, динозавров, органов, тканей, физиологических процессов и иных тем.
8. Такой перечень представляет собой фактически каталог конкретной библиотеки одного программного продукта.
9. При этом часть наименований повторяется.
10. Отдельные темы встречаются в перечне неоднократно.
11. Имеются неоднозначные и редакционно некорректные формулировки.
12. В результате альтернативный образовательный продукт может содержать большее количество качественных моделей по школьной программе, но не иметь одного случайно указанного объекта и формально быть отклонен.
13. Такой подход не позволяет оценивать образовательную эквивалентность.
14. Например, два программных комплекса могут полностью покрывать разделы цитологии, генетики, анатомии, ботаники, зоологии, эволюции и экологии, но использовать разный набор визуальных объектов.
15. Это не означает ухудшение педагогического результата.
16. Заказчику следует определить минимальные тематические разделы и минимальное количество моделей по каждому разделу.
17. Например, не менее определенного числа 3D-моделей по анатомии человека.
18. По клеточной биологии.
19. По генетике.
20. По ботанике.
21. По зоологии.
22. По микробиологии.
23. По экологии и эволюции.
24. Такой подход позволит сравнивать разные программные продукты.
25. Вместо этого ТС фиксирует названия практически каждого объекта внутренней библиотеки.
26. Еще более выраженная привязка содержится в описании пользовательского интерфейса.
27. ПО должно распознавать конкретный перечень жестов.
28. Одинарное нажатие.
29. Двойное нажатие.
30. Однократное нажатие двумя пальцами.
31. Двойное нажатие двумя пальцами.
32. Смахивание вверх, вниз, вправо и влево.
33. Нажатие и перетаскивание.
34. Нажатие и растягивание.
35. Сведение/разведение двумя пальцами.
36. Функциональный результат масштабирования и вращения моделей действительно необходим.
37. Но конкретный набор жестов интерфейса может различаться у разных разработчиков.
38. Программа может обеспечивать те же функции кнопками, мышью, стилусом или иными стандартными жестами.
39. Это не делает ее хуже.
40. Отдельно требуется вращение моделей и компонентов на 360 градусов.
41. Такое требование функционально понятно и может быть сохранено.
42. Однако дальнейшее описание определяет точное поведение игровых/учебных заданий.
43. В задании «Собрать объект» первые три движения должны подсвечиваться.
44. После трех движений подсветка должна отключаться.
45. В задании «Выбрать объект» после выбора должна появляться кнопка подтверждения.
46. Цвет фона просмотра моделей должен меняться более чем на четыре цвета.
47. Это уже описание конкретного UX конкретного продукта.
48. Наличие именно четырех или пяти цветов фона не характеризует педагогическое качество.
49. Аналогично отдельная функция поиска модели по названию является полезной, но способ ее реализации может различаться.
50. Особенно показательно требование возможности направить запрос в техническую поддержку непосредственно из интерфейса программы.
51. Альтернативный разработчик может предоставлять техническую поддержку через сайт, электронную почту, личный кабинет либо отдельный сервис.
52. Отсутствие встроенной кнопки обращения в поддержку не ухудшает образовательный функционал.
53. ТС требует отображать модели и анимации именно в разделе «Категории».
54. Это конкретное название элемента интерфейса.
55. У другого продукта аналогичный раздел может называться «Библиотека», «Темы», «Модели», «Каталог» либо «Курсы».
56. Формальное требование названия вкладки способно необоснованно исключать эквивалентные решения.
57. Наиболее явная привязка содержится в требовании режима «Автоматические вопросы».
58. После нажатия должны появиться три конкретные кнопки.
59. «Собрать объект».
60. «Выбрать объект».
61. «Сопоставить метку».
62. По существу это буквальное описание интерфейса конкретного программного продукта.
63. Заказчику следует требовать возможность интерактивного тестирования или автоматического формирования заданий, но не конкретные названия кнопок.
64. Также ТС требует, чтобы «кнопки действий» появлялись в сценах анимационного режима и обеспечивали переход к следующей анимации.
65. Это опять относится к внутреннему дизайну интерфейса.
66. Другой разработчик может использовать временную шкалу, стрелки, карточки либо автоматический переход.
67. Педагогический результат остается тем же.
68. Необходимо также уточнить тип лицензии.
69. Указана услуга подписки сроком один год.
70. Однако предмет закупки является поставкой двух комплектов кабинета.
71. Не определено, что происходит после окончания первого года.
72. Кабинет перестает иметь доступ к образовательному ПО?
73. Может ли школа продолжить работу с уже загруженным контентом?
74. Какова стоимость продления?
75. Предусмотрено ли автоматическое продление?
76. Включены ли обновления?
77. Включается ли техническая поддержка?
78. Какая учетная запись создается?
79. Лицензия привязана к панели, школе, пользователю или устройству?
80. Можно ли перенести лицензию на новую панель?
81. Требуется ли постоянный Интернет?
82. Можно ли использовать ПО офлайн?
83. Где хранятся трехмерные модели?
84. Каков объем загрузки?
85. Может ли контент использоваться после прекращения работы разработчика?
86. Эти эксплуатационные вопросы существенно важнее конкретного расположения кнопки в интерфейсе.
87. Дополнительно потенциальный поставщик обязан представить авторизационное письмо производителя программы.
88. В результате комбинация точного каталога моделей, точной логики интерфейса и обязательного письма разработчика фактически способна сформировать закрытую закупку одного программного продукта.
89. Просим заказчика провести анализ рынка и указать не менее трех независимых программных продуктов разных разработчиков, которые одновременно имеют весь перечисленный контент, трехъязычный интерфейс и озвучку, все указанные жесты, названия режимов, расположение функций и требуемую архитектуру.
90. Если таких продуктов нет, ТС необходимо переработать.
91. Следует сформулировать перечень обязательных учебных разделов.
92. Минимальное количество трехмерных моделей.
93. Требования к языкам.
94. Наличие интерактивного взаимодействия.
95. Возможность масштабирования и вращения.
96. Наличие заданий и тестирования.
97. Возможность поиска.
98. Совместимость с интерактивной панелью.
99. Но конкретные названия вкладок, кнопок, последовательность действий и состав каталога должны быть исключены.
100. Просим также разрешить эквивалентное ПО, обеспечивающее не меньший образовательный охват.
101. Просим исключить требования, которые невозможно объективно связать с результатом обучения.
102. Отдельно просим урегулировать эксплуатацию после окончания годовой подписки.
103. Без этого закупка создает последующую финансовую зависимость заказчика от конкретного правообладателя.
104. При необходимости продлевать лицензию ежегодно школа фактически становится зависимой от будущей ценовой политики разработчика.
105. Поэтому условия продления должны быть известны заранее либо лицензия должна предусматривать продолжение использования приобретенной версии без обязательной подписки.
2. Программное обеспечение должно использоваться для изучения биологии.
3. Интерфейс должен быть не менее чем на русском, казахском и английском языках.
4. Весь образовательный контент также должен быть представлен минимум на трех языках.
5. Звуковое сопровождение должно быть на трех языках.
6. Само по себе требование трехъязычности может быть обосновано образовательными задачами.
7. Однако далее ТС содержит многосотенный перечень конкретных моделей, объектов, организмов, процессов, заболеваний, вирусов, бактерий, динозавров, органов, тканей, физиологических процессов и иных тем.
8. Такой перечень представляет собой фактически каталог конкретной библиотеки одного программного продукта.
9. При этом часть наименований повторяется.
10. Отдельные темы встречаются в перечне неоднократно.
11. Имеются неоднозначные и редакционно некорректные формулировки.
12. В результате альтернативный образовательный продукт может содержать большее количество качественных моделей по школьной программе, но не иметь одного случайно указанного объекта и формально быть отклонен.
13. Такой подход не позволяет оценивать образовательную эквивалентность.
14. Например, два программных комплекса могут полностью покрывать разделы цитологии, генетики, анатомии, ботаники, зоологии, эволюции и экологии, но использовать разный набор визуальных объектов.
15. Это не означает ухудшение педагогического результата.
16. Заказчику следует определить минимальные тематические разделы и минимальное количество моделей по каждому разделу.
17. Например, не менее определенного числа 3D-моделей по анатомии человека.
18. По клеточной биологии.
19. По генетике.
20. По ботанике.
21. По зоологии.
22. По микробиологии.
23. По экологии и эволюции.
24. Такой подход позволит сравнивать разные программные продукты.
25. Вместо этого ТС фиксирует названия практически каждого объекта внутренней библиотеки.
26. Еще более выраженная привязка содержится в описании пользовательского интерфейса.
27. ПО должно распознавать конкретный перечень жестов.
28. Одинарное нажатие.
29. Двойное нажатие.
30. Однократное нажатие двумя пальцами.
31. Двойное нажатие двумя пальцами.
32. Смахивание вверх, вниз, вправо и влево.
33. Нажатие и перетаскивание.
34. Нажатие и растягивание.
35. Сведение/разведение двумя пальцами.
36. Функциональный результат масштабирования и вращения моделей действительно необходим.
37. Но конкретный набор жестов интерфейса может различаться у разных разработчиков.
38. Программа может обеспечивать те же функции кнопками, мышью, стилусом или иными стандартными жестами.
39. Это не делает ее хуже.
40. Отдельно требуется вращение моделей и компонентов на 360 градусов.
41. Такое требование функционально понятно и может быть сохранено.
42. Однако дальнейшее описание определяет точное поведение игровых/учебных заданий.
43. В задании «Собрать объект» первые три движения должны подсвечиваться.
44. После трех движений подсветка должна отключаться.
45. В задании «Выбрать объект» после выбора должна появляться кнопка подтверждения.
46. Цвет фона просмотра моделей должен меняться более чем на четыре цвета.
47. Это уже описание конкретного UX конкретного продукта.
48. Наличие именно четырех или пяти цветов фона не характеризует педагогическое качество.
49. Аналогично отдельная функция поиска модели по названию является полезной, но способ ее реализации может различаться.
50. Особенно показательно требование возможности направить запрос в техническую поддержку непосредственно из интерфейса программы.
51. Альтернативный разработчик может предоставлять техническую поддержку через сайт, электронную почту, личный кабинет либо отдельный сервис.
52. Отсутствие встроенной кнопки обращения в поддержку не ухудшает образовательный функционал.
53. ТС требует отображать модели и анимации именно в разделе «Категории».
54. Это конкретное название элемента интерфейса.
55. У другого продукта аналогичный раздел может называться «Библиотека», «Темы», «Модели», «Каталог» либо «Курсы».
56. Формальное требование названия вкладки способно необоснованно исключать эквивалентные решения.
57. Наиболее явная привязка содержится в требовании режима «Автоматические вопросы».
58. После нажатия должны появиться три конкретные кнопки.
59. «Собрать объект».
60. «Выбрать объект».
61. «Сопоставить метку».
62. По существу это буквальное описание интерфейса конкретного программного продукта.
63. Заказчику следует требовать возможность интерактивного тестирования или автоматического формирования заданий, но не конкретные названия кнопок.
64. Также ТС требует, чтобы «кнопки действий» появлялись в сценах анимационного режима и обеспечивали переход к следующей анимации.
65. Это опять относится к внутреннему дизайну интерфейса.
66. Другой разработчик может использовать временную шкалу, стрелки, карточки либо автоматический переход.
67. Педагогический результат остается тем же.
68. Необходимо также уточнить тип лицензии.
69. Указана услуга подписки сроком один год.
70. Однако предмет закупки является поставкой двух комплектов кабинета.
71. Не определено, что происходит после окончания первого года.
72. Кабинет перестает иметь доступ к образовательному ПО?
73. Может ли школа продолжить работу с уже загруженным контентом?
74. Какова стоимость продления?
75. Предусмотрено ли автоматическое продление?
76. Включены ли обновления?
77. Включается ли техническая поддержка?
78. Какая учетная запись создается?
79. Лицензия привязана к панели, школе, пользователю или устройству?
80. Можно ли перенести лицензию на новую панель?
81. Требуется ли постоянный Интернет?
82. Можно ли использовать ПО офлайн?
83. Где хранятся трехмерные модели?
84. Каков объем загрузки?
85. Может ли контент использоваться после прекращения работы разработчика?
86. Эти эксплуатационные вопросы существенно важнее конкретного расположения кнопки в интерфейсе.
87. Дополнительно потенциальный поставщик обязан представить авторизационное письмо производителя программы.
88. В результате комбинация точного каталога моделей, точной логики интерфейса и обязательного письма разработчика фактически способна сформировать закрытую закупку одного программного продукта.
89. Просим заказчика провести анализ рынка и указать не менее трех независимых программных продуктов разных разработчиков, которые одновременно имеют весь перечисленный контент, трехъязычный интерфейс и озвучку, все указанные жесты, названия режимов, расположение функций и требуемую архитектуру.
90. Если таких продуктов нет, ТС необходимо переработать.
91. Следует сформулировать перечень обязательных учебных разделов.
92. Минимальное количество трехмерных моделей.
93. Требования к языкам.
94. Наличие интерактивного взаимодействия.
95. Возможность масштабирования и вращения.
96. Наличие заданий и тестирования.
97. Возможность поиска.
98. Совместимость с интерактивной панелью.
99. Но конкретные названия вкладок, кнопок, последовательность действий и состав каталога должны быть исключены.
100. Просим также разрешить эквивалентное ПО, обеспечивающее не меньший образовательный охват.
101. Просим исключить требования, которые невозможно объективно связать с результатом обучения.
102. Отдельно просим урегулировать эксплуатацию после окончания годовой подписки.
103. Без этого закупка создает последующую финансовую зависимость заказчика от конкретного правообладателя.
104. При необходимости продлевать лицензию ежегодно школа фактически становится зависимой от будущей ценовой политики разработчика.
105. Поэтому условия продления должны быть известны заранее либо лицензия должна предусматривать продолжение использования приобретенной версии без обязательной подписки.
