Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

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

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

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

В методологии IDEF0 существует соглашения по размещению стрелок:

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

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

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

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

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

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

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

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

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

• расстояние между блоками и поворотами стрелок должно быть максимально возможным (с учетом габаритов диаграммы), что позволяет облегчить процесс чтения и уменьшить веро-ятность перепутать две разные стрелки;

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

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

• обратные связи по входу вычерчиваются «вниз и под» («нижняя» петля), что позволяет ука-зать обратные потоки данных при минимальном числе линий и пересечений, а также собрать все входные стрелки в левой нижней части диаграммы;

• обратные связи посредством механизма должны быть показаны как «вниз и под»;

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

• иногда разрешается выделять буферы и повторно используемые объекты;

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

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

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

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

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

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

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

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

Основу методологии IDEFO составляет графический язык описания процессов в виде иерархии функциональных схем, называемых функциональными диаграммами. Модель системы в нотации IDEFO – это совокупность иерархически упорядоченных и логически связанных диаграмм модели, созданных на основе ранее определенного субъекта, цели и точки зрения, каждая из которых имеет название, располагающееся в центре нижней части ее бланка/каркаса, при этом, чем выше уровень диаграммы, тем она менее детализирована. ДИАГРАММА – это основная единица описания системы, расположенная на отдельном листе и имеющая собственные синтаксические правила, отличающиеся от синтаксических правил описания модели. Диаграмма представляет собой тщательно согласованный набор взаимосогласованных описаний, начиная с описания системы самого верхнего уровня и кончая подробным описанием деталей или операций системы, позволяющих определить различные системные функции и показать взаимосвязь и взаимное влияние этих функций. К назначению создаваемых диаграмм можно отнести то, графическое изображение модели является предметом экспертизы, т. е. обсуждение диаграммы со специалистами конкретной предметной области. В рамках методологии IDEF0 модель процесса описывается при помощи IDEF0 диаграмм, которые являются графическим представлением знаний экспертов о моделируемой системе. С одной стороны описывая процессы на естественном языке, эксперты не испытывают трудностей при определении процессов и объектов. С другой стороны, аналитик, используя при разработке диаграмм графическую нотацию IDEF0, дает более лаконичное и однозначное описание процессов, не жертвуя при этом его качеством. Таким образом, в ходе разработки диаграмм знания экспертов структурируются, и устраняется неоднозначность описаний за счет:

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

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

Контекстная диаграмма - вид IDEF0-диаграммы. Это диаграмма, расположенная на вершине древовидной структуры диаграмм, представляющая собой самое общее описание системы и ее взаимодействие с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). Контекстная диаграмма состоит из одного блока, описывающего функцию верхнего уровня, ее входы, выходы, управления, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель. Контекстная диаграмма A-0 должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиции которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Согласно стандарту IDEF0 на каждом уровне декомпозиции должен использоваться принцип ограничения объекта, поэтому в соответствии с этим принципом считается, что единствен-ный блок и несколько стрелок на самом верхнем (контекстном) уровне используются для определения границы всей системы. Соответственно, стрелки, касающиеся этого блока, описывают главные управления, входы, выходы и механизмы этой системы. В дальнейшем, текстовое описание, содержащее основные типы объектов и функции и комментарии экспертов, используется для предварительного создания диаграммы А0. Стрелки на контекстной диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представля-ют полный комплект внешних интерфейсов объекта. Контекстная диаграмма имеет узловой номер A-n (n?0), которая представляет кон-текст модели. Диаграмма верхнего уровня обозначается идентификатором «А-0» (произно-сится «А минус ноль»), на которой объект моделирования представлен единственным блоком с граничными стрелками, устанавливает область моделирования, определяет границы модели и является обязательной контекстной диаграммой. Диаграммы с узловыми номерами А-1, A-2,... - дополнительные контекстные диаграммы. В пояснительном тексте к контекстной диаграмме указывается цель (Purpose) построения диаграммы в виде краткого описания и фиксированная точка зрения (Viewpoint). Именно с помощью контекстной диаграммы определяется субъект моделирования, т.е. что будет в дальнейшем рассматриваться как элементы/компоненты системы, а что - как внешняя среда/воздействие. Имя функции, записываемое в блоке контекстной диаграммы, является общей функцией системы с принятой точки зрения и определенной целью построения модели. Детализируя рассматриваемую систему на этапе сбора и анализа предварительной информации, необходимо обращать внимание на входные и выходные объекты самой системы и составляющих ее подсистем. Моделирование необходимо начинать с составления описания основных типов объектов и основных функций системы. При этом необходимо учесть нормальные и аномальные ситуации, имеющиеся в системе обратные связи, и возможные случаи потенциальных ошибок.

Разработка контекстной диаграммы включает определение:

• субъекта моделирования - определение, что входит в состав модели, а что из нее исключено;

• цели, как критерия окончания моделирования;

