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

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

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

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

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

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

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

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

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

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

1. Бот-напоминание о домашних заданиях с рассылкой по расписанию
2. Тренажёр слепой печати с замером скорости и прогрессом ученика
3. Скрипт сортировки школьного фотоархива по датам и папкам
4. Интерактивный справочник по формулам с поиском и категориями
5. Игра-викторина по предмету на 40 вопросов со счётом очков
6. Анализ успеваемости класса за год с диаграммами по предметам
7. Сравнение алгоритмов сортировки на своих данных с замером времени
8. Скрипт автоматической проверки домашних работ по шаблону
9. Сайт школьного кружка с адаптивной вёрсткой и публикацией
10. Юзабилити школьного сайта: тест на 10 пользователях со списком проблем
11. Открытые данные города: своя визуализация в виде интерактивной страницы
12. Тренажёр по одной теме школьной программы с генерацией примеров
13. Бот-опросник для сбора обратной связи после мероприятия
14. Резервное копирование школьных материалов: сравнение трёх способов
15. Что смотрят одноклассники: анализ опроса с кластеризацией ответов

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

Как понять, что тему пора сузить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Архитектура описывается схемой до того, как разбирается код. Что откуда получает данные, куда их отдаёт, какие модули за что отвечают — без этой схемы разбор фрагментов выглядит случайным набором строк.
• Разбирается не весь листинг, а 15–20 ключевых строк. Тот фрагмент, где сосредоточена основная логика продукта, с построчным пояснением — остальное уходит в приложение или репозиторий.
• Тестирование проводится на реальных пользователях, а не только самим автором. 5–10 человек, конкретные сценарии, список найденных проблем и что было исправлено по итогу.
• Заимствованный код помечается ссылкой на источник. Использование готовой библиотеки — нормальная практика, если это явно указано; выдавать чужой код за свой — плагиат, который вскрывается на вопросах комиссии.

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

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

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

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

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

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

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

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

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

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

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

Идея. Хочется написать что-то на Python, но пока непонятно, что именно — тем слишком много.

Сужение. Слишком широко. Что реально раздражает в повседневной школьной жизни? Расписание кружка меняется, и половина участников узнаёт об этом слишком поздно. Можно сделать бота с одной функцией.

Тема. «Телеграм-бот, который присылает расписание своего кружка на завтра».

Объект. Процесс информирования участников кружка о расписании занятий.

Предмет. Автоматическая рассылка актуального расписания через бота вместо ручного оповещения в чате.

Гипотеза. Если рассылку расписания автоматизировать ботом, число участников, узнавших об изменении вовремя, вырастет минимум до 90%.

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

Продукт. Работающий телеграм-бот с инструкцией по подключению для другого кружка.

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

Если времени на полноценное тестирование не хватает, план сжимается, но логика та же: тема сужается до одной функции без расширения, а не до общего впечатления от идеи. Для примера выше без полноценного тестирования это выглядело бы так — «Телеграм-бот с расписанием кружка: разработка и проверка на своей группе», задачи и продукт остаются той же формы, просто выборка для теста меньше и период короче.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше

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

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

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