✨ ПРО ВИДЫ МОДЕЛЕЙ ПРОЦЕССА ✨

Для удобства моделирования и презентации процессов заинтересованным лицам модели и схемы принято делить на три вида — в зависимости от расположения описываемого процесса:

1️⃣ Модель бизнес-процесса —
описание последовательности действий, которые выполняются в рамках определённой задачи через всю компанию или её часть.
Чаще всего этим уровнем процесса занимаются бизнес-архитекторы и бизнес-аналитики.

Пример такого процесса: оформление доставки продуктов в приложении -> сбор заказа в дарксторе -> передача груза курьеру -> доставка продуктов клиенту -> завершение доставки (например, обработка обращений и формирование специального предложения)


2️⃣ Модель системного процесса —
описание последовательности работ и действий, которые компоненты системы выполняют для достижения поставленной цели.
Этим уровнем описания занимаются бизнес- и системные аналитики.

Пример такого процесса: тот же процеес оформления доставки продуктов в приложении, но уже с точки зрения ПО. То есть описывается взаимодействие приложения по доставке продуктов, ПО даркстора, приложения курьера, доставляющего заказ, и ПО компании для служюы поддержки и маркетинговых кампаний.


3️⃣ Модель потока программного процесса —
описание последовательности работ и действий, которые программа (или микросервис) выполняет для достижения поставленной цели.
Этот уровень процесса моделируют системные аналитики, системные архитекторы и разработчики.

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

Запомните этот пример или напишите в комментариях аналогичные, чтобы на этот вопрос отвечать интервьюеру быстро и понятно 😉


🛠 ИНСТРУМЕНТЫ ДЛЯ МОДЕЛИРОВАНИЯ ПРОЦЕССОВ 🛠

Есть много разных методов и средств моделирования процессов — от доски, ватмана и стикеров до специализированного ПО. В таких ПО можно быстро рисовать различные диаграммы и схемы, причём нескольким участникам одновременно в формате онлайн (например в Miro или Diagrams.net).

Для описания, анализа и поддержки процессов подойдёт любое из этих средств.
Главное правило — участники моделирования должны быть сконцентрированы на самом процессе моделирования, а не на средстве моделирования 😉

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

⭐️ ФТ vs НФТ: повторить перед собеседованием на СА ⭐️

👉 Функциональные требования (ФТ) — это про то, ЧТО делает система.

Для сервиса доставки еды это могут быть:

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

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

+ Пользователь может добавить блюдо в корзину.

+ Пользователь может добавить удалить блюдо из корзины.

+ Пользователь может оформить заказ, когда наполнил корзину.

+ Пользователь может оплатить заказ банковской картой или с использованием электронного кошелька.

ФТ — фундамент любой системы.



👉 Нефункциональные требования (НФТ) — это про то, КАК система работает.

❗️ Любое НФТ должно быть проверяемым: либо в фукнциональных/авто-тестах, либо нагрузкой. Непроверяемые формулировки — просто "вода". Это не нужно.

Есть несколько основных видов НФТ, которые вы должны помнить всегда. Рассказываем про них с примерами:

1) Производительность - скорость работы системы.
👎 Система работает быстро.
✅ Время обработки запросов к системе не должно превышать 900 мс при 150 RPS и 300 одновременных пользователей.

2) Доступность и отказоустойчивость - время работы без сбоев.
👎 Обеспечить для системы высокую доступность.
✅ Публичный API должен быть доступен 99.9% в месяц.
✅ Регламентные окна ≤2 ч/мес.
✅ Допустимое время восстановления сервиса после сбоя (RTO) ≤ 15 мин.
✅ Допустимая потеря данных во времени при восстановлении (RPO) ≤ 1 мин для заказов и платежей.

3) Масштабируемость - способность расти в зависимости от нагрузки.
👎 Система должна легко и быстро масштабироваться при увеличении нагрузки от пользователей.
✅ В часы пик 12:00–15:00 и 18:00–21:00 по Мск входящий трафик возрастает в 3 раза относительно базовой нагрузки. Сервисы каталога товаров, заказов и платежей, должны автоматически масштабироваться, увеличивая количество активных инстансов (работающих экземпляров) в 4 раза без простоя.

4) Безопасность
👎 Обеспечить защиту данных.
✅ Система должна поддерживать аутентификацию по OAuth2/OIDC с обязательным PKCE для мобильных клиентов.

А ещё:
5) Целостность
6) Надежность
7) Удобство использования
😍 Эффективность
9) Переносимость
и другие виды НФТ.

Подробнее познакомиться с теорией и примерами по НФТ можно в подкасте:
🔗 Нефункциональные требования: пример для медицинской системы

Пример, когда не учтенные НФТ положили систему:
🔗 Миграция БД, индексы и импортозамещение ПО: как положить прод и поднять обратно

❗️ НФТ считаются одними из самых сложных для понимания аналитиков. Поэтому собрали для вас как примеры, так и реальные примеры их влияния на системы.



Обязательно повторите этот материал перед собеседованием на Junior/Middle позиции. Всегда будьте готовы объяснить разницу и привести примеры 🤝