Реферат: Управление требованиями для разработки и эксплуатации обучающей системы TSI
В ходе анализа были выявлены следующие основные категории заинтересованных лиц, которые представлены в табл.4.
Таблица 4. Основные категории заинтересованных в разработке КСО лиц.
|
Пользователи |
Другие заинтересованные лица |
|
Обучаемые Преподаватели Администраторы |
Внешние поставщики учебных материалов Команды разработчиков КСО Управляющий проектом КСО |
Обучаемыми могут быть: студенты; слушатели; гостевые пользователи.
Преподавателями могут быть:
авторы учебных материалов;
дизайнеры курсов;
собственно преподаватели;
фасилитатор (facilitator) - консультант по методам обучения.
Администраторами могут быть:
тьютор (tutor) - специалист по интерактивному предоставлению курсов;
инвигилятор (invigilate) - специалист по методам контроля за результатами обучения, ответственный за организацию и проведение тестов;
администратор электронного деканата;
системный администратор.
Ограничения, накладываемые на систему, уменьшают степень свободы, которой мы располагаем при предложении решения. Существуют различные источники ограничений системы: экономические, политические, технические, системные, эксплуатационные, графика и ресурсов.
Для разрабатываемой системы были приняты следующие ограничения, описанные в табл. 5.
Таблица 5. Ограничения, накладываемые на разрабатываемое КСО.
|
Идентификатор |
Описание |
| DС 01 | Версия 1.0. должна быть запущена в производство до 1 апреля 2005 года. |
| DС 02 | При проектировании системы использовать UML - моделирование, ОО - методологии, унифицированный процесс разработки ПО (Unifed Software Development Process). |
| DС 03 | Программное обеспечение должно быть написано на языке PHP и C++. |
| DС 04 | Разрешено использовать закупаемые компоненты ПО. |
| DС 05 | Количество учебных курсов для версии 1.0. - в пределах трех учебных программ. |
| DС 06 | Количество обучаемых - до 500 человек на отдельный курс. |
| DС 07 | Административный и технический персонал - до 25 человек. |
| DС 08 | Количество занятых преподавателей - до 30 человек. |
В процессе моделирования требований к КСО были использованы диаграммы вариантов использования - 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.
