Курсовая по информационным системам и технологиям в НИЯУ МИФИ: архитектура, интеграции, данные и эксплуатация

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

Официальные страницы:
https://admission.mephi.ru/admission/baccalaureate-and-specialty/education/moscow
https://admission.mephi.ru/admission/baccalaureate-and-specialty/education/regional

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

Плохо:

«Создание базы данных предприятия».

Сильнее:

«Разработка системы учёта состояния оборудования с историей событий и контролем сроков технического обслуживания».

Теперь понятны пользователи, данные и проверяемый результат.

Пользовательские роли

Определите:

• operator;
• engineer;
• manager;
• administrator.

Для каждой роли:

• что видит;
• что меняет;
• что подтверждает.

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

Требования

Разделите:

• functional;
• non-functional;
• constraints.

Например:

«Инженер регистрирует событие» - функция.

«p95 открытия карточки меньше 500 мс» - качество.

Acceptance criteria

Для важного требования задайте тест.

Например:

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

Так требования превращаются в проверяемое поведение.

Предметная модель

Сущности должны отражать реальный процесс.

Например:

• equipment;
• event;
• maintenance;
• document;
• user;
• status.

Не называйте таблицы `data1`, `data2`.

ER-диаграмма

Покажите:

• cardinality;
• keys;
• constraints.

M:N обычно требует отдельной таблицы.

Не храните список связанных ID строкой через запятую.

История состояния

Для инженерной системы часто важно знать не только текущий status, но и историю.

Сохраняйте:

• old value;
• new value;
• actor;
• time.

Это полезно и для анализа, и для аудита.

Справочники

Единые справочники нужны для:

• equipment type;
• department;
• failure code;
• status.

Без них аналитика быстро ломается.

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

Проверьте:

• missing;
• duplicate;
• impossible value;
• inconsistent dictionaries.

До дашборда нужно сначала сделать данные пригодными.

Импорт

Если источник Excel или CSV, валидируйте:

• schema;
• type;
• unit;
• duplicate.

Пользователь должен видеть конкретную ошибочную строку.

API

Опишите несколько ключевых операций.

Например:

POST /equipment
POST /events
GET /maintenance/overdue.

Для каждого покажите input, output и error.

Не вставляйте сотни endpoint.

Интеграция

Информационная система может получать данные из:

• sensor platform;
• ERP;
• external database;
• file exchange.

Определите owner данных.

Не создавайте вторую master-систему случайно.

ETL

Для загрузки:

extract -> validate -> transform -> load.

Лучше иметь staging layer, если исходные данные грязные.

Не грузите всё напрямую в боевую таблицу.

Идентификатор

Оборудование или документ должны иметь устойчивый ID.

Название может меняться.

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

Временные данные

Для состояния оборудования важны timestamps.

Храните timezone осознанно.

Не смешивайте local time разных площадок без правила.

Асинхронная задача

Если отчёт или обработка длится долго, используйте job.

Пользователь получает ID и статус.

Не держите HTTP request бесконечно.

Очередь

Покажите:

queued -> running -> completed/failed.

Если worker падает, задача не должна исчезнуть без следа.

Retry

Повторять стоит только временную ошибку.

Bad input не исправится от десятого retry.

Опишите policy.

Транзакции

Если операция меняет несколько сущностей, решите, должна ли она быть atomic.

Например, создание события и обновление status оборудования.

Половина выполненной операции может нарушить целостность.

Авторизация

Разделите:

authentication
и
authorization.

Пользователь может войти, но не иметь права менять критичный объект.

Создайте negative tests.

RBAC

Матрица ролей делает права понятными.

Например:

| Действие | Оператор | Инженер | Админ |
|---|---|---|---|
| Просмотр | да | да | да |
| Закрытие | нет | да | да |

Логирование

Для эксплуатации фиксируйте:

• timestamp;
• request id;
• event;
• error.

Не логируйте password и secret.

Аудит

Для критичных изменений audit trail нужен отдельно от обычного debug log.

Он отвечает на вопрос:

кто и когда изменил состояние.

Monitoring

Выберите несколько метрик:

• request errors;
• p95 latency;
• queue length;
• failed jobs.

Не создавайте дашборд из всего, что умеет monitoring system.

Надёжность

Проверьте:

• DB unavailable;
• external API timeout;
• corrupt file;
• duplicate request.

Сильная система имеет предсказуемую реакцию.

Backup

Опишите:

• что копируется;
• frequency;
• retention;
• restore test.

Backup без теста восстановления остаётся предположением.

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

Если система должна хранить большой журнал, тестируйте реальный scale.

Например:

1 млн events.

Сравните query time до и после index.

Index

Индекс должен соответствовать query.

Например:

equipment_id + timestamp.

Не создавайте десятки индексов автоматически.

Они увеличивают storage и стоимость записи.

Partitioning

Для очень большой history можно разделять таблицу по времени.

Но это имеет смысл только при реальном объёме.

Не добавляйте сложность ради современного термина.

UI

Интерфейс должен помогать работе.

Для инженерной системы полезны:

• status;
• warning;
• filter;
• history.

Не делайте интерфейс главным содержанием, если задача про архитектуру.

Dashboard

Отделите операционный dashboard от аналитического.

Операционный:

«что требует действия сейчас».

Аналитический:

«какие причины отказов доминируют за год».

Аналитика

Можно считать:

• MTBF;
• MTTR;
• downtime;
• failure frequency.

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

Документация

README или инструкция должны позволить другому человеку:

• установить;
• запустить;
• мигрировать DB;
• выполнить test.

Это проверка воспроизводимости.

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

Схема:

1. users;
2. requirements;
3. domain;
4. DB;
5. integrations;
6. API;
7. security;
8. tests;
9. monitoring;
10. limitations.

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

ИСиТ в университете реализуется в разных подразделениях, поэтому курсовая может быть связана как с промышленной информационной системой, так и с более классическим IT-сервисом.

Всегда сверяйте профиль своего учебного плана.

Защита

Будьте готовы показать data model, основной use case, одну integration, negative test, metric и failure scenario.

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