Создание контекстной диаграммы

Введение

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

Что происходит на предприятии? Прежде чем пытаться улучшить деятельность предприятия, выбрать, а затем внедрить информационную систему, необходимо проанализировать, как работает предприятие в настоящее время. Для анализа необходимо знать не только как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом рабочем месте. Один человек, как правило, не обладает такой информацией. Действительно, руководитель предприятия хорошо разбирается, как работает организация в целом, но не в состоянии знать особенности деятельности всех рядовых сотрудников. Рядовой сотрудник хорошо разбирается в своих обязанностях, но плохо знает, как работают его коллеги. Следовательно, для анализа деятельности предприятия следует собрать знания множества в едином месте - создать модель деятельности предприятия. Многие корпоративные информационные системы зарубежных производителей (SAP R/3, BAAN, ROSS iRenaissance и др.) имеют в своем составе специальные средства (поддерживающие оригинальные методики), с помощью которых можно обследовать предприятия и построить модель их деятельности, однако существуют стандартизированные, опробованные в течение многих лет методологии и инструментальные средства. Наиболее известной и распространенной является предложенная в 70-х годах Дугласом Россом (Douglas Ross) методология структурного анализа SADT (Structured Analysis and Design Technique).

В начале 90-х годов в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 (http://www.idef.com). IDEF0 является независимым от частных организаций стандартом и получил чрезвычайно широкое распространение, он принят в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ. BPwin 4.0 является инструментальным средством, полностью поддерживающим стандарт IDEF0.

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

Затем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие – и так далее до достижения необходимой детализации описания.

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

Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или работу и именуется глаголом или глагольной фразой, обозначающей действие, например "Изготовление изделия", "Обслуживание клиента" и т. д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в функциональной модели - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работа верхнего уровня, но в более детальном изложении. После каждого сеанса декомпозиции автором диаграммы формируется папка — набор документов, в который входит сама диаграмма, дополнительные отчеты и т. д. Папка направляется эксперту предметной области (т. е. человеку, хорошо разбирающемуся в моделируемом фрагменте деятельности предприятия) для проведения экспертизы. На уровне контекстной диаграммы это может быть управляющий предприятия, на уровне первой декомпозиции - начальник отдела и т. д., вплоть до рядового исполнителя. Прежде чем декомпозировать далее, на текущем уровне необходимо внести в диаграмму все замечания экспертов. Таким образом, каждый из экспертов дополняет модель в той ее части, в которой он наиболее компетентен. В результате получается полностью адекватная системе модель, которая позволяет наглядно представить существующие недостатки, перенаправить и усовершенствовать бизнес-процессы, провести анализ стоимости производства, а также послужить основой для создания информационной системы. BPwin позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования - DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы. Нотация IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - нотацией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.

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

Как должно работать предприятие в будущем? Какой выигрыш (проигрыш) даст реорганизация? Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (Как будет) - модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных/лучших путей выполнения работы и документирования того, как предприятие будет функционировать в будущем. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая (рис. 1). Например, каждая из моделей ТО-ВЕ может соответствовать определенной информационной системе.

Рис. 1. Построение моделей ТО-ВЕ как результат анализа модели AS-IS

 

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

BPwin предоставляет аналитику два инструмента для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации движителей затрат в организации. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ. Следовательно, стоимостный анализ позволяет оценить, каковы будут последствия внедрения информационной системы, действительно ли это приведет к повышению производительности и экономическому эффекту и к какому именно.

BPwin позволяет делать достаточно эффективные оценки стоимости, но при этом не претендует на высокую точность таких оценок. Для точных вычислений затрат можно воспользоваться специализированным средством стоимостного анализа EasyABC. BPwin поддерживает двунаправленный экспорт - импорт в EasyABC (рис. 2). Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - ABC. ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем UDP.

В какую сумму обойдется внедрение информационной системы? Модели AS-IS и ТО-ВЕ позволяют описать начальное и конечное состояние предприятия - до и после внедрения корпоративной информационной системы, оставляя без внимания сам процесс разработки (выбора) и внедрения. Но поскольку внедрение информационной системы - это тоже работа, можно с помощью BPwin создать модель этой работы (модель ТО-ВЕ на рис. 1). Модель ТО-ВЕ - это не модель деятельности предприятия, а модель мероприятий по переводу предприятия на новую технологию работы. Используя эту модель можно с помощью стоимостного анализа оценить объем средств, необходимых для приобретения/разработки и внедрения информационной системы. Такие модели можно построить для перехода на различные модели ТО-ВЕ, т. е. для внедрения различных информационных систем (как готовых, так и созданных на заказ) и выбрать оптимальный вариант.

Рис. 2. Общая схема взаимодействия BPwin с программными продуктами Computer Associates и других фирм

Поддерживает ли структура данных информационной системы деятельность предприятия? Ответ на этот вопрос возможен, если предприятие самостоятельно разрабатывает информационную систему или структура данных приобретаемой информационной системы открыта и документирована. База данных должна полностью обеспечивать каждую функцию предприятия. Для того чтобы убедиться в этом, структура данных должна быть связана с функциональной моделью. Модель данных может быть создана вновь или воссоздана из существующей информационной системы с помощью ERwin 4.0 (фирма Computer Associates) - системы проектирования данных.

Связь функциональной модели BPwin 4.0 и модели данных ERwin 4.0 (см. рис. 2) гарантирует завершенность анализа, гарантирует, что есть источник данных (сущность) для всех потребностей данных (работа). Связи объектов способствуют согласованности, корректности и завершенности анализа.

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

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

Поддерживает ли функциональность информационной системы деятельность предприятия? Разработчики информационных систем в процессе создания программного обеспечения сталкиваются с целым рядом трудновыполнимых задач. Работая с объектно-ориентированными технологиями создания приложений, они создают клиент-серверные приложения, которые должны удовлетворять требованиям надежности, управляемости и высокой производительности. Решение этих задач возможно только в условиях высокоэффективного анализа и проектирования. С одной стороны, BPwin позволяет построить адекватную модель (модель работ) существующих на предприятии процессов (AS-IS), проанализировать эту модель и построить модель будущих процессов (ТО-ВЕ). С другой стороны, разработчики, использующие такие средства объектно-ориентированного анализа и проектирования, как Rational Rose фирмы Rational Software или Paradigm Plus фирмы Computer Associates, могут описать функциональность информационной системы при помощи диаграмм Use Cases (диаграммы Use Cases являются составной частью объектно-ориентированного языка моделирования информационных систем UML, Unified Modeling Language). Бизнес-процессы современных предприятий и организаций весьма сложны. В результате анализа могут быть описаны работы (activity) и функции (use case), информация о которых получена из самых разных источников, поэтому необходима синхронизация работ и функций. Такая синхронизация позволяет выявить соответствие информационной системы реальным бизнес-процессам предприятия, выяснить, действительно ли внедряемая корпоративная информационная система обеспечит поддержку деятельности предприятия.

BPwin 4.0 позволяет связать модели процессов с объектной моделью Paradigm Plus 4.0 (см. рис. 2). Целью интеграции моделей Paradigm Plus и BPwin является установление логической связи между работами (activity) и функциями (use case), что позволяет создать единую технологическую цепочку от анализа бизнес-процессов до генерации кода приложений, включая описание требований к приложению.

Организация коллективной работы. Создание и внедрение современных информационных систем, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Для организации коллективной работы BPwin способен взаимодействовать с Model Mart (фирма Computer Associates) - хранилищем моделей, к которому открыт доступ для участников проекта (см. рис. 2). Model Mart удовлетворяет всем требованиям, предъявляемым к средствам организации коллективной работы, а именно:

1. Совместному моделированию. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля - Intelligent Conflict Resolution (ICR). В дополнение к стандартным средствам организации совместной работы Model Mart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.

2. Управлению доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми они получают возможность работать только с определенными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах, может меняться, поэтому в Model Mart можно определять права доступа и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели.

3. Архитектуре Model Mart, которая реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin 4.0 и BPwin 4.0. В Model Mart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.

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

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

Создание имитационной модели является очень сложной задачей. BPwin позволяет детально исследовать технологический процесс, построить диаграмму такого процесса (IDEF3) и экспортировать модель (см. рис. 2) в один из самых эффективных инструментов имитационного моделирования – Arena (фирма System Modeling Corporation, http://www.sm.com). Arena позволяет строить имитационные модели, "проигрывать" и оптимизировать технологические процессы в самых разных сферах деятельности.

Отчеты и экспорт модели. BPwin 4.0 на основе информации о модели бизнес-процесссов позволяет генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования модели. Отчеты могут быть экспортированы в распространенные форматы – текстовый, MS Office, HTML и др. (см. рис. 2). Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin 4.0 поддерживает также экспорт и импорт модели в текстовый файл формата IDL (см. рис. 2). Формат IDL является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.

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

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

Практикум состоит из нескольких лабораторных работ.

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

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

Основные процедуры в компании таковы:

– продавцы принимают заказы клиентов;

– операторы группируют заказы по типам компьютеров;

– операторы собирают и тестируют компьютеры;

– операторы упаковывают компьютеры согласно заказам;

– кладовщик отгружает клиентам заказы.

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

Лабораторная работа 1

Таблица 1.1.1

Описание элементов управления основной панели инструментов BPwin 4.0

Элемент управления	Описание	Соответствующий пункт меню
	Создать новую модель	File/New
	Открыть модель	File/Open
	Сохранить модель	File/Save
	Напечатать модель	File/Print
	Вызвать генератор отчетов	Tools/Report Builder
	Выбор масштаба	View/Zoom
	Масштабирование	View/Zoom
	Проверка правописания	Tools/Spelling
	Включение и выключение навигатора модели Model Explorer	View/Model Explorer
	Включение и выключение дополнительной панели инструментов работы с ModelMart	ModelMart

 

Создание новой модели

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 4).

Рис. 1.1.2. Диалог создания модели

 

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

После щелчка по кнопке ОК появляется диалог Properties for New Models (рис. 1.1.3), в котором следует внести свойства модели. (Более подробно свойства модели будут рассмотрены в 1.2.1.)

 

Рис. 1.1.3. Диалог Properties for New Models

 

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Работы (Activity)

Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Изготовление детали", "Прием заказа" и т.д.). Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 1.2.3).

Рис. 1.2.3. Пример контекстной диаграммы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. 1.2.4).

Рис. 1.2.4. Редактор задания свойств работы

 

Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке . Возникает диалог Activity Box Count (рис. 1.2.5), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 1.2.6). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.

Рис. 1.2.5. Диалог Activity Box Count

 

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

Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.

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

Рис. 1.2.6. Пример диаграммы декомпозиции

 

Каждая из работ на диаграмме декомпозиции может быть, в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 1.2.7 работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции.

Рис. 1.2.7. Пример декомпозируемых работ

Стрелки (Arrow)

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

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

Вход (Input) – материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1.2.3 – это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании информационных систем, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет -управление.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. "Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1.2.3 стрелки "Задание" и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться, Стрелка выхода рисуется как исходящая из правой грани работы, На рис. 1.2.3 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия ".

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

Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На рис. 1.2.3 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

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

Для внесения граничной стрелки входа надо:

· щелкнуть по кнопке с символом стрелки в палитре инструментов и перенести курсор к левой стороне экрана, пока не появится начальная темная полоска;

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

· вернуться в палитру инструментов и выбрать опцию редактирования стрелки;

· щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки во вкладке Name диалога Arrow Properties (рис. 1.2.8).

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 1.2.8. Диалог Arrow Properties

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEFO - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что и границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 1.2.9).

Рис. 1.2.9. Фрагмент диаграммы декомпозиции с ICOM-кодам (II, С1 и С2)

 

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на вкладке Display диалога Model Properties (меню Model/Model Properties).

Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий (рис. 1.2.10).

Рис. 1.2.10. Словарь стрелок

 

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