Обзор популярных нотаций моделирования

Владение нотациями крайне важно для системного аналитика. Это must have, который встречается практически в любой вакансии

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

Зачем нужны нотации

1️⃣ Визуализация сложного в картинках

2️⃣ Моделирование — позволяют создавать описание структуры данных для анализа системных процессов (например, для фиксации требований)

3️⃣ Стандартизация — единый язык для коммуникации между разными специалистами (например, бизнеса, разработки)

Виды нотаций

💩 Структурные нотации: отображают состав объекта и взаимодействие между его частями. Примеры: UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. К таким нотациям относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6 из стандарта IDEF.

💩 Динамические нотации: показывают потоки данных или логику выполнения процессов. Примеры: DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

Примеры распространённых нотаций

🔹 BPMN (Business Process Model and Notation) — используется для моделирования бизнес-процессов. Представляет собой набор графических элементов, которые отображают задачи, события, шлюзы, потоки, пулы, дорожки и т.д. BPMN позволяет наглядно и однозначно описать логику, последовательность, роли и правила выполнения бизнес-процессов.

🔸 eEPC (extended Event-driven Process Chain) — нотация моделирования бизнес-процессов с фокусом на события и их результаты. eEPC показывает, какие события инициируют, контролируют и завершают функции, а также какие ресурсы и данные участвуют в процессах.

🔹 IDEF (Integrated DEFinition) — семейство нотаций (IDEF0, IDEF1, IDEF2 и т. д.) для описания разных видов моделирования, например, функционального, данных, логики и т.д. Одна из старейших нотаций.

🔸 UML (Unified Modeling Language) — это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. UML имеет 12 диаграмм, которые показывают структуру и поведение системы на разных уровнях.

🔹 DFD (Data Flow Diagram): для визуализации и анализа потоков данных в информационной системе. Помогает выявить входы, выходы и обработку данных в различных процессах.

🔸 ERD (Entity-Relationship Diagram) — нотация для моделирования сущностей и их отношений в базах данных. ERD показывает, какие сущности существуют в базе данных, какие атрибуты их описывают, какие связи между ними устанавливаются и какие ключи обеспечивают их идентификацию и целостность.

🔹 С4 (Context, Containers, Components, Code) – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: контекст, контейнеры, компоненты и классы.

🔸 ArchiMate — язык для моделирования архитектуры предприятия. ArchiMate имеет элементы, которые отображают бизнес, приложения, технологию, мотивацию и стратегию. ArchiMate позволяет описать, анализировать и визуализировать архитектуру внутри и за пределами бизнес-процессов. Тесно завязан на архитектурный фреймворк TOGAF.

📎 Ссылки
1. Один пример и три нотации: сравниваем BPMN, EPC и DMN
2. Ликбез по BPMN, EPC и UML activity с примерами для начинающих аналитиков
3. Основные нотации моделирования бизнес процессов и их применение
4. Плюсы и минусы IDEF, eEPC, BPMN
5. ТОП-5 нотаций моделирования архитектуры

⭐️ Подборка материалов по каждой нотации доступна в базе знаний по системному анализу

#проектирование #подборка

User Story vs Job Story

📄User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт

Цель: декомпозировать требования на понятные и выполнимые элементы
Формула: Я, как [тип пользователя], хочу [желание], чтобы [ценность или результат]
Пример: Я, как пользователь сайта, хочу получить трек-номер, чтобы следить за посылкой. Я, как пользователь, могу запросить напоминание пароля, чтобы восстановить пароль

Как составить user story:
➖Определите пользователя, для которого создается функция
➖Сформулируйте результат, который получит пользователь после использования функции
➖Опишите ситуацию, в которой пользователь может использовать функцию
➖Укажите ограничения или условия, при которых функция должна работать

Способ проверки “INVEST”:
➖«I» Independent — независима от других историй
➖«N» Negotiable — обсуждаема, по ней можно спланировать дальнейшие действия
➖«V» Valuable — ценная, отвечает на вопрос «зачем»
➖«E» Estimable — оцениваемая, можно установить критерии успеха
➖«S» Small — маленькая или короткая, описывает одну задачу
➖«Т» Testable — тестируемая - можно получить обратную связь от пользователей и сделать выводы


🎯Job Story (инструмент из концепции Jobs To Be Done (JBTD)) - это описание возможных ситуаций, при которых пользователь хочет воспользоваться нашим продуктом

