Для разрабатываемой системы были приняты следующие ограничения, описанные в табл. 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]. Имеющийся опыт разработки программного обеспечения для целей обучения показывает, что нет особого смысла производить оценку самого программного обеспечения вне того конкретного учебного содержания, для усвоения которого данное программное обеспечение используется. Поэтому, показатели качества КСО предлагается оценивать контекстно по каждому учебному курсу, включенному в КСО в процессе опытной эксплуатации оцениваемого курса. Все замечения по конкретным функциям системы будут фиксироваться и отслеживаться до их устранения с помощью предложенного авторами работы программного обеспечения.