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

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

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

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

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

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

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

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

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

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

1. Автоматический учёт дежурств в классе через таблицу со скриптом
2. Сравнение планировщиков задач для командной работы над проектом
3. Юзабилити-тест сайта школы: путь пользователя по пяти сценариям
4. Дашборд посещаемости факультатива на основе выгрузки из журнала
5. Аудит разрешений мобильных приложений одноклассников: что они знают о нас
6. Электронная запись к школьному психологу: сравнение с очередью на бумаге
7. Автоматическая рассылка напоминаний о дедлайнах через форму и таблицу
8. Сравнение мессенджеров для школьного чата по функциям и приватности
9. Цифровая афиша мероприятий школы с автообновлением расписания
10. Госуслуги для школьника: путь пользователя по пяти сценариям
11. Опрос об экранном времени класса и визуализация результата в дашборде
12. Электронный документооборот школы: где теряется время при переходе с бумаги
13. Вакансии в ИТ без диплома программиста: разметка объявлений по требованиям
14. Электронный дневник: сравнение интерфейса для трёх ролей пользователей
15. Фишинговые письма: распознают ли их одноклассники — тест и обучающий стенд

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

Как сузить слишком общую тему

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

• Один сервис или несколько? «Сравнение облачных технологий» превращается в «сравнение трёх сервисов для опросов по пяти критериям на своей задаче» — сервисы названы, задача одна.
• Одна функция или весь функционал? «Настройка электронного документооборота» превращается в «автоматизация одного отчёта: от ручного переноса данных до готового результата за одно действие».
• Что именно измеряется? Если ответ — «удобство» без числа, добавляется конкретный критерий: время выполнения задачи, число кликов, доля успешных попыток на тесте.

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

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

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

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

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

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

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

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

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

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

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

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

Практическая часть: как работать с готовым инструментом

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

• Замер «до» фиксируется первым, до всякой настройки. Время на ручную операцию, число ошибок, число кликов до результата — без стартовой точки сравнение «стало лучше» не подтвердить ничем, кроме слов.
• Критерии сравнения задаются заранее и одинаковы для всех вариантов. Если сравниваются три сервиса для опросов, каждый проверяется по одному и тому же списку — время сборки, число полей, экспорт данных, — а не по случайным впечатлениям.
• Тестирование на 5–10 пользователях обязательно для 10–11 класса. Собственная оценка удобства ничего не доказывает: комиссию убеждает протокол, где зафиксировано, кто и с какой проблемой столкнулся.
• Опрос уместен только там, где тема про людей — приватность, удобство, восприятие. Для темы про автоматизацию отчёта опрос не нужен: там решает замер времени, а не мнение респондентов.

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

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

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

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

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

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

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

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

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

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

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

Идея. Хочется сделать проект про технологии, но пока непонятно, про что именно — тема слишком общая.

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

Тема. «Электронный дневник: сравнение интерфейса для ученика, родителя и учителя по пяти критериям».

Объект. Интерфейс электронного дневника, используемого в школе.

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

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

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

Продукт. Сравнительная таблица по пяти критериям с рекомендациями, оформленная как памятка для родительского комитета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше

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

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

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