Номер извещения: 0121200004725001427

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РТС-тендер

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://www.rts-tender.ru

Размещение осуществляет: Уполномоченный орган КОМИТЕТ СТАВРОПОЛЬСКОГО КРАЯ ПО ГОСУДАРСТВЕННЫМ ЗАКУПКАМ

Наименование объекта закупки: Оказание услуг по развитию государственной информационной системы Ставропольского края «Региональная информационная система в сфере образования для реализации предоставления государственных и муниципальных услуг в электронной форме»

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202501212000001001000044

Номер типовых условий контракта: 1400700000521003

Контактная информация

Размещение осуществляет: Уполномоченный орган

Организация, осуществляющая размещение: КОМИТЕТ СТАВРОПОЛЬСКОГО КРАЯ ПО ГОСУДАРСТВЕННЫМ ЗАКУПКАМ

Почтовый адрес: 355006, СТАВРОПОЛЬСКИЙ КРАЙ, Г. СТАВРОПОЛЬ, ПР-КТ К.МАРКСА, Д. 63

Место нахождения: 355006, СТАВРОПОЛЬСКИЙ КРАЙ, Г. СТАВРОПОЛЬ, ПР-КТ К.МАРКСА, Д. 63

Ответственное должностное лицо: Борисов Д. С.

Адрес электронной почты: info@stav-zakupki.ru

Номер контактного телефона: 8-8652-955559

Дополнительная информация: Информация о заказчике: Полное наименование: Министерство образования Ставропольского края Адрес местонахождения/Почтовый адрес: 355003, г. Ставрополь, ул. Ломоносова, д. 3 Адрес электронной почты: kilpa@stavminobr.ru Номер контактного телефона: 8-865-2747550 доб. 3101 Ответственное должностное лицо заказчика: Кильпа Инна Александровна Идентификационный код закупки в соответствии с планом-графиком: 252263400875826340100100720000000244

Регион: Ставропольский край

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 29.10.2025 10:41 (МСК)

Дата и время окончания срока подачи заявок: 10.11.2025 08:00 (МСК)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 10.11.2025

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 12.11.2025

Начальная (максимальная) цена контракта

Начальная (максимальная) цена контракта: 7 957 700,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 252263400875826340100100720010000244

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 62.01.11.000 - Развитие государственной информационной системы Ставропольского края «Региональная информационная система в сфере образования для реализации предоставления государственных и муниципальных услуг в электронной форме» Общие требования к оказанию услуг В рамках выполнения работ по развитию РИС СО Исполнителем должны использоваться ранее разработанные технические и программные решения РИС СО, а также технологическая основа исходных кодов функциональных модулей и сервисов. Технические решения, используемые на этапах проектирования и реализации РИС СО должны позволять минимизировать трудозатраты по развитию, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса, а также при подключении к Системе новых внешних информационных систем и ресурсов. Проектные решения должны обеспечивать возможность масштабирования РИС СО при увеличении нагрузки на Систему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности. Должны быть сохранены все эргономические, интерфейсные и архитектурные решения РИС СО, а новый функционал должен быть реализован путем дополнения, адаптации и развития имеющихся уже в РИС СО решений. В частности, для развития системы должен быть использован Конструктор (см. п. 1.11 Контракта «Решения по обеспечению гибкости Системы»), вновь создаваемые решения должны использовать имеющиеся решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации. Также исполнителем должен использоваться имеющийся стек технологий (см. п. 1.6 Контракта «Сведения о программном обеспечении, используемом в рамках Системы»). Все экранные формы Системы, инструкции по работе, вся документация на Систему должны быть выполнены на русском языке. В рамках оказания услуг выполняется доработка ранее созданных функций и создаются новые подсистемы. Требования к доработкам функций Системы для реализации предоставления органами управления образованием администраций муниципальных и городских округов Ставропольского края, а также общеобразовательными организациями, расположенными на территории Ставропольского края, государственной услуги «Запись на участие в государственной итоговой аттестации по образовательным программам основного общего и среднего общего образования в форме единого государственного экзамена, основного государственного экзамена, государственного выпускного экзамена, итоговом сочинении (изложении), итоговом собеседовании по русскому языку» В Системе в настоящее время реализованы следующие возможности: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для прохождения государственной итоговой аттестации в 9 классе (ГИА-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для прохождения государственной итоговой аттестации в 11 классе (ГИА-11); 3) подача выпускниками прошлых лет (ВПЛ) заявления для сдачи ЕГЭ; 4) подача обучающимся учреждений среднего профессионального образования (СПО) заявления для сдачи ЕГЭ. Данные возможности реализованы с использованием аутентификации и идентификации с помощью сервиса идентификации и аутентификации Систем интегрированного с ЕСИА и нормативно-справочной информацией Системы (в частности – с учетом реестра образовательных организаций и органов управления образованием). Исполнитель должен доработать Систему для реализации следующих функций: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для участия в итоговом собеседовании в 9 классе (ИС-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для участия в итоговом сочинении в 11 классе (ИС-11); 3) подача ВПЛ заявления для участия в итоговом сочинении; 4) подача обучающимся СПО заявления для участия в ИС-11. Функции должны быть реализованы в соответствии с административным регламентом Заказчика, доступном по адресу: https://pravo.stavregion.ru/api/app/repo/law/01bee09f8f5e02a8e937380d02fde1e3.pdf Исполнитель должен разработать с использованием ВКУ формы на ЕПГУ, обеспечив их взаимодействие с Системой в соответствии с указанным выше административным регламентом Заказчика. Получение доступа к необходимым видам сведений, тестовой и продуктивной среде для выполнения работ обеспечивается Заказчиком. Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО» Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/53ee2be4-5c8c-408c-a593-3aefc22b1474 Реквизитный состав заявления указан на предоставление компенсации за оплату детского сада ребёнка участника СВО в Таблице 1 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО указан в Таблице 2 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 1 приложения 2 к Контракту. Пример заявления на предоставление компенсации за оплату детского сада ребёнка участника СВО и Пример ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в Системе пользователями – сотрудниками муниципальных органов управления образованием с подтверждением финального статуса в системе сотрудниками дошкольных образовательных организаций (по аналогии с реализованной ранее в Системе услугой «Компенсацию родительской платы за детский сад» с использованием ранее созданных интерфейсов и процессов). - Условная единица - 1,00 - 7 957 700,00 - 7 957 700,00

