Индивидуальный проект по программированию

Как выбрать тему

Тема по программированию рассыпается обычно не на защите, а в первую неделю разработки. Школьник берёт «Помощник школьника» или «Приложение для здоровья» — и после этого не может понять, с чего начинать: формулировка называет область применения, а не конкретную задачу, которую решает один продукт.

Рабочая тема проходит три проверки:

1. Есть конкретная задача, которую решает продукт. Не «помощник школьника», а «бот, который присылает одно конкретное напоминание в заданное время» — задача укладывается в одно предложение без союза «и».
2. Объём ограничен одной функцией, а не платформой. Названы конкретный тип продукта и один сценарий использования — не «система для всей школы», а утилита с одной операцией.
3. Есть чем доказывать работоспособность. Продукт запускается на чужом устройстве и проверен кем-то, кроме автора, а не существует только в виде кода на экране разработчика.

Тему стоит приносить руководителю не голой формулировкой, а сразу с тремя пунктами: задача, какой язык и инструменты понадобятся, кто станет пользователем первой версии. На «хочу сделать бота» возразить нечего конкретного, а на «хочу бота, который проверяет доклады одноклассников на превышение лимита слов, и планирую протестировать на десяти черновиках» руководитель сразу видит объём и может сказать, реалистичен ли он для вашего класса.

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

15 тем для быстрого старта

Формулировки ниже уже прошли три проверки выше. Полный список — с продуктом на выходе и разбором по классам 9–11 — в статье темы индивидуального проекта по программированию.

1. Бот-таймер для контроля времени на контрольной работе
2. Скрипт для проверки докладов на объём и запрещённые сокращения
3. Тренажёр по формулам физики с проверкой ответа и счётом очков
4. Текстовый квест по школьному зданию с тремя концовками
5. Утилита для сортировки конспектов по предметам на основе имени файла
6. Бот-словарь профессиональных терминов для кружка робототехники
7. Веб-страница с расписанием факультативов, которая обновляется из таблицы
8. Генератор карточек для запоминания дат по истории из готового списка
9. Скрипт для подсчёта, сколько времени класс проводит за экраном по анкете
10. Приложение-счётчик прочитанных страниц с недельной статистикой
11. Парсер отзывов о школьных кружках с сайта родительского комитета
12. Сравнение трёх алгоритмов поиска на собственных тестовых данных
13. Мобильное приложение для учёта карманных расходов с категориями
14. Автоматическая проверка орфографии стоп-словами для черновиков сочинений
15. Генератор индивидуальных расписаний тренировок по введённым данным

Первые пять тем строятся на одной чётко очерченной функции — они самые компактные и подходят, если сроки сжаты. Темы 6–10 требуют работы с внешними данными (файлом, таблицей, сайтом) и чуть объёмнее по коду — их логичнее брать в 10 классе. Темы 11–15 предполагают собственную архитектуру из нескольких модулей и тестирование на группе пользователей — это отдельная методика разработки, а не только написание скрипта за вечер.

Если тема получилась слишком широкой

Материала для программирования всегда кажется больше, чем реально помещается в школьный проект — любая идея быстро обрастает «а ещё можно добавить». Проверка на сужение простая: продукт должен описываться одним предложением без союза «и», а первая рабочая версия — быть готова через месяц после старта.

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

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

План и структура: по главам

Структура проекта по программированию устроена так же, как у любого другого предмета, но содержание глав — своё:

1. Титульный лист, содержание.
2. Введение — актуальность, задача продукта, объект (пользователи и их проблема), предмет (конкретная функция, которую реализует продукт), цель, задачи.
3. Глава 1 — теоретическая: обзор аналогов и технологий, которые подходят для решения задачи.
4. Глава 2 — практическая: архитектура продукта, реализация, тестирование.
5. Заключение — вывод по каждой задаче из введения, а не общие слова о пользе программирования.
6. Список литературы — техническая документация, статьи по теме и источники аналогов, не только форумы с советами без ссылок.
7. Приложения — полный листинг кода или ссылка на репозиторий, схема архитектуры, протокол тестирования.

Типичная ошибка главы 1 — она превращается в пересказ документации языка или библиотеки без выхода на задачу проекта: абзацы про то, что такое переменные и циклы, вместо обзора конкретных аналогов и объяснения, почему выбран именно этот стек технологий.

