В данной работе решаются задачи создания автоматизированных систем поддержки и управления учебной и научно-исследовательской деятельности (АС УиНИД), проводится разработка такой системы для обеспечения качества подготовки магистров и аспирантов в соответствии с федеральными государственными образовательными стандартами третьего поколения (ФГОС3) и формирования «паспорта молодого специалиста».
Проведенный анализ существующих отечественных и зарубежных АС поддержки и управления УиНИД показал, что на данный момент такие системы не поддерживают возможности расчета рейтинга компетентности исследователя, т.е. не позволяют применить компетентностный подход к управлению эффективностью процесса подготовки исследователей [1; 7]. На основании результатов анализа были определены следующие характерные особенности систем поддержки и управления УиНИД.
- Географическая удаленность пользователей друг от друга.
- Наличие как локальных групп пользователей, так и распределенных (задача кластеризации данных).
- Доступность системы для пользователей 24 часа в день в течение 7 дней в неделю.
- Необходимость интеграции с большим количеством унаследованных приложений.
- Слабая связанность между модулями системы, а также возможность использования локальных модулей расширений, которые не должны приводить к неполадкам в основных модулях системы (отказоустойчивость).
- Команда разработчиков такой системы может находиться ближе к первому уровню модели технологической зрелости CMMI.
Данная модель описывает шкалу из пяти уровней зрелости, основанных на том, насколько последователен коллектив или организация в следовании общим повторяющимся процессам при выполнении своей работы. Первый, нижний уровень шкалы СMMI описывает команды без повторяющихся процессов, где большая часть процессов хаотична и сумбурна, команда исполнителей разрозненна, проекты двигаются и реализуются отдельными самостоятельными инициаторами. Верхний, пятый уровень шкалы, описывает команды, использующие формальные, повторяющиеся процессы. Такие команды собирают метрики для непрерывного улучшения своих процессов, а также на регулярной основе ищут творческие методы, позволяющие повысить эффективность своей работы.
Основной целью создания АС является повышение эффективности подготовки исследователей. В качестве критерия для оценки эффективности подготовки исследователей используется сравнение результатов их деятельности до и после внедрения системы. Поэтому необходимо реализовать в АС такие функции, как расчет и мониторинг рейтингов компетенций исследователей, создание структурированного хранилища для всех результатов УиНИД, служащих показателями компетентности исследователя. Для этого необходимо построить модель компетенций, которая свяжет каждую компетенцию с результатами УиНИД, влияющими на её развитие, каждому типу результата должен соответствовать тип задачи в системе. Необходимость интеграции с большим количеством унаследованных приложений и обеспечение слабой связанности между моделями системы делают актуальной разработку системы поддержки и УиНИД как сервис-ориентированного решения (SOA). Сравнительный анализ современных технологий разработки, среди которых комплекс государственных стандартов 34-й серии (ГОСТ34), унифицированный процесс разработки (RUP), экстремальное программирование (XP) и методология разработки сервис-ориентированных систем (MSOAM), показал, что наиболее полно учесть характерные особенностей АС УиНИД позволяют технологии ГОСТ34, RUP и MSOAM. Результаты анализа представлены на рис. 1.
Рис. 1. Покрытие характерных особенностей специализированных приложений сферы науки технологиями разработки АС.
По оси абсцисс расположены характерные особенности. По оси ординат приведены экспертные оценки. Оценка «0» означает, что данная технология не ориентирована на удовлетворение особенности. Оценка «1» означает, что технология позволяет удовлетворить особенность. Оценка «2» означает, что технология с высокой степенью гарантирует удовлетворение особенности.
На основании характерных особенностей АС УиНИД был предложен комплексный критерий выбора технологии создания таких АС, содержащий следующие подкритерии. Технология должна поддерживать: различные типы требований к АС (1); возможность визуального моделирования (2); проектирование сервис-ориентированных архитектур (3); возможность использования итерационной разработки для создания АС (4); команду ролей исполнителей проекта (5). Таблица 1 и рис. 2 содержат результаты покрытия комплексного критерия технологиями ГОСТ34, RUP и MSOAM. Значение «0» в таблице означает, что соответствующая технология не удовлетворяет критерию. Значение «1» означает, что соответствующая технология частично удовлетворяет критерию. Значение «2» означает, что данная технология полностью удовлетворяет критерию.
Таблица 1 - Покрытие критериев создания систем АС УиНИД существующими технологиями
|
Технология/Критерий |
1 |
2 |
3 |
4 |
5 |
|
ГОСТ34 |
2 |
0 |
0 |
2 |
0 |
|
RUP |
1 |
2 |
1 |
2 |
2 |
|
MSOAM |
1 |
1 |
2 |
2 |
0 |
Рис. 2. Удовлетворение критериев АС УиНИД технологиями разработки ПО.
Результаты покрытия позволяют сделать вывод, что для полного удовлетворения комплексного критерия необходимо создать новый метод автоматизированной разработки АС УиНИД, в основе которого будет лежать тройка технологий: ГОСТ34, RUP, МSOAM - и компетентностный подход к определению требований пользователей [4].
За основу структуры основных этапов выбран ГОСТ 34.601-90 [5], который был расширен применением технологий визуального моделирования и определением ролей согласно технологии RUP; использованием методики сервис-ориентированного проектирования и разработки MSOAM; использованием компетентностного подхода к определению требований пользователей АС (рис. 3). Префиксы перед названиями этапов определяют технологии, применяемые для выполнения работ этапов. Для каждого этапа построено формальное описание в виде потока работ. Описание включает: заданную последовательность работ, входные и выходные данные каждой работы, используемые инструментальные средства, бизнес-правила выполнения работ, роли исполнителей. Рассмотрим в качестве примера описание двух первых этапов.
Рис. 3. Описание метода автоматизированной разработки АС УиНИД на верхнем уровне.
Первый этап «Формирований требований к АС» описан в виде потока работ и представлен на рис. 4. Для выполнения работ этапа применяются технологии RUP, ГОСТ34 и компетентностный подход. Результатом выполнения этапа является формализованное описание объекта автоматизации и требований пользователей к АС. На первом шаге этапа проводится обследование объекта и обоснование необходимости создания АС. Обследование проводит исполнитель роли «Системный Аналитик». По результатам обследования строится диаграмма целей создания АС. На втором шаге выполняется анализ компетенций исследователя. На основании федеральных государственных образовательных стандартов третьего поколения (ФГОС3), профессиональных и отраслевых стандартов определяются компетенции, которыми должен обладать исследователь. С помощью предметно-ориентированной среды (ПОС) строится модель компетенций исследователя [2]. Шаг выполняется исполнителем с ролью «Работник Управления». Под ПОС понимается пакет программных продуктов, позволяющих оперировать с объектами определенного класса и отношениями между ними согласно их определению [3]. Такая среда должна обеспечивать наглядное представление объектов, их свойств и отношений, позволяя провести апробацию построенной модели.
Рис. 4. Описание этапа «Формирование требований к АС».
В данном случае ПОС используется как средство автоматизации, которое позволяет сократить трудозатраты на построение моделей компетенций в четыре раза. На третьем шаге для каждой компетенции исследователя определяется список развивающих её процессов УиНИД. В результате выполнения шага каждая компетенция взвешивается развивающими её процессами и учебными элементами. Шаг выполняется с помощью ПОС исполнителем роли «Научный Руководитель».
На четвертом шаге этапа проводится визуальное моделирование процессов в виде потока работ. На пятом шаге моделируются объекты процессов, их типы данных и состояния. Оба шага выполняются с помощью инструмента для визуального моделирования Enterprise Architect исполнителем роли «Системный Аналитик». Результаты проведенного моделирования обрабатываются на шестом шаге этапа, где определяются числовые характеристики для каждого описанного процесса. Эти числовые характеристики являются измеряемыми показателями роста уровня компетентности. Исполнитель роли «Научный Руководитель» вносит показатели компетентности в модель компетенций, используя ПОС.
На седьмом шаге исполнитель роли «Научный Руководитель» взвешивает элементы модели компетенций, используя алгоритм оценки компетенций, в основе которого лежит методика решения многокритериальных задач Т. Саати [6]. В результате взвешивания элементов модели для каждого элемента определяется аддитивная целевая функция. Значение целевой функции является рейтингом элемента модели. Таким образом может быть рассчитан рейтинг отдельной компетенции, группы компетенций или общий рейтинг компетентности. На восьмом шаге исполнителем роли «Системный Аналитик» проводится визуальное моделирование ролей пользователей АС. На последнем шаге этапа на основе построенных моделей «Системным Аналитиком» проводится формирование и оформление требований пользователей к АС.
Второй этап «Разработка концепции АС» представлен в виде потока работ на рис. 5. Для выполнения работ этапа используются технологии ГОСТ34 и MSOAM. Результатом выполнения этапа являются: решение о продолжении или прекращении разработки АС, выбор архитектуры системы и платформы разработки. Первый шаг «Детальное изучение объекта автоматизации» проводится исполнителем роли «Системный Аналитик». В результате выполнения шага определяются характерные особенности системы, проводится поиск путей и оценка возможности реализации требований пользователя.
Рис. 5. Описание этапа «Разработка концепции АС».
На втором шаге проводится оценка различных вариантов архитектуры с точки зрения требований пользователя и идентифицированных характерных особенностей АС. Этот шаг позволяет обосновать выбор SOA либо причины, по которой должна быть использована другая архитектура. После этого проводится выбор платформы разработки для программного обеспечения АС. Выбор платформы разработки может включать определение: языков и технологий разработки, протоколов взаимодействия сервисов, промежуточного программного обеспечения и серверов приложений. Оба шага выполняются исполнителем роли «Архитектор».
На последнем шаге ролью «Руководитель проекта» проводится оценка эффектов, получаемых от системы. Принимается решение о разработке.
Формальное описание метода автоматизированной разработки позволило провести разработку и внедрение автоматизированной системы поддержки и управления УиНИД для факультета управления и экономики НИЯУ МИФИ. Использование ПОС для автоматизированного построения моделей компетенций позволило построить формальное описание модели компетенций исследователя и провести семантическое эквивалентирование модели компетенций и моделей системы. Использование предложенного метода автоматизированной разработки позволит сократить время и трудоёмкость разработки не менее чем в 1,5 раза по сравнению с ОСТ 4.071.030.
(Работа выполнена при поддержке ФЦП «Научные и научно-педагогические кадры инновационной России» на 2009-2013 годы).
(Work performed under FTP "Scientific and scientific-pedagogical personnel of innovative Russia" for the years 2009-2013).
Рецензенты
Киреев Сергей Васильевич, доктор физико-математических наук, профессор кафедры № 37, Национальный исследовательский ядерный университет «МИФИ», г. Москва.
Лисов Олег Иванович, доктор технических наук, профессор кафедры информатики и программного обеспечения вычислительных систем, Национальный исследовательский университет «МИЭТ», г. Москва.