МИНИСТЕРСТВО ОБРАЗОВАНИЯ СТАВРОПОЛЬСКОГО КРАЯ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Общие требования к оказанию услуг В рамках выполнения работ по развитию РИС СО Исполнителем должны использоваться ранее разработанные технические и программные решения РИС СО, а также технологическая основа исходных кодов функциональных модулей и сервисов. Технические решения, используемые на этапах проектирования и реализации РИС СО должны позволять минимизировать трудозатраты по развитию, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса, а также при подключении к Системе новых внешних информационных систем и ресурсов. Проектные решения должны обеспечивать возможность масштабирования РИС СО при увеличении нагрузки на Систему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности. Должны быть сохранены все эргономические, интерфейсные и архитектурные решения РИС СО, а новый функционал должен быть реализован путем дополнения, адаптации и развития имеющихся уже в РИС СО решений. В частности, для развития системы должен быть использован Конструктор (см. п. 1.11 Контракта «Решения по обеспечению гибкости Системы»), вновь создаваемые решения должны использовать имеющиеся решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации. Также исполнителем должен использоваться имеющийся стек технологий (см. п. 1.6 Контракта «Сведения о программном обеспечении, используемом в рамках Системы»). Все экранные формы Системы, инструкции по работе, вся документация на Систему должны быть выполнены на русском языке. В рамках оказания услуг выполняется доработка ранее созданных функций и создаются новые подсистемы. Значение характеристики не может изменяться участником закупки Требования к доработкам функций Системы для реализации предоставления органами управления образованием администраций муниципальных и городских округов Ставропольского края, а также общеобразовательными организациями, расположенными на территории Ставропольского края, государственной услуги «Запись на участие в государственной итоговой аттестации по образовательным программам основного общего и среднего общего образования в форме единого государственного экзамена, основного государственного экзамена, государственного выпускного экзамена, итоговом сочинении (изложении), итоговом собеседовании по русскому языку» В Системе в настоящее время реализованы следующие возможности: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для прохождения государственной итоговой аттестации в 9 классе (ГИА-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для прохождения государственной итоговой аттестации в 11 классе (ГИА-11); 3) подача выпускниками прошлых лет (ВПЛ) заявления для сдачи ЕГЭ; 4) подача обучающимся учреждений среднего профессионального образования (СПО) заявления для сдачи ЕГЭ. Данные возможности реализованы с использованием аутентификации и идентификации с помощью сервиса идентификации и аутентификации Систем интегрированного с ЕСИА и нормативно-справочной информацией Системы (в частности – с учетом реестра образовательных организаций и органов управления образованием). Исполнитель должен доработать Систему для реализации следующих функций: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для участия в итоговом собеседовании в 9 классе (ИС-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для участия в итоговом сочинении в 11 классе (ИС-11); 3) подача ВПЛ заявления для участия в итоговом сочинении; 4) подача обучающимся СПО заявления для участия в ИС-11. Функции должны быть реализованы в соответствии с административным регламентом Заказчика, доступном по адресу: https://pravo.stavregion.ru/api/app/repo/law/01bee09f8f5e02a8e937380d02fde1e3.pdf Исполнитель должен разработать с использованием ВКУ формы на ЕПГУ, обеспечив их взаимодействие с Системой в соответствии с указанным выше административным регламентом Заказчика. Получение доступа к необходимым видам сведений, тестовой и продуктивной среде для выполнения работ обеспечивается Заказчиком. Значение характеристики не может изменяться участником закупки Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО» Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/53ee2be4-5c8c-408c-a593-3aefc22b1474 Реквизитный состав заявления указан на предоставление компенсации за оплату детского сада ребёнка участника СВО в Таблице 1 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО указан в Таблице 2 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 1 приложения 2 к Контракту. Пример заявления на предоставление компенсации за оплату детского сада ребёнка участника СВО и Пример ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в Системе пользователями – сотрудниками муниципальных органов управления образованием с подтверждением финального статуса в системе сотрудниками дошкольных образовательных организаций (по аналогии с реализованной ранее в Системе услугой «Компенсацию родительской платы за детский сад» с использованием ранее созданных интерфейсов и процессов). Значение характеристики не может изменяться участником закупки Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление горячего питания в школе детей участников СВО» Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление горячего питания в школе детей участников СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/293be06d-7502-427e-812d-ca16ef1510d8 Реквизитный состав заявления на предоставление горячего питания в школе детей участников СВО указан в Таблице 3 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление горячего питания в школе детей участников СВО указан в Таблице 4 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 2 приложения 2 к Контракту. Пример заявления на предоставление горячего питания в школе детей участников СВО и Пример ответа на предоставление горячего питания в школе детей участников СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в действующей Системе пользователями – сотрудниками общеобразовательных организаций. Значение характеристики не может изменяться участником закупки Перечень новых разрабатываемых подсистем Подсистема «Региональный образовательный портал»; Подсистема «Аттестация педагогов»; Подсистема «Летний отдых»; Подсистема «Цифровой урок»; Подсистема «Мероприятия в образовании»; Аналитическая подсистема; Подсистема управления контентом. Значение характеристики не может изменяться участником закупки Требования к функциям аналитической подсистемы Подсистема должна обеспечивать создание и модернизацию связанных между собой отчетных форм, а также их размещение на портале и в интерфейсе других подсистем. Подсистема должна обеспечивать получение данных из различных источников для формирования отчета, визуализацию отчетов, их выгрузку в редактируемые форматы документов, электронных таблиц и в формат PDF. Доступ к данным – должно быть реализовано подключение ко всем БД, используемым в Системе, включая базы данных портала; – должны конфигурироваться: – роли пользователей; – разделы, на которые будут делиться отчеты при выводе конечному пользователю; – права доступа (кому доступен конструктор, кому и какие отчеты и в каком разрезе); – разрезы данных (какие есть разрезы и как определить, к какому разрезу отнести конкретного пользователя). Функции подсистемы - настройка отчетных форм; - редактирование шаблонов отчетных форм; - разграничение доступа к отчетам; - отображение отчетов. Участник закупки указывает в заявке все значения характеристики Настройка отчетных форм (начало описания) Система отчетности должна формировать отчеты на основе конфигурации – отчетных форм. Отчетные формы должны создаваться на базе документа – шаблона, в котором описаны следующие элементы отчетной формы: – наименование отчета; – шапка отчета; – параметры, заполняемые пользователем перед выводом отображением отчета, с указанием обязательности их заполнения; – список таблиц (с указанием базы данных, если в проекте используется несколько подключений), на основании которых будут вычисляться данные; – описание полей и формул или алгоритмов для наполнения таблицы отчета данными. Отчетная форма должна подразумевать указание одного или несколько источников (баз) данных, списка параметров для формирования отчета и дополнительных обработок данных, реализующих алгоритмы преобразования данных при построении отчетных форм. При формировании отчетов должны использоваться внешние файлы шаблонов в форматах docx, xls и xlsx. При формировании отчетов, в отчетной форме должна быть реализована возможность указания, создаваемых на основании формируемого набора данных графиков и диаграмм. Система отчетности должна поддерживать возможности кэширования результатов выполнения отчетов, ограничение максимального времени ожидания формирования отчета и максимального времени жизни кэша отчета. Настройка отчетных форм (окончание описания) Исполнителю необходимо реализовать функционал представления конфигурации отчёта в виде визуального графа, задающего логику построения отчёта от начальной точки, когда пользователь запросил данные, до момента выполнения последнего шага для каждого разреза с учётом выбранных пользователем параметров. Должен быть разработан визуальный редактор графа. Каждая из вершин графа должна описывать один из шагов при построении отчета, в частности – извлечение данных, трансформацию данных, расчеты по заданным формулам, объединение данных, подготовки на основе данных формы отчета, сохранение отчета и т.д. Конструктор отчетов должен включать в себя функционал настройки расписания, позволяющий указать время и периодичность формирования отчетов. Система должна автоматически формировать отчеты и сохранять их на сервере. В системе должна быть обеспечена визуальная настройка прав доступа пользователей к сгенерированным по расписанию отчетам. Необходимо реализовать механизм, который после запуска формирования отчета, сразу возвращает ответ от сервера с индикацией, что отчет формируется, в то время как пользователь может продолжать использовать систему. После завершения формирования отчета, система должна оповестить пользователя и предложить перейти к сформированному отчету. Исполнитель должен реализовать в конструкторе функционал, обеспечивающий связь между отчетами для реализации механизма Drilldown/Drillup. Необходимо реализовать механизм, обеспечивающий открытый доступ к отчету по уникальной ссылке, которая может быть выслана пользователю. При этом должна быть реализована настройка возможности экспорта отчета и изменения параметров. Должна быть предусмотрена возможность встраивания отчетов с использованием тегов iframe во внешние сайты. Редактирование шаблонов отчетных форм Шаблоны отчетных форм должны составляться в формате Microsoft Office docx и xls и поддерживать возможность вывода итеративных структур данных, например таблиц. Отчетные формы должны храниться на сервере Системы. Наличие шаблонов отчетных форм не является обязательным для создание отчетных форм (простые отчеты могут формироваться на основании запросов, описанных в модуле Конструктор подсистемы Администрирования). Разграничение доступа к отчетам Каждая отчетная форма должна отображаться в личных кабинетах для одной или нескольких групп пользователей. Система отчетности должна поддерживать возможность скрыть отчет для всех пользователей. Должна быть реализована возможность изменения положения отчета в списке доступных пользователю отчетов, а также группировки отчетов по категориям. Отображение отчетов Аналитическая подсистема должна поддерживать возможности: – просмотр всех отчетов в Web-интерфейсе; – скачивания отчета в формате xls и docx; – просмотр или скачивание отчета в отрыве от остальных отчетов в любом личном кабинете Системы или в открытой части портала; – предоставление возможности поэтапного заполнения параметров с автоматическим получением фильтрованных списков для зависимых параметров; – просмотр графиков, указанных в отчетных формах, с дополнительной маркировкой отчетов, в которых присутствуют графики. Взаимодействия между частями подсистемы отчетности и другими подсистемами должно осуществляться посредством REST-API. Требования к подсистеме управления контентом Система управления порталом (CMS) должна обеспечивать: - доступ к размещенной информации без использования программного обеспечения, установка которого на технические средства пользователя информации требует заключения лицензионного или иного соглашения с правообладателем программного обеспечения, предусматривающего взимание с пользователя платы; - портал должен быть разработан с использованием средств разработки, относящимся к свободному программному обеспечению. - система управления сайтом (CMS), входящая в состав Системы должна обеспечивать возможность создания Заказчиком плагинов (расширений). - CMS должна обеспечивать возможность передачи пользователем прав на редактирование отдельных страниц (разделов) сайта для обеспечения наполнения информацией с участием нескольких пользователей; - CMS должна предусматривать механизм рецензирования, при котором пользователь может иметь право на создание и редактирование публикаций в определенном разделе, но при этом публикации сохраняются в статусе «черновик» и проверяются пользователем с правами публикации контента для общего доступа, который в случае корректности, обеспечивает публикацию страницы для всеобщего доступа. - CMS должна позволять осуществлять обсуждение публикаций пользователями, обеспечивать связь между публикациями - CMS должна обеспечивать работу с пользователями, которые имеют права «Редактор портала». - должны быть обеспечены возможности по публикации фото-галерей, а также по прикреплению файлов к публикации с их отображением (или без отображения); если отображение файлов не включено, то они могут быть доступны в виде прямых ссылок из текста публикации; - должны быть обеспечены возможности сквозного полнотекстового поиска по всем публикациям на портале с учетом прав доступа пользователей; - должна быть обеспечена поддержка SSL – шифрования HTTP – трафика (протокол HTTPS). SSL – сертификат предоставляется Заказчиком. Участник закупки указывает в заявке все значения характеристики Подраздел «Публикация» (начало описания) – наименование; – тип публикации – выбор из справочника: публикация, новость, галерея; – событие – должен обеспечиваться выбор из списка событий, доступных для корневого раздела и подразделов (подсайтов), вышестоящих по отношению к публикации, а также находящихся с ней на одном уровне иерархии портала. При выборе события пользователем, публикация будет отображаться среди связанных с событием страниц; – алиас – должна быть возможность задавать алиас для доступа к публикации по адресу / ; – категория – в Системе для администратора портала должна быть обеспечена возможность ведения справочника категорий публикаций (например – родителям, учащимся, педагогам …). В CMS должен быть реализован отбор и выдача публикаций (статей) из разных разделов и разных сайтов, входящих в портал по категориям в хронологическом порядке; – статус версии – выбор из справочника: разрешена, не проверена, на доработку, запрещена. Модератор портала (сайта, раздела) должен иметь право менять статус и сопровождать изменение замечаниями для авторов публикации, не имеющих права публикации; – хост – адрес сайта по которому открывается данный раздел и его подразделы, как отдельный интернет-ресурс; – ключевые слова (теги) публикации – выбор из автоформируемого публичного списка тегов. Если нужных слов нет в списке, должна быть реализована возможность внести ключевое слово в ручную, затем оно будет автоматически доступно в списке; – шаблон – шаблон страницы (раздела), должна быть обеспечена поддержка шаблонов в формате twig (https://twig.symfony.com/); – шаблон для подчиненных публикаций – должен быть реализован шаблон для подчиненных страниц (разделов), должна быть обеспечена поддержка шаблонов в формате twig; Подраздел «Публикация» (окончание описания) – дата публикации – должна генерироваться автоматически, должна быть реализована возможность изменения для пользователей, имеющих административные привилегии; – вес – должен определять вес публикации в текущем контексте; – закрыт – публикация/раздел недоступна никому, кроме автора; – скрытый – отсутствует в меню, раздел доступен только по прямой ссылке, алиасу или адресу сайта; – показывать медиа – должны показываться прикрепленные медиа-файлы; – показывать файлы – при включении данной опции портал должен показывать файлы, прикрепленные к публикации. Если опция не включена, файл не отображается, но может быть доступен по ссылке из WEB-контента публикации; – не подлежит удалению – страница (раздел) не должна быть никем удалена, пока не будет отключена опция; – корневая – страница является «разделом», включается в навигационные структуры (меню); – репост в соц.сети – к странице добавляются функции репоста контента в социальные сети; – плагин – в случае включения должна быть обеспечена возможность указать название плагина: код в результате работы которого генерируется контент, выводимый на портал; – разрешить комментарии – в случае включения должны быть доступны две дополнительные опции: разрешить анонимные комментарии (разрешить комментарии неавторизованным пользователям), запретить добавлять комментарии (ранее добавленные комментарии должны быть видны, но новые добавить нельзя). Комментарии должны отображаться в соответствии с предусмотренным в шаблоне дизайном. Подраздел «Содержание» – web-редактор с панелью инструментов для редактирования текста, включающим опции реализованные в виде пиктограмм: – стиль шрифта: жирный, наклонный, зачеркнутый и подчеркнутый; – выравнивание абзаца: по левому краю, правому краю, по центру и по ширине листа; – выделение текста цветом; – работа с буфером обмена: копировать, вырезать, вставить, вставить как текст, вставить из Word; – поиск; – замена; – вернуть операцию; – повторить операцию; – очистить стиль; – редактор HTML – кода; – предварительный просмотр; – печать; – стиль – картинка слева, картинка справа; – абзац – Заголовок 1, Заголовок 2, ...; – шрифт – выбор типа шрифта; – размер – выбор размера шрифта; – маркированный список; – нумерованный список; – добавить/изменить якорь; – добавить/изменить изображение: должно быть обеспечено размещение изображений пользователем в внутренней коллекции изображений и работа с коллекцией – удаление и скачивание изображений из коллекции; – верхний индекс; – нижний индекс; – добавить/изменить клип: должно быть обеспечено размещение видеоклипов пользователем в внутренней коллекции и работа с коллекцией – удаление и скачивание видео из коллекции; – добавить/изменить таблицу (и другие операции с таблицей); – изменить CSS-стиль. – сохранить – нажатие кнопки должно приводить к записи изменений; – отменить. Подраздел «Файлы» В разделе должна быть реализована возможность загрузки файлов, которые могут быть показаны вместе с публикацией в сопровождении пиктограмм (pdf, Word и тп). Должны быть доступны следующие операции: – открыть – выбрать один или несколько файлов для загрузки; – загрузить – загрузить на сервер выбранные, но еще не загруженные файлы; – отменить – отменить выбор файлов для загрузки; – удалить – удалить один или несколько выбранных файлов. Для каждого файла должно быть доступно скачивание. При указании соответствующей опции для публикации, файлы должны отображаться на портале вместе с контентом публикации. Подраздел «Права» В разделе должна быть реализована возможность выбора пользователя из числа зарегистрированных на портале. В системе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». При выборе пользователей должен быть обеспечен поиск по фамилии, имени, отчеству, учетной записи, СНИЛС. При добавлении пользователя должны быть указаны права пользователя в отношении раздела (страницы): «Администратор» – все права на раздел и подразделы, «Только чтение» – просмотр страниц, «События полный» – управление событиями, «Редактор без права изменения статуса» – создание страниц без права изменения статуса публикаций. «Администратор» должен иметь возможность предоставить другим пользователям права для редактирования страниц и разделов внутри раздела, к которому ему предоставлен доступ. Подраздел «Ссылки» Должен обеспечивать возможность связать публикации (разделы) между собой для представления связанного контента на портале (должно быть предусмотрено в шаблонах). Должна быть предусмотрена операция «Добавить», позволяющая выбрать один или несколько разделов, связанных с публикацией. Раздел главного меню «Пользователи» В разделе пользователь, являющийся администратором портала может управлять правами других пользователей. В разделе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». Пользователи должны получать роли, такие же, как приведены выше в описание подраздела «Права». Эти роли должны распространяться на весь портал. Раздел главного меню «События» Должно быть обеспечено дополнение событий, их изменение и удаление. Информация о событии должна включать в себя: – наименование события; – краткое описание события; – изображение (баннер) события; – дата начала события; – дата завершения события; – вес – используется для определения порядка отображения событий; – разрешить комментарии – обеспечивается добавление и показ комментариев; – разрешить анонимные комментарии – комментарии могут добавлять неавторизованные пользователи; – запретить добавлять комментарии – комментарии по-прежнему показываются, но добавление новых комментариев заблокировано. Раздел главного меню «Обратная связь» Должен содержать список сообщений, направленных через сервис обратной связи, который должен быть реализован для разделов организаций на портале (например — лагерей детского отдыха, ОО и других). Сервис обратной связи должен обеспечивать отправление обращения на официальный e-mail организации и одновременную его запись в базу данных портала. Информация о сообщении должна включать в себя: код организации-получателя, имя отправителя, email, текст сообщения. Требования к подсистеме «Региональный образовательный портал» В подсистеме должны быть предусмотрены возможности доступа к единой базе данных документов образовательных организаций и управлений образования, включая функции поиска необходимых документов. Поисковая форма по единой базе данных документов должна включать в себя, как минимум, следующие поля: - уровень документа (федеральный, региональный, муниципальный, уровень ОО); - тип документа (Приказ, Устав, Результаты самообследования и т. д.); - категория документа (тематика: ЕГЭ, ОГЭ, ГВЭ, Информатизация, Одаренные дети, …); - номер документа; - ключевые слова (поиск по названию и аннотации документа); - наименование организации (подстрока, часть наименования); - дата начала – дата завершения (диапазон дат, в которые должна попадать дата документа). При авторизации, на региональном образовательном портале, педагогического работника, пользователю должна быть доступна функция ведения персонального сайта. Пользователи публичной части регионального образовательного портала должны иметь возможность перехода к просмотру контента сайтов учителей c использованием карточки любой ОО, из подраздела «Руководство. Педагогический (научно-педагогический) состав». На портале должен быть реализован механизм общественной оценки, позволяющий любому авторизованному через ЕСИА пользователю оставить отзыв о работе каждого педагога. Участник закупки указывает в заявке все значения характеристики Структура открытой части портала представлена на Рисунке 1 приложения 2 к Контракту. Исполнитель должен согласовать с Заказчиком в ходе выполнения работ проект дизайна портала и карточек ОО, размещаемых на портале. После направления на согласование проекта дизайна, Заказчик должен дать ответ-согласование или замечания в течении 2 рабочих дней. После устранения замечаний, Исполнитель должен направить проект дизайна вторично. Проект дизайна направляется в формате графических файлов — jpg, pdf или png. Структура титульной страницы портала: Блок 1. Вызов главного меню портала. В главном меню должны быть реализованы следующие разделы: 1. Система образования. Раздел должен открывать форму поиска по образовательным организациям региона. Блок 2. Лого и наименование портала (должны быть предоставлены Заказчиком). Блок 3. Поиск – открывается строка и обеспечивается поиск по всем общедоступным публикациям на портале (не должен включать поиск по базе документов и карточкам организаций). Блок 4. «Вход в единый личный кабинет». Для входа в личный кабинет могут быть использованы следующие типы учетных записей: 1) администратор системы; 2) координаторы всех уровней (см. п. 1.10. Контракта «Решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации»; 3) подтвержденные учетные записи ЕПГУ (педагоги, учащиеся, руководители). В едином личном кабинете пользователь должен иметь возможность получить доступ ко всем функциональным подсистемам к которым ему предоставлены права доступа. Блок 5. Должен содержать ленту событий. Слайдер событий должен представлять собой события, включающие изображение и текст (описание). Если слайдер включает более одного выводимого события, то они должны меняться (пролистываться) автоматически. Под слайдером должен находиться переключатель на одно из открытых для вывода событий. Если щелкнуть по событию, должна открываться страница события, где выводится изображение, подробное описание события и связанные с ним публикации – при внесении публикации может быть указана его связь с событием (см. описание подсистемы управления порталом). События и изображения для обработки и вывода на портал, как и другой начальный контент для заполнения главной страницы портала, предоставляется Заказчиком. Блок 6. Новости. Должны выводиться три последние новости из ленты новостей портала. Должна быть предусмотрена кнопка (ссылка) «Все новости», для открытия ленты новостей портала с возможностью их фильтрации по календарю (должна быть возможность указать диапазон дат). Блок 7. Карта системы образования. Должна быть реализована возможность выбрать типы отображаемых организаций (учреждений): 1. Организации и учреждения. 1.1 Детские сады. 1.2 Школы. 1.3 Школы-интернаты. 1.4 Учреждения дополнительного образования. 1.5 Учреждения профессионального образования. 1.6 Органы управления образованием. 1.7 Иные организации. При щелчке по значку организации (учреждения) на карте, должна открываться ее карточка, с которой можно перейти и на официальный сайт организации (он может быть организован как на портале, так и на внешних ресурсах, например — ГосВеб). В блоке должна быть доступна ссылка «Система образования». В этом разделе должен открываться список организаций и органов управления образованием со следующими полями: - АТЕ – наименование муниципалитета; - наименование – наименование организации/органа управления образованием; - руководитель – ФИО руководителя; - e-mail – адрес электронной почты; - юридический адрес; - телефон(ы). При щелчке по наименованию, которое должно являться ссылкой, на новой закладке должна открываться карточка организации. Должна быть предусмотрена выгрузка реестра в формате электронной таблицы (файл в формате xls). Помимо полей, приведенных выше в выгрузку должно быть добавлено поле «Должность руководителя». Для списка организаций должен быть предусмотрен фильтр, включающий в себя: - выбор муниципалитета; - фрагмент наименования; - выбор одного или нескольких типов организаций: - детские сады; - школы; - школы-интернаты; - профессиональное образование; - дополнительное образование; - управления образования; - иные организации. Блок 9. Мероприятия в образовании (окнчание описания). В разделе должна быть доступна возможность записи на мероприятия. Для мероприятий Исполнитель должен разработать структуру карточки и реализовать ее с использованием Конструктора. Карточка должна включать наименование, тип мероприятия, фотогалерею (просмотр приложенных фотографий), описание мероприятия, ссылки на сайты, а также дополнительные сведения, например – структуру мероприятия и его этапы, информацию о местах проведения, опции информационного сопровождения мероприятия и т.п. Для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например . . . Подсистема «Региональный образовательный портал» должна обеспечивать публичный интерфейс для доступа к общей информации о системе образования, карточкам всех образовательных организациях региона в одном месте с переходом к сайту образовательной организации. Доступ к компонентам подсистемы находящимся вне публичного контура должен быть доступен только после прохождения процедуры авторизации средствами ЕСИА или с помощью учетной записи координатора. Подсистема «Региональный образовательный портал» должна использоваться как единая точка входа во все подсистемы для работников ОО, обучающихся и родителей (законных представителей), для предоставления услуг в сфере образования в электронном виде. Для этих целей она должна быть интегрирована с единым личным кабинетом Системы, созданным ранее. Функционал подсистемы должен обеспечивать возможность ведения разделов портала, используя подсистему управления контентом. Блок 8. Наши показатели. В прямоугольных или иных блоках должны быть выведены показатели, рассчитанные на основе эксплуатации системы, например: число обучающихся в ОО, Заявлений ГИА – число заявлений, поданных на ГИА в электронном виде и т. п. Должна быть предусмотрена кнопка «Дашбоард», при нажатии на которую должна открываться аналитика по работе ОО с системой и предоставлению услуг в электронном виде. В частности должен быть обеспечен вывод раздела «Заполнение открытых данных», включающий три графических отчета: 1. гистограмма по муниципалитетам, показывающая процент ОО, сформировавших «Открытые данные» более, чем на 80 %; 2. при выборе муниципалитета, должна выводиться гистограмма по школам (процент заполнения) и дополнительные данные. Должна выводиться информации о внесении координат зданий, адрес сайта, информация о доступности сайта, дата последней загрузки документов в «Открытые данные». 3. при выборе школы – гистограмма о степени заполнении разделов «Открытых данных»: - основные сведения; - структура и органы управления ОО; - документы; - образование; - образовательные стандарты; - руководство. Педагогический состав; - материально-техническое обеспечение и оснащенность образовательного процесса; - стипендии и иные виды материальной поддержки; - платные образовательные услуги; - финансово-хозяйственная деятельность; - вакантные места для приема (перевода). Формирование открытых данных в Системе уже реализовано ранее. Данные отчеты и дашбоард должны строиться на основе наполнения базы данных. Блок 9. Мероприятия в образовании (начало описания). В разделе «Мероприятия в образовании» на главной странице должны размещаться последние мероприятия с возможностью фильтрации по уровням событий и другим их свойствам, муниципалитетам, направленности, типам образовательных организаций, конкретным образовательным организациям, а также строка, обеспечивающая интеллектуальный полнотекстовый поиск по мероприятиям. Должны показываться карточки трех (шести, девяти и т.п.) последних мероприятий, либо карточки мероприятий, настроенных для выдачи на главной странице модератором системы. Число выводимых по умолчанию мероприятий должно настраиваться модератором. В блоке мероприятий должны быть реализованы возможности: – перехода к полной картотеке мероприятия; – перехода в фильтру мероприятий, полнотекстовый поиск по мероприятиям, переход к карте мероприятий, где мероприятия показаны в привязке к месту проведения (по умолчанию место проведения мероприятия должно совпадать с главным зданием организации, но при планировании мероприятий в личном кабинете организации и при визуализации на портале должно быть предусмотрено проведение многоэтапных и составных мероприятий, для которых места проведения могут быть различными, в частности – школьный этап всероссийской олимпиады школьников проводится во всех общеобразовательных организациях, муниципальный и региональный – в специально определенных местах. Кроме того, Исполнитель должен учитывать, что кроме этапа место проведение зависит от части составного события, например – областной этап олимпиады по физике может проводиться в одном месте, а по биологии – в другом месте и в другое время). Требования к подсистеме «Аттестация педагогов» Подсистема должна обеспечивать формирование объективного портфолио педагога, подачу электронного заявления на аттестацию с использованием ЕСИА и форм ЕПГУ, экспертизу аттестационных документов и проведение онлайн-заседаний аттестационной комиссии. Личные кабинеты должны быть созданы на базе регионального образовательного портала и интерфейса для работы с данными. Основные функции в личных кабинетах представлены в виде раскрываемых блоков, каждый блок в конечном итоге открывается в виде интерфейса для работы с данными или форм и отчетов, являющихся плагинами портала, реализующими конкретный пользовательский функционал. Участник закупки указывает в заявке все значения характеристики Раздел Личный кабинет организации. Личный кабинет любой организации доступен под учетной записью координатора организации. Кроме этого, координатор может внести СНИЛС пользователей, получающих возможность действовать от имени организации, войдя в Систему с использованием ЕСИА, а также указать роль пользователя. Если пользователь прописан в нескольких организациях, то после входа в личный кабинет, у него появляется возможность выбора организации, от которой он действует. Пользователь может работать в личном кабинете от одной конкретной организации («текущая организация»), сменить ее. Раздел Аттестация педагогических работников (начало описания): Аттестация педагогических работников для получения первой и высшей категории проводится региональной аттестационной комиссией, формируемой в соответствии с приказом регионального органа исполнительной власти, осуществляющего функции управления в сфере образования. Для подачи заявлений на аттестацию и получение информации о ходе его рассмотрения и результатах Исполнитель должен использовать вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Аттестация педагогических работников образовательных организаций, находящихся в ведении субъекта Российской Федерации, муниципальных и частных организаций» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e6d19-ff80-11eb-ba23-33408f10c8dc/versions/2dc85429-8816-4f03-bf27-a617daa885e3?area=PROD). Администратор системы должен иметь возможность добавить одну или несколько организаций в качестве «Оператора аттестации педагогических работников» (организация-оператор). Администратор такой организации, добавив пользователей в систему, тем самым предоставляет им возможность доступа к разделу «Аттестация педагогических работников» Системы в качестве координатора. Раздел Аттестация педагогических работников (продолжение описания): В разделе «Аттестация педагогических работников» организации-оператора должен быть доступен раздел «Справочники». В этом разделе должна быть реализована возможность формирования дополнительных справочников, необходимых для обеспечения процесса аттестации педагогических работников: – категории работников образования, проходящих аттестацию (например, воспитатели ДОО, учителя начальных классов, учителя – предметники, мастера производственного обучения). Обеспечена возможность указать «предметную специализацию», которая может включать один или несколько предметов; – критерии аттестации – набор критериев, по которым вносится информация экспертами. Для каждого критерия реализована возможность указать минимально допустимое значение, категории работников образования к которым применим критерий, а также критерий, частью которого (подкритерием) является данный критерий. При обработке данных система автоматически суммирует показатели критериев нижнего уровня для расчета значения критериев первого уровня. Внесение информации вручную экспертами реализовано для критериев, у которых отсутствуют подчиненные критерии (подкритерии); – реестр экспертов – включает в себя данные об эксперте, включая ФИО, место работы, email, телефон, а также перечень лет участия в оценке, перечень категорий работников образования, в экспертизе аттестационных дел которых может принимать участие эксперт, а также предметов (если категория предполагает предметную специализацию). В реестре обязательно указан СНИЛС. Система по нему предоставляет доступ пользователю-эксперту к необходимым функциям в личном кабинете (сличать СНИЛС из базы данных и полученный при авторизации с использованием ЕСИА); – график заседаний комиссии – указывается дата и время проведения заседания. Раздел Аттестация педагогических работников (окончание описания): На заседании комиссии могут рассматриваются все заявления, прошедшие к этому времени экспертизу (см. раздел «Заседания комиссии»). Если заседание комиссии уже состоялось, изменение записи в графике блокируется. График заседаний доступен с просмотром по годам. Раздел «Экспертиза» Раздел «Экспертиза» должен быть включен в раздел «Аттестация педагогических работников». В разделе «Экспертиза» разделе доступны функции (начало описания): – просмотр всех поступивших в течении выбранного календарного года заявлений и их статуса (возможность фильтрации заявлений по статусу, муниципалитету, образовательной организации, категории работников образования и предмету (если категория предусматривает указание предметов), а также по результатам экспертизы; – техническая проверка заявлений проводится сотрудниками организации – оператора аттестации педагогических работников; в случае обнаружения технических недостатков в поданном заявлении (пакете документов), заявление может быть возвращено заявителю с заключением о найденных технических ошибках; если заявление прошло проверку, соответствующий статус возвращен на ЕПГУ (если заявление подавалось с использованием формы на ЕПГУ) и в ЛК заявителя в Системе; заявления для технической проверки выводятся в последовательности поступления; В разделе «Экспертиза» разделе доступны функции (окончание описания): – автоматизированное распределение заявлений на экспертизу обеспечивает распределение заявлений, прошедших техническую проверку, на экспертизу, в соответствии со специализацией экспертов; сначала на проверку выдаются случайным образом заявления из числа прошедших первую проверку или наиболее ранних заявлений, еще не прошедших экспертизу; эксперты в личном кабинете указывают доступные им для проверки категории заявлений и нажать кнопку «Получить заявление на экспертизу»; в личных кабинетах сотрудников организации-оператора отображается статистика о числе заявлений, прошедших экспертизу в разрезе числа дней, прошедших со времени подачи (более 60, от 40 до 60, от 20 до 40, от 0 до 20) и категорий заявлений, а также число заявлений, готовых к рассмотрению на заседании комиссии и число дней, оставшихся до даты проведения комиссии; если используется режим проверки двумя экспертами отображаются сведения о числе полностью прошедших экспертизу заявлениях; – анализ работы экспертов по категориям заявителей выводятся сведения о состоянии поступления и экспертизы заявлений, а также информация о числе экспертов, а при выборе категорий – перечень экспертов с указанием числа сформированных экспертных заключений; при выборе эксперта: – переключение режима экспертизы (проверка одним экспертом, проверка двумя экспертами), указание процента расхождения в оценках экспертов при превышении которого заявление отправляется третьему эксперту (только для случая проверки двумя экспертами); в случае если заявление проверено тремя экспертами – берутся результаты двух наиболее близких по сумме баллов экспертов и оценки по каждому критерию находятся как средние между двумя выбранными результатами и округляются. Раздел «Заседания комиссии»: возможность выбора заседания из числа ранее созданных, а также добавления нового заседания. для еще не состоявшегося заседания должны обеспечиваться следующие возможности: – назначение заявлений из числа прошедших экспертизу (могут выбираться категории заявителей и число заявлений), реализована возможность индивидуального выбора заявлений для рассмотрения комиссией; – приглашение на заседание комиссии экспертов (могут выбираться категории экспертов и их число), реализована возможность индивидуального приглашения экспертов на заседание комиссии; – выбор формата проведения заседания – онлайн. При проведении заседания все члены комиссии должны автоматически приглашаться на заседание через систему сообщений и по электронной почте. Для онлайн-заседаний у всех участников в личном кабинете должен появляться доступ в тестовую комнату для тестирования связи. При проведении заседания комиссии в Системе должна быть обеспечена возможность голосования, в личном кабинете каждого участника выводятся вопросы для голосования и с использованием простой электронной подписи все участники имеют возможность проголосовать. – установка статуса заседания (запланировано, подготовка, проведение, завершено); – прикрепление протокола заседания комиссии – отсканированный итоговый протокол заседания комиссии в формате png, jpg, pdf и/или протокол в формате odt; имеется возможность прикрепить файлы после завершения заседания. При проведении онлайн-заседаний пользователи должны иметь возможность использовать web-камеры (видеосвязь), микрофоны (аудиоконференция), общую доску для презентаций и совместной работы, а также чат. Раздел «Мои заявления»: Раздел «Мои заявления» служит для подачи заявлений и получения по ним обратной связи любым пользователем Системы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала Госуслуг. Внутри раздела должны быть предусмотрены подразделы, оформленные в виде пиктограмм, функционал которых описан далее. При выборе раздела должна отображаться ссылка «Информация об аттестации педагогов», которая ведет на раздел «Аттестация педагогических работников» портала, где в открытом доступе размещаются документы, посвященные аттестации педагогических работников региона, а также информация о числе поданных заявлений по категориям работников системы образования и числе работников, прошедших аттестацию. Далее должна выводиться для педагога информация о его категории, дате прохождения последней аттестации и рекомендация пройти аттестацию в указанный период времени. Ниже должна размещаться кнопка подачи заявления на аттестацию на ЕПГУ и кнопка подачи заявления на аттестацию на региональном портале (через Систему). Вне зависимости от способа подачи заявления, все поданные заявления должны отображаться в личном кабинете Системы, а также должен показываться статус заявления и после появления – экспертное заключение и результаты аттестации. Раздел «Сообщения»: Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». При этом в красном круге поверх пиктограммы «Сообщения» пользователь должен видеть число пришедших и не просмотренных еще сообщений. К сообщениям должны приводить все события, происходящие с заявлениями. Сообщения должны включать прямые ссылки для перехода к формам, страницам, документам и т. п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя. Требования к функциям интеграции с ЕПГУ. Использование СМЭВ3 для интеграции с формами на ЕПГУ. Исполнитель должен реализовать приведенную ниже схему интеграции с помощью специально разработанного модуля, работающего с универсальным видом сведений и обеспечивающего гибкую настройку (изменение параметров) со стороны Заказчика без изменения исходных кодов программного обеспечения. Схема взаимодействия с СМЭВ3 приведена на рисунке 2 приложения 2 к Контракту. 1. СМЭВ3 – федеральная система (ЕПГУ), взаимодействует с внешними системами по протоколу SOAP. 2. Сервис взаимодействия со СМЭВ3 – промежуточная система, Spring Boot приложение (или иное приложение, разработанного на базе свободного программного обеспечения). Упрощает взаимодействие со СМЭВ и выполняет общие операции: выполнение операций для отправки и получения сообщений от СМЭВ (периодический опрос, подтверждение, отправка и получение сообщений); преобразование SOAP-сообщений и перенаправление их в локальную очередь; журналирование – сохранение оригинальных запросов от СМЭВ. 3. Сервис криптографии – обеспечивает подпись запросов по формату СМЭВ и ГОСТ (может быть использован СриптоПро JCP или иное решение). 4. Брокер сообщений (например, на базе ActiveMQ; Исполнителем может быть использовано иное открытое решение) – работа с очередями, хранение необработанных сообщений. 5. Клиенты – приложения или сервисы Системы, которым необходимо взаимодействовать со СМЭВ. Синхронное взаимодействие реализовано по протоколу HTTP, асинхронное – с использованием протокола JMS. Требования к подсистеме «Летний отдых» Подсистема «Летний отдых» должна обеспечивать ведение регионального реестра мест летнего отдыха и оздоровления, ведение страниц мест отдыха и оздоровления детей, формирование информации о сменах и группах, внесение лимитов, обеспечение подачи заявлений с учетом муниципальных лимитов на путевки с полной или частичной компенсацией стоимости, автоматизация процесса рассмотрения и подтверждения путевок с учетом региональных особенностей а также возможность настройки безналичной оплаты (интернет-эквайринг), обеспечивать поддержку детского туристического кэшбека (при его наличии) с использованием национальной платежной системы (карты «Мир»), а также формирование базы данных фактов отдыха (для компенсации с использованием заявлений на ЕПГУ). Подсистема должна обеспечивать размещение на региональном образовательном портале информации о местах отдыха и оздоровления в виде картотеки с возможностью ведения сайтов мест детского отдыха и оздоровления, а также размещение мест детского отдыха и оздоровления на карте региона. Участник закупки указывает в заявке все значения характеристики Подсистема «Летний отдых» должна включать в себя раздел на региональном образовательном портале и систему личных кабинетов для следующих категорий пользователей: 1. Представитель организации. 2. Родитель/законный представитель. 3. Администратор. Раздел на Портале должен, как минимум, включать в себя: – возможность осуществления входа в личные кабинеты представителя организации, родителя/законного представителя, администратора; – сокращенный перечень организаций с возможностью перехода к странице с полным перечнем. По щелчку на конкретную организацию должна открываться страница с ее подробным описанием. Авторизация родителей/законных представителей должна осуществляться посредством ЕСИА. Доступ к подсистеме должен быть предоставлен организациям, для которых администратором системы настроен доступ к ведению информации для мест детского отдыха и оздоровления. Представители организаций, получают возможность настраивать профиль организации, в качестве места детского отдыха и оздоровления. Основная информация об организациях, на базе которых создаются места отдыха и оздоровления детей, включает в себя сведения, перечисленные в таблице 5, приложения 2 к Контракту. Дополнительная информация о местах детского отдыха и оздоровления включает в себя сведения, перечисленные в таблице 6, приложения 2 к Контракту. Сведения о зданиях организации перечисленные в таблице 7, приложения 2 к Контракту. Для ведения очереди заявлений (забронированных мест), полученных на предоставление услуги детского отдыха и оздоровления, в личном кабинете организации должен быть доступен раздел «Работа с заявлениями». В этом разделе должна быть реализована работа со справочниками (внесение информации о сменах, числе мест и возрастных категориях детей, а также местах размещения в привязке к месту детского отдыха и оздоровления и зданию, в котором будет размещен ребенок по путевке). Сотрудник организации, имеющей места отдыха и оздоровления детей в каникулярное время, должен иметь возможность подтверждения электронных заявлений и выдачи путевок, внесения заявлений, получаемых в бумажном виде, внесение заявлений на отказ от путевок, а также возможность запроса по электронным заявлениям граждан дополнительной информации, выставления счетов на полную или частичную оплату услуг, а также оплаты по карте с использованием интернет-эквайринга. В системе должна быть предусмотрена возможность подключения интернет-эквайринга, но сама настройка для зачисления платежей на счета конкретных организаций контрактом не предусмотрена. Система обеспечивает выставление счета на полную или частичную оплату услуг детского отдыха и оздоровления в каникулярное время в личном кабинете заявителя. Для интеграции с платежными системами в Системе должен быть реализован простой API, который на основании номера счета, имени и даты рождения ребенка возвращает в ответ внешней системе назначение платежа и сумму платежа. Исполнитель должен реализовывает интеграцию с порталом гос.услуг для получения в систему заявлений с портала с использованием вида сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время», доступного по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD. Сама форма расположена по адресу https://www.gosuslugi.ru/600173/1/form и предназначена для подачи заявлений для граждан имеющих право на бесплатную путевку для получения детского отдыха и оздоровления. Результатом оказания услуги является решение о постановке в очередь на получение путевки в электронном виде. Другие категории граждан должны иметь возможность подать заявление с использованием Системы. Исполнитель также должен обеспечивать по полученным с ЕПГУ заявлениям передачу результатов их рассмотрения на ЕПГУ, а также передать сообщение о возможности дальнейшего взаимодействия в цифровом формате в Системе. Раздел «Мои заявления» должен служить для подачи заявлений и получения по ним обратной связи любым пользователем подсистемы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала гос.услуг. Подсистема при выборе раздела должна предлагать воспользоваться поиском и выбором места отдыха «Перейти к поиску и выбору мест отдыха и оздоровления». После того, как пользователь нашел место для отдыха и открыл его карточку, он должен иметь возможность выбрать время отдыха (смену), либо наоборот, пользователь указывает для поиска время отдыха и выбирает подходящее место. В случае, если открыто бронирование, родитель выбирает «Подать заявку». В этом случае, выведено два варианта: 1) заявление на бесплатную путевку в электронном виде на портале гос.услуг (при этом родителю даны пояснения, какие категории граждан имеют право на бесплатный отдых и оздоровление детей на территории субъекта Российской Федерации); для подачи заявлений на бесплатный детский отдых и оздоровление используется вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD); 2) заявления на путевку с полной или частичной оплатой (в этом случае должна открываться форма заявления в личном кабинете). Запросы дополнительной информации и уточнения от организации детского отдыха также должны поступать родителям (законным представителям) через личный кабинет. Если бронь одобрена, должен быть выставлен электронный счет, квитанцию об оплате которого (или иное подтверждение) необходимо загрузить в личный кабинет в течении 15 дней. После подтверждения получения оплаты на счет организации, в личном кабинете генерируется электронная путевка, содержащая: 1) QR – код с адресом страницы лагеря; 2) название организации; 3) данные ребенка (ФИО, дата рождения); 4) день заезда (начала смены); 5) день выезда (конца смены). Состав электронной формы подачи заявления в места детского отдыха и оздоровления с использованием системы: 1. Смена (из справочника). 2. Подтверждение ознакомления с: – условиями пребывания в выбранном лагере (документ – ссылка); – правилами внутреннего распорядка в лагере (документ – ссылка); – правила использования мобильных телефонов в лагере (документ – ссылка). 3. Количество путёвок (возможность подачи заявок на 1 и более ребенка). 4. Заявитель дает согласие: – на обработку персональных данных заявителя и ребенка (детей); – на медицинское вмешательство; – на виды активностей (в т.ч. фото и видеосъемку) ребенка в лагере. ФИО заявителя (данные должны совпадать с данными, указанными в заявке и подтверждающих документах): - Дата рождения; - Контактный телефон (1 и более); - Электронная почта; - Адрес регистрации; - Адрес проживания; - Серия, номер паспорта; Подтвержденный статус семьи (отметить): – многодетная; – малоимущая; – неполная. Ребенок: - Фамилия; - Имя; - Отчество; - Свидетельство о рождении ребенка (серия и номер); - Дата рождения; - Пол (М/Ж); - Тип школы (из справочника: начальная (дошкольник), средняя, основная, лицей, гимназия, коррекционная (специальная), с углубленным изучением отдельных предметов; - Муниципалитет, школа (выбор из справочников); - Класс, буква (заполнить); - Подтвержденный статус ребенка (отметить); Состоит ли на различных видах профилактического учета: – ОВЗ; – инвалидность; – другие особенности (указать при наличии). Категория для оформления путевки (из справочника): – полуоплатная; – трудная жизненная ситуация (малоимущая семья, опека инвалид ОВЗ, сирота); – работающая (указать место работы на территории региона, прикрепить справку с места работы); – участник профильной смены. Скан свидетельства о рождении ребенка (прикрепить) Документ, подтверждающий льготную категорию (при наличии, может быть несколько). Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». Должно отображаться число пришедших и не просмотренных еще сообщений. К сообщениям приводят все события, происходящие с заявлениями, а также события в местах детского отдыха, в которых пользователь (его дети) получают услуги. Сообщения по возможности должны включать прямые ссылки для перехода к формам, страницам, документам и т.п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя. Для интеграции с формами на ЕПГУ должны быть использованы механизмы, описанные в разделе «Подсистема «Аттестация педагогических кадров». Состав полей и структуры данных подсистемы «Летний отдых», могут быть изменены в ходе выполнения работ по согласованию с Заказчиком. Требования к подсистеме «Цифровой урок» 4) Структура урока должна состоять из этапов. При редактировании урока должна быть реализована возможность указания следующих свойств этапов: 4.1) наименование этапа; 4.2) тип этапа (как минимум должны быть реализованы следующие типы этапов: «Текст», «Презентация», «Тест – выбор одного ответа», «Тест – выбор нескольких ответов», «Тест – ввод числа», «Тест – ввод строки», «Задание – загрузка файлов», «Просмотр файла», «Совместное редактирование текста»). Вне зависимости от типа этапа, педагогу предлагается HTML-редактор для размещения общего контента и отдельно контента для каждой из групп учащихся. При этом для любого этапа должна быть обеспечена возможность загрузки файлов, которые должны автоматически конвертироваться в pdf и просматриваться прямо из системы, это должно касаться также видео-записей, загружаемых в подсистему: должен быть реализован просмотр видео прямо через подсистему «Цифровой урок»; 4.3) дополнительные этапы – не включаются в обычный ход урока – да/нет. Если «да», этап не показывается педагогу при управлении уроком; 4.4) доступен участнику независимо от хода урока – да/нет – если «да», контент доступен ученику не только когда педагог активизирует этап при управлении уроком, а в любое время, например он может получить доступ к контентам, заданиям, самостоятельно, работая с подсистемой; 4.5) этап завершен – да/нет – показывается соответствующая пометка в названии этапа; 4.6) а редакторе этапа должна быть предусмотрена возможность вставки видео RuTube и объектов, поддерживающих тег , в частности должна быть обеспечена возможность встраивания интерактивных объектов проекта learningapps.org и других аналогичных решений, например – форм google. Редактор должен также предусматривать возможность вывода в рамках этапа внешних сайтов, разрешающих встраивание. Участник закупки указывает в заявке все значения характеристики 5) Управление уроком. Педагог должен иметь возможность управлять показом этапов урока (педагог выбирает этап, этот этап выводится учащимся с учетом разделения контента по группам): пролистывать презентацию, загруженную в «Цифровой урок» при выборе соответствующего этапа, переключать этапы урока, содержащие голосования, анкетирования, представлять учащимся результаты в режиме реального времени. Все изменения в этапах урока и в контенте должны сразу отображаться на устройствах обучающихся (в браузере). Должен быть организован вывод контента этапов, подготовленных педагогом с помощью HTML-редактора (с возможностью загрузки изображений) на всех компьютерах (планшетах, смартфонах) учащихся, либо только на компьютере педагога, подключенном к проектору, интерактивной доске (панели); В качестве презентаций в этап урока должна быть обеспечена возможность загрузки документов в форматах odp, ppt, pptx, а pdf. При выборе этапа с презентацией в ходе управления уроком, педагог должен иметь возможность переключать ее слайды. Слайды должны перелистываться автоматически на устройствах учащихся. В режиме управления уроком учитель должен иметь возможность: – запустить видеоконференцию. Учитель должен иметь возможность демонстрировать свой рабочий стол, а также предоставить такую возможность учащимся или другим педагогам, проводящим урок с ним совместно; – запустить аудиоконференцию (тип конференции должен устанавливаться при настройке урока). 5.1) при выборе этапа «Совместное редактирование текста», педагог вместе с классом получает возможность редактировать текст совместно. Текст каждого пользователя должен выделяться цветом; 5.2) при выборе этапа «Просмотр файла», файл должен выводиться учащимся на устройства и сразу открываться (если это pdf-файл), либо ожидать нажатия кнопки проигрывания (для аудио и видео – файлов); 5.3) при выборе этапа «Вопрос - ...», учащимся выводится вопрос анкеты, на который он получает возможность ответить. Все ответы должны собираться в результаты работы по группам у педагога в интерфейсе управления уроком; 5.4) при выборе этапа «Задание – загрузка файла» ученикам должен выводиться текст этапа (задание) и возможность дать ответ. Надо отметить, что задание не обязательно является текстом. Педагог должен иметь возможность нажать микрофон и озвучить задание. Учащиеся также должны иметь возможность в качестве ответа на задание, как прикрепить файл с диска, так и записать звук на компьютере или смартфоне или видео. Кроме того, ответом на задание может быть фото решения в тетради. Педагог должен иметь встроенный графический редактор в подсистеме, чтобы отметить ошибки прямо на фото решения. По заданиям и вопросам у педагога должна быть возможность дать комментарии каждому учащемуся (написать или записать аудио-комментарий, либо сделать фото), а также выставить балл (оценить ответ). При этом за работу на уроке педагог должен иметь возможность выставить дополнительные баллы, не привязанные к заданию (вопросу). 6) Распределение учащихся по группам. Учитель должен иметь возможность распределить всех учеников по группам (не более 5). Разделение на группы может быть использовано при формировании контента, выдаче вопросов и заданий. 7) В подсистеме «Цифровой урок» должен быть реализован модуль «Студия цифрового урока», обеспечивающий следующий функционал: 7.1) создание видеоролика с настройкой его свойств (разрешение, частота кадров и др); 7.2) обеспечение в браузере редактирования компоновки материала: 7.2.1) изображение с web-камеры; 7.2.2) запись рабочего стола, окна программы или закладки в браузере и размещение на рабочем столе Студии; 7.2.3) подключение фоновой аудиозаписи (например, фоновой мелодии); 7.2.4) подключение (загрузка) презентации; 7.2.5) подключение микрофона; 7.3) запись видеофрагмента: при записи педагог может использовать инструменты (карандаш, линия, окружность и др.) и рисовать поверх слайдов презентации и размещенных на рабочем столе Студии окон, при этом объяснение материала микшируется с фоновым звуком и звуком от микрофона, размещенного на рабочем столе Студии; 7.4) монтаж ролика с использованием видеофрагментов: перемещение видеофрагментов, отключение видеофрагментов; 7.5) экспорт видеоролика и сохранение для использования в «Цифровом уроке». Функционал должен работать в браузерах Chromium, Yandex Browser без установки дополнительного программного обеспечения на компьютер учащегося или педагога. 8) В подсистеме должна быть реализована Библиотека уроков. Любой педагог должен иметь возможность представить свой урок, для которого он разрешил использование другими педагогами, в библиотеке. В Библиотеке должен быть реализован поиск (фильтрация) уроков по типу/уровню образования, параллели, предмету (для общего образования). Выбрав урок любой педагог может просмотреть данные о нем, внесенные автором, включая перечень этапов и нажать «Импортировать» для использования в своей работе. 9) Администрирование. В подсистеме должен быть доступен модуль администратора подсистемы, обеспечивающий доступ, как минимум, к следующим данным: учителя (обязательные поля, как минимум: ФИО, email, СНИЛС); уроки; этапы урока; регистрационные данные участников урока; варианты текста для групп участников урока (HTML); варианты ответа (на вопросы анкетирования); ответы участников (на вопросы анкетирования); файлы этапа (загруженные педагогом дополнительные сведения); задачи для перекодирования файлов (техническая таблица, содержащая список задач и ссылки на файлы); данные участников, связанные с уроком (группа, баллы); список альтернатив для альтернативного этапа (педагог должен иметь возможность назначать альтернативные этапы различным группам детей); данные этапа, связанные с уроком (номер текущей страницы презентации, признак завершения этапа); учителя, которые могут совместно вести урок; теги участников (теги, установленные урокам самими учащимися). Должна быть обеспечена выгрузка всех перечисленных сведений из системы в формате MS Excel, а также в виде csv-файлов. Функциональная подсистема «Цифровой урок» должна быть реализована с использованием личных кабинетов на региональном образовательном портале. Подсистема «Цифровой урок» должна представлять собой инструмент смешанного обучения, позволяющий создавать интерактивные уроки, модули и курсы, организовывать синхронное и асинхронное обучение с возможностью участия в занятиях педагогов и учащихся, находящихся в классе, дома, на улице, реализовывать в цифровом формате сетевые образовательные программы с участием нескольких образовательных организаций. Должен включать в себя электронную библиотеку образовательных материалов, формируемую на региональном уровне. Исполнитель должен предусмотреть реализацию следующих основных функций: 1) Вход в Подсистему педагога: 1.1) Вход в Подсистему с использованием личного кабинета педагога в Системе; 1.2) Вход в Подсистему с использованием ЕСИА. 2) Вход в подсистему обучающихся: 2.1) В подсистеме должна быть предусмотрена загрузка данных об обучающихся из любой внешней системы, для чего должен быть разработан специальный REST-сервис, позволяющий забирать из сторонних систем перечень обучающихся класса (группы) и включать их в Цифровой урок, для которого настроена ссылка (в сторонней системе при этом должен быть реализован совместимый сервис); данные должны передаваться в формате JSON; 2.2) В случае включения свободной регистрации, должна быть обеспечена возможность входа с одновременной регистрацией ученика и записью на урок по ссылке, по пригласительному коду, по QR-коду; 3) При создании урока должна быть обеспечена настройка следующих опций: 3.1) Включить конференцию – педагог может выбрать аудио либо видеоконференцию (WEB RTC – конференцию). Видеоконференция должна обеспечивать возможности трансляции всего рабочего стола или выбранного окна; трансляцию web-камер, подключенных к компьютеру; обеспечить аудиотрансляцию; обеспечить использование общей доски с рисованием на ней всех участников урока и выводом презентации. Также в системе должна быть реализована возможность указания в качестве конференции произвольного стрима, например, организованного с использованием в VK или RuTube; 3.2) Свободная регистрация – возможность входить учащимся по коду, QR-коду или ссылке и регистрироваться в подсистеме и на урок; 3.3) Теги урока – указание тегов, например предмета или образовательной программы с функцией фильтрации по тегам при работе с перечнем уроков; 3.4) Разрешить другим учителям импортировать этот урок – педагогам можно отправить ссылку, по которой после входа в систему можно «забрать» урок себе (импортировать) для самостоятельного развития; 3.5) Разрешить другим учителям совместно использовать этот урок – подключение других педагогов к уроку для его совместной разработки и проведения занятий, включая конференцию и контроль работы обучающихся, оценивание; 3.6) Выделение учащимся виртуальных машин – возможность выделения предварительно подготовленных педагогом виртуальных машин с операционными системами Linux или Windows для доступа через web из подсистемы «Цифровой урок»; 3.7) Включение чата для использования при проведении урока (в режиме управления уроком). Чат должен обеспечивать обмен сообщениями, записанными аудио и видео – фрагментами, скриншотами во время урока; 3.8) Должна быть обеспечена возможность использования встроенной электронной доски при управлении цифровым уроком (без необходимости запускать видеоконференцию). Учащиеся должны на своих устройства получить оповещение, что учитель запустил доску и иметь возможность подключиться к ней. Чтобы участник урока мог писать на доске, учитель должен дать ему доступ «вызвать к доске», тогда у учащегося должны появиться инструменты для работы на общей доске. Требования к подсистеме «Мероприятия в образовании» Основная информация о мероприятии. Раздел должен включать следующие сведения: Наименование мероприятия – строка, содержащая до 250 символов (обязательно). Описание мероприятия – web-страница (memo-поле). Галерея изображений – набор jpg или png – файлов (должно быть загружено хотя бы одно изображение, должны быть собледелены минимальные размеры изображения 1280 x 720 точек или более с возможностью вырезки прямоугольника с пропорциями 16:9 размером не менее 1280 x 720 точек). Видеоанонс (трейлер) мероприятия – видеофайл (не более 250 Mb). Разрешение не менее 720 dpi, соотношение сторон 16:9. Аудиоанонс (подкаст) с сменой слайдов из галереи изображений (могут быть заданы титульный слайд и моменты времени вывода других изображений из числа загруженных в галерею). Основной организатор мероприятия (строковое поле, по умолчанию соответствует полному наименованию организации, от имени которой создается мероприятие). Сайт мероприятия (не обязательное поле). Открыть раздел мероприятия на портале (да/нет). Участник закупки указывает в заявке все значения характеристики Наименование раздела мероприятия на портале. Как сказано выше, для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например ... «.» предоставляет Заказчик для настройки системы на серверах Заказчика. должно формироваться в формате act_, тем самым обеспечивается его уникальность, но в тоже время координатор организации, планирующий мероприятие может придумать свое уникальное , например — указать «olympmath-2021» и т.д. Система должна обеспечить проверку корректности. В случае, если у мероприятия отсутствует раздел, для него должна быть создана только карточка, а функции регистрации, публикации материалов и т.п. не должны быть недоступны. Период проведения: - Дата/время начала мероприятия. - Дата/время завершения мероприятия. Дата начала и завершения должны быть обязательно указаны. По-умолчанию указание времени не должно обязательно требоваться от пользователя. Место проведения (не обязательно, может быть также определено в разделе «Управление мероприятием»). Место проведения (строка). Географические координаты (широта, долгота). Следом за основной информацией должен следовать раздел «Классификация», который включает в себя сведения: - Статус мероприятия (в соответствии с таблицей 8 приложения 2 к Контракту); - Тип мероприятия (в соответствии с таблицей 9 приложения 2 к Контракту); - Форма участия: «Персональное участие» либо «Командное участие» (для тех типов мероприятия, где оно предусмотрено); - Направленность (в соответствии с таблицей 10 приложения 2 к Контракту); - Масштаб (уровень) мероприятия (в соответствии с таблицей 11 приложения 2 к Контракту); - Форма проведения мероприятия (в соответствии с таблицей 12 приложения 2 к Контракту). За разделом «Классификация» следует раздел «Управление мероприятием». Раздел должен быть доступен только в случае, если для мероприятия определен раздел на портале, поскольку функционал должен быть реализован на сайте мероприятия для авторизованных в системе пользователей: - работников системы образования; - обучающихся; - родителей (законных представителей). Раздел «Управление мероприятием» должен содержать следующие данные 1. Этапы мероприятия (с возможностью добавления, удаления и корректировки информации об этапе) да/нет. По каждому этапу, если указано, «да», те этапы выделяются, указываются: 1.1 Наименование этапа мероприятия (номер этапа должен устанавливаться автоматически). 1.2 Организатор(ы) этапа мероприятия. По умолчанию должна быть указана организация, создавшая мероприятие (организатор этапа совпадает с организатором мероприятия). Подсистема «Мероприятия в образовании» должна обеспечивать планирование и публикацию мероприятий всеми образовательными организациями и органами управления образованием, информирование потенциальных участников о планируемых мероприятиях, электронную запись на мероприятия, загрузку информации (тезисов, публикаций – при необходимости) и выдачу цифровых дипломов или других документов (при необходимости) участникам и победителям мероприятий. Должна обеспечиваться, в том числе, регистрация на олимпиады всех уровней, поддерживаться как личное, так и командное участие в мероприятиях. Должна быть обеспечена автоматизация проведения мероприятий, формирование страницы на портале или сайта мероприятия. Подсистема должна обеспечивать процесс подготовки и проведения школьного, муниципального и регионального этапа всероссийской олимпиады школьников. Подсистема должна быть интегрирована с ЕАИС ДО – единой автоматизированной информационной системой сбора и анализа данных по учреждениям, программам, мероприятиям дополнительного образования и основным статистическим показателям охвата детей дополнительным образованием в субъектах Российской Федерации (в отношении мероприятий). Вне зависимости от типа организации, в личном кабинете должен быть доступен раздел «Мероприятия организации», после выбора которого открывается перечень доступных мероприятий, а также возможность добавить, изменить мероприятие, включая его статус. 1.2.1 Место проведения этапа мероприятия. Должен осуществляться выбор из числа зданий организатора мероприятия, по умолчанию должно выставляться главное здание организации. В случае, если в Системе для здания не определены географические координаты (широта и долгота) или для организации не внесены здания, должно обязательно требоваться указание названия места проведения (по умолчанию должна указываться строка, совпадающая с наименованием организатора), должны обязательно требоваться координаты места проведения (широта и долгота). По умолчанию, если указаны координаты места проведения всего мероприятия и организатор этапа совпадает с организатором мероприятия, должны использоваться те же координаты, которые могут быть откорректированы. Для мероприятий, проводимых в дистанционном формате информация о месте проведения не указывается. В разделе мероприятия на портале, в случае, если указано, что этапов «нет», дополнительная информация по этапам выводиться не должна. В качестве мест проведения должна быть обеспечена возможность выбора нескольких образовательных организаций или всех ОО определенного типа. Полный перечень типов организаций приводится в таблице13 приложения 2 к Контракту. При выборе образовательных организаций система должна обеспечивать фильтрацию по органам управления образованием и типам организаций. По умолчанию в качестве мест проведения должны использоваться географические координаты главных корпусов зданий ОО. В случае отсутствия данных, информация о названии и координатах мест проведения должна указываться организатором вручную. 1.2.1.1 Указание времени проведения этапа мероприятия. Должна быть обеспечена возможность применить указанное время ко всем местам проведения мероприятия или указать время индивидуально. 1.2.1.2 Ограничение числа участников (количество человек, количество подключений). 1.3 Регистрация на этап (могут быть выбраны несколько опций в соответствии с таблицей 14 приложения 2 к Контракту). Далее следует обеспечить выбор одного из вариантов регистрации на этап: 1.3.1 Регистрация с использованием ЕПГУ (создание формы не является задачей Исполнителя, не предполагается получение в Систему данных с ЕПГУ) 1.3.1.1 Ссылка на форму ЕПГУ (должна указываться обязательно при выборе варианта 1.3.1) 1.3.2 Регистрация с использованием формы портала, поля формы приведены в таблице 15 приложения 2 к Контракту. Должна быть реализована возможность добавления организатором полей к регистрационной форме с указанием типа поля (числовое, строковое, дата, файл (с указанием допустимых типов файлов), а также обязательности полей. Должны быть реализованы возможности выбора полей для включения в форму, а также изменения требований к обязательности поля. В приведенной таблице указана информация об обязательности данных по умолчанию. Настроенная организатором форма регистрации предоставляется для записи участникам мероприятия (этапа мероприятия). При заполнении формы для регистрации на последующие этапы, поля, заполненные при регистрации на предыдущие этапы мероприятия уже должны быть заполнены. Для каждого поля при конфигурировании формы требуется указать права доступа для просмотра и изменения в соответствии с таблицей 16 приложения 2 к Контракту. 1.3.3 Автоматическая регистрация на этап участников, прошедших регистрацию на предыдущие этапы мероприятия. При выборе данного варианта, потенциальными участниками этапа становятся все, зарегистрировавшиеся на предыдущие этапы. Участие в этапе зависит от того, подтвердил ли участник свое участие и подтвердил ли участие координатор мероприятия. 1.3.3.1 Требуется подтверждение регистрации организатором (да, нет). 1.3.3.2 Требуется подтверждение регистрации участником (да, нет). 1.4. Подача материалов для участия в этапе (да, нет). 1.4.1 Информация о необходимости предоставления материалов (инструкция) – HTML. 1.4.1.1 Материалы – таблица метаданных (структура формируется организатором), включая «Наименование материалов», «Тип файла» (фото, презентация, документ, видео), «Обязательны для предоставления» (Да/Нет). Должна быть обеспечена возможность настраивать права доступа к материалам в соответствии с таблицей 17 приложения 2 к Контракту. 1.5 Результаты участия (да, нет). 1.5.1 Результат или баллы, Достижение (из справочника: Не участвовал, Победитель, Призер, Участник. Значение по умолчанию «Участник»). Поле «Достижение» может редактировать только организатор (соорганизатор) этапа мероприятия. Результаты должны попадать в структуру регистрационной формы см. п. 1.3.2.1. 2. Отчетность Для организаторов мероприятий в системе должна быть реализована отчетность, в том числе, по регистрации участников и результатам мероприятий. Система должна включать в себя следующие универсальные отчетные формы: 1) Отчеты о регистрации на мероприятия. Формы должны включать в себя информацию о мероприятии, его организаторах, этапах мероприятия, их организаторах, числе зарегистрированных участников в разрезе организаторов этапов (образовательных организаций, если этап проводится на базе образовательных организаций). Если мероприятие охватывает несколько муниципалитетов, должна быть реализована возможность сформировать отчет в разрезе органов управления образованием, являющихся учредителями образовательных организаций, а также классов (для внутришкольных мероприятий) и параллелей. Должны быть предусмотрены два вида отчетов по регистрации на мероприятия – сводные отчеты, содержащие информацию о числе зарегистрированных участников и персонализированные списки, содержащие информацию о зарегистрированных участниках в выбранных разрезах. 2) Отчеты о результатах мероприятий. Система должна включать в себя отчеты о результатах двух типов: – сводная отчетность: отчет должен включать в себя информацию о числе зарегистрированных на участие, число участников, результаты победителя и средний набранный балл; – персонализированные списки: организатор должен иметь возможность настроить выборку при формировании списков в части разрезов (включать информацию по муниципалитетам и ОО в отчет, а также выбрать конкретные ОО и муниципалитеты), а также в части фильтра для включения в списки (занятые места, критерии по достижению балла). 3. Заявки на мероприятия. Раздел должен обеспечивать возможность для организаторов управлять заявками (просматривать, подтверждать, отказывать), вносить в Систему результаты мероприятий и т. д. Должна быть обеспечена возможность отбора (фильтрации) заявок по ОО, типам мероприятий, мероприятиям и этапам мероприятий, участникам, предметам (для олимпиад) и другим параметрам, предусмотренным в Системе. Должна быть реализована возможность внесения представителями образовательных организаций заявлений на участие в всероссийской олимпиаде школьников на основе бумажных заявлений родителей (законных представителей). Для заявки на мероприятия, имеющие тип «Всероссийская олимпиада школьников», должен быть использован справочник, содержащий, как минимум следующие предметы: Английский язык; Астрономия; Биология; География; Информатика (ИКТ); Искусство (Мировая художественная культура); История; Испанский язык; Итальянский язык; Китайский язык; Литература; Математика; Немецкий язык; Обществознание; Основы безопасности и жизнедеятельности; Право; Русский язык; Технология; Физика; Физическая культура; Французский язык; Химия; Экология; Экономика. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Общие требования к оказанию услуг - В рамках выполнения работ по развитию РИС СО Исполнителем должны использоваться ранее разработанные технические и программные решения РИС СО, а также технологическая основа исходных кодов функциональных модулей и сервисов. Технические решения, используемые на этапах проектирования и реализации РИС СО должны позволять минимизировать трудозатраты по развитию, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса, а также при подключении к Системе новых внешних информационных систем и ресурсов. Проектные решения должны обеспечивать возможность масштабирования РИС СО при увеличении нагрузки на Систему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности. Должны быть сохранены все эргономические, интерфейсные и архитектурные решения РИС СО, а новый функционал должен быть реализован путем дополнения, адаптации и развития имеющихся уже в РИС СО решений. В частности, для развития системы должен быть использован Конструктор (см. п. 1.11 Контракта «Решения по обеспечению гибкости Системы»), вновь создаваемые решения должны использовать имеющиеся решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации. Также исполнителем должен использоваться имеющийся стек технологий (см. п. 1.6 Контракта «Сведения о программном обеспечении, используемом в рамках Системы»). Все экранные формы Системы, инструкции по работе, вся документация на Систему должны быть выполнены на русском языке. В рамках оказания услуг выполняется доработка ранее созданных функций и создаются новые подсистемы. - - Значение характеристики не может изменяться участником закупки - Требования к доработкам функций Системы для реализации предоставления органами управления образованием администраций муниципальных и городских округов Ставропольского края, а также общеобразовательными организациями, расположенными на территории Ставропольского края, государственной услуги «Запись на участие в государственной итоговой аттестации по образовательным программам основного общего и среднего общего образования в форме единого государственного экзамена, основного государственного экзамена, государственного выпускного экзамена, итоговом сочинении (изложении), итоговом собеседовании по русскому языку» - В Системе в настоящее время реализованы следующие возможности: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для прохождения государственной итоговой аттестации в 9 классе (ГИА-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для прохождения государственной итоговой аттестации в 11 классе (ГИА-11); 3) подача выпускниками прошлых лет (ВПЛ) заявления для сдачи ЕГЭ; 4) подача обучающимся учреждений среднего профессионального образования (СПО) заявления для сдачи ЕГЭ. Данные возможности реализованы с использованием аутентификации и идентификации с помощью сервиса идентификации и аутентификации Систем интегрированного с ЕСИА и нормативно-справочной информацией Системы (в частности – с учетом реестра образовательных организаций и органов управления образованием). Исполнитель должен доработать Систему для реализации следующих функций: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для участия в итоговом собеседовании в 9 классе (ИС-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для участия в итоговом сочинении в 11 классе (ИС-11); 3) подача ВПЛ заявления для участия в итоговом сочинении; 4) подача обучающимся СПО заявления для участия в ИС-11. Функции должны быть реализованы в соответствии с административным регламентом Заказчика, доступном по адресу: https://pravo.stavregion.ru/api/app/repo/law/01bee09f8f5e02a8e937380d02fde1e3.pdf Исполнитель должен разработать с использованием ВКУ формы на ЕПГУ, обеспечив их взаимодействие с Системой в соответствии с указанным выше административным регламентом Заказчика. Получение доступа к необходимым видам сведений, тестовой и продуктивной среде для выполнения работ обеспечивается Заказчиком. - - Значение характеристики не может изменяться участником закупки - Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО» - Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/53ee2be4-5c8c-408c-a593-3aefc22b1474 Реквизитный состав заявления указан на предоставление компенсации за оплату детского сада ребёнка участника СВО в Таблице 1 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО указан в Таблице 2 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 1 приложения 2 к Контракту. Пример заявления на предоставление компенсации за оплату детского сада ребёнка участника СВО и Пример ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в Системе пользователями – сотрудниками муниципальных органов управления образованием с подтверждением финального статуса в системе сотрудниками дошкольных образовательных организаций (по аналогии с реализованной ранее в Системе услугой «Компенсацию родительской платы за детский сад» с использованием ранее созданных интерфейсов и процессов). - - Значение характеристики не может изменяться участником закупки - Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление горячего питания в школе детей участников СВО» - Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление горячего питания в школе детей участников СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/293be06d-7502-427e-812d-ca16ef1510d8 Реквизитный состав заявления на предоставление горячего питания в школе детей участников СВО указан в Таблице 3 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление горячего питания в школе детей участников СВО указан в Таблице 4 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 2 приложения 2 к Контракту. Пример заявления на предоставление горячего питания в школе детей участников СВО и Пример ответа на предоставление горячего питания в школе детей участников СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в действующей Системе пользователями – сотрудниками общеобразовательных организаций. - - Значение характеристики не может изменяться участником закупки - Перечень новых разрабатываемых подсистем - Подсистема «Региональный образовательный портал»; Подсистема «Аттестация педагогов»; Подсистема «Летний отдых»; Подсистема «Цифровой урок»; Подсистема «Мероприятия в образовании»; Аналитическая подсистема; Подсистема управления контентом. - - Значение характеристики не может изменяться участником закупки - Требования к функциям аналитической подсистемы - Подсистема должна обеспечивать создание и модернизацию связанных между собой отчетных форм, а также их размещение на портале и в интерфейсе других подсистем. Подсистема должна обеспечивать получение данных из различных источников для формирования отчета, визуализацию отчетов, их выгрузку в редактируемые форматы документов, электронных таблиц и в формат PDF. Доступ к данным – должно быть реализовано подключение ко всем БД, используемым в Системе, включая базы данных портала; – должны конфигурироваться: – роли пользователей; – разделы, на которые будут делиться отчеты при выводе конечному пользователю; – права доступа (кому доступен конструктор, кому и какие отчеты и в каком разрезе); – разрезы данных (какие есть разрезы и как определить, к какому разрезу отнести конкретного пользователя). Функции подсистемы - настройка отчетных форм; - редактирование шаблонов отчетных форм; - разграничение доступа к отчетам; - отображение отчетов. - - Участник закупки указывает в заявке все значения характеристики - Настройка отчетных форм (начало описания) Система отчетности должна формировать отчеты на основе конфигурации – отчетных форм. Отчетные формы должны создаваться на базе документа – шаблона, в котором описаны следующие элементы отчетной формы: – наименование отчета; – шапка отчета; – параметры, заполняемые пользователем перед выводом отображением отчета, с указанием обязательности их заполнения; – список таблиц (с указанием базы данных, если в проекте используется несколько подключений), на основании которых будут вычисляться данные; – описание полей и формул или алгоритмов для наполнения таблицы отчета данными. Отчетная форма должна подразумевать указание одного или несколько источников (баз) данных, списка параметров для формирования отчета и дополнительных обработок данных, реализующих алгоритмы преобразования данных при построении отчетных форм. При формировании отчетов должны использоваться внешние файлы шаблонов в форматах docx, xls и xlsx. При формировании отчетов, в отчетной форме должна быть реализована возможность указания, создаваемых на основании формируемого набора данных графиков и диаграмм. Система отчетности должна поддерживать возможности кэширования результатов выполнения отчетов, ограничение максимального времени ожидания формирования отчета и максимального времени жизни кэша отчета. - Настройка отчетных форм (окончание описания) Исполнителю необходимо реализовать функционал представления конфигурации отчёта в виде визуального графа, задающего логику построения отчёта от начальной точки, когда пользователь запросил данные, до момента выполнения последнего шага для каждого разреза с учётом выбранных пользователем параметров. Должен быть разработан визуальный редактор графа. Каждая из вершин графа должна описывать один из шагов при построении отчета, в частности – извлечение данных, трансформацию данных, расчеты по заданным формулам, объединение данных, подготовки на основе данных формы отчета, сохранение отчета и т.д. Конструктор отчетов должен включать в себя функционал настройки расписания, позволяющий указать время и периодичность формирования отчетов. Система должна автоматически формировать отчеты и сохранять их на сервере. В системе должна быть обеспечена визуальная настройка прав доступа пользователей к сгенерированным по расписанию отчетам. Необходимо реализовать механизм, который после запуска формирования отчета, сразу возвращает ответ от сервера с индикацией, что отчет формируется, в то время как пользователь может продолжать использовать систему. После завершения формирования отчета, система должна оповестить пользователя и предложить перейти к сформированному отчету. Исполнитель должен реализовать в конструкторе функционал, обеспечивающий связь между отчетами для реализации механизма Drilldown/Drillup. Необходимо реализовать механизм, обеспечивающий открытый доступ к отчету по уникальной ссылке, которая может быть выслана пользователю. При этом должна быть реализована настройка возможности экспорта отчета и изменения параметров. Должна быть предусмотрена возможность встраивания отчетов с использованием тегов iframe во внешние сайты. - Редактирование шаблонов отчетных форм Шаблоны отчетных форм должны составляться в формате Microsoft Office docx и xls и поддерживать возможность вывода итеративных структур данных, например таблиц. Отчетные формы должны храниться на сервере Системы. Наличие шаблонов отчетных форм не является обязательным для создание отчетных форм (простые отчеты могут формироваться на основании запросов, описанных в модуле Конструктор подсистемы Администрирования). Разграничение доступа к отчетам Каждая отчетная форма должна отображаться в личных кабинетах для одной или нескольких групп пользователей. Система отчетности должна поддерживать возможность скрыть отчет для всех пользователей. Должна быть реализована возможность изменения положения отчета в списке доступных пользователю отчетов, а также группировки отчетов по категориям. Отображение отчетов Аналитическая подсистема должна поддерживать возможности: – просмотр всех отчетов в Web-интерфейсе; – скачивания отчета в формате xls и docx; – просмотр или скачивание отчета в отрыве от остальных отчетов в любом личном кабинете Системы или в открытой части портала; – предоставление возможности поэтапного заполнения параметров с автоматическим получением фильтрованных списков для зависимых параметров; – просмотр графиков, указанных в отчетных формах, с дополнительной маркировкой отчетов, в которых присутствуют графики. Взаимодействия между частями подсистемы отчетности и другими подсистемами должно осуществляться посредством REST-API. - Требования к подсистеме управления контентом - Система управления порталом (CMS) должна обеспечивать: - доступ к размещенной информации без использования программного обеспечения, установка которого на технические средства пользователя информации требует заключения лицензионного или иного соглашения с правообладателем программного обеспечения, предусматривающего взимание с пользователя платы; - портал должен быть разработан с использованием средств разработки, относящимся к свободному программному обеспечению. - система управления сайтом (CMS), входящая в состав Системы должна обеспечивать возможность создания Заказчиком плагинов (расширений). - CMS должна обеспечивать возможность передачи пользователем прав на редактирование отдельных страниц (разделов) сайта для обеспечения наполнения информацией с участием нескольких пользователей; - CMS должна предусматривать механизм рецензирования, при котором пользователь может иметь право на создание и редактирование публикаций в определенном разделе, но при этом публикации сохраняются в статусе «черновик» и проверяются пользователем с правами публикации контента для общего доступа, который в случае корректности, обеспечивает публикацию страницы для всеобщего доступа. - CMS должна позволять осуществлять обсуждение публикаций пользователями, обеспечивать связь между публикациями - CMS должна обеспечивать работу с пользователями, которые имеют права «Редактор портала». - должны быть обеспечены возможности по публикации фото-галерей, а также по прикреплению файлов к публикации с их отображением (или без отображения); если отображение файлов не включено, то они могут быть доступны в виде прямых ссылок из текста публикации; - должны быть обеспечены возможности сквозного полнотекстового поиска по всем публикациям на портале с учетом прав доступа пользователей; - должна быть обеспечена поддержка SSL – шифрования HTTP – трафика (протокол HTTPS). SSL – сертификат предоставляется Заказчиком. - - Участник закупки указывает в заявке все значения характеристики - Подраздел «Публикация» (начало описания) – наименование; – тип публикации – выбор из справочника: публикация, новость, галерея; – событие – должен обеспечиваться выбор из списка событий, доступных для корневого раздела и подразделов (подсайтов), вышестоящих по отношению к публикации, а также находящихся с ней на одном уровне иерархии портала. При выборе события пользователем, публикация будет отображаться среди связанных с событием страниц; – алиас – должна быть возможность задавать алиас для доступа к публикации по адресу / ; – категория – в Системе для администратора портала должна быть обеспечена возможность ведения справочника категорий публикаций (например – родителям, учащимся, педагогам …). В CMS должен быть реализован отбор и выдача публикаций (статей) из разных разделов и разных сайтов, входящих в портал по категориям в хронологическом порядке; – статус версии – выбор из справочника: разрешена, не проверена, на доработку, запрещена. Модератор портала (сайта, раздела) должен иметь право менять статус и сопровождать изменение замечаниями для авторов публикации, не имеющих права публикации; – хост – адрес сайта по которому открывается данный раздел и его подразделы, как отдельный интернет-ресурс; – ключевые слова (теги) публикации – выбор из автоформируемого публичного списка тегов. Если нужных слов нет в списке, должна быть реализована возможность внести ключевое слово в ручную, затем оно будет автоматически доступно в списке; – шаблон – шаблон страницы (раздела), должна быть обеспечена поддержка шаблонов в формате twig (https://twig.symfony.com/); – шаблон для подчиненных публикаций – должен быть реализован шаблон для подчиненных страниц (разделов), должна быть обеспечена поддержка шаблонов в формате twig; - Подраздел «Публикация» (окончание описания) – дата публикации – должна генерироваться автоматически, должна быть реализована возможность изменения для пользователей, имеющих административные привилегии; – вес – должен определять вес публикации в текущем контексте; – закрыт – публикация/раздел недоступна никому, кроме автора; – скрытый – отсутствует в меню, раздел доступен только по прямой ссылке, алиасу или адресу сайта; – показывать медиа – должны показываться прикрепленные медиа-файлы; – показывать файлы – при включении данной опции портал должен показывать файлы, прикрепленные к публикации. Если опция не включена, файл не отображается, но может быть доступен по ссылке из WEB-контента публикации; – не подлежит удалению – страница (раздел) не должна быть никем удалена, пока не будет отключена опция; – корневая – страница является «разделом», включается в навигационные структуры (меню); – репост в соц.сети – к странице добавляются функции репоста контента в социальные сети; – плагин – в случае включения должна быть обеспечена возможность указать название плагина: код в результате работы которого генерируется контент, выводимый на портал; – разрешить комментарии – в случае включения должны быть доступны две дополнительные опции: разрешить анонимные комментарии (разрешить комментарии неавторизованным пользователям), запретить добавлять комментарии (ранее добавленные комментарии должны быть видны, но новые добавить нельзя). Комментарии должны отображаться в соответствии с предусмотренным в шаблоне дизайном. - Подраздел «Содержание» – web-редактор с панелью инструментов для редактирования текста, включающим опции реализованные в виде пиктограмм: – стиль шрифта: жирный, наклонный, зачеркнутый и подчеркнутый; – выравнивание абзаца: по левому краю, правому краю, по центру и по ширине листа; – выделение текста цветом; – работа с буфером обмена: копировать, вырезать, вставить, вставить как текст, вставить из Word; – поиск; – замена; – вернуть операцию; – повторить операцию; – очистить стиль; – редактор HTML – кода; – предварительный просмотр; – печать; – стиль – картинка слева, картинка справа; – абзац – Заголовок 1, Заголовок 2, ...; – шрифт – выбор типа шрифта; – размер – выбор размера шрифта; – маркированный список; – нумерованный список; – добавить/изменить якорь; – добавить/изменить изображение: должно быть обеспечено размещение изображений пользователем в внутренней коллекции изображений и работа с коллекцией – удаление и скачивание изображений из коллекции; – верхний индекс; – нижний индекс; – добавить/изменить клип: должно быть обеспечено размещение видеоклипов пользователем в внутренней коллекции и работа с коллекцией – удаление и скачивание видео из коллекции; – добавить/изменить таблицу (и другие операции с таблицей); – изменить CSS-стиль. – сохранить – нажатие кнопки должно приводить к записи изменений; – отменить. - Подраздел «Файлы» В разделе должна быть реализована возможность загрузки файлов, которые могут быть показаны вместе с публикацией в сопровождении пиктограмм (pdf, Word и тп). Должны быть доступны следующие операции: – открыть – выбрать один или несколько файлов для загрузки; – загрузить – загрузить на сервер выбранные, но еще не загруженные файлы; – отменить – отменить выбор файлов для загрузки; – удалить – удалить один или несколько выбранных файлов. Для каждого файла должно быть доступно скачивание. При указании соответствующей опции для публикации, файлы должны отображаться на портале вместе с контентом публикации. Подраздел «Права» В разделе должна быть реализована возможность выбора пользователя из числа зарегистрированных на портале. В системе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». При выборе пользователей должен быть обеспечен поиск по фамилии, имени, отчеству, учетной записи, СНИЛС. При добавлении пользователя должны быть указаны права пользователя в отношении раздела (страницы): «Администратор» – все права на раздел и подразделы, «Только чтение» – просмотр страниц, «События полный» – управление событиями, «Редактор без права изменения статуса» – создание страниц без права изменения статуса публикаций. «Администратор» должен иметь возможность предоставить другим пользователям права для редактирования страниц и разделов внутри раздела, к которому ему предоставлен доступ. Подраздел «Ссылки» Должен обеспечивать возможность связать публикации (разделы) между собой для представления связанного контента на портале (должно быть предусмотрено в шаблонах). Должна быть предусмотрена операция «Добавить», позволяющая выбрать один или несколько разделов, связанных с публикацией. - Раздел главного меню «Пользователи» В разделе пользователь, являющийся администратором портала может управлять правами других пользователей. В разделе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». Пользователи должны получать роли, такие же, как приведены выше в описание подраздела «Права». Эти роли должны распространяться на весь портал. Раздел главного меню «События» Должно быть обеспечено дополнение событий, их изменение и удаление. Информация о событии должна включать в себя: – наименование события; – краткое описание события; – изображение (баннер) события; – дата начала события; – дата завершения события; – вес – используется для определения порядка отображения событий; – разрешить комментарии – обеспечивается добавление и показ комментариев; – разрешить анонимные комментарии – комментарии могут добавлять неавторизованные пользователи; – запретить добавлять комментарии – комментарии по-прежнему показываются, но добавление новых комментариев заблокировано. Раздел главного меню «Обратная связь» Должен содержать список сообщений, направленных через сервис обратной связи, который должен быть реализован для разделов организаций на портале (например — лагерей детского отдыха, ОО и других). Сервис обратной связи должен обеспечивать отправление обращения на официальный e-mail организации и одновременную его запись в базу данных портала. Информация о сообщении должна включать в себя: код организации-получателя, имя отправителя, email, текст сообщения. - Требования к подсистеме «Региональный образовательный портал» - В подсистеме должны быть предусмотрены возможности доступа к единой базе данных документов образовательных организаций и управлений образования, включая функции поиска необходимых документов. Поисковая форма по единой базе данных документов должна включать в себя, как минимум, следующие поля: - уровень документа (федеральный, региональный, муниципальный, уровень ОО); - тип документа (Приказ, Устав, Результаты самообследования и т. д.); - категория документа (тематика: ЕГЭ, ОГЭ, ГВЭ, Информатизация, Одаренные дети, …); - номер документа; - ключевые слова (поиск по названию и аннотации документа); - наименование организации (подстрока, часть наименования); - дата начала – дата завершения (диапазон дат, в которые должна попадать дата документа). При авторизации, на региональном образовательном портале, педагогического работника, пользователю должна быть доступна функция ведения персонального сайта. Пользователи публичной части регионального образовательного портала должны иметь возможность перехода к просмотру контента сайтов учителей c использованием карточки любой ОО, из подраздела «Руководство. Педагогический (научно-педагогический) состав». На портале должен быть реализован механизм общественной оценки, позволяющий любому авторизованному через ЕСИА пользователю оставить отзыв о работе каждого педагога. - - Участник закупки указывает в заявке все значения характеристики - Структура открытой части портала представлена на Рисунке 1 приложения 2 к Контракту. Исполнитель должен согласовать с Заказчиком в ходе выполнения работ проект дизайна портала и карточек ОО, размещаемых на портале. После направления на согласование проекта дизайна, Заказчик должен дать ответ-согласование или замечания в течении 2 рабочих дней. После устранения замечаний, Исполнитель должен направить проект дизайна вторично. Проект дизайна направляется в формате графических файлов — jpg, pdf или png. Структура титульной страницы портала: Блок 1. Вызов главного меню портала. В главном меню должны быть реализованы следующие разделы: 1. Система образования. Раздел должен открывать форму поиска по образовательным организациям региона. Блок 2. Лого и наименование портала (должны быть предоставлены Заказчиком). Блок 3. Поиск – открывается строка и обеспечивается поиск по всем общедоступным публикациям на портале (не должен включать поиск по базе документов и карточкам организаций). Блок 4. «Вход в единый личный кабинет». Для входа в личный кабинет могут быть использованы следующие типы учетных записей: 1) администратор системы; 2) координаторы всех уровней (см. п. 1.10. Контракта «Решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации»; 3) подтвержденные учетные записи ЕПГУ (педагоги, учащиеся, руководители). В едином личном кабинете пользователь должен иметь возможность получить доступ ко всем функциональным подсистемам к которым ему предоставлены права доступа. - Блок 5. Должен содержать ленту событий. Слайдер событий должен представлять собой события, включающие изображение и текст (описание). Если слайдер включает более одного выводимого события, то они должны меняться (пролистываться) автоматически. Под слайдером должен находиться переключатель на одно из открытых для вывода событий. Если щелкнуть по событию, должна открываться страница события, где выводится изображение, подробное описание события и связанные с ним публикации – при внесении публикации может быть указана его связь с событием (см. описание подсистемы управления порталом). События и изображения для обработки и вывода на портал, как и другой начальный контент для заполнения главной страницы портала, предоставляется Заказчиком. Блок 6. Новости. Должны выводиться три последние новости из ленты новостей портала. Должна быть предусмотрена кнопка (ссылка) «Все новости», для открытия ленты новостей портала с возможностью их фильтрации по календарю (должна быть возможность указать диапазон дат). - Блок 7. Карта системы образования. Должна быть реализована возможность выбрать типы отображаемых организаций (учреждений): 1. Организации и учреждения. 1.1 Детские сады. 1.2 Школы. 1.3 Школы-интернаты. 1.4 Учреждения дополнительного образования. 1.5 Учреждения профессионального образования. 1.6 Органы управления образованием. 1.7 Иные организации. При щелчке по значку организации (учреждения) на карте, должна открываться ее карточка, с которой можно перейти и на официальный сайт организации (он может быть организован как на портале, так и на внешних ресурсах, например — ГосВеб). В блоке должна быть доступна ссылка «Система образования». В этом разделе должен открываться список организаций и органов управления образованием со следующими полями: - АТЕ – наименование муниципалитета; - наименование – наименование организации/органа управления образованием; - руководитель – ФИО руководителя; - e-mail – адрес электронной почты; - юридический адрес; - телефон(ы). При щелчке по наименованию, которое должно являться ссылкой, на новой закладке должна открываться карточка организации. Должна быть предусмотрена выгрузка реестра в формате электронной таблицы (файл в формате xls). Помимо полей, приведенных выше в выгрузку должно быть добавлено поле «Должность руководителя». Для списка организаций должен быть предусмотрен фильтр, включающий в себя: - выбор муниципалитета; - фрагмент наименования; - выбор одного или нескольких типов организаций: - детские сады; - школы; - школы-интернаты; - профессиональное образование; - дополнительное образование; - управления образования; - иные организации. - Блок 9. Мероприятия в образовании (окнчание описания). В разделе должна быть доступна возможность записи на мероприятия. Для мероприятий Исполнитель должен разработать структуру карточки и реализовать ее с использованием Конструктора. Карточка должна включать наименование, тип мероприятия, фотогалерею (просмотр приложенных фотографий), описание мероприятия, ссылки на сайты, а также дополнительные сведения, например – структуру мероприятия и его этапы, информацию о местах проведения, опции информационного сопровождения мероприятия и т.п. Для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например . . . - Подсистема «Региональный образовательный портал» должна обеспечивать публичный интерфейс для доступа к общей информации о системе образования, карточкам всех образовательных организациях региона в одном месте с переходом к сайту образовательной организации. Доступ к компонентам подсистемы находящимся вне публичного контура должен быть доступен только после прохождения процедуры авторизации средствами ЕСИА или с помощью учетной записи координатора. Подсистема «Региональный образовательный портал» должна использоваться как единая точка входа во все подсистемы для работников ОО, обучающихся и родителей (законных представителей), для предоставления услуг в сфере образования в электронном виде. Для этих целей она должна быть интегрирована с единым личным кабинетом Системы, созданным ранее. Функционал подсистемы должен обеспечивать возможность ведения разделов портала, используя подсистему управления контентом. - Блок 8. Наши показатели. В прямоугольных или иных блоках должны быть выведены показатели, рассчитанные на основе эксплуатации системы, например: число обучающихся в ОО, Заявлений ГИА – число заявлений, поданных на ГИА в электронном виде и т. п. Должна быть предусмотрена кнопка «Дашбоард», при нажатии на которую должна открываться аналитика по работе ОО с системой и предоставлению услуг в электронном виде. В частности должен быть обеспечен вывод раздела «Заполнение открытых данных», включающий три графических отчета: 1. гистограмма по муниципалитетам, показывающая процент ОО, сформировавших «Открытые данные» более, чем на 80 %; 2. при выборе муниципалитета, должна выводиться гистограмма по школам (процент заполнения) и дополнительные данные. Должна выводиться информации о внесении координат зданий, адрес сайта, информация о доступности сайта, дата последней загрузки документов в «Открытые данные». 3. при выборе школы – гистограмма о степени заполнении разделов «Открытых данных»: - основные сведения; - структура и органы управления ОО; - документы; - образование; - образовательные стандарты; - руководство. Педагогический состав; - материально-техническое обеспечение и оснащенность образовательного процесса; - стипендии и иные виды материальной поддержки; - платные образовательные услуги; - финансово-хозяйственная деятельность; - вакантные места для приема (перевода). Формирование открытых данных в Системе уже реализовано ранее. Данные отчеты и дашбоард должны строиться на основе наполнения базы данных. - Блок 9. Мероприятия в образовании (начало описания). В разделе «Мероприятия в образовании» на главной странице должны размещаться последние мероприятия с возможностью фильтрации по уровням событий и другим их свойствам, муниципалитетам, направленности, типам образовательных организаций, конкретным образовательным организациям, а также строка, обеспечивающая интеллектуальный полнотекстовый поиск по мероприятиям. Должны показываться карточки трех (шести, девяти и т.п.) последних мероприятий, либо карточки мероприятий, настроенных для выдачи на главной странице модератором системы. Число выводимых по умолчанию мероприятий должно настраиваться модератором. В блоке мероприятий должны быть реализованы возможности: – перехода к полной картотеке мероприятия; – перехода в фильтру мероприятий, полнотекстовый поиск по мероприятиям, переход к карте мероприятий, где мероприятия показаны в привязке к месту проведения (по умолчанию место проведения мероприятия должно совпадать с главным зданием организации, но при планировании мероприятий в личном кабинете организации и при визуализации на портале должно быть предусмотрено проведение многоэтапных и составных мероприятий, для которых места проведения могут быть различными, в частности – школьный этап всероссийской олимпиады школьников проводится во всех общеобразовательных организациях, муниципальный и региональный – в специально определенных местах. Кроме того, Исполнитель должен учитывать, что кроме этапа место проведение зависит от части составного события, например – областной этап олимпиады по физике может проводиться в одном месте, а по биологии – в другом месте и в другое время). - Требования к подсистеме «Аттестация педагогов» - Подсистема должна обеспечивать формирование объективного портфолио педагога, подачу электронного заявления на аттестацию с использованием ЕСИА и форм ЕПГУ, экспертизу аттестационных документов и проведение онлайн-заседаний аттестационной комиссии. Личные кабинеты должны быть созданы на базе регионального образовательного портала и интерфейса для работы с данными. Основные функции в личных кабинетах представлены в виде раскрываемых блоков, каждый блок в конечном итоге открывается в виде интерфейса для работы с данными или форм и отчетов, являющихся плагинами портала, реализующими конкретный пользовательский функционал. - - Участник закупки указывает в заявке все значения характеристики - Раздел Личный кабинет организации. Личный кабинет любой организации доступен под учетной записью координатора организации. Кроме этого, координатор может внести СНИЛС пользователей, получающих возможность действовать от имени организации, войдя в Систему с использованием ЕСИА, а также указать роль пользователя. Если пользователь прописан в нескольких организациях, то после входа в личный кабинет, у него появляется возможность выбора организации, от которой он действует. Пользователь может работать в личном кабинете от одной конкретной организации («текущая организация»), сменить ее. - Раздел Аттестация педагогических работников (начало описания): Аттестация педагогических работников для получения первой и высшей категории проводится региональной аттестационной комиссией, формируемой в соответствии с приказом регионального органа исполнительной власти, осуществляющего функции управления в сфере образования. Для подачи заявлений на аттестацию и получение информации о ходе его рассмотрения и результатах Исполнитель должен использовать вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Аттестация педагогических работников образовательных организаций, находящихся в ведении субъекта Российской Федерации, муниципальных и частных организаций» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e6d19-ff80-11eb-ba23-33408f10c8dc/versions/2dc85429-8816-4f03-bf27-a617daa885e3?area=PROD). Администратор системы должен иметь возможность добавить одну или несколько организаций в качестве «Оператора аттестации педагогических работников» (организация-оператор). Администратор такой организации, добавив пользователей в систему, тем самым предоставляет им возможность доступа к разделу «Аттестация педагогических работников» Системы в качестве координатора. - Раздел Аттестация педагогических работников (продолжение описания): В разделе «Аттестация педагогических работников» организации-оператора должен быть доступен раздел «Справочники». В этом разделе должна быть реализована возможность формирования дополнительных справочников, необходимых для обеспечения процесса аттестации педагогических работников: – категории работников образования, проходящих аттестацию (например, воспитатели ДОО, учителя начальных классов, учителя – предметники, мастера производственного обучения). Обеспечена возможность указать «предметную специализацию», которая может включать один или несколько предметов; – критерии аттестации – набор критериев, по которым вносится информация экспертами. Для каждого критерия реализована возможность указать минимально допустимое значение, категории работников образования к которым применим критерий, а также критерий, частью которого (подкритерием) является данный критерий. При обработке данных система автоматически суммирует показатели критериев нижнего уровня для расчета значения критериев первого уровня. Внесение информации вручную экспертами реализовано для критериев, у которых отсутствуют подчиненные критерии (подкритерии); – реестр экспертов – включает в себя данные об эксперте, включая ФИО, место работы, email, телефон, а также перечень лет участия в оценке, перечень категорий работников образования, в экспертизе аттестационных дел которых может принимать участие эксперт, а также предметов (если категория предполагает предметную специализацию). В реестре обязательно указан СНИЛС. Система по нему предоставляет доступ пользователю-эксперту к необходимым функциям в личном кабинете (сличать СНИЛС из базы данных и полученный при авторизации с использованием ЕСИА); – график заседаний комиссии – указывается дата и время проведения заседания. - Раздел Аттестация педагогических работников (окончание описания): На заседании комиссии могут рассматриваются все заявления, прошедшие к этому времени экспертизу (см. раздел «Заседания комиссии»). Если заседание комиссии уже состоялось, изменение записи в графике блокируется. График заседаний доступен с просмотром по годам. - Раздел «Экспертиза» Раздел «Экспертиза» должен быть включен в раздел «Аттестация педагогических работников». В разделе «Экспертиза» разделе доступны функции (начало описания): – просмотр всех поступивших в течении выбранного календарного года заявлений и их статуса (возможность фильтрации заявлений по статусу, муниципалитету, образовательной организации, категории работников образования и предмету (если категория предусматривает указание предметов), а также по результатам экспертизы; – техническая проверка заявлений проводится сотрудниками организации – оператора аттестации педагогических работников; в случае обнаружения технических недостатков в поданном заявлении (пакете документов), заявление может быть возвращено заявителю с заключением о найденных технических ошибках; если заявление прошло проверку, соответствующий статус возвращен на ЕПГУ (если заявление подавалось с использованием формы на ЕПГУ) и в ЛК заявителя в Системе; заявления для технической проверки выводятся в последовательности поступления; - В разделе «Экспертиза» разделе доступны функции (окончание описания): – автоматизированное распределение заявлений на экспертизу обеспечивает распределение заявлений, прошедших техническую проверку, на экспертизу, в соответствии со специализацией экспертов; сначала на проверку выдаются случайным образом заявления из числа прошедших первую проверку или наиболее ранних заявлений, еще не прошедших экспертизу; эксперты в личном кабинете указывают доступные им для проверки категории заявлений и нажать кнопку «Получить заявление на экспертизу»; в личных кабинетах сотрудников организации-оператора отображается статистика о числе заявлений, прошедших экспертизу в разрезе числа дней, прошедших со времени подачи (более 60, от 40 до 60, от 20 до 40, от 0 до 20) и категорий заявлений, а также число заявлений, готовых к рассмотрению на заседании комиссии и число дней, оставшихся до даты проведения комиссии; если используется режим проверки двумя экспертами отображаются сведения о числе полностью прошедших экспертизу заявлениях; – анализ работы экспертов по категориям заявителей выводятся сведения о состоянии поступления и экспертизы заявлений, а также информация о числе экспертов, а при выборе категорий – перечень экспертов с указанием числа сформированных экспертных заключений; при выборе эксперта: – переключение режима экспертизы (проверка одним экспертом, проверка двумя экспертами), указание процента расхождения в оценках экспертов при превышении которого заявление отправляется третьему эксперту (только для случая проверки двумя экспертами); в случае если заявление проверено тремя экспертами – берутся результаты двух наиболее близких по сумме баллов экспертов и оценки по каждому критерию находятся как средние между двумя выбранными результатами и округляются. - Раздел «Заседания комиссии»: возможность выбора заседания из числа ранее созданных, а также добавления нового заседания. для еще не состоявшегося заседания должны обеспечиваться следующие возможности: – назначение заявлений из числа прошедших экспертизу (могут выбираться категории заявителей и число заявлений), реализована возможность индивидуального выбора заявлений для рассмотрения комиссией; – приглашение на заседание комиссии экспертов (могут выбираться категории экспертов и их число), реализована возможность индивидуального приглашения экспертов на заседание комиссии; – выбор формата проведения заседания – онлайн. При проведении заседания все члены комиссии должны автоматически приглашаться на заседание через систему сообщений и по электронной почте. Для онлайн-заседаний у всех участников в личном кабинете должен появляться доступ в тестовую комнату для тестирования связи. При проведении заседания комиссии в Системе должна быть обеспечена возможность голосования, в личном кабинете каждого участника выводятся вопросы для голосования и с использованием простой электронной подписи все участники имеют возможность проголосовать. – установка статуса заседания (запланировано, подготовка, проведение, завершено); – прикрепление протокола заседания комиссии – отсканированный итоговый протокол заседания комиссии в формате png, jpg, pdf и/или протокол в формате odt; имеется возможность прикрепить файлы после завершения заседания. При проведении онлайн-заседаний пользователи должны иметь возможность использовать web-камеры (видеосвязь), микрофоны (аудиоконференция), общую доску для презентаций и совместной работы, а также чат. - Раздел «Мои заявления»: Раздел «Мои заявления» служит для подачи заявлений и получения по ним обратной связи любым пользователем Системы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала Госуслуг. Внутри раздела должны быть предусмотрены подразделы, оформленные в виде пиктограмм, функционал которых описан далее. При выборе раздела должна отображаться ссылка «Информация об аттестации педагогов», которая ведет на раздел «Аттестация педагогических работников» портала, где в открытом доступе размещаются документы, посвященные аттестации педагогических работников региона, а также информация о числе поданных заявлений по категориям работников системы образования и числе работников, прошедших аттестацию. Далее должна выводиться для педагога информация о его категории, дате прохождения последней аттестации и рекомендация пройти аттестацию в указанный период времени. Ниже должна размещаться кнопка подачи заявления на аттестацию на ЕПГУ и кнопка подачи заявления на аттестацию на региональном портале (через Систему). Вне зависимости от способа подачи заявления, все поданные заявления должны отображаться в личном кабинете Системы, а также должен показываться статус заявления и после появления – экспертное заключение и результаты аттестации. - Раздел «Сообщения»: Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». При этом в красном круге поверх пиктограммы «Сообщения» пользователь должен видеть число пришедших и не просмотренных еще сообщений. К сообщениям должны приводить все события, происходящие с заявлениями. Сообщения должны включать прямые ссылки для перехода к формам, страницам, документам и т. п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя. - Требования к функциям интеграции с ЕПГУ. Использование СМЭВ3 для интеграции с формами на ЕПГУ. Исполнитель должен реализовать приведенную ниже схему интеграции с помощью специально разработанного модуля, работающего с универсальным видом сведений и обеспечивающего гибкую настройку (изменение параметров) со стороны Заказчика без изменения исходных кодов программного обеспечения. Схема взаимодействия с СМЭВ3 приведена на рисунке 2 приложения 2 к Контракту. 1. СМЭВ3 – федеральная система (ЕПГУ), взаимодействует с внешними системами по протоколу SOAP. 2. Сервис взаимодействия со СМЭВ3 – промежуточная система, Spring Boot приложение (или иное приложение, разработанного на базе свободного программного обеспечения). Упрощает взаимодействие со СМЭВ и выполняет общие операции: выполнение операций для отправки и получения сообщений от СМЭВ (периодический опрос, подтверждение, отправка и получение сообщений); преобразование SOAP-сообщений и перенаправление их в локальную очередь; журналирование – сохранение оригинальных запросов от СМЭВ. 3. Сервис криптографии – обеспечивает подпись запросов по формату СМЭВ и ГОСТ (может быть использован СриптоПро JCP или иное решение). 4. Брокер сообщений (например, на базе ActiveMQ; Исполнителем может быть использовано иное открытое решение) – работа с очередями, хранение необработанных сообщений. 5. Клиенты – приложения или сервисы Системы, которым необходимо взаимодействовать со СМЭВ. Синхронное взаимодействие реализовано по протоколу HTTP, асинхронное – с использованием протокола JMS. - Требования к подсистеме «Летний отдых» - Подсистема «Летний отдых» должна обеспечивать ведение регионального реестра мест летнего отдыха и оздоровления, ведение страниц мест отдыха и оздоровления детей, формирование информации о сменах и группах, внесение лимитов, обеспечение подачи заявлений с учетом муниципальных лимитов на путевки с полной или частичной компенсацией стоимости, автоматизация процесса рассмотрения и подтверждения путевок с учетом региональных особенностей а также возможность настройки безналичной оплаты (интернет-эквайринг), обеспечивать поддержку детского туристического кэшбека (при его наличии) с использованием национальной платежной системы (карты «Мир»), а также формирование базы данных фактов отдыха (для компенсации с использованием заявлений на ЕПГУ). Подсистема должна обеспечивать размещение на региональном образовательном портале информации о местах отдыха и оздоровления в виде картотеки с возможностью ведения сайтов мест детского отдыха и оздоровления, а также размещение мест детского отдыха и оздоровления на карте региона. - - Участник закупки указывает в заявке все значения характеристики - Подсистема «Летний отдых» должна включать в себя раздел на региональном образовательном портале и систему личных кабинетов для следующих категорий пользователей: 1. Представитель организации. 2. Родитель/законный представитель. 3. Администратор. Раздел на Портале должен, как минимум, включать в себя: – возможность осуществления входа в личные кабинеты представителя организации, родителя/законного представителя, администратора; – сокращенный перечень организаций с возможностью перехода к странице с полным перечнем. По щелчку на конкретную организацию должна открываться страница с ее подробным описанием. Авторизация родителей/законных представителей должна осуществляться посредством ЕСИА. Доступ к подсистеме должен быть предоставлен организациям, для которых администратором системы настроен доступ к ведению информации для мест детского отдыха и оздоровления. Представители организаций, получают возможность настраивать профиль организации, в качестве места детского отдыха и оздоровления. Основная информация об организациях, на базе которых создаются места отдыха и оздоровления детей, включает в себя сведения, перечисленные в таблице 5, приложения 2 к Контракту. Дополнительная информация о местах детского отдыха и оздоровления включает в себя сведения, перечисленные в таблице 6, приложения 2 к Контракту. Сведения о зданиях организации перечисленные в таблице 7, приложения 2 к Контракту. - Для ведения очереди заявлений (забронированных мест), полученных на предоставление услуги детского отдыха и оздоровления, в личном кабинете организации должен быть доступен раздел «Работа с заявлениями». В этом разделе должна быть реализована работа со справочниками (внесение информации о сменах, числе мест и возрастных категориях детей, а также местах размещения в привязке к месту детского отдыха и оздоровления и зданию, в котором будет размещен ребенок по путевке). Сотрудник организации, имеющей места отдыха и оздоровления детей в каникулярное время, должен иметь возможность подтверждения электронных заявлений и выдачи путевок, внесения заявлений, получаемых в бумажном виде, внесение заявлений на отказ от путевок, а также возможность запроса по электронным заявлениям граждан дополнительной информации, выставления счетов на полную или частичную оплату услуг, а также оплаты по карте с использованием интернет-эквайринга. В системе должна быть предусмотрена возможность подключения интернет-эквайринга, но сама настройка для зачисления платежей на счета конкретных организаций контрактом не предусмотрена. Система обеспечивает выставление счета на полную или частичную оплату услуг детского отдыха и оздоровления в каникулярное время в личном кабинете заявителя. Для интеграции с платежными системами в Системе должен быть реализован простой API, который на основании номера счета, имени и даты рождения ребенка возвращает в ответ внешней системе назначение платежа и сумму платежа. - Исполнитель должен реализовывает интеграцию с порталом гос.услуг для получения в систему заявлений с портала с использованием вида сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время», доступного по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD. Сама форма расположена по адресу https://www.gosuslugi.ru/600173/1/form и предназначена для подачи заявлений для граждан имеющих право на бесплатную путевку для получения детского отдыха и оздоровления. Результатом оказания услуги является решение о постановке в очередь на получение путевки в электронном виде. Другие категории граждан должны иметь возможность подать заявление с использованием Системы. Исполнитель также должен обеспечивать по полученным с ЕПГУ заявлениям передачу результатов их рассмотрения на ЕПГУ, а также передать сообщение о возможности дальнейшего взаимодействия в цифровом формате в Системе. Раздел «Мои заявления» должен служить для подачи заявлений и получения по ним обратной связи любым пользователем подсистемы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала гос.услуг. - Подсистема при выборе раздела должна предлагать воспользоваться поиском и выбором места отдыха «Перейти к поиску и выбору мест отдыха и оздоровления». После того, как пользователь нашел место для отдыха и открыл его карточку, он должен иметь возможность выбрать время отдыха (смену), либо наоборот, пользователь указывает для поиска время отдыха и выбирает подходящее место. В случае, если открыто бронирование, родитель выбирает «Подать заявку». В этом случае, выведено два варианта: 1) заявление на бесплатную путевку в электронном виде на портале гос.услуг (при этом родителю даны пояснения, какие категории граждан имеют право на бесплатный отдых и оздоровление детей на территории субъекта Российской Федерации); для подачи заявлений на бесплатный детский отдых и оздоровление используется вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD); 2) заявления на путевку с полной или частичной оплатой (в этом случае должна открываться форма заявления в личном кабинете). - Запросы дополнительной информации и уточнения от организации детского отдыха также должны поступать родителям (законным представителям) через личный кабинет. Если бронь одобрена, должен быть выставлен электронный счет, квитанцию об оплате которого (или иное подтверждение) необходимо загрузить в личный кабинет в течении 15 дней. После подтверждения получения оплаты на счет организации, в личном кабинете генерируется электронная путевка, содержащая: 1) QR – код с адресом страницы лагеря; 2) название организации; 3) данные ребенка (ФИО, дата рождения); 4) день заезда (начала смены); 5) день выезда (конца смены). - Состав электронной формы подачи заявления в места детского отдыха и оздоровления с использованием системы: 1. Смена (из справочника). 2. Подтверждение ознакомления с: – условиями пребывания в выбранном лагере (документ – ссылка); – правилами внутреннего распорядка в лагере (документ – ссылка); – правила использования мобильных телефонов в лагере (документ – ссылка). 3. Количество путёвок (возможность подачи заявок на 1 и более ребенка). 4. Заявитель дает согласие: – на обработку персональных данных заявителя и ребенка (детей); – на медицинское вмешательство; – на виды активностей (в т.ч. фото и видеосъемку) ребенка в лагере. ФИО заявителя (данные должны совпадать с данными, указанными в заявке и подтверждающих документах): - Дата рождения; - Контактный телефон (1 и более); - Электронная почта; - Адрес регистрации; - Адрес проживания; - Серия, номер паспорта; Подтвержденный статус семьи (отметить): – многодетная; – малоимущая; – неполная. Ребенок: - Фамилия; - Имя; - Отчество; - Свидетельство о рождении ребенка (серия и номер); - Дата рождения; - Пол (М/Ж); - Тип школы (из справочника: начальная (дошкольник), средняя, основная, лицей, гимназия, коррекционная (специальная), с углубленным изучением отдельных предметов; - Муниципалитет, школа (выбор из справочников); - Класс, буква (заполнить); - Подтвержденный статус ребенка (отметить); Состоит ли на различных видах профилактического учета: – ОВЗ; – инвалидность; – другие особенности (указать при наличии). Категория для оформления путевки (из справочника): – полуоплатная; – трудная жизненная ситуация (малоимущая семья, опека инвалид ОВЗ, сирота); – работающая (указать место работы на территории региона, прикрепить справку с места работы); – участник профильной смены. Скан свидетельства о рождении ребенка (прикрепить) Документ, подтверждающий льготную категорию (при наличии, может быть несколько). - Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». Должно отображаться число пришедших и не просмотренных еще сообщений. К сообщениям приводят все события, происходящие с заявлениями, а также события в местах детского отдыха, в которых пользователь (его дети) получают услуги. Сообщения по возможности должны включать прямые ссылки для перехода к формам, страницам, документам и т.п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя. Для интеграции с формами на ЕПГУ должны быть использованы механизмы, описанные в разделе «Подсистема «Аттестация педагогических кадров». Состав полей и структуры данных подсистемы «Летний отдых», могут быть изменены в ходе выполнения работ по согласованию с Заказчиком. - Требования к подсистеме «Цифровой урок» - 4) Структура урока должна состоять из этапов. При редактировании урока должна быть реализована возможность указания следующих свойств этапов: 4.1) наименование этапа; 4.2) тип этапа (как минимум должны быть реализованы следующие типы этапов: «Текст», «Презентация», «Тест – выбор одного ответа», «Тест – выбор нескольких ответов», «Тест – ввод числа», «Тест – ввод строки», «Задание – загрузка файлов», «Просмотр файла», «Совместное редактирование текста»). Вне зависимости от типа этапа, педагогу предлагается HTML-редактор для размещения общего контента и отдельно контента для каждой из групп учащихся. При этом для любого этапа должна быть обеспечена возможность загрузки файлов, которые должны автоматически конвертироваться в pdf и просматриваться прямо из системы, это должно касаться также видео-записей, загружаемых в подсистему: должен быть реализован просмотр видео прямо через подсистему «Цифровой урок»; 4.3) дополнительные этапы – не включаются в обычный ход урока – да/нет. Если «да», этап не показывается педагогу при управлении уроком; 4.4) доступен участнику независимо от хода урока – да/нет – если «да», контент доступен ученику не только когда педагог активизирует этап при управлении уроком, а в любое время, например он может получить доступ к контентам, заданиям, самостоятельно, работая с подсистемой; 4.5) этап завершен – да/нет – показывается соответствующая пометка в названии этапа; 4.6) а редакторе этапа должна быть предусмотрена возможность вставки видео RuTube и объектов, поддерживающих тег , в частности должна быть обеспечена возможность встраивания интерактивных объектов проекта learningapps.org и других аналогичных решений, например – форм google. Редактор должен также предусматривать возможность вывода в рамках этапа внешних сайтов, разрешающих встраивание. - - Участник закупки указывает в заявке все значения характеристики - 5) Управление уроком. Педагог должен иметь возможность управлять показом этапов урока (педагог выбирает этап, этот этап выводится учащимся с учетом разделения контента по группам): пролистывать презентацию, загруженную в «Цифровой урок» при выборе соответствующего этапа, переключать этапы урока, содержащие голосования, анкетирования, представлять учащимся результаты в режиме реального времени. Все изменения в этапах урока и в контенте должны сразу отображаться на устройствах обучающихся (в браузере). Должен быть организован вывод контента этапов, подготовленных педагогом с помощью HTML-редактора (с возможностью загрузки изображений) на всех компьютерах (планшетах, смартфонах) учащихся, либо только на компьютере педагога, подключенном к проектору, интерактивной доске (панели); В качестве презентаций в этап урока должна быть обеспечена возможность загрузки документов в форматах odp, ppt, pptx, а pdf. При выборе этапа с презентацией в ходе управления уроком, педагог должен иметь возможность переключать ее слайды. Слайды должны перелистываться автоматически на устройствах учащихся. В режиме управления уроком учитель должен иметь возможность: – запустить видеоконференцию. Учитель должен иметь возможность демонстрировать свой рабочий стол, а также предоставить такую возможность учащимся или другим педагогам, проводящим урок с ним совместно; – запустить аудиоконференцию (тип конференции должен устанавливаться при настройке урока). 5.1) при выборе этапа «Совместное редактирование текста», педагог вместе с классом получает возможность редактировать текст совместно. Текст каждого пользователя должен выделяться цветом; - 5.2) при выборе этапа «Просмотр файла», файл должен выводиться учащимся на устройства и сразу открываться (если это pdf-файл), либо ожидать нажатия кнопки проигрывания (для аудио и видео – файлов); 5.3) при выборе этапа «Вопрос - ...», учащимся выводится вопрос анкеты, на который он получает возможность ответить. Все ответы должны собираться в результаты работы по группам у педагога в интерфейсе управления уроком; 5.4) при выборе этапа «Задание – загрузка файла» ученикам должен выводиться текст этапа (задание) и возможность дать ответ. Надо отметить, что задание не обязательно является текстом. Педагог должен иметь возможность нажать микрофон и озвучить задание. Учащиеся также должны иметь возможность в качестве ответа на задание, как прикрепить файл с диска, так и записать звук на компьютере или смартфоне или видео. Кроме того, ответом на задание может быть фото решения в тетради. Педагог должен иметь встроенный графический редактор в подсистеме, чтобы отметить ошибки прямо на фото решения. По заданиям и вопросам у педагога должна быть возможность дать комментарии каждому учащемуся (написать или записать аудио-комментарий, либо сделать фото), а также выставить балл (оценить ответ). При этом за работу на уроке педагог должен иметь возможность выставить дополнительные баллы, не привязанные к заданию (вопросу). - 6) Распределение учащихся по группам. Учитель должен иметь возможность распределить всех учеников по группам (не более 5). Разделение на группы может быть использовано при формировании контента, выдаче вопросов и заданий. 7) В подсистеме «Цифровой урок» должен быть реализован модуль «Студия цифрового урока», обеспечивающий следующий функционал: 7.1) создание видеоролика с настройкой его свойств (разрешение, частота кадров и др); 7.2) обеспечение в браузере редактирования компоновки материала: 7.2.1) изображение с web-камеры; 7.2.2) запись рабочего стола, окна программы или закладки в браузере и размещение на рабочем столе Студии; 7.2.3) подключение фоновой аудиозаписи (например, фоновой мелодии); 7.2.4) подключение (загрузка) презентации; 7.2.5) подключение микрофона; 7.3) запись видеофрагмента: при записи педагог может использовать инструменты (карандаш, линия, окружность и др.) и рисовать поверх слайдов презентации и размещенных на рабочем столе Студии окон, при этом объяснение материала микшируется с фоновым звуком и звуком от микрофона, размещенного на рабочем столе Студии; 7.4) монтаж ролика с использованием видеофрагментов: перемещение видеофрагментов, отключение видеофрагментов; 7.5) экспорт видеоролика и сохранение для использования в «Цифровом уроке». Функционал должен работать в браузерах Chromium, Yandex Browser без установки дополнительного программного обеспечения на компьютер учащегося или педагога. - 8) В подсистеме должна быть реализована Библиотека уроков. Любой педагог должен иметь возможность представить свой урок, для которого он разрешил использование другими педагогами, в библиотеке. В Библиотеке должен быть реализован поиск (фильтрация) уроков по типу/уровню образования, параллели, предмету (для общего образования). Выбрав урок любой педагог может просмотреть данные о нем, внесенные автором, включая перечень этапов и нажать «Импортировать» для использования в своей работе. 9) Администрирование. В подсистеме должен быть доступен модуль администратора подсистемы, обеспечивающий доступ, как минимум, к следующим данным: учителя (обязательные поля, как минимум: ФИО, email, СНИЛС); уроки; этапы урока; регистрационные данные участников урока; варианты текста для групп участников урока (HTML); варианты ответа (на вопросы анкетирования); ответы участников (на вопросы анкетирования); файлы этапа (загруженные педагогом дополнительные сведения); задачи для перекодирования файлов (техническая таблица, содержащая список задач и ссылки на файлы); данные участников, связанные с уроком (группа, баллы); список альтернатив для альтернативного этапа (педагог должен иметь возможность назначать альтернативные этапы различным группам детей); данные этапа, связанные с уроком (номер текущей страницы презентации, признак завершения этапа); учителя, которые могут совместно вести урок; теги участников (теги, установленные урокам самими учащимися). Должна быть обеспечена выгрузка всех перечисленных сведений из системы в формате MS Excel, а также в виде csv-файлов. - Функциональная подсистема «Цифровой урок» должна быть реализована с использованием личных кабинетов на региональном образовательном портале. Подсистема «Цифровой урок» должна представлять собой инструмент смешанного обучения, позволяющий создавать интерактивные уроки, модули и курсы, организовывать синхронное и асинхронное обучение с возможностью участия в занятиях педагогов и учащихся, находящихся в классе, дома, на улице, реализовывать в цифровом формате сетевые образовательные программы с участием нескольких образовательных организаций. Должен включать в себя электронную библиотеку образовательных материалов, формируемую на региональном уровне. Исполнитель должен предусмотреть реализацию следующих основных функций: 1) Вход в Подсистему педагога: 1.1) Вход в Подсистему с использованием личного кабинета педагога в Системе; 1.2) Вход в Подсистему с использованием ЕСИА. 2) Вход в подсистему обучающихся: 2.1) В подсистеме должна быть предусмотрена загрузка данных об обучающихся из любой внешней системы, для чего должен быть разработан специальный REST-сервис, позволяющий забирать из сторонних систем перечень обучающихся класса (группы) и включать их в Цифровой урок, для которого настроена ссылка (в сторонней системе при этом должен быть реализован совместимый сервис); данные должны передаваться в формате JSON; 2.2) В случае включения свободной регистрации, должна быть обеспечена возможность входа с одновременной регистрацией ученика и записью на урок по ссылке, по пригласительному коду, по QR-коду; - 3) При создании урока должна быть обеспечена настройка следующих опций: 3.1) Включить конференцию – педагог может выбрать аудио либо видеоконференцию (WEB RTC – конференцию). Видеоконференция должна обеспечивать возможности трансляции всего рабочего стола или выбранного окна; трансляцию web-камер, подключенных к компьютеру; обеспечить аудиотрансляцию; обеспечить использование общей доски с рисованием на ней всех участников урока и выводом презентации. Также в системе должна быть реализована возможность указания в качестве конференции произвольного стрима, например, организованного с использованием в VK или RuTube; 3.2) Свободная регистрация – возможность входить учащимся по коду, QR-коду или ссылке и регистрироваться в подсистеме и на урок; 3.3) Теги урока – указание тегов, например предмета или образовательной программы с функцией фильтрации по тегам при работе с перечнем уроков; 3.4) Разрешить другим учителям импортировать этот урок – педагогам можно отправить ссылку, по которой после входа в систему можно «забрать» урок себе (импортировать) для самостоятельного развития; - 3.5) Разрешить другим учителям совместно использовать этот урок – подключение других педагогов к уроку для его совместной разработки и проведения занятий, включая конференцию и контроль работы обучающихся, оценивание; 3.6) Выделение учащимся виртуальных машин – возможность выделения предварительно подготовленных педагогом виртуальных машин с операционными системами Linux или Windows для доступа через web из подсистемы «Цифровой урок»; 3.7) Включение чата для использования при проведении урока (в режиме управления уроком). Чат должен обеспечивать обмен сообщениями, записанными аудио и видео – фрагментами, скриншотами во время урока; 3.8) Должна быть обеспечена возможность использования встроенной электронной доски при управлении цифровым уроком (без необходимости запускать видеоконференцию). Учащиеся должны на своих устройства получить оповещение, что учитель запустил доску и иметь возможность подключиться к ней. Чтобы участник урока мог писать на доске, учитель должен дать ему доступ «вызвать к доске», тогда у учащегося должны появиться инструменты для работы на общей доске. - Требования к подсистеме «Мероприятия в образовании» - Основная информация о мероприятии. Раздел должен включать следующие сведения: Наименование мероприятия – строка, содержащая до 250 символов (обязательно). Описание мероприятия – web-страница (memo-поле). Галерея изображений – набор jpg или png – файлов (должно быть загружено хотя бы одно изображение, должны быть собледелены минимальные размеры изображения 1280 x 720 точек или более с возможностью вырезки прямоугольника с пропорциями 16:9 размером не менее 1280 x 720 точек). Видеоанонс (трейлер) мероприятия – видеофайл (не более 250 Mb). Разрешение не менее 720 dpi, соотношение сторон 16:9. Аудиоанонс (подкаст) с сменой слайдов из галереи изображений (могут быть заданы титульный слайд и моменты времени вывода других изображений из числа загруженных в галерею). Основной организатор мероприятия (строковое поле, по умолчанию соответствует полному наименованию организации, от имени которой создается мероприятие). Сайт мероприятия (не обязательное поле). Открыть раздел мероприятия на портале (да/нет). - - Участник закупки указывает в заявке все значения характеристики - Наименование раздела мероприятия на портале. Как сказано выше, для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например ... «.» предоставляет Заказчик для настройки системы на серверах Заказчика. должно формироваться в формате act_, тем самым обеспечивается его уникальность, но в тоже время координатор организации, планирующий мероприятие может придумать свое уникальное , например — указать «olympmath-2021» и т.д. Система должна обеспечить проверку корректности. В случае, если у мероприятия отсутствует раздел, для него должна быть создана только карточка, а функции регистрации, публикации материалов и т.п. не должны быть недоступны. Период проведения: - Дата/время начала мероприятия. - Дата/время завершения мероприятия. Дата начала и завершения должны быть обязательно указаны. По-умолчанию указание времени не должно обязательно требоваться от пользователя. Место проведения (не обязательно, может быть также определено в разделе «Управление мероприятием»). Место проведения (строка). Географические координаты (широта, долгота). - Следом за основной информацией должен следовать раздел «Классификация», который включает в себя сведения: - Статус мероприятия (в соответствии с таблицей 8 приложения 2 к Контракту); - Тип мероприятия (в соответствии с таблицей 9 приложения 2 к Контракту); - Форма участия: «Персональное участие» либо «Командное участие» (для тех типов мероприятия, где оно предусмотрено); - Направленность (в соответствии с таблицей 10 приложения 2 к Контракту); - Масштаб (уровень) мероприятия (в соответствии с таблицей 11 приложения 2 к Контракту); - Форма проведения мероприятия (в соответствии с таблицей 12 приложения 2 к Контракту). - За разделом «Классификация» следует раздел «Управление мероприятием». Раздел должен быть доступен только в случае, если для мероприятия определен раздел на портале, поскольку функционал должен быть реализован на сайте мероприятия для авторизованных в системе пользователей: - работников системы образования; - обучающихся; - родителей (законных представителей). Раздел «Управление мероприятием» должен содержать следующие данные 1. Этапы мероприятия (с возможностью добавления, удаления и корректировки информации об этапе) да/нет. По каждому этапу, если указано, «да», те этапы выделяются, указываются: 1.1 Наименование этапа мероприятия (номер этапа должен устанавливаться автоматически). 1.2 Организатор(ы) этапа мероприятия. По умолчанию должна быть указана организация, создавшая мероприятие (организатор этапа совпадает с организатором мероприятия). - Подсистема «Мероприятия в образовании» должна обеспечивать планирование и публикацию мероприятий всеми образовательными организациями и органами управления образованием, информирование потенциальных участников о планируемых мероприятиях, электронную запись на мероприятия, загрузку информации (тезисов, публикаций – при необходимости) и выдачу цифровых дипломов или других документов (при необходимости) участникам и победителям мероприятий. Должна обеспечиваться, в том числе, регистрация на олимпиады всех уровней, поддерживаться как личное, так и командное участие в мероприятиях. Должна быть обеспечена автоматизация проведения мероприятий, формирование страницы на портале или сайта мероприятия. Подсистема должна обеспечивать процесс подготовки и проведения школьного, муниципального и регионального этапа всероссийской олимпиады школьников. Подсистема должна быть интегрирована с ЕАИС ДО – единой автоматизированной информационной системой сбора и анализа данных по учреждениям, программам, мероприятиям дополнительного образования и основным статистическим показателям охвата детей дополнительным образованием в субъектах Российской Федерации (в отношении мероприятий). Вне зависимости от типа организации, в личном кабинете должен быть доступен раздел «Мероприятия организации», после выбора которого открывается перечень доступных мероприятий, а также возможность добавить, изменить мероприятие, включая его статус. - 1.2.1 Место проведения этапа мероприятия. Должен осуществляться выбор из числа зданий организатора мероприятия, по умолчанию должно выставляться главное здание организации. В случае, если в Системе для здания не определены географические координаты (широта и долгота) или для организации не внесены здания, должно обязательно требоваться указание названия места проведения (по умолчанию должна указываться строка, совпадающая с наименованием организатора), должны обязательно требоваться координаты места проведения (широта и долгота). По умолчанию, если указаны координаты места проведения всего мероприятия и организатор этапа совпадает с организатором мероприятия, должны использоваться те же координаты, которые могут быть откорректированы. Для мероприятий, проводимых в дистанционном формате информация о месте проведения не указывается. В разделе мероприятия на портале, в случае, если указано, что этапов «нет», дополнительная информация по этапам выводиться не должна. В качестве мест проведения должна быть обеспечена возможность выбора нескольких образовательных организаций или всех ОО определенного типа. Полный перечень типов организаций приводится в таблице13 приложения 2 к Контракту. При выборе образовательных организаций система должна обеспечивать фильтрацию по органам управления образованием и типам организаций. По умолчанию в качестве мест проведения должны использоваться географические координаты главных корпусов зданий ОО. В случае отсутствия данных, информация о названии и координатах мест проведения должна указываться организатором вручную. 1.2.1.1 Указание времени проведения этапа мероприятия. Должна быть обеспечена возможность применить указанное время ко всем местам проведения мероприятия или указать время индивидуально. 1.2.1.2 Ограничение числа участников (количество человек, количество подключений). - 1.3 Регистрация на этап (могут быть выбраны несколько опций в соответствии с таблицей 14 приложения 2 к Контракту). Далее следует обеспечить выбор одного из вариантов регистрации на этап: 1.3.1 Регистрация с использованием ЕПГУ (создание формы не является задачей Исполнителя, не предполагается получение в Систему данных с ЕПГУ) 1.3.1.1 Ссылка на форму ЕПГУ (должна указываться обязательно при выборе варианта 1.3.1) 1.3.2 Регистрация с использованием формы портала, поля формы приведены в таблице 15 приложения 2 к Контракту. Должна быть реализована возможность добавления организатором полей к регистрационной форме с указанием типа поля (числовое, строковое, дата, файл (с указанием допустимых типов файлов), а также обязательности полей. Должны быть реализованы возможности выбора полей для включения в форму, а также изменения требований к обязательности поля. В приведенной таблице указана информация об обязательности данных по умолчанию. Настроенная организатором форма регистрации предоставляется для записи участникам мероприятия (этапа мероприятия). При заполнении формы для регистрации на последующие этапы, поля, заполненные при регистрации на предыдущие этапы мероприятия уже должны быть заполнены. Для каждого поля при конфигурировании формы требуется указать права доступа для просмотра и изменения в соответствии с таблицей 16 приложения 2 к Контракту. 1.3.3 Автоматическая регистрация на этап участников, прошедших регистрацию на предыдущие этапы мероприятия. При выборе данного варианта, потенциальными участниками этапа становятся все, зарегистрировавшиеся на предыдущие этапы. Участие в этапе зависит от того, подтвердил ли участник свое участие и подтвердил ли участие координатор мероприятия. 1.3.3.1 Требуется подтверждение регистрации организатором (да, нет). 1.3.3.2 Требуется подтверждение регистрации участником (да, нет). - 1.4. Подача материалов для участия в этапе (да, нет). 1.4.1 Информация о необходимости предоставления материалов (инструкция) – HTML. 1.4.1.1 Материалы – таблица метаданных (структура формируется организатором), включая «Наименование материалов», «Тип файла» (фото, презентация, документ, видео), «Обязательны для предоставления» (Да/Нет). Должна быть обеспечена возможность настраивать права доступа к материалам в соответствии с таблицей 17 приложения 2 к Контракту. 1.5 Результаты участия (да, нет). 1.5.1 Результат или баллы, Достижение (из справочника: Не участвовал, Победитель, Призер, Участник. Значение по умолчанию «Участник»). Поле «Достижение» может редактировать только организатор (соорганизатор) этапа мероприятия. Результаты должны попадать в структуру регистрационной формы см. п. 1.3.2.1. - 2. Отчетность Для организаторов мероприятий в системе должна быть реализована отчетность, в том числе, по регистрации участников и результатам мероприятий. Система должна включать в себя следующие универсальные отчетные формы: 1) Отчеты о регистрации на мероприятия. Формы должны включать в себя информацию о мероприятии, его организаторах, этапах мероприятия, их организаторах, числе зарегистрированных участников в разрезе организаторов этапов (образовательных организаций, если этап проводится на базе образовательных организаций). Если мероприятие охватывает несколько муниципалитетов, должна быть реализована возможность сформировать отчет в разрезе органов управления образованием, являющихся учредителями образовательных организаций, а также классов (для внутришкольных мероприятий) и параллелей. Должны быть предусмотрены два вида отчетов по регистрации на мероприятия – сводные отчеты, содержащие информацию о числе зарегистрированных участников и персонализированные списки, содержащие информацию о зарегистрированных участниках в выбранных разрезах. 2) Отчеты о результатах мероприятий. Система должна включать в себя отчеты о результатах двух типов: – сводная отчетность: отчет должен включать в себя информацию о числе зарегистрированных на участие, число участников, результаты победителя и средний набранный балл; – персонализированные списки: организатор должен иметь возможность настроить выборку при формировании списков в части разрезов (включать информацию по муниципалитетам и ОО в отчет, а также выбрать конкретные ОО и муниципалитеты), а также в части фильтра для включения в списки (занятые места, критерии по достижению балла). - 3. Заявки на мероприятия. Раздел должен обеспечивать возможность для организаторов управлять заявками (просматривать, подтверждать, отказывать), вносить в Систему результаты мероприятий и т. д. Должна быть обеспечена возможность отбора (фильтрации) заявок по ОО, типам мероприятий, мероприятиям и этапам мероприятий, участникам, предметам (для олимпиад) и другим параметрам, предусмотренным в Системе. Должна быть реализована возможность внесения представителями образовательных организаций заявлений на участие в всероссийской олимпиаде школьников на основе бумажных заявлений родителей (законных представителей). Для заявки на мероприятия, имеющие тип «Всероссийская олимпиада школьников», должен быть использован справочник, содержащий, как минимум следующие предметы: Английский язык; Астрономия; Биология; География; Информатика (ИКТ); Искусство (Мировая художественная культура); История; Испанский язык; Итальянский язык; Китайский язык; Литература; Математика; Немецкий язык; Обществознание; Основы безопасности и жизнедеятельности; Право; Русский язык; Технология; Физика; Физическая культура; Французский язык; Химия; Экология; Экономика.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Общие требования к оказанию услуг - В рамках выполнения работ по развитию РИС СО Исполнителем должны использоваться ранее разработанные технические и программные решения РИС СО, а также технологическая основа исходных кодов функциональных модулей и сервисов. Технические решения, используемые на этапах проектирования и реализации РИС СО должны позволять минимизировать трудозатраты по развитию, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса, а также при подключении к Системе новых внешних информационных систем и ресурсов. Проектные решения должны обеспечивать возможность масштабирования РИС СО при увеличении нагрузки на Систему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности. Должны быть сохранены все эргономические, интерфейсные и архитектурные решения РИС СО, а новый функционал должен быть реализован путем дополнения, адаптации и развития имеющихся уже в РИС СО решений. В частности, для развития системы должен быть использован Конструктор (см. п. 1.11 Контракта «Решения по обеспечению гибкости Системы»), вновь создаваемые решения должны использовать имеющиеся решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации. Также исполнителем должен использоваться имеющийся стек технологий (см. п. 1.6 Контракта «Сведения о программном обеспечении, используемом в рамках Системы»). Все экранные формы Системы, инструкции по работе, вся документация на Систему должны быть выполнены на русском языке. В рамках оказания услуг выполняется доработка ранее созданных функций и создаются новые подсистемы. - - Значение характеристики не может изменяться участником закупки

