Недостатки. - описание деятельности организации исключительно трудоемкое

- описание деятельности организации исключительно трудоемкое

При разбиении на процессы можно потерять вид всей деятельности

1. Этапы идентификации процесса как объекта управления.

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

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

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

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

На стадии идентификации бизнес-процессов выполняются следующие работы:

1. Формулирование (уточнение) миссии предприятия.

2. Определение ключевых факторов успеха (7-8 факторов): длительность, издержки, качество, сервисное обслуживание и т.д.

3. Выявление основных видов бизнес-процессов, как существующих, так и перспективных (10 – 15 процессов).

4. Оценка бизнес-процессов по степени реализации ключевых факторов успеха.

5. Ранжирование бизнес-процессов с указанием приоритетов реинжиниринга.

6. Неформальное описание отличительных особенностей бизнес-процессов.

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

8. Описание возможных сценариев развития предприятия: появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов.

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

10.Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров.

1. Методика моделирования бизнес-процессов: основные составляющие. Примеры методик моделирования бизнес-процессов. Семейство стандартов IDEF.

Структурный анализ как совокупность методов моделирования сложных систем вследствие большой размерности решаемых задач должен опираться на мощные средства компьютерной поддержки, обеспечивающей автоматизацию труда системных аналитиков. Такими средствами являются CASE-системы (Computer Aided Software Engineering).

Архитектура большинства CASE-систем основана на парадигме «методология — модель — нотация — средства».

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

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

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

Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.

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

• функции, которые система должна выполнять;

• процессы, обеспечивающие выполнение указанных функций;

• данные, необходимые при выполнении функций, и отношения между этими данными;

• организационные структуры, обеспечивающие выполнение функций;

• материальные и информационные потоки, возникающие в ходе выполнения функций.

Среди многообразия средств, предусмотренных для проведения структурного анализа, наиболее часто и эффективно применяются:

• DFD(Data Flow Diagrams)—диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

• STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени;

• ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена

и Баркера;

• структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

• FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;

• SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;

• семейство IDEF (Integration Definition for Function Modeling):

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

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

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

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

• IDEF4 — методология объектно-ориентированного проектирования для поддержки проектов, связанных с объектно-ориентированными реализациями;

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

1. Понятия «зона ответственности», «бизнес-роль». Виды бизнес-ролей.

1. Входы и выходы процесса. Поставщики и потребители потоков процесса. Привести примеры обеспечивающих БП.

Входы и выходы процесса

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

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

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

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

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

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

Поставщики и потребители потоков процесса.

Первичный поставщик

Вторичный поставщик

Первичный потребитель

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

Потребитель – конечный потребитель выходных потоков процесса.

Вторичный потребитель

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

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

1. Понятие «граница процесса». Виды границ. Понятие «интерфейс процесса». Виды интерфейсов.

У каждого БП есть границы, интерфейс и владелец.

Границы БП – граница входа, которая предшествует первой операции процесса, и граница выхода, которая следует за его последней операцией.

Начальная граница процесса – предшествует первой выполняемой функции процесса.

Конечная граница процесса – располагается за последней функцией процесса.

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

Внешний интерфейс процесса – механизм (организационный, информационный, технический), посредством которого процесс взаимодействует с предшествующим и последующим процессами.

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

1. Архитектура процессов (уровни представления). Понятие «продукт». Категории продукции.

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

Продукт – результат процесса (ISO 9000:2005)

4 категории продукции:

· Услуга является результатом по меньшей мере одного действия, обязательно осуществляемого при взаимодействии поставщика и потребителя. Она, как правило, нематериальна.

· Программные средства содержат информацию, являются нематериальными.

· Технические средства материальны, и их количество выражается исчисляемой характеристикой.

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

Отнесение продукции к одной из категорий зависит от преобладающего элемента.

1. Системный анализ как основа описания деятельности. Понятия «система», «цель», «система целей». Классификация целей по признаку «интервал планирования». Классификация целей по качественному признаку решения проблем бизнеса.

1. Основные свойства системы. Понятие «системный подход». Задачи, для решения которых применяется системный подход.

Свойства системы:

· Целенаправленность – определяет поведение системы

· Сложность – зависит от множества входящих в нее компонентов

· Делимость – система состоит из ряда подсистем, выделенных по определенному признаку

· Целостность - функционирование всех элементов системы подчинено единой цели

· Многообразие элементов системы и различие их природы