Ориентировочный объём по главам для 9 класса — 12–18 страниц без приложений:

Для 10–11 класса пропорции те же, но растут сложность архитектуры и число протестированных сценариев — вместо одного модуля в девятом классе к одиннадцатому продукт обычно состоит из нескольких взаимодействующих частей.

Если руководитель просит другую разбивку — например, отдельную главу с планом спринтов или дополнительный раздел про безопасность данных — эта структура не единственно верная, а рабочий минимум: убирать схему архитектуры или протокол тестирования из практической части не стоит ни при каком варианте требований, без них работа перестаёт быть исследованием и превращается в демонстрацию готового кода без объяснений.

Актуальность: первое, что проверяет руководитель

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

Рабочий ход: сначала фиксируется наблюдение в одном-двух предложениях (одноклассники теряют время на ручной подсчёт слов в докладе; готовые приложения для контроля времени на контрольной перегружены лишними функциями), потом объясняется, почему это стоит решить именно сейчас — не «программирование развивается», а «аналоги либо платные, либо избыточно сложны для этой узкой задачи». Продукт сразу отвечает на вопрос «кому пригодится»: конкретным одноклассникам, кружку, самому автору при подготовке к экзамену по профилю.

Подробный разбор актуальности с готовыми оборотами — в статье про введение индивидуального проекта.

Практическая часть: как работать с кодом

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

• Архитектура фиксируется до первой строки кода. Схема с частями продукта и связями между ними рисуется заранее — она же становится опорой для главы 2 и приложением к работе.
• История разработки ведётся в репозитории по коммитам. Небольшие осмысленные коммиты с понятными сообщениями показывают, что продукт собирался постепенно, а не был скопирован за одну ночь перед сдачей.
• Тестирование ведётся протоколом, а не памятью. Список сценариев, кто их проверял и что нашли — фиксируется в таблице, а не пересказывается устно на защите.
• Рефакторинг документируется отдельно от новых функций. Если код переписывался для ясности, это отмечается отдельным разделом — комиссия должна видеть, что улучшение архитектуры было осознанным шагом, а не случайностью.

Пример для темы про проверку докладов: сначала фиксируются все типичные нарушения объёма и сокращений на 10 черновиках вручную, потом эти же 10 черновиков прогоняются через написанный скрипт, и результаты сравниваются построчно — расхождения между ручной и автоматической проверкой и дают содержательный вывод главы, а не сам факт того, что скрипт запустился без ошибок.

Где искать источники

Без обзора источников теоретическая глава превращается в пересказ документации без единой мысли о задаче проекта. Рабочие места для поиска:

• «КиберЛенинка» и eLibrary — статьи по алгоритмам, архитектуре ПО и смежным темам, часто в открытом доступе целиком.
• Официальная документация языка и используемых библиотек — первичный источник для раздела про выбор инструментов, а не пересказ чужого пересказа документации.
• Открытые репозитории на GitHub с похожими проектами — материал для обзора аналогов: как решена та же задача другими и в чём отличие вашего подхода.
• Профильные технические блоги и статьи с разбором архитектурных решений — источник контекста для главы 1, при условии, что у статьи указан автор и дата.

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

Продукт: что показать на защите

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

• Бот с одной функцией — работающий диалог, который комиссия может протестировать сама на телефоне.
• Тренажёр или игра — веб-страница или консольное приложение с понятной механикой за минуту без объяснений.
• Утилита для обработки данных — скрипт, который решает конкретную рутинную задачу и выводит результат.
• Мобильное или настольное приложение — интерфейс, данные и логика, запускающиеся на чужом устройстве.
• Тестовый набор для чужого проекта — код с покрытием и отчётом о найденных ошибках, если тема про проверку, а не про написание с нуля.

Продукт выбирается под задачу, а не по принципу «что легче собрать из шаблона»:

Подробнее про требования к продукту — в статье про продукт индивидуального проекта.

Пример целиком: от идеи до плана

Идея. Хочется сделать что-то полезное для одноклассников, но пока непонятно, что именно.

Сужение. Слишком общо. Что конкретно мешает? Доклады часто превышают лимит по объёму, а проверять это вручную долго. Что можно автоматизировать? Подсчёт слов и поиск запрещённых сокращений.

Тема. «Скрипт для проверки докладов на объём и запрещённые сокращения перед сдачей».

