Контекстная диаграмма деятельности компании - Контакты компаний и предприятий на Adresa.top

Денис Бесков

Руководитель школы,
основной автор федерального профстандарта системного аналитика,
Certified Professional for Requirements Engineering

Зачем нужна
Как устроена
Как создавать
Как тестировать
Как применять
Происхождение

Зачем нужна контекстная диаграмма?

Обсуждение и визуализация назначения и границ системы

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

Быстрое выявление функциональных системных требований

Второе её назначение — служить источником для быстрой генерации первичного набора системных функциональных требований при необходимости проектирования системы не «сверху-вниз», от бизнес-модели, бизнес-требований, модели деятельности организации, требований заинтересованных лиц, модели использования, как предлагает нам системная инженерия, а «из середины».

Как устроена контекстная диаграмма

Контекстная диаграмма относится к категории диаграмм, описывающих систему на уровне «чёрного ящика» — а именно, только внешние свойства (в данном случае — потоки данных), но не содержание системы.

Контекстная диаграмма содержит 3 основных компонента:

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

Пример контекстной диаграммы для программной системы управления Заказами в ресторане:

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

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

В стандартной форме не принято указывать виды интерфейсов взаимодействия и тем более протоколы, чтобы не усложнять диаграмму и не пытаться принимать вторичные решения, пока не приняты первичные.

Пример контекстной диаграммы для программной системы автоматизации Единого расчётного центра (ЕРЦ) коммунальных услуг:

Как создавать контекстную диаграмму

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

Контекстную диаграмму можно рисовать на маркерной доске, в среде проектирования или в онлайн-инструменте (Google Draw, Draw.io, Miro и т.д.). Мы рекомендуем маркерную доску или онлайн-инструмент с совместным редактированием.

Порядок разработки контекстной диаграммы на рабочем семинаре:

Из числа заинтересованных лиц собирается рабочая группа (обычно от 3 до 5 человек)
Рабочая группа фиксирует в центре диаграммы название конкретной системы
Рабочая группа выдвигает и отображает группы пользователей, которые должны взаимодействовать с системой, обсуждает их перечень, дополняет его
Рабочая группа выдвигает и отображает смежные системы, которые должны взаимодействовать с системой, обсуждает их перечень, дополняет его
Рабочая группа последовательно проходит по каждому элементу окружения и описывает потоки данных, связывающие его с системой
Рабочая группа проводит тестирование контекстной диаграммы, дополняя диаграмму по ходу тестирования

Для экономии времени участников тестирование можно производить 1-2 участниками, однако это ухудшает осведомлённость группы о найденных проблемах, поэтому мы не рекомендуем так делать.

Как тестировать контекстную диаграмму

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

Тестирование контекстной диаграммы с помощью парных соответствий

Контроль соответствия входных и выходных данных системы опирается на принцип (aka «Закон сохранения данных»), что если в систему попадают какие-то данные (входной поток), они должны как-то использоваться для как минимум одного выходного потока.

И наоборот, если есть выходной поток, то система либо должна генерировать эти данные согласно каким-то правилам (например, случайно) или формировать их на основе каких-то других входных данных.

Более формально парные соответствия можно проконтролировать через таблицу, например:

Тестирование контекстной диаграммы с помощью сквозного сценария

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

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

Система загружает реестр пользователей из AD
Администратор настраивает полномочия пользователей
и т.д.

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

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

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

Как применять контекстную
диаграмму после её создания

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

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

Выявление и контроль полноты (функциональных) системных требований

При создании системных требований возникает риск упустить что-то важное или наоборот, избыточно проработать очевидное.

Чтобы не упустить что-то важное среди системных функций, можно применять:

Трассировку системных требований на требования заинтересованных лиц
Модель использования системы (обычно в форме набора сценариев использования, use case’ов)
Контекстную диаграмму системы

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

Наибольшие гарантии даёт применение всех 3-х методов, однако контекстная диаграмма — это самый простой и дешёвый их них, поэтому часто стоит начинать проработку системных требований именно с неё.

Чтобы убедиться в том, что при выявлении первичного набора системных функциональных требований вы не упустили ни один из нарисованных потоков данных, бывает полезно развернуть потоки данных в таблицу, на которую потом страссировать порождённые ей требования:

