​​Варианты использования (Use Case).  Элементы структуры и примеры составления.
#usecase #работастребованиями #теория

Вариант использования/Use Case - описывает последовательность взаимодействия системы и внешнего действующего лица, в результате которого действующее лицо получает полезный результат.

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

Вариант использования должен:
✔описывать, что именно система должна сделать, чтобы действующее лицо достигло своей цели;
✔иметь достаточный уровень детализации;
✔не затрагивать деталей реализации;
✔не описывать пользовательские интерфейсы и экраны. 

Единого формата (шаблона) составления Вариантов использования не существует. Чаще их представляют в текстовой форме, дополняя диаграммами/схемами.

Основными элементами структуры Варианта использования являются:

🔹️Имя - пишется в формате «глагол + объект», отражает цель и смысл сценария ( Зарегистрироваться на рейс, Снять деньги в банкомате).

🔹️Цель - короткое описание того, чего  намеревается достигнуть действующее лицо с этим сценарием

🔹️Актор (actor) - действующее лицо (человек/другая программная система/аппаратное устройство), взаимодействующее с системой для реализации Варианта использования.

🔹️Предусловия  - условия, которые должны быть удовлетворены до начала выполнения Варианта использования.

🔹️Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение Варианта использования.

🔹️Выходные условия (результат, постусловие) - описывают состояние системы после успешного выполнения Варианта использования. 

🔹️Порядок Событий (основной поток/сценарий) — пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия действующего лица и системы (диалогов) от предварительных до выходных условий.

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

🔹️Исключения - условия, препятствующие успешному выполнению Варианта использования. Описывают ожидаемое ошибочное условие, которое может сложиться во время выполнения варианта использования, и как его обрабатывать.

🔹️Бизнес-правила - которые, наприпер, могут влиять на отдельные шаги нормального направления, задавая разрешенные входные значения или диктуя, какие вычисления должны выполняться.

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

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

------
Заметки Аналитика | @notes_analyst

​​Как подготовиться к собеседованию бизнес-/системному аналитику.
#подборка #собеседование

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

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

Вместе с кналом @analysis_it сделали небольшую подборку статей, авторы которых приводят примеры вопросов, встречающихся на собеседованиях, и рекомендации по ответам на них.

🔹 50 лучших вопросов из интервью для бизнес-аналитиков

🔹 Прохождение собеседования на позицию бизнес-аналитика

🔹 Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)

🔹 Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем

🔹 Что мы хотим от аналитика

🔹 Типовые вопросы на собеседовании на аналитика и ответы на них

🔹 «Кем вы видите себя через 5 лет»...

🔹 Бизнес-аналитик идет на собеседование

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

Немного подробнее о задачах и обязанностях бизнес- и системных аналитиков можно прочитать тут и тут

Следите за новыми постами на каналах @analysis_it и @notes_analyst, где сможете найти ответы на многие вопросы из представленных статей ⬆️

Давайте готовиться к собеседованиям вместе!

Project-менеджер в IT - один из немногих каналов для начинающих проджектов в телеграм. Если вы хотите развиваться в сторону менеджмента в IT — подписывайтесь!

​​Диаграммы прецедентов (вариантов использования).
#usecase #диаграмма #теория

Диаграммы вариантов использования (use-case diagrams) позволяют получить высокоуровневое визуальное представление о требованиях пользователей.
Их чаще применяют в качестве дополнения к более описательным текстовым Вариантам использования.

При помощи use-case диаграммы можно:
▪︎ продемонстрировать различные способы взаимодействия пользователя с системой;
▪︎ визуально представить логическое развитие сложного варианта использования;
▪︎ описать общую функциональность системы;
▪︎ определить общие границы и контекст моделируемой предметной области;   
 ▪︎ разработать исходную концептуальную модель системы;
 ▪︎ подготовить исходную документацию. 

Основными элементами use-case диаграммы являются:
 🔹 Актеры (акторы) - группы лиц или систем, взаимодействующие с описываемой системой;
🔹 Варианты использования (прецеденты) - функции, которые система предоставляет актерам;
🔹 Комментарии;
🔹 Отношения между элементами диаграммы - отношения ассоциации, обобщения, включения, расширения.

Графические обозначения и определения данных элементов привела в таблице Основные элементы Use-case диаграммы

Строить диаграмму прецедентов можно в следующей последовательности:
1.Выделите группы действующих лиц
2. Определите функциональность для каждой из групп (варианты использования/прецеденты)
3. Дополните прецеденты словесным описанием (сценарием) - для каждого прецедента создайте разделы: "основной поток" и " "альтернативный"
4. Проведите анализ связей (отношений)
5. Перенесети собранные данные в графический формат - постройте use-case диаграмму.

При построении диаграммы помните, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации.
Отображайте на диаграмме только ключевые моменты, не делите процессы слишком мелко.

