BA & SA | 10000 Interview questions

№4880 категория вопросов: #ARCHITECTURE

☀Объяснение:

Use Case Points (UCP) – метод оценки трудоёмкости, первоначально разработанный Густавом Карлссоном для оценки разработки. Однако его модификации активно применяются и для оценки тестирования. В основе лежит анализ вариантов использования (use cases), а не низкоуровневых входов/выходов, как в TPA.

Базовые элементы для расчёта UCP тестирования:
Акторы (actors) – внешние сущности, взаимодействующие с системой. Каждому актору присваивается вес (простой, средний, сложный) в зависимости от протокола взаимодействия (GUI, API, файл).

Транзакции – элементарные шаги в потоке событий use case. Это может быть ввод данных, выбор из списка, нажатие кнопки, получение сообщения. Каждая транзакция добавляет определённое количество тестовых точек.
Коэффициенты сложности – поправки на технические характеристики (распределённость, производительность, безопасность) и на опыт команды.

Формула UCP для тестирования (упрощённо):
text

UCP (тестирование) = (UUCW + UAW) × TCF × EF

UUCW (Unadjusted Use Case Weight) – сумма весов транзакций по всем use cases.
UAW (Unadjusted Actor Weight) – сумма весов акторов.
TCF (Technical Complexity Factor) – на основе 15 технических факторов (например, распределённая обработка, производительность).
EF (Environmental Factor) – на основе 8 факторов среды (например, опыт команды, мотивация).

Как получить из UCP оценку в часах тестирования:
Обычно используют эмпирическую калибровку: одна точка UCP ≈ 5–20 человеко-часов тестирования (зависит от проекта).
Умножают на поправочные коэффициенты (например, на регрессионное тестирование 1.2).

Преимущества UCP:
Основан на early-артефактах (use cases), которые есть уже на стадии анализа.
Учитывает как функциональность, так и нефункциональные факторы (технические).
Прозрачен для заказчика (видно, из чего складывается оценка).

Недостатки:
Требует детальной спецификации use cases.
Коэффициенты TCF и EF частично субъективны.
Непосредственно для тестирования метод менее распространён, чем TPA.

Реальный пример:
В проекте по созданию интернет-банка было 12 use cases с 48 транзакциями и 4 акторами (клиент, администратор, оператор, внешний платёжный шлюз). UUCW = 120, UAW = 20, TCF = 1.1, EF = 1.0. Итого UCP = (120+20) × 1.1 = 154. Умножив на 6 часов на точку (калибровка прошлых проектов), получили 924 человеко-часа на тестирование. Оценка совпала с фактическими затратами с точностью 15%.

Что должен зафиксировать аналитик:
Использовать UCP для ранней (укрупнённой) оценки тестирования, когда ещё нет детальных спецификаций экранов.
Калибровать коэффициент «часы на точку» по истории завершённых проектов.
Включать в TCF отдельные нефункциональные требования.

Вывод: UCP для тестирования – полезный метод, особенно когда нужно быстро дать оценку при планировании, а детальные спецификации ещё пишутся.

№4879 категория вопросов: #TESTING

☀Объяснение:

Проблема:
В классической монолитной архитектуре с одной реляционной базой данных чтение и запись используют одни и те же таблицы и индексы. Тяжёлые аналитические запросы (отчёты, поиск) блокируют или тормозят транзакционные операции (создание заказов, обновление остатков). Попытки настроить индексы для чтения ухудшают производительность записи, и наоборот.

Суть CQRS (Command Query Responsibility Segregation):
Паттерн, предложенный Грегом Янгом, разделяет компоненты системы на две части:
Команды (Commands) – изменяют состояние системы (create, update, delete). Они выполняются строго последовательно и могут возвращать только подтверждение или ошибку, но не данные.
Запросы (Queries) – читают состояние, не изменяя его. Они могут возвращать сложные, денормализованные данные, оптимизированные для конкретного экрана или отчёта.

Как это реализуется технически:
Модель команд работает с нормализованным хранилищем (обычно реляционная БД), оптимизированным на скорость записи и целостность.
Модель запросов работает с денормализованными read-моделями – отдельными таблицами, кэшами (Redis), поисковыми движками (Elasticsearch) или репликами основной БД с другими индексами.
Синхронизация между командной и query-моделями происходит асинхронно (через события, CDC или брокер сообщений). Это означает, что read-модель может отставать от реальности на несколько секунд (eventual consistency).

Плюсы CQRS:
Развязка нагрузки – тяжёлые отчёты не мешают транзакциям.
Независимая оптимизация – для запросов можно использовать хранилища, идеально подходящие под задачу (поисковые движки, графовые БД, колоночные хранилища).
Масштабирование – можно масштабировать read-модели горизонтально, не затрагивая write-модель.

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