Требования к доработкам функций Системы для реализации предоставления органами управления образованием администраций муниципальных и городских округов Ставропольского края, а также общеобразовательными организациями, расположенными на территории Ставропольского края, государственной услуги «Запись на участие в государственной итоговой аттестации по образовательным программам основного общего и среднего общего образования в форме единого государственного экзамена, основного государственного экзамена, государственного выпускного экзамена, итоговом сочинении (изложении), итоговом собеседовании по русскому языку» - В Системе в настоящее время реализованы следующие возможности: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для прохождения государственной итоговой аттестации в 9 классе (ГИА-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для прохождения государственной итоговой аттестации в 11 классе (ГИА-11); 3) подача выпускниками прошлых лет (ВПЛ) заявления для сдачи ЕГЭ; 4) подача обучающимся учреждений среднего профессионального образования (СПО) заявления для сдачи ЕГЭ. Данные возможности реализованы с использованием аутентификации и идентификации с помощью сервиса идентификации и аутентификации Систем интегрированного с ЕСИА и нормативно-справочной информацией Системы (в частности – с учетом реестра образовательных организаций и органов управления образованием). Исполнитель должен доработать Систему для реализации следующих функций: 1) подача обучающимися, осваивающими образовательные программы основного общего образования, заявления для участия в итоговом собеседовании в 9 классе (ИС-9); 2) подача обучающимися, осваивающими образовательные программы среднего общего образования, заявления для участия в итоговом сочинении в 11 классе (ИС-11); 3) подача ВПЛ заявления для участия в итоговом сочинении; 4) подача обучающимся СПО заявления для участия в ИС-11. Функции должны быть реализованы в соответствии с административным регламентом Заказчика, доступном по адресу: https://pravo.stavregion.ru/api/app/repo/law/01bee09f8f5e02a8e937380d02fde1e3.pdf Исполнитель должен разработать с использованием ВКУ формы на ЕПГУ, обеспечив их взаимодействие с Системой в соответствии с указанным выше административным регламентом Заказчика. Получение доступа к необходимым видам сведений, тестовой и продуктивной среде для выполнения работ обеспечивается Заказчиком. - - Значение характеристики не может изменяться участником закупки

Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО» - Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/53ee2be4-5c8c-408c-a593-3aefc22b1474 Реквизитный состав заявления указан на предоставление компенсации за оплату детского сада ребёнка участника СВО в Таблице 1 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО указан в Таблице 2 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 1 приложения 2 к Контракту. Пример заявления на предоставление компенсации за оплату детского сада ребёнка участника СВО и Пример ответа на заявление на предоставление компенсации за оплату детского сада ребёнка участника СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в Системе пользователями – сотрудниками муниципальных органов управления образованием с подтверждением финального статуса в системе сотрудниками дошкольных образовательных организаций (по аналогии с реализованной ранее в Системе услугой «Компенсацию родительской платы за детский сад» с использованием ранее созданных интерфейсов и процессов). - - Значение характеристики не может изменяться участником закупки

