Почему это важно Заказчикам нужна объективная оценка размера требований до начала разработки. Метод COSMIC позволяет измерить функциональный размер в единицах CFP (COSMIC Function Points) на основе логики данных, независимо от языка и платформы.
Как работает COSMIC (упрощённо) Выделяем функциональные процессы (например, «Начать поездку»). Для каждого процесса определяем триггер (событие, инициирующее процесс – например, пользователь отсканировал QR-код). Определяем объекты данных, которые процесс читает или изменяет (например, состояние самоката, ID пользователя, временная метка). Каждое перемещение данных (вход, выход, чтение, запись) – 1 CFP. В примере с самокатом: «Начать поездку»: триггер – сканирование; читается статус самоката, записывается начало поездки, обновляется счётчик. Это даст, скажем, 4 CFP. Суммируя по всем процессам, получим объективный размер.
Почему не другие варианты A (количество историй) – зависит от степени детализации, субъективно. C (количество экранов) – не отражает сложность логики. D (стори-поинты) – относительная оценка, не переносится между проектами.
Реальный кейс Крупный банк использовал COSMIC для оценки размера кредитного конвейера. Оказалось, что оценка в CFP отличается от экспертной на 15%, но зато прозрачна для заказчика.
Вывод Аналитик, владеющий COSMIC, может дать объективную оценку размера требований и обосновать бюджет.
Проблема Прямые синхронные вызовы между сервисами создают жесткую связанность. Когда сервис А вызывает Б, В, Г, то падение любого из них может затронуть А. Событийная архитектура решает это.
Event-driven Сервис-источник публикует событие в брокер (Kafka, RabbitMQ). Подписчики (другие сервисы) получают события асинхронно. Источник не знает о подписчиках и не ждёт ответа. Отказ одного подписчика не влияет на источник и других.
Почему это снижает связанность Слабая связанность — публикация события и его обработка разделены. Отказоустойчивость — брокер буферизует события, упавший подписчик получит их при восстановлении. Легко добавлять новых подписчиков без изменения источника.
Почему не другие A — ретраи не решат связанность. C — монолит против микросервисной идеи. D — общая БД создаёт другую связанность.
Реальный пример Upwork перешёл на event-driven и ускорил доставку уведомлений в реальном времени.
Вывод аналитика Событийная архитектура — стандарт для слабо связанных микросервисов. Аналитик должен в требованиях указывать асинхронное взаимодействие для всех бизнес-событий, не требующих немедленного ответа.
Почему OFFSET плох OFFSET заставляет базу пропускать все предыдущие строки (10000 записей), даже если они не нужны. При глубине 1 млн строк производительность катастрофична.
Пагинация на основе курсора Вместо OFFSET запрос использует условие на индексированное поле, по которому идёт сортировка, например: SELECT * FROM news WHERE created_at < last_seen_date ORDER BY created_at DESC LIMIT 10. Переменная last_seen_date — значение из последней записи предыдущей страницы. Это называется keyset pagination или seek method.
Преимущества База сканирует только нужные строки + ограниченный диапазон. Работает за O(логарифм) по индексу. Не зависает на больших смещениях.
Требования Индекс на поле сортировки (например, created_at). Уникальный вторичный ключ для разрешения связей (добавить id в ORDER BY).
Реальный пример Twitter и Reddit используют курсоры для бесконечной ленты.
Вывод Аналитик должен потребовать использования курсора вместо OFFSET для любых бесконечных списков.
Честно, мне кажется, через пару лет навык работы с ИИ будет таким же базовым, как умение пользоваться интернетом.
И самое интересное — многие это до сих пор недооценивают.
Кто-то делает всё вручную, а другие уже экономят часы работы с помощью нейросетей и растут быстрее. Разница между ними со временем будет только увеличиваться.
Проблема Когда сервис В недоступен, множество экземпляров сервиса А одновременно начинают повторные попытки с фиксированным интервалом. Это создаёт синхронизированные всплески нагрузки, которые мешают восстановлению. Это называется retry storm (шторм повторных вызовов).
Решение Экспоненциальная задержка (exponential backoff) — интервал между ретраями удваивается (1, 2, 4, 8 секунд). Это раздвигает по времени пики нагрузки.
Джиттер (jitter) — случайное небольшое смещение, чтобы разные экземпляры не синхронизировались. Ограничение числа ретраев (например, 5 попыток). Circuit Breaker — после определённого числа ошибок быстрый сброс без вызова вообще.
Почему не другие варианты A — deadlock относится к блокировкам в БД. C — race condition — состояние гонки, не то. D — thundering herd — асинхронная проблема, но решение с очередями не прямое.
Реальный случай В Amazon одна из внутренних систем легла из-за retry storm. После внедрения экспоненциального бэккотта и джиттера инциденты прекратились.
Требования аналитика Политика ретраев: начальная задержка 1 сек, максимум 10 сек, коэффициент 2, джиттер 0-30%.
Проблема Нереалистичные нефункциональные требования (NFR) — частая ошибка стартапов. Заказчик может назвать цифру «10 000» без обоснования, потому что «конкуренты так могут» или «на всякий случай».
Что должен сделать аналитик Уточнить источник цифры: откуда ожидается такой рост, есть ли маркетинговые прогнозы или это просто желание. Предложить компромисс: сделать архитектуру, которая позволит горизонтально масштабироваться, но не строить инфраструктуру на полную мощность сейчас (например, использовать облачные сервисы с автосейлингом). Задокументировать риск: «При резком росте нагрузки без дополнительных инвестиций система может не выдержать. Требуется повторная оценка через 6 месяцев».
Почему не другие варианты A — согласиться без анализа — приведёт к перерасходу бюджета или невыполнимому обязательству. C — отказ от проекта без попытки обсуждения — не гибко. D — игнорирование — безответственно.
Реальный кейс Один стартап по доставке еды требовал 5000 RPS с первого дня. Аналитик предложил использовать масштабируемый облачный кластер, но с минимальной конфигурацией. После запуска пик оказался 50 RPS. Экономия составила 80% бюджета.
Требования Врач (роль) — доступ к картам пациентов, но только своего отделения (контекст — отделение). Администратор — все карты (вышестоящая роль). Лаборант — доступ только к типу данных «анализы» (контекст — тип данных).
Почему RBAC с контекстными ограничениями Ролевая модель (RBAC) назначает разрешения ролям, а не пользователям. Врачи, лаборанты, админы — это роли. Добавляются ограничения: У врача: условие patient.department == user.department. У лаборанта: условие data_type == 'lab_results'. У администратора: нет условий.
Почему не другие DAC — владелец данных решает, кому дать доступ. Не подходит для медорганизации. MAC — жёсткая классификация (секретно/несекретно), не подходит для бизнес-правил. Только ACL — глобальные списки доступа для каждого объекта, трудоёмко.
Реальный пример Electronic Health Record (EHR) системы используют RBAC с атрибутами (отделение, специализация). Лаборанты видят анализы, но не диагнозы (диагнозы только у врачей).
Что должен зафиксировать аналитик Роли и права. Контекстные ограничения (фильтры). Иерархию ролей (старшая роль включает младшие).
Проблема Наивное описание синхронными сообщениями (сплошная стрелка с заполненным концом) подразумевает, что вызывающий объект ждёт ответа. Для внешнего платёжного шлюза типично: вы отправляете запрос, затем получаете асинхронный ответ через некоторое время (callback, webhook). Изображать это как синхронный вызов неправильно. Как правильно
Асинхронное сообщение — открытая стрелка (линия со стрелкой на конце, но без заливки). Оно означает, что управление не блокируется. Получение callback — изображается как входящее асинхронное сообщение от банка к контроллеру, часто с пометкой «callback» или «webhook». Можно также использовать фрагмент async или показать запуск отдельного потока (активационная полоска).
Почему это важно Асинхронное взаимодействие даёт другую последовательность: клиент получит подтверждение не сразу, а позже. На диаграмме это влияет на временные рамки.
Реальный пример В интеграции с PayPal: ваш сервер отправляет запрос и продолжает работу. Через несколько секунд PayPal присылает уведомление на ваш endpoint. На диаграмме последовательности это показывается как два асинхронных сообщения (туда и обратно), возможно, с фреймом par для параллельных действий.
Вывод Аналитик, рисуя диаграмму последовательности, должен различать синхронные и асинхронные вызовы. Это влияет на проектирование таймаутов, ретраев и обработки callback.
