Запрос «курсовая по программной инженерии в МГУ» не всегда означает отдельное название бакалаврского направления. На ВМК МГУ программная инженерия представлена в учебных дисциплинах, специализациях и IT-подготовке, а основной набор факультета включает такие направления, как прикладная математика и информатика и фундаментальная информатика и информационные технологии.
Поэтому в курсовой важно опираться на реальный курс и учебный план, а не автоматически писать, будто студент обучается на отдельной программе 09.03.04.
Официальные ресурсы ВМК:
https://cs.msu.ru/education/bachelors
https://cs.msu.ru/studies/curricula
https://iit.cs.msu.ru/studying_process/distant
Программная инженерия шире программирования
Программирование отвечает:
как написать код?
Программная инженерия добавляет:
- требования;
- архитектуру;
- управление изменениями;
- тестирование;
- качество;
- сборку;
- развёртывание;
- сопровождение.
Курсовая должна показывать этот цикл.
Начните с требований
До выбора фреймворка сформулируйте:
- пользовательские сценарии;
- функциональные требования;
- ограничения;
- критерии приёмки.
Плохо:
«Создать удобный сервис».
Лучше:
«Пользователь загружает CSV до 50 МБ и получает отчёт не позднее N секунд при корректном формате».
Теперь требование проверяемо.
User story
Например:
Как аналитик я хочу загрузить набор данных, чтобы получить отчёт по качеству.
Добавьте критерии приёмки.
Иначе user story остаётся пожеланием.
Нефункциональные требования
Для проекта выберите действительно важные:
- latency;
- throughput;
- доступность;
- безопасность;
- maintainability.
Не копируйте универсальный список из учебника.
Архитектура
Покажите компоненты и ответственность.
Например:
- frontend;
- API;
- service;
- database;
- worker.
Не делайте архитектуру перечнем технологий.
PostgreSQL и FastAPI сами по себе не объясняют структуру.
Связность и ответственность
Каждый модуль должен иметь ясную роль.
Если один класс:
- читает файл;
- валидирует;
- считает;
- пишет в БД;
- отправляет письмо,
его слишком трудно тестировать и менять.
Интерфейсы
Определите контракт между модулями.
Например:
input -> output -> error.
Хороший интерфейс уменьшает зависимость частей.
ADR
Architecture Decision Record полезен для ключевых решений.
Например:
Решение: использовать очередь задач.
Причина: длительные операции не должны блокировать HTTP-запрос.
Альтернатива: синхронная обработка.
Так архитектура становится аргументированной.
Git
Используйте историю разработки.
Хороший процесс:
- небольшие коммиты;
- содержательные сообщения;
- ветка для задачи;
- review, если есть команда.
Один коммит «final» не показывает инженерный процесс.
Issue tracker
Даже в индивидуальной работе удобно вести:
- задачу;
- bug;
- enhancement;
- статус.
Так видно, как требования превращаются в изменения кода.
Traceability
Сильный проект связывает:
требование -> реализация -> тест.
Например:
FR-04 -> UploadService -> test_upload_invalid_format.
Это гораздо убедительнее общего заявления «всё протестировано».
Unit tests
Проверяют маленький блок.
Для чистой функции вход и ожидаемый выход должны быть понятными.
Не тестируйте детали реализации, если можно проверить поведение.
Integration tests
Проверяют связь:
- API и БД;
- сервис и очередь;
- приложение и внешний API.
Именно интеграции часто ломаются в реальных системах.
End-to-end
Проверяет пользовательский сценарий целиком.
Например:
регистрация -> загрузка -> обработка -> отчёт.
Таких тестов обычно меньше, потому что они медленнее.
Test pyramid
Идея полезна как ориентир:
- много быстрых unit;
- меньше integration;
- ещё меньше end-to-end.
Не воспринимайте пропорции как жёсткий стандарт для любого проекта.
Coverage
100% покрытия строк не гарантирует качество.
Можно выполнить строку, но не проверить правильность результата.
Coverage используйте как сигнал, а не цель.