Требования к доработкам функций Системы для реализации предоставления государственных (муниципальных) услуг «Заявление на предоставление горячего питания в школе детей участников СВО» - Исполнитель должен обеспечить подключение Системы к виду сведений «Заявление на предоставление горячего питания в школе детей участников СВО». Доступ к виду сведений обеспечивает Заказчик. Описание вида сведений доступно по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/293be06d-7502-427e-812d-ca16ef1510d8 Реквизитный состав заявления на предоставление горячего питания в школе детей участников СВО указан в Таблице 3 приложения 2 к Контракту. Реквизитный состав ответа на заявление на предоставление горячего питания в школе детей участников СВО указан в Таблице 4 приложения 2 к Контракту. Схема вида сведений СМЭВ приведена на Схеме 2 приложения 2 к Контракту. Пример заявления на предоставление горячего питания в школе детей участников СВО и Пример ответа на предоставление горячего питания в школе детей участников СВО, приведены в приложении 2 к Контракту. Исполнитель должен обеспечить получение и обработку заявлений в действующей Системе пользователями – сотрудниками общеобразовательных организаций. - - Значение характеристики не может изменяться участником закупки

Перечень новых разрабатываемых подсистем - Подсистема «Региональный образовательный портал»; Подсистема «Аттестация педагогов»; Подсистема «Летний отдых»; Подсистема «Цифровой урок»; Подсистема «Мероприятия в образовании»; Аналитическая подсистема; Подсистема управления контентом. - - Значение характеристики не может изменяться участником закупки

