# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ и тест дизайн Тест план Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сумма технологии Экстраполяция в будущее Политэкономия Красивые диаграммы Сознание, интеллект
Ещё на странице:
# Приобщиться к мудрости # Инструменты # Методы анализа и нотации # BPMN # UML # IDEF0
Ещё в разделе:
[ АНАЛИЗ ] [ Стейкхолдеры ] > Нотации [ Vision ] [ Сервисы ]
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Графические нотации
last update: 29-05-2021, 20:27
Приобщиться к мудрости
Инструменты
Методы анализа и нотации
В зависимости от того, какую проблему мы решаем и что конкретно анализируем, определяемся с точкой зрения на систему (Point of View): Для каждой из выбранной точки зрения существуют свои методы анализа и графические нотации для визуализации его результатов. Например:
Потоки работ
(Функциональность)
Нотации моделирования бизнес-процессов:
Связи компонентов
(Архитектура)
Язык описания моделей предметной области:
Активности пользователей
(UX-design)
  • ...
Потоки данных
(Модель данных предметной области)

TBD

BPMN

BPMN (Business Process Model and Notation, нотация и модель бизнес-процессов) = система условных обозначений для моделирования бизнес-процессов.
В BPMN рассматривается функциональная последовательность работ.

Пример BPMN:

Нюансы

  • Создание Бизнес-Процесса -- от общего к частному.
  • Изменение Бизнес-Процесса -- от частного к общему.
  • Когда кто-то кому-то что-то передаёт (н-р, документы), нет смысла обозначать саму передачу отдельной задачей, ибо сама стрелка между задачами как раз и обозначает передачу.
  • Если в текстовом описании БП (н-р, регламенте), которое вы переводите в BPMN, вы видите какие-то сроки
    И при этом с т.зр. БП эти сроки никак не влияют на последовательность действий (за несоблюдение сроков нет никаких санкций)
    , ТО мы сроки на схеме никак не рисуем.
    Т.е. если, например, в регламенте никак не указано, что конкретно должно происходить если мы не успеваем сделать какой-то документ к 20 мая (аннулируем? не аннулируем? исправляем и т.п.), то и отражать это на BPMN никак не нужно.
  • Если в текстовом описании БП, которое вы переводите в BPMN, в одном пункте указано 2+ действий, то очень внимательно отнеситесь к этому, возможно, что на схеме это имеем смысл отразить как отдельные последовательные задачи
  • После того как вы перевели какой-то текстовый регламент в BPMN, вы сделали только первый шаг. Для дальнейшей детализации диаграммы и превращения её в аналитическую, необходимо проводить опрос представителей ролей-участников БП.
    Типичные вопросы это уточняющие и проясняющие исключительные случаи:
    • как именно вы выполняете задачу?
    • что вы делаете, если не можете выполнить эту задачу?
    Потому что в процессе опроса может выяснится, что в выполнении задачи участвуют какие-то другие стороны, дополнительные информационные артефакты и прочее.
    И только после такого уточнения у вас появится возможность понимать где и как можно скорректировать БП.
  • TBD
С чем ознакомиться:
ПО для автоматизация бизнес-процессов в ИТ-системах на основе BPMN:
  • Camunda - BPMS-платформа. (Camunda Modeler, Community Platform - бесплатно. Enterprise Platform - платно).
    Полезные статьи, связанные с этим ПО:
UML

UML (Unified Modeling Language, унифицированный язык моделирования) = язык графического описания для объектного моделирования в области разработки ПО.

Часто встречаемыми (и наиболее полезными, IMHO) видами диаграмм являются:

  • диаграмма вариантов использования (use case diagram)
  • диаграмма последовательности (sequence diagram)

TBD

IDEF0
Эта нотация на практике абсолютно не применима и бесполезна. Не тратьте время. Схема даже всего из 4-х блоков становится нечитабельной.
Даже с археологической точки зрения носит сомнительную ценность.
Ресурсы:

IDEF0 (Icam DEFinition for Function Modeling) = методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.
Традиционно применяется для описания процессов в укрупнённых блоках, с указанием связей между ними.
В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.

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

Например, простая ежедневная операция -- приготовление борща.

Большой прямоугольник посередине -- функциональный блок, его название отображает описываемое действие (функцию).
Слева в функциональный блок входят стрелки входящих данных. Входящими данными для борща являются овощи и мясо.
Сверху в функциональный блок входят стрелки ограничений, или управляющих воздействий. В нашем случае рецепт -- это ограничение (нельзя варить борщ не по рецепту), а мудрые советы веснушчатой Агриппины Саввичны это управляющие воздействия.
Снизу в функциональный блок входят стрелки указания исполнителей.
Справа из функционального блока выходят стрелки исходящий данных (результата). А ожидаем мы получить борщ.

Но указанная выше схема не даёт никакого понятия о том, как же будет происходить процесс варки борща.
Для этого мы должны спуститься вглубь функционального блока и сделать его декомпозицию:

На этой схеме уже видно, что для того чтобы из мяса и овощей получить готовый борщ нужно выполнить определённую последовательность операций. Приготовить бульон, подготовить овощи, собрать всё в одном месте, а потом подать на стол.
Данная диаграмма состоит из тех же элементов, что и главная. Всё так же в каждый функциональный блок входят стрелки входящих данных, выходят стрелки исходящих данных. Снизу -- исполнители, сверху -- ограничения и управляющее воздействие.