Архитектура предприятия.-7

Рис. 2.1. DFD-схема бизнес-процесса «Оформление и выдача трудовойкнижкисотруднику приувольнении» внотацииГейна-Сарсона

Рис. 2.2. DFD-схема бизнес-процесса «Оформление и выдача трудовой книжки сотруднику при увольнении» в нотации Йордона Де Марко

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

1)анализ — определение назначения системы;

2)проектирование — определение подсистем и их взаимодействие;

3)реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое;

4)тестирование — проверка работы системы;

5)установка — введение системы в действие;

6)эксплуатация — использование системы.

IDEF0 (Function Modeling) — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов, разработана Дугласом Россом. Отличительной особенностью IDEF0 является ее акцентирование на соподчиненности объектов. В данной методологии рассматриваются логические отношения между работами, а не их временная последовательность. Изначально модель IDEF0 была разработана как стандарт в 1981 г. в рамках программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing), предложенной Департаментом воен- но-воздушных сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (ICAM DEFinition). В процессе практической реализации участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик – специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений появилась методология функционального моделирования IDEF0. C 1981 г.

84 Глава 2. Классические методологии построения …

стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST).

Методология IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция: система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. Каждая диаграмма IDEF0 содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

Функциональные блоки (работы) на диаграммах изобра-

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

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

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

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

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

В IDEF0 различают пять типов стрелок:

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

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

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

4)механизм — ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По ус-

86 Глава 2. Классические методологии построения …

мотрению аналитика стрелки механизма могут не изображаться на модели;

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

Для описания отношений между блоками в методологии IDEF0 требуется пять типов взаимодействий:

1)управление;

2)вход;

3)обратная связь по управлению;

4)обратная связь по входу;

5)выход–механизм.

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

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

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

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

•непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением;

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

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

•непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния;

•помеченные перед слиянием ветви содержат все или некоторыеобъекты изперечисленных вобщей метке после слияния.

Диаграмма IDEF0 верхнего уровня приведена на рис. 2.3.

Заявка клиента Оформление заявки для биржи Контракт

Брокер

Рис. 2.3. Пример диаграммы IDEF0 верхнего уровня

Далее перечислим рекомендации по желательным значениям факторов диаграммы:

88Глава 2. Классические методологии построения …

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

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

2)диаграммы должны быть сбалансированы. Например, у работы число входящих стрелок и стрелок управления не должно быть существенно большим, чем число выходящих стрелок.

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

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

Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания;

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

2.2.4.Методология моделирования и стандарт документирования процессов IDEF3

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставля-

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

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

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

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

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

•разрабатывать имитационные модели технологических процессов по принципу «Как будет, если...».

Существуют два типа диаграмм в стандарте IDEF3, пред-

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

1) диаграммы PFDD (Process Flow Description Diagrams) —

диаграммы описания последовательности процессов;