Реферат: Управление требованиями для разработки и эксплуатации обучающей системы TSI

Б.Мишнев, Л.Герасимова

Кафедра программного обеспечения компьютерных систем Институт транспорта и связи, Рига, Латвия

Введение

Многие вузы самостоятельно занимаются разработкой сетевых образовательных средств, в том числе, сетевых курсов, адаптируя их под свой профиль и имеющуюся материально-техническую базу. Разработка и использование технологических систем в образовании предполагает наличие системы стандартов и соглашений, адекватных условиям их применения. Архитектура среды обучения для таких систем формируется стандартами на интерфейсы, форматы, протоколы обмена информацией с целью обеспечения мобильности, интероперабельности, стабильности, эффективности и других положительных качеств, достигаемых при создании открытых систем [Башмаков А., 2003].

Статистика показывает, что наиболее часто встречающиеся серьёзные проблемы при разработке систем связаны с неполными требованиями и спецификациями проектов, а также с управлением изменениями требований клиента. Исследования групп Стендиша и организации ESPITI показывают, что проблемы требований, судя по всему, превосходят остальные в плане риска неполадок, которые они вызывают при разработке систем. [Леффенгуэл Д., 2002]. Ошибки требований занимают первое место среди оставшихся недоработок и составляют примерно одну треть всех неустранённых дефектов.

В настоящей работе описываются результаты исследования проблемы управления требованиями информационной системы, которая выполняет функции компьютерного средства обучения (КСО) при дистанционном обучении студентов Института транспорта и связи [Misnevs B., 2003].

Методология исследования

Процесс формулирования требований считается одним из самых важных при построении программной системы. Успех проекта зависит от хорошо организованного управления требованиями, поскольку требования к системам программного обеспечения (ПО) неизбежно меняются в процессе разработки [URL 1].

На сегодняшний день основными организациями, ведущими разработки по направлениям информатизации образования и развития отраслевых стандартов являются ADL, AICC, ALIC, ARIADNE, CEN/ISSS, EdNA, DCMI, DCMI, GEM, IEEE, IMS, ISO, PROMETEUS.

Деятельность этих организаций направлена на:

создание концептуальной модели стандартизации в системе открытого образования (IEEE); разработку архитектуры технологических систем в образовании AICC, IMS, ISO/IEC JTC1 SC36;

разработку внутренних стандартов и спецификаций для корпоративного обучения и переподготовки персонала компаний (AICC);

решение задач в области телематики и мультимедиа в образовании для Европейского Сообщества (ARIADNE, PROMETEUS); формирование учебного контента для учебных заведений, ориентированных на Интернет-обучение (проект SCORM).

Наиболее активно развивающейся международной ассоциацией в настоящее время является консорциум IMS Global Learning Consortium. Деятельность консорциума направлена на разработку системы базовых стандартов, описывающих требования к элементам учебного процесса в среде новых образовательных технологий.

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

стандартизация форматов хранение и поиск учебной информации;

стандартизация принципов построения систем управления обучением;

стандартизация форматов обмена данных;

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

стандартизация элементов образовательного контента учебных материалов;

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

Авторы данной работы основывались на следующем понимании процесса формирования требований [Леффенгуэл Д., 2002].

Требование - это возможность, которую должна обеспечивать система; это некое свойство ПО, необходимое пользователю для решения проблемы при достижении поставленной цели; это некое свойство ПО, которым должна обладать система или её компонент, чтобы удовлетворить требования контракта, стандарта, спецификации либо иной формальной документации.

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

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

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

После того, как был определён набор функций и достигнуто соглашение с заказчиком, был сделан переход к определению более конкретизированных требований, которым должно удовлетворять решение, - к требованиям к ПО (Software requirements), согласно которым далее проиходило проектирование и реализация системы.

Реализация системы управления требованиями

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

В таблицах 1-3 приведены результаты анализа проблемы отсутствия штатного компьютерного средства обучения (КСО) для дистанционного образования (ДО) в Институте транспорта и связи (TSI) с точки зрения организации в целом, с точки зрения преподавательского состава и с позиции обучаемого.

Таблица 1. Постановка проблемы с точки зрения TSI.

Таблица 2. Постановка проблемы с точки зрения преподавательского состава.

Таблица 3. Постановка проблемы с позиции обучаемого.

В ходе анализа были выявлены следующие основные категории заинтересованных лиц, которые представлены в табл.4.

Таблица 4. Основные категории заинтересованных в разработке КСО лиц.

Обучаемыми могут быть: студенты; слушатели; гостевые пользователи.

Преподавателями могут быть:

авторы учебных материалов;

дизайнеры курсов;

собственно преподаватели;

фасилитатор (facilitator) - консультант по методам обучения.

Администраторами могут быть:

тьютор (tutor) - специалист по интерактивному предоставлению курсов;

инвигилятор (invigilate) - специалист по методам контроля за результатами обучения, ответственный за организацию и проведение тестов;

администратор электронного деканата;

системный администратор.

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

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

Таблица 5. Ограничения, накладываемые на разрабатываемое КСО.