Требования к функциям аналитической подсистемы - Подсистема должна обеспечивать создание и модернизацию связанных между собой отчетных форм, а также их размещение на портале и в интерфейсе других подсистем. Подсистема должна обеспечивать получение данных из различных источников для формирования отчета, визуализацию отчетов, их выгрузку в редактируемые форматы документов, электронных таблиц и в формат PDF. Доступ к данным – должно быть реализовано подключение ко всем БД, используемым в Системе, включая базы данных портала; – должны конфигурироваться: – роли пользователей; – разделы, на которые будут делиться отчеты при выводе конечному пользователю; – права доступа (кому доступен конструктор, кому и какие отчеты и в каком разрезе); – разрезы данных (какие есть разрезы и как определить, к какому разрезу отнести конкретного пользователя). Функции подсистемы - настройка отчетных форм; - редактирование шаблонов отчетных форм; - разграничение доступа к отчетам; - отображение отчетов. - - Участник закупки указывает в заявке все значения характеристики

Настройка отчетных форм (начало описания) Система отчетности должна формировать отчеты на основе конфигурации – отчетных форм. Отчетные формы должны создаваться на базе документа – шаблона, в котором описаны следующие элементы отчетной формы: – наименование отчета; – шапка отчета; – параметры, заполняемые пользователем перед выводом отображением отчета, с указанием обязательности их заполнения; – список таблиц (с указанием базы данных, если в проекте используется несколько подключений), на основании которых будут вычисляться данные; – описание полей и формул или алгоритмов для наполнения таблицы отчета данными. Отчетная форма должна подразумевать указание одного или несколько источников (баз) данных, списка параметров для формирования отчета и дополнительных обработок данных, реализующих алгоритмы преобразования данных при построении отчетных форм. При формировании отчетов должны использоваться внешние файлы шаблонов в форматах docx, xls и xlsx. При формировании отчетов, в отчетной форме должна быть реализована возможность указания, создаваемых на основании формируемого набора данных графиков и диаграмм. Система отчетности должна поддерживать возможности кэширования результатов выполнения отчетов, ограничение максимального времени ожидания формирования отчета и максимального времени жизни кэша отчета.

