МЕТОДОЛОГИИ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

Функциональное моделирование деятельности предприятия

Методология моделирования IDEF0

Методология IDEF (Integrated Computer Aided Manufacturing DEFini- tion) включает в себя ряд стандартов моделирования различных аспектов исследуемой системы:

  • • IDEF0 — стандарт функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков;
  • • IDEF1 — стандарт моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
  • • IDEF1X (IDEF1 extended) — стандарт построения реляционных структур. IDEF1X относится к типу методологий «сущность — взаимосвязь» (ER — Entity-Relationship) и используется для моделирования реляционных БД в системе;
  • • IDEF3 — стандарт документирования процессов. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса.

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEFO как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть в глагольной форме (например, «производить услуги») и он должен иметь уникальный идентификационный номер. На диаграмме функциональный блок изображается прямоугольником (рис. 4.1). Каждая из четырех сторон функционального блока имеет определенное и неизменное значение (роль), при этом:

  • • верхняя сторона имеет значение «управление» (control);
  • • левая сторона — «вход» (input);
  • • правая сторона — «выход» (output);
  • • нижняя сторона имеет значение «механизм» (mechanism).
Функциональный блок IDEF0

Рис. 4.1. Функциональный блок IDEF0

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

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

Вход {Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. При описании технологических процессов (для этого и был разработан 1DEF0) не возникает проблем определения входов: это нечто, что перерабатывается в процессе исполнения функции блока для получения результата. При моделировании ИС, когда стрелками являются нс физические объекты, а данные, не все так очевидно. Например, при «Приеме пациента» карта пациента может быть и на входе, и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — «Заполненная карта пациента»).

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

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

Выход (Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться.

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

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

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

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

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >