Статья посвящена фундаментальной структуре аналитической метамодели и метамодели верхнего уровня абстракций (с такими элементами, как цель, ценность, принцип, стратегия, тактика, миссия.
).
Я считаю, что задачей анализа в ИТ является борьба с неопределенностью, чтобы прийти к понимание , что выражается как модели .
Неважно, как представлена модель: в виде схемы, текста, таблиц, она все равно остается моделью.
Существуют разные модели: модель проблемы, модель решения, модель предметной области, бизнес-модель, модель системы, разные модели.
А статья целиком состоит из моделей, в которых будет использован простой вымышленный случай, когда требовалось создание системы.
Клиент: ООО-пекарня «Три яблока», которая специализируется на производстве выпечки с яблочной начинкой.
Заказать: Информационная система поддержки нового хлебобулочного изделия на всех этапах жизненного цикла продукта.
Итак, допустим, бизнес-аналитики собрали все бизнес-требования и описали все бизнес-процессы.
Системные аналитики описали модель данных и процессы на системном уровне.
И разработчики реализовали систему по этим описаниям.
Тестеры тоже постарались, критических ошибок нет. А клиент говорит: «Это не то, что вам нужно!» Давайте разберемся, где что-то в анализе может пойти не так.
Нас интересуют только проблемы анализа.
Нам понадобится следующая иерархия уровней абстракции: 
Розовый уровень – так заказчик видит информационную систему; уровень описывает: какие задачи будет решать созданная система и какие ограничения на нее будут распространяться.
На этом уровне формируются основные бизнес-требования.
Желтый уровень - это уровень операционной деятельности пекарни, включая основные и вспомогательные бизнес-процессы; к этому уровню относится и организационная структура пекарни.
Зеленый уровень — это модель автоматизированных процессов и функций, которые будут реализовывать или поддерживать бизнес-процессы; этот уровень также включает модель данных.
Синий уровень — это воплощение нашей системы в программном коде.
Этих больших уровней достаточно, чтобы выявить следующие возможные проблемы анализа:
- Модель не соответствует решаемой задаче аналитика.
- Модели не являются внутренне согласованными.
- Модели не соответствуют друг другу.
- Реализация по модели не соответствует потребностям пользователей и бизнеса.
Первый метод – итерационный, результатом которого является работающее программное обеспечение.
Это гарантирует, что абстракции проверяются на максимальную глубину и корректируются для управления разработкой в соответствии с целями и ограничениями.
Другой способ — сдвинуть точки зрения навстречу друг другу: сверху вниз – вовлечение пользователей в процесс разработки; снизу вверх – вовлечение разработчиков в обсуждение бизнес-задач и проблем.
А если объединить эти два метода, мы получим приближение к Agile. В нем эти методы закреплены в следующих 2 принципах: 1. Частая доставка рабочего ПО; 2. Общение между представителями бизнеса и разработчиками должно быть ежедневным на протяжении всего проекта.
Еще раз отмечу, что это организационные методы, которые должны были решать, в том числе, и задачи анализа.
И по идее все должно было быть хорошо, но на практике возникают вопросы, над которыми стоит задуматься:
- Вы стали чаще достигать своих рабочих целей? В простых случаях — да, в сложных и крупных проектах Agile требует дополнительных организационных работ и методологий, которые и без того тяжелы.
- Стал ли лучше процесс и результат анализа? По своей сути Agile — это постоянное согласование текущего результата с желаемым.
Время для всестороннего анализа и разработки вариантов ограничено.
Основным способом проверки гипотез является практика, а не рассуждения.
Здесь представлен «старый» аналитический подход. И я говорил не только об Agile; Я вернусь к этому позже.
Но сначала нужно найти краеугольный камень анализа.
Начнем наш поиск со следующего утверждения, которое я привел в начале отчета:
Задача анализа – бороться с неопределенностью, чтобы прийти к пониманию, выражаемому в виде модели.Что такое модель? Что описывают модели? Если исключить из рассмотрения парадигмы, то нижние (исходные, базовые, основные) модели описывают, как субъект совершает действие над объектом или субъект взаимодействует с другим субъектом.
Дополнительными моделями и элементами модели могут быть события, интерфейсы и состояния.
Но основа, вокруг которой все строится, это: субъект, действие, объект. При этом нет разницы, в какой форме построена модель: BPMN, Use Case или UML Sequence диаграмма.
Все таки это модель субъекта, совершающего действие над объектом, или субъекта, взаимодействующего с другим субъектом.
Соответственно, бизнес-анализ строит модели, которые включают бизнес-субъекты, бизнес-объекты и бизнес-процессы.
А системный анализ строит модели, состоящие из программных модулей, объектов данных, а также программных функций и сервисов.
Которые, по сути, тоже являются субъектами, объектами и деятельностью на системном уровне.
Напомню проблемы, которые необходимо решить:
- Модели не являются внутренне согласованными.
- Модели не соответствуют друг другу.
Для этого нужно задать первое требование к моделям: Модели на всех уровнях абстракции должны представлять систему.
Есть еще одна проблема, на которую я указал в начале отчета:
- Реализация по модели не соответствует потребностям пользователей и бизнеса.
И вот второе требование: Модели, взятые вместе, должны ответить на вопрос, что нужно пользователям и бизнесу.
.
Цель и ограничения можно указать как бизнес-требования, но нам необходимо их понять, то есть построить модель.
А потом, ой! Оказывается, это непросто.
Для описания моделей верхнего уровня необходимо использовать и другие элементы; нужна другая метамодель.
Существуют значительные трудности в связывании и согласовании моделей на разных уровнях абстракции.
Если вы подойдете к этому напрямую, то, скорее всего, попытаетесь построить бизнес-модель высшего уровня.
Если вы ищете разные взгляды, вы, скорее всего, найдете холст бизнес-модели Александра Остервальдера.
И в этом табличном представлении вы найдете элементы, которые могут быть необычными, если раньше вы описывали только оперативную деятельность организации.
Вы можете попробовать использовать Architectural Frameworks, BIZBOK или TOGAF. Но без конкретных примеров они представляют собой теоретические абстракции.
На мой взгляд, сложность в том, что они созданы не для того, чтобы кого-то учить, они нужны тем, кто уже знает и понимает, и хочет систематизировать знания.
Ячейка «Почему» отвечает за назначение остальных ячеек в этой строке, но уровень абстракции у нее выше.
Это хорошо видно на матрице Захмана первой версии.
Если взять матрицу Захмана третьего варианта, то в определениях «Цели и методы системы» этот момент размыт, но это не собственные цели системы, это бизнес-цели, реализация которых должна обеспечиваться система.
И с этим выводом формируется «Краеугольный камень анализа» : 1) Модели на всех уровнях абстракции должны представлять система .
2) Назначение элементов системы определяет система .
3) Назначение самой системы находится на более высоком уровне абстракции.
То есть это определяется вышестоящим система(ы) .
Последствие : Невозможно построить модель «Назначения и ограничения», не меняя уровень абстракций.
Но изменить уровень абстракций нельзя, так как метамодель этого уровня отличается от привычной нижним уровням.
То есть для элементов модели информационной системы можно найти назначение в бизнес-модели, а по бизнес-элементам вы можете оказаться в ситуации, когда есть цель и ограничения — это требования бизнеса, но нет модели и понимания.
Как Agile решил эту проблему? В Agile есть принцип: «Общение между представителями бизнеса и разработчиками должно быть ежедневным на протяжении всего проекта».
Ему не всегда следуют, но именно такое общение должно гарантировать, что команда понимает цель и ограничения.
Есть и технические приемы.
Насколько сильно вы задумывались над тем, почему часть пользовательской истории после слова «кому» так сложно написать? И почему критерии INVEST именно такие? Шаблон пользовательской истории:
Как < предмет > , я хочу/могу активность или получить объект > , к < За что или Почему > .ВКЛАДЫВАТЬ ДЕНЬГИ — критерии хорошей пользовательской истории:
Независимый - независима от других историй; Возможен торг - обсуждается, отражает суть, а не детали; Ценный — ценны для клиентов, бизнеса и заинтересованных сторон; достойный — оцениваются по сложности и трудозатратам; Маленький — компактный, может быть выполнен командой за одну итерацию; Тестируемый — протестирован, имеет критерии приемки.Дело в том, что эти критерии описывают требования и ограничения для User Story как своего рода небольшого система .
Почему и почему это встреча наша система и абстракция верхнего уровня, которую сложно написать, если нет понимания.
Так что это полностью соответствует тому краеугольному камню, который я описал ранее.
В 2020 году в Scrum Guide была добавлена концепция цели продукта, а планирование было сосредоточено на вопросе «Почему» для цели спринта.
Agile фокусируется на вершине пирамиды абстракций.
Авторы неглупые люди, они понимают, что это залог успеха.
Для проработки вопроса цели и ограничений вместе с Agile-подходом можно использовать дополнительные методики: дизайн-мышление, картирование воздействия и JTBD. Они все хороши, рекомендую попробовать попрактиковаться.
Но здесь есть большое «НО» — это не сработает, если у вас команда неопытных аналитиков.
Несмотря на кажущуюся простоту и заявленную опору на простой здравый смысл, использовать Agile могут только квалифицированные специалисты с достаточным опытом.
Потому что Agile игнорирует уровни абстракции.
А в Scrum теоретически вообще нет аналитиков, есть кросс-функциональная команда, которая работает, не обращая внимания на уровни абстракции.
Примечание Даже с профессионалами это возможно только одной команде из 7-9 человек, раз у вас большой проект и 3-4 команды, то необходима архитектура, модели, дизайн.
Итак, Agile — это подход, который делает упор на организационные способы решения проблем с участием опытных специалистов.
Используя различные приемы, упомянутые ранее, вы можете получить некоторое представление о целях и ограничениях в виде набора наклеек, историй вакансий и интеллект-карты.
Есть ли более строгий, аналитический способ понять цель и ограничения? 
Посвящается этому Вторая часть статьи.
Теги: #Управление проектами #Управление продуктами #Анализ и проектирование систем #agile #модель #абстракция #метамодель
-
Стираем Свои Цифровые Следы.
19 Oct, 24 -
Самуэльсон, Пол
19 Oct, 24 -
Пресс-Конференция Google В Киеве
19 Oct, 24 -
Архитектурные Шаблоны В Ios
19 Oct, 24
