доклад Саватеевx

Выносим проблему, а не задачу. Исследовательская работа
Поставлена проблема, что ФИТ хочет поднимать дистанционку. Составили список критериев для
анализа. Выделили основную проблематику и проанализировали существующие СДО.
Системы такие.
Я рассмотрел систему, выделил такие моменты.
Результаты моего анализа по критериям не очень. По другим системам похожая картина.
Принято решение писать свою систему.
Над проектом работала команда из 4 чел. В ходе разработки возникали трудности не только
технологического характера, но также возникали проблемы с коммуникацией, так как была
Были опробованы разные методики разработки.
Перешли на СКРАМ.
В рамках работы над проектом было интересно изучить разные проектные роли, каждый был в
каждой роли.
Первый этап – сбор требований с заказчика (ФИТ НГУ). У него не было четкого понимания, что
такое СДО, то требования собирались в жоских полевых условиях =)
Требования собирались с их видения СДО.
Мы разделили бизнес-процессы на три ключевых раздела. Я Собирал вот эти требования по этому
разделу. В ходе сбора требований по данной области были выработаны ключевые моменты и
роли(кратко).
Параллельно велась разработка архитектура. После сбора требований и разработки архитектуры
было принято решение разбить системы над подсистемы.
В связи с поставленной проблемой Архитектура дб модульная, расширяемая. Нашей командой
была решена эта задача. Система базируется на программных сервисах.
В рамках работы над моей подсистемой были разработаны и спроектированы структура данных,
польз. интерфейс.
Модель – > Архитектуры
Мною разработаны такие сервисы (список, описание каждого сервиса)
В рамках разработки были использованы принципы юзабилити
И разработана структура экранов моей подсистемы. Пример пары экранов + скриншоты
После проработки была имплементация разработанных
Почему такая модель данных, такая архитектура, что такое сервисы, зачем хранимые
процедуры (секурность)
Сервисы для не дублирования функциональностей.
Тема моего дипломного проекта «Разработка системы дистанционного обучения. Подсистема
инспектора. Нормативные документы»
Перед нашей командой была поставлена проблема разработки СДО для ФИТ НГУ. От заказчика в
некоторой форме были получены критерии. Для понимания проблематики было принято
решение рассмотреть существующие СДО. Я рассматривал СДО Прометей. Это удобная,
современная СДО, которой пользуются многие компании. У нее есть такие-то такие-то
преимущества, но по результатам проведения анализа по критериям эта СДО не подходит для
ФИТ. С другими продуктами картина похожая, поэтому было принято решение писать свою СДО.
Над разработкой собственного решения работала команда из 4-х человек. В ходе разработки
возникали трудности не только технологического характера (разные ОС), но и проблемы
организационного характера (коммуникация) в связи с распределенностью команды и т.д.
Были применены разные методики разработки программного обеспечения. Опытным путем было
получено, что для работы над этим проектом лучше подходит Scrum, т.е. по истечении короткого
временного отрезка предоставлять отчет о проделанной работе.
В рамках работы над проектом каждый участник попробовал себя в разных ролях (разработчик,
архитектор).
Первым этапом работы по проекту был сбор требований от заказчика. Так как заказчик не
представлял себе что такое ДО, с его стороны были собраны бизнес-процессы образования и их
видение итоговой системы.
После сбора бизнес процессов было принято решение разделить их на три области. Я собирал
требования по такой-то области.
В ходе сбора требований по данной области были выработаны ключевые моменты: роли,
сервисы, сущности…
Параллельно сбору требований велась работа по разработке архитектуры.
В связи с поставленной проблемой разработанная архитектура должна быть модульной,
расширяемой, отчуждаемой и т.д. Командой была решена эта проблема.
Имея разработанную архитектуру и требования, полученные с БП, было принято решение разбить
систему на логические подсистемы, проработана концепция пользовательского интерфейса. Моя
работа заключалась в разработке подсистемы инспектора и управление нормативными
документами.
В рамках реализации моей подсистемы стояла задача проектирования модели данных (хранимые
процедуры), структуры сервисов и пользовательского интерфейса.
Мною разработаны сервисы создания/изменения группы . Они используются/вызываются не
только в моей подсистеме, но и в других тоже.
При разработке пользовательского интерфейса учтены основные принципы юзабилити.
Добрый день. Я, Саватеев Олег, и я расскажу вам о своем дипломном проекте. Цель диплома
(слайд 1)
Для начала я бы хотел сказать пару слов о том, что же такое система дистанционного обучения и
зачем она нужна.
Система Дистанционного Обучения (СДО) - это программное обеспечение для организации
дистанционной формы обучения, дополнительной системы поддержки учебного процесса,
электронного
документооборота,
для
создания
электронных
обучающих
материалов,
администрирования и оценки успеваемости по курсу (программе) дистанционного обучения.
Дистанционное обучение, фактически это использование любых технологий, позволяющих
проводить обучение, если преподаватель и обучаемый разделены расстоянием и/или временем.
Объем информации, которой владеет цивилизация, удваивается каждые 5 лет. В связи с этим,
помимо приобретения знаний, не менее важным становится освоение технологий, с помощью
которых можно получать, перерабатывать и использовать информацию. Без информатизации
сложно представить дальнейшее развитие научной деятельности. Основная цель внедрения
информационных технологий в образовательный процесс – это повышение уровня качества
подготовки специалистов. Информационные технологии в образовании позволяют динамично
изменять содержание учебного материала в соответствии с последними достижениями в технике
и технологиях.
Перед
нашим
существующий
коллективом
процесс
была
поставлена
дополнительного
проблема
образования
с
внедрения
автоматизации
применением
в
дистанционных
технологий. От научного руководителя были получены ряд критериев для готовой системы, такие
как, например, масштабируемость, простота поддержки, отчуждаемость (слайд 2 с критериями).
На этом этапе ни научный руководитель, ни команда разработчиков не имели представления о
том, что такое СДО. Для этого было решено рассмотреть существующие программные решения.
(Слайд 3 с логотипами программ) Были выбраны три, на тот момент, самые распространенные
СДО и распределены для рассмотрения между участниками команды. Я рассматривал СДО
"Прометей". Это постоянно развивающаяся СДО, внедренная во многих предприятиях (ЛУКОЙЛ,
ИНГОССТРАХ), а также ВУЗах РФ (Институт мировых цивилизаций Москвы, московская финансовоюридическая академия). У этой системы можно выделить следующие плюсы: ориентированный
на
конечного
пользователя
интерфейс,
поддержка
со
стороны производителя
после
приобретения СДО, получение обновлений ПО, многоязычная поддержка. Из минусов можно
отметить цену на предоставляемый продукт и невозможность доработки собственными силами.
После того, как каждый участник изучил свою систему, полученные результаты были сведены в
сводную таблицу функциональных возможностей каждой из рассматриваемых систем.
(Слайд1. Цель) Добрый день. Целью моей дипломной работы является разработка и программная
реализация
подсистем
инспектора
и
управления
нормативными
документами
для
разрабатываемой системы дистанционной поддержки дополнительного обучения.(слайд 2
рассказ об этапах)
Как уже было выше сказано о коллективной части разработки, что для понимания проблематики
каждый из нас рассматривал готовую СДО. Я рассматривал СДО Прометей, которая нам, также как
и другие, не подошла по ряду критериев. В рамках коллективной работы я хотел бы рассказать о
том, каким образом мы строили и поддерживали процесс разработки и о том, какая была
выбрана технологическая среда для разработки.
В самом начале разработки стала проблема хранения информации в таком виде, чтобы каждый из
участников мог в любое время иметь к ней доступ. Для решения этой проблемы было решено
организовать централизованное хранилище данных на стороннем сервере.
Такую услугу
предоставил сайт assembla.com. Мы зарегистрировались на сайте, нам было выделено некоторое
количество места для хранения данных и мы начали работу. Для связи с хранилищем был выбран
клиент TortoiseSVN. Впоследствии нам пришлось поменять это хранилище на другое из-за малого
объема выделенного места на жестком диске, а также сыграл роль тот факт, что связь с сервером
стала непостоянной. В связи с этим было решено выбрать другое централизованное хранилище
данных, лишенное этих недостатков. Выбор пал на сайт GoogleCode, который используется в
данный момент. Клиент для связи с новым хранилищем остался тем же.
Для обеспечения возможности общения между участниками проекта была использована
программа Skype, которая позволяла устраивать общие конференции. Помимо этого она
обеспечивала возможность показа рабочего стола одному из участников для решения какоголибо вопроса. Для возможности показа рабочего стола всем участникам было использовано ПО
WebEx.
На разных этапах проекта использовались разные подходы. В общем случае был использован
итерационный (waterfall) процесс разработки, т.е. сбор требований - архитектура \ дизайн разработка - тестирование - запуск - поддержка. При этом с самого начала решили пойти по
классическому RUP - большие этапы, работа четко распределена в команде. Технология себя не
оправдала в силу различных причин и специфики работы в команде. Были существенные простои,
команда не выдавала требуемый результат к срокам, и стало понятно, что необходимо перейти на
более жесткий контроль. На последнем этапе перешли на SCRUM c 3 - 4 совещаниями в неделю и
короткими (недельными) итерациями. Задачи выдавались на неделю, в течение каждой итерации
(недели) четко контролировался прогресс, что позволяло оперативно отслеживать ход проекта и,
соответственно, вносить необходимые корректировки в планы.
Для реализации серверной части системы было решено использовать технологию Java, а
клиентскую часть реализовать с использованием технологии Adobe Flex.
Выбор именно этой связки обусловлен такими факторами, как:
Кроссплатформенность – возможность установки и использования системы на различных
платформах, таких как windows или linux.
Кросс-браузерность – возможность сайта, в нашем случае, системы отображаться и выглядеть во
всех популярных браузерах одинаково.
Открытые свободные технологии, позволяющие значительно снизить стоимость разработки
системы
Простота разработки – выбранные технологии не являются закрытыми и существует большая
библиотека документации.
Надежность. (все это в слайд)
Для реализации системы были выбраны следующие технологии (слайд)
(Слайд с технологиями, рассказать о парочке из них)
Java — объектно-ориентированный язык программирования, разработанный компанией Sun
Microsystems. Приложения Java обычно компилируются в специальный байт-код, поэтому они
могут работать на любой виртуальной Java-машине (JVM) независимо от компьютерной
архитектуры.
Apache Tomcat 6
Открытый свободный сервер приложений для Java. Очень просто в настройке и предъявляет
очень низкие требования к аппаратному обеспечению сервера.
В качестве среды разработки использовалось открытое свободное ПО Eclipse.
А теперь я перейду к рассказу о своей индивидуальной работе.
В разработанной архитектуре моей подзадачей стала разработка и программная реализация
подсистем инспектора и управления нормативными документами. Задачи инспектора можно
увидеть вот на этом плакате (перечислить). Для реализации этих задач была разработана
структура данных, (на слайде предоставлена часть структуры). Но я хотел бы остановить ваше
внимание на разработке экранов подсистемы. Изначально все экраны делались только для
разработчиков, то есть, для нас, чтобы проводить тестирование разработанных сервисов. В
дальнейшем разбиение экранов делалось в идеологии "от пользователя". Т.е. экраны системы
были распределены и сгруппированы таким образом, чтобы каждый пользователь в рамках своих
ежедневных действий совершал минимальное количество переходов и смен уровня. Т.е. чтобы
для каждого пользователя "дорога" от главного экрана системы до очередной часто выполняемой
им функции была минимальна.
Помимо этого, при группировке экранов использовалась логика функциональных разделов - т.е.
чтобы переходы между сущностями системы были логичны. Т.е. если у группы есть курс - есть
ссылка из группы в этот курс.
В заключение я хотел бы отметить