Курсовая работа

Курсовая по прикладной информатике в СПбГУ: как соединить данные, предметную область и работающий цифровой продукт

Как писать курсовую по прикладной информатике в СПбГУ: выбрать прикладную задачу, собрать данные, реализовать систему или AI-модель и проверить результат.

Содержание +

Курсовая по прикладной информатике в СПбГУ в 2026 году имеет конкретный образовательный контекст. В актуальном наборе университета есть несколько программ по направлению «Прикладная информатика», включая «Искусственный интеллект и наука о данных», Computer Science and Artificial Intelligence и прикладную информатику в области искусств и гуманитарных наук.

Официальный список программ:
https://cabinet.spbu.ru/Lists/ForeignersLists/bak/index_comp_groups.html

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

Начните с предметной задачи

Слабая тема:

«Разработка информационной системы».

Непонятно, для кого она нужна, какую проблему решает и чем измерить результат.

Сильнее:

«Разработка системы классификации обращений пользователей по тематике и приоритету».

Или:

«Информационная система для анализа цифрового архива с полнотекстовым поиском и тематической разметкой».

Здесь технология встроена в задачу.

Предметная область должна быть реальной

Прикладная информатика находится на границе IT и другой области.

Это может быть экономика, медицина, образование, искусство, история, управление или наука о данных.

Сначала разберитесь, как работает процесс без вашей системы. Только потом проектируйте решение.

Зафиксируйте As-Is

Опишите текущую процедуру:

1. откуда приходит информация;
2. кто её обрабатывает;
3. где хранит;
4. что проверяет;
5. где возникает задержка;
6. какие ошибки повторяются.

Например, сотрудник вручную сводит данные из трёх Excel-файлов. Это уже основание для автоматизации.

Измеримый baseline

До разработки полезно знать:

  • среднее время операции;
  • число ручных шагов;
  • долю ошибок;
  • число возвратов;
  • объём данных.

Если после внедрения ничего не измеряется, нельзя доказать, что решение действительно лучше.

Требования

Не начинайте с таблиц БД.

Сначала сформулируйте пользовательские требования.

Например:

«Аналитик загружает файл и получает отчёт о пропусках и дубликатах».

После этого системное требование:

«Сервис должен проверять обязательные поля и возвращать список строк с ошибками».

Так появляется связь между потребностью и реализацией.

Данные

Для data-driven темы опишите:

  • источник;
  • формат;
  • объём;
  • период;
  • поля;
  • ограничения.

Если dataset собран из открытого источника, сохраните URL и дату выгрузки.

Если данные синтетические, так и напишите. Не выдавайте учебный набор за реальные данные организации.

Качество данных

До модели или дашборда проверьте:

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

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

Data lineage

Полезно показать путь:

source -> import -> validation -> transformation -> result.

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

Модель данных

Если создаётся информационная система, определите сущности.

Например:

  • пользователь;
  • документ;
  • проект;
  • объект;
  • событие;
  • результат.

Связи между сущностями должны соответствовать реальному процессу. Не храните всё в одной универсальной таблице только ради скорости разработки.

Ограничения БД

Часть качества можно закрепить через:

  • UNIQUE;
  • NOT NULL;
  • FOREIGN KEY;
  • CHECK.

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

API

Для backend-проекта покажите несколько ключевых endpoint.

Например:

POST /datasets
POST /analysis
GET /analysis/{id}

Для каждого достаточно описать запрос, ответ и ошибку. Не превращайте курсовую в распечатанный Swagger.

Прототип

Лучше полностью реализовать один основной сценарий, чем частично десять.

Например:

загрузка -> проверка -> анализ -> результат -> экспорт.

Это позволяет показать работу системы на защите.

Если тема про AI

Тогда информационная система и модель должны быть разделены.

Модель отвечает за prediction, classification или ranking.

Система отвечает за данные, API, права, сохранение результата и интерфейс.

Notebook сам по себе ещё не прикладная система.

Train и test

Если используется ML, тестовый набор не участвует в подборе параметров.

Покажите train, validation и test.

Особенно внимательно следите за дубликатами объектов между частями.

Baseline модели

Сравните сложный алгоритм с простым.

Для классификации это может быть majority class, logistic regression или rule.

Если сложная модель выигрывает минимально, обсудите, оправдана ли сложность.

Метрика

Выбирайте под задачу.

При несбалансированных классах одной accuracy мало.

Смотрите precision, recall и F1.

Для регрессии можно использовать MAE и RMSE.

Не используйте метрику только потому, что она есть в библиотеке.

Ошибки модели

Разберите несколько неправильных предсказаний.

Например:

  • редкий класс;
  • неоднозначный текст;
  • плохое качество исходного файла;
  • ошибка разметки.

Так становится видно, что вы понимаете ограничения алгоритма.

Если тема гуманитарная

В СПбГУ есть отдельная программа прикладной информатики в области искусств и гуманитарных наук.

Это может вести к проектам:

  • цифровой архив;
  • анализ текстового корпуса;
  • каталог изображений;
  • граф связей;
  • GIS исторических объектов.

В таком проекте IT-часть должна помогать исследовательскому вопросу, а не жить отдельно.

Полнотекстовый поиск

Если система работает с текстами, оцените скорость, качество результатов, stemming, язык и фильтры.

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

Информационный поиск

Для развитой темы можно измерять precision@k, recall и MRR.

Нужен набор релевантности. Без него качество поиска оценивается только субъективно.

UX

Интерфейс должен соответствовать пользователю.

Исследователь не обязан знать технические имена полей БД.

Показывайте понятные ошибки, единицы, preview и состояние операции.

Безопасность

Минимально продумайте authentication, authorization, validation и secrets.

Не храните пароль и токен в открытом репозитории.

Персональные данные

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

Не добавляйте реальные ФИО и телефоны ради реалистичности демонстрации.

Тестирование

Свяжите тесты с требованиями.

Требование: нельзя создать объект без обязательного поля.

Тест: запрос без поля.

Ожидаемо: отказ с понятной ошибкой.

Так test проверяет функцию системы, а не просто строку кода.

Производительность

Если заявлена работа с большими данными, покажите реальный объём.

Например:

10 тыс.
100 тыс.
1 млн строк.

Измерьте время и память. Для сервера добавьте p95.

Не пишите «быстро работает» без числа.

Эксперимент

Хороший прикладной эксперимент сравнивает до и после.

Например:

ручная проверка 25 минут;

система 6 минут;

доля пропущенных ошибок сохранилась или снизилась.

Это сильнее скриншота интерфейса.

Практическая глава

Логичная последовательность:

1. предметная область;
2. As-Is;
3. требования;
4. данные;
5. архитектура;
6. реализация;
7. тесты;
8. эксперимент;
9. эффект;
10. ограничения.

Контекст СПбГУ

В 2026 году прикладная информатика в СПбГУ представлена несколькими программами, поэтому работа по AI, data science и гуманитарной информатике не должна строиться по одному шаблону.

Смотрите название именно своей образовательной программы.

Защита

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

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

Ещё по теме