Нужна помощь в поиске названия. Есть переход от "модели автоматизации" к "модели автоматизации с учетом возможностей конкретной ИТ системы". Поясню на примере:
Это не выбор СУБД, это не выбор "как делать расширяемую модель данных конкретной сущности с помощью конкретной СУБД", это не выбор "как конкретно мы будем хранить обрабатываемые данные и вообще что будем хранить" - это по идее делает 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?

#wawconf Евгений Скориков. Модели автоматизации бизнес-процессов вместо функциональных требований. Очень интересный доклад о том, как реально происходит проектирование систем. Не теоретически обоснованным одним спуском по уровням, пусть даже замкнутым в итерационный цикл, а с многочисленными возвратами. И какие мыслительные операции выполняются на каждом шаге. И поскольку он это делает не осознанно, то у него боль от несоответствия идеальному процессу, описанному в учебниках, а еще он может пропускать важные, но не очевидные шаги. В презентации было много схем, а у меня будет линейный конспект.

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

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

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

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

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

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

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

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

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

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

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

3. Прямая проекция на функциональные требования. Мы решили, что будет последовательность фоток: ШК и снимки товара. Где брать ШК? На товаре или на накладной? На накладной - увеличивает ошибки, на товаре - может быть сложно снять. А при загрузке: надо уметь отличить ШК от фоток товара.

Когда мы поделили на задачи - потерялась связь между ними. Печать ШК на накладной - это основной способ их получить, или это workaround когда нет ШК на товаре, и на первом шаге можно без него? При этом печать накладной, скорее всего, уже есть, то есть нам надо доработать стандартную фичу, и, наверное, вставить эту задачу соответствующей команде - поэтмоу важно понимать критичность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого, аналитик не просто обеспечивает согласованность решений стейкхолдеров, он делает оптимальное решение. Первое решение далеко не всегда оптимально.
* Мы создаем модели вариантов конструкции и дизайна с помощью типовых конструкций и конструирования из них.
* Решения по выбору принимает менеджер.
* Все это делаем используя некоторое количество мыслительных операций, они перечислены.
* Между уровнями - всегда конструкция. Внутри уровня может быть проекция.

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

Слайды презентации с WAW. Удалось сделать связанный аналитический процесс и структуру документацию, по взаимоувязки аспектов системных уровней. Как сверху вниз, так сверху вниз. Объединяющий системный анализ и продуктовый анализ. В перезентацию все не влезло, поля узкие... )

На WAW я рассказывал про основные системные уровни, артефакты проектирования на этих уровнях и мыслительных операциях проектирования. Не все уровни и не все операции рассказал, многое что не влезло, тем не менее основной каркас аналитического процесса рассказал. А именно - процесс проектирования как процесс создания и трансформации моделей разных системных уровней в разных аспектах.

Проектируйте системы путем декомпозиции на подсистемы, а далее переходите к проектированию подсистем. Сейчас до меня дошло, то раньше пытались декомпозировать ИТ-систему на классы, воспринимая их как подсистемы (давайте делать диаграммы классов UML). А дальше пришел SOA/ микросервисный подход в обоих из которых предполагается деление системы на простые ИТ подсистемы. Каждая подсистема больше чем один класс (обычно) и для ее проектирования достаточно сделать модели структур данных/взаимодействий/доступов/компонтент/размещения и пр, но не нужно проектировать классы. UML диаграммы классов ушли в историю… Или кто-то реально на проектах их использует по назначению (именно как классов в языке программирования)?

Читаю статью (по бизнес-требованиям) и натыкаюсь на пример «бизнес-требования» (судя по контексту, это коммерческая организация в РФ). В ней определена дата подготовки, но почему эта дата - определено достаточно абстрактно. Поразмышляв, появились мысли, что бы я еще добавил, но мне важно понять ваше мнение (не хочу портить вам задачку, якоря на ответ). Напишите плиз, а я в конце дня напишу что стоит добавить на мой взгляд (в статье кстати, сделана неплохая классификация "надсистем" (кроме клиента) для коммерческой организации)

И размышляя о примере выше, вот что еще важно. Требование в таком виде ограничивает пространство решений. Оно уже выработано и если вы не знаете почему выбрано именно такой способ решения, то пространство решений избыточно ограничено. Модель сочетания с другими требованиями может оказаться слишком дорогим. Понимая область проблем можно найти более эффективную модель решения. Вот только почему то проблематику требований, "чтобы что", в статьях постоянно забывают. В итоге в постановке есть верхнедетальные огрызки проблематики, а веть каждое требование имеет какую то свою проблематику...

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

"Клиент, когда приходит за самовывозом заказа, передает данные для идентификации заказа и идентификации себя, как получателя заказа продавцу". Это модель взаимодействия сверху, без определенного функционального дизайна.

Далее мы определяем как функционально это возможно - предлагаем функциональные конструкции

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

После выбора конструкции, модель взаимодействия преобразуется в модель с определенным функциональным дизайном, например:
"Клиент, когда приходит за самовывозом заказа, передает QR код с зашифрованным алгоритмом RSA номером заказа и пин-кодом для идентификации заказа и идентификации себя, как получателя заказа продавцу, который сканирует, убеждаясь в подлинности"
(тут можно заметить, что не определен дизайн c1 уровня - в какой конкретно системе будет это работать и уровень инфраструктуры - конкретно сканирование будет в сканер+комп или ТСД или телефон).

Найдите ошибку в рассуждении. Нам нужна новая еком платформа, чтобы заменить старую еком платформу, так как мы не можем развивать старую легаси платформу. Это ответ на вопрос - чтобы что. Увы, тот кто спрашивал, не увидел дырку в рассуждении

Вопрос в аудиторию. Ощущение, что не хватает удобного инструмента