Курсовая по программной инженерии в НИЯУ МИФИ: AI-системы, архитектура, тестирование и качество критичного ПО

Курсовая по программной инженерии в НИЯУ МИФИ имеет прямую связь с актуальными программами 2026 года. В перечне направления 09.03.04 указаны программы по программной инженерии искусственного интеллекта, конструктивным моделям в информационных и интеллектуальных системах и моделированию когнитивных процессов.

Официальная страница:
https://admission.mephi.ru/admission/baccalaureate-and-specialty/education/programs

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

Требования раньше архитектуры

До выбора технологии ответьте:

• кто пользователь;
• какая задача;
• какой результат;
• какие ограничения.

Например:

«Сервис принимает поток событий и обнаруживает аномалии с p95 задержки ниже X мс».

Это уже влияет на архитектуру.

Functional requirement

Пример:

«Система сохраняет результат анализа».

Non-functional requirement

Пример:

«Система выдерживает N запросов в секунду».

Эти требования нельзя смешивать.

Они проверяются по-разному.

Scope

Зафиксируйте:

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

Это защищает работу от бессмысленного роста.

Architecture drivers

Выберите 3-5 факторов:

• performance;
• reliability;
• security;
• modifiability;
• data volume.

Не проектируйте всё одинаково важным.

Monolith или services

Для небольшой курсовой monolith часто рационален.

Если нужны microservices, покажите причину:

• независимое масштабирование;
• разные failure domains;
• отдельный lifecycle.

Не дробите систему ради диаграммы.

ADR

Для важного решения создайте запись:

Проблема
Варианты
Выбор
Последствия

Например, выбор message broker.

Так решение становится аргументированным.

Domain boundaries

Особенно для сложной системы важно отделить:

• domain;
• infrastructure;
• interface.

Не смешивайте бизнес-правила и SQL в одном модуле.

API contract

Опишите несколько endpoint.

Для каждого:

• request;
• response;
• error;
• permission.

Это позволяет тестировать interface независимо.

Versioning

Если contract может меняться, задайте стратегию.

Для курсовой достаточно показать:

• v1;
• compatibility;
• deprecation idea.

Не нужна сложная enterprise governance.

Data model

Для critical system особенно важны:

• constraints;
• history;
• traceability.

Сущность должна иметь устойчивый identifier.

Не используйте название как primary key.

Event log

Если система обрабатывает события, продумайте:

• id;
• time;
• source;
• type;
• payload version.

Это упрощает воспроизводимость.

Idempotency

Повторная доставка event не должна обязательно создавать duplicate effect.

Покажите механизм:

• unique event id;
• deduplication.

Это хороший инженерный кейс.

Unit tests

Проверяйте чистую domain logic отдельно.

Это делает тесты быстрыми.

Не запускайте DB для каждого маленького правила.

Integration tests

Проверяйте:

• DB;
• queue;
• model service;
• external API.

Такие границы особенно критичны.

Contract tests

Если AI model service отделён от backend, зафиксируйте contract.

Например:

input schema
output schema
model version.

Это снижает риск неожиданной несовместимости.

End-to-end

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

Но E2E не должен заменять все остальные tests.

Он медленнее и хуже локализует bug.

Test doubles

Для внешнего API можно использовать mock.

Но хотя бы один integration test должен проверять реальный contract в контролируемой среде, если это возможно.

Property testing

Для parser, validator или numerical function можно проверять свойства на множестве входов.

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

Mutation testing

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

Высокий coverage не гарантирует, что test действительно что-то проверяет.

CI

Pipeline:

1. lint;
2. static analysis;
3. unit;
4. integration;
5. build.

Для security-critical темы можно добавить dependency scan.

Reproducible build

Зафиксируйте dependency versions.

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

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

Container

Docker может фиксировать runtime.

Но container не заменяет документацию.

Покажите:

• image;
• config;
• healthcheck.

Secret management

Не храните token в repo.

Для demo используйте env variables или безопасный placeholder.

Проверьте Git history.

Logging

Логируйте:

• event;
• request id;
• status;
• error.

Не логируйте секреты.

В critical system traceability важнее огромного объёма логов.

Monitoring

Метрики могут быть:

• request rate;
• error rate;
• p95;
• queue;
• model failures.

Выберите те, что связаны с SLO.

SLO

Например:

99% запросов за период завершаются без server error.

Не ставьте «99,999%» без реальной необходимости.

Fault injection

Проверьте:

• DB timeout;
• service unavailable;
• duplicate message;
• corrupted input.

Система должна предсказуемо реагировать.

Retry

Retry должен учитывать idempotency.

Иначе при timeout клиент может создать duplicate operation.

Это особенно важно в распределённой системе.

AI component

Если проект включает модель, версия модели является частью software artifact.

Сохраняйте:

• model id;
• dataset version;
• parameters.

Не заменяйте один файл модели другим без traceability.

Model fallback

Что произойдёт, если AI service недоступен?

Варианты:

• queue;
• manual mode;
• fail closed;
• simple baseline.

Это архитектурное решение.

Performance

Для AI-service разделите:

• preprocessing;
• inference;
• postprocessing.

Профиль покажет, где latency.

Не оптимизируйте model, если bottleneck в I/O.

Load test

Измерьте:

• p50;
• p95;
• errors;
• throughput.

Покажите точку saturation.

Не ограничивайтесь одним числом запросов.

Security

Для программной инженерии в контексте МИФИ уместно показать:

• auth;
• role;
• validation;
• secrets;
• dependency control.

Но не обещайте абсолютную защищённость.

Documentation

Минимум:

• architecture;
• API;
• setup;
• tests;
• deployment.

Другой человек должен уметь поднять проект без устных инструкций.

Технический долг

Зафиксируйте:

• shortcoming;
• impact;
• proposed action.

Например:

«Нет horizontal scaling model service».

Это делает проект честнее.

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

Схема:

1. requirements;
2. drivers;
3. architecture;
4. data;
5. implementation;
6. test strategy;
7. CI;
8. performance;
9. fault tests;
10. technical debt.

Контекст НИЯУ МИФИ

Программная инженерия МИФИ в актуальном наборе тесно связана с AI и интеллектуальными системами.

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

Защита

Будьте готовы показать requirement, ADR, integration test, CI, load test и failure mode.

Сильная курсовая по программной инженерии в НИЯУ МИФИ показывает, как система сохраняет корректность и управляемость не только в идеальном сценарии.