Процессная модель
Процессная модель отвечает на вопрос, как работа разворачивается во времени. В отличие от списка требований, она показывает порядок действий, развилки, циклы, параллельность, участников и данные, переходящие между шагами. Поэтому процессная модель особенно полезна после спецификации сценария: она делает текстовую последовательность видимой и проверяемой.
Если вариант использования отвечает на вопрос “какой результат хочет получить актор?”, то процессная модель отвечает на вопрос “как этот результат достигается?”. Например, цель “записаться на консультацию” раскрывается через выбор преподавателя, просмотр свободных интервалов, проверку доступности, создание записи, отправку уведомлений и обработку ошибки, если интервал уже занят.
Процессная модель может описывать текущее состояние и целевое состояние.
AS-IS описывает текущий процесс: как люди действуют сейчас, какие документы используют, где возникают задержки, какие проверки выполняются вручную. TO-BE показывает целевой процесс после внедрения ИС: какие шаги автоматизируются, какие остаются ручными, какие данные появляются и какие роли меняются.
Даже если учебный проект описывает новую систему, полезно мысленно отделять текущую практику от будущего решения. Например, запись на консультацию может сейчас происходить через сообщения в чате. TO-BE-процесс переводит часть действий в систему: публикацию свободных интервалов, выбор времени, подтверждение записи и уведомления. Но само проведение консультации может остаться вне автоматизации.
Процесс не должен описываться на уровне технической реализации. Действия вроде “сделать SQL-запрос”, “вызвать endpoint” или “отрисовать форму” относятся к другому уровню детализации. В процессной модели важнее предметный смысл: заявка создана, исполнитель назначен, правило проверено, уведомление отправлено, решение согласовано.
Структура процессного описания может быть такой:
| Элемент | Что фиксируется | Пример |
|---|---|---|
| Участник | кто выполняет действие | студент, система, преподаватель, внешний сервис |
| Действие | что происходит на бизнес-уровне | система проверяет доступность интервала |
| Данные | что создаётся или изменяется | запись, статус, уведомление |
| Условие | когда выбирается ветка | интервал свободен / интервал занят |
| Результат | чем заканчивается фрагмент процесса | запись создана или пользователь выбирает другое время |
Ещё одна причина строить процессную модель отдельно от спецификации — возможность увидеть ответственность системы и человека. В тексте сценария шаги часто выглядят линейно, а на процессной модели становится заметно, где пользователь ждёт решения системы, где сотрудник принимает управленческое решение, где внешняя система может задержать ответ и где процесс должен завершиться с частичным результатом.
Процессная модель подготавливает материал для дальнейшего проектирования. Данные на потоках становятся кандидатами в предметные объекты. Условия ветвления указывают на бизнес-правила. Повторяющиеся действия могут стать операциями или сервисами. Ручные шаги помогают уточнить границу автоматизации.
Для первичного описания процесса можно использовать простую таблицу: шаг, участник, действие, данные, правило, возможная ошибка. Такая таблица часто удобнее диаграммы на раннем этапе, потому что позволяет быстро увидеть пропуски. Если у шага нет участника, непонятно, кто его выполняет. Если нет данных, непонятно, что меняется. Если нет результата, действие может оказаться лишним.