· Структурированность – определяется наличием установленных связей и отношений между элементами внутри системы, распределении элементов системы по уровням иерархии.

1. Понятия «бизнес-система», «структурный анализ», «структура организации», «подсистема организации».

Бизнес-система – это система для организации и ведения бизнеса. Бизнес-систему необходимо рассматривать в неразрывной связи с внешней средой.

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

Структура организации – устойчивая картина взаимных отношений подсистем организации.

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

1. Задачи структурного анализа. Понятие «методология».

Задачи структурного анализа организации:

· Выявление структуры как относительно устойчивой совокупности отношений

· Частичное отвлечение от развития объектов

· Графическое модельное представление объектов, которое начинается с общего обзора и затем детализируется

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

1. Общее понятие «модель», понятия «модель организации», «нотация». Последовательность структурированного описания деятельности.

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

1. Понятия «структурный объект», «связь». Методологии структурного анализа.

Структурный объект – неделимая наименьшая часть системы (на данном уровне рассмотрения).

Связь – вид отношений между объектами, который проявляется как некоторое взаимодействие.

1. Основные шесть методов структурного анализа. Семейство стандартов IDEF.

1. Понятие «документирование деятельности». Важнейшие требования к документированию деятельности.

1. Роль CASE-систем в структурном анализе, привести примеры CASE систем. Привести примеры основных БП. Понятие «моделирование деятельности организации».
2. Понятие «бизнес-моделирование» как составляющая моделирования деятельности. Объект моделирования при описании деятельности организации. Предмет моделирования (объект управления в конкретной организации).
3. Комплекс проектов по совершенствованию деятельности: состав и очередность.
4. Управление проектами в соответствии с PMI PMBOK. Понятия «проект», «проектный треугольник», «управление проектами». Программные продукты, позволяющие автоматизировать деятельность по управлению проектом.
5. Понятия «стратегическое планирование», «стратегическое управление», «система стратегического управления», «система сбалансированных показателей» (Balanced Scorecard).

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

Пять элементов стратегии (Г.Минцберг):

§ стратегия как план;

§ стратегия как позиция;

§ стратегия как приём;

§ стратегия как паттерн действий;

§ стратегия как перспектива.

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

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

Ключевые моменты стратегического планирования:

§ стратегия разрабатывается высшим руководством;

§ стратегический план должен быть подкреплен исследованиями и фактическими данными;

§ стратегические планы должны быть гибкими для возможности их изменения;

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

Стратегическое управление (менеджмент) — функция управления (менеджмента), распространяется на долгосрочные цели и действия компании. Формулировка стратегии (образа действий) и её чёткий инструментарий являются ядром управления и важным признаком хорошего менеджмента компании.

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

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

1. Назначение BSC и основания для ее внедрения.
2. Порядок разработки системы показателей BSC.Понятия «дерево целей», «перспектива», «стратегическая карта», «ключевой показатель эффективности», «измеритель достижимости цели», «показатель эффективности бизнес-процесса», «вес ключевого показателя эффективности», «источник данных для показателя», «мероприятие» (инициатива), «ответственный за мероприятие».
3. Контроль достижения целей в методике BSC.Реализация принципа обратной связи в BSC. Основное отличие методики BSCот простого набора показателей.
4. Цели и логика разработки соглашения по моделированию БП как основы для документирования деятельности.
5. Структура соглашения по моделированию.
6. Методы получения информации о деятельности организации в рамках проекта по описанию бизнес-процессов.
7. Порядок описания существующих бизнес-процессов. Виды документов, разрабатываемых на основе бизнес-модели и регламентирующих деятельность.
8. Основные результаты проекта по описанию бизнес-процессов.
9. Этапы проекта по совершенствованию бизнес-процессов.
10. Результаты проекта по совершенствованию бизнес-процессов.
11. Метод моделирования SADT. Назначение метода. Структура бизнес-модели по уровням декомпозиции.

Для моделирования БП используются несколько различных методов. Основой этих методов является как структурный, так и объектно-ориентированный подходы. Однако деление методов на структурный и объектный является достаточно условным, потому что наиболее развитые методы используют оба подхода. К числу наиболее распространенных методов относятся:

-метод функционального моделирования SADT(IDEF0)

-метод моделирования процессов из семейства методов IDEF3

-метод моделирования потоков данных

-метод ARIS

-метод Ericsson-Penker

