Как только хочется сказать "невыгодный/выгодный", "ценности", "хорошо/плохо" - сразу отвечать на вопрос, кто акторы (чьих точек зрения будет). Иначе крайне неопределённый разговор
Тема 1: Перепутаны понятия "иррациональное" и "непознанное". Человек - абсолютно физическое существо. Как изучат, так и будет для нашего понимания 100% предсказуем. Сейчас неизучен, есть очень грубые модели, поэтому нам человек и кажется иррациональным
Задача БА - выявить цель бизнеса, когда к нему прикатывает "Мы хотим". И только потом работать с требованиями по реальным целям.
Поэтому приведённый пример с БА - это плохой БА. БА - это не передачтик между бизнесом и командой разработки. Прежде чем выкатывать требования, БА должен прогнать их по критериям. И тогда автоматом не будет этого примера.
Ок, допустим, БА промахнулся с договором через e-mail. Но дальше, если возможные решения напрямую затрагивают бизнес-процессы, то это уже вне работы СА. То, что описано в примере, обсуждается на этапе принятия решений по бизнес-процессам (см. выше, это я уже повторяюсь). И в данном случае СА это должен вернуть взад БА, чтоб тот почесал затылок и провернул ещё одну итерацию с бизнесом и командой
Спасибо за краткое изложение, но у меня повились вопросы.
Логичнее располагать вопросы аналтика иерархично. Первым напрашивается "Зачем?"
"Зачем это делать?" для СА - расширить функциональность? Если у нас есть БА, то не могу представить для СА такой формулировки. Результат БА - артефакты в виде описанных конкретных целей бизнеса и способа их достижения бизнесом - бизнес-процесс. БА говорит, что делать с бизнес-функциональностью (создать/изменить/убить, не "расширить/уменьшить"). Тогда зачем это делать СА? Чтобы заработать денег - какой вопрос, такой и ответ, потому что вопрос должен указывать на объект, а не на субъект; например, Что должен достичь СА? достичь (описанных БА) конкретных целей системы.
Microsoft теперь позиционирует Copilot как бесплатную версию своего чат-бота, которая будет доступна всем пользователям в поисковике Bing, браузере Edge и Windows, а также по собственному адресу copilot.microsoft.com
В Firefox - недоступна. И это логично, потому что в оригинале статьи нет такого, перевод неточный. Иметь свой домен и быть доступным по адресу - разная функциональность.
Я, как обыватель, ничего не понял, а что для меня, потребителя, полезного? Ну, я и так почти 2 года назад понакупал кучу китайских 2ТБ NVMe накопителей для апгрейда всех ноутов в семье. Тут что-то ёмче/круче/дешевле? И текст какой-то странный:
Так, в КНР в продаже появился 1-терабайтный накопитель ZhiTai Ti600
Упаси боже, чтоб я кого-то убеждал что-то переделывать в неизвестной мне системе. Это я пытаюсь понять логику и как оно работает через вопросы и некоторые постулаты
Просто я за то, чтобы глагол определял именно то значение, которое он имеет в своём действии. Повторюсь, под "принять" подразумевать "создать" - очень плохая практика. Ещё раз повторюсь, объект или есть, или его нет. Что такое "безликая сущность с генерализованным названием"? Это или запрос (объект!) на создание объекта-заявки, или сама заявка. Посередине не бывает. В принципе, как в ИС возможно существование "безликой сущности"?
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности
Триггер - это какое-то событие. Актор - это субъект, что-то выполняющий. Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано. Надо отделять артефакты физического мира и артефакты смоделированной ИС. Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий. Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС. Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система, только хардкор. Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом. Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)). Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Пока не соглашусь, что время - это актор. Это что-то из внематериального и эзотерического. Ну как время (что это за субъект такой - время?!) может на что-то воздействовать? Чем оно воздействует?
Во всех примерах вместо Time очень чётко встаёт конкретная система. Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б. Можно выделить конкретный модуль/компонент/сервис, если требуется - так будет нагляднее, что внутри объекта "Торговая система" есть актор-модуль, являющийся в данном процессе субъектом
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда.
Не, так не пойдёт )). "Подразумевается", "можно считать, что" и т.п.- страшные вещи! 1. "Принята" - значит, принят, получен объект. Никак не создан. Создание - это создание объекта, никак не его передача/получение. Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запросна создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
была некоторая недосказанность в статусной модели мастер-системы
Вот именно, я про это. Задайте вопрос - кто владелец объекта, кто заинтересованные в этом объекте акторы. К кому будет ходить фронт (пользователь) за статусом заявки? А как информационная система (не бэк) вообще понимает, что происходит с этой заявкой? Где связь заявки с договором? Если команда отвечает только за один компонент (бэк, обрабатывающий заявку), то, я так считаю, у команды должна быть полная статусная модель объекта, даже если управление объектом отдаётся в другие сервисы, ИС. Хотя бы потому, что полная модель позволяет:
понимать границы ответственности каждого компонента/сервиса за объект;
трассировать входящие, исходящие и внутренние требования по работе с объектом;
заранее понимать возможные требования к обработке объекта - заранее подстелить соломку в нужных местах проектирования логики
А так вы пилите ногу слона и не знаете, или она должна ходить в составе слона, или её на мясо, или её пришьют не к слону, или...
был предусмотрен вызов 1-й системы из 2-й
Это продолжение предыдущего, на самом деле. Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха? Могу сказать, что это совсем не праздные вопросы. В продукте моего проекта предыдущие команды разработки предусмотрели ответ только принят/не принят на техническом уровне, прямо как тут. И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Вот только начал смотреть и сразу бросилось в глаза:
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку. В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Я чего так волнуюсь за статью :) - у меня сейчас в работе очень похожая ситуация. Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Логика статьи подхода к проектированию правильная. Тоже вижу, что фомальное следование нотациям может иметь близкую к нулю ценность. Например, в качестве промежуточной схемы между вариантами поведения и бизнес-процессами (БП) пару раз омогало сначала накидывать движение управления процессами прямо внутри вариантов поведения, а потом уже, поглядывая на полученного ежа с ужом, спокойно отрисовывать БП
Два раза перечитал и всё никак не мог врубиться, почему команда стала частью схемы. Пока не посмотрел на схему. Я понимаю, конечно, что на англ. это просто "command". Но надо же учитывать контекст. "Командой" часто называют актора процесса (team). Было бы чуть лучше сказать "управляющая команда"
Спасибо за ответ. Именно так, можно по-разному выгребать бэклог, но в любом случае это должен быть постоянный рабочий процесс. А не набеги в стиле "ой, мальчики, давайте поиграем стильно-модно-молодёжно (а то у меня скиллов не хватает - сделайте что-нибудь)"
Полностью поддерживаю предыдущих ораторов, вплоть до профпригодности. После прочтения заголовка "Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям" хочется спросить - народ в этой ваше Ламоде, а что вам раньше мешало сделать то же самое, но в нормальном рабочем процессе? И вы вообще понимаете, что такое "...отон"? Что этот ваш сотрудник, написавший статью и не затруднивший себя даже представить, хладнокровно решил свои проблемы вашим ловким манипулированием?
Поясните, какое отношение ваш пост имеет к содержанию новости
Как только хочется сказать "невыгодный/выгодный", "ценности", "хорошо/плохо" - сразу отвечать на вопрос, кто акторы (чьих точек зрения будет).
Иначе крайне неопределённый разговор
Тема 1: Перепутаны понятия "иррациональное" и "непознанное".
Человек - абсолютно физическое существо. Как изучат, так и будет для нашего понимания 100% предсказуем.
Сейчас неизучен, есть очень грубые модели, поэтому нам человек и кажется иррациональным
Задача БА - выявить цель бизнеса, когда к нему прикатывает "Мы хотим". И только потом работать с требованиями по реальным целям.
Поэтому приведённый пример с БА - это плохой БА.
БА - это не передачтик между бизнесом и командой разработки. Прежде чем выкатывать требования, БА должен прогнать их по критериям. И тогда автоматом не будет этого примера.
Ок, допустим, БА промахнулся с договором через e-mail.
Но дальше, если возможные решения напрямую затрагивают бизнес-процессы, то это уже вне работы СА.
То, что описано в примере, обсуждается на этапе принятия решений по бизнес-процессам (см. выше, это я уже повторяюсь). И в данном случае СА это должен вернуть взад БА, чтоб тот почесал затылок и провернул ещё одну итерацию с бизнесом и командой
Приведите пример пересечения задач СА и БА
Спасибо за краткое изложение, но у меня повились вопросы.
Логичнее располагать вопросы аналтика иерархично. Первым напрашивается "Зачем?"
"Зачем это делать?" для СА - расширить функциональность?
Если у нас есть БА, то не могу представить для СА такой формулировки.
Результат БА - артефакты в виде описанных конкретных целей бизнеса и способа их достижения бизнесом - бизнес-процесс. БА говорит, что делать с бизнес-функциональностью (создать/изменить/убить, не "расширить/уменьшить").
Тогда зачем это делать СА? Чтобы заработать денег - какой вопрос, такой и ответ, потому что вопрос должен указывать на объект, а не на субъект; например, Что должен достичь СА? достичь (описанных БА) конкретных целей системы.
Если мы тут про язык, то в чём смысл выражения?
Это какое-то устойчивое выражение? Не понимаю взаимоотношений бумажек и липового мёда
Апд. Нашёл - ГрОб
Просто скажу - не читайте этот бред. Антинаучно, последующее утверждение противоречит предыдущему и т.п. В топку
Как пример МС - наверное, хорошо. Как описание МС - ужасно
В Firefox - недоступна. И это логично, потому что в оригинале статьи нет такого, перевод неточный. Иметь свой домен и быть доступным по адресу - разная функциональность.
Я, как обыватель, ничего не понял, а что для меня, потребителя, полезного?
Ну, я и так почти 2 года назад понакупал кучу китайских 2ТБ NVMe накопителей для апгрейда всех ноутов в семье. Тут что-то ёмче/круче/дешевле?
И текст какой-то странный:
, а на фото - 2ТБ с таким же названием модели
Вот! ))
Упаси боже, чтоб я кого-то убеждал что-то переделывать в неизвестной мне системе. Это я пытаюсь понять логику и как оно работает через вопросы и некоторые постулаты
Просто я за то, чтобы глагол определял именно то значение, которое он имеет в своём действии. Повторюсь, под "принять" подразумевать "создать" - очень плохая практика.
Ещё раз повторюсь, объект или есть, или его нет. Что такое "безликая сущность с генерализованным названием"? Это или запрос (объект!) на создание объекта-заявки, или сама заявка. Посередине не бывает. В принципе, как в ИС возможно существование "безликой сущности"?
Триггер - это какое-то событие.
Актор - это субъект, что-то выполняющий.
Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано.
Надо отделять артефакты физического мира и артефакты смоделированной ИС.
Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий.
Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС.
Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система
, только хардкор.Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом.
Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)).
Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Опять я несогласный.
Пока не соглашусь, что время - это актор. Это что-то из внематериального и эзотерического. Ну как время (что это за субъект такой - время?!) может на что-то воздействовать? Чем оно воздействует?
Во всех примерах вместо Time очень чётко встаёт конкретная система.
Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б. Можно выделить конкретный модуль/компонент/сервис, если требуется - так будет нагляднее, что внутри объекта "Торговая система" есть актор-модуль, являющийся в данном процессе субъектом
Спасибо за развёрнутый ответ
Не, так не пойдёт )). "Подразумевается", "можно считать, что" и т.п.- страшные вещи!
1. "Принята" - значит, принят, получен объект. Никак не создан.
Создание - это создание объекта, никак не его передача/получение.
Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запрос на создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
Вот именно, я про это.
Задайте вопрос - кто владелец объекта, кто заинтересованные в этом объекте акторы.
К кому будет ходить фронт (пользователь) за статусом заявки? А как информационная система (не бэк) вообще понимает, что происходит с этой заявкой? Где связь заявки с договором?
Если команда отвечает только за один компонент (бэк, обрабатывающий заявку), то, я так считаю, у команды должна быть полная статусная модель объекта, даже если управление объектом отдаётся в другие сервисы, ИС. Хотя бы потому, что полная модель позволяет:
понимать границы ответственности каждого компонента/сервиса за объект;
трассировать входящие, исходящие и внутренние требования по работе с объектом;
заранее понимать возможные требования к обработке объекта - заранее подстелить соломку в нужных местах проектирования логики
А так вы пилите ногу слона и не знаете, или она должна ходить в составе слона, или её на мясо, или её пришьют не к слону, или...
Это продолжение предыдущего, на самом деле.
Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха?
Могу сказать, что это совсем не праздные вопросы. В продукте моего проекта предыдущие команды разработки предусмотрели ответ только принят/не принят на техническом уровне, прямо как тут. И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Вот только начал смотреть и сразу бросилось в глаза:
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку.
В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Я чего так волнуюсь за статью :) - у меня сейчас в работе очень похожая ситуация. Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Логика статьи подхода к проектированию правильная.
Тоже вижу, что фомальное следование нотациям может иметь близкую к нулю ценность.
Например, в качестве промежуточной схемы между вариантами поведения и бизнес-процессами (БП) пару раз омогало сначала накидывать движение управления процессами прямо внутри вариантов поведения, а потом уже, поглядывая на полученного ежа с ужом, спокойно отрисовывать БП
Два раза перечитал и всё никак не мог врубиться, почему команда стала частью схемы. Пока не посмотрел на схему.
Я понимаю, конечно, что на англ. это просто "command". Но надо же учитывать контекст. "Командой" часто называют актора процесса (team).
Было бы чуть лучше сказать "управляющая команда"
Спасибо за ответ. Именно так, можно по-разному выгребать бэклог, но в любом случае это должен быть постоянный рабочий процесс. А не набеги в стиле "ой, мальчики, давайте поиграем стильно-модно-молодёжно (а то у меня скиллов не хватает - сделайте что-нибудь)"
Полностью поддерживаю предыдущих ораторов, вплоть до профпригодности.
После прочтения заголовка
"Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям"
хочется спросить - народ в этой ваше Ламоде, а что вам раньше мешало сделать то же самое, но в нормальном рабочем процессе? И вы вообще понимаете, что такое "...отон"? Что этот ваш сотрудник, написавший статью и не затруднивший себя даже представить, хладнокровно решил свои проблемы вашим ловким манипулированием?