Когда CQRS необходим:
Системы с высоким соотношением чтения к записи (например, каталог товаров).
Системы, где у чтения и записи разные требования к производительности.
Проекты, где read-модель может быть построена на специализированном хранилище (Elasticsearch, Redis, Cassandra).

Реальный пример:
В онлайн-кинотеатре просмотр страницы с фильмами (чтение) обрабатывается через read-реплики и кэш, а добавление новых фильмов (запись) – через master-базу. CQRS позволил сократить время отклика главной страницы с 1.5 с до 0.1 с.

Что должен зафиксировать аналитик:
«Модели чтения и записи должны быть разделены на уровне логики и, при необходимости, на уровне инфраструктуры».
«Согласованность между ними – конечная (eventual), допустимая задержка не более 2 секунд».
«Для каждого отчёта или экрана проектируется отдельная read-модель (может быть даже отдельная таблица)».

Вывод: CQRS – мощный паттерн для систем, где нагрузка на чтение кардинально отличается от нагрузки на запись. Аналитик, предлагающий CQRS, должен также предусмотреть стратегию обновления read-моделей и механизмы обработки рассинхрона.

ИИ меняет всё вокруг. Кто разбирается в трендах, тот управляет будущим.

Вот отличная подборка сильных экспертов по AI & IT для твоего профессионального роста — всё в одном месте.

Забирай ПОДБОРКУ и оставайся на шаг впереди 💪🏻
                                                            
* Там — живые инструменты, реальные кейсы и понятные схемы, как использовать нейросети с толком и высоким КПД.

Добавляй ПАПКУ в свой актив и делись с друзьями! 📌
 
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
 
* Отписаться можно в любой момент. Остаться — тоже. ✔️

№4878 категория вопросов: #ARCHITECTURE

НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ

Друзья, наш канал попал в подборку ТГ-каналов про AI & IT, технологии и карьеру — получилась тусовка «для своих» 😎

Мы собрали каналы для себя, которые реально полезны:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление, ИИ для удаленки и работы за рубежом

🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/k7k1VvVVo1YzNTU0 👉 Делимся знаниями и аудиторией — растём вместе ⚡️

☀Объяснение:

Что такое MoSCoW?

Это метод приоритизации требований, где каждая фича относится к одной из категорий:
Must have – критически важно, без этого релиз не имеет смысла (обычно не более 40–50% от общего объёма).
Should have – очень важно, но может быть заменено обходным путём или реализовано позже.
Could have – желательно, но не критично (если время позволяет).
Won’t have – явное исключение (договорённость, что эта фича не делается в текущем релизе).

Как помогает MoSCoW?
Заказчик сначала относит все 20 фич к категориям. После обсуждения часто выясняется, что реальных Must have всего 5–6. Остальные переносятся на следующие версии. MoSCoW даёт заказчику инструмент осознанного выбора: если он настаивает на 10 Must have, команда показывает, что это физически не укладывается в сроки, и предлагает согласовать «жертвы».

Почему не другие варианты:
A (WSJF) – требует численной оценки ценности и длительности, хорошо для ранжирования бэклога, но менее нагляден для переговоров о границах релиза.
C (голосование) – не структурирован, ведёт к усреднению, а не к жёсткому отбору.
D (story points) – это оценка трудоёмкости, а не приоритизация бизнес-ценности.
Реальный кейс: В разработке мобильного приложения заказчик хотел 15 фич в первом релизе. Аналитик провёл MoSCoW-сессию, и в Must попало 6 фич. Остальные перенесли на второй релиз. Релиз вышел в срок, а второй релиз был доработан позже.

Что должен зафиксировать аналитик:
Регламент: «Каждое требование классифицируется по MoSCoW перед планированием релиза».
Критерии для Must have: если фича не выполнена, релиз не выпускается.
Процесс пересмотра: если появляется новая Must have, другая Must have должна быть перемещена в Should или Could (правило «вход только через выход»).

Вывод: MoSCoW – простой и эффективный способ приоритизации, особенно на этапе согласования границ релиза с бизнесом.

№4877 категория вопросов: #REQUIREMENTS

☀Объяснение:

В чём проблема реляционных БД?
В социальных сетях запрос «друзья друзей» требует трёх JOIN (пользователь → друзья → друзья друзей). При миллионах пользователей такой запрос выполняется очень долго, даже с индексами. Для поиска путей произвольной длины (например, «связь через 5 шагов») реляционная БД практически не приспособлена.

