Каждый хороший преподаватель, а я полагаю, что таким являюсь, старается сделать процесс обучения максимально эффективным. При этом он сталкивается с рядом трудностей, например:
1. Зачастую у преподавателя отсутствует глубокий практический опыт, но имеются отличные теоретические знания
2. В силу учебного характера приходится брать довольно простые задачи, решение которых не побуждает студентов использовать сложные методы. Если же брать сложные задачи, то просто не хватает времени для их глубокой проработки, и в результате часть задачи остается не решенной или решенной скверно, не вырабатывая нужного понимания у студента, а зачастую формируя стереотип - зачем нам все это давали
3. У студента много других дисциплин и задач, которые ему приходится решать одновременно. Преподаватели разные, разные по человеческим и профессиональным качествам, выдвигают разные требования, которые слабо или вообще не согласуются с требованиями и подходами других преподавателей
4. Классический подход в образовании предполагает выполнение студентом индивидуального задания. А поскольку все студенты разные, то и степень понимания, проработки и выполнения задания у всех разная, при этом преподаватель оказывается так перегружен, что не в состоянии оказать всем равное внимание, тем более в ситуация, когда у студента есть большие пробелы в знаниях и проблемы с дисциплиной занятий.
Разрешить эти трудности можно, пожалуй, одним способом. Сделать так, чтобы студенты сами были заинтересованы в глубоком изучении предмета, чтобы сама учебная среда их обучала, незаметным образом создавала нужные компетенции и навыки. Для преподавателя нужно сделать так, чтобы максимально сократить число точек внимания, распределить их во времени так, чтобы не напрягали и не истощали его, позволяли ему быть не просто вещателем знаний, а наставником, коллегой.
Чтобы добиться этого, нужно сократить число задач или число студентов на одного преподавателя. А из обучения сделать игру, максимально похожую на то, что происходит в реальности. Число студентов - объективная реальность, данная нам в ощущениях, и изменению не подлежит. Потому тут два пути: или давать одну задачу на всех, или объединять студентов в команды, сокращая число задач и число студентов на единицу преподавателя.
Одна задача на всех, к сожалению, не наш путь, потому что одно задание на всех будет означать, что несколько человек может и будут стараться его делать, но большая часть просто спишет, позаимствует.
Поэтому я выбрал другой путь, объединение студентов в команды и выполнение единого на команду проекта. У меня уже есть достаточно богатый опыт организации обучения в виде командного проекта, когда вся группа "нанималась" для разработки конкретного продукта. Результаты были опубликованы на конференции Объектные системы [Галиаскаров Э.Г., Умнов Д.М., Агеев М.С. Организация учебного проекта разработки программного обеспечения информационной системы]. Такие семестровые проекты организовывались на 5 курсе. Это было очень удобно. У меня был большой 200 часов курс, а к этому времени у студентов уже были пройдены практически все профильные предметы (технология программирования, теория информационных процессов, управления данными, моделирование систем, корпоративные ИС, проектирование ИС и т.п.), сделан ряд курсовых проектов, пройдены все возможные практики, выполнена защита квалификационной работы бакалавра. Таким образом, этот подход позволял мне сосредоточиться не на передаче новых знаний, а на систематизации знаний студента, на том, чтобы дать им практическую направленность, сформировать и закрепить навыки решения сложных задач, работать в команде.
Для создания духа соревновательности было решено делать не один, а несколько проектов. Количество проектов зависит от количества команд, а количество команд от общего числа студентов. Идеально иметь две команды, которые соревнуются друг с другом, но они могут быть слишком велики. Оптимальное количество студентов в команде 6-8, 10 - это уже предел. Учитывая общее количество студентов в группе, я организовал 3 команды по 9 человек.
Следующая задача - подобрать тему для проекта. Поскольку требуется построить архитектуру информационной системы, то и проект должен быть связан с разработкой этой самой ИС. Также хотелось бы, чтобы он был оригинальным, интересным и познавательным, но вместе с тем не очень сложным, чтобы успеть получить удовлетворительный результат в конце семестра.
Так получилось, что мне посчастливилось познакомиться с Сергеем Немеровым, удивительно талантливым и творческим человеком. Он с готовностью мне помог и набросал десяток занимательных тем. Я настолько восхитился оригинальностью мышления Сергея, что тут же попросил его стать сторонним консультантом и одновременно играть роль строгого заказчика, такой темной лошадкой, мистером Х, с которым командам нужно работать, понимать его нужды, добиваться его внимания и финансирования своего проекта. Вообщем, типичный stakeholder!
Формирование команд тоже происходило довольно неформально. Хороший каламбур получился. Для начала ребятам было предложено самим объединиться в три команды. Чтобы получить какой-то опыт взаимодействия и понять к какой команде все-таки примкнуть, предварительно были проведены несколько деловых игр. Самая значительная из них - игра в архитектора.
Суть игры довольно простая. Формируются команды. Из каждой команды выделяется Заказчик. Заказчик во время игры находится вне поля зрения команды (за дверью класса) и общается с командой только письменно, отвечая на вопросы команды. В команде избирается Архитектор, остальные его помощники.
Архитектор организует работу по проекту и представляет результаты в конце заказчику. 15 минут отводится на сбор требований их анализ и формирование решения. 5-10 минут на подготовку проекта к презентации. 5 минут на презентацию проекта Заказчику.
До начала игры Заказчик выводится за дверь, и ведущий предлагает ему записать свои требования к Дому Его Мечты. Документ изымается до конца игры.
Команде объясняются правила игры: общение с заказчиком только письменно, через ведущего. Можно задавать любые вопросы, но они должны быть конкретны, не в открытой произвольной форме. Т.е. нельзя написать - Какой дом ты хочешь иметь? Можно - Сколько этажей? Какая площадь? Стены должны быть каменными? Нужна ли баня? Каков бюджет проекта? Как быстро должен быть построен дом? и т.п.
Игра на самом деле очень интересная и познавательная. Интересно наблюдать, как ребята организуют процесс формирования вопросов и далее проектируют решение. Какие вопросы они задают, их тип, количество. Как эти вопросы превращаются в решение.
На презентации результатов сравниваем, что написано у заказчика, а что сделано командой. Окончательное слово остается за заказчиком.
Кстати, игра сразу показала, что стоит каждая команда. кто лидер. а кто аутсайдер. Это сохранилось и в дальнейшем.
После формирования команд происходил выбор и согласование тем. Были выбраны такие темы:
- социальная сеть управления и пропаганды в РККА "Товарищи"
- новостной портал Золотой орды "Благие вести"
Проект был условно разбит на 10 итераций. Команда должна была представить результаты каждой итерации. С преподавателем это происходило в живую на кафедре, а со сторонними консультантами по договоренности, через скайп или оффлайн в виде текстовых рекомендаций и оценок. В частности, Сергей это делал по почте. были некоторые задержки и проблемы при взаимодействии в силу большой занятости Сергея, но тем и ценнее такие отношения, они очень коррелируют с тем, что происходит в действительности.
Все свои артефакты команды хранили на GoogleDocs, а общение производили в социальной сети ВКонтакте.
Все учебные материалы и рекомендации были представлены на сайте курса учебного портала ИГХТУ. На форуме курса я подводил итоги каждой итерации, подробно прописывал выявленные недостатки или упущения, размещал рекомендации от Сергея Немерова и свои.
Результаты оценивания каждой итерации также сводились в специальную ведомость.
Необходимость оценивания с одной стороны вынужденная мера. Нужно было три раза в семестре выставлять оценку за контрольную точку и за семестр в целом. С другой стороны - это был некий критерий эффективности команды, той основой, которая позволила определить победителя. Оценка формировалась довольно сложно. Каждый студент в семестре мог иметь до 100 баллов. Общая сумма баллов на группу 2800. Эта сумма пропорционально делится по командам. Также сумма делится по возможности равномерно по итерациям. Оценка за итерацию ставится всеми преподавателями, экспертами. Эта сумма передается команде, и далее команда сама распределяла баллы между участниками. Интересно, что сначала это была стратегия равномерного распределения, но постепенно распределение баллов уже стало происходить по справедливости и по вкладу. К сожалению некоторые студенты стали филонить, игнорировать выполнения своих задач, подводить свои команды, что незамедлительно стало сказываться на общей оценке. Возможно, такая система оценок сложна и не идеальна, но она работает. Но я всегда открыт для дискуссии и новых идей, как это сделать лучше.
Процесс проектирования архитектуры включал в себя три этапа: анализ требований, функциональный анализ и синтез архитектуры.
С точки зрения корректности на входе предполагался некоторый пул требований, лучше - утвержденная концепция, в которой определены основные свойства будущей системы и заданы показатели качества и эффективности. Но в тот момент подготовить такой набор требований оказалось для меня непосильной задачей, По этому помимо задачи анализа требований, необходимо было прежде решать задачу выявления и уточнения требований и формирования концепции решения. На самом деле в этом был полезный момент, т.к. практики выявления, документирования и работы с требованиями у студентов за прошедший семестр было не так много. На этом этапе студенты учились понимать назначение системы, достижение каких целей она должна обеспечить, кто заинтересован в существовании такой системы, каковы их потребности, как все это взаимоувязано. Формировали основные свойства системы, показатели качества и эффективности. Далее приступали к анализу требований, их приоритезации, выделения тех, которые на их взгляд наиболее значимы и имеют наибольшее влияние на архитектуру системы, описывали основные сценарии взаимодействия с системой. Особое внимание уделялось выстраиванию цепочек причинно-следственных связей посредством трассировки элементов анализа и проектирования между собой.
Далее проводился функциональный анализ и формировалась функциональная или логическая архитектура, предлагалась функциональная декомпозиция и описывались интерфейсы взаимодействия между частями. На этом этапе предполагалось, что на основе выявленных показателей эффективности и качества, а также функциональных требованиях, имеющихся проектных ограничений и возможностей, будет подобран один или несколько существующих шаблонов проектирования (архитектурных паттернов) и на их основе будет выполнен синтез логической оригинальной архитектуры. Предполагалось, что студенты сформируют несколько представлений и подготовят черновой вариант описания архитектуры в виде документа подобного architecture vision или architecture notebook.
Этот этап оказался самым сложным. Я и сам довольно плавал в этом вопросе, хотя возможно есть понимание в каком направлении двигаться. Наш эксперт в этом тоже не смог нам помочь, поскольку его конек - это информационная архитектура и внешние интерфейсы. Впрочем выход был найден, он в общем-то был довольно очевиден, подсмотреть существующие решения и подходы.
Конечным этапом была попытка сформировать физическую архитектуру, предложить варианты спецификации для оборудования, приобретаемого системного и прикладного ПО, использование фреймворков. Как не странно этот этап оказался самым продуктивным, мне даже приходилось сдерживать фантазию и ретивость студентов.
Чтобы процесс проектирования архитектуры не превратился в скучную работу по созданию документов, заполнению шаблонов и рисованию схем и диаграмм, начиная со второго этапа студентам предлагалась создавать прототип решения. Прототип предлагалось создавать с помощью wix.com, но студенты могли выбрать и другие способы и инструменты прототипирования.
В качестве инструментальной поддержки предлагалось использовать иерархические списки, таблицы, UML, диаграммы потоков данных, IDEF1x, mindmap, вообщем, все то, что студенты сочтут для себя полезным, а преподаватель намекнет или сумеет убедить их это использовать.
По завершению проекта каждая команда делала презентацию своей архитектуры с демонстрацией своих идей на подготовленном прототипе. Затем тайным голосованием остальные команды оценивали полученное решение, саму презентацию. Получилось очень интересно.
В итоге по сумме баллов, полученных каждой командой в семестре, а также по результатам перекрестного голосования, первое место заняла команда "Товарищи" с проектом социальной сети, прототип которой можно ознакомиться по ссылке: социальная сеть "Товарищи".
Второе место заняла команда "Неваляшки" с проектом новостного портала "Благие вести".
Третье место заняла команда с проектом интернет-магазина "З00 Спартанцев", к сожалению публичной версии прототипа не существует. Зато эта команда разработала два разных приложений (прототипов): одно для покупателей, второе для администраторов и менеджеров магазина.
Отдельно хочу отметить команду, которая заняла первое место. Вообще эта команда меня приятно удивила, своей сплоченностью, нацеленностью на результат, работоспособностью, стремлением лучше понять свою задачу, проактивностью, результативностью, дисциплиной. Можно сказать единственная команда, которая вовремя предоставляла результат каждой итерации, присылала распределение оценок экспертов. Интересно, что в этой команде была одна единственная девушка и более того, она взяла на себя функцию руководителя команды, была ее лидером. А какие она письма по итогам итерации присылала! В письме кратко, но очень ясно описывался результат, который команда получила, по пунктам, сопровождая каждую тему ссылкой на материал, который нужно посмотреть эксперту, в конце письма всегда приводилась ссылка на общий репозиторий. Это очень экономило время при знакомстве с результатами итерации. Я очень надеюсь, что эту талантливую девушку ждет интересное будущее. Обращайтесь, если хотите видеть ее в своей команде прямо сейчас, пока Яндекс не переманил.
Что не удалось сделать, но хотелось бы.
Научиться оценивать архитектурные решения. Т.е. провести сессии, при которых команды конкуренты оценивают проект своего конкурента в соответствии с заданной методикой типа АТАМ.
Также следует проработать и получить минимальный набор артефактов и подготовить шаблоны оформления документации.
Также нужна помощь и поддержка сторонних специалистов на стадии функционального анализа и выработки архитектурных решений. Возможно, делу помог бы атлас архитектурных решений, но увы его в сколь-нибудь организованном виде не существует. Правда, в какой-то степени можно воспользоваться подборкой на wiki: https://en.wikipedia.org/wiki/Architectural_pattern.
Ну и напоследок хочу привести несколько отзывов студентов:
Отзыв 1:
Формат проведения данного курса показался очень необычным, с точки зрения обычного обучения в ВУЗе, а с другой стороны, очень познавательный, т. к. позволил поработать в довольно большой команде, выполняя поставленную преподавателем (заказчиком) задачу.Отзыв 2:
Здесь конечно же проявились как плюсы, так и минусы.
К минусам я бы отнесла, во-первых, невозможность работы с реальным заказчиком, от которого мы бы могли получить его конкретные требования, пожелания, вместо этого приходилось изучать исторические моменты, характеры и идеологию личностей и народа того времени. Это очень помогало, но все равно не удалась избежать недопонимания в команде. Мы смотрели на то общество с точки зрения нашей повседневности, и нам было трудно представить наличие гаджетов, доступа к интернету у военнослужащих РККА: возможно они бы их использовали совершенно иначе, чем мы?
Во-вторых, я бы отнесла к минусам и объединение в команды людей с совершенно разной мотивацией, и, как следствие, работоспособности и дисциплины отдельных членов команд. Некоторые не были заинтересованы в получении практики (из-за отсутствия времени и, возможно, интереса к данному виду работы в команде).
В-третьих, мне показалось недостаточным интерес со стороны стороннего эксперта, возможно, из-за отсутствия времени или возможностей. Мое мнение, возможно он оценивал нас как UX-дизайнеров, от него не получила почти никакого взаимодействия, ответов на писем.
И последний минус: как мне показалось, сначала было очень сложно понять, что от нас конкретно требуется. Полное отсутствие опыта делало нас очень "заторможенными" в понимании того, что мы делали. Но благодаря живому общению с преподавателем, а также комментариев и заметок к документам, изучению статей, книг, мы пытались исправлять свои ошибки, тем самым набираясь опыта и знаниями.
К плюсам конечно же относится возможность командного проектирования ИС. Мы изучали информацию, статьи, делились ими между собой, пытались объяснять друг другу непонятные моменты, высказывали свои точки зрения, выбирали наилучшие. Иногда даже были небольшие столкновения и недопонимания, что позволяло искать аргументы, доказательства своей правоты, желание сделать что-либо лучше.
Так же к плюсам я бы отнесла то, что все-таки у большинства появился азарт, соперничество между командами, борьба за баллы, что, как мне показалось, моделировало реальные условия разработки ИС: получение прибыли от продукта, конкуренция между компаниями.
И последний плюс, лично от меня, как от представителя и руководителя команды: мне было очень интересно координировать работу команды, пытаться ставить перед ней конкретные задачи, мотивировать на их выполнение. Очень приятно что все члены команды принимали участие, кто-то в большей мере, кто-то в меньшей, но все старались внести свой вклад.
В данном курсе мне бы пригодился четкий план, последовательность действий, Вы нам его предоставляли на многих итерациях и жизнь становилась намного легче. Бывали моменты когда не знали с чего начать, с какой стороны подойти. У нас совершенно отсутствовал опыт в этой сфере и, как мне кажется, в таких условиях нужен более жесткий и детальный план, что сократило бы время на вливание в работу. Это конечно же мое мнение, так как к каждому студенту нужен свой подход, и это именно мой.
В целом, курсом осталась довольна, и если бы мне пришлось пройти его снова, то уже бы подошла к нему с более высокого уровня знаний, что позволило бы ощутить его дополнительные достоинства. Работа архитектора мне понравилась, но нужен очень большой опыт и знания, чтобы с ней справиться.
В целом курс понравился, но есть не мало минусов. В основном эти минусы по проведению. Не очень понравилось работать в группах по 8-9 человек, некоторые вообще ничего не делали и получалось, что мы очень отставали. Так же не понравилось, что плохо поддерживали связь с внешним заказчиком, вроде человек взял ответственность на себя, что будет поддерживать связь, но под конец пропал у него видимо интерес, что очень расстроило. Хоть и объемный курс, много вопросов появляется во время реализации задания, но все же, наверное, лучше по 3-4 человека работать.Из всего курса очень понравилось реализовывать сам сайт, хотя это скорее всего, потому что я человек творческий и мне больше нравится что-то "творить" :) Работа архитектором мне была интересна, многое для себя нового открыла. Были моменты, которые я немного не понимала: можно даже начать с тем, когда я их увидела, то вообще никак не могла понять их смысла и долго очень привыкала к интернет-магазину в Спарте ) поэтому в начале курса были небольшие проблемы с заданиями.Еще понравилась идея с внешним заказчиком, хоть и не часто с ним общались, но было бы, я думаю, интересно пообщаться с ним даже в том же скайпе и рассказать все наши идеи, а не в документах представлять. Все же при общение больше говоришь, нежели в письменном виде.
А так, курс интересный, сложновато конечно, но в целом было познавательно.
Отзыв 3:
Это очень интересный и важный предмет. На счет формата проведения - это Вы здорово придумали =) Здоровая конкуренция это хорошо =)
На самом деле я не особо разобралась в том, что же делает архитектор =( Нет, я понимаю, что он строит саму архитектуру, так сказать "каркас", но не особо поняла в чем же он заключается. Возможно я просто плохо слушала
