Post #880

— У нас протечка. — Протечка чего? — У меня всё сиденье мокрое. — Должно быть, это абстракции протекли. К дискуссии о границах ролей. Кажется, границы ролей должны проходить по границам абстракций. Пока тебе не нужно думать о том, как это на самом деле работает — ты остаешься в рамках одной роли. В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры: Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять? Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают. Потом — принципиальную электрическую, и тут выясняется, что постоянный ток не очень-то постоянный, нолики не совсем нолики, а единички — совсем не единички, и что при нажатии кнопки бывает дребезг контактов, который может вызвать 3-5 ложных срабатываний. Причем обрабатывать это нужно либо на логическом уровне, либо вообще на программном — а вот вам и протечка абстракции! Потом нужно развести плату (и расположение элементов на ней может сильно отличаться от принципиальной схемы!), а потом внезапно выясняется, что значки на принципиальной схеме на самом деле имеют размер, высоту, они греются, пылятся, трескаются на холоде, испускают электромагнитное излучение, а ещё имеют собственную частоту (и ваша плата может треснуть, войдя в резонанс при размещении, например, на автомобиле), при пайке их нельзя перегревать, а при креплении платы винтами — перетягивать. Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка! И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего. Можно попробовать ещё накидать типовых точек протечек: — Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают. — Форматы данных при передаче. JSON? XML? Avro? — Парадигма хранилища (реляционное, колоночное, документарное) — Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше) — Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения) — Распределение обращений по однотипным узлам, балансировка нагрузки — Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных — Развертывание, обновление — Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети) Разборки со всеми этими уровнями требуют двух точек зрения: 1. Взгляд на устройство системы: а почему я не могу сделать систему такой, чтобы об этом не нужно было думать? 2. Взгляд на внешние проявления системы: если система будет так себя вести, какую сигнализацию я бы хотел видеть, и какие дополнительные действия мне нужны (например — прерывание зависшей операции, локальное сохранение черновиков, принудительная синхронизация) В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.