Б.Мишнев, Л.Герасимова
Кафедра программного обеспечения компьютерных системИнститут транспорта и связи, Рига, Латвия
Введение
Многиевузы самостоятельно занимаются разработкой сетевых образовательных средств, втом числе, сетевых курсов, адаптируя их под свой профиль и имеющуюсяматериально-техническую базу. Разработка и использование технологических системв образовании предполагает наличие системы стандартов и соглашений, адекватныхусловиям их применения. Архитектура среды обучения для таких систем формируетсястандартами на интерфейсы, форматы, протоколы обмена информацией с цельюобеспечения мобильности, интероперабельности, стабильности, эффективности идругих положительных качеств, достигаемых при создании открытых систем[Башмаков А., 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/IECJTC1 SC36;
разработкувнутренних стандартов и спецификаций для корпоративного обучения ипереподготовки персонала компаний (AICC);
решениезадач в области телематики и мультимедиа в образовании для ЕвропейскогоСообщества (ARIADNE, PROMETEUS); формирование учебного контента для учебныхзаведений, ориентированных на Интернет-обучение (проект SCORM).
Наиболееактивно развивающейся международной ассоциацией в настоящее время являетсяконсорциум IMS Global Learning Consortium. Деятельность консорциума направленана разработку системы базовых стандартов, описывающих требования к элементамучебного процесса в среде новых образовательных технологий.
Множествосоздаваемых спецификаций консорциума включает в себя:
стандартизацияформатов хранение и поиск учебной информации;
стандартизацияпринципов построения систем управления обучением;
стандартизацияформатов обмена данных;
стандартизацияинформации об участниках учебного процесса;
стандартизацияэлементов образовательного контента учебных материалов;
стандартизацияформатов и принципов разработки учебных материалов.
Авторыданной работы основывались на следующем понимании процесса формированиятребований [Леффенгуэл Д., 2002].
Требование- это возможность, которую должна обеспечивать система; это некое свойство ПО,необходимое пользователю для решения проблемы при достижении поставленной цели;это некое свойство ПО, которым должна обладать система или её компонент, чтобыудовлетворить требования контракта, стандарта, спецификации либо инойформальной документации.
Требованияследует записывать так, чтобы они были доступны для ознакомления — это можетбыть документ, модель, база данных.
Задачалюбого проектирования — в рамках отведённого срока и бюджета разработатькачественное ПО, удовлетворяющее реальные потребности клиентов.
Функция- предоставляемое системой обслуживание для удовлетворения одной или несколькихпотребностей заинтересованных лиц.
Послетого, как был определён набор функций и достигнуто соглашение с заказчиком, былсделан переход к определению более конкретизированных требований, которымдолжно удовлетворять решение, — к требованиям к ПО (Software requirements),согласно которым далее проиходило проектирование и реализация системы.
Реализация системы управления требованиями
Исходяиз описанного выше подхода для создания качественного программного приложениянеобходимо вначале описать проблему, которая должна быть решена, а затемопределить требования к создаваемой системе. Анализ проблемы — это процессосознания реальных проблем и потребностей пользователя и предложений решений дляудовлетворения этих потребностей. Цель анализа проблемы — добиться лучшегопонимания решаемой проблемы до начала разработки.
Втаблицах 1-3 приведены результаты анализа проблемы отсутствия штатногокомпьютерного средства обучения (КСО) для дистанционного образования (ДО) вИнституте транспорта и связи (TSI) с точки зрения организации в целом, с точкизрения преподавательского состава и с позиции обучаемого.
Таблица1. Постановка проблемы с точки зрения TSI.
Проблема Отсутствие ПО для организации ДО в TSI; отсутствие технологии определения требований для приобретения и разработки КСО для ДО TSI; необходимость эффективной разработки КСО в условиях бурного развития научно-технического процесса и усиления тенденций перехода к нетрадиционным технологиям образования
воздействует на администрацию TSI, акционеров TSI
результатом чего является недостаточное качество организации учебного процесса, а также недостаток возможностей для роста доходов и прибыльности за счет увеличения количества студентов-заочников
выигрыш от
внедрения КСО может состоять в следующем:
• повышение уровня контроля организации образовательного процесса;
• рост числа обучаемых;
• сокращение расходов на содержание учебных аудиторий и общежитий.
• рост доходов и прибыльности;
• повышение конкурентоспособности на рынке заочного образования;
• повышение престижа TSI.
Таблица2. Постановка проблемы с точки зрения преподавательского состава.
Проблема Отсутствие КСО на базе новых технологий; отсутствие свободного владения специальными знаниями в области современных технологий для разработки содержания учебных курсов, а также сложности обеспечения в ходе учебного процесса активного взаимодействия с обучаемым на базе современных коммуникационных технологий
воздействует на преподавателей
результатом чего является неэффективная организация труда преподавательского состава и слабая обратная связь преподавателя с обучающимися
выигрыш от
диверсификации и усложнения преподавательской деятельности:
• специализация преподавательсткой деятельности — организация разделения труда преподавателя с целью повышения качества и эффективности обучения;
• эффективное управление учебно — познавательной деятельностью обучающихся, а также систематический контроль знаний обучающихся;
• возрастание активной роли самого обучаемого в учебном процессе;
повышение вознаграждения за преподавательскую деятельность.
Таблица3. Постановка проблемы с позиции обучаемого.
Проблема Отсутствие полноценной возможности получения непрерывного, самостоятельного, удаленного и открытого доступа к образованию с использованием новых информационных технологий
воздействует на обучаемых
результатом чего является отсутствие возможности получения желаемого уровня знаний или формы образования
выигрыш от
Внедрения КСО:
• использование высококачественных учебных программ, материалов, информационных ресурсов;
• возможность получения непрерывного образования;
• совмещение производственной деятельности и обучения;
• возможность освоения образовательной программы в индивидуальные сроки;
• обучение в условиях географически изолированных образовательных ресурсов;
• отсутствие или существенного сокращение расходов на переезды к месту учёбы;
• расширение спектра потребления образовательных услуг.
Входе анализа были выявлены следующие основные категории заинтересованных лиц,которые представлены в табл.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 СaseSpecification (спецификация варианта использования). Для создания подобногодокумента применялся стандартный шаблон, заимствованный из регламента RationalUnified 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).
Ключевымэлементом трассировки является «отношение трассировки» (traceabilityrelationship), определяемое с помощью простой модели, использующей понятия«трассируется к» и «трассируется от». Между этимиэлементами проекта имеются отношения вида один-ко-многим, многие-к-одному,многие-ко-многим.
Послетого, как были заданы все известные отношения, обязательным действием сталапроверка матрицы трассировки на наличие двух возможных индикаторов ошибки:
вматрице трассировки существуют пустые строки — еще не определено требование кПО, отвечающее функции;
вматрице трассировки существуют пустые столбцы — создано требование к ПО, длякоторой нет требующей его функции.
Проверкаматрицы трассировки производится автоматически по запросу пользователя. Приобнаружении «дыры» в отношениях нужно вернуться к исходному наборутребований к продукту и связанным с ними программным требованиям (прецедентам).
Помимопроверки матрицы трассировки в данной системе реализованы следующие возможностиуправления изменениями функций и требований к ним:
Добавлениев базу данных новых функций и требований.
Изменениефункций и атрибутов функций. Если изменение функции влияет на требования,связанные с этой функцией, существует возможность изменения требований илиудаления их.
Удалениефункций и требований.
Поискфункций и требований.
Ведениеконтрольных журналов изменений. В истории изменений в хронологическом порядкепредставляется последовательность всех предшествующих изменений данноготребования или функции с фиксацией автора изменения, даты и времени изменения.
Сортировкафункций и требований по атрибутам.
Реализацияметодов определения очередности разработки функций КСО.
Разработанноепрограммное обеспечение в настоящее время используется в отделе компьютерныхтехнологий 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с.
[MisnevsB., 2003] Misnevs, B., Danilov, P… Requirements for the TTIe-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. UsingTQM and ISO 9000 Principles in Assuring Education Service Quality. — Journal ofAir 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: www.sei.cmu.edu/arm/SA-CMM.html.