В процессе моделирования требований к КСО были использованы диаграммы вариантов использования - use case diagrams [Соммервилл И., 2002].

Варианты использования (use-case) - это методика формирования требований, основанная на сценариях (в UML сценарием часто называют экземпляр варианта использования). Для моделирования требований к создаваемому продукту используются диаграммы вариантов использования (use case diagrams). Описание потока событий для варианта использования системы содержится в документе виде Use Сase Specification (спецификация варианта использования). Для создания подобного документа применялся стандартный шаблон, заимствованный из регламента Rational Unified Process - процесс, основанный на прецедентах и использовании интерактивного подхода к разработке ПО.

Для иллюстрации подхода возьмём конкретный вариант использования "Доступ к структурным единицам учебного материала". Нумерация вариантов использования взята из оригинальной документации системы.

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

2.0. Поток событий.

2.1. Основной поток: вариант использования начинает выполняться, когда "обучаемый" желает получить доступ к учебному материалу по соответствующему курсу.

Система предлагает один из вариантов доступа: доступ "через блок содержания", "доступ через указатель", "доступ через словарь", "доступ по ключевому слову".

Если выбрана опция "Доступ через блок содержания", система извлекает и отображает содержание учебного курса (если данные получить нельзя, выполняется поток 2.2.1.), элементы которого ссылаются на соответствующие структурные единицы учебного материала. "Обучаемый" может активизировать вариант использования сначала или выполнить поток "выход".

Если выбрана опция "доступ через указатели", система извлекает список предметных указателей, элементы которого ссылаются на соответствующие структурные единицы учебного материала (если данные получить нельзя, выполняется поток 2.2.2.).

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

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

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

Если выбрана опция "доступ по ключевому слову", система предлагает "обучаемому" ввести ключевое слово (если услуга не предоставляется, выполняется поток 2.2.4.).

Если выбрана опция "выход", то выполнение варианта использования системы завершается.

2.2. Альтернативные потоки

2.2.1. Ошибка извлечения данных о содержании учебных курсов: система сообщает "обучаемому" о том, что в данный момент информация недоступна. Вариант использования активизируется с начала.

2.2.2. Ошибка извлечения данных списка предметного указателя: система сообщает "обучаемому" о том, что в данный момент предметный указатель недоступен или отсутствует. Вариант использования активизируется с начала.

2.2.3. Ошибка извлечения данных из словаря учебного материала: система сообщает "обучаемому" о том, что в данный момент информация недоступна или словарь терминов отсутствует. Вариант использования активизируется с начала.

2.2.4. Ошибка извлечения данных по ключевому слову: система сообщает "обучаемому" о том, что сервис не активизирован (учебный материал не проиндексирован).

Специальные требования: специальные требования не определены.

4.0. Предусловие: перед выполнением варианта использования "обучаемый" должен пройти идентификацию в системе и получить права доступа к соответствующему учебному курсу.

5.0. Постусловия: после выполнения данного варианта использования выполняется вариант использования "Выбор текущего фрагмента учебного материала и передача его для представления пользовательскому интерфейсу (ПИ)".

6.0. Дополнительные замечания: дополнительных замечаний нет.

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

G1. Организация работы с учебным материалом:

G2. Организация работы с учебно-тренировочными задачами:

G3. Управление учебным процессом:

G4. Доступ обучаемого к протоколам его работы.

G5. Настройка КСО.

G6. Поддержка служебных функций КСО.

Каждая группа содержит от двух до двенадцати функций системы (например, F1.1-F1.6 - функции организации работы с учебным материалом и т.д.).

Присваивая функциям различные атрибуты, можно успешно управлять сложностью структуры информации. Существует набор общеупотребительных атрибутов, который применяется в большинстве проектов.

В данной разработке использовались следующие атрибуты: Статус, Приоритет/Полезность, Трудоемкость, Риск, Стабильность, Целевая версия, Назначение, Обоснование.

После того, как были определены функции системы, следующая задача состояла в уточнении спецификации до уровня детализации, пригодного для проведения процессов проектирования, описания программного кода и тестирования. Управление требованиями предполагало обработку большого объема информации о требованиях, поэтому в этом процессе использовалась специально разработанная авторами система баз данных MySQL в среде PHP.

При создании системы управления требованиями особое внимание уделялось механизму верификации требований. Верификация (verification) - постоянно выполняемый процесс проверки того, что каждый шаг разработки является корректным, удовлетворяет потребности последующей деятельности и не является излишним. Одним из методов осуществления постоянного контроля верификационных действий является трассировка (traceability).

Ключевым элементом трассировки является "отношение трассировки" (traceability relationship), определяемое с помощью простой модели, использующей понятия "трассируется к" и "трассируется от". Между этими элементами проекта имеются отношения вида один-ко-многим, многие-к-одному, многие-ко-многим.

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

в матрице трассировки существуют пустые строки - еще не определено требование к ПО, отвечающее функции;

в матрице трассировки существуют пустые столбцы - создано требование к ПО, для которой нет требующей его функции.

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