Ещё больше рекомендаций и примеров построения use-case диаграмм можете найти в статьях:
 ° Правила и рекомендации по разработке диаграмм прецедентов
 
° Использование диаграммы вариантов использования UML при проектировании программного обеспечения

Заметки Аналитика | @notes_analyst

​​Алистер Коберн. Современные методы описания функциональных требований к системам.
#работастребованиями #литература

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

"Данная книга эксперта по объектной технологии Алистера Коберна служит новейшим практическим руководством по написанию вариантов использования. Богатый опыт в этой области помогает автору расширить классическое толкование вариантов использования. В книге представлены начальная, промежуточная и развитая концепции, поэтому она подходит читателям с разным уровнем подготовки. Инструкции подкреплены наглядными примерами и упражнениями."

Электронную версию можно найти тут

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

В рамках своего канала @data_study Даниил делится знаниями и теоретическими навыками работы аналитиком:
- работа с базами данных
- хранилища данных, озера данных
- управление данными, качество данных
- обработка данных
- SQL, Python
- бизнес-анализ
- визуализация данных
- soft-навыки аналитика

Канал будет интересен как новичкам в аналитике, так и специалистам, желающим повысить свои навыки работы с данными.
https://t.me/data_study
@daniildzheparov

Шпаргалка по основам SQL

Скачать в формате pdf

#sql | @notes_analyst

​​📑 Нормализация баз данных. 1, 2 и 3 нормальные формы.

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

Данный метод дает следующие преимущества:
▪︎ упрощает процесс выборки;
▪︎ обеспечивает целостность данных;
▪︎ улучшает масштабируемость;
▪︎ минимизирует избыточность данных;
▪︎ предотвращает потери информации.

Устранение избыточности происходит за счёт декомпозии отношений (когда одна таблица разбивается на несколько).

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

🔹️ Первая нормальная форма (1NF) - предполагает, что сохраняемые данные на пересечении строк и столбцов должны представлять скалярное значение, а таблицы не должны содержать повторяющихся строк.

🔹️ Вторая нормальная форма (2NF) - предполагает, что каждый столбец, не являющийся ключом, должен зависеть от первичного ключа.

🔹️ Третья нормальная форма (3NF) - предполагает отсутствие в таблицах транзитивной зависимости (когда один неключевой столбец связан с первичным ключом через другой неключевой столбец)

Полный перечень нормальных форм и требования к ним приводятся тут

#БазыДанных | @notes_analyst

📑 Jira. Знакомство с инструментом.

Jira - это программный инструмент с открытым исходным кодом, используемый для управления проектами, задачами и отслеживания ошибок, который:
 ▪︎ позволяет создавать карту проекта,  контролировать ход выполнения задач,
управлять загрузкой исполнителей, 
выделять "узкие" места в проектах и важные задачи;
 ▪︎ имеет ряд необходимых стандартных отчетов;
 ▪︎ использует настраиваемые доски Scrum и Kanban;
 ▪︎ имеет возможности конфигурирования, интеграции и расширения функций.

Статья: Jira - как вводная часть для тех, кто только начинает свое знакомство с данным инструментом.

Содержание статьи:
 ° Agile-разработка с Jira
  ° Для чего используют Jira
 ° Как пользоваться Jira
  ° Интерфейс
  ° Создание первого проекта
  ° Создание задачи
 ° Повышение производительности
 ° Аналоги.

#инструменты | @notes_analyst

​​Мини-курс "Введение в API".Брайан Кукси
(перевод под редакцией Артема Стукалова и Дениса Бескова)

Содержание:
 ▪︎ Глава 1: Введение
 ▪︎ Глава 2: Протоколы
 ▪︎ Глава 3: Форматы данных
 ▪︎ Глава 4: Аутентификация, часть 1
 ▪︎ Глава 5: Аутентификация,  часть 2
 ▪︎ Глава 6: Проектирование API
 ▪︎ Глава 7: Связь в реальном времени
 ▪︎ Глава 8: Реализация

Скачать оригинал в формате PDF

#API | @notes_analyst

Шпаргалка по SQL - JOINs

Скачать в формате pdf

#sql | @notes_analyst

​​📑 Как правильно писать User Stories

User stories (пользовательские истории) представляют исходные требования от заказчика о целях пользователей в общем виде.
Каждая Пользовательская История – это повод к обсуждению, а не конечное требование к системе.

Для написания Пользовательских историй часто используют шаблон:

Как <тип пользователя>, я хочу <цель>, чтобы <причина>.

Авторы статьи на примере разбирают возможные ошибки при написании User stories и способы их исправления.

Перейти к статье

#работастребованиями | @notes_analyst

​​📑 Частые ошибки бизнес-/системного аналитика