Если выполнить все рекомендации статьи, то у вас может получиться такая схема трассировок:

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

Откуда взялась контекстная диаграмма
и почему до сих пор актуальна

Похоже что контекстная диаграмма в той или иной форме использовалась человечеством в разное время, однако свою каноническую форму получила у Тома ДеМарко в 70-80-х годах в семействе методологий Structured Analysis and Structured Design как верхний уровень диаграммы потоков данных — DFD (Data Flow Diagram).

При создании нотации и языка UML его авторы не взяли в него контекстную диаграмму, а использовали диаграмму схожего назначения — диаграмму использования (Use Case Diagram, UCD).

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

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

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

Подписаться на новые статьи

Научиться создавать эффективные системные требования

Научиться создавать эффективные системные требования под руководством опытного наставника с использованием контекстных диаграмм, а также ещё 10 других современных аналитических техник, можно на нашем онлайн-курсе «Системный анализ и Разработка требований к ИТ-системам»

Источник

Актуально ли на сегодня моделирование в IDEF0?

Автор сайта Projectimo.ru

Свежие публикации автора:

Содержание

1 Основные понятия и сокращения
2 Функциональный блок
3 Контекстная диаграмма
4 Основные потоки
5 Декомпозиция
6 Выводы об актуальности нотации

Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ «Методология функционального моделирования IDEF0. Руководящий документМетодология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва», но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

Функциональный блок

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

Обязательные элементы функционального блока в IDEF0

Независимо от масштаба действий все функции отображаются единообразно и обязательно содержат 4 ключевых потока, которые жестко закреплены за сторонами функционального блока:

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

Такой подход позволяет немного сэкономить на пояснениях в схемах и добиться однозначности в отображении потоков, что придает стройности всей модели.

Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.

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

Рассмотренная схема является «кирпичиком» подхода IDEF0. Функциональное моделирование предполагает постепенный переход от общего к частному за счет декомпозиции. Декомпозиция – это «углубление» в рассматриваемую функцию, разделение ее на более мелкие функции. При этом, когда функция верхнего уровня представлена обобщенно и после декомпозирована, ее уместно уже назвать процессом.

Контекстная диаграмма

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

Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

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

Пример контекстной диаграммы
(нажмите для увеличения)

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

Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:

законы и нормы;
приказы, распоряжения;
инструкции и регламенты;
планы;
конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

Декомпозиция

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

Первый шаг декомпозиции
(нажмите для увеличения)

И вот здесь уже начинается собственно функциональное моделирование – мы должны понять, какой набор действий может связать эти потоки и обеспечить выполнение всех требований. Сложность состоит в том, что действий в компании очень много, а на схеме мы имеем право отобразить не более 9 функций, иначе схема станет нечитабельной и соответственно бесполезной.

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

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

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