-метод моделирования, используемый в технологии RUP

Метоф функционального моделирования IDEF0. Метод SADT считается классическим методом процессного подхода к управления. Основной принцип процессного подхода заключается в структурировании деятельности в соответствии с БП организации, а не организационно-штатной структурой. Именно БП, формирующие значимые для потребителя результаты, представляют ценность. Именно их улучшением предстоит заниматься системным аналитикам. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации, о котором в принципе руководству и так известно. НА основе организационно-штатной структуре можно лишь внести предложения об ее изменении. С другой стороны, модель, основанная на БП, содержит в себе в том числе и организационно-штатную структуру. В связи с этим бизнес-модель должна выглядеть следующим образом:

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

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

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

-описание элементарной бизнес-операции. Осуществляется посредством задания алгоритма и его выполнения.

Метод SADT разработан Дугласом Россом в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организаций США для решения задач:

-долгосрочное стратегическое планирование;

-автоматизированное производство и проектирование;

-разработка программного обеспечения для оборонных систем;

-управление финансами и материально-техническим снабжением.

Метод SADT поддерживается мин обороны США, которое было инициатором разработки семейства стандартов IDEF. Метод SADT реализован в одном стандарте этого семейства — 0.

Данный стандарт утвержден в качестве федерального стандарта США в 1993г. Существует также российская версия данного стандарта [9]. Вместе со стандартом IDEF0 обычно используется стандарт IDEF3 и стандарт моделирования данных IDEF1X.

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

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

-строгости и точность. Правила SADT включают: 1) ограничение количество блоков на каждом уровне декомпозиции (3,6 блоков); 2) связность диаграмм (нумерация блоков); 3) уникальность меток и наименований (отсутствие повторяющихся элементов); 4) синтаксические правила для графики (); 5)

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

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

1. Метод моделирования SADT. Состав функциональной модели. Типы интерфейсов.

Результатом применения метода SADT является модель которая состоит из диаграмм, фрагментов текста и глоссария имеющих ссылки друг на друга.

Главные компоненты модели.

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

Особенность — постепенное введение все больших уровней детализации по мере создания диаграмм.

Отображение модели – каждый компонент может быть декомпозирован на др диаграмме.

1. Метод моделирования SADT. Порядок построения SADT-модели.

Выполнение следующих действий:

1) сбор информации об объекте и определения его границ;

2) определение цели и точки зрения на объект моделирования;

3) построение, обобщение и декомпозиция диаграмм;

4) критическая оценка, рецензирование, комментирование.

Построение диаграмм начинается с представления всей системы в виде простейшего компонента, т.е. одного блока и дуг, изображающих интерфейсы к функциям вне системы. Поскольку единственный блок отражает систему как единое целое, имя указанное в блоке является общим. Это же верно и для интерфейсных дуг, они так же соответствуют полному набору внешних интерфейсов системы в целом. Блок, который представляет систему в качестве единого модуля детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок. Каждая из подфункций может быть декомпозирована подобным образом. Во всех случаях, каждая подфункция может содержать только те функции, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы. То есть родительский блок и его интерфейсы обеспечивают контекст. К нему ничего нельзя добавить и из него не может быть ничего удалено. Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающий сложный объект на составные части. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. На каждом шаге декомпозиции диаграмма на предыдущем уровне называется родительской. На SADT -диаграммах не указываются явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся по времени функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д.

1. Метод моделирования SADT. Стратегии декомпозиции.

При построении иерархии диаграмм используются следующие стратегии декомпозиции диаграмм:

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

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

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

1. Метод моделирования SADT. Правила (рекомендации) для определения момента завершения моделирования.

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

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

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

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

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

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

5. Блок представляет тривиальную функцию. Тривиальная функция-функция, понимание которых не имеет никаких объяснений. В этом случае очевидна целесообразность отказа от декомпозиции потому, что роль метода САДТ заключается в превращении сложного вопроса в понятный, а не в педантичный в разработке очевидных деталей. В таких случаях декомпозиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста. Следует заметить, что тривиальный не означает бесполезный, такая функция выполняет очень важную роль, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать тривиальные функции, наоборот их существование должно быть зафиксировано и они должны быть детализированы как любые другие функции, но следует предостеречь от больших затрат времени на анализ тривиальных функций. Усиленное внимание к мелочам может привести к созданию модели, которой будет недоставать абстракции, что сделает ее трудной для понимания и использования. Общее число уровней модели, включая контекстный, не должно превышать 5-6 уровней. Практика показывает, что этого вполне достаточно для построения полной, функциональной модели современного предприятия любой отрасли.