Настройка отчетных форм (окончание описания) Исполнителю необходимо реализовать функционал представления конфигурации отчёта в виде визуального графа, задающего логику построения отчёта от начальной точки, когда пользователь запросил данные, до момента выполнения последнего шага для каждого разреза с учётом выбранных пользователем параметров. Должен быть разработан визуальный редактор графа. Каждая из вершин графа должна описывать один из шагов при построении отчета, в частности – извлечение данных, трансформацию данных, расчеты по заданным формулам, объединение данных, подготовки на основе данных формы отчета, сохранение отчета и т.д. Конструктор отчетов должен включать в себя функционал настройки расписания, позволяющий указать время и периодичность формирования отчетов. Система должна автоматически формировать отчеты и сохранять их на сервере. В системе должна быть обеспечена визуальная настройка прав доступа пользователей к сгенерированным по расписанию отчетам. Необходимо реализовать механизм, который после запуска формирования отчета, сразу возвращает ответ от сервера с индикацией, что отчет формируется, в то время как пользователь может продолжать использовать систему. После завершения формирования отчета, система должна оповестить пользователя и предложить перейти к сформированному отчету. Исполнитель должен реализовать в конструкторе функционал, обеспечивающий связь между отчетами для реализации механизма Drilldown/Drillup. Необходимо реализовать механизм, обеспечивающий открытый доступ к отчету по уникальной ссылке, которая может быть выслана пользователю. При этом должна быть реализована настройка возможности экспорта отчета и изменения параметров. Должна быть предусмотрена возможность встраивания отчетов с использованием тегов iframe во внешние сайты.

Редактирование шаблонов отчетных форм Шаблоны отчетных форм должны составляться в формате Microsoft Office docx и xls и поддерживать возможность вывода итеративных структур данных, например таблиц. Отчетные формы должны храниться на сервере Системы. Наличие шаблонов отчетных форм не является обязательным для создание отчетных форм (простые отчеты могут формироваться на основании запросов, описанных в модуле Конструктор подсистемы Администрирования). Разграничение доступа к отчетам Каждая отчетная форма должна отображаться в личных кабинетах для одной или нескольких групп пользователей. Система отчетности должна поддерживать возможность скрыть отчет для всех пользователей. Должна быть реализована возможность изменения положения отчета в списке доступных пользователю отчетов, а также группировки отчетов по категориям. Отображение отчетов Аналитическая подсистема должна поддерживать возможности: – просмотр всех отчетов в Web-интерфейсе; – скачивания отчета в формате xls и docx; – просмотр или скачивание отчета в отрыве от остальных отчетов в любом личном кабинете Системы или в открытой части портала; – предоставление возможности поэтапного заполнения параметров с автоматическим получением фильтрованных списков для зависимых параметров; – просмотр графиков, указанных в отчетных формах, с дополнительной маркировкой отчетов, в которых присутствуют графики. Взаимодействия между частями подсистемы отчетности и другими подсистемами должно осуществляться посредством REST-API.

Требования к подсистеме управления контентом - Система управления порталом (CMS) должна обеспечивать: - доступ к размещенной информации без использования программного обеспечения, установка которого на технические средства пользователя информации требует заключения лицензионного или иного соглашения с правообладателем программного обеспечения, предусматривающего взимание с пользователя платы; - портал должен быть разработан с использованием средств разработки, относящимся к свободному программному обеспечению. - система управления сайтом (CMS), входящая в состав Системы должна обеспечивать возможность создания Заказчиком плагинов (расширений). - CMS должна обеспечивать возможность передачи пользователем прав на редактирование отдельных страниц (разделов) сайта для обеспечения наполнения информацией с участием нескольких пользователей; - CMS должна предусматривать механизм рецензирования, при котором пользователь может иметь право на создание и редактирование публикаций в определенном разделе, но при этом публикации сохраняются в статусе «черновик» и проверяются пользователем с правами публикации контента для общего доступа, который в случае корректности, обеспечивает публикацию страницы для всеобщего доступа. - CMS должна позволять осуществлять обсуждение публикаций пользователями, обеспечивать связь между публикациями - CMS должна обеспечивать работу с пользователями, которые имеют права «Редактор портала». - должны быть обеспечены возможности по публикации фото-галерей, а также по прикреплению файлов к публикации с их отображением (или без отображения); если отображение файлов не включено, то они могут быть доступны в виде прямых ссылок из текста публикации; - должны быть обеспечены возможности сквозного полнотекстового поиска по всем публикациям на портале с учетом прав доступа пользователей; - должна быть обеспечена поддержка SSL – шифрования HTTP – трафика (протокол HTTPS). SSL – сертификат предоставляется Заказчиком. - - Участник закупки указывает в заявке все значения характеристики

Подраздел «Публикация» (начало описания) – наименование; – тип публикации – выбор из справочника: публикация, новость, галерея; – событие – должен обеспечиваться выбор из списка событий, доступных для корневого раздела и подразделов (подсайтов), вышестоящих по отношению к публикации, а также находящихся с ней на одном уровне иерархии портала. При выборе события пользователем, публикация будет отображаться среди связанных с событием страниц; – алиас – должна быть возможность задавать алиас для доступа к публикации по адресу / ; – категория – в Системе для администратора портала должна быть обеспечена возможность ведения справочника категорий публикаций (например – родителям, учащимся, педагогам …). В CMS должен быть реализован отбор и выдача публикаций (статей) из разных разделов и разных сайтов, входящих в портал по категориям в хронологическом порядке; – статус версии – выбор из справочника: разрешена, не проверена, на доработку, запрещена. Модератор портала (сайта, раздела) должен иметь право менять статус и сопровождать изменение замечаниями для авторов публикации, не имеющих права публикации; – хост – адрес сайта по которому открывается данный раздел и его подразделы, как отдельный интернет-ресурс; – ключевые слова (теги) публикации – выбор из автоформируемого публичного списка тегов. Если нужных слов нет в списке, должна быть реализована возможность внести ключевое слово в ручную, затем оно будет автоматически доступно в списке; – шаблон – шаблон страницы (раздела), должна быть обеспечена поддержка шаблонов в формате twig (https://twig.symfony.com/); – шаблон для подчиненных публикаций – должен быть реализован шаблон для подчиненных страниц (разделов), должна быть обеспечена поддержка шаблонов в формате twig;

Подраздел «Публикация» (окончание описания) – дата публикации – должна генерироваться автоматически, должна быть реализована возможность изменения для пользователей, имеющих административные привилегии; – вес – должен определять вес публикации в текущем контексте; – закрыт – публикация/раздел недоступна никому, кроме автора; – скрытый – отсутствует в меню, раздел доступен только по прямой ссылке, алиасу или адресу сайта; – показывать медиа – должны показываться прикрепленные медиа-файлы; – показывать файлы – при включении данной опции портал должен показывать файлы, прикрепленные к публикации. Если опция не включена, файл не отображается, но может быть доступен по ссылке из WEB-контента публикации; – не подлежит удалению – страница (раздел) не должна быть никем удалена, пока не будет отключена опция; – корневая – страница является «разделом», включается в навигационные структуры (меню); – репост в соц.сети – к странице добавляются функции репоста контента в социальные сети; – плагин – в случае включения должна быть обеспечена возможность указать название плагина: код в результате работы которого генерируется контент, выводимый на портал; – разрешить комментарии – в случае включения должны быть доступны две дополнительные опции: разрешить анонимные комментарии (разрешить комментарии неавторизованным пользователям), запретить добавлять комментарии (ранее добавленные комментарии должны быть видны, но новые добавить нельзя). Комментарии должны отображаться в соответствии с предусмотренным в шаблоне дизайном.

Подраздел «Содержание» – web-редактор с панелью инструментов для редактирования текста, включающим опции реализованные в виде пиктограмм: – стиль шрифта: жирный, наклонный, зачеркнутый и подчеркнутый; – выравнивание абзаца: по левому краю, правому краю, по центру и по ширине листа; – выделение текста цветом; – работа с буфером обмена: копировать, вырезать, вставить, вставить как текст, вставить из Word; – поиск; – замена; – вернуть операцию; – повторить операцию; – очистить стиль; – редактор HTML – кода; – предварительный просмотр; – печать; – стиль – картинка слева, картинка справа; – абзац – Заголовок 1, Заголовок 2, ...; – шрифт – выбор типа шрифта; – размер – выбор размера шрифта; – маркированный список; – нумерованный список; – добавить/изменить якорь; – добавить/изменить изображение: должно быть обеспечено размещение изображений пользователем в внутренней коллекции изображений и работа с коллекцией – удаление и скачивание изображений из коллекции; – верхний индекс; – нижний индекс; – добавить/изменить клип: должно быть обеспечено размещение видеоклипов пользователем в внутренней коллекции и работа с коллекцией – удаление и скачивание видео из коллекции; – добавить/изменить таблицу (и другие операции с таблицей); – изменить CSS-стиль. – сохранить – нажатие кнопки должно приводить к записи изменений; – отменить.

Подраздел «Файлы» В разделе должна быть реализована возможность загрузки файлов, которые могут быть показаны вместе с публикацией в сопровождении пиктограмм (pdf, Word и тп). Должны быть доступны следующие операции: – открыть – выбрать один или несколько файлов для загрузки; – загрузить – загрузить на сервер выбранные, но еще не загруженные файлы; – отменить – отменить выбор файлов для загрузки; – удалить – удалить один или несколько выбранных файлов. Для каждого файла должно быть доступно скачивание. При указании соответствующей опции для публикации, файлы должны отображаться на портале вместе с контентом публикации. Подраздел «Права» В разделе должна быть реализована возможность выбора пользователя из числа зарегистрированных на портале. В системе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». При выборе пользователей должен быть обеспечен поиск по фамилии, имени, отчеству, учетной записи, СНИЛС. При добавлении пользователя должны быть указаны права пользователя в отношении раздела (страницы): «Администратор» – все права на раздел и подразделы, «Только чтение» – просмотр страниц, «События полный» – управление событиями, «Редактор без права изменения статуса» – создание страниц без права изменения статуса публикаций. «Администратор» должен иметь возможность предоставить другим пользователям права для редактирования страниц и разделов внутри раздела, к которому ему предоставлен доступ. Подраздел «Ссылки» Должен обеспечивать возможность связать публикации (разделы) между собой для представления связанного контента на портале (должно быть предусмотрено в шаблонах). Должна быть предусмотрена операция «Добавить», позволяющая выбрать один или несколько разделов, связанных с публикацией.

Раздел главного меню «Пользователи» В разделе пользователь, являющийся администратором портала может управлять правами других пользователей. В разделе должны отображаться пользователи, имеющие роль «Сотрудник организации» с правами «Редактор портала». Пользователи должны получать роли, такие же, как приведены выше в описание подраздела «Права». Эти роли должны распространяться на весь портал. Раздел главного меню «События» Должно быть обеспечено дополнение событий, их изменение и удаление. Информация о событии должна включать в себя: – наименование события; – краткое описание события; – изображение (баннер) события; – дата начала события; – дата завершения события; – вес – используется для определения порядка отображения событий; – разрешить комментарии – обеспечивается добавление и показ комментариев; – разрешить анонимные комментарии – комментарии могут добавлять неавторизованные пользователи; – запретить добавлять комментарии – комментарии по-прежнему показываются, но добавление новых комментариев заблокировано. Раздел главного меню «Обратная связь» Должен содержать список сообщений, направленных через сервис обратной связи, который должен быть реализован для разделов организаций на портале (например — лагерей детского отдыха, ОО и других). Сервис обратной связи должен обеспечивать отправление обращения на официальный e-mail организации и одновременную его запись в базу данных портала. Информация о сообщении должна включать в себя: код организации-получателя, имя отправителя, email, текст сообщения.

Требования к подсистеме «Региональный образовательный портал» - В подсистеме должны быть предусмотрены возможности доступа к единой базе данных документов образовательных организаций и управлений образования, включая функции поиска необходимых документов. Поисковая форма по единой базе данных документов должна включать в себя, как минимум, следующие поля: - уровень документа (федеральный, региональный, муниципальный, уровень ОО); - тип документа (Приказ, Устав, Результаты самообследования и т. д.); - категория документа (тематика: ЕГЭ, ОГЭ, ГВЭ, Информатизация, Одаренные дети, …); - номер документа; - ключевые слова (поиск по названию и аннотации документа); - наименование организации (подстрока, часть наименования); - дата начала – дата завершения (диапазон дат, в которые должна попадать дата документа). При авторизации, на региональном образовательном портале, педагогического работника, пользователю должна быть доступна функция ведения персонального сайта. Пользователи публичной части регионального образовательного портала должны иметь возможность перехода к просмотру контента сайтов учителей c использованием карточки любой ОО, из подраздела «Руководство. Педагогический (научно-педагогический) состав». На портале должен быть реализован механизм общественной оценки, позволяющий любому авторизованному через ЕСИА пользователю оставить отзыв о работе каждого педагога. - - Участник закупки указывает в заявке все значения характеристики

Структура открытой части портала представлена на Рисунке 1 приложения 2 к Контракту. Исполнитель должен согласовать с Заказчиком в ходе выполнения работ проект дизайна портала и карточек ОО, размещаемых на портале. После направления на согласование проекта дизайна, Заказчик должен дать ответ-согласование или замечания в течении 2 рабочих дней. После устранения замечаний, Исполнитель должен направить проект дизайна вторично. Проект дизайна направляется в формате графических файлов — jpg, pdf или png. Структура титульной страницы портала: Блок 1. Вызов главного меню портала. В главном меню должны быть реализованы следующие разделы: 1. Система образования. Раздел должен открывать форму поиска по образовательным организациям региона. Блок 2. Лого и наименование портала (должны быть предоставлены Заказчиком). Блок 3. Поиск – открывается строка и обеспечивается поиск по всем общедоступным публикациям на портале (не должен включать поиск по базе документов и карточкам организаций). Блок 4. «Вход в единый личный кабинет». Для входа в личный кабинет могут быть использованы следующие типы учетных записей: 1) администратор системы; 2) координаторы всех уровней (см. п. 1.10. Контракта «Решения по идентификации и аутентификации пользователей и единой нормативно-справочной информации»; 3) подтвержденные учетные записи ЕПГУ (педагоги, учащиеся, руководители). В едином личном кабинете пользователь должен иметь возможность получить доступ ко всем функциональным подсистемам к которым ему предоставлены права доступа.

