· классификаторы.
· проекции.
Классификаторы описывают состав понятий каждого элемента, их атрибуты и иерархически упорядочивает элементы. На рисунке 1.2 приведен классификатор.
Рис. 1.2 Классификатор
Проекции устанавливают связи между понятиями, которые входят в классификаторы. На рисунке 1.3 представлены способы установления связей между элементами, которые используются в системе.
Рис. 1.3 Схема формирования связей между классификаторами в проекции
1.3 Выводы к первой главе
Учитывая перечисленные документы сферы образования и сферы труда и возможности аналогов можно сделать следующие выводы:
1. Документы ОПОП, ПООП, РПД, ФГОС и ПС взаимосвязаны. Основой для формирования документов ОПОП, ПООП, РПД является сопоставимые понятия из документов ФГОС И ПС, которые имеют одинаковую смысловую нагрузку и которые необходимо сопоставлять с помощью разрабатываемой системы.
2. Существует необходимость в проверке степени формализации текста ФГОС и его соответствия словарю предметной области, при адаптации образовательных программ к требованиям рынка.
3. Каждому документу ФГОС может соответствовать несколько документов ПС. Таким образом, для составления соответствий необходим механизм, который бы упрощал получение информации из документов.
4. Благодаря проведенному анализу над аналогами, в нашей системе будем учитывать следующее:
a) Для хранения всей полученной информации и созданных связей, необходима база данных.
b) Необходима реализация классификаторов и проекций.
c) Для создания отчетов применим мощный инструмент «FastReport».
d) Необходима реализация экспорта и импорта данных с использованием открытого XML формата;
e) Реализация модульности. Реализация программы будет идти постепенно, отдельными блоками.
2.1 Программная инженерия
Как известно, каждая профессия содержит в себе определенный набор знаний [5]. Если имеется возможность данный набор знаний структурировать, то он становится базой для следующих компонентов:
· создания учебных программ;
· разработки в области работ по повышению их квалификации;
· разработки работ для аккредитации академических программ;
· разработки профессиональной сертификации.
Формализация знаний произошла и в программной инженерии (software engineering) [7], где был создан собственный свод знаний. Программная инженерия - систематический подход к разработке, сопровождению и исследованию программных продуктов. Названия профессии программных инженеров несколько отличаются в разных странах: в Великобритании программные инженеры становятся «сертифицированными инженерами» [8], а в Канаде «профессиональными инженерами» или «магистрами информационных систем» [9].
В программной инженерии предлагается сертификация знаний по следующим областям:
1. Безопасность.
2. Оптимизация.
3. Архитектура программного обеспечения.
Многие компании создают и проводят собственные экзамены для сертификации специалистов в данной области [10]. В данном случае, сертификации ориентированы на конкретные технологии. Эти программы сертификации разработаны с учётом необходимых знаний и опыта в той или иной технологии. Многие университеты мира имеют программы обучения программной инженерии. Сюда входят:
· очные программы;
· интернет-курсы;
· программы для специалистов;
· программы для учёных в этой области;
· программы для сертификатов (например в США) [11].
В российских вузах есть отдельное направление подготовки 09.03.04 «программная инженерия». Многие компании финансируют программы стажировок для будущих специалистов. Эти практики полезны для студентов тем, что они способны показать практические задачи, с которыми программные инженеры сталкиваются каждый день. Но, по мнению экспертного сообщества, существует нехватка квалифицированного персонала [6]. Особенно это заметно ощущается в Европе и Австралии. Даже не смотря на мировой спад в экономике, зарплаты специалистов программной инженерии остаются высокими. Подобный экономический спад может послужить причиной более тщательного поиска высококвалифицированных работников работодателями.
На сегодня многие люди могут самостоятельно приобрести навыки программирования. Это происходит потому, что создаются простые инструменты для разработки. Подобная ситуация создает конкуренцию и заставляет специализированных профессионалов предпринимать усилия в конкуренции с непрофессионалами. Многим предприятиям нужны именно сертифицированные разработчики. Иногда возникают настолько большие проблемы, связанные с программным обеспечением, что заставляют государственные органы ввести жесткую процедуру лицензирования. Решается задача по отделению специалистов от программистов-любителей. Такие тенденции, естественным образом, затрагивают вузы. Перед вузами стоит важная задача обучить студентов фундаментальным методам мышления применительно к их профессиональной сфере деятельности.
2.2 Руководство к своду знаний по программной инженерии - SWEBOK
Без знаний в области программной инженерии не стать программным инженером-специалистом. В феврале 2004 года ieee computer society завершило работу над созданием SWEBOK. Данное руководство было опубликовано как стандарт iso/iec 19759:2004. Данный стандарт описывает знания и навыки, которые должен получить дипломированный инженер за срок его обучения продолжительностью в четыре года. Среди обязательных знаний и навыков инженера:
1. начальное профессиональное образование;
2. регистрация пригодности к практической деятельности;
3. повышение квалификации специалистов;
4. поддержка со стороны профессионального сообщества;
5. следование коду этики профессии.
Разработка SWEBOK позволяет выполнить первые три компонента. SWEBOK содержит в себе, что должен знать и какими навыками владеть специалист по программной инженерии.
SWEBOK рассчитана на следующих пользователей:
· государственные организации и компании, для определения требований к образовательным программам и требований к профессии;
· чиновники, для профессионального лицензирования специалистов;
· сообщества и учебные организации, для сертификации программ вузов;
· студенты, которые связали свою профессиональную деятельность с программной инженерией;
· преподаватели, которые отвечают за создание учебных планов и курсов.
SWEBOK предлагает руководство к своду знаний, в котором приводятся понятия, знания и определения по программной инженерии Цели SWEBOK:
· Единое представление.
· Определение границы.
· Содержание.
· Единый свод знаний и предоставление к нему доступа.
· Разработки учебных планов и материалов.
· Лицензирование.
· Сертификации.
Приведем пример один из элементов структуры документа SWEBOK в таблице 1.1.
Таблица 1
Структура SWEBOK
|
1. Software Requirements Fundamentals |
1. основы программного обеспечения |
|
|
1.1. Definition of a Software Requirement |
1.1. определение требований к программному обеспечению |
|
|
1.2. Product and Process Requirements |
1.2. требования к продукту и процессам |
|
|
1.3. Functional and Nonfunctional Requirements |
1.3. функциональные и нефункциональные требования |
|
|
1.4. Emergent Properties |
1.4. новые свойства |
|
|
1.5. Quantifiable Requirements |
1.5. количественные требования |
|
|
1.6. System Requirements and Software Requirements |
1.6. требования к системе и требования к программному обеспечению |
|
|
2. Requirements Process |
2. процесс требований |
|
|
2.1. Process Models |
2.1. модели процессов |
|
|
2.2. Process Actors |
2.2. процессоры |
|
|
2.3. Process Support and Management |
2.3. поддержка процессов и управление ими |
|
|
2.4. Process Quality and Improvement |
2.4. качество и улучшение качества процесса |
|
|
3. Requirements Elicitation |
3. требование к требованиям |
|
|
3.1. Requirements Sources |
3.1. источники требований |
|
|
3.2. Elicitation Techniques |
3.2. методы эскизации |
|
|
4. Requirements Analysis |
4. анализ требований |
|
|
4.1. Requirements Classification |
4.1. классификация требований |
|
|
4.2. Conceptual Modeling |
4.2. концептуальное моделирование |
|
|
4.3. Architectural Design and Requirements Allocation |
4.3. распределение архитектурного дизайна и требований |
|
|
4.4. Requirements Negotiation |
4.4. требования согласования |
|
|
4.5. Formal Analysis |
4.5. формальный анализ |
|
|
5. Requirements Specification |
5. спецификация требований |
|
|
5.1. System Definition Document |
5.1. документ определения системы |
|
|
5.2. System Requirements Specification |
5.2. спецификация системных требований |
|
|
5.3. Software Requirements Specification |
5.3. спецификация требований к программному обеспечению |
|
|
6. Requirements Validation |
6. проверка требований |
|
|
6.1. Requirements Reviews |
6.1. требования проверки |
|
|
6.2. Prototyping |
6.2. макетирование |
|
|
6.3. Model Validation |
6.3. проверка модели |
|
|
6.4. Acceptance Tests |
6.4.приемочные испытания |
|
|
7. Practical Considerations |
7. практические соображения |
|
|
7.1. Iterative Nature of the Requirements Process |
7.1. итеративная природа процесса требований |
|
|
7.2. Change Management |
7.2. управление изменениями |
|
|
7.3. Requirements Attributes |
7.3. атрибуты требований |
|
|
7.4. Requirements Tracing |
7.4. отслеживание требований |
|
|
7.5. Measuring Requirements |
7.5. требования к измерению |
|
|
8. Software Requirements Tools |
8. инструменты программного обеспечения |
В документе SWEBOK описывается все то, что относится и должно быть рассмотрено и учтено в предметной области программной инженерии. На основе SWEBOK. Мы можем создать нечто похожее, а именно собственный словарь синонимов предметной области, с помощью которого мы будем проверять наличие необходимых компонентов в содержании ФГОС. На основе ФГОС необходимо проанализировать понятия и термины, которые обязаны быть в данном документе и которые должны быть отражены в ПС. Благодаря структурированию и упорядочиванию терминов понятий работу можно рассматривать как составную часть онтологической модели и как усеченный вариант структурирования предметной области программной инженерии. При поиске аналогов не было найдено автоматизированных средств для подобного структурирования.
2.3 Составление ОПОП
В разрабатываемой автоматизированной системе будет идти работа над документами ФГОС и ПС, так как они являются основным источником информации для формирования ОПОП, ПООП и РПД.
Анализ нормативных документов позволил выделить основную методику и алгоритм. Для этого необходимо провезти анализ трудовых функций и уточнить задачи профессиональной деятельности, к решению которых готовится выпускник. В ходе исследования необходимо:
· проанализировать перечень трудовых функций, отобранных для разработки конкретной образовательной программы;
· выбрать наиболее значимые трудовые функции;
· при необходимости на основе выбранных трудовых функций составить обобщенный перечень задач профессиональной деятельности выпускника образовательной программы высшего образования и сопоставить его с ФГОС.
Вышеперечисленные операции можно изобразить в виде таблицы (таблица 1.2).
Таблица 1.2
Сопоставление профессиональных задач ФГОС и трудовых функций ПС
|
Требования ФГОС ВО |
Требования ПС |
|
|
Профессиональные задачи |
Обобщенные трудовые функции (ОТФ), трудовые функции (ТФ) |
Для системы также необходимо формирование перечня компетенций, вносимых в ОПОП дополнительно к компетенциям ФГОС. При использовании ПС для формирования расширенного перечня профессиональных компетенций образовательной программы необходимо:
· проанализировать описание трудовых функций, которые содержит профессиональный стандарт;
· проанализировать описание характеристик обобщенных трудовых функций всех ПС, используемых для разработки образовательных программ;
· отобрать наиболее значимые для конкретного проекта образовательной программы трудовые функции;
· проанализировать сформулированные в ПС квалификационные требования к выбранным трудовым функциям;
· составить на основе отобранных единиц профессионального стандарта и квалификационных требований к ним перечень профессиональных компетенций.
Необходимо учитывать, что предлагаемые работодателем описания трудовых функций могут носить несколько иной характер, чем формулировки профессиональных компетенций, формируемых в период обучения, в связи с тем, что трудовые функции предполагают наличие практического опыта, которого нет у обучающихся, и который может быть сформирован у выпускников только в объеме трудоемкости практической подготовки, предусмотренной ФГОС.
Так же оформим эти действия в виде таблицы (таблица 1.3).
Таблица 1.3
Сопоставление профессиональных компетенций ФГОС и трудовых функций ПС
|
Требования ФГОС ВО |
Требования ПС |
|
|
Профессиональные компетенции по каждому ВД |
Трудовые функции по каждой ОТФ и квалификационные требования к ним, сформулированные в ПС |
Таким образом, из документа ФГОС необходимо выделить следующие пункты 4.4 и 5.2.
В пункте 4.4 приводятся профессиональные задачи соответствующие определенному направлению подготовки. На рисунке 2.1 приведен пример пункта 4.4 для направления подготовки 010400 Прикладная математика и информатика
Рис. 2.1 Пункт 4.4
В пункте 5.2 приводятся профессиональные компетенции (ПК), которыми выпускник должен обладать. На рисунке 2.2 приведен пример текста из пункта 5.2.
Рис. 2.2 Пункт 5.2
Таким образом, мы можем выделить три основных компонента, которые необходимы для автоматизации методики:
1. Название пункта
2. Вид деятельности
3. Список компетенций и задач
Проанализируем, что необходимо учитывать из документа ПС. В качестве примера приведен профессиональный стандарт для программиста (Рисунок 2.3).
Рис. 2.3 ПС «Программист»
Учитывая методические рекомендации, из приведенной выше таблицы, необходимо выделить наименование обобщенной трудовой функции, а так же список трудовых функций входящих в каждую обобщенную трудовую функцию.
На рисунке 2.4 приведены перечень компонентов, которые входят в каждую трудовую функцию.
Рис. 2.4 Компоненты
Таким образом, мы имеем следующий необходимый набор данных из этого документа: