🪧Методы трассировки требований

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

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

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

Помимо ID, требования могут иметь следующие атрибуты:
💩статус
💩дата создания
💩версия
💩автор
💩владелец
💩приоритет
💩источник
💩обоснование
💩релиз
💩контактное лицо или ответственный за принятие решений по внесению изменений в требование
💩критерии приёмки

Виды трассировки

↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
↔️Горизонтальная—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

💫💫 Матрица трассировки (Requirements Traceability Matrix)

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

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

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

💫💫 Дерево требований

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

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


Плюсы и минусы трассировки

➕➕Четкое представление о требованиях к системе и их взаимосвязях
➕➕Отслеживание изменений требований

➖➖Ресурсо-затратно: некоторые методы требуют времени на подготовку, ведение требований и обновление
➖➖Есть риск недооценки сложных взаимосвязей между требованиями и элементами проекта.

#требования

Из джуна в мидла вместе с Холдингом Т1 🚀

Приглашаем системных аналитиков в Открытые школы Т1!

🎓 Открытые школы Т1 — это новая карьерная программа для IТ-специалистов, объединяющая обучение без отрыва от работы и offer weeks.

👨‍💻 Для участия необходим опыт работы системным аналитиком от 1 года, а также желание присоединиться к команде Т1.

Т1 — крупнейшая ИТ-компания в России по версии RAEX 2023 и партнёр ключевых производителей и разработчиков в сфере IT.

В программу входит: курс по работе с требованиями, проектирование REST API, понимание банковской специфики.
⌛️ Длительность 1 месяц.
💻 Формат: онлайн по вечерам (от 8 часов в неделю на вебинары и практику).

Лучшим назначим интервью и направим оффер!

Готов к вызову? Тогда скорее подавай заявкуподавай заявку!
⏰ Дедлайн — 23 мая.

Реклама. ООО "Т1". ИНН 7720484492.

▶▶ Способы асинхронного взаимодействия в API

Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
👩‍🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑‍🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨‍🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер


Способы асинхронного взаимодействия в API

1⃣1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ ПримерПример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис

2⃣2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  ПримерПример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

3⃣3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  ПримерПример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу

5⃣5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот


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

#интеграции #async

Репост:

Git. Обзор и подборка материалов

В связи всё более широким распространением подхода Docs as Code самое время изучить Git.

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

Git позволяет:
💩Хранить историю изменений проекта. Git может определить, кто и в какой момент внёс изменения.
💩Параллельно работать над файлами. Все изменения затем сливаются воедино.
💩Откатиться к предыдущим версиям проекта, если что-то пойдёт не так.

Принцип работы Git

1️⃣Разработчик создаёт свою ветку от главного проекта, куда вносит свои изменения
2️⃣В своей ветке разработчик делает необходимые изменения в коде или документации, которые затем фиксируются в истории изменений.
3️⃣После того как работа в ветке завершена, разработчик сохраняет изменения, создавая коммиты. Коммиты отражают историю изменений и могут быть просмотрены в любой момент.
4️⃣Слияние изменений. Когда изменения готовы, создаётся Merge Request, чтобы влить изменения в мастер-ветку. До этого момента все изменения всё ещё находятся в отдельной ветке проекта. После слияния с мастер-веткой изменения вступают в силу для всего проекта.
5️⃣Контроль версий Git позволяет отслеживать все изменения, предоставляя возможность возвращения к любому предыдущему состоянию проекта, если это необходимо.


Курсы (бесплатные)

1. «Основы работы с Git» от Яндекс.Практикума. 16 часов обучения, свободный график, теория и тесты для самопроверки, поддержка специалистов, электронное свидетельство о прохождении курса, доступ после авторизации через Яндекс ID
2. Git для начинающих от Слёрм. Доступ придет на указанную почту после регистрации, закрытый Telegram-чат, теория и практические задания, без сертификата
3. Введение в Git от Хекслет. Видеоуроки, лекции, тренажеры с практикой, бессрочный доступ к теории, асинхронный формат обучения, без сертификата, доступ после регистрации
4. Основы Git из Степика. Много практики
5. Git. Базовый курс от GeekBrains. 13 видеоуроков, без сертификата, доступ после записи

⏯⏯ Видосы с Ютуба
1. GIT - Полный Курс Git и GitHub Для Начинающих — одно видео на 4 часа полного погружения
2. Что такое Git для Начинающих — GitHub за 30 минут
3. Уроки по Git и GitHub от ITDoctor
4. Базовый курс по Git от Devcolibri

🕹 Интерактивные гайды на русском
1. Git How To — это интерактивный тур, который познакомит с основами Git
2. LearnGitBranching — веб-приложение по интерактивному погружению в Git

📄 Полезные статьи
1. Что такое GitHub и как он работает
2. Как начать работать с GitHub: быстрый старт
3. Про стратегии ветвления в Гите
4. 19 советов по повседневной работе с Git
5. Как настроить работу с Git в Intellij IDEA

✍️ Шпаргалка по командам Git

📖 Книга
Pro Git — основное чтиво по гиту от Скотта Чакона и Бена Штрауба

#подборка

Event Driven Architecture: краткий обзор

Event-Driven Architecture (EDA) — архитектурный подход, при котором система строится вокруг событий.

В таком подходе сервисы взаимодействуют друг с другом через генерацию событий, вместо того, чтобы вызывать друг друга напрямую через HTTP-запросы. Сервис, который породил событие, ничего не знает о сервисах, которые будут это событие обрабатывать (обратное тоже верно). Подход EDA широко применяется в архитектуре микросервисов.


Компоненты EDA
💩 Событие – любое изменение состояния некой сущности или возникновение новой.
💩Производитель события – сервис, который создаёт событие.
💩Обработчик события – сервис, который получает событие и обрабатывает его, после чего порождается новое событие – результат обработки события.
💩Маршрутизатор события – промежуточный слой, который обеспечивает. доставку события от производителя до обработчика. Обычно это брокер сообщений.

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


Модели доставки событий в EDA

1⃣Pub/Sub
1. Производители генерируют события и отправляют брокеру.
2. Брокер направляет события потребителям, которые на них подписались.
3. После отправки события удаляются.
ПримерПример – RabbitMQ.

2⃣Потоковая передача
1. Производители генерируют события и отправляют брокеру.
2. Брокер сохраняет события у себя в журнале.
3. Потребители считывают события из любой части журнала в любой момент времени. События не удаляются брокером.
ПримерПример – Kafka.


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

✅ Преимущества EDA

➕Слабая связность и гибкость: можно масштабировать, обновлять и развертывать сервисы независимо друг от друга.

➕➕Скорость: в EDA каждое событие может быть обработано независимо, что позволяет системе использовать параллельную обработку. А ещё можно эффективнее распределять нагрузку между обработчиками событий с учётом текущей загруженности узлов.

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


⛔️ Недостатки EDA

💩💩Сложность разработки и тестирования вследствие распределённой архитектуры и асинхронного взаимодействия.

💩💩Отсутствие транзакционности. Поскольку компоненты обработчика событий сильно разобщены и распределены, очень трудно поддерживать транзакции между ними. Если нужно разделить один шаг процесса работы между обработчиками событий, то есть вы используете отдельные обработчики событий для чего-то, что должно быть неделимой транзакцией — вероятно, EDA тут не подходит.

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

💩💩Дополнительные затраты на инфраструктуру. Реализация EDA требует больше производительности вычислительных ресурсов, нужно больше хранилищ данных, растут расходы на поддержку и управление инфраструктурой.


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

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

Репост:

💚 Контур приглашает системных аналитиков на онлайн-митап Analyst Update

Когда: 11 апреля, в 15:00 по МСК

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

В программе 4 доклада:

🟢«Думать — самый ценный скилл аналитика». Расскажем, как в Контуре помогают развивать способность думать шире.

🟢«Все в твоих аналитических руках, и даже процессы». Поделимся опытом внедрения новых аналитических процессов в команду.

🟢«Какие hard-скиллы качать системному аналитику». Построим индивидуальный план развития себе и младшим коллегам.

🟢«Ломать — не строить, или зачем выпиливать фичи». Поговорим о том, почему полезно наводить порядок в зрелом продукте.

РегистрируйтесьРегистрируйтесь на митап и зовите коллег! 👋

Реклама АО «ПФ «СКБ Контур» ИНН 6663003127. Erid: 2SDnjehV1Xw

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

1. Техническое собеседование для System Analyst

2. Техническое собеседование системного аналитика. В роли кандидата Булат Якубов, системный аналитик в Samokat Tech. В роли интервьюера Алексей Лобзов, руководитель направления в Альфа-Банке.

3. Публичное собеседование системного аналитика с компанией Usetech

4. Собеседование системного аналитика. Райффайзен банк

5. Публичное собеседование системного аналитика. Lamoda

6. Собеседование бизнес-системного аналитика. В роли интервьюера Сергей Нужненко — руководитель экспертной группы обновления профстандарта "Системный аналитик" редакции 2022 года, преподаватель, со-основатель Школы Cистемного Анализа. В роли кандидата — Ольга Шимкив, системный аналитик в финтехе.

7. Собеседование лида аналитиков. Интервьювер: Анна Серетенская, тимлид и системный аналитик в продуктовой разработке. Кандидат: Екатерина Зиновьева - главный системный аналитик в системном интеграторе

8. Моковое собеседование на системного аналитика. Интервьювер — Маргарита Нижельская, ex Head of SA в Мегафоне

9. Моковое собеседование на позицию Junior Системного аналитика


Бонусом — подборка интервью по System Design

1. Интервью по System Design. Александр Поломодов (Тинькофф)

2. Публичное интервью по System Design. Александр Поломодов (тех. дир. Тинькофф).

3. Публичное собеседование по System design. В роли собеседующего - Владимир Иванов (Bolt). На позиции собеседуемого - Виталий Лихачев (Авито)

4. Публичное собеседование по System Design. Интервьювер — Владимир Иванов (Bolt), собеседуемый — Денис Костоусов (Тинькофф)

5. Публичное собеседование по System Design. Проводить собеседование будет Игорь Антонов, TeamLead из Тинькофф

⏯ Все видео собрали в плейлисты на Ютубе:
1. Публичные собеседования системных аналитиков
2. System Design Interview

#подборка

Масштабирование БД. Партиционирование, шардирование и репликация

⚡️Максимально кратко
💩💩Партиционирование — разделение БД на части в рамках одного сервера. Может быть вертикальным (по столбцам) и горизонтальным (по строкам)
💩💩Шардирование — разделение БД на части по разным серверам. Может быть только горизонтальным (по строкам)
💩💩Репликация — копирование одних и тех же данных между разными серверами


💩Партиционирование

Партиционирование — разделение большой таблицы на несколько частей. Все части хранятся на одном сервере. Бывает горизонтальным и вертикальным.

1⃣ Горизонтальное партиционирование: данные разбиваются на несколько отдельных таблиц по строкам. Каждая такая таблица содержит содержит одинаковые столбцы, но разные строки данных.
ПреимуществаПреимущества:
➕уменьшение объема данных, которые нужно обрабатывать при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный диапазон строк
➕возможность распараллеливания запросов между подтаблицами
ПримерПример: разделение таблицы заказов по дате заказа, так что каждая подтаблица содержит заказы за определенный месяц или год.

2⃣ Вертикальное партиционирование: данные разбиваются на несколько отдельных таблиц по столбцам. Каждая такая таблица содержит часть столбцов и все связанные с ними строки данных.
ПреимуществаПреимущества:
➕уменьшение объема данных, которые нужно загружать в память при выполнении запросов
➕ускорение выполнения запросов, которые затрагивают только определенный набор столбцов
➕возможность оптимизации хранения данных в зависимости от типа и частоты использования столбцов.
ПримерПример: разделение таблицы пользователей на две подтаблицы, одна из которых содержит основную информацию о пользователях, а другая — доп. информацию.


💩💩Шардирование — техника масштабирования БД, когда данные разносятся по нескольким машинам. Бывает только горизонтальным (по строкам). Шардирование позволяет распределить нагрузку на запись и чтение данных между различными серверами, за каждый из которых отвечает отдельная машина.

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

Методы шардирования

1. Хешированное — данные разбиваются на шарды на основе хеш-функции, которая принимает входные данные и возвращает хеш-значение. Это значение определяет, в какой шард будет помещена каждая запись данных. Метод позволяет достичь высокой производительности и отсутствия единой точки отказа, однако усложняет поиск данных.

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

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

4. Динамическое — позволяет автоматически масштабировать хранилище в зависимости от текущей производительности и объема данных. Нужна система мониторинга и балансировки нагрузки.


💩💩Репликация
Репликация — копирование данных между несколькими серверами. При использовании такого метода выделяют два типа серверов: master и slave. Мастер используется для записи или изменения информации, слейвы — для копирования информации с мастера и её чтения. Чаще используется один мастер и несколько слейвов, т. к. обычно запросов на чтение больше, чем запросов на изменение.
ПреимуществоПреимущество: большое количество копий данных. Если мастер выходит из строя, любой другой сервер сможет его заменить.
НедостаткиНедостатки: рассинхронизация и задержки при передаче данных. Репликация используется как средство обеспечения отказоустойчивости вместе с другими методами.

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

#бд