Не могу сказать что всегда. В каких то случаях вначале детализируется бизнес-процесс (например, когда проектируется последовательность его исполнения). В каких-то наоборот (например, когда проектируется структура обрабатываемых данных или модель ограничения доступа). Не могу сказать, что существует универсальной траектории проектирования. В общем случае принимается решение о том, какая модель следующая в проработке (может быть моделью бизнес-процесса или моделью ИТ системы). Проработка модели создает вопросы, которые создают точки зрения по которым строятся модели обоснования
Спасибо за статью. Некоторые моменты остались неясными
Как связаны Event storing и User story mapping, как одно перетекает в другое?
и не хватает описания: как идет переход от требований к макетам: по какой логике формируются формы из потока требований, как требования превращаются в отображаемую информацию, действия и обработку действий?
Я так же не встречал enterprice архитекторов не бывших программистов. Но архитекторов много, есть, к примеру, бизнес-архитектор, архитектор инфраструктуры и пр, где программирование не требуется
Почему вы так решили? Методолог, судя по названию, разрабатывает методику реализации каких-то работ. Вероятно, вы имели в виду "архитектора". Но в жизни проектированием моделей (функциональных моделей) занимается именно аналитик. Иначе он не может сопоставить различные требования к решению (и проекту решения) и понять что выполнимо, а что нет. Вариативность возникает из-за того, что требования/потребности не всегда определяют решение однозначно
Жаль, что вам не зашло. Цель статьи - показать на простом жизненном примере чем требования отличаются от модели. Цель Васи (goal) - обеспечить себе достойную прибыль (подразумевается, хотя вы правы, стоило указать), цель Васи (objective) - сделать магазин на Охотном ряду.
Смысл примера в том, что требования заказчика могут (и чаще всего так и бывает, особенно по расходам и срокам) быть не выполнимы. И это нормально. Пока требования не связаны, невозможно проверить выполнимость. Задача аналитика зачастую - выявить функцию штрафа, "на сколько сроки можно нарушить" - или более точно "к каким последствиям для бизнеса приведет какое нарушение этого требования". И создать решение с наименьшим штрафом.
Расчеты в статье, разумеется, взяты с потолка. В реальности, модель анализа рынка в конкретной точке - предмет отдельной статьи (или книги). Смысл - показать, что требование по обороту не выполнено и насколько не выполнено. Или более точно стоит говорить, каким качеством "оборот" обладает спроектированное решение (и не нужно путать оценку качества модели решения с требованием к модели решения)
Да, вы правы. Я намерено указал в статье то, как советует Вигерс и Ко, как будто аналитик после цели начинает с требований. В реальности, он разумеется, начинает с моделей использующих систем. Цель статьи - показать различие моделей проектируемой системы и требований к ней.
К сожалению, далеко не каждый программист может стать аналитиком. Большинство программистов думают "как это запрограммировать", а аналитики думают "зачем это нужно и как можно это не программировать". Программисту каждая задача кажется "гвоздем", грубо говоря.
Да, вы правы, знание синтаксиса помогает никак. Собственно в статье указана цель тренировки - это не изучение синтаксиса, а как раз изучение алгоритмики, в том числе синхронного и асинхронного выполнения
Да, вы с одной стороны правы, сложно определить гармонию через ее назначение. С другой стороны мне это нужно будет в последующих статьях для определения понятий "требование", "потребность", "обоснование", "модель", "система" и других понятий системной инженерии (которые в SEBoK определяются несколько абстрактно, без назначения, без примеров и антипримеров). Сами по себе эти понятия не являются вещами, это концепции. Но можно вполне рассуждать над тем, что такое назначение требования, примеры, антипримеры и пр.
Иными словами, стратегия - это модель решения задачи, а прибыль, обороты, доля рынка это атрибуты качества этой модели. Найти стратегию - это построить модель с заданными приоритетами атрибутов качества в заданном контексте, с заданным текущим состоянием
Очень не хватает понятных примеров. Лучше ткнуть пальцев в слонов и сказать «это слон, и это слон, и это слон», чем говорить: «слон это большое травоядное животное с большим весом, живущее в Африке» (бегемот — это слон).
Собственно без создания моделей невозможно оценить стоимость перехода, а без этого БА похож на Сову из анекдота "станьте ёжиками"
Не могу сказать что всегда. В каких то случаях вначале детализируется бизнес-процесс (например, когда проектируется последовательность его исполнения). В каких-то наоборот (например, когда проектируется структура обрабатываемых данных или модель ограничения доступа). Не могу сказать, что существует универсальной траектории проектирования. В общем случае принимается решение о том, какая модель следующая в проработке (может быть моделью бизнес-процесса или моделью ИТ системы). Проработка модели создает вопросы, которые создают точки зрения по которым строятся модели обоснования
Спасибо за статью. Некоторые моменты остались неясными
Как связаны Event storing и User story mapping, как одно перетекает в другое?
и не хватает описания: как идет переход от требований к макетам: по какой логике формируются формы из потока требований, как требования превращаются в отображаемую информацию, действия и обработку действий?
Пожалуйста))
Я так же не встречал enterprice архитекторов не бывших программистов. Но архитекторов много, есть, к примеру, бизнес-архитектор, архитектор инфраструктуры и пр, где программирование не требуется
Почему вы так решили? Методолог, судя по названию, разрабатывает методику реализации каких-то работ. Вероятно, вы имели в виду "архитектора". Но в жизни проектированием моделей (функциональных моделей) занимается именно аналитик. Иначе он не может сопоставить различные требования к решению (и проекту решения) и понять что выполнимо, а что нет. Вариативность возникает из-за того, что требования/потребности не всегда определяют решение однозначно
Жаль, что вам не зашло. Цель статьи - показать на простом жизненном примере чем требования отличаются от модели. Цель Васи (goal) - обеспечить себе достойную прибыль (подразумевается, хотя вы правы, стоило указать), цель Васи (objective) - сделать магазин на Охотном ряду.
Смысл примера в том, что требования заказчика могут (и чаще всего так и бывает, особенно по расходам и срокам) быть не выполнимы. И это нормально. Пока требования не связаны, невозможно проверить выполнимость. Задача аналитика зачастую - выявить функцию штрафа, "на сколько сроки можно нарушить" - или более точно "к каким последствиям для бизнеса приведет какое нарушение этого требования". И создать решение с наименьшим штрафом.
Расчеты в статье, разумеется, взяты с потолка. В реальности, модель анализа рынка в конкретной точке - предмет отдельной статьи (или книги). Смысл - показать, что требование по обороту не выполнено и насколько не выполнено. Или более точно стоит говорить, каким качеством "оборот" обладает спроектированное решение (и не нужно путать оценку качества модели решения с требованием к модели решения)
Да, вы правы. Я намерено указал в статье то, как советует Вигерс и Ко, как будто аналитик после цели начинает с требований. В реальности, он разумеется, начинает с моделей использующих систем. Цель статьи - показать различие моделей проектируемой системы и требований к ней.
Дело в том, что в сообществе аналитиков обсуждается именно такой вопрос. Статья описывает как раз то, что именно программирование знать и не нужно.
Напишите, пожалуйста, комментарии к содержанию статьи, а не к названию.
Я тоже так считаю !
К сожалению, далеко не каждый программист может стать аналитиком. Большинство программистов думают "как это запрограммировать", а аналитики думают "зачем это нужно и как можно это не программировать". Программисту каждая задача кажется "гвоздем", грубо говоря.
Полностью с вами согласен. Аналитики без минимального опыта программирования не создают полезные модели будущей системы.
P.S. Кстати, у меня был такой же путь развития. Программист-РП-аналитик-архитектор
Да, вы правы, знание синтаксиса помогает никак. Собственно в статье указана цель тренировки - это не изучение синтаксиса, а как раз изучение алгоритмики, в том числе синхронного и асинхронного выполнения
да да, уменьшать ))
Да, вы с одной стороны правы, сложно определить гармонию через ее назначение. С другой стороны мне это нужно будет в последующих статьях для определения понятий "требование", "потребность", "обоснование", "модель", "система" и других понятий системной инженерии (которые в SEBoK определяются несколько абстрактно, без назначения, без примеров и антипримеров). Сами по себе эти понятия не являются вещами, это концепции. Но можно вполне рассуждать над тем, что такое назначение требования, примеры, антипримеры и пр.
Хорошая статья, большое спасибо
Для книги «Шаблоны корпоративных приложений» приложено фото другой книги.
Иными словами, стратегия - это модель решения задачи, а прибыль, обороты, доля рынка это атрибуты качества этой модели. Найти стратегию - это построить модель с заданными приоритетами атрибутов качества в заданном контексте, с заданным текущим состоянием