Создание запроса на изменение в рамках обновления функционала системы дистанционного обучения вуза

Анализ процесса управления изменениями информационно-технологического сервиса. Создание запроса на изменение в рамках обновления функционала для системы дистанционного обучения вуза. Описание модуля по оценке уровня сформированных компетенций студентов.

Рубрика Программирование, компьютеры и кибернетика
Вид статья
Язык русский
Дата добавления 03.06.2016
Размер файла 75,3 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

СОЗДАНИЕ ЗАПРОСА НА ИЗМЕНЕНИЕ (RFC) В РАМКАХ ОБНОВЛЕНИЯ ФУНКЦИОНАЛА СИСТЕМЫ ДИСТАНЦИОННОГО ОБУЧЕНИЯ ВУЗА

Карманова Екатерина Владимировна

ФГБОУ ВПО "Магнитогорский государственный

технический университет"

магистрант кафедры прикладной информатики

Аннотация

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

Ключевые слова: библиотека инфраструктуры информационных технологий, запрос на изменение, мониторинг компетенций студентов, система дистанционного обучения вуза, управление изменениями

На современных предприятиях рано или поздно возникает потребность в обновление/изменении используемых ИТ-сервисов, это связанно и с изменениями рынка, где работает данное предприятие, изменениями взглядов потребителей, с эволюцией программного и аппаратного обеспечения, изменениями в законодательстве, желанием повысить качество услуг, либо просто устранить какую-либо проблему. В действительности, возникновение потребностей в изменениях ИТ - сервисов и их реализация с учетом рисков являются необходимым компонентом совершенствования и улучшения качества функционирования всей ИТ инфраструктуры предприятия. Однако если изменения должным образом не контролируются, то часто в результате их проведения могут возникать сбои и конфликты в нормальном предоставлении услуг. Для обеспечения контроля над изменениями можно воспользоваться рекомендациями библиотеки инфраструктуры информационных технологий или ITIL (IT Infrastructure Library). ITIL представляет собой наиболее известную базу знаний в области управления услугами во всем мире и отражает фундаментальные основы ведущих мировых практик в IT-области. За обеспечение контроля над изменениями в ITIL отвечает ряд процессов преобразования услуг (Service Transition): Управление изменениями, Управление сервисными активами и конфигурациями и управления релизами и развертыванием.

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

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

На рисунке 1 представлено описание процесса Управления изменениями в частности, какие входные данные необходимы, что следует сделать и что будет на выходе.

Рис. 1. Процесс Управления изменениями

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

Запрос на изменение - формальное предложение на выполнение изменения. Запрос на изменение включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде.

У запросов на Изменение множество причин и источников: требуется решение, указанное в отчете об инциденте или проблеме; неудовлетворенность пользователя или заказчиком уровнем обслуживания; изменение требований или направления бизнеса; нововведения или изменения в законодательстве и др.

Следующие данные должны быть включены в форму RFC:

· Порядковый номер RFC (+ ссылка на номер отчета о проблемы, если таковая имеется)

· Описание и идентификация элемента/ов, который следует изменить - опишите предлагаемое изменение

· Причина Изменения - в краткой форме укажите его причину изменении

· Последствия в случае, если изменение не будет внедрено - укажите, какие последствия/влияние будет иметь непринятие предложенного изменения для проекта

· Версия изменяемого элемента

· Название, местоположение и телефонный номер человека, предлагающего Изменение

· Дата, когда было предложено изменение

Далее менеджером изменений заполняются следующие данные по изменению:

· Приоритет изменения - Высокий/средний/низкий

· Оценка влияния и ресурсов

· Рекомендации САВ, когда это уместно

· Авторизующая подпись

· Дата и время авторизации

· Планируемое внедрение - идентификация Релиза или даты и времени

· Местоположение плана Релиза/внедрения

· Сведения о том, кто разрабатывает/внедряет изменения

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

· Действительные дата и время внедрения

· Дата проведения анализа

· Результаты анализа

· Оценка и управления рисками

· Влияние на план непрерывности бизнеса и на план действий в чрезвычайных ситуациях

· Статус RFC - «обработан», «оценен», «отклонен», «принят», «в ожидании» [1, c. 229].

Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Все полученные запросы на изменения должны быть зарегистрированы и для каждого изменения должна быть создана запись об изменении (change record).

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

