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

Курсовая по прикладной информатике в МГТУ им. Баумана должна начинаться с прикладной области. Само программирование является инструментом. Главный вопрос: какую деятельность система меняет и как доказать, что новое решение лучше текущего процесса.

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

Официальные ресурсы:
https://open.bmstu.ru/courses/
https://course.bmstu.ru/2edu/programs

Найдите реальную задачу

Подходящие области:

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

Плохо:

«Разработка базы данных».

Сильнее:

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

Опишите процесс без системы

Кто получает информацию, вводит, проверяет, согласует и формирует отчёт?

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

Тогда автоматизация имеет основание.

Pain points

Например:

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

Не перечисляйте общие «проблемы цифровизации».

KPI до автоматизации

Выберите:

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

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

Без baseline нельзя доказать эффект.

Требования

Сначала пользовательские:

«Руководитель видит просроченные заявки».

Потом системные:

«Система рассчитывает deadline и фильтрует записи по статусу».

Не начинайте с таблиц БД.

Домен

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

Например:

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

Используйте терминологию реальной области.

Бизнес-правила

Например:

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

Правила нужно формализовать.

Workflow

Покажите:

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

Для каждого перехода укажите исполнителя, условие и время.

База данных

Схема должна поддерживать правила.

Например:

• статус;
• история;
• связи;
• ограничения.

Не храните историю только в текстовом поле «комментарий».

Справочники

Используйте единые подразделения, типы, категории и статусы.

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

Импорт Excel

Многие реальные процессы начинают с Excel.

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

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

Валидация

Разделите формат, бизнес-правило и связь.

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

Отчёт

Отчёт должен отвечать на управленческий вопрос.

Плохо:

«таблица всех заявок».

Сильнее:

«просроченные заявки по подразделениям».

Задайте фильтр, период и KPI.

Dashboard

Не делайте дашборд из 25 карточек.

Выберите объём, срок, качество и статус.

Каждый график должен помогать действию.

Поиск

Для большой системы полезно измерить время, поля и индексацию.

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

Роли

Матрица:

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

Не делайте права на уровне «пользователь/админ», если процесс сложнее.

Уведомления

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

Но уведомление должно иметь владельца действия. Иначе оно превращается в шум.

Интеграции

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

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

API

Если взаимодействие автоматическое, формализуйте контракт.

Покажите один-два ключевых примера.

Не вставляйте весь технический API-каталог в основную главу.

Прототип

Сконцентрируйтесь на главном процессе.

Например:

создать заявку -> назначить -> обработать -> закрыть -> отчёт.

Лучше один законченный flow, чем десять неработающих экранов.

Тест-кейсы

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

Правило: нельзя закрыть без обязательного поля.

Тест: попытка закрытия.

Ожидаемо: отказ и сообщение.

Так проверяется бизнес-логика.

User acceptance test

Пусть пользователь или условный эксперт пройдёт сценарий.

Зафиксируйте задачу, успешность, ошибку и время.

Это сильнее фразы «интерфейс удобный».

Эффект

Если автоматизация сокращает 5 минут на заявку:

эффект = экономия времени × число заявок.

Но не переводите время в деньги автоматически, если оно просто перераспределяется.

Формулируйте как высвобождаемую трудоёмкость или потенциальную экономию.

Ошибки

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

Это конкретный эффект.

Процесс после внедрения

Постройте To-Be.

Сравните шаги, роли, время и документы.

Не ограничивайтесь новым интерфейсом.

Риск

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

Для каждого риска нужен контроль.

Backup

Опишите, что копируется, как часто и как восстанавливается.

Фраза «резервное копирование предусмотрено» слишком общая.

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

В прикладных системах это особенно важно.

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

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

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

Хорошая логика:

1. область;
2. As-Is;
3. KPI;
4. требования;
5. домен;
6. workflow;
7. система;
8. тест;
9. To-Be;
10. эффект.

Бауманский контекст

В МГТУ прикладная информатика может быть связана с разными предметными областями, поэтому содержание курсовой должно быть отраслевым.

Медицинская ИС и система промышленного учёта не должны выглядеть как один шаблон с заменой названий.

Защита

Будьте готовы объяснить процесс, показать baseline, показать бизнес-правило, пройти сценарий, показать тест, объяснить эффект и назвать риск.

Сильная курсовая по прикладной информатике в Бауманке показывает, как информационная система решает конкретную прикладную задачу и меняет измеримый процесс.