Интернет и другие компьютерные сети. Классификация территориальных сетей

Читайте также: Ведомые сетью инверторы на тиристорах (на примере трехфазной однополупериодной схемы, анализ, временные диаграммы). Вопрос № 4. Фазовые равновесия в двухкомпонентных системах. Диаграммы плавкости. Правило рычага. Выделить диаграмму, на вкладке Конструктор в группе Расположение выполнить команду Переместить диаграмму Генераторы постоянного тока, энергетическая диаграмма. Классификация. Графическое изображение изменения гидростатического давления вдоль стенки в зависимости от глубины называется диаграммой распределения давления или эпюрой давления. Диаграмма направленности антенны. Способы представления: в прямоугольной системе координат; полярной системе координат; картографическое изображение.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах:

• Диаграммы относящиеся к первому типу называются диаграммамиОписания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) ,
• а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN) .

Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

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

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

Рисунок 1. Пример PFDD диаграммы.

На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементамиповедения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения . Каждый UOB имеет свое имя , отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления .

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

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

Рисунок 2. Пример OSTN диаграммы

На рис.2 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

6) IDEF3-модель отвечает на вопросы "Как система это делает?" Язык IDEF3 - язык диаграмм, помогающий разработчику моделей наглядно представить моделируемые процессы. В IDEF3 входят два типа описаний:

1. процесс-ориентированные в виде последовательности операций (Process Flow Description Diagrams, PFDD);

2. объект-ориентированные, выражаемые диаграммами перехода состояний, характерными для конечно-автоматных моделей (Object State Transition Network, OSTN).

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

Рис. 1. IDEF3-диаграмма последовательности операций

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

Рис. 2. Перекрестки

На рис. 4 представлен пример объект-ориентированной IDEF3-диаграммы. В таких диаграммах имеются средства для изображения состояний системы, активностей, переходов из состояния в состояние и условий перехода.

Рис. 4. IDEF3-диаграмма перехода состояний

7)IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает система?", то в этих методиках детализируется ответ на вопрос: "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний. Перечисленные методики относятся к так называемым структурным методам.

IDEF4 Объектно-ориентированное проектирование

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

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

IDEF5 Систематизация объектов приложения

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

Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 Использование рационального опыта проектирования

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

Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF8 Взаимодействие человека и системы

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

User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 Учет условий и ограничений

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

Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF14 Моделирование вычислительных сетей

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

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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

· достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

· отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

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

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

· негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

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

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

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

· приемлемый уровень отдачи от инвестиций в CASE-средства.

CASE средства поддерживают 2 технологии:

All fusion (поддерживает структурную методологию, IDEF0, IDEF1 и т.д.) - datarun

Объектно-ориентированную методологию (UML). – RUP (рациональный унифицированный процесс)

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

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

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели- В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы, например, "Изготовление изделия". Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

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

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

Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

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

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

Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 1.52).

Рисунок 1.52. Временная диаграмма выполненияработ

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка в палитре инструментов - добавить в диаграмму перекресток Junction. В диалоге Junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.

Таблица 1.4. Типы перекрестков
Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должныбыть завершены	Один или несколько следующих процессов должны быть запущены
	Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.53). Для внесения объекта ссылки служит кнопка (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки. Типы объектов ссылок приведены в табл. 1.5.

Таблица 1.5. Типы объектов ссылок
Тип объекта ссылки	Цель описания
OBJECT	Описывает участие важного объекта в работе
GOTO	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток
UOB (Unit of behavior)	Применятся, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа "Контроль качества" может быть использована в процессе "Изготовления изделия" несколько раз, после каждой единичкой операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ
NOTE	Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму
ELAB (Elaboration)	Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.54).

Рисунок 1.54. Номер единицы работы (UOW)

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

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

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

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

Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например, для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация Перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом писывает все стороны деятельности предприятия (рис. 1.55). Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEF0 изображаются зеленым цветом, IDEF3 - желтым, DFD - синим.

Рисунок 1.55. Представление смешанной модели в окне Model Explorer

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

• · документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;
• · определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
• · определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта;
• · содействовать принятию оптимальных решений при реорганизации технологических процессов;
• · разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…».

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

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

Рис. 4.

Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

Рис. 5.

На рисунке 5 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB_блоками в ходе процесса. Линии бывают следующих видов:

• · Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;
• · Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB;
• · Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 1.

Таблица 1

Название перекрестков	Обозначение перекрестков	Смысл перекрестков
Схема расхождения	Схема схождения
«Исключающий ИЛИ»	Только одна последующая работа запускается	Только одна предшествующая работа должна быть завершена
	Асинхронный	Все последующие работы запускаются	Все предшествующие работы должны быть завершены
Синхронный	Все последующие работы запускаются одновременно	Все предшествующие работы должны быть завершены одновременно
	Асинхронный	Одна или несколько последующих работ запускаются	Одна или несколько предшествующих работ должны быть завершены
Синхронный	Одна или несколько последующих работ запускаются одновременно	Одна или несколько предшествующих работ должны быть завершены одновременно

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J». Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 5, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Рис. 6.

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

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

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

	Цель описания
	Описывает участие важного объекта в работе
	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток
UOB (Unit of behaviour)	Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовление изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ
	Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму
ELAB (Elaboration)	Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках

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

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

универсальный графический моделирование трикотажный процесс

Стандарт IDEF0 является развитием классического DFD - подхо­да и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выпол­нения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.

В IDEF3 декомпозиция используется для детализации работ. Ме­тодология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множе­ственной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на те­кущей диаграмме.

Отличием стандарта IDEF3 от классической методологии WFD яв­ляется также использование на схеме бизнес-процесса элемента «объект ссылки», который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информа­ция, которую целесообразно зафиксировать при описании бизнес-процесса.

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

2) модель, показывающая «сеть переходных состояний объекта», предлагающая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определен­ный процесс,

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

В отличие от классической методологии WFD в стандарте IDEF3 связи между работами делятся на три типа, обозначения, названия и смыл которых, приведены на рис. 3.16.

Существуют два типа диаграмм в стандарте IDEF3, представля­ющих описание одного и того же сценария технологического процес­са в разных ракурсах:

диаграммы Описания Последовательности Этапов Процес­са (Process Flow Description Diagrams, PFDD);

диаграммы Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

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

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

обработку.

Стрелки или линии являются отображением перемещения детали между иОВ-блоками в ходе процесса. Линии бывают следующих ви­дов:

Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;

Отношения (Relational Link) - пунктирная линия, использу­ющаяся для изображения связей между UOB;

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

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены пе­ред началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекре­сток не может использоваться одновременно для слияния и для раз­ветвления. При внесении перекрестка в диаграмму необходимо ука­зать тип перекрестка.

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».

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

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

Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 3.18, а та, соответственно роди­тельской. Номера UOB дочерних диаграмм имеют сквозную нумера­цию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1». «1.2» и т.д. Применение принципа декомпозиции в IDEF 3 позволяет структу­рировано описывать процессы с любым требуемым уровнем детализа­ ции.

Если диаграммы PFDD технологический процесс «С точки зре­ния наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Со­стояния объекта (в нашем случае детали) и Изменение состояния яв­ляются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линия­ми. Каждая линия имеет ссылку на соответствующий функциональ­ный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Первой работой является «Обработка заявок». Эта работа использу­ет два объекта ссылок - «Заказы клиентов» и «Склад» - причем на диаграмме они показаны без деталей, т.к. не являются центральными для данной диаграммы. Работа «Обработка заявок» требует выпол­ нения одной из двух работ -либо «Оформление документов», либо «Дооформление заявок» (в случае, если заявка неверно оформлена). Ра­ бота «Дооформление заявок» использует ссылочный объект «Клиен­ты». Работа «Оформление документов» передает управление на две параллельные работы: «Формирование партии» и «Составление от­четности», причем работа «Формирование партии» также обраща­ется к ссылочному объекту «Заказы клиентов». Как видно, на диаграмме есть два перекрестка ветвления, перекре­ сток с ветвлением по логическому исключающему «ИЛИ», и перекре­ сток с ветвлением по «И», означающим выполнение двух работ парал­ лельно.

Методология ARIS

В настоящее время наблюдается тенденция интеграции разнооб­разных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуе­мой системы:

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

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

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

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

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

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

Основная бизнес-модель ARIS - еЕРС (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS еЕРС является расширением нотации IDEF3. Бизнес-процесс в нотации еЕРС представляет собой поток по­следовательно выполняемых работ (процедур, функций), располо­женных в порядке их выполнения. Реальная длительность выполне­ния процедур в еЕРС визуально не отражается. Для получения информации о реальной длительности процессов необходимо исполь­зовать другие инструменты описания, например, MS Project.

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

Платформа ARIS является специализированным набором ин­струментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:

Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);

динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);

разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);

мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);

управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager):

разработки, внедрения и поддержания системы управления опе­рационными рисками (ARIS Process Risk Scout);

создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);

Проектирования системы сбалансированных показателей (ARIS

В ARIS существует более 130 различных способов графического представления моделей деятельности предприятия. Пример модели­рования в нотации ARIS представлен на рис. 3.20. и в Приложении Д.

Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к приме­ру, перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стои­мость работ. Модуль ARIS Process Cost Analyzer позволяет реализо­вать традиционную методологию Activity based costing для определе­ния стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.

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

Например, ЕМ Tool Kit требуется пройти учебный курс длительно­ стью два-три дня, а для освоения основных функциональных возмож­ностей ARIS придется посетить несколько специализированных учеб­ ных курсов продолжительностью от пяти до пятнадцати дней.

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

Оплата безналичным расчетом

Рис. 3.20 - Модель верхнего уровня взаимосвязи ЗАТ НКМЗ с внешней средой в нотации AR1S Express

Моделирование бизнес-процессов -это

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

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

Анализ бизнес-процессов предприятия с разных точек зрения называ­ется аудитом бизнес-процессов. Он проводится после создания и описа­ния модели предприятия.

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

Модель бизнес-процесса -прикладное представление (в заданной нотации) исполняемых предприятием работ.

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

Методология -это совокупность методов применяемых в жизнен­ном цикле разработки системы (бизнес-процесса) и объединенных одним общим философским подходом.

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

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

Методологии моделирования бизнес-процессов классифицируют по трем категориям: 1) Методологии ведения проекта; 2) Методологии использования программных продуктов для моделирования бизнес-процессов в проекте; 3) Методологии моделирования и анализа бизнес-процессов.

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

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

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

