1. CASE-средства и их
применение
в процессе разработки
информационных систем
Стандарты моделирования IDEF
Язык UML
2. Область применения
методологий IDEF
Автоматизация бизнеса: построение информационной
системы
• Выполняемые функции • E-R диаграммы
• Пользовательский интерфейс • Структура файлов и БД
• Диаграммы потоков данных • Передача данных
• Модульная структура системы • Структура сети
• Выбор архитектуры
• Оснащение аппаратно-
программными средствами
• Разработка новой системы
3. Бизнес-модель
предприятия
1 2 3
Базовые компоненты бизнес-модели
бизнес-функции (1) фазы
бизнес-процессы (2) роли
организационная структура (3) правила
4. Семейство стандартов IDEF
IDEF0 функциональное моделирование
моделирование информационных потоков
IDEF1 внутри системы
IDEF1X построение реляционных структур
IDEF2 динамическое моделирование развития систем
IDEF3 описание бизнес-процессов
IDEF4 построение объектно-ориентированных систем
IDEF5 онтологическое исследование сложных систем
5. Методология IDEF0
1 2
Основные понятия IDEFO
диаграмма (diagram) декомпозиция (decomposition)
функциональный блок (activity box) 1 точка зрения (viewpoint)
интерфейсная дуга (arrow) 2 туннелирование (tunneling),
туннель (tunneled arrow)
глоссарий (glossary)
18. Соединения
1 X & 2
разворачивающее соединение соединение «эксклюзивное ИЛИ»
(fan-out junction) (1)
1 (XOR junction) (X)
X
сворачивающее соединение соединение «И» (AND junction) (&)
&
(fan-in junction) (2)
2
19. Соединения
O
соединение «ИЛИ» (OR junction) (O)
O
Термин IDEF (Integrat ion Definition) - это сокращение от англоязычного словосочетания I-CAM Definition Methods , обозначающее методы описания для I-CAM . I-CAM - это сокращённое название проекта Integrated Computer-Aided Manufacturing , обозначающее комплексно автоматизированное производство. IDEF – это семейство стандартов моделирования бизнес-процессов, в основу которого была положена методология SADT (Structured Analysis and Design Technique) . Семейство IDEF объединяет 15 стандартов ( IDEF0-IDEF14) , первым из которых был разработан стандарт IDEF0 ( 1981 г. ) . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993 года Национальным Институтом По Стандарам и Технологиям США (NIST). UML (Unified Modeling Language) или Унифицированный язык моделирования позволяет специфицировать, визуализировать, конструировать и документировать артефакты систем программного обеспечения, а также моделировать предпринимательскую деятельность и другие системы, не имеющие отношения к программному обеспечению.
Область применения методологий IDEF Новаторство методологий IDEF заключается в том, что в фокусе IDEF находятся не структурные единицы и не функции, а процессы . Исследование и моделирование процессов существенно сокращает время и затраты на разработку и упрощает процедуру принятия решений. Цели, которых позволяет достичь IDEF : Снизить производственные издержки и повысить качество продукции (услуг) за счет совершенствования внутренних процессов в компании. Получить количественную оценку влияния эффективности работы того или иного бизнес-процесса на получаемую прибыль. Повысить эффективность принятия решений (предоставить точную картину, дать четкое обоснование для принимаемого решения, и сократить время, требуемое для принятия решения). Полностью автоматизировать бизнес-процессы от начальной стадии до внедрения. Эффективно управлять бизнес-процессами Построение информационной системы Цель : четкая и правильно понимаемая постановка задачи при подготовке проекта построения информационной системы. Для этого необходимо исследовать все происходящие финансово-хозяйственные процессы и соответствующие им потоки информации на предприятии, выявить те из них, которые должны быть реорганизованы в первую очередь. Для этого выполняется предпроектное обследование предприятия, в процессе которого составляется бизнес-модель . Бизнес-модель предприятия — это совокупность графических и текстовых описаний, позволяющих описать процесс управления предприятием. Иными словами, бизнес-модель является отображением предприятия и его информационно-управляющей системы. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, что и как должна делать автоматизированная система. Обычно бизнес-модель формируется в целях усовершенствования процесса управления, когда руководство понимает, что предприятие должно перейти на новую ступень развития, например повысить качество производимой продукции или оказываемых услуг, выйти на внешний рынок и т. п. Создание бизнес-модели начинается с понимания, какие элементы существуют в данном бизнесе, т.е. с описания оргструктуры компании. Далее, нас интересует система взаимодействия между ее элементами . Основные виды такого взаимодействия: Административное Финансовое Материальное (товарное) Информационное Коммуникационное
В основе бизнес-модели всегда лежат бизнес-цели предприятия , определяющие состав всех базовых компонентов бизнес-модели. бизнес-функции , описывающие, ЧТО делает бизнес; бизнес-процессы , описывающие, КАК предприятие выполняет свои бизнес-функции; организационная структура , определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы; фазы , определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции; роли , определяющие, КТО исполняет бизнес-процессы; правила , определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО. Описание бизнес-процессов, как наиболее трудоемкая и чреватая ошибками задача, нуждается в конкретной методологической платформе. Поэтому существует наиболее устоявшийся перечень атрибутов, которые модель бизнес-процессов должна описывать на изобразительном уровне, а именно: воздействия , инициирующие каждый шаг бизнес-процесса; исполнители каждого шага (это могут быть как люди, так и программы и механизмы); воздействия , регламентирующие данный шаг (законодательные акты, рыночные условия и т. п.); результат , получаемый на выходе конкретного шага бизнес-процесса. Существуют следующие категории бизнес-процессов: процессы, непосредственно обеспечивающие выпуск продукции; процессы планирования и управления; ресурсные процессы; процессы преобразования. Бизнес-процесс характеризуется: существующей технологией реализации бизнес-процесса; существующей структурой бизнес-системы ; средствами автоматизации, оборудованием, механизмами и т.п., обеспечивающими реализацию процесса .
В настоящий момент к семейству IDEF можно отнести следующие стандарты: IDEF0 - методология функционального моделирования. Представление изучаемой системы в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0) с помощью наглядного графического языка. Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать структуру информационных потоков и взаимосвязи между ними; IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “сущность-связь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных , имеющих отношение к рассматриваемой системе; IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets); IDEF3 – методология документирования процессов , происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях . С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса . IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3; IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия , тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы ; IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил , на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени . На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.
Основные понятия методологии функционального моделирования IDEF0 Функциональный блок графически изображается в виде прямоугольника и представляет определенную функцию в рамках рассматриваемой системы. По требованиям стандарта для именования каждого функционального блока используются глаголы (например, “производить услуги”, а не “производство услуг”). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль): Верхняя сторона имеет значение “ Управление ” (Control); Левая сторона имеет значение “ Вход ” (Input); Правая сторона имеет значение “ Выход ” (Output); Нижняя сторона имеет значение “ Механизм ” (Mechanism). Для типизации категорий информации на IDEF0- диаграммах используется аббревиатура ICOM ( Input – Output – Control - Mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Также интерфейсные дуги часто называют потоками или стрелками. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть формой существительного. С помощью интерфейсных дуг отображают различные объекты, определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся. Любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения ( v iewpoint). Определение и формализация цели разработки модели IDEF0 является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек. Точка зрения определяет основное направление развития модели и уровень необходимой детализации . Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней ( c hild diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – c hild b ox). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме ( p arent b ox), а диаграмма, к которой он принадлежит – родительской диаграммой ( p arent d iagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует. Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. Такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”. Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента . Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий дополняет графический язык, снабжая диаграммы необходимой информацией.
В IDEFO существует пять основных видов комбинированных стрелок: выход — вход (1) , выход — управление (2) , выход — механизм исполнения (3) , выход — обратная связь на управление (4) и выход — обратная связь на вход (5) . 1 Комбинация стрелок выход — вход Такая комбинация стрелок применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. 2 Комбинация стрелок выход — управление Стрелка выход — управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. 3 Комбинация стрелок выход — механизм исполнения Стрелки выход — механизм исполнения встречаются реже и отражают ситуацию, когда выход одного функционального блока применяется в качестве инструментария для работы другого блока. 4 Комбинация стрелок выход — обратная связь на вход Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. 5 Комбинация стрелок выход — обратная связь на управление Стрелка выход — обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо. Кроме того, связи выход — обратная связь на вход могут применяться в случае, если бракованная продукция может заново использоваться в качестве сырья, как это происходит, например, в процессе производства оконного стекла, когда разбитое стекло перемалывается и переплавляется заново вместе с исходным сырьем.
Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность IDEFO заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соответственно IDEFO предусматривает как разъединение, так и соединение стрелок на диаграмме. Разъединенные на несколько частей стрелки могут иметь наименования, отличающиеся от наименования исходной стрелки. Исходная и разъединенные (или объединенные) стрелки в совокупности называются связанными . Такая техника обычно применяется для того, чтобы отразить использование в процессе только части сырья или информации, обозначаемой исходной стрелкой. Аналогичный подход применяется по отношению к объединенным стрелкам. Пояснения к Рис. 1 1 Разъединение стрелок (1) означает, что «Записи» содержат «Данные о клиенте» (необходимые для функции 2) и «Справочные таблицы Налоги и Цены » (необходимые для функции 3). 2 Соединение стрелок (2) означает, что «Записи в бухгалтерской книге» составляются на основании Доставленной продукции и Выставленных счетов.
Функциональный блок декомпозируется, если необходимо детально описать его работу. При декомпозиции блока полезно рассмотреть его жизненный цикл, это поможет определить функциональные блоки получающейся "детской" диаграммы. Например, жизненный цикл блока "Поджарить бифштекс" может выглядеть как следующая последовательность: "Подготовить продукты", "Отбить мясо", "Подогреть масло" и т.д. При IDEFO -моделировании важно иметь в виду, что граница детской диаграммы есть граница родительского функционального блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличие от иерархии, применяемой в структурном программировании, блоки верхнего уровня не являются субъектами управления для блоков нижнего уровня. Это означает, что в IDEFO потомки — это те же самые объекты, что и их родители, только показанные с большей детализацией. На концах граничных стрелок (начинающихся или заканчивающихся за пределами диаграммы) диаграмм-потомков помещаются коды ICOM, чтобы показать, где находится соответствующая стрелка на родительской диаграмме (рис. 2). Они нужны для проверки целостности модели и могут быть полезны, когда порядок расположения стрелок на диаграмме-потомке отличается от порядка их размещения на родительской диаграмме. Код ICOM состоит из латинской буквы I, С, О или М и числа, показывающего расположение стрелки на родительской диаграмме в порядке сверху вниз (для стрелок I и O ) или слева направо (для стрелок С). Связь между диаграммой и ее родительским функциональным блоком Рис. 1 1 – Вход ( Input ) 2 – Выход ( Output ) 3 – Управление ( Control ) Рис. 2 Пунктиром показано соответствие интерфейсных дуг I, C, O на родительской и дочерней диаграмах. Применение кодов ICOM позволяет избежать путаницы в тех случаях, когда на родительской диаграмме и диаграмме-потомке стрелки имеют разные роли (см. Рис. 2: стрелка C1 является обозначает управление на родительском функциональном блоке и вход – на диаграмме-потомке. Когда какой-либо блок на родительской диаграмме детализируется с помощью дочерней диаграммы, то все интерфейсные дуги, относящиеся к родительскому блоку, должны быть отображены на дочерней диаграмме (исключение составляет случай, если стрелка родительского блока туннелируется: туннелируемые стрелки не показываются на дочерних диаграммах). Два подхода к началу моделирования ("в ширину" и "в глубину") Модели могут проектироваться как с использованием подхода "в ширину", когда каждая диаграмма максимально детализируется перед своей декомпозицией, так и с подходом "в глубину", когда сна-чала определяется иерархия блоков, а затем создаются соединяющие их стрелки. D озможно применение комбинации этих подходов, причем иерархия блоков может иногда немного меняться после того, как нарисованы стрелки. Это происходит в случае, когда создание стрелок может изменить понимание внутренней архитектуры моделируемого объекта. Когда остановиться Сформулированная цель моделирования содержит вопросы, на которые должна отвечать модель. Когда построенная модель позволяет получить ответы на них, тогда модель считается удовлетворяющей поставленным требованиям и рассматривается как завершенная. При декомпозиции первого уровня нужно следить за тем, чтобы все блоки на диаграмме лежали внутри определенных ранее границ моделирования. Перед декомпозицией блока нужно удостовериться, не приведет ли это к превышению установленной ранее глубины детализации данной модели. Еще одно правило состоит в том, что IDEFO -моделирование должно продолжаться до тех пор, пока стрелки предшествования (вход и выход) преобладают на диаграммах. При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3.
Элементы заголовка диаграммы: USED AT – используется для внешних ссылок на данную диаграмму (заполняется на печатном документе вручную) AUTHOR, DATE, PROJECT – содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась NOTES 1 ... 10 – при ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление Status: – отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса итерации пересмотра и утверждения Status: может принимать одно из следующих значений: working – новая диаграмма, глобальные изменения или новый автор для существующей диаграммы draft – диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение recommended – диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся publication – диаграмма готова для окончательной печати и публикации READER – ФИО читателя DATE – дата знакомства читателя с диаграммой CONTEXT – схематическое изображение функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР NODE – номер диаграммы, совпадающий с номером родительского функционального блока TITLE – имя родительского функционального блока NUMBER (C-NUMBER) – Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую, номер заменяемой диаграммы может быть заключен в скобки - SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели. Дисциплина групповой работы над разработкой IDEF0-модели Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов: Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели. Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе). Цикл эксперт — аналитик IDEFO -диаграммы пересматриваются и изменяются подобно циклу автор — редактор, применяющемуся в книгоиздат тельском деле. Для каждого рецензента автором, как правило, подготавливается свой набор диаграмм. Предложения по изменениям и исправлениям рецензенты возвращают автору для внесения их в модель. При возникновении разногласий между автором и рецензентом спорная диа-грамма обычно рассылается всем рецензентам для достижения консенсуса. Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм, контроль истории изменений — полем Field . Принципы ограничения сложности IDEF0-диаграмм Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности: Ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание; Ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя. Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе. Особенности применения функционального моделирования средствами IDEF0 При проведении сложных проектов обследования предприятий, разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия в нужном разрезе. Однако самое главное – это возможность коллективной работы, которую предоставляет IDEF0. В моей практической деятельности было достаточно много случаев, когда построение модели осуществлялось с прямой помощью сотрудников различных подразделений. При этом, консультант за достаточно короткое время объяснял им основные принципы IDEF0 и обучал работе с соответствующим прикладным программным обеспечением. В результате, сотрудники различных отделов создавали IDEF-диаграммы деятельности своего функционального подразделения, которые должны были ответить на следующие вопросы: Что поступает в подразделение “на входе”? Какие функции, и в какой последовательности выполняются в рамках подразделения? Кто является ответственным за выполнение каждой из функций? Чем руководствуется исполнитель при выполнении каждой из функций? Что является результатом работы подразделения (на выходе)? После согласования черновиков диаграмм внутри каждого конкретного подразделения консультант использует эти черновики для составления черновой модели предприятия, в которой увязываются все входные и выходные элементы. На этом этапе фиксируются все неувязки отдельных диаграмм и их спорные места. Далее эта модель вновь проходит через функциональные отделы для дальнейшего согласования и внесения необходимых корректив. В результате за достаточно короткое время и при привлечении минимума человеческих ресурсов со стороны консультационной компании получается IDEF0-модель предприятия по принципу “как есть”, причем она представляет предприятие с позиции сотрудников, которые в нем работают и досконально знают все нюансы, в том числе неформальные. В дальнейшем эта модель будет передана на анализ и обработку к бизнес-аналитикам, которые будут заниматься поиском “узких мест” в управлении компанией и оптимизацией основных процессов, трансформируя модель “Как есть” в соответствующее представление “Как должно быть”. На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации сисемы управления.
С помощью методологии SADT на основе технологий аудиторской компании "BDO Руфаудит" была создана обобщенная схема процесса проведения аудиторской проверки, начиная с преддоговорной организационной работы и заканчивая представлением аудиторского заключения. Целью данной работы является последовательное описание аудиторского процесса в максимально доступном и информативном изложении. Она может быть использована как для оптимизации аудита, управления им на высоком профессиональном уровне, так и для ознакомления заинтересованного пользователя-неспециалиста. Работа над описанием технологии аудиторского процесса ведется достаточно давно. Какие же методы могут быть применены? Словесный метод — часто используемый. Однако он всегда несет в себе элемент субъективности. Составление блок-схем позволяет доступнее представить процесс. Однако по сравнению с блок-схемами диаграммы функционального моделирования обладают явными преимуществами. Они позволяют показать мотивацию и ограничивающие факторы, особенности механизма реализации, в них четко прослеживается итеративность. Уже на начальном этапе SADT -моделирования мы задаем цели, которые необходимо достичь, определяем исполнителей, указываем имеющиеся исходные данные и ресурсы, а также различного рода ограничения.
Любой процесс может быть описан с различной степенью детализации. Таким образом, схемы разных уровней являются расшифровкой элементов более общих схем и подробно описывают тот или иной этап. Так, ознакомление с деятельностью клиента является частью разработки стратегии проведения аудиторской проверки (диаграммы АО и А2). Кроме того, схема более низкого уровня сохраняет все внешние связи элемента родительской схемы, который она детализирует. Результаты некоторых стадий могут стать руководством к действию для последующих этапов. Так, бюджет времени проверки, установленный партнером в процессе предварительной экспертизы клиента, определяет разработку стратегии проверки клиента. Другие промежуточные результаты являются основным материалом для следующих стадий аудиторского процесса. Например, на основе выводов, сделанных аудиторами в ходе проверки, составляется аудиторская отчетность (диаграмма АО).
Возможны также обратные связи: при промежуточной оценке результатов принимается решение о корректировке направлений проверки, что приводит к изменению стратегии аудита и новому планированию (диаграммы АО и A3).
МОДЕЛИРОВАНИЕ УПРАВЛЕНЧЕСКОГО УЧЕТА НА ПРЕДПРИЯТИИ Постановка задачи В условиях конкуренции руководству предприятия требуется оперативная информация для принятия решений. Финансовая отчетность предоставляет лишь часть необходимой информации в виде ограниченного круга обобщенных стоимостных показателей. Бухгалтерский учет в первую очередь предназначен для предоставления информации для внешних пользователей. Этим обусловлено наличие нормативных требований к его ведению (документирование, стандартные методы и формы отчетности). Функцию обеспечения руководства предприятия необходимой информацией выполняет управленческий учет, который не регламентируется законодательно, а определяется, прежде всего, целями предприятия. Институт дипломированных бухгалтеров в области управления (Charted Institute of Management Accountants) определяет управленческий учет как деятельность по обеспечению руководства информацией, которая необходима для управления предприятием с максимально возможной степенью эффективности. Информация, которую обеспечивает управленческий учет, может быть представлена в любой форме по выбору руководства. В большинстве работ по управленческому учету как российских, так и иностранных авторов описываются его отдельные элементы: методики учета и распределения затрат, учет по центрам ответственности, система управленческой отчетности и другие, но не дается целостного представления о бизнес-процессе, что затрудняет их использование для организации управленческого учета на предприятии. Восполнить этот пробел можно с помощью разработки модели данного процесса. Основные элементы модели управленческого учета Название проекта: организация управленческого учета на предприятии. Цель проекта: подготовить рабочую модель бизнес-процесса управленческого учета для внедрения на предприятии. Точка зрения: руководство предприятия. Инструментарий: методология функционального моделирования IDEFO и программное приложение BPwin I.8.O. Список данных: • потребность в управленческой информации; • стратегия предприятия; • управленческая информация; • информационная система; • финансовая функция; • центры ответственности; • руководство предприятия; • данные; • методология управленческого учета; • финансовая отчетность; • обработанные данные; • стратегия управленческого учета; • имеющиеся ресурсы; • квалификация персонала; • первичные документы; • данные в информационной системе; • подтвержденные данные; • отчетность в разрезе центров ответственности; • сводная отчетность; • отчетность по требованию. Перечень функций В модели использованы следующие функции: организовать управленческий учет — АО; разработать методологию управленческого учета — А1: определить стратегию управленческого учета — АН, оценить имеющиеся ресурсы — А12, разработать приемы и методы управленческого учета — А13; собрать и обработать данные — А2: получить и ввести данные — А21, подтвердить данные — А22, обработать данные — А23; подготовить управленческую отчетность — A3: подготовить отчетность по центрам ответственности — A31, составить сводную отчетность — A3 2, подготовить отчетность по требованию — АЗЗ. Словарь Данные — факты, характеризующие деятельность предприятия, подлежащие количественному выражению. Данные в информационной системе — данные, введенные в информационную систему и сгруппированные по аналитическим признакам. Имеющиеся ресурсы — персонал и информационная система в распоряжении предприятия. Информационная система — совокупность программных приложений, баз данных, используемых для управления предприятием. Квалификация персонала — совокупность знаний, умений и навыков персонала в конкретной профессиональной области. Методология управленческого учета — совокупность приемов и методов ведения управленческого учета. Обработанные данные — данные, распределенные по объектам учета и центрам ответственности. Отчетность в разрезе центров ответственности — стандартная управленческая отчетность, составленная для каждого центра ответственности. Эта отчетность используется руководителями центров ответственности для принятия решений в рамках их должностных полномочий. Отчетность по требованию — управленческая отчетность нестандартной формы, используемая для пояснения стандартной отчетности. Первичные документы — документы, подтверждающие факты совершения хозяйственных операций, оформленные в соответствии с действующим законодательством и нормативными актами. Подтвержденные данные — данные, соответствующие первичным документам. Данные в информационной системе, обозначенные как соответствующие первичным документам. Потребность в управленческой информации — обоснованная необходимость получения управленческой информации. Руководство предприятия — должностные лица, несущие конечную ответственность за принимаемые ими управленческие решения в пределах своей компетенции. Сводная отчетность - - стандартная управленческая отчетность, характеризующая деятельность предприятия в целом. Деятельность центров ответственности представлена обобщающими показателями. Стратегия предприятия — совокупность целевых ориентиров, определяющих деятельность предприятия в долгосрочном периоде. Стратегия управленческого учета — формализованные потребности руководства предприятия в управленческой информации. Управленческая информация — информация, необходимая для принятия управленческих решений. Управленческая отчетность -- управленческая информация, представленная в удобной для чтения форме. Может быть стандартной, подготавливаемой регулярно в установленной форме, и нестандартной, подготавливаемой по требованию. Управленческий учет — деятельность по обеспечению руководства предприятия информацией, необходимой для принятия управленческих решений. Финансовая отчетность — агрегированная отчетность, подготавливаемая на регулярной основе для внешних пользователей информации. Требования к составу, порядку составления и срокам предоставления финансовой отчетности устанавливаются законодательством или стандартами бухгалтерского учета. Финансовая функция — бухгалтерия и финансовые подразделения предприятия. Центры ответственности — структурные сегменты предприятия, руководители которых несут ответственность за конкретные показатели деятельности (например, руководитель центра затрат отвечает за затраты своего сегмента, руководитель центра прибыли — за затраты и выручку и т.д.) IDEFO -диаграммы модели управленческого учета Контекстная диаграмма модели управленческого учета
Декомпозиция первого уровня А1. Определить цели управленческого учета. На этом этапе разрабатывается методология управленческого учета, которая контролирует следующие этапы. От его организации во многом зависит успешность процесса управленческого учета в целом. А2. Собрать и обработать данные. На этом этапе готовятся данные, составляющие основу управленческой информации. A3. Подготовить управленческую отчетность На этом этапе формируется управленческая отчетность. При хорошо разработанной методологии отчетность может формироваться автоматически. Роль финансовой функции как механизма зависит от возможностей информационной системы.
Одна из декомпозиций второго уровня ( A3 ) Декомпозиция первого уровня А1. Определить цели управленческого учета. На этом этапе разрабатывается методология управленческого учета, которая контролирует следующие этапы. От его организации во многом зависит успешность процесса управленческого учета в целом. А11. На первом этапе декомпозиции руководством определяется стратегия управленческого учета на основе потребностей в управленческой информации. Его задача – формализовать потребности и увязать их со стратегией предприятия. А12. На следующем этапе определяются ресурсы для реализации стратегии управленческого учета, оценивается эффективность стратегии с точки зрения затрат имеющихся ресурсов и необходимость привлечения дополнительных ресурсов. А13. На третьем этапе стратегия трансформируется в конкретные приемы и методы ведения управленческого учета с учетом ресурсов, имеющихся в распоряжении предприятия. А2. Собрать и обработать данные. На этом этапе готовятся данные, составляющие основу управленческой информации. А21. Данные собираются и вводятся в информационную систему непосредственно центрами ответственности, что обеспечивает оперативность поступления информации. Состав данных, аналитические признаки и сроки их учета определяются методологией. А22. По мере поступления первичных документов бухгалтерия подтверждает данные в информационной системе. В случае расхождений данные корректируются на основе первичных документов. Подтвержденные данные используются для составления финансовой отчетности. А23. Данные в информационной системе распределяются по объектам учета и центрам ответственности. При наличии достаточной аналитики это осуществляется автоматически. A3. Подготовить управленческую отчетность На этом этапе формируется управленческая отчетность. При хорошо разработанной методологии отчетность может формироваться автоматически. Роль финансовой функции как механизма зависит от возможностей информационной системы. A31. Распределение данных по объектам учета и центрам ответственности позволяет сформировать отчетность в разрезе центров ответственности. Форма отчетов и сроки их представления определяются методологией. А32. Сводная отчетность формируется на основе консолидации отчетности центров ответственности и других обработанных данных. В части подтвержденных данных контрольные функции выполняет финансовая отчетность. АЗЗ. Отчетность по требованию также основана на обработанных данных. Поскольку ее формы не предусмотрены методологией, они предварительно разрабатываются соответствующими подразделениями.
IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев . Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи: Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса. Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов, по принципу "как будет, если..." В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. IDEF3 -моделирование органично дополняет традиционное моделирование с использованием стандарта IDEFO. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Аналогично другим технологиям моделирования действие, или в терминах IDEF3 функциональный элемент (unit of behavior — UOB), — важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя. Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В IDEF3 существует 3 типа связей: временное предшествование объектный поток нечеткое отношение Соединения используются в тех случаях, когда завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса. Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они используются при построении диаграммы для привлечения внимания пользователя к каким-либо важным аспектам модели. Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор . На слайде показан указатель типа ОБЪЕКТ. Далее мы перечислим возможные типы указателей : ОБЪЕКТ (OBJECT) – этот тип указателя служит для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект. ССЫЛКА (GOTO) – этот тип указателя служит для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению. ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior — UOB) – этот тип указателя служит для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчет наличных» выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB . ЗАМЕТКА (NOTE) – этот тип указателя служит для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах. УТОЧНЕНИЕ (Elaboration — ELAB) – этот тип указателя служит для уточнения или более подробного описания изображенного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соединений.
Временное предшествование (Temporal precedence): Исходное действие должно завершиться, прежде чем конечное действие сможет начаться Объектный поток (Object flow) : Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться Нечеткое отношение (Relationship) : Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения Связь типа «временное предшествование» Как видно из названия, связи этого типа показывают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого. Пример (1): автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу. Связь типа «объектный поток» Одна из наиболее часто встречающихся причин использования связи типа «объектный поток» заключается в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования: это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться. Пример: счет на оплату услуг является результатом выполнения предшествующего действия («принять счет»). Связь типа «нечеткое отношение» . Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Для связей этого типа должно быть определено значение каждой связи, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений — отображение взаимоотношений между параллельно выполняющимися действиями. Пример 3.2: фрагмент процесса запуска бензопилы с водяным охлаждением и нечеткое отношение между действиями «запустить двигатель» и «запустить насос». Название стрелки может быть использовано для описания типа отношения; для более подробного объяснения может использоваться отдельная ссылка. Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования. В примере 3.1 внесение исправлений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания принятия замечаний. Отметим еще раз необходимость четкого документирования временных ограничений между действиями, соединенными нечетким отношением. В качестве примера возьмем 3.1. Мы уже сопоставили начало внесения исправлений с началом получения замечаний от рецензентов, но вот относительно моментов окончания обоих процессов нужно сделать несколько особых замечаний. В отсутствие каких-либо дополнительных указаний возможны два варианта: Окончание процесса A1.1 предшествует окончанию процесса A1.2 Окончание процесса A1.1 следует после окончания процесса A1.2 Во втором случае внесение исправлений будет начато после получения первых замечаний, но закончится до того, как все замечания от рецензентов будут получены и обработаны. Оба рассмотренных выше варианта временной альтернативной шкалы могут иметь место, поэтому корректная интерпретация нечеткого отношения должна быть документирована в модели. Важно отметить, что корректность в этом случае означает именно интерпретацию, которая в точности отображает документируемую ситуацию, а не ее интерпретацию, более эффективную для работы системы с точки зрения аналитика.
Соединения представляют собой ограничения ( или следствия ограничений ) на логику активизации процесса . Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса: • разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других; • сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия. Все соединения в диаграммах нумеруются, каждый номер имеет префикс "J". Парность соединений . Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений не обязательно должны совпадать. Например, разворачивающее «и»-соединение может иметь парное сворачивающее «или»-соединение. Соединения бывают асинхронные и синхронные . На этой диаграмме представлены асинхронные соединения . «И»-соединения Соединения этого типа инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему «и»-соединению, должны завершиться, прежде чем начнется выполнение следующего действия. Соединение «эксклюзивное "или "» . Вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное «или», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное «или», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения .
Для асинхронных соединений: Соединение «И» Разворачивающее : Каждое конечное (следующее за ветвлением) действие обязательно инициируется Сворачивающее : Каждое исходное (предшествующее ветвлению) действие обязательно должно завершиться Соединение «Эксклюзивное «ИЛИ» Разворачивающее : Одно и только одно конечное действие инициируется Сворачивающее : Одно и только одно исходное действие должно завершиться Соединение «ИЛИ» Разворачивающее : Одно или несколько конечных действий инициируются Сворачивающее : Одно или несколько исходных действий должны завершиться
Синхронные и асинхронные соединения . В рассмотренных примерах связей «и» и «или» мы не затрагивали отношения между началом и окончанием действий, инициируемых разворачивающими соединениями. Все действия в этих примерах выполнялись асинхронно, т.е. они не инициировались одновременно. Однако есть случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно. Для моделирования такого поведения системы используются различные виды синхронных соединений. Синхронное соединение обозначается двумя вертикальными линиями внутри прямоугольника. Для синхронных соединений Соединение «И» Разворачивающее – Все действия начнутся одновременно Сворачивающее – Все действия закончатся одновременно Соединение «ИЛИ» Разворачивающее – Может быть, несколько действий начнутся одновременно Сворачивающее – Может быть, несколько действий закончатся одновременно Соединение «эксклюзивное «ИЛИ» Разворачивающее – Одновременное начало действий невозможно Сворачивающее – Одновременное окончание действий невозможно
Чтобы последовательность действий, изображенных на диаграмме, была правильной с логической точки зрения, необходимо уделять особое внимание используемым видам соединений. Не все виды соединений можно комбинировать произвольным образом. В частности, на рис. 2 изображена ситуация, когда после разворачивающего соединения XOR нельзя использовать сворачивающее соединение AND, т.к. это приведет к нарушению внутренней логики процесса (один из изображенных процессов не сможет быть активизирован). На рис. 2 после блока Получить предложение , разворачивающее соединение XOR ведет к двум блокам. Это означает, что только один из следующих блоков — Рассмотреть предложенную цену или Оценить с технической т. зрения — может быть активизирован, исходя из логики реализованной в данной схеме. Следовательно, блок Заключить контракт также не может быть реализован, поскольку не выполняется условие, что ОБА блока, предшествующие сворачивающему «И»-соединению, реализуются. Следует заметить, что тем не менее, подобная схема МОЖЕТ встречаться на реальной диаграмме, поскольку при описании процессов «как есть» модель бизнес-процессов не обязательно должна быть внутренне непротиворечивой. Возможно, в ситуации, изображенной на Рис. 2, ряд контрактов не был заключен именно по этой причине, и моделирование процесса в IDEF3 позволило обнаружить внутреннее противоречие в организации бизнес-процессов. Тем не менее, в описании процессов «Как должно быть» (TO-BE) предлагаемой в качестве основы для проектирования информационной системы или описания бизнес-процесса, не должно быть структур, аналогичных структуре, изображенной на Рис. 2. В реальном процессе моделирования регулярно проводится пересмотр и проверка диаграмм с целью выявить подобные ошибки.
Действия в IDEF3 могут быть декомпозированы или разложены на составляющие для более детального анализа. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели. Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.1.7: 1 — номер родительского действия, 1 — номер декомпозиции, 7 — номер действия.
Пример документирования альтернативных потоков процесса в одной модели. Далее будут представлены варианты декомпозиции блока 3.1.10 с точки зрения стороннего наблюдателя и с точки зрения менеджера проекта.
Декомпозиция блока 3.1.10 с точки зрения стороннего наблюдателя
Декомпозиция блока 3.1.10 с точки зрения менеджера проекта Требования IDEF3 к описанию бизнес-процессов Далее мы рассмотрим построение IDEF3 -диаграммы на основании выраженного в текстовом виде описания процесса. Предполагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспертов предметной области, представляющие описание процесса. Определение сценария, границ моделирования, точки зрения Для экспертов предметной области, подготавливающих описание моделируемого процесса, должны быть документированы границы моделирования, чтобы им была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от точки зрения эксперта, это должно быть ясно и подробно обосновано. Вполне возможно, что эксперты не смогут сделать приемлемое описание без их формального опроса автором модели. В таком случае автор должен заранее подготовить перечень вопросов таким же образом, как журналист для интервью. Определение действий и объектов Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может прилагаться письменная документация, позволяющая определить природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе. В некоторых случаях возможно создание графической модели процесса при участии экспертов. Такая модель может быть разработана после сбора всей необходимой информации, что позволяет, не отнимать время экспертов на детали форматирования получающихся диаграмм. Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий, что обеспечивает их независимость друг от друга. Пример В таблице номера действий выделяются каждому аналитику большими блоками. В этом примере аналитик Антонов И.П. полностью использовал данный ему вначале диапазон номеров и дополнительно получил второй.
В отличие от IDEFO, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD -диаграмм преобладают имена существительные. Контекстная DFD -диа-грамма часто состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы. Добавление на диаграмму внешних ссылок не изменяет фундаментального требования, что модель должна строиться с единственной точки зрения и иметь четко определенные цель и границы, что уже обсуждалось ранее. Функциональные блоки Функциональный блок DFD моделирует некоторую функцию, которая преобразует сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEFO и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEFO. В некоторых интерпретациях нотации DFD Гейна-Сарсона механизмы исполнения IDEFO моделируются как ресурсы и изображаются в нижней части прямоугольника. Внешние сущности Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель). Внешние сущности изображаются как отбрасывающие тень прямоугольники и обычно размещаются у краев диаграммы. Одна внешняя сущность может повторяться на одной и той же диаграмме несколько раз. Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме. Стрелки (потоки данных) Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEFO), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа «приказ—результат выполнения»). Двунаправленная стрелка обозначает взаимный обмен информацией (см. пример: обмен информацией происходит между департаментом маркетинга и рекламы и департаментом пластиковых карт). Хранилища данных В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки. В информационных системах хранилища данных представляют любой механизм, который поддерживает хранение данных для их промежуточной обработки.
Стрелки на DFD -диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть переименован таким образом, чтобы показать декомпозицию данных, переносимых конкретным потоком (рис. 1). Стрелки могут соединяться между собой (объединяться) для формирования так называемых комплексных объектов. Пример такого объединения приведен на рис. 2. Нумерация объектов В DFD каждый номер функционального блока может включать в себя префикс (1), номер родительской диаграммы (2) и собственно номер объекта (3) (рис. 3). Номер объекта уникальным образом идентифицирует функциональный блок на диаграмме. Номер родительской диаграммы и номер объекта в совокупности обеспечивают уникальную идентификацию каждого блока модели. Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположения объекта на диаграмме. Каждый номер хранилища данных содержит префикс D (Data Store) и уникальный номер хранилища в модели (например, D3). Аналогично, номер каждой внешней сущности содержит префикс Е (External entity) и уникальный номер сущности в модели (например, Е5).
ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ Два подхода к построению DFD -моделей Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEFO. Вначале строится модель физической реализации существующей системы, которая используется пользователями в настоящее время. Затем создается логическая модель для моделирования основных требований реальной системы. После этого формируется новая логическая модель для отражения основных параметров разрабатываемой системы. И наконец, создается новая физическая модель, реализующая логическую модель новой системы. В настоящее время при разработке информационных систем завоевывает все большую популярность альтернативный подход, известный как разделение событий, в котором для моделирования системы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система. Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемые внешними сущностями. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешние сущности (окружения), с которыми система взаимодействует. На заключительном этапе создается модель поведения, показывающая, как система обрабатывает те или иные события. Эта модель начинается с единственной диаграммы с одним функциональным блоком на каждый ответ системы на событие, описанное в модели окружения. Хранилища данных в модели поведения используются для моделирования данных, которые должны сохраняться в промежутках между обработкой событий. Потоки применяются для соединения элементов диаграмм между собой и для проверки согласованности моделей поведения и окружения. При подготовке такого рода моделей к различным презентациям обычно необходима их «чистка». При этом может применяться как создание упрощенных родительских диаграмм посредством объединения нескольких функциональных блоков в один, так и, наоборот, декомпозиция некоторых элементов для более легкого восприятия модели.
