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

 

  Главная      Учебники - Производство     

 

поиск по сайту           правообладателям

 

 

 

 

 

 

 

 

 

содержание   ..  18  19  20  21   ..

 

 

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

 

 

 

 

77

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

Рабочая модель процесса проектирования занимает ключевое место в рас-

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

передача  контейнера  с  проектным  решением  в  оперативное  хранилище 

информационной системы САПР; 

замена контейнера с проектным решением, хранящегося в хранилище ин-

формационной  системы  САПР,  на  новый  контейнер  (обычно  после  доработки 
или полной переработки ранее сформированного проектного решения); 

корректировка  рабочей  модели  проекта,  в  результате  которой  было  вы-

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

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

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

В  случае  возникновения  какого-либо  из  перечисленных  выше  событий 

для одной из проектных процедур технологического маршрута МС должна опо-
вестить всех ответственных исполнителей последующих процедур, информаци-
онно связанных с первой. Для этой цели выполняется чтение записей файла ра-
бочей  модели  с  целью  подготовки  списка  идентификаторов  проектных  проце-
дур, а также ответственных исполнителей, которым требуется послать сообще-
ние.  Далее  выполняется  обработка  файла  полномочий  пользователей  с  целью 
извлечения из него такой необходимой информации,  как входное (учетное) имя 
пользователя и имя узла ЛВС, выделенного для его работы. Из полученных ин-
формационных  элементов    формируется  соответствующая  командная  строка 
для  запуска  утилиты  MAIL  в  качестве  порожденного  подпроцесса  (SPAWN), 
который  и  осуществляет  рассылку  сообщений.  Формат  команды  для  рассылки 
сообщения: 

MAIL  

имя_файла  имя_пользователя

 

 

 

78

где 

имя_файла 

  спецификация  текстового  файла,  который  формируется  соот-

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

Пользователь локальной МС для просмотра адресованных ему сообщений 

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

MAIL 

REPLY

,  которая  затем  запускается  как  порожденный  подпроцесс.  Этот  способ 

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

 

3.3. 

Контроль логической целостности проекта 

 
Данная  задача  выполняется  с  помощью  программы  Report  (файл RE-

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

1. Отчет  о  проектных  процедурах,  находящихся  в  заданном  состоянии 

(аналогичная задача выполняется программой Listing; см. выше). 

2. Отчет  о  проектных  процедурах,  выполняемых  указанным  подразделе-

нием. 

3. Отчет о проектных процедурах, не имеющих входных ссылок. 

4. Отчет о проектных процедурах, не имеющих выходных ссылок. 

5. Отчет  о  проектных  процедурах,  плановые  даты  окончания  которых 

меньше заданной даты. 

6. Отчет  о  проектных  процедурах,  плановые  даты  окончания  которых 

больше заданной даты. 

7. Отчет о рабочих состояниях проектных процедур для данного проекта. 

8. Отчет  о  проектных  процедурах,  ожидающих  входную  информацию  от 

указанной проектной процедуры.   

9. Отчет об узлах объекта проектирования, разрабатываемых в рамках за-

данного проекта. 

 

 

79

Выбор нужного отчета осуществляется путем ввода номера отчета. Затем 

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

Сформированный отчет можно отобразить на экране терминала, записать 

на диск в виде текстового файла или вывести на принтер.   

Программа  Report  написана  на  языке  Фортран/МВС  [74,  75].  Файл  вы-

полнимого  образа  программы  (REPORT.EXE)  имеет  размер    приблизительно 
равный 49 Кбайтам. 

Использование  этой  программы  обеспечивает  контроль  проекта  по  раз-

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

 

3.4. 

Перепланирование и временная увязка 

проектных работ 

 
Задача  перепланирования  и  временной  увязки  различных  работ  над  про-

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

Расчет длин путей в орграфе требует, чтобы каждая дуга была ассоцииро-

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

 

 

80

Поиск критического пути в ациклическом орграфе осуществляется на ос-

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

Структурно алгоритм состоит из трех следующих частей: 

1. Инициализация  матрицы  смежности.  Выполняется  сканирование  запи-

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

2. Поиск  кратчайшего  пути  в  соответствии  с  алгоритмом  Дейкстры  [76, 

77]. В орграфе задаются две вершины 

 начальная и конечная, между которыми 

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

Шаг  1.  Определяются  веса  для  дуг,  исходящих  из  заданной  вершины 

поиска во все остальные. 

Шаг  2.  Просматриваются    веса    исходящих    дуг    с    целью    отыскания 

наименьшего  значения  и  запоминается  новая  вершина,  в  кото-
рую заходит дуга с наименьшим весом. 

Шаг  3.  Далее  алгоритм  добавляет  этот  наименьший  вес  к  весам  всех 

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

Шаг  4.    В    цикле    сравниваются    полученные  суммы  с  наименьшим 

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

Шаг 5.  Затем  новая  вершина  поиска  удаляется из списка вершин, до 

которых  еще  не  определены  кратчайшие  расстояния.  Если  но-
вая  вершина  является  заданной  конечной  вершиной,  то  поиск 
завершается. 

3.  Вывод  абсолютного  значения  вычисленного  суммарного  веса  дуг 

 

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

 

 

 

 

 

 

 

содержание   ..  18  19  20  21   ..