18.1.8. Состав используемой нормативно-технической документации

При разработке автоматизированной системы и создании проектно-эксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов:

• ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

• ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;

• РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

31.Методы системной диагностики организаций. Цель проведения стратегического ИТ-аудита. Задачи стратегического ИТ-аудита.

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

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

В конечном счете стратегический ИТ – аудит  нацелен на:

1. получение адекватной картины текущего состояния ИТ;

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

Стратегический ИТ-аудит  закладывает основу для:

1. повышения показателей отдачи от инвестиций (ROI) в информационные технологии;

2. снижения совокупной стоимости владения (TCO) средствами ИТ;

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

4. сокращения сроков внедрения новых средств ИТ, получение быстрых и распространяемых результатов.

32.Методы и приемы проведения стратегического ИТ-аудита организации. Анкетирование. Интервьюирование. Сбор документов. Структура отчета.

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

Во время обследования должны быть собраны следующие материалы:

1. стратегические цели и перспективы развития;

2. данные по организационно-штатной структуре организации;

3. информация о принятых технологиях деятельности;

4. результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

5. предложения сотрудников по усовершенствованию деятельности;

6. нормативно-справочная документация;

7. данные по имеющимся в организации средствам и системам автоматизации.

Во время обследования должны быть проведены:

1. анкетирование

2. сбор документов

3. интервьюирование.

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

Примерный вариант анкеты приведен ниже:

• ФИО руководителя подразделения, телефон

• Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться)

• Каковы (с позиций Вашего подразделения) должны быть цели внедрения ИТ

• Основные функции подразделения

• Какая информация поступает из других подразделений (заявки, запросы, отчеты и т.п.)

• Какая информация передается в другие подразделения

• Какая информация формируется ("рождается") в подразделении

• С какими внешними организациями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается

• Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журнал, картотека и т.п.)

• Время хранения информации

• Штатная структура и квалификация кадров

• Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.)

• Используемые программные продукты

• Подпись

• Приложение 1: Положение о подразделении

• Приложение 2: Набор шаблонов и форм основных документов, используемых подразделением

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

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

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

33.Выбор стратегии автоматизации деятельности.Управление процессом автоматизации. Планирование процесса автоматизации . Методы и средства проектирования автоматизированной ИС предприятия (реорганизация деятельности предприятия). Подходы к созданию автоматизированных ИС. Моделирование информационных систем на базе стандартов ERP и ИСО 9001:2000 356.

