Методология структурного анализа и проектирования информационных систем

Основные понятия IDEF0

Методология IDEF (I CAM Def inition) была разработана в рамках потребностей программы интегрированной компьютеризации производства (ICAM), предложенной NASA и направленной на увеличение производительности в промышленности посредством повсеместного внедрения компьютерных технологий. Подход, лежащий в основе программы ICAM, заключается в разработке структурных методов и использованию этих методов для лучшего понимания путей повышения производительности производства.

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

Уточним понятия среды и архитектуры с точки зрения методологии IDEF0. Целью программы ICAM была разработка «основных систем общего назначения», которые могут использоваться большим числом компаний для достижения прогресса в промышленности. Эти «подсистемы» должны были обеспечивать выполнение общих производственных функций, таких, как управление информацией, диспетчерская служба, материальное снабжение. Такая крупномасштабная цель нуждалась в некотором связующем базисе, вокруг которого осуществлялось бы планирование, разработка и внедрение подсистем в отдельных аэрокосмических компаниях. Этот базис был назван «архитектурой производства», так как это понятие отражало его современное состояние и являлось основой, опираясь на которую можно было бы спланировать, разработать и внедрить общие подсистемы.

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

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

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

Этот язык удовлетворяет следующим критериям:

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

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

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

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

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

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

В качестве методологии блочного моделирования была выбрана методология SADT.

IDEF0-методология основана на следующих концепциях:

1. Графическое представление блочного моделирования. Графика «блоков и дуг» IDEF0-диаграммы отображают производственную операцию в виде блока, а интерфейсы входа/выхода в/из операции представляются дугами, соответственно входящими в блок или выходящими из него. Для того чтобы иметь возможность описывать производственные операции, существующие в реальности, было предложено описывать взаимодействие блоков друг с другом посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом операции выполняются и управляются.

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

3. Передача информации. В IDEF0 существует ряд средств, разработанных для улучшения передачи информации:

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

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

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

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

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

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

- ограничение количества деталей на каждом уровне (правило 3-6 блоков);

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

- связность интерфейса диаграмм (номера узлов, номера блоков, C-номера);

- связность структуры данных (ICOM-коды и использование туннельных дуг);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- ограничение на ветвление дуг данных (метки для ограничений потоков данных на ветвях);

- разделение входов и управлений (правило определения роли данных);

- требования к меткам дуг данных (правила минимальных меток);

- минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга;

- цель и точка зрения (у каждой модели есть цель и точка зрения).

5. Методология. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач интеграции.

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

Вопросы для самопроверки

1. Что такое функциональная модель?

2. Что такое «архитектура производства»?

3. Что такое среда?

4. Назначение функциональной модели.

5. Когда IDEF-модель становится архитектурой?

6. Нотация IDEF-модели.

7. Каким критериям удовлетворяет язык блочного моделирования?

8. Концепции IDEF-методологии.

9. Графическое представление блочного моделирования.

10. Концепция краткости.

11. Концепция передачи информации.

12. Концепция строгости и четкости.

13. Концепция методологии.

14. Концепция организации из функций.

Основные понятия методологии SADT

Методология SADT (Structured Analysis and Design Technique) основана Россом в 1973 году и является методологией, ориентированной на описание процессов. С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах. Соответствующие модели принято называть функциональными (активностными) моделями и моделями данных.

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

Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом, чем выше уровень диаграммы, тем она менее детализирована.

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

Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающим функции. При этом каждая сторона блока имеет вполне определенное назначение: левая сторона предназначена для Входов (Input – I), верхняя – для Управления (Control – C),правая – для Выходов (Output – O), нижняя – для Механизмов (Исполнителей) (Mechanism - M).

рис.1 Пример SADT-диаграммы

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

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

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

рис.2 Изображение блоков на SADT диаграмме

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

В SADT требуются только пять типов взаимосвязей между блоками для описания их отношений: Управление, Вход, Обратная Связь по Управлению, Обратная Связь по Входу, Выход-Механизм.

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

рис.3 Отношение Управления рис.4 Отношение Вход

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

рис.5 Обратная связь по Управлению

рис.6 Обратная связь по Входу

Отношение Выход – Механизм отражают ситуацию, при которой Выход одной функции становится средством достижения цели другой функции.

рис.7 Отношение Выход - Механизм

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

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

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

SADT, как и другие методологии проектирования, целесообразно использовать на ранних этапах ЖЦ для понимания системы до ее воплощения. SADT позволяет сократить дорогостоящие ошибки на ранних этапах создания системы, улучшить контакт между пользователями и разработчиками, сгладить переход от анализа к проектированию Несомненное достоинство SADT заключается в том, что она легко отражает такие характеристики, как управление, обратная связь и механизмы.

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

1. Сбор информации.

2. Декомпозиция объекта исследования.

3. Моделирование:

3.1. Выбор цели о точки зрения.

3.2. Составление списка данных.

3.3. Составление списка функций.

3.4. Построение и обобщение диаграммы А0(А0 – А-0).

3.5. Декомпозиция ограниченного объекта.

3.6. Итерационный процесс рецензирования.

3.7. Завершение моделирования.

3.8. Документирование.

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

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

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

Цель и точка зрения модели определяется на самой ранней стадии создания модели. Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбором позиции, с которой описывается модель. Если выбор цели и точки зрения затруднен, то можно вначале построить диаграммуА0, и с ее помощью установить это. Иногда приходится строить несколько альтернативных диаграмм А-0 для достаточной уверенности в правильности выбранной цели и точки зрения.

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

Исходное содержание диаграммы А0 обеспечивают списки данных и функций. Вначале изображаются блоки в соответствии с их доминированием. Затем основные дуги, представляющие ограничения. Эти дуги всегда являются внешними, так как представляют данные, поступающие из непосредственного окружения системы. Далее размещаются остальные внешние дуги и назначаются соответствующие им ICOM-коды. В завершении изображаются все оставшиеся дуги. Как правило, невозможно сразу без черновика нарисовать диаграмму. Поэтому ее перерисовывают (рисуют несколько версий).

Обобщение является последним важным шагом начального этапа моделирования. Для любой SADT – диаграммы есть родительская диаграмма, содержащая ее контекст. Контекстом для А0 служит А-0, представляющая обобщение всей модели. Эта диаграмма имеет несколько назначений: она объявляет общую функцию всей системы, дает множество основных типов или наборов данных, которые использует или производит система, указывает взаимоотношения между основными типами данных, производя их разграничение. Для построения А-0 в центре бланка рисуют один большой блок, название которого совпадает с названием диаграммы А0. Все внешние дуги диаграммы А0 изображаются на диаграмма А-0 входящими в соответствующую сторону блока. Далее на диаграмме выписывается цель и точка зрения модели.

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

Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. При этом надо учесть, что рассматривать следует в первую очередь такой блок, декомпозиция которого выявит многие аспекты диаграммы А0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы. В процессе декомпозиции целесообразно проверять ICOM-коды, потому что при моделировании весьма распространены ошибки интерфейса. Если Вы сомневаетесь, стоит ли включать некоторые блоки и дуги в диаграмму, то лучше ее включить, снабдив соответствующими записями.

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

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

Одна из самых важных проблем, возникающих при моделировании – когда следует завершить построение конкретной модели. SADT-модели иерархичны и поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие SADT-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.

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

Вопросы для самопроверки

1. На что ориентирована методология SADT?

2. В чем заключается методология SADT?

3. Основной рабочий элемент моделирования SADT.

4. Состав диаграмм SADT.

5. Изображение блоков и назначение сторон блоков в SADT.

6. Как отображаются на модели SADT принципы функционирования системы?

7. Как отображаются на модели SADT данные?

8. Как происходит размещение блоков на диаграмме SADT.

9. Типы взаимосвязей между блоками в SADT-модели.

10. Отношение Управления.

11. Отношение Входа.

12. Обратная связь по Управлению

13. Обратная вязь по Входу.

14. Отношение Выход-Механизм.

15. Разветвление дуг

16. Слияние дуг.

17. Последовательность создания функциональной модели.

18. Что включает в себя сбор информации?

19. Как производится декомпозиция модели?

20. Как осуществляется выбор цели и точки зрения?

21. Как формируются списки данных и списки функций?

22. Как происходит обобщение модели?

23. Как происходит декомпозиция ограниченного объекта?

24. Как производится рецензирование модели?

25. Из чего состоит папка?

26. Когда завершается процесс декомпозиции?

2.3.3. Bpwin – инструмент реализации методологий структурного анализа и проектирования

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

- с точки зрения функциональности системы;

- с точки зрения потоков информации (документооборота) в системе;

- с точки зрения последовательности выполняемых работ.

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

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

В качестве нотации DFD использует четыре элемента:

Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. (cм. рис.8 – “Проверить наличие товара на складе”)

Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота. (cм. рис.8 – “Запрос на склад”)

Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.. (cм. рис.8 – “Клиент”)

Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. (cм. рис.8 – “Сведения о заказах”)

рис.8 Пример диаграммы DFD

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

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

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.

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

Связь поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

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

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

Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.

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

рис. 9 Пример диаграммы IDEF3

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

Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.

BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer (см. Рис. 5), который по организации очень похож на привычный всем проводник Windows. Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. В версии BPwin 4.0 проводник модели предлагает пользователю улучшенный интерфейс, который включает в себя новую вкладку объектов (Objects), и доработанную вкладку диаграмм (Diagrams). С помощью вкладки объектов можно методом Drag&Drop размещать объекты из словаря на любой диаграмму. С помощью вкладки диаграмм можно просматривать всю иерархию диаграмм, включая Organization Chart, Node Tree, Swim Lane, FEO, и IDEF3 Scenario.

рис. 10 Model Explorer

BPwin поддерживает словари для следующих объектов:

- Работы;

- Стрелки;

- Хранилища данных;