Помимо проверки матрицы трассировки в данной системе реализованы следующие возможности управления изменениями функций и требований к ним:

Добавление в базу данных новых функций и требований.

Изменение функций и атрибутов функций. Если изменение функции влияет на требования, связанные с этой функцией, существует возможность изменения требований или удаления их.

Удаление функций и требований.

Поиск функций и требований.

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

Сортировка функций и требований по атрибутам.

Реализация методов определения очередности разработки функций КСО.

Разработанное программное обеспечение в настоящее время используется в отделе компьютерных технологий TSI для целей управления развитием системы дистанционного обучения института [Герасимова Л., 2003].

Анализ и оценка качества разработки

Вопросы комплексной оценки качества учебного процесса в вузе ранее уже рассматривались авторами [Kabashkin, I., 1998]. Имеющийся опыт разработки программного обеспечения для целей обучения показывает, что нет особого смысла производить оценку самого программного обеспечения вне того конкретного учебного содержания, для усвоения которого данное программное обеспечение используется. Поэтому, показатели качества КСО предлагается оценивать контекстно по каждому учебному курсу, включенному в КСО в процессе опытной эксплуатации оцениваемого курса. Все замечения по конкретным функциям системы будут фиксироваться и отслеживаться до их устранения с помощью предложенного авторами работы программного обеспечения.

С другой стороны, степень интеграции программных компонентов в КСО может быть различной. Это дает возможность оценить потенциальные возможности КСО. В связи с этим обычно используется классификация КСО по нескольким уровням (классам). Одна из таких классификаций введена в международном стандарте АЕСМА 1000D, посвященном разработке интерактивных электронных технических руководств для авиационных отраслей промышленности.

В соответствии с этой классификацией учебные материалы класса 0 относятся к обычным документам, переведенным в электронный вид (например, с помощью редактора Word) и предназначенным, как правило, для архивации. Класс 1 относится к документам, части которого индексированы и доступны по ссылкам из оглавления. Документы класса 2 - файлы в коде ASCII, внутри которых применена разметка с помощью тегов, что позволяет осуществлять навигацию внутри пособия. Документы класса 3 отличаются тем, что в них применена разметка с помощью языка SGML. Документы классов 0-3 являются линейными в том смысле, что в них, как и в обычных бумажных пособиях, материал излагается последовательно страница за страницей.

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

Исходя из заданных заказчиком требований система дистанционного обучения Института транспорта и связи должна соответствовать классу 4 согласно международному стандарту АЕСМА 1000D. Предложенная авторами и описанная в работе система управления требованиями гарантирует управление реализацией этих требований в процессе разработки и эксплуатации КСО.

Заключение

В работе изложены результаты исследований, проведенных в Институте транспорта и связи (TSI), по автоматизации управления требованиями для системы дистанционного обучения в рамках Intranet TSI. При разработке и последующей эксплуатации системы дистанционного обучения была определена методика и создано опытное программное обеспечение, поддерживающее функцию управления требованиями к этой системе. Рассмотрена постановка проблемы с точки зрения различных пользователей системы дистанционного обучения TSI. Рассмотрены варианты описания требований к системе в терминах Rational Unified Process. Определены базовые функции системы обучения и их атрибуты. Реализация поддержки управления требованиями дистанционной системы обучения TSI выполнена на языке PHP с использованием СУБД MySQL, использование которой должно гарантировать достижение соответствия КСО для системы ДО классу 4 по стандарту АЕСМА 1000D.

Список литературы

[Башмаков А., 2003] Башмаков А., Башмаков И. Разработка компьютерных учебников и обучающих систем. - М.: Информационно-издательский дом "Филинъ", 2003.-616с.

[Леффенгуэл Д., 2002] Леффенгуэл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с англ.- М.: "Вильямс", 2002.-448с.

[Misnevs B., 2003] Misnevs, B., Danilov, P.. Requirements for the TTI e-learning System. Computers in Educations. Transactions of MIPRO HU, Opatija, 2003, pp 28-32.

[СоммервиллИ., 2002] СоммервиллИ. Инженерияпрограммногообеспечения, 6-еизд.:Пер. сангл. - М.: "Вильямс", 2002. - 624 с.

[Kabashkin, I., 1998] Kabashkin, I., Michnev, B., Utehin, G. Using TQM and ISO 9000 Principles in Assuring Education Service Quality. - Journal of Air Transportation World Wide, 1998, vol. 3, N 2, pp. 70-77.

[Герасимова Л., 2003] Герасимова Л. Разработка и исследование спецификаций информационной системы дистанционного обучения ИТС. Научно-практическая и учебно-методическая конференция "Наука и технология - шаг в будущее" Институт транспорта и связи, 13 декабря 2003 года, Рига, Латвия. Программаитезисы, с.24-25.

[URL1] Software Acquisition Capability Maturity Model. (SA-CMM.), Version 1.03, Jack Cooper, Matthew Fisher, CMU/SEI-2002-TR-010, ESC-TR-2002-010, 2002, URL: http://www.sei.cmu.edu/arm/SA-CMM.html.