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

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 для тестирования – полезный метод, особенно когда нужно быстро дать оценку при планировании, а детальные спецификации ещё пишутся.

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

Feature Toggles (Feature Flags) – это механизм, позволяющий включать или выключать определённую функциональность во время выполнения программы без выкатки нового кода. Значения флагов обычно хранятся в централизованной конфигурации (файл, база данных, Redis) или в стороннем сервисе (LaunchDarkly, ConfigCat). Код содержит проверку (if feature_is_enabled('new_payment')) и в зависимости от флага выполняет новый или старый алгоритм.

Как решается задача тестирования на 5% пользователей:

· Создаётся флаг new_payment с правилом: включён для 5% случайных user_id (по модулю или хешу).
· Остальные 95% продолжают использовать старую оплату.
· При обнаружении ошибки администратор меняет правило на 0% (или false) – система мгновенно переключает всех обратно на старый код. Никакого передеплоя не требуется.

Виды Feature Toggles:

1. Release Toggles – для скрытия незавершённого кода до релиза.
2. Experiment Toggles – для A/B-тестирования (как в примере).
3. Ops Toggles – для управления производительностью (например, отключить тяжёлый отчёт).
4. Permission Toggles – для доступа новых фич только определённым пользователям (бета-тестеры).

Преимущества:

· Безопасный rollout: можно включить функцию постепенно для групп пользователей.
· Мгновенный откат: при проблемах выключаем флаг за секунды.
· Независимость от циклов релиза: можно деплоить код с флагами, а включать позже.
· Возможность канареечных релизов (canary releases) и A/B-тестов.

Недостатки:

· Усложнение кода (много if/else).
· Со временем накапливаются устаревшие флаги (технический долг).
· Требуется централизованное хранилище с хорошим временем ответа.

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

Что должен зафиксировать аналитик:

· «Ключевые изменения бизнес-логики должны быть реализованы через Feature Toggles».
· «Процесс отката: при выключении флага система переходит на предыдущее поведение в течение 1 минуты».
· «Устаревшие флаги должны удаляться после 2 релизов, для этого завести техническую задачу».

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

Раскрываем секреты🤫

Как нам удается стабильно зарабатывать с блога 300-500к+ рублей🔥

Мы собрали свою ЛИГУ ЭКСПЕРТОВ и упаковали опыт в конкретные шаги, которые можно внедрить и увидеть рост уже в этом месяце.

🎁Более 300 подарков про:

▪️ТРАФИК

— Как выйти на первые 1000 подписчиков в Telegram без бюджета и рекламы
— Секретные связки, дающие поток заявок уже за 7 дней
— База проверенных блогеров для рекламы в Telegram
— Как бесплатно привлекать подписчиков из Threads и получать заявки системно
— Подборка топовых сервисов для поиска рекламных каналов в МАХ
— Движуха в МАХ, где можно набрать подписчиков бесплатно!

▪️ПРОДАЖИ

— Простые инструменты ИИ для ускорения работы и ведения вашего блога
— Продающие скрипты для переписок, которые реально закрывают на оплату
— Система регулярных продаж руками команды
— Как эксперту вытащить КЭШ из блога за 24 часа
— Схема продаж на холодную аудиторию
— Автоворонки, которые продают за вас пока вы отдыхаете

И много других мощных подарков!

Чек-листы, статьи, уроки и подкасты - как стабильно находить клиентов
и делать продажи в новых реалиях.

Чтобы забрать подарки подпишитесь на всех экспертов из папки👇
https://t.me/addlist/2ozqmVS4cDozZWNi

Если вы планируете зарабатывать в Telegram — без этой папки вам будет сложно.

Это не просто информация — это выжимка опыта, на сбор которой обычно уходят годы.

Мне регулярно задают одни и те же вопросы:

✅«Почему нет роста?»
✅«Откуда брать подписчиков?»
✅«Как выйти на доход в Telegram?»

И в большинстве случаев причина одна — нет чёткого понимания, как работает продвижение и маркетинг.

Все знания обычно собираются по частям из разных источников.
Я упростила этот путь и собрала всё в одном месте.

Сохраняйте и добавляйте себе.

Переход по ссылке: https://t.me/addlist/7wOVy3SDM2diNjUy

Записывайся в подборку🫶

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

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

Почему не одно конечное событие (A)?
Если свести все три исхода в одно конечное событие, то на диаграмме будет непонятно, какой результат достигнут. Более того, для «Отправлена на доработку» может потребоваться дополнительная информация (например, комментарий проверяющего), что невозможно выразить единой точкой выхода.

Почему не два конечных события (успех/ошибка)?
В бизнес-процессе «Отправлена на доработку» – это не ошибка, а нормальное, ожидаемое состояние (например, заявка требует правок). Моделировать его как ошибку было бы некорректно и сбивало бы с толку аналитика и исполнителя.
Как изобразить на диаграмме:
После шлюза (XOR или OR) расходятся три потока.
Каждый поток ведёт к своему конечному событию.
У конечных событий можно задать имена (например, «Утверждено», «Отклонено», «На доработку»).

Реальный пример:
В процессе найма сотрудника возможны исходы: «Принят», «Отклонён», «Резерв». Каждый исход завершает процесс по-разному (в HR-системе разные статусы заявки). Три конечных события – стандартная практика.

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

Вывод: Количество конечных событий в BPMN должно соответствовать количеству бизнес-исходов процесса. Неверное количество приводит к потере информации и неверной реализации.

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

Двухфазная фиксация (2PC):
Протокол, обеспечивающий строгую атомарность в распределённой среде. Имеет две фазы:
Подготовка (prepare) – координатор опрашивает все узлы, могут ли они зафиксировать транзакцию; узлы блокируют ресурсы и отвечают «готов».
Фиксация (commit) – если все готовы, координатор даёт команду commit, иначе – rollback.

Недостатки 2PC, критичные для требований:
Блокировки – ресурсы заблокированы на всё время транзакции (включая ожидание ответов). Это увеличивает задержку.
Координатор – единая точка отказа – если координатор упал после отправки commit, система может зависнуть.
Плохая масштабируемость – при большом числе участников растёт время и вероятность сбоев.
Не подходит для высокодоступных систем – требование «высокая доступность» несовместимо с 2PC, так как при сетевом разделении 2PC блокируется.

Saga (Сага):
Разбивает распределённую транзакцию на последовательность локальных транзакций. Каждая локальная транзакция обновляет свой сервис и публикует событие. Если транзакция не удалась, запускаются компенсирующие транзакции (откат выполненных шагов).

Варианты реализации Saga:
Хореография – сервисы обмениваются событиями без центрального координатора.
Оркестрация – центральный оркестратор управляет шагами и компенсациями.

Преимущества Saga:
Нет длительных блокировок – каждая локальная транзакция быстро фиксирует изменения.
Высокая доступность – нет единой точки отказа (в хореографии). Даже при оркестрации можно перезапустить оркестратор.

Масштабируемость – каждый сервис может обрабатывать свои транзакции независимо.
Недостаток Saga:
Конечная согласованность (eventual consistency) – в момент между шагами данные могут быть несогласованы (например, деньги списаны, товар ещё не зарезервирован). Но для многих бизнес-сценариев это допустимо.

Почему Saga подходит под требования «низкая задержка, высокая доступность»:
Нет блокировок → низкая задержка.
Нет единой точки отказа → высокая доступность.
Компенсации позволяют откатить изменения без глобальных блокировок.

Реальный пример:
В Uber для заказа поездки используется Saga: создание заказа → поиск водителя → списание средств → уведомление. Если поиск водителя не удался, запускается компенсация: отмена заказа и возврат средств.

Что должен зафиксировать аналитик:
«Для критичных по доступности и латентности распределённых операций использовать паттерн Saga».
«Для каждого шага определить компенсирующее действие (что делать при отказе)».
«Допустима конечная согласованность с максимальным окном 5 секунд».

Вывод: 2PC подходит для систем, где строгая атомарность важнее доступности и задержки (например, банковский перевод внутри одного кластера). Для микросервисов с высокими требованиями к доступности и скорости Saga – стандарт.

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

Что такое принцип наименьших привилегий (PoLP)?
Это фундаментальный принцип информационной безопасности, согласно которому любой субъект (пользователь, процесс, сервис) должен иметь только те права доступа, которые минимально необходимы для выполнения его функций, и не более. Даже если сервису нужно много файлов, ему можно дать доступ только к определённой директории и права на чтение, но не на запись или выполнение.

Почему в примере нарушен PoLP:
Сервису резервного копирования достаточно прав на чтение файлов из определённых каталогов и записи в каталог бэкапов. Ему не нужны права на установку программ, изменение конфигурации системы, доступ к другим сервисам. Выдача прав администратора даёт всё это, что резко увеличивает риски.

Реальные последствия нарушения:
При взломе сервиса атакующий получает полный контроль над хостом (root/Administrator).
Он может установить вредоносное ПО, получить доступ к данным других приложений, использовать сервер для атак на другие системы.

Как правильно:
Создать отдельную учётную запись для сервиса.
Выдать ей права на чтение только необходимых директорий (например, C:\data\, /var/www/).
Запретить интерактивный вход (только сервисный).
Использовать групповые политики или мандатный контроль доступа (SELinux/AppArmor).

Пример из практики:
В Amazon Web Services пользователям рекомендуют создавать IAM-роли с минимальными правами для каждого сервиса (например, EC2 может читать только свой S3-бакет, а не все бакеты компании).

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

Вывод: Принцип наименьших привилегий — краеугольный камень защищённой системы. Нарушение этого принципа многократно увеличивает ущерб от успешной атаки.