Структурный анализ систем средствами IDEF-моделирования

3.2.1. Общие положения

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

В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем)

Методология IDEF в настоящее время поддерживается семейством из 11 стандартов, отражающих различные аспекты моделирования систем. Мы ограничимся тремя технологиями моделирования, а именно методом функционального моделирования IDF0, методом описания бизнес-процессов IDF3 и методом построения диаграмм потоков данных DFD.

Своим появлением семейство стандартов IDEF во многом обязано появившейся в 80-х гг. технологии автоматизированной поддержки разработки информационных систем CASE (Computer Aided Software Engineering). До настоящего времени эта технология с успехом применяется при разработке разнообразного программного обеспечения. Однако в последнее время CASE-технологии приобретают все большее распространение для моделирования и анализа деятельности предприятий, предоставляя богатый набор возможностей для оптимизации или, в терминах CASE, реинжиниринга технологических процедур, выполняемых этими предприятиями – бизнес-процессов.

IDEF0, ранее известный как технология структурированного анализа и разработки (Structured Analysis and Design Technique – SADT), был разработан компанией SofTech, Inc. в конце 60-х гг. как набор рекомендаций по построению сложных систем, которые предполагали взаимодействие механизмов и обслуживающего персонала. Значительная часть SADT была принята ВВС США как часть их программы интегрированной компьютерной поддержки производства (Integrated Computer-Aided Manufacturing – ICAM) в конце 70-х гг. Эта технология, переименованная в IDEF0, довольно быстро стала стандартом технологии моделирования деятельности в министерстве обороны США.

В 1993 г. группа пользователей IDEF (IDEF Users Group, в настоявшее время Society of Enterprise Engineering – SEE), совместно с Национальным институтом стандартов и технологии (National Institute of Standards and Technology – NIST) предприняли попытку создания документированного стандарта для IDEF0, который мог бы использоваться как военными, так и гражданскими департаментами правительства США. Этот стандарт был опубликован как федеральный стандарт обработки информации (Federal Information Processing Standard – FIPS).

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

Стандарт IDEF3 был специально разработан для закрытого проекта ВВС США. Это технология получения описания деталей процесса от экспертов в предметной области и разработки таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними.

Подход SADT относится к классу формальных методов, используемых при анализе и разработке систем. Несмотря на то, что вполне допустима независимая разработка функциональных моделей, методология SADT предполагает ведение структурированного проекта анализа, в процессе которого происходит их создание. В дополнение к функциональному моделированию SADT структурный анализ предполагает построение информационных моделей данных и диаграмм состояний (State-Transition Diagrams – STD), которые моделируют поведение системы во времени.

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

Часто разработка моделей применяется для документирования ситуации, сложившейся к определенному моменту (модели "как есть" – «as is»). Впоследствии они применяются при создании новых моделей функционирования системы (модели "как должно быть" – «to be»), а также для проверки моделей «to be», с тем, чтобы удостовериться, что предлагаемые изменения действительно повлекут улучшение функционирования системы.

В дополнение к алгоритмизации процесса построения предлагаемой системы модели «to be» используются для планирования загрузки частей системы; калькуляции бюджета и распределения ресурсов; при построении плана реорганизации системы, определяющего действия по переводу системы из состояния «as is» в состояние «to be».

3.2.2. Методология описания бизнес-процессов IDEF3

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

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

Пример описания процесса с использованием методологии IDEF3 изображен на рис. 3.6.1. IDEF3 может быть использован как метод проектирования бизнес-процессов, а так же он органично дополняет традиционное моделирование с использованием методологии IDEF0.

Рис. 3.6.1. Описание процесса в методологии IDEF3.

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

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

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

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

Другой важной компонентой в модели IDEF3 является действие, или «единица работы» (Unit of work – UOW). Диаграммы IDEF3 отображают действие в виде прямоугольников, причем действие именуется с использованием глаголов и отглагольных существительных. Действию присваивается уникальный идентифицированный номер, который не используется вновь даже в тех случаях, когда в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (см. рис. 3.6.2).

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

Рис. 3.6.2. Изображение и нумерация действий в диаграмме IDEF3

Таблица 3.1.1. Возможные типы связей между действиями

Изображение	Название	Назначение
	Временное предшествование(Temporal precedence)	Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться прежде, чем конечное действие сможет начаться
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

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