Цель: определить ситуации, в которых у пользователя возникает потребность в продукте
Формула: Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]
Пример: когда пользователь оплатил заказ на сайте, он беспокоится, доставят ли ему товар и хочет получить трек-номер, чтобы следить за посылкой

Способ проверки:
➖Описывает результат, который получит пользователь
➖Не содержит готовое решение
➖Описывает контекст, в котором человек находится при возникновении проблемы, а не саму проблему
➖Отвечает на вопрос «Почему/для чего?» мы должны это сделать

Отличия:
💩User Story описывает конкретный сценарий с точки зрения пользователя, Job Story - общую задачу, которую он выполняет в системе
💩User Story фокусируется на описании одной задачи, Job Story может включать в себя несколько User Story
💩User Story помогать лучше узнать пользователей, Job Story отвечают на вопрос почему они продолжают пользоваться продуктом и почему приходят новые


Совмещение инструментов:
1. Изучить потребности пользователей
2. Описать потребности по шаблону Job Story, это позволит видеть картину пользователя целиком: его чувства, эмоции, привычные реакции
3. Придумать как удовлетворить потребности, описанные в Job Story
4. Выбрать решение и описать его по шаблону User Story
5. Передать User Story в разработку

Итог:
💩Job Story подходит, если нужны идеи для доработки текущего продукта или создания нового
💩User Story подходит, если нужно декомпозировать и описать уже выбранное решение

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#требоваия

Тест-кейсы: как и зачем писать📝

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

Виды тест-кейсов:

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

❌ Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными
Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный

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


Особенности:
💩Идеально подходят для описания сложных проверок в системе и регрессионного тестирования
💩Помогают автоматизировать ручные проверки, если тестирование занимает много времени
💩Используются для проверки системы не тестировщиками, для онбординга новых людей на проект
💩Помогают определить необходимое время на тестирование
💩Избыточны для небольших задач
💩Требуют много времени на написание и актуализацию
💩Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки


Содержание тест-кейса

💫Уникальный номер. Позволит ссылаться на тесты по номеру
💫Заголовок. Отражает цель - что именно нужно проверить
💫Предусловия. Что нужно сделать перед началом тест-кейса
💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных
💫Шаги. Что нужно сделать для проверки
💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”
💩Скриншоты можно использовать только как дополнение к текстовому описанию
💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов
💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком


Use Case 🆚 Test Case

🔹 Use Case — детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Используют для описания функциональных требований к системе

🔸 Test Case — детальное описание того, как должно проходить тестирование конкретной функции в системе. Основываются на юскейсах и используются для проверки соответствия реализации требованиям.


👨‍💻 Аналитик и тест-кейсы
➖На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем
➖Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе
➖Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям


Инструменты ведения для тест-кейсов:
➖Zephyr for Jira
➖TestRail
➖Qase
➖Test IT


⭐️ Подборка материалов доступна в базе знаний по системному анализу

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

Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

➖Обе методологии относятся к Agile
➖Важна визуализация работы для прозрачности и оценки текущего состояния задач.
➖Имеют итерационный подход к работе, даже если длительность итераций различается.
➖Имеют механизмы для определения и управления приоритетами задач.
➖Акцентируют внимание на командной работе и взаимодействии между участниками


✅ Когда лучше применять

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

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

Kanban
💩в проектах, где необходимо строго соблюдать сроки
💩в кросс-функциональных командах
💩когда требуется постоянная обратная связь от клиентов

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#управление_проектами

Больше подборок в закрытом канале

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

Что входит в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес, экономия 20%)

Оформить подписку можно через кнопки ниже.

OAuth 2.0 и OpenID Connect

🔐 OAuth 2.0 — протокол авторизации, который позволяет приложениям получать доступ к ресурсам от имени пользователей, без необходимости передавать логин и пароль. Вместо этого используются токены доступа.

👤 OpenID Connect — протокол аутентификации, который позволяет безопасно узнать сведения о пользователе, от имени которого совершается вход. OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO).

В чём отличие между OAuth 2.0 и OpenID Connect

Вся разница сводится к различию процессов аутентификации и авторизации.

Простыми словами:

💩Аутентификация — это когда мы проверяем, кто именно запрашивает доступ и является ли он тем, кем он себя представляет.