SADT ( Structured Analysis and Design Tecchnique ) - методология структурного анализа и проектирования, которая породила целый ряд методов IDEFx . завоевавших особую популярность в задачах инжини­ ринга и реинжиниринга бизнес - процессов.

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

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

DFD ( Data Flow Diagrams ) - диаграммы потоков данных - методо­ логия структурного анализа, описывающая внешние по отношению к си­ стеме источники и адресаты данных, логические функции, потоки дан­ ных и хранилища данных к которым осуществляется доступ.

1. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация биз­нес- процессов [Текст]: учеб. посо­бие для студ. вузов, обучающихся по специальности 080801 «Прикладная информатика (по областям)» и др. экон. специальностям. - М. : Фи­нансы и статистика, 2007. - 240с.

Сериков А.В., Титов Н.В., Белоцерковский А.В., Лобанов А.В., Успаленко В.И. Компьютерное моделирование бизнес-процессов [Текст]: учеб. пособие для студ. вузов / Харьковский гос. техниче­ский ун-т строительства и архитектуры. - X. : Бурун Книга, 2007. -303 с.

Щенников С. Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка [Текст]. - М.:Ось-89, 2004. -288 с.

Робсон Майк, Уллах Филип. Реинжиниринг бизнес-процессов [Текст]: Практическое руководство / Л.Е. Долгова (пер.). - М. : ЮНИТИ, 2003. - 222 с.

Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов [Текст]. - М.: РИА «Стандар­ты и качество», 2004. - 408 с

а Шеер Август-Вильгельм. Моделирование бизнес-процессов [Текст]. - М.: Весть-МетаТехнология, 2000. - 206 с.

7 Виноградова О.В. Реінжиніринг бізнес-процесів торговельних підприємств [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2006.- 183 с.

Виноградова О.В. Реінжиніринг бізнес-процесів у сучасному ме­неджменті [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2005. - 195 с.

Ойхман Е.Г. Реинжиниринг бизнеса [Текст]/ Е. - М.: Финансы и статистика, 1997. - 336с.

Ю.Марка Д. Методология структурного анализа и проектирования.

[Текст] / Марка Д. - пер. с англ. - М. Финансы и статистика. -

2003. -240 с. H.Draheim, D. Business process technology: a unified view on business

processes, workflows and enterprise applications / Dirk

Draheim. - Berlin: Springer, 2010. - 323 p. 12.Holt, J. A Pragmatic guide to business process modelling / Jon

Holt. - British Informatics Society Ltd, 2009. - 246 p. 13.Laguna, M. Business process modeling, simulation and design /

Manuel Laguna, Johan Marklund. - Prentice Hall, 2005. - 429 p.

/. Что представляет собой процесс мо­делирования бизнес-процессов?

Назовите цель моделирования бизнес-процессов.

Перечислите преимущества моделиро­вания.

Что называется аудитом бизнес-процессов?

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

6 Что представляет собой модель в целом? 7 Раскройте сущность модели бизнес-процесса.

8 В чем состоит сущность нотации бизнес-процессов?

9- Перечислите виды моделей, которые могут применяться в дея­ тельности предприятия. Раскройте их сущность.

10. В каких формах может производиться описание бизнес-процесса? В чем их преимущества и недостатки? П. Что представляет собой методология?

По каким признакам классифицируют методологии моделирова­ния бизнес-процессов?

Раскройте сущность методологий ведения проектов.

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

В чем состоит сущность методологии моделирования и анализа бизнес-процессов?

Перечислите основные исторические этапы развития методоло­гий.моделирования бизнес-процессов.

В чем состоит многообразие «проекций» предприятия?

SADT . Охарактеризуйте ти­пы данных моделей.

Какие основные элементы используются в модели по SADT ?

Раскройте историю появления методологии IDEFO .

Какие основные понятия лежат в основе методологии IDEFO ? Раскройте их содержание.

Какие составляющие имеет функциональный блок?

Охарактеризуйте виды интерфейсных дуг.

В чем заключается сущность принципа декомпозиции и в каких случаях декомпозиция выполняется?

Для чего необходим глоссарий?

В каких случаях используются диаграммы потоков данных DFD (Data Flow Diagrams )?

Перечислите и раскройте сущность основных элементов DFD диаграмм.

Раскройте сущность методологии DFD в нотациях Гейна-Сарсона и Иордана-Де Марко. В чем их сходства и отличия?

Для каких целей был разработан стандарт IDEF 3?

Назовите основные отличия стандарта 1 DEF 3 от классической методологии WFD .

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

І.Что понимают под моделирова­нием бизнес-процессов?

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

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

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