Объект. Черновики докладов одноклассников в текстовом формате.

Предмет. Автоматическая проверка объёма текста и разметка проблемных мест по словарю сокращений.

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

Задачи. 1) собрать список типичных нарушений объёма и сокращений на 10 черновиках вручную; 2) написать модуль подсчёта слов и поиска сокращений по словарю; 3) сделать интерфейс командной строки с выводом отчёта; 4) прогнать те же 10 черновиков через скрипт и сравнить результат с ручной проверкой.

Продукт. Скрипт с текстовым отчётом и репозиторием с историей коммитов.

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

Если времени меньше — например, до защиты остаётся не месяц, а две недели, — план сжимается, но логика та же: словарь сокращений сокращается до одной категории вместо нескольких, а сравнение с ручной проверкой делается на 5 черновиках вместо 10. Продукт и задачи остаются той же формы, просто объём тестовых данных меньше.

Оформление и защита

Формат страницы и общий подход задаёт ФГОС, а точные цифры — интервалы, отступы, требования к титульному листу — устанавливает положение конкретной школы. Специфика для проекта по программированию:

• листинг кода в основном тексте ограничивается разобранным фрагментом в 15–20 строк, полный код уходит в приложение или прикладывается ссылкой на репозиторий;
• схема архитектуры оформляется как обычный рисунок с подписью и номером, а не вставляется скриншотом без объяснения;
• список зависимостей и версия языка фиксируются отдельно — это часть воспроизводимости продукта, а не техническая деталь;
• ссылка на репозиторий оформляется в списке источников отдельной строкой, с указанием даты последнего коммита на момент сдачи.

Подробный разбор с примерами — в статье про оформление по ГОСТу.

Защита строится вокруг презентации на 8–12 слайдов и речи на 5–10 минут. Для темы по программированию в презентацию обязательно идёт живая демонстрация продукта, а не только скриншоты — комиссия должна увидеть, что продукт запускается и работает без участия автора за клавиатурой в роли «волшебника за шторкой».

На защите проекта по программированию чаще всего спрашивают:

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

Порядок защиты — в статье про защиту проекта, готовая речь — в статье про речь для защиты, критерии оценивания — в статье про критерии оценивания проекта.

Частые ошибки

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

• Тема без конкретной задачи. «Полезное приложение» описывает намерение, а не то, что продукт реально делает.
• Шаблон с изменённым текстом кнопок. Логика скопирована из туториала, доработана только визуально — на первом же вопросе про архитектуру это вскрывается.
• Нет истории коммитов. Весь код появляется в репозитории одним разом перед сдачей, что выглядит как перенос готового проекта.
• Тестирование только автором. Продукт не пробовал никто, кроме разработчика, ошибки на чужом устройстве не найдены.
• Листинг на двадцать страниц в основном тексте. Комиссия не читает код построчно, ей нужен разобранный фрагмент и вывод.
• Зависимости не зафиксированы. У комиссии продукт не запускается, потому что версия библиотеки не указана.
• Демонстрация скриншотами вместо запуска. Работающий продукт не показан вживую, только его изображения.

Чек-лист перед сдачей

1. Актуальность объясняет, какой проблемы не хватает готового решения и кому пригодится продукт.
2. Задача продукта описывается одним предложением без союза «и».
3. Сделан обзор аналогов с обоснованием, чем выбранное решение отличается.
4. Есть схема архитектуры продукта, а не только код.
5. Разобран ключевой фрагмент кода в 15–20 строк с пояснением.
6. Продукт протестирован кем-то, кроме автора, и есть протокол тестирования.
7. Репозиторий содержит историю коммитов, а не один финальный код.
8. Зависимости и версия языка зафиксированы для воспроизводимости.
9. Чужой код и примеры из документации помечены ссылкой на источник.
10. Заключение отвечает на каждую задачу из введения отдельным абзацем.
11. Презентация и живая демонстрация продукта отрепетированы минимум дважды.

Что дальше

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

Матчасть по каждому шагу: структура проекта · продукт проекта · оформление по ГОСТу · защита проекта · критерии оценивания.

Если продукт написан, а пояснительная записка не складывается, Нейросова соберёт индивидуальный проект по программированию по вашей теме — с введением, обзором аналогов и списком литературы, которые останется доработать разбором своего кода.