Введение 3
Цели и задачи 4
Глава 1. Бизнес правила и ограничения процесса планирования нагрузки и расписания 5
Глава 2. Архитектура решения 10
2.1. Ресурсы системы 11
Глава 3. Выявленные требования и задачи развития и разработки электронного расписания СПбГУ 15
3.1. Разработка высокопроизводительного и удобного интерфейса для манипуляции данными нагрузки и расписания 15
Организация пользовательского интерфейса и используемые компоненты 15
Устранение зависимости от API, препятствующего удовлетворению требования по производительности 18
3.2. Web API (timetable.spbu.ru/help) 20
Решение 21
Технические детали решения 21
Документация 22
Итоги 22
3.3. Повышение производительности доступа к данным 23
Критерии сравнения 23
Возможные решения 23
Вывод 27
3.4. Накладки или поиск конфликтов 28
3.5. Логирование 29
Заключение 31
Ссылки 31
Приложение A. Статистика данных по веб-сайту из Google Analytics 37
В 2011 году была сформирована рабочая группа с целью разработки и введения в эксплуатацию информационной системы «Единое электронное расписание СПбГУ» на основе действующего аналога системы, успешно функционирующего на Юридическом факультете СПбГУ. Ключевые задачи этой системы - доведение до контингента обучающихся и профессорско-преподавательского состава актуального расписания учебных занятий и внеучебных мероприятий, расчет занятости аудиторного фонда и преподавателей. В 2012 году было произведено тестовое внедрение системы на три направления СПбГУ: Филология, Востоковедение и Искусства. С 2014 года система успешно функционирует на всех направлениях университета. В настоящий момент осуществляется техническая поддержка, разработка новых функций системы и ее модернизация.
Автор данной работы был принят на стажировку в состав упомянутой группы и перечисленные в настоящем тексте результаты затрагивают не только вклад автора, но и коллег.
Итак, была поставлена цель - исследовать и по возможности улучшить функциональное состояние информационной системы Электронное расписание. Аналитика системы не была проведена и исследована в полной мере, однако проделанная работа вывела аналитику на новый уровень за счёт а) популяризации данных посредством WEB API (параграф 3.2), б) продвинутых средств анализа логов (параграф 3.5) и в) системы оповещения и индикации конфликтов процесса планирования (параграф 3.4). Всё ещё есть проблемы с производительностью, но данная работа положила начало вопросу её улучшения, т.к. были предложены методы оптимизации и дальнейшего развития в этом направлении (параграф 3.3). Не лишним будет сказать, что проделана большая коллективная исследовательская работа в отношении того, как хранятся данные в БД, как они должны храниться и что нужно для развития. Также автором работы было предложено решение на базе ETL - мигратор, использующий API DevExpress для разворачивания данных в удобный формат и последующей перезаписи в базу (параграф 3.1). Возвращаясь к вопросу аналитики, базовые характеристики системы всё же удалось обозначить и зафиксировать в работе, что тоже несёт позитивный вклад. На основе полученных характеристик можно сделать выводы:
• Объем возвращаемых данных в ответ на запрос пользователя веб-сайта — выше нормы, причина тому - избыточный JavaScript-код.
• Число повторяющихся запросов на сайте относится к общему числу запросов как 1 к 5, тем самым можно оценить эффективность работы механизма кэширования (получается, что в среднем 20% всех запросов берётся из кэша).
