VI Международная студенческая научная конференция Студенческий научный форум - 2014

Введение

В настоящее время большое число студентов получают неудовлетворительные оценки и не в срок сдают сессии из-за неправильного подхода к планированию своей учебной работы. Кроме того, в связи с распространением модульно-рейтинговых систем, проблема планирования учебного процесса становится еще более острой.

Причин этому может быть множество, но основными из них являются:

1) Отсутствие возможности у студентов оценить весь объем работ на учебный период (модуль, семестр, курс).

2) Отсутствие возможности быстрой коммуникации между студентом и преподавателем.

3) Недостаточный контроль сроков сдачи работ студентами со стороны самих студентов и преподавателей.

Следствием этого зачастую является отставание по учебе, перегрузки в конце семестра (модуля).

Кроме того, преподавателю, в связи с растущими нагрузками, бывает сложно оценить учебную деятельность студента в отдельно взятом периоде (модуль, семестр, курс, все обучение), что может повлиять на объективность его оценки.

Разрабатываемая система помогает решить эти проблемы, а так же обеспечить возможность отследить весь ЖЦ учебных работ студента по дисциплине. Система позволит как студенту, так и преподавателю анализировать деятельность, оценивать возможности и потенциал студента. Кроме того, она позволяет привить студентам навык работы в коллективах разработчиков, приучить их к планированию работы на основании жизненного цикла продукта.

Процесс практического обучения

Рисунок 1 – IDEF0 диаграмма процесса управления конфигурацией

На рисунке 1 изображена диаграмма IDEF 0 управления конфигурацией студенческих работ. Преподаватель проводит управление конфигурацией согласно регламенту и исходя из информации об учебной группе и об изменениях. По завершению управления предоставляет отчет.

Рисунок 2 – IDEF0 диаграмма, декомпозиция процесса управления конфигурацией

На рисунке 2 представлена декомпозиция IDEF0 диаграммы процесса управления конфигурацией. Она отражает весь жизненный цикл студенческих работ, от их планирования и идентификации, до верификации и аудита. На рисунках 3-7 представлена IDEF3 декомпозиция каждого этапа управления конфигурацией.

Рисунок 3 – IDEF3 декомпозиция процесса “Произвести планирование”

Рисунок 4 – IDEF3 декомпозиция процесса “Произвести идентификацию”

Рисунок 5 – IDEF3 декомпозиция процесса “Осуществить контроль объекта конфигурации”

Рисунок 6 – IDEF3 декомпозиция процесса “Произвести учет статуса конфигурации”

Рисунок 7 – IDEF3 декомпозиция процесса “Осуществить верификацию и аудит”

Описание разрабатываемого продукта

Разрабатываемый продукт представляет собой веб-приложение, позволяющее значительно упростить коммуникацию между студентом и преподавателем, а так же обеспечить более быстрый обмен данными.

Пользователи системы разделены на 3 группы:

1. Студенты – пользователи получающие и выполняющие задания

2. Преподаватель – как правило 1 пользователь, проверяющий задания, ставящий за их выполнение оценки.

3. Администратор – также 1 пользователь, осуществляющий тех. обслуживание и доработку системы.

Разрабатываемая система представляет собой веб-приложение, разработанное на базе CMS Drupal 7.

Неавторизованному пользователю доступна только форма авторизации и форма регистрации.

В случае успешной авторизации интерфейс генерируется в зависимости от роли пользователя (преподавателю – интерфейс преподавателя, студенту – интерфейс студента и т. д.).

В случае регистрации – учетная запись будет неактивна до того момента, пока ее не утвердит преподаватель или администратор.

Группа пользователей – администраторы

Рисунок 8 – Use-Case диаграмма группы пользователей администраторы

Данная группа после авторизации получает полные права в системе. Она может производить настройку, доработку системы или ее частей, а так же производить любые действия с учетными записями пользователей (добавлять, редактировать, утверждать, удалять и т.д.). На рисунке 8 представлена Use Case диаграмма данной группы пользователей.

Группа пользователей – преподаватели

Рисунок 9 – Use Case диаграмма группы пользователей преподаватели

Преподаватели после авторизации получают возможность добавления заданий для студентов. Весь список заданий рекомендуется формировать до начала учебного семестра.

Кроме того, преподаватели утверждают учетные записи студентов, после их регистрации.

В процессе обучения, преподаватели имеют возможность проверять отправленные студентами работы, ставить оценки или отправлять работы на доработку.

При необходимости преподаватель может посмотреть различные срезы статистики или активность какого-либо студента.

Возможности преподавателя в системе представлены на диаграмме (рисунок 9).

Группа пользователей – студенты

Рисунок 10 – Use Case диаграмма группы пользователей студенты

После авторизации, студенты могут получить задание. После его выполнения – отправить его на проверку. В случае отсутствия недочетов – посмотреть оценку и комментарии преподавателя. В противном случае – получить замечания преподавателя, доработать работу и повторно отправить ее на проверку. Use Case диаграмма представлена на рисунке 10.

Структура базы данных разрабатываемого ПО

Рисунок 11 – ER диаграмма базы данных разрабатываемого ПО

На рисунке 11 представлена ER диаграмма (логическая схема) разрабатываемого ПО. Диаграмма отображает функциональную часть БД (без вспомогательных таблиц).

Задачи группируются в проекты, каждой задаче назначается ожидаемый результат. Студенты прикрепляют к задачам полученные результаты, а преподаватель их оценивает и делает замечания. В случае, если полученный результат не удовлетворяет каким-либо требованиям, преподаватель оценивает его как неудовлетворительный и отправляет на доработку. Затем студент прикрепляет следующий результат. Так продолжается до тех пор пока задание не будет выполнено корректно.

Разработанная база данных позволяет хранить всю историю изменения конфигурации студенческих работ на протяжении всего их жизненного цикла. Эти данные будут использованы для генерации различных отчетов, а так же для ведения статистики по совместной работе студентов и преподавателей.

Пример интерфейса программы

Рисунок 12 – пример интерфейса программы

На рисунке 12 изображен интерфейс добавления задачи на этапе планирования в работающем прототипе программы.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Международный стандарт ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes»

2. Липаев В.В. Сопровождение и управление конфигурацией сложных программных средств. - М.: СИНТЕГ, 2006. - 372 с.

3. Donello J. F. Theory and practice: Learning content management systems / Donello J. F. // E-learning magazine. – 2002.

4. «JavaScript: Подробное руководство (Definitive Guide)», (электронный ресурс), / режим доступа: http://javascript.ru/book/definitiveguide

5. «jQuery API Documentation», (электронный ресурс), / режим доступа: http://api.jquery.com

6. «PHP, MySQL и другие веб-технологии», (электронный ресурс), / режим доступа: http://www.php.su

Код для цитирования: Скопировать