• точки зрения модели, как определение объема, состава информации и формы подачи ин-формации;

• ограничений, налагаемые на объект;

• построение диаграммы верхнего уровня и ее обобщение.

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

• ширина - это границы модели. Ширина модели определяет, что будет рассматриваться внутри системы, а что снаружи;

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

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

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

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

• составляет список функций;

• преобразует функции в блоки;

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

• создает диаграмму декомпозиции.

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

ДИАГРАММЫ ДЕКОМПОЗИЦИИ предназначены для детализации функций и получаются при разбиении контекстной диаграммы на крупные подсистемы (функциональная декомпозиция) и описывающие каждый подсистему и их взаимодействие. Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня, на которой некоторые или все функции также могут быть разложены на составные части. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока. Хотя действительной вершиной модели является диаграмма уровня А-0, настоящей «рабочей вершиной» является диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели проекта. Нижние уровни уточняют содержание функциональных блоков, детализируя их, но, не расширяя границ модели. По методологии IDEF любая декомпозиция начинается с создания и изучения диаграммы АО с целью определения блока, декомпозиция которого выявит основные аспекты диаграммы АО и будет оказывать большое влияние на декомпозиции других блоков этой диаграммы. При выборе такого самого содержательного блока желательно учитывается доминирование, функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. После построения диаграммы А0, ее данные обобщаются на диаграмме А-0. Для получения хорошей основы для декомпозиции имеет смысл несколько раз переключиться с проработки диаграммы А-0 на диаграмму А0 и обратно. В дальнейшем производится декомпозиция каждой подсистемы на более мелкие и так далее, до достижения нужного уровня подробности описания. Диаграммы обычно состоят из 3-6 блоков, каждый из которых потенциально может быть детализирован на диаграмме декомпозиции, поэтому блок может пониматься как отдельный тщательно определенный объект (подсистема). Правило «от трех до шести» размещаемых на одной диаграмме блоков связано с тем, что мощность краткосрочной памяти человека ограничена восприятием примерно семи категорий, каждая из которых может содержать около семи отдельных единиц информации. Именно поэтому IDEF0 рекомендует в качестве верхнего предела декомпозиции создавать шесть блоков - по одному на категорию, поэтому диаграммы создаются так, чтобы не подвергать испытанию пределы краткосрочной памяти человека. Однако опыт показывает, что по объему информации приближаются к оптимальным диаграммы из 4-5 блоков с не более чем пятью стрелками, касающимися каждого блока. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее подсистемы одинаков во всей модели. Диаграммы декомпозиции должны содержать только родственные функции/задачи, т. е. дочерние функции, имеющие общую родительскую функцию. Декомпозиция единственной функции на одну функцию не производится. Первые шаги представляют для автора особую трудность, поскольку требуют, поддерживая определенный уровень абстракции описания системы, следить за постепенным углублени-ем модели по направлению к более подробным уровням детализации. При детализации, декомпозируя каждый блок диаграммы А0, необходимо более подробно отражать то, что представлено на родительском блоке. Это может потребовать дополнительного сбора информации о моделируемой системе. Поэтому, сделав предварительный эскиз диаграммы-потомка, необходимо перечислить все объекты и уточнить перечень функций, вы-полнения которых обеспечит выполнение функции, описанной в родительском блоке. Имея неструктурированные перечни объектов и функций, приступают к прорисовке отдельных блоков и соединению их при помощи стрелок. Скорее всего, первоначально созданную диаграмму придется несколько раз модифицировать, разбивая ее блоки на части или объединяя их, чтобы добиться максимальной наглядности. Для более точного отображения деталей и выяснения “узких мест”, требующих уточнения, лучше создавать сразу от 2 до 4 диаграмм, отслеживая, таким образом, их взаимосвязи. Диаграмме может быть поставлен в соответствие структурированный текст, представляющий собой краткий комментарий к содержанию диаграммы. Текст, относящийся к представленной диаграмме, поясняет, каким образом она соответствует поставленным целям и точке зрения, делая материалы более понятными для читателей. При этом текст лаконично описывает процесс, представленный именно на текущей диаграмме, не дублируя то, что очевидно из ее содержания. Текст используется для объяснений и уточнений характеристик, потоков и т.д. Текст не должен использоваться для описания и без того понятных блоков и стрелок на диаграммах. По окончанию создания диаграммы к ней, как правило, прилагаются сопроводительный текст, глоссарий и иногда FEO диаграмма. Для обеспечения наглядности диаграмм, а, следовательно, и графических изображений модели рекомендуется, чтобы каждая функция/блок на любой диаграмме должна быть декомпозирована в виде диаграммы из 3-6 блоков на следующем уровне с целью более подробного раскрытия его содержания. Эти ограничения позволяют осуществить детализацию постепенно с обеспечением сложности диаграмм и модели на уровне, доступном для чтения, понимания и использования. Таким образом, вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта.