Современные образовательные технологии востребованы на всех ступенях обучения, и в педагогических науках уделяется много внимания их структуре, свойствам, классификации (Беспалько В.П. и др.). Однако на практике построение образовательных технологий с заданными свойствами или их элементов является частной, но нетривиальной исследовательской задачей. Так, в высшем образовании большое значение имеет обучение студентов элементам профессиональных технологий в областях специализаций. В данной статье приводятся описание двух опытов организации командной проектной деятельности студентов, специализирующихся в области информатики. В описываемых случаях применяются различные методологии профессионального проектирования программных систем и условия организации команд. Первый опыт отражает аспекты дистанционного взаимодействия в процессе межвузовской разработки web-систем и опирается на адаптивный подход. Второй – описывает применение междисциплинарной образовательной технологии на основе методологии объектно-ориентированного проектирования [1], где дистанционные коммуникации применяются эпизодически. Материал для исследования получен в рамках образовательного процесса двух вузов: ННИГУ и АГАО имени В.М. Шукшина.
Для существующей проблемы интеграции в образовательном процессе учебной и профессиональной деятельности предлагаются разнообразные пути решения. Целью
нашей работы является сравнительный анализ проектной деятельности студенческих команд, который позволяет предположить организационные условия и этапы учебно-профессионального проектирования в целях разработки и апробации дистанционной технологии формирования готовности студентов, специализирующихся в области информатики, к учебно-профессиональному проектированию программных систем. В ходе описываемой опытно-экспериментальной работы применялись методы педагогического моделирования, наблюдения в процессе обучения, изучения результатов деятельности студентов, метод экспертных оценок, педагогический эксперимент [1].
Рассмотрим вначале опыт дистанционного взаимодействия студентов при разработке web-систем. Студенту факультета информационных технологий НГУ была предложена тема квалификационной работы бакалавра с целью создания адаптивной среды поддержки конструирования web-систем. Технически задача заключалась в создании пополняемой библиотеки модулей, из которых составляется требуемая конфигурация системы, и интерфейсных решений, позволяющих настраивать взаимодействие пользователей на эффективную организацию поддерживаемой деятельности. Первичной прикладной базой проекта, на которой отрабатывалась концепция адаптивности и формировалась библиотека модулей, стал сайт лаборатории НГУ-Intel с ее потребностями разнообразной работы посетителей и сотрудников лаборатории (www.i-lab.nsu.ru).
Анализ проектной задачи показал, что для ее решения необходимо реализовать ряд достаточно автономных модулей, и это возможно сделать, привлекая разработчиков со стороны. Возник круг проблем: кого и как привлекать, как обеспечить надежность выполнения автономных заданий, как организовать взаимодействие исполнителей. Поскольку в финансовом плане проект не был обеспечен ресурсами в полной мере, на запрос инициатора работ откликались в основном студенты, изначально не обладающие достаточной квалификацией. Поэтому проектные работы должны были сопровождаться мероприятиями обучающего характера. Из порядка двадцати отобранных претендентов примерно половина согласилась подключиться к проекту. Они обладали небольшим опытом, развить который им хотелось бы в рамках проекта. Среди них оказались разработчики из трех городов России и один из Украины. Еще пять претендентов видели в проекте себя лишь как поставщиков модулей, создаваемых по предоставляемым спецификациям. В ходе начальных работ произошел отсев, в результате которого сложилась структура команды:
• Инициатор проектных работ, в дальнейшем называемый менеджером проек-
та, – упомянутый выше студент ФИТ, выполняющий дипломную работу. Только он в полной мере представлял проект в целом. В дополнение к менеджерским обязанностям он выполнял роли архитектора проекта и разработчика главных модулей системы.
• Три ключевых исполнителя, заинтересованность которых в проекте была самодостаточна. Компоненты системы, которые они реализовали, требовали овладения информацией об архитектуре проекта. Лишь один из них оказался доступным для непосредственного общения. Проектная деятельность ключевых работников стала определяющей.
• От двух до пяти дополнительно привлекаемых работников, которые выполняли автономные задания под руководством сначала менеджера, а по мере роста зрелости проекта и других ключевых работников.
Другой способ организации проектных студенческих команд применялся в процессе обучения студентов младших курсов построению прикладных программных систем на физико-математическом факультете АГАО имени В.М. Шукшина. Потребность в организации студенческих команд возникла вследствие необходимости массового обучения в рамках традиционного образовательного процесса объектно-ориентированному моделированию и программированию слабо подготовленных студентов-первокурсников. Каждый студент к третьему курсу дважды принимал участие в командной проектной деятельности: сначала как исполнитель, а затем, в следующем году, как менеджер. Студенты, уже участвовавшие в проектах, обучались сами и способствовали обучению студентов младших курсов, организовывали командную проектную деятельность, что соответствует «обучению в сотрудничестве». В качестве экспертов привлекались старшекурсники, они оценивали результаты на защите проектов, проводили внешнее тестирование программ.
Студенческие команды формировались в составе от двух до пяти человек. Подбор участников групп вначале осуществлялся в директивном порядке. Далее оказалось, что более эффективно формировать состав команд после презентации менеджером тематики проекта с возможностью выбора команд исполнителями. Структура команд выглядела так:
• Один или два менеджера проекта – студенты второго курса ФМФ. Функции менеджера включают определение темы, объема, графика работы, ответственность за построение словаря, информационной модели, функционирования системы в целом, а также алгоритмическое обеспечение проекта.
• От одного до трех исполнителей – студентов первого курса, а также, по желанию и возможностям, отдельных студентов второго курса. Функции исполнителей: поиск и анализ информации, относящейся к проекту, в первую очередь, с помощью средств информационно-коммуникационных технологий, самостоятельная реализация программных модулей.
• До двух старшекурсников, курирующих команду, выступающих в качестве привлеченных экспертов, которые при необходимости могут оказать консультационную помощь. Однако основная функция студентов-экспертов, как и преподавателей – максимально объективная оценка результатов и деятельности проектной команды.
Элементы дистанционного взаимодействия, такие как общение в чатах и коммуникации с помощью электронной почты, активно применялись участниками команд вследствие высокой доли самостоятельной работы проектных команд во внеаудиторное время. Тем не менее, все участники находились в потенциальной доступности не только других студентов, но и преподавателей, наблюдавших проекты. В полной мере возможность дистанционных взаимодействий проявлялась при внешней оценке проектов на открытых площадках для обсуждения, форумах. Однако этот путь был недоступен большинству участников, так как сторонний интерес вызывали лишь самые оригинальные проекты.
Команды, как правило, оставались стабильными по составу, благодаря глубокой интеграции в образовательный процесс, так как деятельность студентов была реализована в рамках междисциплинарного модуля дисциплин предметной подготовки. Тем не менее, состав команд менялся в сторону уменьшения участников из-за оттока студентов из вуза. В случае если происходила потеря одного из исполнителей, работа перераспределялась менеджером на других участников или выполнялась им, чаще при поддержке экспертов. Это служило иллюстрацией реализации метода смягчения рисков невыполнения проектов. Если происходила потеря одного из менеджеров – другой брал на себя функции руководства и управления; важно различать эти два аспекта работы менеджера (см. [3]). При отсутствии менеджеров проект закрывался, а исполнители присоединялись к другой команде.
Важнейшую роль в результативном завершении проектов в двух описываемых педагогических моделях сыграли организационные и коммуникационные условия проектной деятельности. Так, при дистанционной разработке web-систем первичный анализ проектной ситуации был выполнен менеджером. Он определил круг первоочередных задач и порядок их решения. К моменту завершения первичного анализа обозначились будущие ключевые работники, в ходе взаимодействия с которыми выяснилось, что почта – недостаточно оперативный вид связи, а потому наряду с ней для коммуникаций использовался сервис видеоконференций Скайп. В дальнейшем менеджер организовал регулярные дистанционные обсуждения и отслеживание контрольных точек. Наиболее трудной и неоднозначной задачей стало определение методологии проектной деятельности. Очевидная ориентация на облегченный (agile) подход не прояснила ситуации, поскольку ни XP, ни Scrum, ни иные вариации таких методологий не подходили из-за невыполнимости условий их применения.
Ясность в том, что нужно формировать собственную методологию, появилась, когда менеджеру попалась статья А. Коукберна [4], в которой провозглашается этот принцип как наиболее разумный для учета человеческого фактора. В результате сначала стихийно и лишь для ключевых работников, а затем для всей команды была предложена организация процесса разработки, ближайшим к которой является подход ASD (Adaptive Software Development) Дж. Хайсмита [5]. При интерактивном развитии проекта происходит постепенная адаптация команды к пользовательским требованиям. Разработка каждого из библиотечных модулей включала следующие перекрывающиеся фазы:
• Фаза обдумывания. Инициация проекта – это формирование задания на разработку модуля. Задание исходит из внешнего заказа либо из осознания необходимости реализации разработки. Задание, утвержденное менеджером, определяет требования к модулю. Планирование адаптивного цикла – назначение исполнителей, которым выделяются работы: поиск готового, подобного компонента или констатация необходимости разработки модуля, определение критериев качества. Вначале проекта в качестве исполнителей выбирались один или два ключевых работника. По мере развития работ в проекте стали появляться привлекаемые работники, для которых назначался куратор из числа ключевых работников. Реализация модуля находится в сфере ответственности куратора. Коммуникации этапа –
дистанционное обсуждение плана работ, составляемого менеджером и куратором.
• Фаза сотрудничества. Совместное конкурирующее развитие возможностей библиотеки и пользовательской web-системы: разработка вариантов требуемого модуля, если необходимость этого признана;
определение и проведение работ по адаптации подобранных и разработанных вариантов модуля к требованиям web-системы и библиотеки. Коммуникации этого этапа не формализованы. Они сводятся к индивидуальным консультациям в разной форме. Исключением является ситуация, когда для выполнения задания требуется освоение специального материала учебного характера. В этом случае одним из ключевых работников организовываются регулярные занятия в форме вебинаров для заинтересованных исполнителей. Первичная оценка качества – обсуждение полученных решений. Если не удается выбрать решения, пригодные для развития разрабатываемой web-системы и/или библиотеки, то организуется мини-цикл обучения или переход к итерации цикла адаптации. Коммуникации эта-
па – обсуждение документов, заранее подготовленных и отправленных по электронной почте под контролем менеджера. В обсуждении обязательно участвует исполнитель (ключевой или привлекаемый работник).
• Фаза обучения. Обзор качества – оценка проведенных работ и решение о продолжении проекта. Целью обзора является принятие решения о выпуске релиза или организации перехода к итерации цикла адаптации. Коммуникации этапа не отличаются от проведения обсуждения на этапе первичной оценки качества. Итоговый обзор качества и выпуск релиза для заказчика. Содержание деятельности этапа складывается из определения уровня успешности выполнения работ в целом и организации мероприятий, обеспечивающих включение модуля в библиотеку, встраивание модуля в пользовательскую web-систему. Коммуникации этапа – Скайп-обсуждение успешности выполнения всех фаз проекта с целью корректировки будущей деятельности команды и критериев оценки с учетом полученного опыта, а также взаимодействия с пользователями и заказчиком, регламентируемые последним. В обсуждении успешности участвуют все исполнители проекта. Взаимодействия с заказчиком проводит менеджер, который при необходимости может привлекать к ним других исполнителей.
Во втором описываемом опыте междисциплинарной проектной деятельности основой послужил адаптированный процесс объектно-ориентированного моделирования с использованием шаблонов (patterns) проектирования и универсального языка моделирования UML. Процесс ориентирован на построение объектно-ориентированных моделей предметной области и включал фазы планирования, построения, развертывания в соответствии с идеями К. Лармана [2] об оптимальных приемах и этапах объектно-ориентированного моделирования с применением шаблонов проектирования. В данном случае ведущей среди нижеперечисленных оказалась именно фаза планирования.
• Фаза планирования. После составления спецификации проекта и его словаря, описываются основные режимы использования программной системы или прецеденты. Для каждого режима составляется таблица типичного поведения (прецедентов) системы. Первоначально таблицы составляются без учета интерфейса системы. Это делается намеренно, чтобы как можно четче отделить проектирование от реализации. И только после этого студентам рекомендуется проектировать макеты интерфейсов. Стоит отметить, что ребята все равно потихоньку пытались писать программный код, а при использовании визуальных сред проектирования быстро переходить к использованию библиотек стандартных компонентов. Поэтому задача педагога по возможности пресекать кодирование до построения моделей. Далее на основе макетов интерфейсов уже можно рассматривать поведение проектируемой программной системы более определенно, с применением средств интерфейса: кнопок, надписей, меню, диалоговых окон. Студенты строят таблицы реальных прецедентов вновь для каждого режима использования. Перечисленная документация обязательно представляется командой на предзащите проектов.
• Фаза построения. На последующую реализацию, составление текстов программ отводится в два раза меньше времени, чем на проектирование. И как показывает многолетний опыт, студенческие команды в такие сроки вполне укладываются.
• Фаза развертывания. Для защиты проекта требуется пройти внешнее тестирование, также желательно реализовать дистрибутив системы. Отдельно оценивается справочная система, которая является необходимой составляющей проекта.
В последнем случае процесс оказался достаточно систематизированным и послужил хорошей иллюстрацией технологии объектно-ориентированного проектирования прикладных программных систем не только отдельных студентов, но и всего потока, и послужил основой развернутого педагогического исследования [1] с обработкой данных педагогического эксперимента. Основу образовательной технологии составил метод учебно-профессиональных проектов, сочетающий этапы как педагогического метода проектов, так и методов профессионального проектирования программ.
Рассмотренные опыты организации командной проектной деятельности студентов демонстрируют два способа интеграции технологий и методов обучения с практическими технологиями области специализации, в данном случае информатики и компьютерных наук. В первом из них происходил подбор подходящей методологии, уже включающей возможность обучения. Во вто-
ром – обучающие мероприятия были эффективно привнесены в технологический процесс, и наоборот. В условиях командной работы студентов особую значимость приобрели методы и средства дистанционной коммуникации, такие как общение по электронной почте, с помощью видеоконференций.
Методология, сформировавшаяся при дистанционной разработке серии проектов web-систем, опробована в специфической ситуации организации студентом дистанционной команды, состоящей из студентов. Она не претендует на всеобщность, тем не менее применение подхода в подобных ситуациях возможно, в частности, в научно-исследовательской работе, в курсовом и дипломной проектировании. Существенным моментом представленной методологии является обучающая составляющая. В условиях обсуждаемого проекта обучение можно охарактеризовать как тактическое, подчиненное нуждам разрабатываемой системы. Если же мыслить перспективно и настраиваться на формирование дистанционной команды с высоким производственным потенциалом, то становится понятно, что использованных образовательных мероприятий недостаточно. Второй из рассмотренных опытов использует потенциал дистанционного общения, но в минимальной степени.
В качестве заключения, обсуждения выполнения проектов студенческими командами отметим следующее. На основе сравнительного анализа показана принципиальная возможность эффективной организации дистанционного выполнения командных студенческих проектов разработки программных систем при использовании в рассмотренной междисциплинарной технологии формирования готовности к учебно-профессиональному проектированию методов и средств коммуникационных технологий. Экспериментальная работа по адаптации данной образовательной технологии к дистанционному взаимодействию ведется кафедрой информатики АГАО и лабораторией НГУ – Intel.
Работа выполняется при поддержке РГНФ, проект № 12-06-00103а «Организация дистанционного учебно-профессионального проектирования программных систем».
Рецензенты:
Веряев А.А., д.п.н., профессор кафедры информационных технологий ФГБОУ ВПО «АлтГПА», г. Барнаул;
Мокрецова Л.А., д.п.н., профессор, проректор по научной работе ФГБОУ ВПО «АГАО», г. Бийск.
Работа поступила в редакцию 26.10.2012.