Евгений Скориков. Размышления про IT-аналитиз и проектирование
243 subscribers
11 photos
2 files
26 links
Всякое из мира ИТ анализа и проектирования. Канал ведет Евгений Скориков
Download Telegram
А вот и долгожданное выступление. Это значимо доработанная версия доклада, который я делал на прошлом ЛАФ (+оформил в статье). Тут фокус на том, как это все выглядит на иерархии систем, где тут работы аналитика, где разработчика и что в каком порядке делать. В том числе, как находить баланс качества, если нельзя оценить потери от недостаточного качества.
Плюс классификация НФТ (не путать с классификацией атрибутов качества, требования качества - лишь часть НФТ)
31 января, в среду вечером, Евгений Скориков расскажет о балансовом подходе при проектированию качественных решений на основе нефункциональных требований.
https://sistemnyy-podkhod.timepad.ru/event/2761260/
Жаркая дискуссия про "неактуальность" use case в одном из чатов подтолкнула на мысль. А кто сказал, что пользователь будет работать по написанному вами usecase? Если он сотрудник компании? Реальные сценарии пользования клиентами интернет магазина сильно разные для разных клиентов. Невозможно спроектировать все случаи разного детального контекста и мотивации с которыми клиент заходит в еком. Работает ли в этих случаях usecase сценарии? Обсудим?
Нужна помощь в поиске названия. Есть переход от "модели автоматизации" к "модели автоматизации с учетом возможностей конкретной ИТ системы". Поясню на примере:
Это не выбор СУБД, это не выбор "как делать расширяемую модель данных конкретной сущности с помощью конкретной СУБД", это не выбор "как конкретно мы будем хранить обрабатываемые данные и вообще что будем хранить" - это по идее делает solution архитектор и это делается одновременно к выбором какой-то конструктивной компоненты ИТ системы
Это выбор "а давайте расширяемую модель обрабатываемых данных вот так". Например, у нас есть "промо 3 по цене 2-х на конкретный товар". Нужно принять решение что это будет:
1. "промо 3 по цене 2-х на выборку моделей товаров"
2. " промо 3 по цене 2-х на динамическую выборку по атрибутам через набор условий (значение атрибута IN список значений) пересекаемых через И
3. " промо 3 по цене 2-х на динамическую выборку по атрибутам через набор условий составляющих дизьюнтивную нормальную форму"
4. "промо Х по цене Y, на ....
Вопрос - как назвать этот системный уровень? Он "внешний " для ИТ системы, так как не раскрывает конструктивную ее модель.
Я постоянно наблюдаю, как СА делают это работу. "Как с помощью настроек и существующих документов обеспечить автоматизацию бизнес-процесса" - к примеру. Что создается ? Модель чего ? "Модель взаимодействия с учетом выбора конкретных функциональных возможностей ИТ системы с учетом минимальности ее доработок" - длинно
Вчера вдруг стало понятно, что создание функциональных требований к ИТ и проработка аспектов качества ИТ системы идут по одной схеме. Вот по этой (я рассказывал ее в прошлом выступлении про НФТ).
Попробуйте догадаться почему (это очевидно, когда понятно ))
В качестве шутки самопредставления. Попробуйте определить все отсылки к книгам и мирам:
Живите и процветайте, я техножрец, ковыряюсь в варпе, учился с Гарри , заострившем кости своих сокурсников, Йог-Сотот ответил мне 42, это сказано вслух, поэтому это правда, это выброс за 5 сигма целевой системы в проблемном месиве, я буду говорить зачем делать, первее чем что, от моего привлечения увеличится TTM вашего горящего проекта. Люблю брин с питиаровыми мангустинами в трехслойном бутерброде обратной связи. Герби стучи в барабан, тяни веревку и дуди в свою дудку.
Model view point (или для моделей архитектуры - архитектурные представления) в рамках описания архитектуры имеет фокус именно на описание в соответветствии с интересами заинтересованных лиц.
Но аналитик на самом деле использует модели, как инструмент взаимосвязывания, обнаружения серых зон и созданию вариантов "обратных конструкций", model view point задает варианты решений, направлет мысль аналитика, по которым мы разбираемся "а в этом варианте как это может быть полезно использовано".
Можно конечно сказать, что есть стейкхолдер - это сам аналитик и у него его интерес проектирования. Но как модель помогает проектировать как -то настолько завуалировано в стандартах, что непонятно, что оно существует
И да, наблюдая работу аналитиков, аналитик постоянно занимается конструированием моделей автоматизации (имея какую то модель задачи).
Пример выявления серых зон в комментах напишу + пришлите свои примеры.
А может быть это описано, ткните меня носом в это плиз, если я пропустил
А давайте разберем задачку. Есть желание определять правила автопривязки товаров к веткам дерева. Есть два варианта:
1) правила задаются значениями произвольного набора атрибутов.
2) правила задаются значениями фиксированного набора атрибутов.
Для каких случаев/для решения каких задач 2 вариант лучше варианта 1?
Forwarded from mtsepkov (Maxim Tsepkov)
#wawconf Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований. Очень интересный доклад о том, как реально происходит проектирование систем. Не теоретически обоснованным одним спуском по уровням, пусть даже замкнутым в итерационный цикл, а с многочисленными возвратами. И какие мыслительные операции выполняются на каждом шаге. И поскольку он это делает не осознанно, то у него боль от несоответствия идеальному процессу, описанному в учебниках, а еще он может пропускать важные, но не очевидные шаги. В презентации было много схем, а у меня будет линейный конспект.

