Хола, амигос! 💃

Вы просили КВИЗ - мы замутили КВИЗ 😎

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

Ваша задача: указать, к чему применимо каждое из высказываний.
Будьте внимательны – далеко не все ответы будут лежать на поверхности, вопросы с «хитрецой» часто задают на собеседованиях при проверке теоретических знаний 🤔

Ставим ❤️, если ю а рэди!

#quizGetAnalyst

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

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

✨ ПЕРЕХОДИМ К ОПИСАНИЮ 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 Мск (ЧТ)
🔗 ЗАРЕГЕСТИРОВАТЬСЯ

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