После регистрации запроса на изменение (RFC) Управление изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных запросов. Такие запросы отклоняются с объяснением причин. Сотруднику, направившему запрос, всегда должна быть предоставлена возможность для защиты своего запроса.

Опишем содержание запроса на изменение на примере предложения от преподавателя вуза на предмет разработки нового функционала для системы дистанционного обучения (СДО) университета. Однако прежде представим состояние СДО на текущий момент.

СДО была разработана в 2011 году сотрудниками отдела образовательной политики и менеджмента качества образования ФГБОУ ВПО Магнитогорского государственного университета (реорганизованного в 2013 году в ФГБОУ ВПО «Магнитогорский государственный технический университет») и продолжает функционировать в новом реорганизованном университете.

На сегодняшний день систему поддерживает один инженер-программист управления информационных технологий и АСУ в функциональные обязанности которого входят администрирование системы, разработка дополнительного функционала системы, а также два сотрудника центра электронных образовательных ресурсов и дистанционных образовательных технологий.

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

информационный технологический функционал дистанционный

Таблица 1 - Запрос на изменение

Порядковый номерRFC

Описание и идентификация элемента/ов, который следует изменить

Изменение отчетов об успеваемости студентов, обучающихся с использованием СДО университета, а именно: разработка дополнительно к электронной зачетной книжки студента электронного журнала компетенций.

Модуль должен обладать следующими функциональными возможностями:

· сканирование/диагностика уровня сформированности компетенций;

· выявление динамики уровня сформированности компетенций и составлении прогноза на перспективу - рекомендации по составлению индивидуальным траекторий;

· сравнение уровня сформированности между студентами.

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

Причина Изменения

С внедрением новых ФГОС ВПО образовательная политика и практика работы всех высших учебных заведений перестраивается в соответствии с компетентностным подходом. В основе этих изменений лежит идея о переходе к оценке уровня подготовки выпускника вуза в форме измерения его компетенций. Согласно ФГОС ВПО, высшее учебное заведение обеспечивает качество подготовки студентов в т.ч. путем «разработки объективных процедур оценки уровня знаний и умений обучающихся, компетенций выпускников». Проблемой современных вузов по-прежнему остается организация процесса измерений компетенций, которые необходимы, согласно п.8.1. раздела VIII «Оценка качества освоения основных образовательных программ» ФГОС ВПО, с использованием автоматизированных систем и ресурсов вуза.

Последствия в случае, если изменение не будет внедрено

Отсутствие возможности объективного контроля за уровнем формируемых компетенций студентов в СДО; некорректность предоставляемых данных об успеваемости студентов в рамках ФГОС ВПО; сложный, дорогостоящий и трудоемкий анализ уровней сформированных компетенций у студентов.

Версия изменяемого элемента

1

Название, местоположение и телефонный номер человека, предлагающего Изменение

магистрант кафедры прикладной информатики ФГБОУ ВПО «Магнитогорский государственный технический университет»

Дата, когда было предложено изменение

10.09.2014

Таким образом, в качестве заключения, хотелось бы отметить следующее: несмотря на кажущуюся бюрократизацию, опыт показывает, что две трети серьезных инцидентов происходят именно при внесении изменений в ИТ-инфраструктуру, и все из-за того, что изменения эти не документируется и еще реже планируется. Все изменения, вносимые в ИТ-инфраструктуру предприятия, должны быть спланированы и задокументированы. Данная процедура должна касаться не только бизнеса, но и других предприятий со сложной ИТ-инфраструктурой, к примеру, как описано выше, в высших учебных заведениях. В настоящее время вузы все больше стараются автоматизировать не только процессы управления финансами, кадрами, ресурсами, но и внедрять ИТ-сервисы в учебный процесс, к примеру, реализовывать электронное, дистанционное обучение, что требует больших вложений и, несомненно, имеет свои риски. Однако если правильно организовать процесс, то любые изменения пройдут безболезненно.

Библиографический список

1. ITIL - Поддержка услуг / пер. с англ. - М: «Ай-Теко». - 2006. - 416 с. [Электронный ресурс]. URL: http://greendail.ru/book/36 (дата обращения: 20.10.2014).

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.