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

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

Сильная работа идёт от требований к архитектуре, модели данных и проверяемому прототипу.

Определите границу системы

Сначала ответьте:

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

Граница нужна, чтобы не пытаться автоматизировать всю организацию.

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

Акторы

Выделите роли.

Например:

• пользователь;
• оператор;
• менеджер;
• администратор;
• внешний сервис.

Не создавайте роли только ради диаграммы.

Каждая должна иметь отличающийся набор действий и прав.

Функциональные требования

Формулируйте их как проверяемое действие.

Плохо:

«Система должна быть удобной».

Лучше:

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

Такие требования можно связать с тестами.

Нефункциональные требования

Они описывают качество.

Например:

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

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

Use case

Для ключевого сценария покажите:

1. предварительное условие;
2. основной поток;
3. альтернативы;
4. ошибки;
5. результат.

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

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

Архитектура

Выберите структуру под масштаб.

Это может быть:

• клиент-сервер;
• трёхуровневая;
• монолитное веб-приложение;
• набор сервисов;
• desktop-система.

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

Архитектура должна отражать реальные границы компонентов.

Слои

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

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

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

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

Сначала определите сущности предметной области.

Например:

• пользователь;
• заказ;
• товар;
• платёж.

Для каждой задайте:

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

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

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

Она нужна не ради экзаменационного термина.

Цель - убрать аномалии:

• обновления;
• вставки;
• удаления.

Но не дробите базу на десятки таблиц без практической необходимости.

Баланс зависит от задачи и производительности.

Ограничения данных

Часть ошибок должна предотвращаться на уровне схемы.

Например:

• уникальный логин;
• обязательный внешний ключ;
• допустимое состояние;
• ненулевая сумма.

Не оставляйте целостность только на совести интерфейса.

Транзакция

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

Например, заказ создан, а списание остатка не выполнено.

Транзакция помогает сохранить согласованность.

Объясните, какие действия должны быть атомарными.

API

Если система имеет интерфейс между компонентами, опишите контракт.

Для запроса укажите:

• метод;
• путь;
• входные данные;
• ответ;
• коды ошибок.

Не ограничивайтесь фразой «используется REST API».

Покажите реальный пример обмена.

Валидация

Проверяйте данные на границе системы.

Например:

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

Не полагайтесь только на HTML-форму или визуальный контроль.

Клиентский интерфейс можно обойти.

Аутентификация и авторизация

Это разные задачи.

Аутентификация отвечает, кто пользователь.

Авторизация - что ему разрешено.

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

Запрет должен работать на серверной стороне.

Состояния объекта

Для заявки, заказа или документа полезно описать жизненный цикл.

Например:

черновик -> отправлен -> согласован -> завершён.

Определите допустимые переходы.

Не позволяйте системе перейти из любого состояния в любое.

Интеграция

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

Что произойдёт, если он:

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

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

Логирование

Лог нужен не для записи каждого клика.

Сохраняйте события, которые помогают:

• искать ошибку;
• отслеживать важное изменение;
• анализировать интеграцию.

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

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

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

Минимальный набор:

• позитивный сценарий;
• неверный ввод;
• отсутствие прав;
• отсутствующий объект;
• сбой внешней зависимости.

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

Нагрузочная проверка

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

Укажите:

• число запросов;
• длительность;
• конфигурацию;
• метрику.

Один запуск на локальном компьютере не даёт общего вывода о масштабируемости.

Прототип и промышленная система

Честно обозначайте уровень результата.

Курсовой прототип может не иметь:

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

Это нормально.

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

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

Минимально полезны:

• инструкция запуска;
• переменные окружения;
• зависимости;
• схема БД;
• описание API;
• тестовый пользователь.

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

Защита

Покажите один сквозной сценарий:

1. требование;
2. экран или API;
3. бизнес-правило;
4. запись в БД;
5. проверка тестом.

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