ОБУЧЕНИЕ ООАП НА ОСНОВЕ НАУЧНЫХ ШАБЛОНОВ

Фирсов Александр Дмитриевич (phirsof@mail.ru)
к.ф.-м.н., доцент
Днепропетровский национальный университет, г. Днепропетровск

Последние годы в Приднепровском регионе наблюдается стремительное развитие рынка труда ориентированного на производителей программного обеспечения. Еще три-четыре года назад существовал один крупный оутсоринговый производитель ПО, со своей специфической нишей производства и несколько мелких, занимающихся короткими проектами. При этом профессиональной подготовкой программистов занимались три высших учебных заведения, и конечно, следует учесть огромный потенциал технических специалистов, работавших в космической отрасли и готовых сменить профиль деятельности. Существующая база не могла быть не задействована крупными и средними компаниями - разработчиками ПО, и в течении короткого промежутка времени свои филиалы открыли с десяток известных компаний.

Появление новых рабочих мест с хорошими условиями оплаты труда, карьерного и творческого роста, обострило конкуренцию между компаниями за специалистов, выпускников и даже студентов, обучающихся по соответствующим специальностям.

Высшие учебные заведения отреагировали корректировкой учебных программ и введением новых методик преподавания и изучения материалов по программной инженерии. Необходимо отметить два источника изменений, которые повлияли на содержание учебного процесса. Украина присоединилась к Болонской декларации, и как следствие, приняла новый список профессий и квалификаций выпускников, максимально соответствующих европейским, что потребовало как изменения учебных планов, так и их наполнения. С другой стороны, многие преподаватели ИТ, активно сотрудничают с компаниями - разработчиками ПО и имеют возможность изнутри видеть их потребности.

На факультете прикладной математики ДНУ, существует хорошая история преподавания программирования в целом, а также сопутствующих дисциплин. Начальный курс программирования, курсы ООП и теории алгоритмов стали такой же классикой, как и курсы математического анализа или численных методов. Но производственная реальность потребовала введения курсов по программной инженерии, в частности последние три года курсы по программированию, являются частью цепочки курсов, которая соответствует всему жизненному циклу ПО. Дополняют эту цепочку курсы соответствующие процессам управления, управления требованиями, управления интеллектуальной собственностью. Причем упор на фундаментальное математическое образование остается прежним, естественно с учетом специализаций.

Концептуально важным направлением подготовки в рамках жизненного цикла разработки ПО является анализ и проектирование. И важным здесь является не только получение специальных знаний, а в первую очередь развитие, соответствующего образа мышления у студентов.

Изучить формальную нотацию, будь то IDF или UML в рамках курсов моделирования информационных систем и системного анализа информационных систем, для третьекурсника особого труда не представляет, более того построить модель простой системы с различных точек зрения на практических занятиях и затем на экзамене тоже удается почти всем. Дальнейшее же изучение ООАД сталкивается с серьезными трудностями.

На наш взгляд, анализировать и проектировать, нельзя научиться в теории, нужна практика - изучение существующих архитектурных решений, и создание методом проб и ошибок своих собственных дизайнерских решений.

Мощным инструментом при проектировании программного обеспечения, основанным на индустриальном опыте являются шаблоны проектирования. Их изучение позволяет получить опыт анализа существующих разработок. То есть студент не путем изучения проблемы и возможных путей ее решения приходит к стандартному проектному решению, а, имея описание проблемы и готовый проект (шаблон) восстанавливает путь получения решения, затем изучает его достоинства и стоимость. С инженерной точки зрения данный ход изучения эффективен. Будущий разработчик, сталкиваясь с архитектурным вопросом, зная стандартное решение, просто его применяет, при этом работая в системе общепринятых подходов.

Изучение шаблонов проектирования в рамках учебной программы также подразумевает их практическую реализацию, а главное их практическую реализацию в контексте проектного решения более высокого уровня.

И здесь возникает следующая проблема - необходимо предложить студенту задачу, которую он смог бы решить обладая текущим уровнем знаний, но при этом он должен ориентироваться в предметной области так, что бы вложиться в рамки учебного процесса.

Шаблоны в области проектирования ПО, делятся на стандартные группы - структурные, поведенческие и т.д. Но шаблонные решения существуют также и в других областях, например в области образования. Мы решили ввести понятие научного программного шаблона, которое подразумевает описание стандартной математической задачи (модели) не средствами структурного программирования, а формальным описанием на UML с необходимым описанием решаемой проблемы.

Используя такое понятие, появилась возможность ставить перед студентами задачу по анализу и проектированию известных им систем, но с другой точки зрения - разработки своего собственного объектного шаблона с обоснованием его правильности.

Примерами математических моделей, для которых разрабатывались научные программные шаблоны стали нейронные сети, генетические алгоритмы, интеллектуальные агенты, модели разбиения множеств и т.д.

Таким образом, решается целый комплекс задач:

• студент получает опыт ООАП на реальном примере, конечно, это не заменяет работу над полноценным программным проектом в коллективе, но позволяет провести исследование на базе собственного опыта и знаний;
• студент получает опыт формализации собственной разработки, и не только построения модели, но и описания так, что бы представить ее коллегам и преподавателю с учетом сильных и слабых сторон;
• студент встречается с нетривиальным видением известного решения в области прикладной математики, что позволяет расширить представления о системном подходе и моделировании;
• студент повторяет изученный ранее материал, болем того, для построения хорошей модели возникает необходимость досконального владения материалом;
• преподаватель получает весьма большой набор учебного материала, с одной стороны достаточно большой выбор математических систем и моделей, а с другой отсутствие стандартов на научные программные шаблоны означает, что независимые студенты могут получить разные решения, со своими обоснованиями;
• преподаватель имеет возможность проведения творческих конкурсов с целью дополнительной мотивации, если есть возможность представления своих работ в рамках семинаров перед коллегами.

Понятно, что подобного рода деятельность требует дополнительных усилий как от преподавателя так и от студентов, т.к возникает необходимость в регулярном общении выходящем за отведенные часы, выделении дополнительного времени на проектирование и проверку. Имеющийся же опыт позволяет говорить как минимум о дополнительной подготовке студентов предъявляющих более высокие требования к своему образованию.