Виктор Дмитриев - практикующий бизнес-/системный аналитик с опытом управления командой / глубокого бизнес-анализа / запуска Web и Mobile проектов, подготовил список ошибок , которые часто допускают бизнес-/системные аналитики в своей ежедневной работе, и даёт рекомендации, как их не допустить:

Статья 1:
▪︎ Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
▪︎ Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
▪︎ Ошибка 3. Забыли обработать исторические данные
▪︎ Ошибка 4. Принимаем слова руководителей за «чистую монету»

Статья 2:
▪︎ Ошибка 5. Забыли получить согласование ТЗ
▪︎ Ошибка 6. Не привлекаете дизайнера на интервью заказчика
▪︎ Ошибка 7. В процессе сбора требований вы общаетесь не с тем человеком
▪︎ Ошибка 8. Не фиксируете все договоренности в заметках встреч

#статья | @notes_analyst

​​📚 Путь аналитика. Практическое руководство IT-специалиста. А.Перерва, В. Иванова

"Как воплотить неясные ожидания заказчика в блестящий и прибыльный проект? Как избежать ошибок на начальном этапе? Как стать эффективным аналитиком? Авторы отвечают на эти вопросы и делятся своими ноу-хау, которые позволят вам стать гуру в разработке программного обеспечения. Главное достоинство книги — ее практическая направленность. В ней собрана полезная информация со ссылками на теоретические материалы из разных областей разработки программного обеспечения: анализа, архитектуры, управления проектами, лидерства и управления персоналом — все, что понадобится в реальных производственных проектах.."

Прочитать об авторах, о том, для кого предназначена данная книга и что вы в ней найдёте, а чего нет - можно тут

Скачать 📗

#литература | @notes_analyst

Шпаргалка по оконным функциям SQL

Скачать в формате pdf

#sql | @notes_analyst

​​📑 REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков.

- Какие принципы вложил в парадигму REST её автор и как они могут помочь при проектировании систем?

- Почему существует терминологическая путаница вокруг REST?

- Как связаны HTTP и REST?

- Почему REST противопоставляют SOAP?..

Ответы на эти и другие вопросы, касающиеся REST , можете найти в видео Андрея Буракова или  в статье, составленной по его вебинару.

#rest | @notes_analyst

​​📑 Уровни тестирования.

Как минимум каждый второй системный аналитик так или иначе участвует в тестировании.
В связи с этим хотелось бы несколько постов посвятить теме:  #тестирование

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

Выделяют 4 базовых уровня:

1️⃣ Модульное/компонентное тестирование
проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.)

На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях.

2️⃣ Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / подсистемами / системами.

Выделяют два подтипа:
▪︎ Компонентное интеграционное тестирование - проверяет работу модулей в связке друг с другом.
▪︎ Системное интеграционное тестирование - проверяет связи между подсистемами / системами. 

Существует несколько подходов интеграционного тестирования:
▪︎ Большой взрыв - тестируются все или практически все разработанные модули, собранные вместе в виде законченной системы или ее основной части.
▪︎ Снизу вверх - все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. Далее собирается и тестируется следующий уровень модулей.
▪︎ Сверху вниз - вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые.
▪︎ Гибридная интеграция (сэндвич)- представляет собой комбинацию подходов «сверху вниз» и «снизу вверх».

3️⃣ Системное тестирование- заключается в проверке как функциональных, так и нефункциональных требований в системе в целом. 

Можно выделить два подхода к системному тестированию:
▪︎ на базе требований, когда для каждого отдельного требования пишутся тест-кейсы;
▪︎ на базе вариантов использования (use case)

4️⃣ Приемочное тестирование предназначено для проверки соответствия системы заявленным требованиям. Позволяет заказчику системы убедиться в соответствии системы спецификации.

Существует несколько форм приемочного тестирования:
▪︎ Пользовательское приемочное тестирование - проверяет пригодность системы к эксплуатации конечными пользователями;
▪︎ Эксплуатационное приемочное тестирование - тестирование с позиции тех, кто будет поддерживать работу программы;
▪︎ Контрактное приемочное тестирование - проводится в соответствии с критериями, указанными в контракте приемки специального ПО;
▪︎ Альфа- и бета-тестирование - используются для получения обратной связи от потенциальных или существующих клиентов. 

#тестирование | @notes_analyst

Друзья, привет!
Напишите, пожалуйста, в комментариях:

✏ Какую проф.литературу вы бы порекомендовали к прочтению?

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

​​📑 Apache Kafka: основы технологии

Apache Kafka (брокер сообщений) распределенная система обмена сообщениями между серверными приложениями в режиме реального времени.

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

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

Разобраться в том, чем Kafka отличается от популярных систем обмена сообщениями, как хранит данные и обеспечивает гарантию сохранности, а так же, как записываются и читаются данные, поможет статья: Apache Kafka: основы технологии

#kafka | @notes_analyst