Первый уровень декомпозиции
(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

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

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

конкретизации событий запуска и остановки процесса;
условий перехода от одних действий к другим;
возможности наглядно отобразить все ресурсы и исполнителей без перегрузки схемы стрелками.

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

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

Источник

Время на прочтение
8 мин

Количество просмотров 44K

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

Задача архитектора решений ― четко донести проект системы до бизнеса, руководителей проектов и разработчиков. Нельзя просто нарисовать одно изображение, это невозможно и не принесет никому пользы. Вместо этого лучше сгруппировать различные проблемы и создать набор диаграмм, описывающих каждое представление. Конечно, есть миллиард способов сделать это. Как выбрать подходящий? За время работы в качестве архитектора решений я чаще всего использовал 5 диаграмм: контекстную диаграмму C4, диаграмму контейнеров, развертывания, последовательности и вариантов использования. В этой статье я рассмотрю подробно каждую из них.

Контекстная диаграмма

Веб-сайт, посвященный модели С4 (Context, Container, Component and Code), довольно хорошо объясняет свои диаграммы, я же поделюсь своим представлением, как эта модель работает.

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

Пример

Context diagram

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

Как рисовать

Определите пользователей.
Определите внешние системы.
Создайте единый прямоугольник, изображающий вашу систему.
Добавьте связи между системой, пользователями и внешними системами.
Напишите содержательные комментарии по каждому компоненту.

Инструменты

Существуют различные инструменты, которые можно использовать для создания контекстной диаграммы. Существуют трафареты C4 для OmniGraffle, примеры C4 для LucidChart, шаблоны есть также в draw.io. Чтобы использовать диаграммы как код, попробуйте PlantUML.

Допустим, мы хотим нарисовать такую диаграмму для цифровой платформы необанковского обслуживания с помощью uml:

@startuml
!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/master/C4_Context.puml
' uncomment the following line and comment the first to use locally
' !include C4_Context.puml


Person(customer, "Customer", "A bank client")
System(abc_system, "Digital Platform", "Allows freelancers and business owners see their transactions.")

System_Ext(idnow, "IDNow", "System for KYC and Qualified Eletronic Signatures")
System_Ext(pay, "Google Pay/Apple Pay", "Google Pay and Apple Pay systems")
System_Ext(dms, "DMS", "Document Management System")
System_Ext(crm, "CRM", "CRM")
System_Ext(current, "Existing Banking System", "Banking Backoffice")

Rel(abc_system, pay, "uses")
Rel(customer, abc_system, "Uses")


Rel_L(abc_system, idnow, "integrates")
Rel_Neighbor(abc_system, dms, "uploads files")
Rel_D(abc_system, crm, "integrates")
Rel_U(abc_system, current, "uses")

@enduml

Мы определяем человека, систему, внешние системы и отношения между ними. Предикаты Person, System и System_ext имеют 3 параметра: ключ, заголовок и описание. Предикат Rel также имеет 3 параметра, но они разные: ключ одной сущности, ключ другой и тип отношений между сущностями.

Нарисовать контекстную диаграмму можно любым удобным инструментом. Здесь можно найти несколько отличных примеров.

Важно

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

Я боролся с контекстной диаграммой для одной банковской системы. Она должна была включать только недавно созданную систему и одного клиента, который не принесет никакой ценности. После согласования я добавил API Gateway и существующий Auth Provider, который мы собирались использовать. Таким образом, контекстная диаграмма стала обретать смысл и позволяла опустить эти элементы из диаграмм нижнего уровня.

Алексей, архитектор решений

У нас в разработке была образовательная система. На момент выпуска Alpha мы поняли, что аналитическая система не получает данные от клиентского приложения. Если бы у нас была контекстная диаграмма, мы бы не сделали такой ошибки. К счастью, это было легко исправить.

Джон, архитектор решений.

Резюме

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

Диаграмма контейнеров

Контейнеры здесь не означают обязательно докер-контейнеры. Контейнер — это любой развертываемый объект или хранилище данных с точки зрения C4. Это может быть мобильное приложение, веб-сайт, виртуальная машина, докер-контейнер, база данных или хранилище объектов; все, что вы можете развернуть. По моему опыту эта диаграмма – самая сложная, а потому привлекает к себе особое внимание. Это, можно сказать, главная диаграмма, над которой нужно работать!

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

Пример

Container diagram

Как рисовать

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

Инструменты

То же, что и для контекстной диаграммы: Draw.io, OmniGraffle, LucidChart и другие.

Важно

Обратите внимание, что элементы расположены столбцами. Первый столбец — это просто API-шлюз, второй ― первая группа сервисов, затем вторая группа сервисов, затем несколько хранилищ. Таким образом вы продемонстрируете многоуровневую архитектуру, которая поможет понять границы и обязанности.
Когда количество микросервисов превысит однозначное число, ваши линии соединения начнут пересекаться. В академических книгах говорится, что для удобочитаемости нужно избегать пересечений. К сожалению, это не всегда возможно. Но не расстраивайтесь, диаграмму можно сделать удобочитаемой, используя разные цвета или ширину линий или разные стили линий (пунктирные, сплошные и т. д.).
Если вы используете специальный инструмент, (как я), вам необходимо включить блок легенды. Сами по себе стрелки и цвет непонятны — легенда объясняет всё это.
Очень распространенный вопрос, когда используешь облака, включать ли вы управляемые сервисы, такие как очереди сообщений? Я обычно отвечаю: «Нет». Это усложняет диаграмму, делает её нечитабельной. Если некоторые сервисы обмениваются данными через очередь сообщений, отобразите её с помощью стрелки отдельного типа.

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

Илья, архитектор предприятия.

Резюме

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

Диаграмма последовательностей

Первые две диаграммы показывают, как элементы системы соотносятся друг с другом. Однако они не могут продемонстрировать, что происходит внутри системы. Например, пользователь регистрируется в вашей системе. Какие компоненты задействованы? Какие действия срабатывают? Как компоненты взаимодействуют друг с другом? Диаграмма последовательностей может ответить на эти вопросы.

Пример

Вверху мы видим взаимодействующие объекты: люди, веб-приложения и мобильные приложения, внешние системы, сервисы и хранилища данных. У каждого объекта есть вертикальная линия внизу. Взаимодействие между сервисами обозначено горизонтальными стрелками между вертикальными линиями. Эти стрелки могут быть разных типов в зависимости от того, синхронная это операция или асинхронная. Серые прямоугольники показывают, что процесс занимает некоторое время, и длина должна указывать на продолжительность: чем длиннее прямоугольник, тем больше время.

Как рисовать

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

Инструменты

К сожалению, OmniGraffle не подходит для диаграмм последовательности. Поэтому для создания этой диаграммы я использую draw.io и LucidChart. Последний вариант является хорош тем, что вы можете рисовать диаграмму вручную или использовать диаграмму последовательности UML.

Важно

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

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

Владимир, Архитектор решений

Резюме

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

Диаграмма развертывания

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

Есть несколько разных вещей, которые необходимо отобразить.

Вычислительные ресурсы. Это могут быть виртуальные машины, докеры, кластеры Kubernetes и облачные функции. Мобильные устройства и настольные компьютеры также можно рассматривать как вычислительные ресурсы.
Хранилища. Постоянные хранилища данных, такие как реляционные базы данных и базы данных nosql, хранилища двоичных файлов, таких как изображения, музыка и видео, хранилища больших данных и так далее.
Ресурсы обмена сообщениями. Установки Kafka / RabbitMQ, Google Cloud pub / sub, AWS SQS и другие.
Сети. Ваши компьютеры используют сети для связи друг с другом. Должны отображаться как физические, так и виртуальные сети.
Зоны доступности. Вы можете думать о них как о центрах обработки данных.
Узлы инфраструктуры. DNS-серверы, балансировщики нагрузки, брандмауэры, сети CDN

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

Как нарисовать

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

Пример

В C4 нотации есть дополнительная диаграмма развертывания:

Обратите внимание на имена вычислительных ресурсов, их типы и номера узлов.

Другой пример для облака AWS:

Distributed Load Testing by AWS

Инструменты

Существует множество инструментов для создания схемы развертывания. OmniGraffle, LucidChart, Draw.io и другие прекрасно справляются с этой задачей, если установлены соответствующие шаблоны.

Важно

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

Резюме

Диаграмма развертывания дополняет понимание системы с точки зрения внешнего вида.

Диаграмма вариантов использования

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

Как рисовать

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

Примеры

Инструменты

Архитектор может нарисовать диаграмму с помощью любого графического редактора и того же набора инструментов, что и для других диаграмм. Omnigraffle, LucidChart, Draw.io работают хорошо. Помните, что эта диаграмма является структурированной, поэтому вы можете использовать UML для её создания. В этом помогает PlantUml или LucidChart.

Резюме

Используйте контекстную диаграмму, чтобы отобразить представление системы на самом высоком уровне.
Документируйте варианты использования с соответствующей диаграммой.
Масштабируйте внутренние компоненты системы с помощью контейнеров и диаграмм развертывания.
Документируйте конкретные бизнес-кейсы с помощью диаграмм последовательности.

Источник

Контекстная
диаграмма
– это модель, представляющая систему
как набор иерархических действий, в
которой каждое действие преобразует
некоторый объект или набор объектов.
Высшее действие иерархии называется
действием контекста – это самый высокий
уровень, который непосредственно
описывает систему. Уровни ниже называются
порожденными декомпозициями и представляют
подпроцессы родительского действия.

При
создании модели сначала необходимо
изобразить самый высокий уровень –
действие контекста. Наименование
действия описывает систему
непосредственно и, как правило, состоит
из одного активного глагола в сочетании
с обобщающим существительным, которое
разъясняет цель деятельности с точки
зрения самого общего взгляда на систему,
в наше случае это процесс «сборки и
ремонта компьютеров». (рис.3). Контекстная
диаграмма изображает
деятельность самого верхнего уровня и
обозначает границу моделирования
относительно цели, возможностей и
точки зрения. На
контекстной диаграмме специфицируемая
система представляется в виде одного
единственного процесса, связанного с
внешними сущностями потоками данных.
Контекстная диаграмма представляет
требования к системе на самом верхнем
уровне – уровне взаимодействия с
окружением.

На
нашей контекстной диаграмме изображен
процесс «Сборки и ремонта компьютеров»
(рис.3) его входные и выходные данные, а
также механизмы и управление.

Входное
«Заказы клиентов»;
Входное
«Ввод комплектующих»;
Входное
«Расценки»;
Управление
«Устав предприятия»;
Управление
«Законодательство РФ»;
Механизм
«Персонал»;
Механизм
«Клиент»;
Выходные
«Готовая продукция»;
Выходные
«Отчеты»;
Выходные
«Документы».

Рисунок
3 – Контекстная диаграмма процесса
«Сборки и ремонта компьютеров»

Декомпозиция
используется при моделировании
информационных систем для разделения
функций на составляющие части. Диаграммы
декомпозиции предназначены для
детализации функций и получаются при
разбиении контекстной диаграммы на
крупные подсистемы (функциональная
декомпозиция) и описывающие каждый
подсистему и их взаимодействие.
Единственная функция,
представленная на контекстной диаграмме
верхнего уровня, может быть разложена
на основные подфункции посредством
создания дочерней диаграммы. В свою
очередь, каждая из этих подфункций может
быть разложена на составные части
посредством создания дочерней диаграммы
следующего, более низкого уровня, на
которой некоторые или все функции также
могут быть разложены на составные части.
Каждая дочерняя диаграмма содержит
дочерние блоки и стрелки, обеспечивающие
дополнительную детализацию родительского
блока. В связи с этим, нами было произведена
декомпозиция контекстной диаграммы A0
процесса «сборки и ремонта компьютера»
на 4 функциональных блока (рис.4):

Принятие
заказа (входящие «заказы клиентов»,
выходящие «Информация по заказу»,
управление «устав предприятия»,
механизмы «Клиент» и «Персонал»);
Обработка
заказа (входящие «Информация по заказу»,
«Ввод комплектующих» и «Расценки»,
выходящий «Заказ», управление «устав
предприятия», механизм «Персонал»);
Сборка
и тестирование (входящий «Заказ»,
выходящий «Данные о готовой продукции»,
механизм «Персонал»);
Оформление
сдачи заказа (входящее «Данные о готовой
продукции», выходящие «Документ»,
«Готовая продукция» и «Отчеты»,
управление «Устав предприятия» и
«Законодательство РФ»).

Рисунок
4 – Диаграмма декомпозиции процесса
«сборки и ремонта компьютеров»

Далее
представлен процесс создания конфигурации
на базе 1С Предприятие для организации
занимающейся сборкой и ремонтом
компьютеров.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Знакомство с контекстной диаграммой и отличным программным обеспечением для простого создания

Если вы планируете строить свой бизнес, важно планировать заранее. Мы должны учитывать все факторы и детали, которые могут помочь нашему бизнесу и негативно повлиять на него. В соответствии с этим а контекстная диаграмма это отличный план, чтобы сделать, прежде чем положить бизнес. Этот план поможет нам увидеть риски, с которыми мы можем столкнуться в процессе. Таким образом, эта диаграмма поможет предотвратить эти риски с нашим проектом. Поэтому мы узнаем определение этой диаграммы и то, как мы можем ее составить. Мы также встретим отличное программное обеспечение, которое может мгновенно помочь нам сделать процесс.

Часть 1. Что такое контекстная диаграмма
Часть 2. Типы контекстных диаграмм
Часть 3. Плюсы и минусы контекстной диаграммы
Часть 4. Как сделать контекстную диаграмму
Часть 5. Часто задаваемые вопросы о контекстной диаграмме

Часть 1. Что такое контекстная диаграмма

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

Часть 2. Типы контекстных диаграмм

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

Тип I: Контекстная диаграмма системы бронирования отелей

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

Тип II: контекстная диаграмма электронной коммерции

Во времена глобализации электронная коммерция быстро растет. Таким образом, контекстная диаграмма электронной коммерции является важным способом оказания помощи всем внешним и внутренним компонентам наших клиентов. Эти компоненты включают персонал клиента, управление и систему оплаты. Кроме того, основная цель диаграммы — обеспечить гармонию между сторонами с точки зрения определения масштабов бизнеса и проектов из другой иерархии.

Тип III: Контекстная диаграмма системы банкомата

Третий тип отображает контекст внутри нашего банкомата. Эта диаграмма необходима для представления оборудования, которое взаимодействует с клиентом. Кроме того, на этой диаграмме показан поток информации между программными и аппаратными компонентами. Вот некоторые из них: данные команды, информация об учетной записи, информация об отображении и многое другое.

Часть 3. Плюсы и минусы контекстной диаграммы

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

ПЛЮСЫ

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

МИНУСЫ

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

Часть 4. Как сделать контекстную диаграмму

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

Доступ к MindOnMap на его официальном сайте. Пожалуйста, нажмите на Создайте свою ментальную карту кнопку в центральной части сайта.

В главном интерфейсе редактирования перейдите к Новый части, и вы увидите различные темы и стили для вашей карты ума. В этом варианте, пожалуйста, выберите MindMap функция в правом углу веб-страницы.

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

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

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

Вы также можете добавить Sub Узлы для получения более подробной информации в вашей контекстной карте. Нажмите на Узел и нажмите Подузлы от верхней части добавить.

На седьмом шаге мы улучшим нашу карту, изменив тема карты, Цвет, а также Стиль карты. Найдите значок функции в правом углу веб-страницы.

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

Это наиболее полные и подробные шаги, которым мы можем следовать, чтобы создать вашу контекстную карту эффективно и профессионально. Мы видим, как MindOnMap облегчает нам это.

Часть 5. Часто задаваемые вопросы о контекстной диаграмме

В чем сходство контекстной карты и диаграммы потока данных?

Как мы все знаем, контекстная диаграмма — это высокоуровневая диаграмма потока данных. Он также известен как уровень 0. Контекстная диаграмма — это своего рода блок-схема данных, которая содержит ту же информацию и имеет ту же цель.

Какой автономный инструмент можно использовать для создания контекстной карты?

Подобно онлайн-инструменту, у нас также есть автономное программное обеспечение, которое мы можем использовать для простого создания контекстной карты. Мы можем использовать PowerPoint и Word Microsoft для мгновенного запуска. Все мы знаем, что это программное обеспечение предлагает функцию SmartArt, которая позволяет нам легко вставлять диаграммы, такие как контекстная карта.

В чем разница между контекстной диаграммой и диаграммой прецедентов?

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

Вывод

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

Источник

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

Фото с сайта foto.basov.com.ua

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

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

Составление контекстной диаграммы

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

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

Рисунок 1. Контекстная диаграмма

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

Итак, суть процесса состоит в следующем:

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

Декомпозиция работ и создание стрелок

Для составления нотации IDEF0 используется два типа объектов: работы и стрелки.

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

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

По сути уже рассмотренная контекстная диаграмма (рисунок 1) является описанием одной работы самого верхнего уровня. Например, «Доставлять товар» является процессом верхнего уровня для таких процессов как «Следовать к месту разгрузки», «Отгружать товар», «Подписывать и оформлять накладные документы» и т.д. Таким образом, процесс верхнего уровня состоит из процессов более низкого уровня.

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

Родственные работы также могут быть детализированы. Схема, на которой отображены декомпозированные работы, называют диаграммой декомпозиции.

Рисунок 2. Диаграмма декомпозиции верхнего уровня

На диаграмме декомпозиции может быть размещено от 2 до 8 работ, но рекомендуется размещать от 3 до 6.

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

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

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

Еще существует пять типов стрелок:

1. Вход (input) – материал и/или информация, которые используются работой для производства продукта (выхода). Допускается, что работа может не иметь ни одного входа. Стрелка входа рисуется, как входящая в левую грань прямоугольника, обозначающего работу. К примеру, на рисунке 2 к таким стрелкам относятся:

«Товар на складе» – относится к работе «Комплектовать товар». Это материальный ресурс, который в ходе выполнения работы преобразуется в продукт «Собранный товар».
«Заявки от клиентов» – относится к работе «Принимать и обрабатывать доставки». Информационный ресурс, который используется в ходе данной работы для формирования планов по доставке и комплектации заказа. В реальности для формирования планов еще необходимая информация о свободных мощностях склада и службы доставки (далее на схеме СД). Но чтобы не перегружать схему, будем условно считать, что эта информация присутствует в вашей реальной практике.
«Отчет о комплектовании» – относится к работе «Доставлять товар». Это информация, которая поступает от работы по комплектации товара к работе по его доставке, чтобы просигнализировать, что товар собран и можно подавать автомобиль на его загрузку.

2. Управление (control) – различная управляющая информация постоянного или оперативного характера (регламенты, стандарты, чертежи, планы, приказы и т.д.).

Каждая работа должна иметь хотя бы одну управляющую стрелку. Они должны располагаться вверху прямоугольника. Если посмотреть на рисунок 2, то можно заметить, что «План доставок» на рисунке обозначен как стрелка, относящаяся к типу «вход», на самом деле она должна являться стрелкой управления и должна находится, соответственно, вверху прямоугольника. То же самое относится и к стрелке «План комплектования».

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

В дальнейшем мы еще вернемся к рисунку 2 и дополним его.

3. Выход (output) – материал или информация, которая производятся работой. Каждая работа должна иметь хотя бы один выход. Он рисуется как выходящая стрелка из правого ребра прямоугольника. На рисунке 2 выходами являются, например, «Собранный товар» – относится к работе «Комплектовать товар».

4. Механизм (mechanism) – это ресурсы, которые используются в ходе выполнения работы. Это могут быть станки, персонал, программное обеспечение, автомобили и т.д. Данный тип стрелок входит в прямоугольник снизу. По вашему усмотрению, эти стрелки могут и не отображаться на схеме.

В нашем примере на рисунке к механизмам относятся: персонал, складская техника, складской комплекс, транспорт.

5. Вызов (call) – стрелка, указывающая на другой (альтернативный) вариант выполнения работы. Рисуется как исходящая из нижней грани прямоугольника. Используется для указания того, что некоторая работа выполняется за пределами описываемой системы. В некоторых программных средствах стрелки вызова используются для слияния и разделения различных моделей.

На рисунке 3 стрелка вызова «Передача доставки на аутсорсинг» обозначает, что при определенном сценарии развития событий доставка будет выполнять силами внешнего исполнителя, в соответствии с другой моделью выполнения работ.

Рисунок 3. Пример стрелки типа «Вызов»

Продолжение следует.

Источник

IDEF0 (Integrated Definition) — язык проектирования функциональных моделей, включает как сам язык моделирования, так и методологию для построения и интерпретации моделей. IDEF0 является одной из первых нотаций для моделирования бизнес-процессов, которая возникла в американской аэрокосмической промышленности в 1970-ых годах.

IDEF0 — основные характеристики

IDEF0 задумывался как способ отобразить процессы, процедуры и действия внутри организации. Как и большинство методов моделирования, главным элементом нотации является графический язык, созданный для передачи определенной информации. Нотация помогает понимать и анализировать процессы, определяет логику изменений, позволяет уточнить требования к проекту, а также поддерживает проектирование на уровне систем и задач по интеграции.

Модель процесса в диаграмме IDF0

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

Основной принцип моделирования в нотации IDEF0 указывает, что между функциями, которые входят в различные подсистемы, должно быть как можно меньшей связей. На одном уровне должно быть не меньше 5 и не больше 3 функций.

Диаграммы IDEF0 читают сверху вниз и слева направо. Все базовые элементы основаны на простых символах:

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

Синтаксическая модель IDF0

Семантика языка описывает именно функции системы — что должно быть сделано для преобразования входящего потока, поэтому названия в прямоугольниках должны быть заданы глаголом или отглагольным существительным. Каждая сторона прямоугольника имеет свое значение и однозначно связана с одним из 4 видов стрелок:

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

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

Другие правила синтаксиса

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

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

Виды диаграмм

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

Пример диаграммы верхнего уровня A0 в нотации IDF0

Иерархия типов функций

деятельность — совокупность всех процессов организации;
бизнес-процесс — совокупность логически связанных операций;
операция — совокупность последовательных или параллельных действий внутри определенного потока;
действие— преобразование свойств какого-либо объекта.

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

Основные характеристики IDF0

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

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

Для чего используется

Нотация универсальна и позволяет детально описывать достаточно сложные системы и процессы на любом уровне.

широко применяется в США при автоматизации машинного производства и до сих пор является частью стандарта FIPS (Federal Information Processing Standard);
применяется для имплементации методологий непрерывного улучшения, таких как Strategic Justification of Integrated Enterprise Technologies (SJET) и Perform Continuous Enterprise Improvement (PCEI);
в литературе можно найти пример описания процесса разработки стратегии на языке IDEF0.

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

Преимущества

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

Недостатки

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

В целом можно сказать, что в области проектирования бизнес-процессов в информационных системах на смену IDEF0 пришли другие нотации, прежде всего BPMN.

BPMN vs IDEF0

Хотя IDEF0 иногда используют для моделирования бизнес-процессов, эта нотация задумывалась как средство моделирования взаимодействия бизнес-функций, не обязательно в процессном контексте. Стрелка в BPMN показывает точную последовательность выполнения шагов процесса, а в IDEF0 стрелки входов-выходов не обязаны отображать эту последовательность. Кроме того, BPMN содержит XML-описание элементов, что значительно упрощает имплементацию на программном уровне. В отличие от IDEF0, BPMN разрабатывалась с прицелом на автоматизацию бизнес-процессов, поэтому многие элементы нотации показывают именно машинные способы передачи и обработки данных. Нотация нашла широкое применение в BPMS, ERP, CRM, SRM и других информационных системах.

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

Верхнеуровневая диаграмма в Comindware Business Application Platform

Comindware Business Application Platform исправляет этот недостаток BPMN за счет конструктора для проектирования исполняемой архитектуры предприятия. Конструктор визуализирует связи между бизнес-процессами, ресурсами и способностями предприятия, не уступая по точности IDEF0. Инструмент можно использовать для создания иерархических моделей с несколькими уровнями вложений.

Ознакомьтесь с возможностями по построению процессной архитектуры в Comindware Business Application Platform

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Источник

Денис Бесков

Актуально ли на сегодня моделирование в IDEF0?

Основные понятия и сокращения

Функциональный блок

Контекстная диаграмма

Основные потоки

Декомпозиция

Выводы об актуальности нотации

Контекстная диаграмма

Пример

Как рисовать

Инструменты

Важно

Резюме

Диаграмма контейнеров

Пример

Как рисовать

Инструменты

Важно

Резюме

Диаграмма последовательностей

Пример

Как рисовать

Инструменты

Важно

Резюме

Диаграмма развертывания

Как нарисовать

Пример

Инструменты

Важно

Резюме

Диаграмма вариантов использования

Как рисовать

Примеры

Инструменты

Резюме

Знакомство с контекстной диаграммой и отличным программным обеспечением для простого создания

Часть 1. Что такое контекстная диаграмма

Часть 2. Типы контекстных диаграмм

Тип I: Контекстная диаграмма системы бронирования отелей

Тип II: контекстная диаграмма электронной коммерции

Тип III: Контекстная диаграмма системы банкомата

Часть 3. Плюсы и минусы контекстной диаграммы

Часть 4. Как сделать контекстную диаграмму

Часть 5. Часто задаваемые вопросы о контекстной диаграмме

Вывод

Составление контекстной диаграммы

Декомпозиция работ и создание стрелок

IDEF0 — основные характеристики

Другие правила синтаксиса

Виды диаграмм

Иерархия типов функций

Основные характеристики IDF0

Для чего используется

Преимущества

Недостатки

BPMN vs IDEF0

Другие крутые статьи на нашем сайте: