При моделировании бизнеса используются различные модели, отображающие следующие компоненты [8]:
- • функции, которые бизнес-система должна выполнять — что она делает, для кого, с какой целью;
- • процессы, обеспечивающие выполнение указанных функций, последовательность отдельных шагов процессов (работ, операций);
- • данные, необходимые при выполнении процессов, и отношения между этими данными;
- • организационные структуры, обеспечивающие выполнение процессов;
- • материальные и информационные потоки, возникающие в ходе выполнения процессов.
Выделяют четыре основные группы методологий моделирования бизнеса (рис. 3.3): структурные, объектно-ориентированные, имитационные, интегрированные.
В основе структурных методов моделирования бизнеса лежит декомпозиция системы на подсистемы, которые, в свою очередь, делятся на более мелкие подсистемы и т. д. Базовыми принципами структурного подхода являются [17]:
3. БИЗНЕС-МОДЕЛИРОВАНИЕ. Классический шаблон бизнес-модели.
- • «разделяй и властвуй» — принцип решения сложных проблем путем их разбиения на множество мелких задач, легких для понимания и решения;
- • иерархическое упорядочивание — принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Рис. 3.3. Классификация методологий моделирования бизнеса
Выделяются две группы структурных методологий: моделирующие функциональную структуру и моделирующие структуру данных. При моделировании бизнеса чаще используются функциональные модели. Главным структурообразующим элементом таких моделей является функция (действие, операция) [18]. Биз-нес-процессы представляются на разных уровнях детальности в виде последовательности функций, с которыми связаны входные и выходные объекты (материальные, информационные) и используемые ресурсы (человеческие, технические).
Наибольшее распространение получили следующие нотации структурного моделирования:
• IDEF0 — функциональные модели, основанные на методе структурного анализа и проектирования SADT (Structured Ana-lysis and Design Technique) Дугласа Росса;
- • IDEF1X — модели данных, основанные на диаграммах «сущность-связь» (ERD. Entity-Relationship Diagrams);
- • IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
- • DFD (Data Flow Diagrams) — диаграммы потоков данных.
Методы объектно-ориентированного моделирования (ООМ) изначально создавались для разработки информационных систем, а именно для формирования моделей систем с целью их последующей реализации в виде объектно-ориентированных программ. Однако в дальнейшем методы ООМ стали применяться нс только и не столько для программирования, сколько для анализа и перепроектирования бизнес-процессов.
Главным структурообразующим элементом в объектно-ориентированном подходе является объект. В программировании объектом называется информационная структура, объединяющая данные (атрибуты) и процедуры. При моделировании бизнеса объектами являются, прежде всего, участники бизнес-процесса (активные объекты) — организационные единицы, конкретные исполнители, информационные системы, а также пассивные объекты — материалы, документы, оборудование, над которыми выполняют действия активные объекты [18]. Таким образом, в объектно-ориентированных методах модель бизнес-процессов строится вокруг участников процессов и их действий.
Разные авторы создавали различные языки объектно-ориентированного моделирования, отличающиеся составом, видом диаграмм, используемыми обозначениями. Наиболее известными к середине 1990-х годов стали: метод Booch’93 Г. Буча, метод ОМТ (Object Modeling Technique) Дж. Румбаха и метод OOSE (Object-Oriented Software Engineering) А. Джекобсона. Авторы этих методов решили объединить свои представления и создать унифицированный метод, что и привело к появлению языка UML. Благодаря поддержке консорциума OMG этот язык стал фактически стандартом в области объектно-ориентированного моделирования.
Имитационное моделирование — это имитация на компьютере (с помощью специальных программ) процесса функционирования реальной системы. Методы имитационного моделиро вания позволяют получить наиболее полную картину состояния процесса в любой момент времени. Они копируют бизнес -процессы путем отображением «живой» картины процесса в режиме сжатого времени. В моделях можно задать временные и вероятностные параметры, например: время поступления заявки в систему, определяемое по некоторому закону распределения; время выполнения той или иной операции обработки заявки и др.
К наиболее распространенным методам имитационного моделирования относятся:
- • сети Петри и модификация этого метода — раскрашенные сети Петри (CPN, Colored Petri Nets);
- • GPSS (General Purpose Simulating System) — унифицированный язык имитационного моделирования;
- • SIMAN (SIMulation ANalysis) — язык визуального моделирования.
Интегрированные методы моделирования объединяют различные виды моделей, отражающие соответственно разнообразные аспекты системы. Так, популярная методология ARIS (Architecture of Integrated Information System) рассматривает деятельность предприятия с различных точек зрения, в частности, она предполагает отражение в единой интегрированной модели организационной структуры, функций, данных и процессов. Для описания различных аспектов бизнеса в ARIS используются множество типов моделей: дерево функций, событийно-ориентированная модель, диаграмма цепочек добавленной стоимости, модели производственного и офисного процессов и т. д.
Ряд интегрированных методологий наряду с методами построения статических и динамических моделей использует методы интеллектуального моделирования (инженерии знаний, экспертных систем). Среди них можно назвать методологию создания динамических интеллектуальных систем G2, методологию управления бизнес-правилами (BRM — Business Rules Management).
Источник: ozlib.com
Еще 2 похожих техники моделирования из BABOK®Guide: ликбез для бизнес-аналитика
Продолжая разбирать техники BABOK®Guide, сегодня рассмотрим, чем моделирование данных отличается от моделирования понятий, в чем разница между концептуальной, логической и физической моделью, а также как все это связано со ER/IDEF1x-схемами и UML-диаграммой классов. Смотрите далее краткий обзор с примерами и рекомендациями по использованию в задачах бизнес-анализа.
Моделирование данных: 3 вида моделей
В отличие от словаря данных, который включает определения, синонимы и возможные значения элементов данных, модель данных не просто описывает сущности, классы или объекты данных предметной области, но и показывает связи между ними. На практике одним из наиболее частых кейсов, когда системный или бизнес-аналитик сталкивается с моделью данных, является описание/проектирование схемы реляционной базы данных или UML-диаграммы классов. Например, при разработке технического задания на информационную систему по шаблонам стандартов спецификации требований к ПО ISO IEEE 29148-2018 и IEEE 830-1998, которые мы разбирали здесь.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
24 июля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Таким образом, элементы словаря данных являются объектами (сущностями, классами) или их атрибутами в модели данных, которая представляет собой графическую диаграмму. Обычно это схема в нотации ERD, IDEF1x, UML-диаграмма классов или объектов. Такая модель используется при выявлении и анализе требований, проектировании решения, т.е. определения дизайна, а также в рамках внедрения и улучшения продукта. Модели данных принято делить по уровню абстракции на следующие категории:
- концептуальная, которая не зависит от проектируемого решения или технологии. Это начальный этап описания ключевых бизнес-сущностей и их взаимосвязей. Концептуальную модель можно представить в виде ER-диаграммы. Хотя, если в классической ER-нотации описать более 10 сущностей, каждая из которых имеет хотя бы пару атрибутов, такая схема уже будет выглядеть очень громоздко. Поэтому даже для разработки концептуальной модели данных сегодня большинство аналитиков используют UML и/или IDEF1x, где классы/сущности могут иметь широкий список атрибутов, однако еще нет необходимости определять ключи, индексы и типы данных.
- логическая – уточненная абстракция концептуальной модели с учетом правил управления целостностью данных и взаимосвязей между ними. Например, при проектировании реляционной базы данных аналитику именно на этом этапе стоит вспомнить о 3-ей нормальной форме или схеме звезды/снежинки, если речь идет о КХД. Таким образом, особенности и ограничения дизайна решения начинают проявляться на этапе разработке логической модели данных. Определенные на концептуальном уровне атрибуты здесь уточняются и дополняются. В частности, для таблиц реляционных баз данных определяются ключевые поля, индексы и типы данных.
- физическая – максимально детализированная версия логической модели, с учетом тонкостей физической организации системы хранения данных: производительность, многопоточность и безопасность.
В реальности системные и бизнес-аналитики чаще всего работают с концептуальными и логическими моделями данных, а физическая лежит в области ответственности ИТ-архитектора или ведущего разработчика. Поскольку цели описанных категорий отличаются, то концептуальная, логическая и физическая модели данных для одной и той же предметной области могут значительно отличаться.
Помимо самих сущностей в реляционной парадигме или классов в объектно-ориентированном подходе, а также их атрибутов, модель данных включает следующие элементы:
- взаимосвязи или зависимости, включая кардинальность – число, обозначающее количество связанных экземпляров;
- метаданные, которые расширяют представленные на диаграмме сведения, например, когда, кем и почему были созданы/изменены элементы схемы, каковы ограничения на их использование, включая ограничения безопасности и доступа.
Иногда этап разработки концептуальной модели пропускается и аналитик сразу переходит к логическому проектированию, создавая IDEF1x-диаграмму для реляционных баз данных или UML-диаграмму классов для объектно-ориентированного ПО. Тщательный анализ логической модели совместно со стейкхолдерами со стороны бизнеса и техническими специалистами из команды реализации поможет убедиться, что логический дизайн корректно отражает бизнес-потребности и ограничения решения. Такой системный подход к анализу и документированию данных с их взаимосвязями достаточно гибкий: можно представить различным стейкхолдерам разный уровень детализации, чтобы выявить несоответствия и/или новые требования.
BABOK рекомендует использовать технику моделирования данных в следующих задачах бизнес-анализа:
- «Проведение выявления» из области знаний «Выявление и сотрудничество»;
- «Спецификация и моделирование требований» из области знаний «Анализ требований и определение дизайна»;
- «Определение архитектуры требований» (область знаний «Анализ требований и определение дизайна»).
Несмотря на схожесть названий в англоязычном варианте, концептуальная модель данных (Conceptual data model) и модель понятий (Concept Modelling) – это разные техники BABOK®Guide. Что именно представляет собой модель понятий, читайте далее.
Моделирование понятий: еще одна техника BABOK®Guide
Если модели данных связаны со словарями данных, то модели понятий немного похожи на другую технику BABOK – глоссарий, который мы также рассматривали здесь. В отличие от концептуальной модели данных, которая описывает ключевые понятия предметной области и взаимосвязи между ними, модель понятий, как и глоссарий, нужна для систематизации бизнес-терминов, чтобы обеспечить согласованное представление знаний о предметной области. Модели данных неотделимы от IT, а модели понятий поддерживают естественный язык и не предназначены для унификации и кодирования данных. Графическое изображение модели понятий может выполняться не только в виде ER-диаграммы, но и как визуальная схема без привязки к какой–либо нотации подобно картам ассоциаций (Mind Map). Несмотря на высокую степень свободы в разработке таких моделей, BABOK рекомендует придерживаться следующих правил:
- называть объекты/сущности существительными;
- связи между сущностями описывать глаголами;
- при необходимости вводить понятия, описывающие отношения категоризации, классификации, «часть-целое», роли.
Таким образом, модель понятий, которая не зависит от особенностей решений, структуры данных и других тонкостей ИТ-домена, позволяет показать стейкхолдерам со стороны бизнеса смысл и отличия базовых концептов предметной области. А благодаря визуальному представлению бизнес-правил на такой модели, аналитик совместно со стейкхолдерами может убедиться, что они являются полными, согласованными и непротиворечивыми.
Однако, разработка комплексной модели понятий требует глубокого понимания бизнес-контекста и может занять много времени. Также эта техника BABOK®Guide требует постоянной поддержки и актуализации используемой терминологии при написании бизнес-правил, требований и другой информации бизнес-анализа. На практике модели понятий пригодятся в следующих случаях:
- проектирование корпоративной базы знаний с целью систематизировать, сохранять, использовать, администрировать и распространять информационные активы предприятия;
- документирование множества бизнес-правил;
- нужно упрощение модели данных для представления стейкхолдерам с недостаточным уровнем технических знаний;
- поиск новых возможностей бизнеса и инновационных решений в его улучшении;
- необходимость соответствия новым требованиям законодательства и/или отраслевым стандартам.
BABOK рекомендует использовать технику моделирования понятий в следующих задачах бизнес-анализа:
- «Проведение выявления» из области знаний «Выявление и сотрудничество»;
- «Анализ текущего состояния» из области знаний «Анализ стратегии»;
- «Спецификация и моделирование требований» из области знаний «Анализ требований и определение дизайна».
Источник: babok-school.ru