Блок 5. Должен содержать ленту событий. Слайдер событий должен представлять собой события, включающие изображение и текст (описание). Если слайдер включает более одного выводимого события, то они должны меняться (пролистываться) автоматически. Под слайдером должен находиться переключатель на одно из открытых для вывода событий. Если щелкнуть по событию, должна открываться страница события, где выводится изображение, подробное описание события и связанные с ним публикации – при внесении публикации может быть указана его связь с событием (см. описание подсистемы управления порталом). События и изображения для обработки и вывода на портал, как и другой начальный контент для заполнения главной страницы портала, предоставляется Заказчиком. Блок 6. Новости. Должны выводиться три последние новости из ленты новостей портала. Должна быть предусмотрена кнопка (ссылка) «Все новости», для открытия ленты новостей портала с возможностью их фильтрации по календарю (должна быть возможность указать диапазон дат).

Блок 7. Карта системы образования. Должна быть реализована возможность выбрать типы отображаемых организаций (учреждений): 1. Организации и учреждения. 1.1 Детские сады. 1.2 Школы. 1.3 Школы-интернаты. 1.4 Учреждения дополнительного образования. 1.5 Учреждения профессионального образования. 1.6 Органы управления образованием. 1.7 Иные организации. При щелчке по значку организации (учреждения) на карте, должна открываться ее карточка, с которой можно перейти и на официальный сайт организации (он может быть организован как на портале, так и на внешних ресурсах, например — ГосВеб). В блоке должна быть доступна ссылка «Система образования». В этом разделе должен открываться список организаций и органов управления образованием со следующими полями: - АТЕ – наименование муниципалитета; - наименование – наименование организации/органа управления образованием; - руководитель – ФИО руководителя; - e-mail – адрес электронной почты; - юридический адрес; - телефон(ы). При щелчке по наименованию, которое должно являться ссылкой, на новой закладке должна открываться карточка организации. Должна быть предусмотрена выгрузка реестра в формате электронной таблицы (файл в формате xls). Помимо полей, приведенных выше в выгрузку должно быть добавлено поле «Должность руководителя». Для списка организаций должен быть предусмотрен фильтр, включающий в себя: - выбор муниципалитета; - фрагмент наименования; - выбор одного или нескольких типов организаций: - детские сады; - школы; - школы-интернаты; - профессиональное образование; - дополнительное образование; - управления образования; - иные организации.

Блок 9. Мероприятия в образовании (окнчание описания). В разделе должна быть доступна возможность записи на мероприятия. Для мероприятий Исполнитель должен разработать структуру карточки и реализовать ее с использованием Конструктора. Карточка должна включать наименование, тип мероприятия, фотогалерею (просмотр приложенных фотографий), описание мероприятия, ссылки на сайты, а также дополнительные сведения, например – структуру мероприятия и его этапы, информацию о местах проведения, опции информационного сопровождения мероприятия и т.п. Для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например . . .

Подсистема «Региональный образовательный портал» должна обеспечивать публичный интерфейс для доступа к общей информации о системе образования, карточкам всех образовательных организациях региона в одном месте с переходом к сайту образовательной организации. Доступ к компонентам подсистемы находящимся вне публичного контура должен быть доступен только после прохождения процедуры авторизации средствами ЕСИА или с помощью учетной записи координатора. Подсистема «Региональный образовательный портал» должна использоваться как единая точка входа во все подсистемы для работников ОО, обучающихся и родителей (законных представителей), для предоставления услуг в сфере образования в электронном виде. Для этих целей она должна быть интегрирована с единым личным кабинетом Системы, созданным ранее. Функционал подсистемы должен обеспечивать возможность ведения разделов портала, используя подсистему управления контентом.

Блок 8. Наши показатели. В прямоугольных или иных блоках должны быть выведены показатели, рассчитанные на основе эксплуатации системы, например: число обучающихся в ОО, Заявлений ГИА – число заявлений, поданных на ГИА в электронном виде и т. п. Должна быть предусмотрена кнопка «Дашбоард», при нажатии на которую должна открываться аналитика по работе ОО с системой и предоставлению услуг в электронном виде. В частности должен быть обеспечен вывод раздела «Заполнение открытых данных», включающий три графических отчета: 1. гистограмма по муниципалитетам, показывающая процент ОО, сформировавших «Открытые данные» более, чем на 80 %; 2. при выборе муниципалитета, должна выводиться гистограмма по школам (процент заполнения) и дополнительные данные. Должна выводиться информации о внесении координат зданий, адрес сайта, информация о доступности сайта, дата последней загрузки документов в «Открытые данные». 3. при выборе школы – гистограмма о степени заполнении разделов «Открытых данных»: - основные сведения; - структура и органы управления ОО; - документы; - образование; - образовательные стандарты; - руководство. Педагогический состав; - материально-техническое обеспечение и оснащенность образовательного процесса; - стипендии и иные виды материальной поддержки; - платные образовательные услуги; - финансово-хозяйственная деятельность; - вакантные места для приема (перевода). Формирование открытых данных в Системе уже реализовано ранее. Данные отчеты и дашбоард должны строиться на основе наполнения базы данных.

Блок 9. Мероприятия в образовании (начало описания). В разделе «Мероприятия в образовании» на главной странице должны размещаться последние мероприятия с возможностью фильтрации по уровням событий и другим их свойствам, муниципалитетам, направленности, типам образовательных организаций, конкретным образовательным организациям, а также строка, обеспечивающая интеллектуальный полнотекстовый поиск по мероприятиям. Должны показываться карточки трех (шести, девяти и т.п.) последних мероприятий, либо карточки мероприятий, настроенных для выдачи на главной странице модератором системы. Число выводимых по умолчанию мероприятий должно настраиваться модератором. В блоке мероприятий должны быть реализованы возможности: – перехода к полной картотеке мероприятия; – перехода в фильтру мероприятий, полнотекстовый поиск по мероприятиям, переход к карте мероприятий, где мероприятия показаны в привязке к месту проведения (по умолчанию место проведения мероприятия должно совпадать с главным зданием организации, но при планировании мероприятий в личном кабинете организации и при визуализации на портале должно быть предусмотрено проведение многоэтапных и составных мероприятий, для которых места проведения могут быть различными, в частности – школьный этап всероссийской олимпиады школьников проводится во всех общеобразовательных организациях, муниципальный и региональный – в специально определенных местах. Кроме того, Исполнитель должен учитывать, что кроме этапа место проведение зависит от части составного события, например – областной этап олимпиады по физике может проводиться в одном месте, а по биологии – в другом месте и в другое время).

Требования к подсистеме «Аттестация педагогов» - Подсистема должна обеспечивать формирование объективного портфолио педагога, подачу электронного заявления на аттестацию с использованием ЕСИА и форм ЕПГУ, экспертизу аттестационных документов и проведение онлайн-заседаний аттестационной комиссии. Личные кабинеты должны быть созданы на базе регионального образовательного портала и интерфейса для работы с данными. Основные функции в личных кабинетах представлены в виде раскрываемых блоков, каждый блок в конечном итоге открывается в виде интерфейса для работы с данными или форм и отчетов, являющихся плагинами портала, реализующими конкретный пользовательский функционал. - - Участник закупки указывает в заявке все значения характеристики

Раздел Личный кабинет организации. Личный кабинет любой организации доступен под учетной записью координатора организации. Кроме этого, координатор может внести СНИЛС пользователей, получающих возможность действовать от имени организации, войдя в Систему с использованием ЕСИА, а также указать роль пользователя. Если пользователь прописан в нескольких организациях, то после входа в личный кабинет, у него появляется возможность выбора организации, от которой он действует. Пользователь может работать в личном кабинете от одной конкретной организации («текущая организация»), сменить ее.

Раздел Аттестация педагогических работников (начало описания): Аттестация педагогических работников для получения первой и высшей категории проводится региональной аттестационной комиссией, формируемой в соответствии с приказом регионального органа исполнительной власти, осуществляющего функции управления в сфере образования. Для подачи заявлений на аттестацию и получение информации о ходе его рассмотрения и результатах Исполнитель должен использовать вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Аттестация педагогических работников образовательных организаций, находящихся в ведении субъекта Российской Федерации, муниципальных и частных организаций» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e6d19-ff80-11eb-ba23-33408f10c8dc/versions/2dc85429-8816-4f03-bf27-a617daa885e3?area=PROD). Администратор системы должен иметь возможность добавить одну или несколько организаций в качестве «Оператора аттестации педагогических работников» (организация-оператор). Администратор такой организации, добавив пользователей в систему, тем самым предоставляет им возможность доступа к разделу «Аттестация педагогических работников» Системы в качестве координатора.

Раздел Аттестация педагогических работников (продолжение описания): В разделе «Аттестация педагогических работников» организации-оператора должен быть доступен раздел «Справочники». В этом разделе должна быть реализована возможность формирования дополнительных справочников, необходимых для обеспечения процесса аттестации педагогических работников: – категории работников образования, проходящих аттестацию (например, воспитатели ДОО, учителя начальных классов, учителя – предметники, мастера производственного обучения). Обеспечена возможность указать «предметную специализацию», которая может включать один или несколько предметов; – критерии аттестации – набор критериев, по которым вносится информация экспертами. Для каждого критерия реализована возможность указать минимально допустимое значение, категории работников образования к которым применим критерий, а также критерий, частью которого (подкритерием) является данный критерий. При обработке данных система автоматически суммирует показатели критериев нижнего уровня для расчета значения критериев первого уровня. Внесение информации вручную экспертами реализовано для критериев, у которых отсутствуют подчиненные критерии (подкритерии); – реестр экспертов – включает в себя данные об эксперте, включая ФИО, место работы, email, телефон, а также перечень лет участия в оценке, перечень категорий работников образования, в экспертизе аттестационных дел которых может принимать участие эксперт, а также предметов (если категория предполагает предметную специализацию). В реестре обязательно указан СНИЛС. Система по нему предоставляет доступ пользователю-эксперту к необходимым функциям в личном кабинете (сличать СНИЛС из базы данных и полученный при авторизации с использованием ЕСИА); – график заседаний комиссии – указывается дата и время проведения заседания.

Раздел Аттестация педагогических работников (окончание описания): На заседании комиссии могут рассматриваются все заявления, прошедшие к этому времени экспертизу (см. раздел «Заседания комиссии»). Если заседание комиссии уже состоялось, изменение записи в графике блокируется. График заседаний доступен с просмотром по годам.

Раздел «Экспертиза» Раздел «Экспертиза» должен быть включен в раздел «Аттестация педагогических работников». В разделе «Экспертиза» разделе доступны функции (начало описания): – просмотр всех поступивших в течении выбранного календарного года заявлений и их статуса (возможность фильтрации заявлений по статусу, муниципалитету, образовательной организации, категории работников образования и предмету (если категория предусматривает указание предметов), а также по результатам экспертизы; – техническая проверка заявлений проводится сотрудниками организации – оператора аттестации педагогических работников; в случае обнаружения технических недостатков в поданном заявлении (пакете документов), заявление может быть возвращено заявителю с заключением о найденных технических ошибках; если заявление прошло проверку, соответствующий статус возвращен на ЕПГУ (если заявление подавалось с использованием формы на ЕПГУ) и в ЛК заявителя в Системе; заявления для технической проверки выводятся в последовательности поступления;

В разделе «Экспертиза» разделе доступны функции (окончание описания): – автоматизированное распределение заявлений на экспертизу обеспечивает распределение заявлений, прошедших техническую проверку, на экспертизу, в соответствии со специализацией экспертов; сначала на проверку выдаются случайным образом заявления из числа прошедших первую проверку или наиболее ранних заявлений, еще не прошедших экспертизу; эксперты в личном кабинете указывают доступные им для проверки категории заявлений и нажать кнопку «Получить заявление на экспертизу»; в личных кабинетах сотрудников организации-оператора отображается статистика о числе заявлений, прошедших экспертизу в разрезе числа дней, прошедших со времени подачи (более 60, от 40 до 60, от 20 до 40, от 0 до 20) и категорий заявлений, а также число заявлений, готовых к рассмотрению на заседании комиссии и число дней, оставшихся до даты проведения комиссии; если используется режим проверки двумя экспертами отображаются сведения о числе полностью прошедших экспертизу заявлениях; – анализ работы экспертов по категориям заявителей выводятся сведения о состоянии поступления и экспертизы заявлений, а также информация о числе экспертов, а при выборе категорий – перечень экспертов с указанием числа сформированных экспертных заключений; при выборе эксперта: – переключение режима экспертизы (проверка одним экспертом, проверка двумя экспертами), указание процента расхождения в оценках экспертов при превышении которого заявление отправляется третьему эксперту (только для случая проверки двумя экспертами); в случае если заявление проверено тремя экспертами – берутся результаты двух наиболее близких по сумме баллов экспертов и оценки по каждому критерию находятся как средние между двумя выбранными результатами и округляются.

Раздел «Заседания комиссии»: возможность выбора заседания из числа ранее созданных, а также добавления нового заседания. для еще не состоявшегося заседания должны обеспечиваться следующие возможности: – назначение заявлений из числа прошедших экспертизу (могут выбираться категории заявителей и число заявлений), реализована возможность индивидуального выбора заявлений для рассмотрения комиссией; – приглашение на заседание комиссии экспертов (могут выбираться категории экспертов и их число), реализована возможность индивидуального приглашения экспертов на заседание комиссии; – выбор формата проведения заседания – онлайн. При проведении заседания все члены комиссии должны автоматически приглашаться на заседание через систему сообщений и по электронной почте. Для онлайн-заседаний у всех участников в личном кабинете должен появляться доступ в тестовую комнату для тестирования связи. При проведении заседания комиссии в Системе должна быть обеспечена возможность голосования, в личном кабинете каждого участника выводятся вопросы для голосования и с использованием простой электронной подписи все участники имеют возможность проголосовать. – установка статуса заседания (запланировано, подготовка, проведение, завершено); – прикрепление протокола заседания комиссии – отсканированный итоговый протокол заседания комиссии в формате png, jpg, pdf и/или протокол в формате odt; имеется возможность прикрепить файлы после завершения заседания. При проведении онлайн-заседаний пользователи должны иметь возможность использовать web-камеры (видеосвязь), микрофоны (аудиоконференция), общую доску для презентаций и совместной работы, а также чат.

Раздел «Мои заявления»: Раздел «Мои заявления» служит для подачи заявлений и получения по ним обратной связи любым пользователем Системы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала Госуслуг. Внутри раздела должны быть предусмотрены подразделы, оформленные в виде пиктограмм, функционал которых описан далее. При выборе раздела должна отображаться ссылка «Информация об аттестации педагогов», которая ведет на раздел «Аттестация педагогических работников» портала, где в открытом доступе размещаются документы, посвященные аттестации педагогических работников региона, а также информация о числе поданных заявлений по категориям работников системы образования и числе работников, прошедших аттестацию. Далее должна выводиться для педагога информация о его категории, дате прохождения последней аттестации и рекомендация пройти аттестацию в указанный период времени. Ниже должна размещаться кнопка подачи заявления на аттестацию на ЕПГУ и кнопка подачи заявления на аттестацию на региональном портале (через Систему). Вне зависимости от способа подачи заявления, все поданные заявления должны отображаться в личном кабинете Системы, а также должен показываться статус заявления и после появления – экспертное заключение и результаты аттестации.

Раздел «Сообщения»: Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». При этом в красном круге поверх пиктограммы «Сообщения» пользователь должен видеть число пришедших и не просмотренных еще сообщений. К сообщениям должны приводить все события, происходящие с заявлениями. Сообщения должны включать прямые ссылки для перехода к формам, страницам, документам и т. п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя.

Требования к функциям интеграции с ЕПГУ. Использование СМЭВ3 для интеграции с формами на ЕПГУ. Исполнитель должен реализовать приведенную ниже схему интеграции с помощью специально разработанного модуля, работающего с универсальным видом сведений и обеспечивающего гибкую настройку (изменение параметров) со стороны Заказчика без изменения исходных кодов программного обеспечения. Схема взаимодействия с СМЭВ3 приведена на рисунке 2 приложения 2 к Контракту. 1. СМЭВ3 – федеральная система (ЕПГУ), взаимодействует с внешними системами по протоколу SOAP. 2. Сервис взаимодействия со СМЭВ3 – промежуточная система, Spring Boot приложение (или иное приложение, разработанного на базе свободного программного обеспечения). Упрощает взаимодействие со СМЭВ и выполняет общие операции: выполнение операций для отправки и получения сообщений от СМЭВ (периодический опрос, подтверждение, отправка и получение сообщений); преобразование SOAP-сообщений и перенаправление их в локальную очередь; журналирование – сохранение оригинальных запросов от СМЭВ. 3. Сервис криптографии – обеспечивает подпись запросов по формату СМЭВ и ГОСТ (может быть использован СриптоПро JCP или иное решение). 4. Брокер сообщений (например, на базе ActiveMQ; Исполнителем может быть использовано иное открытое решение) – работа с очередями, хранение необработанных сообщений. 5. Клиенты – приложения или сервисы Системы, которым необходимо взаимодействовать со СМЭВ. Синхронное взаимодействие реализовано по протоколу HTTP, асинхронное – с использованием протокола JMS.

Требования к подсистеме «Летний отдых» - Подсистема «Летний отдых» должна обеспечивать ведение регионального реестра мест летнего отдыха и оздоровления, ведение страниц мест отдыха и оздоровления детей, формирование информации о сменах и группах, внесение лимитов, обеспечение подачи заявлений с учетом муниципальных лимитов на путевки с полной или частичной компенсацией стоимости, автоматизация процесса рассмотрения и подтверждения путевок с учетом региональных особенностей а также возможность настройки безналичной оплаты (интернет-эквайринг), обеспечивать поддержку детского туристического кэшбека (при его наличии) с использованием национальной платежной системы (карты «Мир»), а также формирование базы данных фактов отдыха (для компенсации с использованием заявлений на ЕПГУ). Подсистема должна обеспечивать размещение на региональном образовательном портале информации о местах отдыха и оздоровления в виде картотеки с возможностью ведения сайтов мест детского отдыха и оздоровления, а также размещение мест детского отдыха и оздоровления на карте региона. - - Участник закупки указывает в заявке все значения характеристики

Подсистема «Летний отдых» должна включать в себя раздел на региональном образовательном портале и систему личных кабинетов для следующих категорий пользователей: 1. Представитель организации. 2. Родитель/законный представитель. 3. Администратор. Раздел на Портале должен, как минимум, включать в себя: – возможность осуществления входа в личные кабинеты представителя организации, родителя/законного представителя, администратора; – сокращенный перечень организаций с возможностью перехода к странице с полным перечнем. По щелчку на конкретную организацию должна открываться страница с ее подробным описанием. Авторизация родителей/законных представителей должна осуществляться посредством ЕСИА. Доступ к подсистеме должен быть предоставлен организациям, для которых администратором системы настроен доступ к ведению информации для мест детского отдыха и оздоровления. Представители организаций, получают возможность настраивать профиль организации, в качестве места детского отдыха и оздоровления. Основная информация об организациях, на базе которых создаются места отдыха и оздоровления детей, включает в себя сведения, перечисленные в таблице 5, приложения 2 к Контракту. Дополнительная информация о местах детского отдыха и оздоровления включает в себя сведения, перечисленные в таблице 6, приложения 2 к Контракту. Сведения о зданиях организации перечисленные в таблице 7, приложения 2 к Контракту.

Для ведения очереди заявлений (забронированных мест), полученных на предоставление услуги детского отдыха и оздоровления, в личном кабинете организации должен быть доступен раздел «Работа с заявлениями». В этом разделе должна быть реализована работа со справочниками (внесение информации о сменах, числе мест и возрастных категориях детей, а также местах размещения в привязке к месту детского отдыха и оздоровления и зданию, в котором будет размещен ребенок по путевке). Сотрудник организации, имеющей места отдыха и оздоровления детей в каникулярное время, должен иметь возможность подтверждения электронных заявлений и выдачи путевок, внесения заявлений, получаемых в бумажном виде, внесение заявлений на отказ от путевок, а также возможность запроса по электронным заявлениям граждан дополнительной информации, выставления счетов на полную или частичную оплату услуг, а также оплаты по карте с использованием интернет-эквайринга. В системе должна быть предусмотрена возможность подключения интернет-эквайринга, но сама настройка для зачисления платежей на счета конкретных организаций контрактом не предусмотрена. Система обеспечивает выставление счета на полную или частичную оплату услуг детского отдыха и оздоровления в каникулярное время в личном кабинете заявителя. Для интеграции с платежными системами в Системе должен быть реализован простой API, который на основании номера счета, имени и даты рождения ребенка возвращает в ответ внешней системе назначение платежа и сумму платежа.

Исполнитель должен реализовывает интеграцию с порталом гос.услуг для получения в систему заявлений с портала с использованием вида сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время», доступного по адресу https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD. Сама форма расположена по адресу https://www.gosuslugi.ru/600173/1/form и предназначена для подачи заявлений для граждан имеющих право на бесплатную путевку для получения детского отдыха и оздоровления. Результатом оказания услуги является решение о постановке в очередь на получение путевки в электронном виде. Другие категории граждан должны иметь возможность подать заявление с использованием Системы. Исполнитель также должен обеспечивать по полученным с ЕПГУ заявлениям передачу результатов их рассмотрения на ЕПГУ, а также передать сообщение о возможности дальнейшего взаимодействия в цифровом формате в Системе. Раздел «Мои заявления» должен служить для подачи заявлений и получения по ним обратной связи любым пользователем подсистемы, прошедшим аутентификацию с использованием подтвержденной учетной записи портала гос.услуг.

Подсистема при выборе раздела должна предлагать воспользоваться поиском и выбором места отдыха «Перейти к поиску и выбору мест отдыха и оздоровления». После того, как пользователь нашел место для отдыха и открыл его карточку, он должен иметь возможность выбрать время отдыха (смену), либо наоборот, пользователь указывает для поиска время отдыха и выбирает подходящее место. В случае, если открыто бронирование, родитель выбирает «Подать заявку». В этом случае, выведено два варианта: 1) заявление на бесплатную путевку в электронном виде на портале гос.услуг (при этом родителю даны пояснения, какие категории граждан имеют право на бесплатный отдых и оздоровление детей на территории субъекта Российской Федерации); для подачи заявлений на бесплатный детский отдых и оздоровление используется вид сведений «Прием заявлений с ЕПГУ по форме «ПГС_Организация отдыха детей в каникулярное время» (https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/636e945a-ff80-11eb-ba23-33408f10c8dc/versions/4d198ba8-9815-4dab-b06b-2807f38ce930?area=PROD); 2) заявления на путевку с полной или частичной оплатой (в этом случае должна открываться форма заявления в личном кабинете).

Запросы дополнительной информации и уточнения от организации детского отдыха также должны поступать родителям (законным представителям) через личный кабинет. Если бронь одобрена, должен быть выставлен электронный счет, квитанцию об оплате которого (или иное подтверждение) необходимо загрузить в личный кабинет в течении 15 дней. После подтверждения получения оплаты на счет организации, в личном кабинете генерируется электронная путевка, содержащая: 1) QR – код с адресом страницы лагеря; 2) название организации; 3) данные ребенка (ФИО, дата рождения); 4) день заезда (начала смены); 5) день выезда (конца смены).