- Внешние ссылки;

- Перекрестки;

- Объекты ссылок;

- Атрибуты;

- Центры затрат;

- Сущности;

- Ресурсы;

- Роли;

- Группы ролей;

- Свойства, определяемые пользователем (UDP);

- Ключевые слова UDP.

Генератор отчетов имеет мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о модели. С его помощью можно также создавать шаблоны для отчетов, которые можно будет многократно использовать впоследствии, а также преобразовывать отчеты в формат txt (.CSV), HTML или RTF.

В дополнение к диаграммам IDEF0, DFD и IDEF3, BPwin поддерживает еще целый ряд вспомогательных диаграмм таких как:

Диаграммы дерева узлов (Node Tree Diagram). К модели BPwin можно добавлять дерево узлов, которое показывает иерархию всех работ модели на одной диаграмме. Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели, тогда верхним узлом диаграммы будет та работа декомпозиции, с которой вы захотите начать моделирование.

рис. 11 Пример диаграммы дерева узлов

Диаграммы только для показа (For Exposition Only {FEO} Diagram). К модели всегда можно добавить диаграмму FEO. Чаще всего это делается, для того чтобы проиллюстрировать разные сценарии развития процесса, показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы (см. рис. 7), не портя при этом саму диаграмму. К любой диаграмме модели в BPwin, будь то контекстная диаграмма или одна из диаграмм декомпозиции можно добавлять произвольное число FEO диаграмм. FEO диаграммы характерны тем, что они не подлежат синтаксической проверке со стороны BPwin, поскольку, как в нашем примере, они могут являться лишь частью синтаксически правильной диаграммы.

рис. 12 Пример FEO диаграммы

Диаграммы сценариев IDEF3 (IDEF3 Scenario). В BPwin 4.0 есть возможность добавлять к модели диаграммы сценариев IDEF3.

рис. 13 Пример сценария IDEF3

Схемы организации (Organization Charts). Для того чтобы наглядно представить структуру организации к любой модели в BPwin 4.0 можно добавить схему организации. Схемы организации BPwin имеют традиционную древовидную иерархическую структуру, на вершине которой находится один прямоугольник, от которого идут ветвления к нескольким нижестоящим. Каждый прямоугольник в схеме организации соответствует конкретной роли или должности, например президента или вице-президента.

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

рис. 14 Пример схемы организации

Swim Lane Diagrams. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей.

рис. 15 Пример Swim Lane диаграммы.

BPwin является не только мощным средством графического представления информации, но и инструментом ее анализа. При реорганизации бизнес-процессов уже существующей системы строятся две модели: AS IS и TO BE. Модель AS IS призвана показать, как система функционирует в настоящий момент и является своего рода фотографией системы. А модель TO BE, которая строится исходя из результатов анализа модели AS IS, показывает, как система будет работать после реорганизации.

Анализ модели AS IS проводится следующим образом. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т.д. Кроме того, BPwin содержит ряд средств, которые помогают аналитику анализировать и исправлять модель AS IS. Прежде всего, речь идет о том, что BPwin указывает на синтаксические ошибки в модели, которые могут быть вызваны неправильной организацией системы. Когда все такие ошибки будут исправлены, перед аналитиком должна встать задача оптимизации, а для корректной постановки этой задачи, как известно, необходим критерий.

BPwin дает аналитику метрику - стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP).

Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия. С помощью стоимостного анализа можно решить такие задачи как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь).

Механизм поддержки ABC в BPwin, хотя и учитывает стоимость выполнения каждой работы, продолжительность каждой работы по времени и сколько раз необходимо выполнить работу в течение одного цикла бизнес-процесса, все же дает довольно грубые оценки и, к тому же требует, чтобы все диаграммы, для которых производится оценка были выполнены в IDEF0. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.

BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов Erwin, Component Modeller и другие.

Вопросы для самопроверки

1. Какие методологии поддерживает Bpwin?

2. Что отличает Bpwin от графического редактора?

3. Для чего используется методология DFD?

4. Перечислите основные элементы нотации DFD.

5. Для чего используется методология IDEF3?

6. Какие типы моделей позволяет строить методология IDEF3?

7. Перечислите основные элементы нотации IDEF3.

8. Укажите типы связей IDEF3.

9. Опишите виды перекрестков IDEF3.

10. Что собой представляет модель, выполненная в Bpwin?

11. Какой инструмент является инструментом навигации Bpwin?

12. Какие словари поддерживает Bpwin?

13. Какой инструмент служит для создания отчетов Bpwin?

14. Опишите вспомогательные диаграммы Node Tree Diagram.

15. Для чего нужны FEO диаграммы?

16. Что такое диаграммы сценариев IDEF3 Scenario?

17. Как создаются диаграммы Organization Charts?

18. Для чего нужны Swim Lane диаграммы?

19. Как в Bpwin проводится анализ модели AS IS?

20. Как реализованы ABC (Activity-Based Costing) метод и UDP (User Defined Properties) в Bpwin?