Сценарий учебного мероприятия "Хакатон - мастерская программных модулей"

Мастерская программных модулей: командная разработка мини-проекта

Дисциплина / междисциплинарный курс: МДК «Разработка программных модулей» (или дисциплина профессионального цикла, формирующая соответствующие компетенции).

Формат мероприятия: учебное занятие с элементами деловой игры, проектной работы и взаимного оценивания (код-ревью).

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

Продолжительность: 90–180 минут.

Нормативная база и формируемые компетенции

Мероприятие спроектировано с учётом требований федеральных государственных образовательных стандартов среднего профессионального образования по специальностям 09.02.07 «Информационные системы и программирование», 09.02.06 «Сетевое и системное администрирование» и другим специальностям ИТ-профиля, а также с опорой на профессиональный стандарт 06.001 «Программист».

В ходе занятия у обучающихся целенаправленно формируются следующие компетенции.

Общие компетенции (ОК) – в соответствии с ФГОС СПО:

Профессиональные компетенции (ПК) – на примере специальности 09.02.07:

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

Связь с профессиональным стандартом 06.001 «Программист»:
в процессе выполнения заданий студенты осваивают трудовые функции, связанные с формализацией требований, разработкой программного кода, отладкой и тестированием модулей, документированием результатов.

Цели мероприятия

• Учебная: сформировать у обучающихся целостное представление о жизненном цикле программного модуля (проектирование интерфейса, реализация, отладка, тестирование, документирование).

• Развивающая: развить навыки командного взаимодействия, критического анализа кода, аргументированной защиты технических решений.

• Воспитательная: способствовать формированию ответственности за результат коллективной работы, профессиональной рефлексии и уважительного отношения к чужому коду.

Подготовка к мероприятию

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

• Библиотека для работы с датами и временем (форматирование, вычисление интервалов).

• Модуль валидации форм (проверка email, телефона, пароля).

• Конвертер единиц измерения (длина, вес, температура).

• Генератор CSV-отчётов по переданным данным.

• Кэширующий прокси для медленного внешнего API (имитация).

Каждое ТЗ должно содержать:

• Краткое описание назначения модуля.

• Функциональные требования (что модуль должен делать).

• Нефункциональные требования (ограничения по памяти, быстродействию, стилю кода – при необходимости).

• Примеры входных и выходных данных.

• Критерии приёмки модуля.

Также готовятся раздаточные материалы:

• Шаблон документации на модуль.

• Чек-лист для проведения код-ревью.

• Карточки с ролями участников.

• Оценочные листы для преподавателя (с привязкой к компонентам компетенций).

Ход мероприятия

Этап 1. Организационный момент и постановка задачи (10 минут)
Преподаватель объявляет тему и цель занятия, напоминает структуру программного модуля и его место в архитектуре программного продукта. Акцентируется внимание на том, что современный разработчик выполняет не только написание кода, но и проектирование интерфейсов, тестирование и документирование. Группа разбивается на команды по 3–4 человека, каждая получает ТЗ.

Этап 2. Распределение ролей (5 минут)
Каждый участник команды получает одну из ролей, соответствующих реальным функциям в ИТ-проекте:

• Архитектор – отвечает за проектирование публичного интерфейса модуля (сигнатуры функций и классов, контракты взаимодействия).

• Разработчик – реализует основную логику модуля в соответствии с утверждённым интерфейсом.

• Тестировщик – разрабатывает модульные тесты (автоматические или сценарии ручного тестирования с ожидаемыми результатами).

• Документатор (при наличии четырёх человек) – готовит описание модуля, инструкцию по подключению и использованию, примеры.

Если команда состоит из трёх человек, обязанности документатора распределяются между остальными участниками.

Этап 3. Проектирование интерфейса модуля (15 минут)
Команда обсуждает ТЗ, и архитектор фиксирует публичный интерфейс в виде заглушек кода с docstring-комментариями. На данном этапе преподаватель выполняет роль консультанта, оценивая соответствие предложенного интерфейса требованиям ТЗ, принципам модульности и возможности повторного использования.

Этап 4. Параллельная разработка и тестирование (30 минут)
Разработчик реализует функциональность. Тестировщик параллельно пишет тесты (код или тест-кейсы) на основе спецификации интерфейса. Документатор готовит текстовое описание модуля. Архитектор координирует работу и помогает разработчику при возникновении технических затруднений.

Этап 5. Сборка и предварительная верификация (10 минут)
Тестировщик запускает тесты и фиксирует результат. Обнаруженные дефекты оперативно исправляются командой. Документатор завершает описание модуля и добавляет пример использования.

Этап 6. Взаимное код-ревью (15 минут)
Команды обмениваются модулями и проводят рецензирование по чек-листу, включающему следующие позиции:

• Соответствие реализации заявленному интерфейсу.

• Соблюдение стандартов оформления кода, читаемость.

• Полнота и корректность документации.

• Наличие и покрытие тестами основных сценариев.

• Обработка граничных значений и исключительных ситуаций.

После ревью команда получает обратную связь и может внести финальные правки.

Этап 7. Защита мини-проекта (15 минут)
Каждая команда в течение 2–3 минут представляет свой модуль: архитектор описывает интерфейс, разработчик демонстрирует ключевые фрагменты кода, тестировщик комментирует результаты тестирования, документатор показывает документацию. Преподаватель и другие команды задают вопросы по реализации и принятым решениям.

Этап 8. Подведение итогов и рефлексия (10 минут)

Оценка модулей осуществляется по заранее объявленным критериям, сформулированным как показатели освоения компетенций:

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

Материально-техническое обеспечение

• Автоматизированные рабочие места обучающихся (ПК или ноутбуки) с установленными инструментами разработки (IDE, Git – при необходимости).

• Проектор и экран для демонстрации результатов.

• Раздаточные материалы (ТЗ, шаблон документации, чек-лист код-ревью, оценочные листы).

• Локальный репозиторий или сетевая папка для обмена модулями (опционально).

Ожидаемые образовательные результаты

После завершения мероприятия обучающиеся смогут:

• анализировать техническое задание на разработку программного модуля;

• проектировать публичный интерфейс модуля в виде сигнатур функций и классов;

• реализовывать программный код на основе спецификации;

• выполнять отладку и тестирование модуля;

• оформлять программную документацию;

• взаимодействовать в команде с распределением ролей, аргументированно защищать принятые решения;

• проводить взаимное рецензирование кода в соответствии с принятыми критериями.

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