1. Метод моделирования SADT. Преимущества и недостатки SADT.

Метод САДТ в наибольшей степени подходит для описания моделей верхнего уровня. Его основные преимущества заключаются в следующем:

1. полнота описания БП (управления, информационные и материальные потоки, обратные связи).

2. Комплексность декомпозиции

3. Возможность агрегирования и детализации потоков данных и информации (разделение и слияние дуг)

4. наличие жестких требований, обеспечивающих получение модели стандартного вида.

5. Простота документирования процесса

6. соответствие подхода к описанию процесса стандарту ИССО

В то же время САДТ обладает рядом недостатков:

1. сложность восприятия — большое количество дуг на диаграмме.

2. Большое количество уровней декомпозиции

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

1. Метод моделирования IDEF3.Назначение метода. Структура бизнес-модели по уровням декомпозиции.

IDEF3 – метод моделирования процессов.

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

Разработан в к 80-х для закрытого проекта ВВС США. Предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процесса. Он не достиг статуса Федерального стандарта США, но приобрел широкое распространение как дополнение к методу функционального моделирования IDEF0. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции.

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

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

1. Метод моделирования IDEF3.Состав диаграмм IDEF3.Типы связей.

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

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

Существенные взаимоотношения между действиями изображаются с помощью связи. Все связи являются однонаправленными (слево-направо).

Типы связей:

- временное предшествование: исходное действие должно завершиться прежде чем конечное действие сможет начаться;

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

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

1. Метод моделирования IDEF3.Виды соединений по принципу ветвления и логике. Отображение синхронных соединений.

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

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

Рис. Соединение типа И. Соединения разбивают или соединяют внутренние потоки и используются для изображения ветвления процесса. Таким образом существует 2 вида соединений по способу ветвления процесса:

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

2. сворачивающие соединения - объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.

Все эти соединения могут быть 3-х типов:

-

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

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

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

В рассмотренных примерах действия выполнялись асинхронно, не инициировались одновременно. Однако существуют случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаково. То есть действия должны выполняться синхронно. Для моделирования такого поведения системы используются различные виды синхронных соединений, которые обозначаются двумя вертикальными линиями внутри прямоугольника. Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений не обязательно должны совпадать. Соединения могут комбинироваться для создания более сложных ветвлений. Комбинации соединений следует использовать с осторожностью, поскольку перегруженные ветвления диаграммы могут оказаться сложными для восприятия. Действия в диаграммах ИДЕФ3 могут быть декомпозированы или разложены на составляющие для более детального анализа. Метод ИДЕФ3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процессов в модели.

1. Метод моделирования DFD. Назначение метода. Структура бизнес-модели по уровням декомпозиции.

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

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

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

1. Метод моделирования DFD. Состав диаграмм DFD. Основные компоненты.

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

Основные компоненты диаграмм потоков данных являются

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

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

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

3.

процессы — представляет собой преобразование входных потоков данных в выходные в соответствие с определенным алгоритмом. Физически процесс может быть реализован различными способами: подразделение организации, выполняющие обработку входных документов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображается аналогично рисунку выше. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным, недвусмысленным глаголом в неопределенной форме, за которым следуют существительные в винительном падеже, (например,"Ввести сведения о клиентах"; "Выдать информацию о текущих расходах"; "Проверить кредитоспособность клиента").

Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

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

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

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

1. Метод моделирования DFD.Правила (рекомендации) построения иерархии диаграмм DFD.

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

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

· размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично САП). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей. Нижняя граница — по соображениям здравого смысла.

· Не загромождать диаграммы не существенными на данном уровне деталями

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

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

1. Метод моделирования DFD. Порядок построения иерархии диаграмм DFD.