Главная цель создания ИС – обеспечить руководство предприятия информацией для принятия обоснованных управленческих решенийПодходы к автоматизации:  Хаотичная автоматизация - Автоматизация не связанных между собой операций, выполняемых как одним, так и не сколькими сотрудниками, что приводит к наличию неавтоматизированных участков процессов  Автоматизация по участкам - Процесс автоматизации отдельных производственных или управленческих подразделений предприятия, объединенных по функциональному признаку Автоматизация по направлениям - Автоматизация отдельных направлений деятельности предприятия. Обязательное участие всех организационных звеньев, связанных с автоматизируемым направлением)  Полная автоматизация управления предприятием -Автоматизация всех ключевых бизнес-процессов, которые могут быть интегрированы между собой двумя способами: - Полная автоматизация с внутренней интеграцией(работа отдельных ИС на предприятии, на основе единой базы данных) - Полная автоматизация с внешней интеграцией(применение отдельных ИС, между которыми налаживаются процедуры регламенты передачи данных)АИС состоит из большого кол-ва элементов: подсистем, модулей, блоков, задач, процедур, функций, операций и т.п. Интеграция предполагает такое объединение и согласование функций и процедур, чтобы в ходе процесса функционирования предприятия обеспечивалась оптимизация его поведения, она должна применятся во всех подсистемах. При проектировании и эксплуатации системы вопросам интеграции должно уделяться первостепенное внимание, так как разрывы интеграционных связей, выпадение необходимых функциональностей снижают эффективность деятельности предприятия.Особенности комплексного подхода к автоматизации деятельности предприятия:  Повышенная экономическая эффективность этого подхода по сравнению с другими  Чрезвычайно высокие требования к качеству управления процессом внедрения системыФормирование и развитие на предприятия ИС, всегда требуют долгосрочного планирования, ориентированного на стратегические цели в области организации, развития и использования ИС, т.е стратегического планирование ИСПроцесс автоматизации состоит из следующих этапов:  Планирования  Контроля исполнения плана  Регулирования – анализа результатов и принятия решений Существуют два типа планов автоматизации предприятия:  Стратегический план(за редким исключением не содержит конкретного плана работ)  Оперативный план(содержит план конкретных работ по реализации принятых стратегических решений. Он включает в себя события, которые должны произойти, носит календарный характер и сопровождается сметой расходовКонтроль исполнения планов подразумевает наличие периодического сбора, информации, её обобщение и представление оперативной информации лицам, принимающим решения. Анализ результатов и принятие решений подразумевает наличие процедуры анализа результатов, опираясь на который производится ревизия плана или внесение изменений в ход процесса.Стратегический план(стратегия автоматизации) включает в себя следующие компоненты:  Цели: области деятельности предприятия и последовательность в которой они будут автоматизированы  Способ автоматизации: по участкам, направлениям, комплексная автоматизация  Долгосрочная техническая политика – комплекс внутренних стандартов, поддерживаемых на предприятии  Ограничения: финансовые, временные и т.д.  Условия, при наступлении которых производится ревизия плана  Анализ результатов выполнения плана  Процедура управления изменениями планаАвтоматизация – это один из способов достижения стратегических бизнес - целей, во главе которого должна лежать стратегия бизнеса предприятия: миссия предприятия, направления и модель бизнеса.Ограничения, которые необходимо учитывать при выборе стратегий автоматизации:  Финансовые(определяются величиной инвестиций, которые предприятия способно сделать в развитие автоматизации)  Временные обусловленны: - сменой технологий основного производства - Рыночной стратегией предприятия - Государственным регулированием экономики  Ограничения, связанные с влиянием человеческого фактора - Корпоративная культура(отношение персонала в автоматизации) - Особенности рынка труда - Трудовое законодательство  Технические ограничения(связанны с реальными возможностями предприятия, отсутствие помещений и т.п.)Проблемы возникающие при разработке стратегии автоматизации, как правило, связаны со следующими факторами:  Состоянием рынка информационных технологий  Определением эффективности инвестиций в информационные технологии  Необходимостью реорганизации деятельности предприятия при внедрении информационных технологийПроцесс изменения системы управления является многоэтапным:  Определение миссии предприятия и его стратегических целей(решается исходя из анализа)  Анализ и адаптация внутренней среды предприятия с тем, чтобы его структура и принципы функционирования соответствовали миссии предприятия и были направлены на достижение поставленных стратегических целей  Формирование спецификаций, сопровождающееся выпуском проекта ИС предприятия  Внедрение – реализация проекта ИС на предприятииМетод проектирования автоматизированных ИС.  Одним из наиболее известных подходов к реорганизации является методика планирования бизнес-систем BSP. Главная идея заключается в том, что информация является одним из основных ресурсов и должна планироваться в масштабах всего предприятия, а ИС должна проектироваться независимо от текущего состояния и структуры предприятия  Подход CPI (Continuous Process Improvement) и его японский аналог TQM(Total Quality Management) В основе лежит очевидная концепция управления качеством выпускаемой продукции. Качество должно быть направлено на удовлетворение текущих и будущих запросов потребителя. Требования CMM (Capability Maturity Model) CMM применяется для: - Улучшения ПО – процессов, когда предприятие планирует, разрабатывает и реализует их изменения. - Оценки ПО - процессов - Оценки возможностей ПО Фактически CMM является комплексом требований к ключевым элементам эффективного ПО – процесса и способам его эволюционного улучшения.  Реинжиниринг бизнес – процессов BPR(Business Process Reengineering) фундаментальное переосмысление и радикальное перепланирование бизнес - прцоессов предприятий, имеющих целью резкое улучшение показателей их деятельностиПод бизнес – процессом понимается совокупность действий, получающая на входе данные различных типов и продуцирующая результат, имеющий ценность для потребителя. Одним из побудительных мотивов реорганизации деятельности предприятия может служить его желание сертифицироваться по стандарту ISO 9000(представляет собой серию стандартов 9000-9004, наиболее полным из которых является ISO 9001, специфицирующий модель обеспечения качества на всех этапах жизненного цикла товара/услуги) При реорганизации важен выбор метода оценки существующего положения дел и перспективных предложений:  Метод динамического функционального анализа на основе сетей Петри различного вида  Метод функционально – стоимостного анализа ABCКаждый из этих методов регламентирует следующие основные этапы выполнения оценок:  Построение статистической модели  Расширение стат. Модели соответственно поведенческими или стоимостными характеристиками её объектов  Сбор и ввод в модель необходимой фактической информации  Исполнение модели и получение соответствующих оценокС использование динамической модели, основанной на сетях Петри можно описать и проанализировать:  Механизмы взаимодействия процессов(последовательность, альтернатива)  Временные отношения между выполняемыми процессами(одновременность, наложение, поглощение, одинаковое время запуска и т.п.)  Абсолютное время(длительность процесса, время запуска)  Управление исключительными ситуациями, определяемое нарушениямиABC (Activity Based Costing) – метод определения себестоимости и других характеристик товаров и услуг на базе функций и ресурсов, задействованных во всех видах деятельности предприятия ABC модель обеспечивает лишь получение важной для бизнес – процесса информации, содержащей стоимостную картину деятельности и характеризующей её эффективность и прибыльность товаров Для дальнейшего анализа применяется методика ABM(Activity Based Management) ABM представляет собой комплекс методов анализа ABC – модели для реорганизации бизнес – процессов в целях повышения производительности, снижения стоимости и улучшения качестваСредства проектирования автоматизированных информационных систем. Инструментарий, которым пользуются инженеры по управлению, аналитики и проектировщики автоматизированных систем называется CASE – средствами. Инструментальные средства могут быть отнесены к одной из следующих категорий:  Локальные, поддерживающие один – два типа моделей и методов(Design/IDEF, ProCap, S-Designor, “CASE. Аналитик ”)  Малые интегрированные средства моделирование, поддерживающие несколько типов моделей и методов – Erwin и Bpwin  Средние, поддерживающие от 4 до 10-15 типов(Rational Rose, Paradigm Plus, Designer/2000)  Крупные, поддерживающие более 15 типов(ARIS Toolset)Предприятие располагает следующими принципиальными способами приобретения IT решения:  Разработка(самостоятельно, либо силами другой компании) + Возможность разработки АИС для конкретных локальных целей предприятия + Отсутствие функциональных, информационных и др. ограничений, присущих готовы АИС + Повышение степени совместимости с уже использующимися системами на предприятии - Большие затраты ресурсов - Сложность в определении пользователем своих потребностей - Необходимость в планировании и контроле над разработкой - Отсутствие необходимой квалификации у сотрудников в большинстве компаний Покупка готового решения, его адаптация и настройка под специфику предприятия + Минимальные задержки и затраты до внедрения ИС + Возможность выбора пакета(модулей), наиболее соответствующего требованиям организации + Наличие возможности наглядно оценить функциональные возможности готового продукта + Наличие соответствующего полного пакета документации на ИС - Наличие вероятности того, что разработчик прекратит свое существование или обслуживание ИС - Выбор и оценка готовых решений требуют использования дополнительных ресурсов - Ограниченные возможности для решения возникающих проблем Покупка ядра информационной системы и её модификация + Уменьшается использование ресурсов организации по сравнению с самостоятельной разработкой + Преодолеваются функциональные ограничения + Сочетаются выгоды двух других подходов - Возникают трудности при модификации, что порождает новые ошибки и проблемы контроля - Усложняется процесс ведения документации по внесенным изменениям - Возможен отказ со стороны разработчика в обслуживании модифицированных решений Прототипирование – это подход к разработке системы, при котором создается упрощенная действующая модель, или прототип. + Лучшее определение потребностей пользователей, большая вовлеченность пользователей в разработку, обнаружение ошибок при экспериментах, простота внесения изменений, меньшая стоимость - Большой расход времени пользователей, прототип не охватывает всех свойств разрабатываемой системы, повышенные ожидания пользователей и возможные разочарования  Аренда информационной системы у специального ASP провайдераПредлагается следующая классификация деятельности на предприятии:  А – первичная деятельность: изготовление конкретных изделий(автомобилей) или сервис(например гарантийное обслуживание)  B – вторичная деятельность, направленная на улучшение основной деятельности А  С – деятельность, направленная на совершенствование деятельности группы B В рамках рассмотренных групп деятельности предприятия используются модели, представленные на рисунке:Вышеперечисленные группы деятельности предприятия предполагают взаимосвязанность, таким образом, модели, используемые в рамках данных групп деятельности предприятия должны быть взаимосвязаны. Логическая модель, созданная на базе объектно- ориентированного подхода отражается:  В компоненте представления(интерфейс ИС) через прямой или обратный инжинириг  В документации СМК предприятия в серверной части ИС через описание бизнес-логики  В базе данных ИС через реляционную модельBPI(Business Process Improvement) подразумевает прохождение следующих этапов, предполагающих использование логического моделирования:  Отражение в шаблоне текущего состояния предприятия  Создание в шаблоне желаемой системы бизнес-процессов предприятия с привлечением передового опыта(IDEF0 и DFD-диаграмм)  Обеспечение реализации на предприятии желаемой системы бизнес-процессов с помощью ERP-системы и системы менеджмента качества(основанной на стандарте ISO 9001:2000)  Накопление статистики по состоянию бизнес-процессов предприятия(относящиеся к деятельности А), и ее анализ для обеспечения эффективности группы B Определение качественных и количественных измерений и оценок бизнес-процессов предприятия, для возможности определения факта достижения желаемой системы бизнес- процессов. Когда результаты оценок предприятия не совпадают с теми что заложены в шаблоне, необходимо вернуться на предыдущий этап  Констатация факта достижения предприятием желаемой системы бизнес-процессов. Прохождение описанных выше этапов предполагает вхождение предприятия в цикл BPI, обеспечивающий непрерывное улучшение бизнес-процессов предприятияПроблемы моделирования и предложения по их решению: Моделирование для предприятия нередко заканчивается тем, что разработанные модели оказываются неактуальными и ненужными. Причинами этого являются:  Наличие нескольких нестыкованных между собой моделей  Отсутствие шаблона, что способствует увеличению срока создания модели и ее удорожанию  Отсутствие четко сформулированных целей моделирования  Отсутствие информационной поддержки обеспечения внедрения и функционирования модели на предприятииПервая проблема снимается за счет описания в рамках одной модели как текущей, так и желаемой системы бизнес- процессов Вторая проблема снимается за счет использования шаблона, который основывается на стандартах ISO 9001:2000 и ERP Третья проблема снимается за счет использования базы для моделирования(стандарты ISO 9001:2000 и ERP) Четвертая проблема снимается за счет ориентации предприятия с самого начала моделирования на ERP- систему, что в дальнейшем позволяет в полной мере обеспечить контроль и оценку бизнес-процессов.Используя ERP-систему, предприятие решает сразу 3 задачи:  Информационную поддержку внедрения, контроля и оценки желаемой системы бизнес-процессов  Представление организацией производства и управления предприятием на базе ERP-стандарта, полностью или частично покрывающего стандарт ISO 9001:2000  Интеграция процессов предприятия

34.Структурное моделирование информационных систем средствами BPwin и Erwin.

Основные этапы построения IDEF3-модели: 1) Определить очередность запуска процессов. 2) Выделить перекрестки для отражения слияния/разветвления действий. 3) Построит возможные графики запусков процессов. 4) Построить контекстную диаграмму и диаграммы декомпозиции. 5) Создать сценарии 6.4.1.3 BPwin – средство моделирования потоков данных (DFD). Основные этапы построения DFD-модели: 1) Выделить процессы, внешние сущности и связывающие их потоки данных. 2) Построить контекстную диаграмму. 3) Выделить процессы, определить потоки данных и хранилища на соответствующем уровне декомпозиции. 4) Построить диаграммы декомпозиции. 5) Предложит управляющие процессы, потоки и хранилища.6.4.1.4 – средство информационного моделирования (IDEF1X). Основные этапы построения IDEF1X-модели: 1) Построение логической модели данных: - определение сущностей, определение зависимостей между ними. - задание первичных и альтернативных ключей. - определение атрибутов сущностей. - приведение модели к требуемому уровню нормальной формы. - переход к физическому описанию модели. - задание триггеров, процедур и ограничений. - генерация базы данных. 2) Построение физической модели данных: - выбор целевой СУБД, выделение представления, правила валидации для колонок, значения по умолчанию, определение индексируемых полей. - построение на базе логической модели физической модели. - генерирование БД на языке целевой СУБД. - создание физической модели по схеме данных уже существующей БД на языке любой поддерживаемой ERwin СУБД.

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

35.Объектное моделирование информационных систем средством Ration Rose.

Rational Rose – мощный инструмент для анализа и проектирования объектно-ориентированных программных систем, позволяющий моделировать системы до написания кода.

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

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

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

Диаграмма последовательности. Используется для моделирования взаимодействия объектов во времени.

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

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

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

36.Моделирования бизнес-процессов в среде Bizagi Process modeler. Нотация BPMN.

Bizagi Process Modeler это очень эффективная программа, специализирующаяся на разработке диаграмм или цепей бизнес-процессов.

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

Моделирование в BPMN 2.0 осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

·Объекты потока управления: события, действия и логические операторы

·Соединяющие объекты: поток управления, поток сообщений и ассоциации

·Роли: пулы и дорожки

·Артефакты: данные, группы и текстовые аннотации.

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

Объекты потока управления

Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).

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

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

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

·Операторисключающего«или», управляемый данными (англ.data-based exclusive gateway). Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

·Оператор исключающего«или», управляемый событиями (англ.event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.

·Операторвключающего«или»(англ.inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

·Оператор «и» (англ.parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.

·Сложный оператор (англ.complex gateway) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.