Артефакты бизнес анализа это

Шестой Урок практического курса BPMN посвящён рассмотрению графических элементов спецификации BPMN и их использованию при описании бизнес-процессов: Артефакты, Данные и Ассоциации.

Язык BPMN позволяет разработчикам моделей указывать дополнительную информацию о процессе, не связанную непосредственно с потоками операций или потоками сообщений данного процесса. BPMN предлагает использование элементов нотации – Артефакты, Данные, и соединяющие элементы — Ассоциации. Рассматриваемые в Уроке элементы нотации не являются исполнительными и служат для облегчения читаемости и анализа моделируемых бизнес-процессов.

Артефакты используются для введения дополнительной информации по процессу. Существует два стандартных артефакта: Группа и Текстовая аннотация (в версии 1.2 нотации BPMN Данные входили в Артефакты, в BPMN 2.0 – уже выделены в отдельную категорию элементов). Однако разработчики BPMS систем или инструменты моделирования могут добавить столько Артефактов, сколько требуется.

Артефакты работы бизнес-аналитика

Рассмотрим использование Группы как элемента моделирования процессов. Графическое изображение элемента Группа изображается прямоугольником с закругленными углами, граница которого — штриховая линия с точками. Группа позволяет объединять различные действия, но не влияет на поток управления в диаграмме.

Рис. 25. Графическое изображение Группы

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

Рис. 26. Использование Группы в рамках процесса

Примечание: в приведённом процессе «Оформление документов на нового сотрудника» (Урок 4 Практических курсов BPMN) в Группу соединены задачи по подготовке и подписанию приказа о приёме на работу. Как видно, такое выделение области диаграммы (группировка элементов) носит только смысловую нагрузку (показывая логическую взаимосвязь, не изменяя при этом ход процесса).

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

Это означает, что для объединения элементов диаграммы Группа может простираться за границы пула. В таком качестве Группа используется для отображения действий, являющихся частью масштабных взаимоотношений типа B2B. Текстовая аннотация – второй стандартный Артефакт нотации BPMN — представляет собой механизм, при помощи которого разработчик модели может добавлять на диаграмму дополнительную информацию, являющуюся важной для конечного пользователя диаграммы. Текстовые аннотации используются для уточнения значения элементов диаграммы (добавления комментариев, пояснений и другой текстовой информации) и повышения её информативности и лёгкость для понимания любым бизнес-пользователем.

Наталья Косинова. Пирамида артефактов для ИТ-проекта: анализ и проектирование

Графический элемент Текстовая аннотация представляет собой негерметичный прямоугольник, выполненный одинарной линией.

Рис. 27. Графический элемент Текстовая аннотация

Текстовая Аннотация может быть присоединена к определенному элементу на диаграмме при помощи Ассоциации, однако, он не оказывает влияния на ход Процесса. Текст, ассоциированный с Текстовой аннотацией, располагается в пределах данного графического элемента.

Рис.28. Использование Текстовой аннотации в описании процесса

Примечание: в процессе «Оформление документов на нового сотрудника» Текстовая аннотация позволяет уточнить действия бухгалтера при выполнении задачи «Открыть лицевой счёт сотрудника».

Примените знания нотации BPMN 2.0 на практике
в Low-code BPM-системе ELMA365

Другой элемент нотации BPMN (соединяющий) — Ассоциация — используется для установки соответствия между какой-либо информацией и Артефактом и элементами потока (события, действия, шлюзы). Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока или потоком операции с помощью Ассоциации (см. рис.29).

Графическое изображение Ассоциации представляет собой пунктирную линию.

Рис.29. Графический элемент Ассоциация

При необходимости Ассоциация может указывать направление потока (например, потока Данных). Тогда графический элемент Ассоциации отображается со стрелкой.

Рис.30. Графический элемент направленная Ассоциация

В практике описания бизнес-процессов Ассоциация используется для соединения указанного пользователем текста (Текстовой аннотации), Данных (Объектов данных, Хранилище данных – см. далее) с элементами потока.

Традиционным требованием к моделированию процессов является возможность моделирования компонентов (физических или информационных), которые создаются, управляются и используются в ходе выполнения процесса. Важным аспектом этого требования является возможность сбора введённых данных, а также запроса этих данных и управления ими.

BPMN выделяет несколько элементов, предназначенных для хранения и передачи компонентов в ходе выполнения процесса: Объекты данных и Хранилище данных. Обычно такие элементы относят к «связанным с компонентами».

Графическое представление элемента Объект данных имеет вид листа документа с загнутым углом.

Рис.31. Графическое изображение Объекта данных

Объект данных представляет собой информацию, которая обрабатывается в ходе процесса. Они не влияют непосредственно на последовательный поток или поток сообщений процесса, но обеспечивают информацию о том, какие действия требуют выполнения и/или что они производят. Объект данных привязан к контексту процесса: он изображается внутри процесса или подпроцесса.

Объект данных процесса существует только в интервале времени от момента запуска данного экземпляра процесса до его завершения. При отмене выполнения данного экземпляра процесса все находящиеся в нём экземпляры Объектов данных становятся неактивны. Соответственно, при завершении или отмене выполнения экземпляра процесса, доступ к Объектам данных этого экземпляра процесса из другого внешнего процесса невозможен.

В нотации BPMN 2.0 (в отличие от предыдущей версии нотации) вводится новое понятие Хранилище данных для моделирования постоянной памяти. Данный объект используется процессом для записи и извлечения данных как, например, базы данных. Сохраненная информация будет действительна даже после завершения выполнения экземпляра процесса.

Графический элемент Хранилища данных изображается следующим образом:

Рис. 32. Графический элемент Хранилище данных

Рис.33. Пример использования Ассоциаций в моделировании процессов

Примечание: на рис.34. рассмотрен пример процесса «Поиск кандидатов на вакансию» с использованием элементов нотации Данные и Ассоциации. Данные в рамках процесса показывают, какая информация является результатом исполнения задач (заявка на сотрудника, информация о кандидате) или используется при выполнении задачи (заявка на сотрудника, База данных кандидатов). Заявка на сотрудника и информация о кандидате являются Объектами данных, База данных (БД) кандидатов – Хранилищем данных.

В нотации BPMN элемент Хранилище данных используется для моделирования межпроцессного взаимодействия через данные, что невозможно исполнить с помощью Объектов данных, которые применяются только в рамках одной оркестровки (процесса/подпроцесса).

Рис. 34. Межпроцессное взаимодействие через данные

Более подробно с элементами нотации BPMN Артефакты, Данные и Ассоциации и их использование при описании бизнес-процессов можно ознакомиться в разделах 10.3 «Компоненты и Данные» и 8.3.1 «Артефакты» в нотации BPMN.

Источник: www.elma-bpm.ru

Введение в BPMN

Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) — это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.

Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:

• Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
• Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
• Возможность автоматизировать бизнес-процессы без необходимости программирования;
• Уменьшение разрыва между моделями «Как есть» и «Как должно быть».

Как пользоваться данным руководством

Благодаря большому количеству примеров настоящее руководство по BPMN можно использовать как самоучитель для освоения нотации «с нуля». Для этого рекомендуется читать все главы по порядку с самого начала. Также это руководство подходит в качестве справочника, в котором опытные специалисты могут найти ответ на вопрос, если что-то забыли.

Руководство по BPMN имеет следующие особенности:

• Все содержимое полностью соответствует последней версии спецификации нотации BPMN;
• Статьи сфокусированы на нотации моделирования, без привязки к какому-либо конкретному программному продукту, что дает возможность применять полученные знания в любых программах, которые поддерживают моделирования в BPMN;
• Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;
• Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;
• Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.

Хотите быстро освоить BPMN?
Пройдите обучение в нашем учебном центре!

Источник: www.optimacons.info

3.5. Артефакты процесса управления требованиями.

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

Обычно каждый термин глоссария представляется существительным и его определением. При этом все существительные заносятся в единственном числе: «заказ», «задача», «поставка», а не «заказы», «задачи», «поставки».

Кроме того, участники большинства проектов стремятся разработать специальный язык или систему сокращений. Чаще всего сокращения бывают мнемоническими, например АИС (автоматизированная информационная система), ГОСТ (государственный стандарт), АСУ (автоматизированная система управления) и т.д. Хорошо организованный глоссарий содержит список таких сокращений и их расшифровку, чтобы помочь понять участникам проекта язык прикладной области разработки. В целом, рекомендации по организации глоссария сводятся к следующему:

• необходимо воздерживаться от использования терминов, имеющих различный смысл в различных ситуациях;
• следует позаботиться о том, чтобы включить в глоссарий объяснения всех специфических терминов проекта, аббревиатур и специальных фраз.

Rational Unified Process позволяет рассматривает глоссарий терминов как неформальный словарь данных предметной области. Подробнее о создании и использовании словаря данных можно прочесть в книге Карла Вигерса «Разработка требований к программному обеспечению» [13].

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

Общая идея состоит в следующем. Определение актеров и прецедентов создаваемой системы необходимо начинать с определения производственных исполнителей модели категорий производства. Затем для каждого производственного исполнителя определяются актеры создаваемой информационной системы. После этого для всех производственных прецедентов, в которых участвуют имеющиеся производственные актеры, создаются прецеденты разрабатываемой системы, как показано на рисунке 3.8.

Рисунок 3.8. Определение актеров и прецедентов системы с использованием модели категорий производства.

Если целью проекта является создание системы, которая бы полностью автоматизи­ровала производственные процессы (например, приложения электронной коммерции), то к числу производственных исполнителей актеры системы относиться уже не будут. При создании приложений такого типа приходится сталкиваться с изменением способа ведения дел. Обязанности производственных исполнителей передаются производственным актерам. Пример такой ситуации приведен на рис. 3.9.

Рисунок 3.9. Определение актеров и прецедентов системы при условии изменения способа реализации производственного процесса.

Разработка документа видения предполагает использование данных, хранимых в документе «Запросы заинтересованных сторон». Рассмотрим этот документ подробнее. Этот артефакт содержит «список пожеланий», которые должны использоваться в качестве первичной информации для определения модели прецедентов, прецедентов и дополнительных спецификаций. Хотя подавляющее большинство «пожеланий» обычно выясняется в итерациях стадий «Начало» и «Уточнение», запросы заинтересованных сторон должны собираться в течение всего проекта.

Цель документа «Запросы заинтересованных сторон» состоит в том, чтобы зафиксировать запросы к выполняемому проекту так, как они были первоначально сформулированы. Хотя за создание этого документа отвечает системный аналитик, ему помогают специалист по маркетингу и представители заинтересованных сторон (конечные пользователи, заказчики и т.д.).

Кроме запросов заинтересованных сторон, документ должен содержать ссылки на все внешние источники, налагающие ограничения на создаваемую систему. Примерами таких источников являются:

• Инструкции по работе
• Бизнес-правила
• Законы и другие правовые акты
• Наследуемые системы
• Бизнес-модели
• Любые результаты, полученные в ходе проведения семинаров, посвященных требованиям.

Как и для других артефактов, для «Запросов заинтересованных сторон» Rational Unified Process предлагает ряд вопросов, положительный ответ на которые свидетельствует о высоком качестве артефакта:

Используя в качестве входных данных сведения, содержащиеся в модели прецедентов информационной системы, документах «Запросы заинтересованных сторон» и «Бизнес-правила» системные аналитик имеет возможность приступить к разработке документа видения.

Документ видения (Vision document), называемый в некоторых источниках документом-концепцией [5] сочетает в себе некоторые основные элементы документа маркетинговых требований и документа требований к продукту.

Филипп Крачтен (Philippe Kruchten) как-то сказал: «Если бы мне разрешили разработать только один документ, модель или другой артефакт для поддержки программного проекта, я бы выбрал краткий, хорошо сформулированный документ видения».

Документ-концепция описывает приложение в общих чертах, а также содержит опи­сания целевых рынков, пользователей системы и функций приложения. Сфера действия документа видения распространяется на два верхних уровня пирамиды требований (рис. 3.3), благодаря чему он охватывает как проблему, так и решение. Кроме того, документ видения для программного продукта служит основой для достижения со­гласия между тремя сообществами заинтересованных сторон:

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

Документ видения является мощным средством, так как содержит описание всех существенных аспектов продукта с различных точек зрения в краткой, абстрактной, доступной и управляемой форме.

Структура документа видения имеет следующий вид:

1. Введение.

В данном разделе предлагается общий обзор документа-концепции.

1.1. Назначение документа-концепции.

В данном разделе фиксируются, анализируются и задаются высоко­уровневые потребности пользователей и функции системы.

1.2. Краткое описание продукта.

Формулируется цель создания приложения, и новые функции, предоставляемые системой.

1.3. Ссылки.

Приводится полный список всех документов, упоминаемых в документе видения.

2. Описание пользователей

Кратко представлены общие сведения о пользователях системы. 2.1. Данные о пользователе / рынке

Кратко представлены основные данные о рынке, которые мотивируют решения относительно продукта.

2.2. Типы пользователей.

Кратко описываются будущие пользователи системы.

2.3. Среда пользователя.

2.4. Основные потребности пользователей.

Перечисляются основные проблемы или потребности пользователей.

2.5. Альтернативы и конкуренты.

Выявляются все приемлемые (с точки зрения пользователя) альтернати­вы.

3. Краткое описание продукта

3.1. Общий вид продукта

Предлагается блок-схема продукта или системы и ее интерфейсов с внешней средой.

3.2. Определение позиции продукта на рынке

Предлагается обобщенная краткая характеристика (на самом высоком уровне абстракции) уникальной позиции, которую должен занять продукт на рынке.

3.3. Характеристика возможностей

Перечисляются основные возможности и функции, которые будут предоставлены продуктом.

3.4. Предположения и зависимости

3.5. Затраты и цены

4. Атрибуты функций

Описываются атрибуты функций, которые будут использоваться для оценки, отслеживания, задания приоритетов и управления функциями.

5. Функции продукта

В данном разделе перечисляются функции продукта.

6. Ключевые прецеденты

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

7. Другие требования к продукту

7.1. Применяемые стандарты

Перечисляются все стандарты, которым должен соответствовать продукт.

7.2. Системные требования

Задаются все системные требования, которым должно соответствовать приложение.

7.3. Лицензирование и установка

Описываются все инсталляционные требования, которые оказывают влияние на создание программного кода или вызывают потребность в создании отдельного инсталляционного программного обеспечения.

7.4. Требования к производительности

Этот раздел используется для подробного описания требований к произ­водительности.

8. Требования к документации

Описывается, какую документацию необходимо разработать для успеш­ного развертывания приложения.

8.1. Руководство пользователя

8.2. Интерактивные подсказки

Требования к интерактивным подсказкам, средствам предупреждения и т.п.

8.3. Руководства по инсталляции, конфигурация и файлы «Read Me»

8.4. Маркировка и упаковка

9. Глоссарий

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

Для этого документ видения должен быть как можно более кратким, сжатым и излагать вещи «по существу». При создании первой версии документа это не слож­но, так как все пункты в перечне будут новыми для данного проекта. В последующие версии документа видения повторно записывать информацию, не претерпевшую измене­ний (описание функций, пользователей и рынков) представляется малоэффективным. Для решения данной проблемы предлагается использовать документ изменений видения (Delta Vision Document).

Рассмотрим развитие документа видения на протяжении жизненного цикла нового проекта. Для нового продукта или приложения необходимо разработать практи­чески все пункты документа видения. Если некоторый пункт не рассматривается, необходимо удалить его из оглавления. Обязательными элементами документа, показанными на рис. 3.10 являются следующие:

• общая информация и введение;
• сведения о пользователях системы и описание рынков;
• описание функций, которые предполагается реализовать в версии 1.0;
• прочие требования;
• будущие функции, которые были выявлены, но не вошли в версию 1.0.

Рисунок 3.10. Документ видения системы для версии 1.0.

По мере развития проекта будут выявляться и добавляться новые функции, а функции, выявленные ранее, будут описаны более полно. Таким образом, документ разрастается, и одновременно возрастает его значение для команды.

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

Может оказаться, что некоторые реализованные в версии 1.0 функции не достигают по­ставленной цели (возможно, из-за того, что внешняя среда изменилась за время разработки и функция больше не нужна или должна быть заменена новой, либо из-за того, что она просто не нужна клиентам, хотя они предполагали обратное). В любом случае скорее всего обнаружится, что в следующей версии некоторые функции необходимо удалить. Как отразить эти «антитребования»? В данной ситуации нужно просто использовать документ видения для указания того, что определенная функция должна быть удалена из следующей версии.

В процессе работы документ постоянно растет. Это естественно, так как он определя­ет растущую систему. К сожалению, может случиться, что со временем документ будет все труднее читать и понимать, так как теперь он гораздо объемнее и содержит много информации, которая не претерпела изменений со времени предыдущей реализа­ции. Например, определение позиции продукта и целевые пользователи, скорее всего, остались неизменными, как и 25-50 функций, реализованных в версии 1.0, которые перекочуют в документ видения для версии 2.0.

Поэтому предлагается вести документ изменений видения (Delta Vision Document). В нем отражается только то, что изменилось. Дополнительные сведения, включаемые в документ, напоминают команде концепцию проекта и помогают войти в курс дела ее новым членам.

Таким образом, формируется документ изменений, в котором основное внимание уделяется тому, что нового включено в очередную версию и что отличает ее от предыдущей версии документа видения (рис 3.11.).

Рисунок 3.11. Документ видения системы для версии 1.0.

• Документ видения для версии системы 1.0 является точкой отсчета: здесь представ­лено все, что заинтересованной стороне необходимо знать о проекте.
• Delta Vision 2.0 определяет то, что отличает вторую версию системы от первой.
• Объединение этих документов задает полное определение версии 2.0 системы.

Совместное использование упомянутых документов, несомненно, полезно для новых членов команды. Однако в этом случае приходится читать о функциях системы версии 1.0, которых уже нет в версии 2.0, так как они были позднее удалены, и нужно всегда отслеживать эти изменения при воссозда­нии полного определения.

Если это необходимо, можно достаточно просто соединить содержимое документа видения системы версии 1.0 и изменения видения для системы версии 2.0 в новый документ видения системы версии 2.0, который представляет все­объемлющую и полную картину проекта. В других обстоятельствах может оказаться удобным использовать документ изменения видения только при относительно небольших модификациях (таких, как версии системы 1.1 и 1.2) и начинать все сначала и пересматривать определение продукта в целом для каждой крупной реализации

Крайне редко практикуется документирование полных требований крупномасштабной существующей системы.

Одна из сложнейших проблем при управлении требованиями состоит в применении методов управления требованиями к эволюции существующих IТ-систем. Крайне редко существуют полные и адекватные спецификации требований для миллионов строк кода и сотен человеко-лет трудозатрат, отражением которых являются эти системы. Так­же непрактично останавливаться и повторно документировать прошлое. При этом мож­но упустить время и не выполнить свою задачу, записывая исторические требования то­гда, когда следовало писать код!

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

Источник: studfile.net