Состав электронной формы подачи заявления в места детского отдыха и оздоровления с использованием системы: 1. Смена (из справочника). 2. Подтверждение ознакомления с: – условиями пребывания в выбранном лагере (документ – ссылка); – правилами внутреннего распорядка в лагере (документ – ссылка); – правила использования мобильных телефонов в лагере (документ – ссылка). 3. Количество путёвок (возможность подачи заявок на 1 и более ребенка). 4. Заявитель дает согласие: – на обработку персональных данных заявителя и ребенка (детей); – на медицинское вмешательство; – на виды активностей (в т.ч. фото и видеосъемку) ребенка в лагере. ФИО заявителя (данные должны совпадать с данными, указанными в заявке и подтверждающих документах): - Дата рождения; - Контактный телефон (1 и более); - Электронная почта; - Адрес регистрации; - Адрес проживания; - Серия, номер паспорта; Подтвержденный статус семьи (отметить): – многодетная; – малоимущая; – неполная. Ребенок: - Фамилия; - Имя; - Отчество; - Свидетельство о рождении ребенка (серия и номер); - Дата рождения; - Пол (М/Ж); - Тип школы (из справочника: начальная (дошкольник), средняя, основная, лицей, гимназия, коррекционная (специальная), с углубленным изучением отдельных предметов; - Муниципалитет, школа (выбор из справочников); - Класс, буква (заполнить); - Подтвержденный статус ребенка (отметить); Состоит ли на различных видах профилактического учета: – ОВЗ; – инвалидность; – другие особенности (указать при наличии). Категория для оформления путевки (из справочника): – полуоплатная; – трудная жизненная ситуация (малоимущая семья, опека инвалид ОВЗ, сирота); – работающая (указать место работы на территории региона, прикрепить справку с места работы); – участник профильной смены. Скан свидетельства о рождении ребенка (прикрепить) Документ, подтверждающий льготную категорию (при наличии, может быть несколько).

Должна быть доступна система сообщений, размещенная в личном кабинете в разделе «Сообщения». Должно отображаться число пришедших и не просмотренных еще сообщений. К сообщениям приводят все события, происходящие с заявлениями, а также события в местах детского отдыха, в которых пользователь (его дети) получают услуги. Сообщения по возможности должны включать прямые ссылки для перехода к формам, страницам, документам и т.п., связанным с событием сообщения. В настройке профиля пользователя должна быть реализована возможность дублировать сообщения из личного кабинета Системы на электронную почту пользователя. Для интеграции с формами на ЕПГУ должны быть использованы механизмы, описанные в разделе «Подсистема «Аттестация педагогических кадров». Состав полей и структуры данных подсистемы «Летний отдых», могут быть изменены в ходе выполнения работ по согласованию с Заказчиком.

Требования к подсистеме «Цифровой урок» - 4) Структура урока должна состоять из этапов. При редактировании урока должна быть реализована возможность указания следующих свойств этапов: 4.1) наименование этапа; 4.2) тип этапа (как минимум должны быть реализованы следующие типы этапов: «Текст», «Презентация», «Тест – выбор одного ответа», «Тест – выбор нескольких ответов», «Тест – ввод числа», «Тест – ввод строки», «Задание – загрузка файлов», «Просмотр файла», «Совместное редактирование текста»). Вне зависимости от типа этапа, педагогу предлагается HTML-редактор для размещения общего контента и отдельно контента для каждой из групп учащихся. При этом для любого этапа должна быть обеспечена возможность загрузки файлов, которые должны автоматически конвертироваться в pdf и просматриваться прямо из системы, это должно касаться также видео-записей, загружаемых в подсистему: должен быть реализован просмотр видео прямо через подсистему «Цифровой урок»; 4.3) дополнительные этапы – не включаются в обычный ход урока – да/нет. Если «да», этап не показывается педагогу при управлении уроком; 4.4) доступен участнику независимо от хода урока – да/нет – если «да», контент доступен ученику не только когда педагог активизирует этап при управлении уроком, а в любое время, например он может получить доступ к контентам, заданиям, самостоятельно, работая с подсистемой; 4.5) этап завершен – да/нет – показывается соответствующая пометка в названии этапа; 4.6) а редакторе этапа должна быть предусмотрена возможность вставки видео RuTube и объектов, поддерживающих тег , в частности должна быть обеспечена возможность встраивания интерактивных объектов проекта learningapps.org и других аналогичных решений, например – форм google. Редактор должен также предусматривать возможность вывода в рамках этапа внешних сайтов, разрешающих встраивание. - - Участник закупки указывает в заявке все значения характеристики

5) Управление уроком. Педагог должен иметь возможность управлять показом этапов урока (педагог выбирает этап, этот этап выводится учащимся с учетом разделения контента по группам): пролистывать презентацию, загруженную в «Цифровой урок» при выборе соответствующего этапа, переключать этапы урока, содержащие голосования, анкетирования, представлять учащимся результаты в режиме реального времени. Все изменения в этапах урока и в контенте должны сразу отображаться на устройствах обучающихся (в браузере). Должен быть организован вывод контента этапов, подготовленных педагогом с помощью HTML-редактора (с возможностью загрузки изображений) на всех компьютерах (планшетах, смартфонах) учащихся, либо только на компьютере педагога, подключенном к проектору, интерактивной доске (панели); В качестве презентаций в этап урока должна быть обеспечена возможность загрузки документов в форматах odp, ppt, pptx, а pdf. При выборе этапа с презентацией в ходе управления уроком, педагог должен иметь возможность переключать ее слайды. Слайды должны перелистываться автоматически на устройствах учащихся. В режиме управления уроком учитель должен иметь возможность: – запустить видеоконференцию. Учитель должен иметь возможность демонстрировать свой рабочий стол, а также предоставить такую возможность учащимся или другим педагогам, проводящим урок с ним совместно; – запустить аудиоконференцию (тип конференции должен устанавливаться при настройке урока). 5.1) при выборе этапа «Совместное редактирование текста», педагог вместе с классом получает возможность редактировать текст совместно. Текст каждого пользователя должен выделяться цветом;

5.2) при выборе этапа «Просмотр файла», файл должен выводиться учащимся на устройства и сразу открываться (если это pdf-файл), либо ожидать нажатия кнопки проигрывания (для аудио и видео – файлов); 5.3) при выборе этапа «Вопрос - ...», учащимся выводится вопрос анкеты, на который он получает возможность ответить. Все ответы должны собираться в результаты работы по группам у педагога в интерфейсе управления уроком; 5.4) при выборе этапа «Задание – загрузка файла» ученикам должен выводиться текст этапа (задание) и возможность дать ответ. Надо отметить, что задание не обязательно является текстом. Педагог должен иметь возможность нажать микрофон и озвучить задание. Учащиеся также должны иметь возможность в качестве ответа на задание, как прикрепить файл с диска, так и записать звук на компьютере или смартфоне или видео. Кроме того, ответом на задание может быть фото решения в тетради. Педагог должен иметь встроенный графический редактор в подсистеме, чтобы отметить ошибки прямо на фото решения. По заданиям и вопросам у педагога должна быть возможность дать комментарии каждому учащемуся (написать или записать аудио-комментарий, либо сделать фото), а также выставить балл (оценить ответ). При этом за работу на уроке педагог должен иметь возможность выставить дополнительные баллы, не привязанные к заданию (вопросу).

6) Распределение учащихся по группам. Учитель должен иметь возможность распределить всех учеников по группам (не более 5). Разделение на группы может быть использовано при формировании контента, выдаче вопросов и заданий. 7) В подсистеме «Цифровой урок» должен быть реализован модуль «Студия цифрового урока», обеспечивающий следующий функционал: 7.1) создание видеоролика с настройкой его свойств (разрешение, частота кадров и др); 7.2) обеспечение в браузере редактирования компоновки материала: 7.2.1) изображение с web-камеры; 7.2.2) запись рабочего стола, окна программы или закладки в браузере и размещение на рабочем столе Студии; 7.2.3) подключение фоновой аудиозаписи (например, фоновой мелодии); 7.2.4) подключение (загрузка) презентации; 7.2.5) подключение микрофона; 7.3) запись видеофрагмента: при записи педагог может использовать инструменты (карандаш, линия, окружность и др.) и рисовать поверх слайдов презентации и размещенных на рабочем столе Студии окон, при этом объяснение материала микшируется с фоновым звуком и звуком от микрофона, размещенного на рабочем столе Студии; 7.4) монтаж ролика с использованием видеофрагментов: перемещение видеофрагментов, отключение видеофрагментов; 7.5) экспорт видеоролика и сохранение для использования в «Цифровом уроке». Функционал должен работать в браузерах Chromium, Yandex Browser без установки дополнительного программного обеспечения на компьютер учащегося или педагога.

8) В подсистеме должна быть реализована Библиотека уроков. Любой педагог должен иметь возможность представить свой урок, для которого он разрешил использование другими педагогами, в библиотеке. В Библиотеке должен быть реализован поиск (фильтрация) уроков по типу/уровню образования, параллели, предмету (для общего образования). Выбрав урок любой педагог может просмотреть данные о нем, внесенные автором, включая перечень этапов и нажать «Импортировать» для использования в своей работе. 9) Администрирование. В подсистеме должен быть доступен модуль администратора подсистемы, обеспечивающий доступ, как минимум, к следующим данным: учителя (обязательные поля, как минимум: ФИО, email, СНИЛС); уроки; этапы урока; регистрационные данные участников урока; варианты текста для групп участников урока (HTML); варианты ответа (на вопросы анкетирования); ответы участников (на вопросы анкетирования); файлы этапа (загруженные педагогом дополнительные сведения); задачи для перекодирования файлов (техническая таблица, содержащая список задач и ссылки на файлы); данные участников, связанные с уроком (группа, баллы); список альтернатив для альтернативного этапа (педагог должен иметь возможность назначать альтернативные этапы различным группам детей); данные этапа, связанные с уроком (номер текущей страницы презентации, признак завершения этапа); учителя, которые могут совместно вести урок; теги участников (теги, установленные урокам самими учащимися). Должна быть обеспечена выгрузка всех перечисленных сведений из системы в формате MS Excel, а также в виде csv-файлов.

Функциональная подсистема «Цифровой урок» должна быть реализована с использованием личных кабинетов на региональном образовательном портале. Подсистема «Цифровой урок» должна представлять собой инструмент смешанного обучения, позволяющий создавать интерактивные уроки, модули и курсы, организовывать синхронное и асинхронное обучение с возможностью участия в занятиях педагогов и учащихся, находящихся в классе, дома, на улице, реализовывать в цифровом формате сетевые образовательные программы с участием нескольких образовательных организаций. Должен включать в себя электронную библиотеку образовательных материалов, формируемую на региональном уровне. Исполнитель должен предусмотреть реализацию следующих основных функций: 1) Вход в Подсистему педагога: 1.1) Вход в Подсистему с использованием личного кабинета педагога в Системе; 1.2) Вход в Подсистему с использованием ЕСИА. 2) Вход в подсистему обучающихся: 2.1) В подсистеме должна быть предусмотрена загрузка данных об обучающихся из любой внешней системы, для чего должен быть разработан специальный REST-сервис, позволяющий забирать из сторонних систем перечень обучающихся класса (группы) и включать их в Цифровой урок, для которого настроена ссылка (в сторонней системе при этом должен быть реализован совместимый сервис); данные должны передаваться в формате JSON; 2.2) В случае включения свободной регистрации, должна быть обеспечена возможность входа с одновременной регистрацией ученика и записью на урок по ссылке, по пригласительному коду, по QR-коду;

3) При создании урока должна быть обеспечена настройка следующих опций: 3.1) Включить конференцию – педагог может выбрать аудио либо видеоконференцию (WEB RTC – конференцию). Видеоконференция должна обеспечивать возможности трансляции всего рабочего стола или выбранного окна; трансляцию web-камер, подключенных к компьютеру; обеспечить аудиотрансляцию; обеспечить использование общей доски с рисованием на ней всех участников урока и выводом презентации. Также в системе должна быть реализована возможность указания в качестве конференции произвольного стрима, например, организованного с использованием в VK или RuTube; 3.2) Свободная регистрация – возможность входить учащимся по коду, QR-коду или ссылке и регистрироваться в подсистеме и на урок; 3.3) Теги урока – указание тегов, например предмета или образовательной программы с функцией фильтрации по тегам при работе с перечнем уроков; 3.4) Разрешить другим учителям импортировать этот урок – педагогам можно отправить ссылку, по которой после входа в систему можно «забрать» урок себе (импортировать) для самостоятельного развития;

3.5) Разрешить другим учителям совместно использовать этот урок – подключение других педагогов к уроку для его совместной разработки и проведения занятий, включая конференцию и контроль работы обучающихся, оценивание; 3.6) Выделение учащимся виртуальных машин – возможность выделения предварительно подготовленных педагогом виртуальных машин с операционными системами Linux или Windows для доступа через web из подсистемы «Цифровой урок»; 3.7) Включение чата для использования при проведении урока (в режиме управления уроком). Чат должен обеспечивать обмен сообщениями, записанными аудио и видео – фрагментами, скриншотами во время урока; 3.8) Должна быть обеспечена возможность использования встроенной электронной доски при управлении цифровым уроком (без необходимости запускать видеоконференцию). Учащиеся должны на своих устройства получить оповещение, что учитель запустил доску и иметь возможность подключиться к ней. Чтобы участник урока мог писать на доске, учитель должен дать ему доступ «вызвать к доске», тогда у учащегося должны появиться инструменты для работы на общей доске.

Требования к подсистеме «Мероприятия в образовании» - Основная информация о мероприятии. Раздел должен включать следующие сведения: Наименование мероприятия – строка, содержащая до 250 символов (обязательно). Описание мероприятия – web-страница (memo-поле). Галерея изображений – набор jpg или png – файлов (должно быть загружено хотя бы одно изображение, должны быть собледелены минимальные размеры изображения 1280 x 720 точек или более с возможностью вырезки прямоугольника с пропорциями 16:9 размером не менее 1280 x 720 точек). Видеоанонс (трейлер) мероприятия – видеофайл (не более 250 Mb). Разрешение не менее 720 dpi, соотношение сторон 16:9. Аудиоанонс (подкаст) с сменой слайдов из галереи изображений (могут быть заданы титульный слайд и моменты времени вывода других изображений из числа загруженных в галерею). Основной организатор мероприятия (строковое поле, по умолчанию соответствует полному наименованию организации, от имени которой создается мероприятие). Сайт мероприятия (не обязательное поле). Открыть раздел мероприятия на портале (да/нет). - - Участник закупки указывает в заявке все значения характеристики

Наименование раздела мероприятия на портале. Как сказано выше, для любого мероприятия должна быть реализована возможность создания раздела на портале с определенным именем (поддоменом), например ... «.» предоставляет Заказчик для настройки системы на серверах Заказчика. должно формироваться в формате act_, тем самым обеспечивается его уникальность, но в тоже время координатор организации, планирующий мероприятие может придумать свое уникальное , например — указать «olympmath-2021» и т.д. Система должна обеспечить проверку корректности. В случае, если у мероприятия отсутствует раздел, для него должна быть создана только карточка, а функции регистрации, публикации материалов и т.п. не должны быть недоступны. Период проведения: - Дата/время начала мероприятия. - Дата/время завершения мероприятия. Дата начала и завершения должны быть обязательно указаны. По-умолчанию указание времени не должно обязательно требоваться от пользователя. Место проведения (не обязательно, может быть также определено в разделе «Управление мероприятием»). Место проведения (строка). Географические координаты (широта, долгота).

Следом за основной информацией должен следовать раздел «Классификация», который включает в себя сведения: - Статус мероприятия (в соответствии с таблицей 8 приложения 2 к Контракту); - Тип мероприятия (в соответствии с таблицей 9 приложения 2 к Контракту); - Форма участия: «Персональное участие» либо «Командное участие» (для тех типов мероприятия, где оно предусмотрено); - Направленность (в соответствии с таблицей 10 приложения 2 к Контракту); - Масштаб (уровень) мероприятия (в соответствии с таблицей 11 приложения 2 к Контракту); - Форма проведения мероприятия (в соответствии с таблицей 12 приложения 2 к Контракту).

За разделом «Классификация» следует раздел «Управление мероприятием». Раздел должен быть доступен только в случае, если для мероприятия определен раздел на портале, поскольку функционал должен быть реализован на сайте мероприятия для авторизованных в системе пользователей: - работников системы образования; - обучающихся; - родителей (законных представителей). Раздел «Управление мероприятием» должен содержать следующие данные 1. Этапы мероприятия (с возможностью добавления, удаления и корректировки информации об этапе) да/нет. По каждому этапу, если указано, «да», те этапы выделяются, указываются: 1.1 Наименование этапа мероприятия (номер этапа должен устанавливаться автоматически). 1.2 Организатор(ы) этапа мероприятия. По умолчанию должна быть указана организация, создавшая мероприятие (организатор этапа совпадает с организатором мероприятия).

Подсистема «Мероприятия в образовании» должна обеспечивать планирование и публикацию мероприятий всеми образовательными организациями и органами управления образованием, информирование потенциальных участников о планируемых мероприятиях, электронную запись на мероприятия, загрузку информации (тезисов, публикаций – при необходимости) и выдачу цифровых дипломов или других документов (при необходимости) участникам и победителям мероприятий. Должна обеспечиваться, в том числе, регистрация на олимпиады всех уровней, поддерживаться как личное, так и командное участие в мероприятиях. Должна быть обеспечена автоматизация проведения мероприятий, формирование страницы на портале или сайта мероприятия. Подсистема должна обеспечивать процесс подготовки и проведения школьного, муниципального и регионального этапа всероссийской олимпиады школьников. Подсистема должна быть интегрирована с ЕАИС ДО – единой автоматизированной информационной системой сбора и анализа данных по учреждениям, программам, мероприятиям дополнительного образования и основным статистическим показателям охвата детей дополнительным образованием в субъектах Российской Федерации (в отношении мероприятий). Вне зависимости от типа организации, в личном кабинете должен быть доступен раздел «Мероприятия организации», после выбора которого открывается перечень доступных мероприятий, а также возможность добавить, изменить мероприятие, включая его статус.

1.2.1 Место проведения этапа мероприятия. Должен осуществляться выбор из числа зданий организатора мероприятия, по умолчанию должно выставляться главное здание организации. В случае, если в Системе для здания не определены географические координаты (широта и долгота) или для организации не внесены здания, должно обязательно требоваться указание названия места проведения (по умолчанию должна указываться строка, совпадающая с наименованием организатора), должны обязательно требоваться координаты места проведения (широта и долгота). По умолчанию, если указаны координаты места проведения всего мероприятия и организатор этапа совпадает с организатором мероприятия, должны использоваться те же координаты, которые могут быть откорректированы. Для мероприятий, проводимых в дистанционном формате информация о месте проведения не указывается. В разделе мероприятия на портале, в случае, если указано, что этапов «нет», дополнительная информация по этапам выводиться не должна. В качестве мест проведения должна быть обеспечена возможность выбора нескольких образовательных организаций или всех ОО определенного типа. Полный перечень типов организаций приводится в таблице13 приложения 2 к Контракту. При выборе образовательных организаций система должна обеспечивать фильтрацию по органам управления образованием и типам организаций. По умолчанию в качестве мест проведения должны использоваться географические координаты главных корпусов зданий ОО. В случае отсутствия данных, информация о названии и координатах мест проведения должна указываться организатором вручную. 1.2.1.1 Указание времени проведения этапа мероприятия. Должна быть обеспечена возможность применить указанное время ко всем местам проведения мероприятия или указать время индивидуально. 1.2.1.2 Ограничение числа участников (количество человек, количество подключений).

1.3 Регистрация на этап (могут быть выбраны несколько опций в соответствии с таблицей 14 приложения 2 к Контракту). Далее следует обеспечить выбор одного из вариантов регистрации на этап: 1.3.1 Регистрация с использованием ЕПГУ (создание формы не является задачей Исполнителя, не предполагается получение в Систему данных с ЕПГУ) 1.3.1.1 Ссылка на форму ЕПГУ (должна указываться обязательно при выборе варианта 1.3.1) 1.3.2 Регистрация с использованием формы портала, поля формы приведены в таблице 15 приложения 2 к Контракту. Должна быть реализована возможность добавления организатором полей к регистрационной форме с указанием типа поля (числовое, строковое, дата, файл (с указанием допустимых типов файлов), а также обязательности полей. Должны быть реализованы возможности выбора полей для включения в форму, а также изменения требований к обязательности поля. В приведенной таблице указана информация об обязательности данных по умолчанию. Настроенная организатором форма регистрации предоставляется для записи участникам мероприятия (этапа мероприятия). При заполнении формы для регистрации на последующие этапы, поля, заполненные при регистрации на предыдущие этапы мероприятия уже должны быть заполнены. Для каждого поля при конфигурировании формы требуется указать права доступа для просмотра и изменения в соответствии с таблицей 16 приложения 2 к Контракту. 1.3.3 Автоматическая регистрация на этап участников, прошедших регистрацию на предыдущие этапы мероприятия. При выборе данного варианта, потенциальными участниками этапа становятся все, зарегистрировавшиеся на предыдущие этапы. Участие в этапе зависит от того, подтвердил ли участник свое участие и подтвердил ли участие координатор мероприятия. 1.3.3.1 Требуется подтверждение регистрации организатором (да, нет). 1.3.3.2 Требуется подтверждение регистрации участником (да, нет).

1.4. Подача материалов для участия в этапе (да, нет). 1.4.1 Информация о необходимости предоставления материалов (инструкция) – HTML. 1.4.1.1 Материалы – таблица метаданных (структура формируется организатором), включая «Наименование материалов», «Тип файла» (фото, презентация, документ, видео), «Обязательны для предоставления» (Да/Нет). Должна быть обеспечена возможность настраивать права доступа к материалам в соответствии с таблицей 17 приложения 2 к Контракту. 1.5 Результаты участия (да, нет). 1.5.1 Результат или баллы, Достижение (из справочника: Не участвовал, Победитель, Призер, Участник. Значение по умолчанию «Участник»). Поле «Достижение» может редактировать только организатор (соорганизатор) этапа мероприятия. Результаты должны попадать в структуру регистрационной формы см. п. 1.3.2.1.

2. Отчетность Для организаторов мероприятий в системе должна быть реализована отчетность, в том числе, по регистрации участников и результатам мероприятий. Система должна включать в себя следующие универсальные отчетные формы: 1) Отчеты о регистрации на мероприятия. Формы должны включать в себя информацию о мероприятии, его организаторах, этапах мероприятия, их организаторах, числе зарегистрированных участников в разрезе организаторов этапов (образовательных организаций, если этап проводится на базе образовательных организаций). Если мероприятие охватывает несколько муниципалитетов, должна быть реализована возможность сформировать отчет в разрезе органов управления образованием, являющихся учредителями образовательных организаций, а также классов (для внутришкольных мероприятий) и параллелей. Должны быть предусмотрены два вида отчетов по регистрации на мероприятия – сводные отчеты, содержащие информацию о числе зарегистрированных участников и персонализированные списки, содержащие информацию о зарегистрированных участниках в выбранных разрезах. 2) Отчеты о результатах мероприятий. Система должна включать в себя отчеты о результатах двух типов: – сводная отчетность: отчет должен включать в себя информацию о числе зарегистрированных на участие, число участников, результаты победителя и средний набранный балл; – персонализированные списки: организатор должен иметь возможность настроить выборку при формировании списков в части разрезов (включать информацию по муниципалитетам и ОО в отчет, а также выбрать конкретные ОО и муниципалитеты), а также в части фильтра для включения в списки (занятые места, критерии по достижению балла).

3. Заявки на мероприятия. Раздел должен обеспечивать возможность для организаторов управлять заявками (просматривать, подтверждать, отказывать), вносить в Систему результаты мероприятий и т. д. Должна быть обеспечена возможность отбора (фильтрации) заявок по ОО, типам мероприятий, мероприятиям и этапам мероприятий, участникам, предметам (для олимпиад) и другим параметрам, предусмотренным в Системе. Должна быть реализована возможность внесения представителями образовательных организаций заявлений на участие в всероссийской олимпиаде школьников на основе бумажных заявлений родителей (законных представителей). Для заявки на мероприятия, имеющие тип «Всероссийская олимпиада школьников», должен быть использован справочник, содержащий, как минимум следующие предметы: Английский язык; Астрономия; Биология; География; Информатика (ИКТ); Искусство (Мировая художественная культура); История; Испанский язык; Итальянский язык; Китайский язык; Литература; Математика; Немецкий язык; Обществознание; Основы безопасности и жизнедеятельности; Право; Русский язык; Технология; Физика; Физическая культура; Французский язык; Химия; Экология; Экономика.

Преимущества, требования к участникам

Преимущества: Преимущество в соответствии с ч. 3 ст. 30 Закона № 44-ФЗ - Размер преимущества не установлен

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 2. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ

Сведения о связи с позицией плана-графика

Сведения о связи с позицией плана-графика: 202501212000001001000044

Начальная (максимальная) цена контракта: 7 957 700,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 252263400875826340100100720010000244

Срок исполнения контракта (отдельных этапов исполнения контракта) включает в том числе приемку поставленного товара, выполненной работы, оказанной услуги, а также оплату заказчиком поставщику (подрядчику, исполнителю) поставленного товара, выполненной работы, оказанной услуги

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 31.12.2025

Закупка за счет бюджетных средств: Да

Наименование бюджета: Бюджет Ставропольского края

Вид бюджета: бюджет субъекта Российской Федерации

Код территории муниципального образования: 07000000: Муниципальные образования Ставропольского края

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 79 577,00 РОССИЙСКИЙ РУБЛЬ

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке установлен в соответствии с частью 5 статьи 44 Федерального закона №44-ФЗ. Для участников, являющихся иностранными лицами, обеспечение заявок в виде денежных средств предоставляется с учетом особенностей, предусмотренных постановлением Правительства Российской Федерации от 10 апреля 2023 г. № 579 «Об особенностях порядка предоставления обеспечения заявок на участие в закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд участниками таких закупок, являющимися иностранными лицами». Условия независимой гарантии установлены в соответствии с положениями статьи 45 Федерального закона №44-ФЗ. Реквизиты счета для перечисления денежных средств в случае, предусмотренном частью 13 статьи 44 Федерального закона: указаны в настоящем разделе

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03222643070000002100, л/c 075050013, БИК 010702101, ОТДЕЛЕНИЕ СТАВРОПОЛЬ БАНКА РОССИИ//УФК по Ставропольскому краю г. Ставрополь, к/c 40102810345370000013

Номер типовых условий контракта: 1400700000521003

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, край Ставропольский, г.о. город Ставрополь, г Ставрополь, ул Пирогова, д. 18/6, Система размещена в центре обработки данных (далее – ЦОД) Заказчика, по адресу: 355045, Россия, Ставропольский край, Ставрополь, ул. Пирогова, 18/6. Заказчиком предоставляется Исполнителю доступ к необходимым для оказания услуг подсистемам РИС СО с использованием защищенных каналов связи. Технические средства для подключения Исполнителя к РИС СО обеспечиваются Исполнителем и предусматривают приобретение сертифицированного программного обеспечения VipNet Client и антивирусного программного обеспечения. Регламент подключения предоставляется Заказчиком после заключения Контракта. Заказчик оказывает содействие Исполнителю в подключении к защищенной сети.

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 30 %

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Порядок предоставления обеспечения исполнения контракта, требования к такому обеспечению установлены в соответствии со статьей 96 Федерального закона № 44-ФЗ и условиями контракта.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03222643070000002100, л/c 075050013, БИК 010702101, ОТДЕЛЕНИЕ СТАВРОПОЛЬ БАНКА РОССИИ//УФК по Ставропольскому краю г. Ставрополь, к/c 40102810345370000013

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: В соответствии с условиями контракта

Информация о требованиях к гарантийному обслуживанию товара: В соответствии с условиями контракта

Требования к гарантии производителя товара: В соответствии с условиями контракта

Банковское или казначейское сопровождение контракта не требуется

Информация о сроках исполнения контракта и источниках финансирования

Срок исполнения контракта (отдельных этапов исполнения контракта) включает в том числе приемку поставленного товара, выполненной работы, оказанной услуги, а также оплату заказчиком поставщику (подрядчику, исполнителю) поставленного товара, выполненной работы, оказанной услуги

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 31.12.2025

Закупка за счет бюджетных средств: Да

Наименование бюджета: Бюджет Ставропольского края

Вид бюджета: бюджет субъекта Российской Федерации

Код территории муниципального образования: 07000000: Муниципальные образования Ставропольского края

Документы

Общая информация

Документы

Журнал событий