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

 

 

69

  

Глава 3. Основные задачи поддержки  

           

оперативного управления проектом,  

           

способы и средства их решения 

 

В настоящей главе представлен ряд основных задач поддержки оператив-

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

Способы  и  средства  решения  перечисленных  выше  задач  основываются 

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

 

3.1. 

Мониторинг текущего состояния проекта 

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

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

Наиболее  часто  руководителю  проекта  требуется  получить  ответ  на  во-

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

В  каждой  записи  файла  рабочей  модели,  соответствующей  некоторой 

проектной процедуре, представлено поле, описывающее рабочее состояние этой 

 

 

70

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

1. Пассивна (0). 

2. Ожидания (1). 

3. Активна (2). 

4. Приостановлена (3). 

5. Завершена локально (4). 

6. Завершена глобально (5). 
В  любой момент проектирования каждая проектная процедура в рабочей 

модели  может  находиться  в одном из следующих состояний: пассивна, ожида-
ния, активна, приостановлена или локально завершена. В состояние “завершена 
глобально”  каждая  процедура  модели  переводится  после  передачи  проекта  в 
архив САПР. 

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

не имеющие входных ссылок, т.е. начальные процедуры маршрута,  установле-
ны  в  состояние  “пассивна”,  остальные процедуры 

−

 в состояние “ожидания”. 

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

Откат  в  технологическом  маршруте  проектирования,    являющийся  след-

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

 

 

71

Для мониторинга текущего состояния проекта  используются следующие 

две  программы:  Listing  (файл  LISTING.EXE)  и  Search_Proc  (файл 

SEAPRC.EXE). Запуск программы Listing выполняется выбором пункта “Вывод 
листинга рабочей модели” в меню “Работа с информационной моделью”. Про-
грамма  обеспечивает  следующие  четыре  варианта  формирования  листинга  ра-
бочей модели процесса проектирования, отраженные в меню: 

1. Вывод по идентификатору процедуры. 

2. Вывод по рабочему состоянию процедуры. 

3. Вывод входных и выходных ссылок. 

4. Вывод полного листинга. 
Для  решения  задачи  мониторинга  проекта  используются  1-й,  2-й  и  4-й 

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

При выборе 2-го пункта меню и ввода кода (номера) конкретного рабоче-

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

При выборе 4-го пункта меню формируется полный листинг рабочей мо-

дели процесса проектирования. 

Листинг  рабочей  модели,  отображенный  на  экране  терминала,  при необ-

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

Идентификатор проектной процедуры:  Генерация_тест_наборов 
Рабочее состояние:  локально завершена 
Плановая дата начала работ:      15-АПР-1998 
Плановая дата окончания работ: 15-ОКТ-1998 
Фактическая  дата начала работ:     20-АПР-1998 
Фактическая дата окончания работ: 17-ОКТ-1998 
Ответственный исполнитель:  Иванов_И_И 
Подразделение:  Лаборатория_1 
Наименование узла:  Блок_декодирования_команд 
Кол-во входных ссылок:    1 
Идентификаторы входных ссылок:   Логическое_моделирование 
Кол-во выходных ссылок:  2 
Идентификаторы выходных ссылок: Компоновка_блока_декодирования 

                                                             

Трассировка_блока_декодирования

      

 

 

72

Программа Listing написана на языке высокого уровня Фортран/МВС [74, 

75].  Файл  выполнимого  образа  программы  (LISTING.EXE)  имеет  размер    при-
близительно равный 27 Кбайтам. 

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

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

В  каждой  записи  файла  рабочей  модели содержатся поля, предназначен-

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

START

 и 

FINISH

 в исходном описании информационной модели процесса проек-

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

Запуск  программы  Search_Proc  выполняется  выбором  пункта  “Поиск 

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

Если оказывается, что в считанной записи поле “Фактическая дата начала 

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