Курсовая по прикладной информатике: как спроектировать приложение для предметной области и доказать его полезность

Курсовая по прикладной информатике ценна не сложностью технологии, а тем, насколько хорошо программное решение соответствует реальной предметной задаче. Можно написать красивое веб-приложение и получить слабую работу, если непонятно, кто им пользуется, какие операции автоматизируются и что стало лучше по сравнению с текущим способом.

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

Объект автоматизации

Определите конкретно:

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

Не берите «деятельность предприятия» целиком.

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

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

Сначала разберите сущности и правила без привязки к интерфейсу.

Например, в сервисном центре есть:

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

У них есть реальные связи.

Эта модель должна появиться раньше таблиц базы данных.

Текущий способ работы

Опишите AS-IS только в нужном объёме.

Покажите:

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

Не пишите историю организации на десять страниц.

Проблема

Она должна быть измеримой.

Например:

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

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

Требования пользователя

Не начинайте с «система должна иметь авторизацию».

Спросите, что пользователь хочет сделать.

Например:

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

Технические функции вырастают из этих задач.

Модель предметной области

Схема классов или ER-модель должна отражать реальные понятия.

Не создавайте искусственные сущности только ради нормализации.

Проверьте, можно ли объяснить каждую таблицу специалисту предметной области.

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

Запишите правила явно.

Например:

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

Это ядро прикладной логики.

База данных

Для основных таблиц определите:

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

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

Поиск и фильтрация

В прикладном приложении это часто важнее красивой главной страницы.

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

Например:

• номер;
• дата;
• клиент;
• статус.

Проверьте сценарий на объёме данных больше десяти записей.

Отчёт

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

Не создавайте таблицу «все данные из базы».

Например:

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

Покажите, кому нужен отчёт и что он позволяет решить.

Печатная форма

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

Проверьте:

• реквизиты;
• данные;
• формат;
• повторное создание.

Не копируйте вручную значение в шаблон, если система уже хранит его в базе.

Интерфейс

Экран должен соответствовать задаче роли.

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

Администратору не нужен экран ежедневной работы кассира.

Разделяйте интерфейс по функциям.

Ошибка пользователя

Продумайте:

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

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

Сообщение должно объяснять, что исправить.

Роли и права

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

Скрытая кнопка не является защитой.

Покажите матрицу:

| Роль | Просмотр | Создание | Изменение | Удаление |
|---|---|---|---|---|

Так проще проверить модель доступа.

Интеграция

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

Например:

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

Не считайте интеграцию готовой после одного успешного запроса.

Миграция данных

Если текущая работа ведётся в Excel, подумайте, как перенести существующие записи.

Проверьте:

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

Импорт реальных грязных данных часто является отдельной задачей.

Тестовые данные

Не заполняйте базу бессмысленными строками user1, user2, test.

Сделайте небольшой реалистичный набор, который проверяет правила.

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

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

Свяжите тест с бизнес-правилом.

Пример:

«Нельзя закрыть заявку без выполненной работы».

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

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

Время выполнения операции

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

Например:

• поиск до автоматизации;
• поиск после;
• подготовка отчёта до;
• после.

Не придумывайте экономический эффект без исходного измерения.

Экономическая оценка

Можно оценить:

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

Но не обещайте миллионную экономию из нескольких секунд без реалистичного объёма операций.

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

Пользовательская инструкция должна описывать рабочие действия.

Техническая - запуск и настройку.

Не смешивайте эти документы.

Пользователю не нужно знать структуру пакетов кода.

Защита

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

1. проблема;
2. исходная работа;
3. ввод данных;
4. бизнес-правило;
5. результат;
6. отчёт;
7. измеримый эффект.

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