Требования к подсистеме интеграции с сервисами SMS-информирования
Для обеспечения возможностей информирования пользователей через услуги СМС-сообщений, электронной почты от сторонних поставщиков (далее - сервис информирования) необходимо реализовать программное обеспечение коммуникационного узла (адаптера) для корпоративной сервисной шины (ESB), а также программное обеспечение модуля для автоматизированного запуска выгрузки данных (программа-планировщик).
В рамках предыдущих разработок Системы были внедрены инструменты для обмена данными по технологии Service Bus посредством XML-сообщений, административный интерфейс для настройки клиентов.
Коммуникационный узел корпоративной сервисной шины для информирования пользователей должен удовлетворять следующим требованиям:
должен реализовывать свой интерфейс контрактов для подключения к шине;
использовать для обмена данными XML-сообщения нескольких видов, требования к структуре каждого из них описаны ниже;
иметь внешний веб-интерфейс для настройки параметров и контроля работы.
Коммуникационный узел служит для обновления данных в базах данных сервисов, формирования сообщений для рассылки и обработки запросов сервисов. Должны поддерживаться следующие сценарии работы: создание подписки на сервис, обновление данных подписки на сервис, запрос доступности услуги для пользователя, формирование информационной рассылки.
Для обеспечения работы сервиса SMS-информирования со стороны такого сервиса должны существовать следующие интерфейсы:
Интерфейс "Регистрация новой подписки на сервис информирования, обновление данных существующей подписки". Для поддержки такого интерфейса коммуникационный модуль Системы должен помещать в шину сообщение формата:
...
...
...
...
...
где: ID – идентификатор подписки, Type – тип сервиса информирования, одно из значений sms, email, Code – код услуги, целое число.
В качестве ответа на обработку запроса новой подписки сервис информирования должен отправлять сообщение формата:
где: ID – идентификатор подписки, Res принимает одно из двух возможных значений ok или fail, в зависимости от результата обновления, Code – код ошибки или 0, если ошибки не произошло.
Интерфейс "Запрос доступности услуги для пользователя". Для реализации такого интерфейса коммуникационный модуль должен помещать в шину сообщение следующего формата:
...
...
...
где: ID – идентификатор подписки.
В качестве ответа на обработку запроса новой подписки сервис информирования должен отправлять сообщение формата:
...
...
...
...
...
где: ID – идентификатор подписки.
Интерфейс "Отправка информации для рассылки". Для реализации такого интерфейса коммуникационный модуль должен помещать в шину сообщение для сервиса:
...
...
...
где: ID – идентификатор подписки.
При формировании и отправке сообщений не должно происходить передачи персональных данных пользователей Системы, все сообщения должны быть обезличены.
В качестве ответа на обработку запроса новой подписки сервис информирования должен отправлять сообщение формата:
...
где: ID – идентификатор подписки, Res принимает одно из двух возможных значений ok или fail, в зависимости от результата обновления, Code – код ошибки или 0, если ошибки не произошло.
Для обеспечения работы сервиса информирования должно быть реализовано программное обеспечение модуля для автоматизированного запуска выгрузки данных (программа-планировщик). Программа-планировщик должна функционировать в фоновом режиме, своевременно формируя и помещая необходимые сообщения в сервисную шину. Для настройки запусков необходимо создать визуальный интерфейс настройки, доступный администратору Системы.
Программа-планировщик должна поддерживать следующие настройки:
периодичность запуска;
команды для запуска и формат сообщений, помещаемых в сервисную шину;
время начала опроса шины, время;
реакция на ошибки (повторный вызов, запуск программы-обработчика).
Указанные настроечные сведения программы-планировщика должны храниться в явном виде на уровне метаданных Системы.
В соответствии с установленным регламентом программа-планировщик должна запускать процедуру выгрузки данных для передачи получателям. Данные о каждом запуске должны сохраняться в журнал планировщика и быть доступными Администратору системы через Веб-приложение для настройки параметров и контроля работы сервиса.
Требования к подсистеме интеграции с системами электронной почты и хранения данных корпоративного уровня
Для предоставления пользователям Системы широких возможностей коммуникаций и хранения данных Исполнителю требуется обеспечить интеграцию Системы с сервисом электронной почты корпоративного уровня (сторонних поставщиков или собственных) и с сервисом хранения больших объемов данных корпоративного уровня (сторонних поставщиков или собственных).
Общие требования к интеграции:
учетная запись пользователя в Системе должна совпадать с логином или состоять из логина и постфикса, указывающего сервер электронной почты, например: @mail.web2edu.ru;
логин и пароль должны вводиться один раз: необходимо настроить протоколы взаимодействия между сервисом и Системой таким образом, чтобы обеспечивалась безопасность передачи данных (на основе цифрового сертификата, либо по защищенным каналам связи, либо используя специальные средства криптографии);
оформление внешних сервисов должно быть настроено таким образом, чтобы у пользователя создавалось впечатление работы в единой системе;
подключение пользователя к сервису должно происходить либо по запросу пользователя в интерактивном режиме, через интерфейс системы, либо при регистрации новых пользователей.
Требования к сервису электронной почты корпоративного уровня:
объём одного почтового ящика пользователя должен быть не менее 1 Гб;
должна быть поддержана возможность стандартного подключения внешних программ-почтовых клиентов;
должны поддерживаться возможности организации групп контактов, настройки структуры папок почтового ящика, полнотекстового поиска писем, архивации, фильтрации и пересылки сообщений;
сервис должен содержать веб-интерфейс для выполнения всех перечисленных операций;
ящики электронной почты для всех пользователей Системы должны иметь одинаковый домен электронной почты, например @mail.web2edu.ru.
Требования к сервису хранения данных:
объем хранилища для каждого пользователя должен быть не менее 20 Гб;
сервис должен поддерживать возможности создания, копирования и перемещения пользовательских папок;
настройка доступа к файлам и папкам должна производиться через веб-интрерфейс сервиса, для предоставления прав доступа должен быть доступен выбор любых пользователи и групп контактов, зарегистрированных в сервисе хранения данных или сервисе электронной почты. Уровни доступа должны быть следующими: доступно для просмотра всем, доступно для просмотра пользователям из списка, доступно для изменения всем, доступно для изменения пользователям из списка, доступно только владельцу;
сервис должен предоставлять интерфейс для синхронизации с папкой файлов, размещенной на локальном компьютере пользователя (для этих целей на компьютере необходимо установить специальное программное обеспечение);
для хранения и обмена фотографиями сервис должен предоставлять визуальный интерфейс для создания, изменения и просмотра отдельных фотографий и фотоальбомов.
Требования к подсистеме новостного сервиса и сервиса рассылок информационных материалов и событий портала на основе технологии RSS
Исполнителю требуется обеспечить функционирование в Системе сервиса рассылки информации на основе RSS. С помощью такого сервиса должны формироваться группы информационных материалов, визуально оформленные в виде лент сообщений. Требуется обеспечить отображения для пользователя следующих групп информационных материалов (лент):
лента новостей (для каждого класса, школы, территории формируются отдельные ленты новостей, с учетом иерархической вложенности территорий и подчинения школ, классов);
лента новых постов блогосферы (дополнительно для каждого пользователя нужна RSS-лента новых постов его друзей и лента блогов, на которые он подписан, т.е. в программе просмотра RSS существует запись о получении данных с портала);
лента изменений в настройках, учебных периодах, звонках, сменах, расписании, школ и классов;
лента сведений о загрузке файлов, папок, электронных образовательных ресурсов и версий уроков, над которыми ведется коллективная работа пользователей Системы.
Информационные материалы должны автоматически обновляться в лентах с помощью описанной в пункте 3.4. программы-планировщика.
Перечисленные выше группы информационных материалов должны быть доступны для подписки только после ввода логина и пароля пользователя в Системе, кроме этого ни в одну ленту не должны передаваться персональные данные пользователей, все сведения должны быть обезличены. При информировании об авторстве объектов допускается указание логина и ссылки на объекты Системы.
Все настройки периодичности обновления должны вестись в программе-планировщике, уровень доступа к информационным материалам должен задавать администратор Системы.
Необходимо поддерживать следующие форматы информационных лент:
Требования к подсистеме поддержки мониторинга качества предоставления услуги "Электронный дневник"
Для обеспечения мониторинга качества предоставления услуг, согласно приказу Министерства образования Пермского края от 29.03.2010 №СЭД-26-01-04-81 «Об утверждении новой редакции требований к характеристикам услуги по ведению электронных дневников и журналов и новой редакции регламента мониторинга предоставления общеобразовательными учреждениями Пермского края услуги по ведению электронных дневников и журналов, утвержденных приказом Министерства образования Пермского края от 09 марта 2010 г. № СЭД-26-01-04-50» (полный текст приказа приведен в разделе 8 настоящего Технического задания) Исполнитель должен обеспечить возможность формирования отчетов о качестве предоставления услуг по ведению электронных дневников и журналов на основании информации, содержащейся в БД Системы и предоставление сформированных отчетов конечным пользователям.
Требования к обновленным сценариям функционирования Системы
Исполнителем должны быть осуществлены поставка, доработка и настройка программного обеспечения, обеспечивающего поддержку обновленных сценариев функционирования Системы:
- сценария «Ввод нового шаблона расписания»;
- сценария «Редактирование существующего шаблона расписания»;
- сценария «Удаление шаблона расписания»;
- сценария «Приведение уроков в соответствие с расписанием»;
- сценария регистрации пользователей;
- сценария работы с классами и учебными группами;
- сценария работы с тематическими планами;
- сценария перемещения учеников из класса в класс;
- сценария работы с отчетными формами .
Исполнитель должен обеспечить обновление сценариев функционирования Системы путем поставки, доработки и настройки программного обеспечения. За счет обновления сценариев функционал системы должен быть дополнен следующим:
должна поддерживаться дата ввода и дата окончания действия шаблона расписания;
должна существовать возможность переноса уроков с праздничных и выходных дней на любые другие дни;
должна существовать возможность явного указания даты начала и окончания каникул, приходящихся на время учебного периода, на такой период уроки не должны генерироваться;
должна быть обеспечена поддержка многокритериальных оценок за одну работу (путем введения вместо одной оценки нескольких отдельных оценок по критериям, а также путем введения обозначений критериев A,B, C, D, E, F);
должна быть поддержана возможность увеличения максимального балла оценки с 5 до 100;
должно быть произведено разделение оценок на констатирующие и формирующие (при автоматизированном расчете итоговой оценки за период должны учитываться только констатирующие оценки);
необходимо добавить справочник «Вид оцениваемой работы» для характеристики оценок;
необходимо дополнить справочник ролей новой ролью «администратор школы» с правами директора, обеспечить возможность завучам самостоятельно изменять свою роль на роль "администратор школы".
Исполнитель должен обеспечить настройку интерфейса и структуру БД в соответствии с требованиями к обновлению сценариев. При выполнении настройки Исполнитель должен обеспечить полную поддержку базовой функциональности Системы и исключить возможность потери данных пользователей при введении новых функций.
Исполнитель должен обеспечить функционирование Системы по обновленным сценариям в соответствии с описаниями обновленных сценариев, представленных ниже.
Описание обновленного сценария «Ввод нового шаблона расписания»
Действия сценария:
Пользователь переходит в раздел «Расписание уроков».
Система отображает поле выбора класса из доступных пользователю в соответствии с правилами разграничения полномочий.
Пользователь выбирает необходимый класс из списка.
Система отображает последний (текущий) шаблон расписания для выбранного класса. В заголовке формы показываются значения, относящиеся к последнему (текущему) шаблону:
номер версии;
состояние;
дата ввода в действие;
срок действия;
дата закрытия;
признак четности недели (пусто – по умолчанию);
примечание.
Пользователю доступны следующие операции: «Создать новый шаблон», «Отредактировать шаблон», «Удалить шаблон», «Привести уроки в соответствие с расписанием».
Пользователь может просмотреть старые (архивные) шаблоны расписания, без возможности их модификации. Система должна сохранить в ячейках памяти значения «Номер версии», «Дата ввода в действие» и «Срок действия» последнего шаблона. Кнопка «Отредактировать шаблон» доступна только для последнего (текущего) шаблона, кроме этого, если по данному расписанию уже созданы уроки, необходимо блокировать возможность редактирования и отображать количество проведенных уроков по каждой строке.
После выбора нужного шаблона пользователь нажимает кнопку «Создать новый шаблон», на его основе формируется новый шаблон, идентичный выбранному, с возможностью вносить изменения, как в строки расписания, так и в поля расписания.
Система открывает на редактирование все поля формы, кроме «Номера версии», «Даты закрытия» и «Состояния». В качестве даты ввода расписания в действие по умолчанию подставляется текущая дата, в качестве состояния – «Черновик». Если «Срок действия» последнего шаблона больше текущей даты, он подставляется в качестве значения по умолчанию.
Пользователь корректирует доступные поля формы. Поля «Дата ввода в действие» и «Срок действия» расписания являются обязательными для заполнения.
Произведя необходимые изменения, Пользователь нажимает кнопку сохранения.
Система сохраняет введенный шаблон расписания в состоянии «Черновик»:
создает запись в таблице «Расписание» с увеличенным на 1 номером версии (относительно номера последнего шаблона), состоянием - «Черновик», пустой датой закрытия;
сохраняет строки нового шаблона расписания в таблице «Строка расписания»;
актуализирует кнопки «Проверить шаблон», «Вести в действие».
Для проверки введенного шаблона пользователь может нажать кнопку «Проверить шаблон», для его актуализации – «Вести в действие».
В любом случае система проверяет данные шаблона и выдает сообщение об ошибке, если
значение «Дата ввода в действие» нового расписания меньше значения «Дата ввода в действие» последнего шаблона расписания и есть хотя бы один урок по старому расписанию;
значение «Дата ввода в действие» нового расписания больше значения «Срок действия» нового расписания;
возможны пересечения следующих видов:
у одного учителя запланировано несколько уроков в одно и то же время в разных учебных кабинетах;
один ученик должен находиться на разных уроках в пересекающиеся периоды времени;
в одном кабинете должно проводится несколько разных уроков в пересекающиеся периоды времени;
невозможно провести ни одного урока в случае, если шаблон расписания действует в период, меньший недели и запланированы уроки на дни недели, которые не входят в период действия шаблона;
невозможно провести ни одного урока в случае, если период преподавания предмета не пересекается с периодом действия шаблона расписания.
Если ошибки не обнаружены и была нажата кнопка «Вести в действие», система выполняет следующее:
прекращает действие текущего шаблона расписания (устанавливает дату закрытия равной «Дате ввода в действие» нового шаблона расписания -1 день, изменяет состояние шаблона на «Архив»;
вводит в действие новый шаблон расписания (изменяет состояние на «Введено в действие»).
|