Что такое графовая БД?
В графовой БД данные хранятся как вершины (пользователи, интересы, посты) и рёбра (дружба, лайк, подписка). Обход графа происходит через обход смежных вершин, что на порядки быстрее JOIN-ов. Например, в Neo4j запрос на поиск друзей друзей:
cypher

MATCH (u:User {id: 123})-[:FRIEND]->(friend)-[:FRIEND]->(friendOfFriend)
RETURN friendOfFriend

Этот запрос выполняется за миллисекунды на графах с миллиардами рёбер.

Почему не подходят другие NoSQL:
Документо-ориентированные (MongoDB) – хранят вложенные структуры, но не оптимизированы для связей произвольной глубины.
Ключ-значение (Redis) – хорош для кэша, но не для сложных запросов к связям.
Колоночные (Cassandra) – для аналитики и временных рядов, не для графов.

Реальный кейс: LinkedIn использует графовую БД для рекомендаций «люди, которых вы можете знать». Facebook хранит социальный граф в TAO (своя графовая БД). В компаниях с большими графовыми данными производительность после перехода с реляционной БД на графовую вырастает в 10–100 раз.

Что должен зафиксировать аналитик:
Требование: «Для хранения социального графа и быстрых запросов на обход связей использовать графовую БД (Neo4j, Neptune, JanusGraph)».
Типичные запросы: поиск друзей друзей, рекомендации по общим интересам, проверка связей на расстоянии до 3.

Вывод: Графовые БД – лучший выбор для сильно связных данных, где важна скорость обхода отношений.

https://t.me/boost/SystemAnalystInterview

Давайте поддержим активностью

№4876 категория вопросов: #DBMS

☀Объяснение:

Что такое Strangler Fig?
Название происходит от фикуса-душителя, который обвивает дерево-хозяина и постепенно его заменяет. В архитектуре – это стратегия постепенной замены старой системы новой без «большого взрыва» (big bang). На начальном этапе создаётся фасад (прокси, API Gateway), который маршрутизирует запросы: часть отправляется в старый монолит, часть – в новый микросервис. Постепенно функционал переносится, и доля запросов к старой системе уменьшается. В конце концов монолит отключается.

Как это работает на практике:
Создаётся маршрутизатор (Nginx, Zuul, Envoy).
Выделяется первый модуль монолита (например, «каталог товаров») и реализуется как отдельный микросервис.
В маршрутизаторе настраивается правило: запросы к /catalog/* направляются в новый сервис, все остальные – в монолит.
Следующий модуль («корзина») выделяется аналогично.
Постепенно все маршруты переключаются.
Когда трафик на монолит падает до нуля, он отключается.

Преимущества:
Нет даунтайма.
Возможность отката (при проблемах с новым сервисом можно быстро переключить маршрут обратно).
Каждый этап даёт бизнес-ценность независимо.
Реальный кейс: Amazon переписывал свою архитектуру несколько лет по паттерну Strangler Fig. Каждый микросервис вырезался из монолита и запускался в отдельное окружение. В итоге монолит исчез без единой остановки сервиса.

Что должен зафиксировать аналитик:
Требование: «Замена функциональных модулей должна происходить итеративно, с сохранением работоспособности системы на каждом этапе».
План маршрутизации (какие URL идут на новый сервис).
Критерии переключения (например, когда новый сервис прошёл нагрузочное тестирование).

Вывод: Strangler Fig – стандартный паттерн для безопасного рефакторинга больших систем.

№4875 категория вопросов: #ARCHITECTURE

☀Объяснение:

Напомним нормальные формы:
1НФ – все атрибуты атомарны, нет повторяющихся групп.
2НФ – находится в 1НФ, и каждый неключевой атрибут зависит от всего первичного ключа (а не от его части).
3НФ – находится в 2НФ, и все неключевые атрибуты зависят только от первичного ключа (нет транзитивных зависимостей).

В нашей таблице:
Первичный ключ составной: (order_id, product_id), так как один заказ может содержать несколько товаров.
customer_id, customer_name, order_date зависят только от order_id (части ключа), а не от product_id.
product_price зависит только от product_id (части ключа).
Это частичные зависимости – нарушение 2НФ.

Как исправить?
Разделить на три таблицы:
Orders (order_id, customer_id, order_date)
Customers (customer_id, customer_name)
OrderItems (order_id, product_id, quantity)
Products (product_id, product_price)

Реальный кейс:
В старой учётной системе были проблемы с дублированием имён клиентов и цен товаров. После нормализации до 3НФ избыточность снизилась на 70%, а обновление имени клиента перестало требовать правки тысяч записей.

Вывод: Аналитик, проектируя схему БД, должен проверять составные ключи на наличие частичных зависимостей (2НФ) и транзитивных зависимостей (3НФ).