💩Авторизация — это когда мы проверяем, имеет ли конкретный клиент доступ к запрашиваемой информации.

OAuth 2.0 используется для авторизации, а OpenID Connect для аутентификации. А ещё OpenID Connect делает возможным использование SSO.

Токены

Оба протокола используют токены. Токен — это строка, которая содержит зашифрованную или подписанную информацию.

💩id_token — содержит информацию о клиенте, он выдается провайдером идентификации (IdP) в ответ на успешную аутентификацию пользователя. Может содержать, например, id пользователя, фамилию, имя, телефон и т.д.
💩access_token — это токен доступа, который используется для совершения действий от имени пользователя. Может быть ограничен скоупом — перечислением прав, которые может делать приложение с этим токеном от имени клиента. access_token имеет короткий срок жизни в целях безопасности.
💩refresh_token — это токен, который используется для получения нового access_token, когда старый истекает или отзывается. Имеет более длительный срок.

Все эти токены можно генерировать по-разному, но самый популярный формат — это JSON Web Token (JWT).

Структура JWT
💫Заголовок (header) — состоит из типа токена и алгоритма хэширования подписи
💫Полезная нагрузка (payload) — любые данные, которые вы хотите передать в токене. Payload не шифруется при использовании токена, поэтому не стоит передавать в нем чувствительные данные. Например, паспортные данные.
💫Подпись (signature) — заголовок и нагрузка формируются отдельно в формате JSON, кодируются в base64, а затем на их основе вычисляется подпись, которая также становится частью токена.

🔀 Процесс на примере использования VK API

1. Приложение генерирует параметры запроса и отправляет пользователя на сервер авторизации oauth.vk.com, добавив к ссылке параметры, включая запрашиваемый scope, например, friends
2. Пользователю открывается окно, где он проходит аутентификацию — вводит логин и пароль
3. После входа открывается окно с запросом прав доступа. Пользователь нажимает на кнопку "Разрешить". Тем самым он авторизует приложение на выполнение действий от его имени с запрашиваемым scope.
4. Сервер авторизации генерирует access_token и refresh_token и возвращает их приложению
5. Теперь приложение может управлять списком друзей пользователя

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#архитектура #проектирование

Версионирование REST API

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

⚙️ Как это работает

1️⃣ Под номером версии фиксируется существующий контракт API, который используется потребителями

2️⃣ Если возникла необходимость внести изменения в существующий контракт, заводится отдельная ветка под дорабатываемый метод

3️⃣ Изменения публикуются в новой версии метода API, при этом старая версия остаётся рабочей до тех пор, пока у неё есть потребители

4️⃣ Потребители сами решают, в какой момент они будут готовы перейти на новую версию того или иного метода


✍️ Пример

Допустим, есть метод который позволяет опубликовать статью в блоге: POST /v1/articles
Метод принимает на вход в теле запроса следующие параметры, которые являются обязательными:

{
  "text": "string",
  "author": "string",
  "noscript": "string"
}

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

Поэтому создаём новую версию метода POST /v2/articles и все изменения реализуем там:

{
  "text": "string",
  "author": "string",
  "noscript": "string",
  "category": "string"
}

При этом старая версия метода (POST /v1/articles) продолжает работать.


Способы версионирования API

💫 Префикс URI
Пример: GET /v1/users
✔️ Способ простой в проектировании, реализации и документировании
✖️ Создает большое количество дубликатов URL и может снизить производительность приложения

💫 Параметр запроса
Пример: GET /users?version=v1
✔️ Способ рекомендуется, если важно HTTP-кеширование для повышения пропускной способности
✖️ Приводит к загрязнению URI, так как префиксы и суффиксы добавляются к основным строкам URI

💫 HTTP заголовок запроса
Пример: GET /users, а версию передаём в headers: version=v1
✔️ Не приводит к загрязнению URI, легко реализовать
✖️ Приводит к неправильному использованию заголовков, т.к они нужны для метаинформации

💫 Feature-версионирование
У клиента API есть набор фич. При отправке запроса, сервер проверяет его набор фич и на этой основе сам определяет нужную версию для каждого клиента
✔️ Можно использовать в качестве внутреннего API
✖️ Со временем фичи могут вступить в конфликт, если отвечают за одну и ту же часть бизнес-логики


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#api