Ребята, это мы с вами! 🥺

Спасибо большое за вашу классную активность в КВИЗах и в теоретических постах. Ваш отклик очень нас воодушевляет! 🐈

✨ ПЕРЕХОДИМ К ОПИСАНИЮ USE CASE ✨

Варианты использования могут быть представлены:
- в графической форме (например, с помощью Use Case Diagram UML),
- в виде таблицы.

Оформление с помощью нотации UML мы рассмотрим позднее, когда детально углубимся в нотации моделирования 😉

А пока разберём более простой и универсальный способ оформления use case – с помощью таблицы.
В документации к ПО именно этот вариант оформления считается основным, а графический - вспомогательным.

#hardGetAnalyst

Существует два варианта табличного оформления use case: полная табличная форма и свободная табличная форма (упрощённая).

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

🟢 Если проект небольшой и варианты использования — не единственное описание будущих требований к системе (а есть ещё, например, user story, модели процессов, протипы и другие артефакты), можно не использовать полный шаблон записи вариантов использования и обойтись свободным форматом.

Именно его мы и рассмотрим.

⬇️⬇️⬇️

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

🥷: Предлагаем сохранить этот и предыдущий пост в избранное, чтобы шаблон use case был у вас всегда под рукой!


1️⃣ Вариант использования

В этом поле указывается название одного варианта использования, которое вы хотите описать, в формате «глагол + существительное».
Например: «зарегистрироваться на сайте», «создать заявку», «оплатить покупку» и так далее.

Для определения возможных вариантов использования можно руководствоваться следующими способами:
📌Определить действующие лица и бизнес-процессы, в которых они участвуют
В каждом процессе выделить доступную для выполнения функцию — это и будет вариант использования.
📌 Применить CRUD-модель для определения возможных сценариев взаимодействия с данными системы: создания (англ. create), чтения (англ. read), изменения (англ. update) или удаления (англ. delete).


2️⃣ Область действия

Границы системы, в рамках которых выполняется сценарий.
Например, приложение или сайт.


3️⃣ Участники процесса

Участники процесса включают основное действующее лицо и иных участников.
- Основное действующее лицо запускает вариант использования, то есть это и есть актор. Можно записать имя пользователя, должность или роль. Например, пользователь ЛК или администратор.
- В иных участниках указывается перечень дополнительных действующих лиц и их целей в рамках варианта использования. Записывается в формате: [Актор] — [его цель].

Например, сайт, цель которого — сформировать ЛК клиенту. Система-партнёр, которая возвращает информацию об оплате услуги в основную систему.


4️⃣ Предусловие

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


5️⃣ Описание

В этом блоке таблицы описывают основной сценарий в виде пошагового описания действий актора и системы.

Например:
1. Система открывает пользователю форму регистрации
2. Пользователь указывает свои персональные данные в форме
3. Система запускает проверку указанных данных на формат
4. Система создаёт пользователю личный кабинет (ЛК)
5. Система авторизует пользователя в ЛК под его персональными данными.

☝🏼 Необходимо указывать номер шага и действия, чтобы порядок шагов был очевиден.


6️⃣ Расширения

В расширениях представлено описание альтернативных сценариев, которые выполняются при ответвлении от основного.

Причин такого ветвления может быть несколько:
- Альтернативные пути к успеху;
- Актор действует некорректно;
- Бездействие актора;
- Некорректные данные;
- Внутренние ошибки системы;
- Критические недостатки в производительности системы.

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


💁🏻‍♀️ Ну вот, собственно, и всё!

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

✨РЕКОМЕНДАЦИИ ПРИ ОПИСАНИИ USE CASE✨

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

Для грамотного оформления вариантов использования следует придерживаться следующих рекомендаций при описании сценариев:

👌 Используйте предложения с короткими конструкциями
Для этого чётко указываете актора, его действие в рамках шага и необходимую дополнительную информацию. Например, «Система формирует отчёт», «Пользователь вводит логин» и так далее.


👌 Показывайте продвижение процесса, но не углубляйтесь в мелкие детали
Например, при описании шагов «Пользователь вводит электронный адрес» и «Пользователь вводит пароль» не нужно добавлять промежуточный шаг «Пользователь перевёл курсор в поле ввода «Пароль», потому что он очевиден и только усложнит конструкцию сценария.


👌 Не перегружайте сценарий описанием деталей интерфейса
Например, вместо «Пользователь нажимает на кнопку “Подтвердить”» лучше использовать «Пользователь подтверждает регистрацию» и так далее. Так при изменениях в интерфейсе (замена кнопки на поле ввода секретного кода и так далее) вам не нужно будет корректировать все варианты использования, связанные с этим сценарием.

Привет, друзья! 🙃

На этой неделе хотим рассмотреть тему ролей и ролевой модели в рамках разработки ПО.

Кажется, что определение ролей – это интуитивно понятный процесс, но в этом-то и сложность. Когда специалист отрабатывает какой-либо навык до автоматизма, теория, на которой базировалась практика, начинает «затираться». А это значит, при неожиданном запросе теории, ответ может предательски потеряться 🙈

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

