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

Владелец ресурса

Владелец процесса

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

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

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

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

Модель деятельности (или функ­циональная модель) рассматривает систему как набор действий, в кото­ром каждое действие преобразует не­который объект или набор объектов. Функциональные модели выделяют действия посредством представле­ния в виде специального элемента — блока (рис. 1.3).

Провести предпроектное исследование

Рис. 1.3. Функциональный блок

Блоки — это основной структурный элемент функциональной модели, графическим представлением которой является диаграмма.

Рис. 1.4. Модифицированный функциональный блок

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

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

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

Функциональный блок, изображенный на рис. 1.4, отображает границы моделирования системы. Если рассмотреть его подробнее, как бы заглянув внутрь него, можно выделить "детские" блоки, кото­рые, в свою очередь, могут декомпозироваться.

Рассмотрим три технологии моделирования: метод функционального моделирования IDEF0, метод описания биз­нес-процессов IDEF3 и метод построения диаграмм потоков данных (DFD). Все описанные подходы входят в семейство стандартов IDEF (Integrated DEFinition), полный перечень и назначение которых приве­дены в приложении.

Своим появлением семейство стандартов 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 был специально разработан для закрытого проек­та ВВС США. Это технология получения описания деталей процесса от экспертов в предметной области и разработки таких моделей про­цессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, эта технология приобрела ши­рокое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0.

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

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

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

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

Преимущества, получаемые от разработки моделей «as is», долж­ны быть сопоставлены с затратами средств и времени, которые для этого необходимы. В литературе без труда можно найти многочислен­ные примеры систем, изначально построенных для решения несоот­ветствующих их истинному назначению задач. «As is»- моделирование позволяет обойти подобные трудности. С другой стороны, если имеется определенный уровень понимания задачи в целом (как это часто случается при разработке информационных систем, электронных устройств), затраты средств на разработку “as is”- моделей могут быть неоправданными.

Дата добавления: 2014-01-07