Курсовая по информационным системам и технологиям в Бауманке: архитектура, данные, интеграции и проверяемый прототип

Курсовая по информационным системам и технологиям в МГТУ им. Баумана должна отвечать не на вопрос «какой фреймворк использовать», а на вопрос «какая информационная задача решается и как система подтверждает, что решает её правильно».

В МГТУ им. Н.Э. Баумана направление 09.03.02 «Информационные системы и технологии» представлено в образовательных планах университета. В официальном каталоге «Открытый МГТУ» оно связано, в частности, с кафедрой ИУ3.

Официальный каталог:
https://open.bmstu.ru/courses/

Начните с пользователя

Кто будет работать с системой?

Например:

• диспетчер;
• инженер;
• оператор;
• аналитик;
• студент;
• клиент.

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

Проблема

Хорошая проблема измерима:

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

Не пишите только «необходима цифровизация».

User journey

Покажите путь:

вход -> действие -> решение -> результат.

Для каждого шага отметьте экран, данные, правило и возможную ошибку.

Требования

Разделите функциональные, нефункциональные и ограничения.

Функциональное:

«Система формирует заявку».

Нефункциональное:

«95% запросов обрабатываются быстрее N секунд».

Acceptance criteria

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

Например:

Given: пользователь авторизован.
When: загружает файл неверного формата.
Then: система отклоняет его и показывает понятное сообщение.

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

Доменная модель

Определите сущности:

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

Не начинайте схему БД с технических таблиц. Сначала нужен смысл предметной области.

ER-диаграмма

Для каждой связи покажите 1:1, 1:N или M:N.

M:N обычно требует отдельную связывающую сущность. Не храните список ID через запятую в одной ячейке.

Нормализация

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

Обсудите баланс.

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

Используйте:

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

Часть качества данных лучше гарантировать на уровне БД, а не только интерфейса.

Миграции

Схема системы развивается. Покажите, как изменение структуры данных переносится между версиями.

Не правьте production-таблицу вручную без истории.

API

Опишите несколько ключевых endpoint:

• метод;
• URL;
• вход;
• ответ;
• ошибки.

Не публикуйте весь Swagger на десяти страницах.

Интеграция

Информационная система часто не существует изолированно.

Возможны:

• ERP;
• CRM;
• LDAP;
• файловый обмен;
• внешнее API.

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

ETL

Если система загружает данные из внешнего источника, опишите:

1. extract;
2. transform;
3. validate;
4. load.

Не загружайте сырые данные сразу в основную таблицу без проверки.

Справочники

Одна и та же сущность должна иметь единый код.

Например, подразделение.

Не допускайте «Отдел продаж», «Sales», «Продажи» как три разных значения без маппинга.

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

Сделайте проверки:

• completeness;
• uniqueness;
• validity;
• consistency.

Покажите несколько метрик до и после очистки.

Аудит изменений

Для критичных сущностей полезно хранить:

• кто изменил;
• когда;
• старое значение;
• новое.

Это особенно важно для статусов и документов.

Авторизация

Разделите authentication и authorization.

Войти в систему и иметь право удалить запись - разные вещи.

Не выдавайте всем пользователям admin.

RBAC

Создайте матрицу ролей:

| Действие | Оператор | Руководитель | Админ |
|---|---|---|---|
| Создать | да | да | да |
| Утвердить | нет | да | да |

Так права можно проверить.

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

Храните только необходимые поля.

Не используйте реальные ФИО и телефоны в публичном репозитории.

Для демонстрации создайте обезличенный набор.

Интерфейс

Экран должен поддерживать сценарий.

Покажите:

• форму;
• список;
• фильтр;
• состояние ошибки.

Не рисуйте десятки экранов без связи с требованиями.

Прототип

Полезный прототип позволяет пройти основной путь.

Например:

создать -> проверить -> согласовать -> закрыть.

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

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

Минимум:

• unit;
• integration;
• acceptance.

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

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

Если список содержит 100 тыс. записей, измерьте время запроса, пагинацию и индекс.

Не доказывайте скорость на таблице из 50 строк.

Индекс БД

Он ускоряет чтение, но замедляет запись и занимает место.

Добавляйте индекс под реальный запрос. Покажите EXPLAIN или время до и после, если тема это позволяет.

Кеш

Кеширование может ускорить повторный запрос.

Но нужно решить TTL, инвалидизацию и работу со stale data.

Не добавляйте Redis без измеренного bottleneck.

Асинхронная обработка

Для долгой операции можно использовать очередь.

Например:

• генерация отчёта;
• обработка файла;
• уведомление.

Покажите статус задачи. Не заставляйте HTTP-запрос ждать десять минут.

Логирование

Фиксируйте уровень, событие, идентификатор и ошибку.

Не логируйте пароль и токен.

Мониторинг

Для сервисной системы можно выбрать latency, error rate, queue length и DB connections.

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

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

README должен содержать установку, конфиг, запуск, миграции и тесты.

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

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

Сильная структура:

1. проблема;
2. требования;
3. домен;
4. БД;
5. архитектура;
6. API;
7. интерфейс;
8. тесты;
9. performance;
10. ограничения.

Что учитывать в Бауманке

В МГТУ направление ИСиТ является реальной образовательной областью, но конкретная курсовая может быть связана с технической системой, промышленным процессом, управлением или программным сервисом.

Ориентируйтесь на дисциплину и кафедру, а не на универсальный IT-шаблон.

Защита

Будьте готовы показать use case, объяснить сущности, открыть API, запустить тест, показать запрос, назвать ограничение и объяснить, почему архитектура соответствует нагрузке.

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