Нам такое не надо! Поэтому погрузимся в основную теорию ролей и отработаем полученные знания на практике! 😎

#hardGetAnalyst

🚓 УИИИИУ УИИИИИУ! 🚓
Полиция крутых вебинаров уже на месте!

Для начинающего специалиста тема архитектуры системы – это «чёрный ящик», к которому даже страшно прикасаться. И именно эту тему спрашивают у респондента на собеседованиях! 😔

Нет, не надо слов, не надо паники! (кто пропел эту строчку, ставь 👍)
Уже послезавтра мы расскажем и покажем про:
- интеграции,
- REST,
- монолит / SOA / MSA
и многое другое! Всё это вы не только узнаете, но и поймёте на практическом вебинаре «Проектирование архитектуры: от монолита к микросервисам» с Екатериной Ананьевой!

План вебинара:
1. Роль системного аналитика в проектировании архитектуры;
2. Знакомство с проектом для работы;
3. Проектирование монолита;
4. Переход к сервисам (SOA) и микросервисам (MSA);
5. Проблемы разделения монолита на микросервисы;
6. Что нужно знать системному аналитику про работу с архитектурой.

Эти навыки по проектированию архитектуры помогут выйти на новый качественный уровень в системном анализе и стать ценным специалистом в мире IT!

КОРОЧЕ ГОВОРЯ, НЕ ПРОПУСТИТЕ:

🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГЕСТИРОВАТЬСЯ

Увидимся на вебинаре! 😘

⭐️ RACI-матрица ⭐️

Английская аббревиатура расшифровывается так:
🟣Responsible (R) — исполнитель задачи.
🟣Accountable (A) — ответственный за выполнение задачи.
🟣Consulted (C) — консультирующий при выполнении задачи.
🟣Informed (I) — тот, кого нужно информировать при выполнении задачи.

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

У одной роли на разных этапах разработки ПО могут формироваться несколько зон ответственности, каждая из которых обычно обозначается соответствующей буквой — R, A, C или I.

Например, на этапе разработки требований к ПО роли внутри проектной команды можно распределить следующим образом:

🟢R - аналитик, который описывает требования к ПО;
🟢A - менеджер продукта, который отвечает за поставку решения;
🟢C - команда разработки и эксперты, которые будут консультировать аналитика для описания более качественных требований;
🟢I - служба поддержки, которую необходимо информировать о логике внутри решения и менеджер продукта, который должен быть в курсе статуса работ по задаче.

На этапе разработки ПО, когда требования были переданы на следующий этап, аналитик становится консультирующим (C), а команда разработки - исполнителями (R) и так далее.


В документации все роли удобно оформлять в виде таблицы со следующими заголовками в столбцах:
1. ФИО
Например: Иванов Иван Иванович
2. Роль
Например: Менеджер продукта
3. Зона ответственности по RACI-матрице
Например: A, I или Ответственный за выполнение задачи, Информированный
4. Контакт для связи

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

#hardGetAnalyst

⭐️ CRUD-модель ⭐️

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

В матрицу доступа входят:
- список ролей (Roles)
- перечень объектов и допустимых способов взаимодействия с ними (Permission)
И если роли можно определить с помощью RACI-матрицы, то разобраться со способами взаимодействия с данными поможет CRUD-модель.

CRUD-модель (аббревиатура от Create, Read, Update и Delete) – это стандартная модель возможностей работы с данными.


Эта модель определяет базовые функции работы с информацией:

🌟 Создание (Create) — это вид доступа, при котором можно добавлять новую информацию в ИС. Например, специалист подбора ассортимента может вносить новые товары, которые он нашёл у поставщиков.

📕 Чтение (Read) — это возможность видеть данные и объекты внутри системы. Этот тип доступа не даёт возможности выгрузить данные или как-то их изменять.

✏️ Изменение (Update)— можно корректировать данные внутри ИС. Например, дизайнер может изменить картинки для новых продуктов, когда они с фотографом сделали более удачные фото.

✖️ Удаление (Delete) — это удаление какой-либо информации. Например, специалист по подбору ассортимента решил удалить товар «Чипсы», потому что у поставщика чипсов проблемы с доставкой.

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

Так, например, одни пользователи могут только читать информацию, другие – создавать / редактировать / удалять только свои данные, а третьи – управлять порядком во всех данных (создавать / редактировать / удалять свои и чужие данные).


🥷: Ну а вообще навык работы по CRUD-модели – это отличная отправная точка при проектировании архитектуры системы. Ведь чтобы понять, какая логика должна располагаться внутри системы, необходимо знать, с какими функциональными потребностями в эту систему придут пользователи.

#hardGetAnalyst

⭐ УЖЕ СЕГОДНЯ! ⭐

Друзья, напоминаем, что сегодня у вас есть отличная возможность попасть на открытый вебинар по проектированию архитектуры - одному из важнейших скиллов системного аналитика! 🤩

На вебинаре вы:

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

Круто? КОНЕЧНО КРУТО!
Не упустите возможность разобраться в хардовой теме под чутким руководством Екатерины Ананьевой!

ИТАК:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 СЕГОДНЯ 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Увидимся там, чемпионы! 💃