Управление сложными проектами в интегрированных САПР - часть 8

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

Ниже рассмотрены особенности организации управления процессом

сквозного проектирования в интегрированной САПР.

1.2.2.

Задачи управления процессом проектирования

Если объектом управления является процесс проектирования, то на его

входе и выходе фиксируются не материальные потоки, как в случае процессов,
протекающих  в  технических  системах  [33],  а  информационные  (рис.  1.9).  Ин-
формация  о  событиях  процесса  проектирования  фиксируется  в  информацион-
ной  модели,  являющейся  важнейшим  компонентом  системы  управления.  Эта
информация анализируется субъектом управления с целью оценки текущего со-
стояния  процесса  проектирования  и  выработки  управляющих  воздействий,  оп-
тимизирующих выполнение этого процесса.

Рис. 1.9. Управление проектированием как информационный процесс

В общем случае процесс проектирования характеризуется наличием

большого  числа  плохо  формализуемых  факторов,  которые  не  позволяют  орга-
низовать  управление  этим  процессом  в  соответствии  с  принципами,  разрабо-
танными  для  автоматических  систем.  В  САПР в контур управления процессом
проектирования  включен  человек,  деятельность  которого  трудно  формализо-

Процесс проектирования

(

объект управления)

Руководитель проекта

(

субъект

управления)

Мониторная система

(“

устройство” управления)

Информация
модели

Информация
об объекте

Цель управ-
ления

Выходная

информация

Входная

информация

Управляющее
воздействие

вать, а само управление, как правило, выполняется в автоинтерактивном режи-
ме.

При рассмотрении процесса проектирования в качестве объекта управле-

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

Формулировка целей управления. Большинство САПР, исполь-

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

С точки зрения управления процесс проектирования определяется плана-

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

Подобная схема управления проектированием имеет ряд слабых мест, к

которым относятся:

значительные трудности при составлении координационных планов, сете-

вых графиков, увязывающих во времени взаимосвязанные этапы проектных ра-
бот;

отсутствие средств контроля логической целостности проекта в целом и

его составных частей;

отсутствие оперативной информации о ходе выполнения работ над проек-

том в целом и каждой из его составных частей в отдельности;

невозможность оперативного вмешательства в процесс управления проек-

тированием руководителя проекта и/или его ответственных исполнителей;

большая вероятность потери информации в процессе передачи ее между

проектными процедурами и/или этапами проектирования;

возможность искажения результирующей информации (проектных реше-

ний) в результате отказов или сбоев оборудования;

возможность искажения информации или ее полной потери (замены) в ре-

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

возможность доступа к проектной информации лиц, не имеющих на это

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

Перечисленные выше недостатки организации процесса управления про-

ектированием и взаимодействия различных обрабатывающих подсистем значи-
тельно снижают научно-технический уровень проработки проекта и усложняют
задачу  получения  конечного  проектного  решения.  Они  и  определяют  цели
управления,  а  также  требуемые  процедуры  и  операции  управления,  которые
возможно  и  целесообразно  автоматизировать  путем  создания  мониторной  сис-
темы (МС) САПР.

Поскольку общие требования, предъявляемые к процессу проектирова-

ния, не зависят от конкретной предметной области проектирования, разрабаты-
ваемые базовые компоненты МС должны быть инвариантными составляющими
САПР различных типов.

Определение объекта управления. Очевидно, что рассмотрение

процесса проектирования в виде некоторого “монолитного” объекта (см. выше
рис. 1.9) или в виде иерархии подпроцессов проектирования (см. выше рис. 1.3),
не позволяет четко сформулировать основные требования к системе управления
этим объектом. Поэтому необходимо продолжить уточнение процесса проекти-
рования и, в частности, выполнить его структурирование с целью выделения в
нем базового, т.е. минимального объекта управления (с точки зрения субъекта
управления

−

руководителя проекта). Это тем более важно, что свойства и ха-

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

Объектом управления для мониторной системы является проектная про-

цедура, поскольку только она позволяет получить промежуточный результат
проектирования или проектное решение [34, 35]. Проектное решение, получае-

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

Для целей формализации процесса проектирования, выполняющегося в

рамках интегрированной среды обработки, ниже введены два вспомогательных
понятия

−

комплексная проектная процедура и комплексное проектное реше-

ние.

В общем случае в состав интегрированной среды обработки могут вхо-

дить различные инструментальные средства

−

от отдельных программ, реали-

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

С точки зрения управления и проектная процедура, реализуемая отдель-

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

Проектное решение, сформированное КПП, рассматривается как ком-

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

содержание .. 6 7 8 9 ..