Первым шагом при построении иерархии является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией. В ее центре находится главный процесс, соединенный с приемниками и источниками информации, потоками, посредством которых с системой взаимодействуют пользователи и другие сущности внешней системы. Перед построением контекстной ДФД необходимо проанализировать внешние события (сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме д.б. по возможности небольшим, поскольку каждый из них в дальнейшем м.б. разбит на несколько потоков. Для проверки контекстной диаграммы можно составить список событий (должен состоять из описания действий внешних сущностей — событий и соответствующих реакций системы на событие. Каждое событие должно соответствовать одному или более потокам данных. Входные потоки интерпретируются как воздействия, выходные — реакция системы на входные потоки.). Для сложных систем (признак сложности - наличие большого количества внешних сущностей>10, распределенная система или ее многофункциональность) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственны главный процесс, а набор подсистем соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистемы. Для каждой подсистемы, присутствующей на контекстной диаграмме выполняется ее детализация при помощи ДФД. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса, накопителями данных, внешними сущностями и ссылками на другие процессы для описание связей м/у этим процессом и его окружением.

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

Спецификация — конечная вершина в иерархии ДФД. Решение о завершении детализации процесса и использование спецификации принимается аналитиком исходя из следующих критериев:

· наличие у процесса относительно небольшого количества входных и выходных потоков данных (2-3)

· если существует возможность описания преобразования данных процесса в виде последовательного алгоритма

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

· возможность описание логики процесса при помощи спецификации небольшого объема (20-30 строк).

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

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

2. глаголы д.б активными не двусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать)

3. логика процесса д.б. выражена четко и не двусмысленно

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

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

1. Метод моделирования DFD. Правила (рекомендации) для определения момента завершения детализации иерархии диаграмм.

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

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

5. глаголы д.б активными не двусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать)

6. логика процесса д.б. выражена четко и не двусмысленно

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

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

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

Миниспецификация является конечной вершиной иерархии ДФД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

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

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

· возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

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

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

1. Метод моделирования DFD. Понятие «спецификация», «элемент данных», «структура данных», «поток данных». Типы организации структур и элементов данных.

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

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

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

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

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

2. глаголы д.б активными не двусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать)

3. логика процесса д.б. выражена четко и не двусмысленно

Основные компоненты (элементы данных):

- внешние сущности

- системы и подсистемы

- процессы

- накопители данных

- потоки данных

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

Для дискретных данных может указываться единица измерения и диапазон значений, точность представления и таблица допустимых значений. После построения законченной модели системы ее необходимо верифицировать, т.е. проверить на полноту и согласованность. В полной модели все ее объекты, т.е подсистемы, процессы, потоки данных должны быть подробно описаны и детализированы. Если выявляются недетализированные объекты, их следует детализировать. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации – все поступающие куда-либо данные должны быть считанны, а все считанные данные должны быть записаны. При моделировании бизнес-процесса диаграммы потоков данных используются для построения модели as is и as to be, отражая таким образом существующую и предполагаемую структуру бизнес-процессов организации и взаимодействия между ними. При этом описание используемых в организации данных на концептуальном уровне, независящем от средств реализации баз данных, выполняется с помощью модели сущность отношения.

1. Метод моделирования ARIS. Назначение и структура бизнес-модели. Типы моделей (аспекты моделирования, представления).

Назначение бизнес-модели: Построение модели организации и усовершенствование по возможности.

1. Метод моделирования ARIS. Требования к последовательности разработки моделей. Основные типы объектов и связей диаграмм ARIS. Понятие «атрибут».

· Этап 1. Разработка модели организации "как есть".

· Этап 2. Анализа модели организации "как есть".

· Этап 3. Разработка модели организации "как надо".

· Этап 4. Разработка плана перехода из состояния "как есть" в состояние "как надо".

· Этап 5. Внедрение изменений и построение организации "как надо".

Будет подробно рассмотрен, первый этап по описанию организации "как есть", который состоит из четырех шагов.

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

Рис. 1. Четыре шага описания организации.

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

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функции", "события", "структурные подразделения", "документы" и т.д. Между объектами определённых видов могут быть установлены связи определённых видов ("выполняет", "принимает решение", "должен быть проинформирован о результатах" и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

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

• выполняет;

• принимает решение;

• участвует в выполнении;

• должен быть проинформирован о результатах;

• консультирует исполнителей;

• принимает результаты.

Основные объекты нотации eEPC:

· Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, "запускающей" выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.

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

· Организационная единица. Например, управление или отдел.

· Документ. Отражает реальные носители информации, например, бумажные документы.

· Прикладная система.

· Кластер информации. Характеризует набор сущностей и связей между ними.

· Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.

· Логический оператор. Оператор "И", "ИЛИ" или исключающее "ИЛИ", позволяет описать ветвление процесса.

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

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

Атрибут – это признак, характеризующий объект.