Уровни - есть:
* Бизнес в целом - вписка в рынок
* бизнес-процессы
* модель автоматизации БП
* Функциональный дизайн ИТ-систем
* Конструктивный дизайн ИТ-систем
Но в динамике по ним разворачивается сложный путь.

Рассказ был на конкретном примере, что позволяло почувствовать, что лежит за словами: фотостудия для интернет-магазина, в которую привозят образцы товаров для фото и публикации, а сами образцы возвращают на склад. И на входе процесс был организован вручную.

Вводная: ручной процесс трудоемок и дает ошибки при привязке фото к товарам, давайте попробуем это улучшить с помощью автоматизации. Типичная вводная от бизнеса.

Первый шаг - модель процесса. Бизнес ее не принес. Тут она проста: заказать, привезти, снять и две ветви: привязать к товару и отобразить, а товар вернуть на склад.

2. Идея автоматизаци -: новая конструкция взаимодействия людей и софта, которая решил проблемы. Помечаем проблемные точки: заказать товары для съемки; правильно привязать фотки. Для каждой - идея решения.

Заказ решается быстро, делаем отчет, сравнивая товары на складе с наличием фотографий товаров.

С привязкой - сложнее. Тут решение НЕ очевидно. Товар определяется своим штрих-кодом. И можно взять умный фотоаппарат и запрограммировать, снимать им сначала ШК, потом товары, и чтобы он делал привязку каждой фотки. А можно брать обычный фотоаппарат и пусть фотограф снимает сначала ШК, потом товары, а дальше умная загрузка пойдет по последовательности фоток.

У решений выписываем плюсы и минусы - по качеству решения, трудоемкости, надежности. Дальше делаем выбор. Важно, что выбор делает бизнес, а не аналитик - он видит больше аспектов. Типичная проблема, когда аналитики сделали выбор сами, из своего понимания, и какие-то аспекты не учли. Но задача аналитика - подготовить варианты. Для выбора нужна какая -то оценка трудоемкости. Не точная - она должна быть достаточна для разделения вариантов. Кроме трудоемкости могут быть смежные аспекты, например, потенциал развития. А еще проблема, когда аналитики берут первое попавшееся решение, вообще не смотрят варианты.

Дальше решение детализируется по разным бизнес-процессам.
* Детализировать модель - по шагам
* Детализировать контекст. Съемка одежды и съемка конструктора - разное: одеть куртку на манекен или собрать из конструктора что-то - разное время. А декоративная сетка - вообще нельзя в студии.
* Детализация бизнес-процесса. Своя фотостудия или чужая - тогда билинг и так далее, ценообразование с выбором фотостудии.
* Контроль качества
* Управление процессом
* Обеспечение деятельности - расходники и так далее.
* Фискальный аспект
* Последовательность, организация, информация.

Для шагов есть типовые задачи, например, заказ со склада - там надо использовать, не придумывать. А есть - не типовые, их надо уметь конструировать через типовые. И нужен опыт оценки трудоемкости, чтобы удерживать стоимость.

Это все - проработка на бизнес уровне.

3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной - увеличивает ошибки, на товаре - может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.
Forwarded from mtsepkov (Maxim Tsepkov)
Когда мы поделили на задачи - потерялась связь между ними. Печать ШК на накладной - это основной способ их получить, или это workaround когда нет ШК на товаре, и на первом шаге можно без него? При этом печать накладной, скорее всего, уже есть, то есть нам надо доработать стандартную фичу, и, наверное, вставить эту задачу соответствующей команде - поэтмоу важно понимать критичность.

Еще делаем проекцию на структуры данных. ШК - может ли один быть у нескольких товаров и так далее.

При проекции не создается новых знаний или принятие решений. Просто преобразование.

4. Возврат на проектирование - при проекции появились серые зоны, надо проработать бизнес-уровень. Например, может ли быть один ШК к нескольким товарам? Если может быть, то как разбираться? На уровне процесса. Могут быть дополнительные атрибуты и выбор при привязке фоток на загрузке, а может быть оклейка уникальными ШК, чтобы избежать дублирования.

Обработка исключений. Фотограф забыл сделать фото ШК, или система не может ШК распознать - как исправляется ситуация? Например, поскольку на товаре ШК может быть плохой, печать на накладной дублирует возможность сделать фото.

При возврате к уровень бизнес-процессов они могут меняться, и, возможно, потребуются доработка автоматизации.

4. Функциональный дизайн. Например, нужно контролировать количество ракурсов. При этом у разного вида товаров - разное количество. Например, у обуви 7, у одежды - 8. Вопрос: что сделать в ИТ-системе, чтобы был контроль? Hard code, настройка - в атрибутах товаров или сбоку через наборы условий и так далее. Из вариантов надо сделать выбор. Если мы выбрали таблицу правил, то дальше вопрос: какой язык записи правил, какие атрибуты. И появляется новый процесс заполнения таблицы.

5. Есть модель автоматизации - делаем дизайн. А потом идет возврат от дизайна к модели. Аналитики часто делают дизайн в рамках конкретного типового набора. А в конкретных случаях может быть нужен выход за типовые рамки. И от дизайна - идет возврат на уровень конструкции системы и бизнес-процессов с учетом дизайна.

6. Конструкция. Типовые деления, виды приложений, которые мы используем.

7. Исполнение конкретных функций. Например, фотограф сделал фото и как грузит? В локальную папку и указывает? Или в сетевую, откуда система сама автоматом забирает?

8. Возвратное проектирование. Фото 10мб, 10 фото на товар, 100к товаров - получили объемы, они дают технические решения. И тут могут появиться проблемы.

9. Проработка аспектов качества - было на ЛАФ. Там аспекты, которые меряют потери против расходов на обеспечение качества. Например, чтобы формочки открывались быстро. А тут на форме 10 фото, и будет открываться 16 секунд - очень долго. Разные тактики, например, авторесайз загруженных фоток, чтобы отображать уменьшенные. И тут возвратным ходом может быть решение хранить картинки не в БД, а на медиасервере, потому что он автоматом делает авторесайз.

Аспекты качества - на разных уровнях. Верхний - качество бизнес-процессов, а автоматизация - одна из тактик. Хотя качество автоматизации тоже играет.

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

В завершении - комплексная картинка. С перемещением по уровням вниз-вверх, с возвратами, проработкой вариантов и выбором.

А где функциональные требования? Они возникали во всех операциях в двух случаях.
* При декомпозиции они являются способом отбросить лишнее, при этом может оказаться, что выполнение сложно - и надо вернуться. А для этого надо фиксировать варианты и основания выбора. Это не делают - и нельзя проверить ТЗ.
* Модель взаимосвязи разных моделей.
Есть мыслительные операции, когда вообще не использовали ФТ. Конструкция -> дизайн - работа с моделью. Проекция моделей - тоже без ФТ.
Forwarded from mtsepkov (Maxim Tsepkov)
Итого, аналитик не просто обеспечивает согласованность решений стейкхолдеров, он делает оптимальное решение. Первое решение далеко не всегда оптимально.
* Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.
* Решения по выбору принимает менеджер.
* Все это делаем используя некоторое количество мыслительных операций, они перечислены.
* Между уровнями - всегда конструкция. Внутри уровня может быть проекция.

И есть боль. В постановках очень часто пишут, что надо изменить. И в результате разобраться, как система работает в окружении очень сложно - надо инкрементально проработать все постановки. Нужно быть представление, чтобы работать сейчас.
Слайды презентации с WAW. Удалось сделать связанный аналитический процесс и структуру документацию, по взаимоувязки аспектов системных уровней. Как сверху вниз, так сверху вниз. Объединяющий системный анализ и продуктовый анализ. В перезентацию все не влезло, поля узкие... )
На WAW я рассказывал про основные системные уровни, артефакты проектирования на этих уровнях и мыслительных операциях проектирования. Не все уровни и не все операции рассказал, многое что не влезло, тем не менее основной каркас аналитического процесса рассказал. А именно - процесс проектирования как процесс создания и трансформации моделей разных системных уровней в разных аспектах.
Проектируйте системы путем декомпозиции на подсистемы, а далее переходите к проектированию подсистем. Сейчас до меня дошло, то раньше пытались декомпозировать ИТ-систему на классы, воспринимая их как подсистемы (давайте делать диаграммы классов UML). А дальше пришел SOA/ микросервисный подход в обоих из которых предполагается деление системы на простые ИТ подсистемы. Каждая подсистема больше чем один класс (обычно) и для ее проектирования достаточно сделать модели структур данных/взаимодействий/доступов/компонтент/размещения и пр, но не нужно проектировать классы. UML диаграммы классов ушли в историю… Или кто-то реально на проектах их использует по назначению (именно как классов в языке программирования)?
Читаю статью (по бизнес-требованиям) и натыкаюсь на пример «бизнес-требования» (судя по контексту, это коммерческая организация в РФ). В ней определена дата подготовки, но почему эта дата - определено достаточно абстрактно. Поразмышляв, появились мысли, что бы я еще добавил, но мне важно понять ваше мнение (не хочу портить вам задачку, якоря на ответ). Напишите плиз, а я в конце дня напишу что стоит добавить на мой взгляд (в статье кстати, сделана неплохая классификация "надсистем" (кроме клиента) для коммерческой организации)
И размышляя о примере выше, вот что еще важно. Требование в таком виде ограничивает пространство решений. Оно уже выработано и если вы не знаете почему выбрано именно такой способ решения, то пространство решений избыточно ограничено. Модель сочетания с другими требованиями может оказаться слишком дорогим. Понимая область проблем можно найти более эффективную модель решения. Вот только почему то проблематику требований, "чтобы что", в статьях постоянно забывают. В итоге в постановке есть верхнедетальные огрызки проблематики, а веть каждое требование имеет какую то свою проблематику...