Система управления проектами в автоматизированном проектировании

Новакова Наталия Евгеньевна кандидат технических наук доцент, кафедра cистем автоматизированного проектирования, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В.И. Ульянова (Ленина) 197082, Россия, г. Санкт-Петербург, ул. Ул. Яхтенная, 35 Novakova Nataliya Evgen'evna PhD in Technical Science Associate Professor, Department of Computer-aided Design, Ulyanov (Lenin) Saint Petersburg State Electrotechnical University "LETI"  197082, Russia, g. Saint Petersburg, ul. Ul. Yakhtennaya, 35 nenovakova@gmail.com Другие публикации этого автора     Горячев Александр Вадимович кандидат технических наук доцент, кафедра систем автоматизированного проектирования, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В.И. Ульянова (Ленина) 197376, Россия, Санкт-Петербург, улица Профессора Попова, дом 5 Goryachev Aleksandr Vadimovich PhD in Technical Science Associate Professor, Department of Computer Aided Design, Ulyanov (Lenin) St. Petersburg State Electrotechnical University "LETI" 197376, Rossiya, Sankt-Peterburg, ulitsa Professora Popova, dom 5 avgoryachev@gmail.com Другие публикации этого автора     Горячев Алексей Александрович кандидат филологических наук старший преподаватель, кафедра речевой коммуникации, Санкт-Петербургский государственный университет 199004, Санкт-Петербург, 1-я линия В.О., д. 26. Goryachev Aleksei Aleksandrovich PhD in Philology 199004, Saint Petersburg, 1-ya liniya V.O., d. 26. aga@list.ru Другие публикации этого автора     Васильев Андрей Алексеевич 197376, Россия, Санкт-Петербург, улица Профессора Попова, дом 5 Vasil'ev Andrei Alekseevich 197376, Russia, Saint Petersburg, ulitsa Professora Popova, dom 5 nenovakova@gmail.com

Монахов Алексей Викторович 197376, Россия, Санкт-Петербург, улица Профессора Попова, дом 5 Monakhov Aleksei Viktorovich 197376, Russia, Saint Petersburg, ulitsa Professora Popova, dom 5 nenovakova@gmail.com

Проектирование – это один из наиболее сложных видов интеллектуальной работы, выполняемой человеком. Проектную деятельность, связанную с созданием сложных технических объектов, невозможно представить без применения средств автоматизации проектирования ^[1]. Одно из основных направлений повышения качества автоматизированного проектирования заключается в применении новых форм организации процесса автоматизированного проектирования, в том числе за счёт применения методологии проектного управления и внедрения корпоративных систем управления проектами ^[2]. Для реализации задачи управления проектными работами в автоматизированном проектировании необходима модель процесса проектирования. Процесс проектирования может быть представлен различными моделями в зависимости от целей применения этих моделей, принятых форм или правил их построения.

Первые попытки формализации процесса автоматизированного проектирования относятся к середине 70-х гг. прошлого века. К наиболее значимым работам в данном направлении можно отнести работы Хубки В. ^[3], Сольницева Р.И. ^[4], Норенкова И.П.^[5], Иошикавы Н. ^[6], Стрельникова Ю.Н.^[7]. Несмотря на различные подходы к формализации данные исследования объединяет представление процесса проектирования как объекта автоматизации. Наибольшее распространение получила теория Иошикавы. В основе теории Иошикавы лежит аксиоматический подход. На основании аксиом о распознавании объекта по его атрибутам и их абстрактным представлениям процесс получения проектных решений представлен как отображение пространства атрибутов в пространство функций. Концепция формального представления процесса проектирования, описанная в работах Иошикавы, получила дальнейшее развитие в теории автоматизированного проектирования, представленной в работах ^[7],[8].

В ^[9] была представлена обобщённая модель процесса автоматизированного проектирования, базирующаяся на аксиоматическом подходе и являющаяся развитием теории Иошикавы. В соответствии с парадигмой автоматизированного проектирования, изложенной в ^[1], процесс проектирования представляет собой движение от состояния к состоянию в соответствии с системой целей. Целью процесса проектирования является создание проектного решения, удовлетворяющего всем требованиям, предъявляемым к разрабатываемому объекту и заключённым обычно в техническом задании. Конечной целью процесса проектирования является выбор обобщенного проектного решения из некоторого пространства поиска для проектируемого объекта, удовлетворяющего исходной спецификации: `FinA:F_r` ` ` где `F` – обобщенное проектное решение; `A` – область его поиска, содержащая все возможные решения; `F_r` – исходная спецификация, все требования которой должны быть выполнены. Получаемое в результате автоматизированного проектирования обобщенное решение включает в себя промежуточные проектные решения `d1, d2, ..., ` принятые на этапах проектирования.

Эти решения находят отражение в окончательной спецификации объекта. В отличие от исходной, окончательная спецификация определяет не только требуемые характеристики объекта, но и способ его производства. Таким образом, процесс проектирования в некотором приближении можно рассматривать как отображение `P:F_r->A_s` , где `A_s` – окончательная спецификация объекта.

Традиционно, в процессе проектирования выделяют этапы, проектные процедуры и проектные операции ^[5]. Этапы состоят из проектных процедур, каждая из которых, в свою очередь включает ряд проектных операций. Проектная операция представляет собой отдельный шаг при проектировании; операция – это минимальная единица работы, рассматриваемая как составная часть процесса проектирования.

Каждая проектная процедура завершается проектным решением. Это решение изменяет информационное описание объекта проектирования либо расширяя его, либо модифицируя (уточняя).

Проектные решения должны иметь некоторое физическое воплощение. Таким воплощением может являться файл или набор файлов проектирующей системы, документ в бумажном или электронном виде, физический макет и т. д. Информационное описание объекта состоит из набора артефактов, дополняемых и изменяемых в процессе проектирования. Этот набор отражает не только текущий результат проектирования, но и знания о текущей проектной ситуации ^[9].

Знания о текущей проектной ситуации могут иметь различные статусы. Типичными примерами являются статусы «разработан» и «утвержден», которые относятся к проектной документации. Обычно порядок присвоения статусов строго задан и должнен быть пройден от начала до конца, однако иногда к конечному статусу (с которым артефакт войдет в окончательную спецификацию) есть несколько маршрутов.

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

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

`W=F[f1(z), f2(z),...,fn(z)], z={zi}. i=bar(1,n)`

где `z` – множество проектных решений, принятых при выполнении проектных процедур `P={P_(i)}, i=bar(1,N)` ; `F` – принятый вид функционала качества проекта; `f1, f2,...,fn` – функции, представляющие частные критерии оценки качества проекта, которые принимают конкретные числовые значения в зависимости от значений аргумента `z` .

Таким образом, если имеются конкретные проектные решения, то функции `f1, f2,...,fn` и функционал `F` примут конкретные числовые значения. Смысл функции `f1, f2,...,fn` может быть следующим: `f1` – трудозатраты на проект; `f2` – время выполнения проекта; `f3` – отличие результатов от требований ТЗ к проекту; `f4` – количество извещений об изменении технической документации из-за ошибок в ней и т. д. Тогда стоимость проектных процедур в процессе проектирования может быть выражена в виде функционала

`W=F(sum_(i=1)^nalpha_(i)f_(i))` ,

где `alpha_(i)` – цена нормо-часа `i` -й проектной процедуры `P_(i)`; `f_(i)` – планируемая трудоёмкость процедуры .

В процессе проектирования приходится сталкиваться с такими ограничениями, как `g1` – допустимая стоимость проекта, `g2` – ресурсы проектного предприятия, `g3` – допустимое время проектирования, количество и состав комплектующих изделий и т. д., которые можно формально записать так

`G(g_(1),g_(2),...,g_(m))<=G_(0)` .

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

Основные принципы построения маршрутов проектирования:

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

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

Теперь попробуем сопоставить основные концепции теории автоматизированного проектирования и проектного управления ^[2].

Проектом принято считать временное усилие, предпринятое для создания уникального результата (продукта или услуги). Когда цель проекта достигнута, он завершается. Сама длительность проекта, как правило, определяется временем, необходимым для достижения конечного результата. В отличие от проекта непроектная (операционная) деятельность, однажды налаженная, может потенциально продолжаться сколь угодно долго. Вместо создания конечного продукта она подразумевает выполнение повторяющихся операций ^[10]. Проектная деятельность подразумевает наличие (а) цели и задач и (б) ограниченных сроков. Разумеется, не стоит также забывать, что (в) объём доступных ресурсов, как правило, тоже ограничен. Очевидно, что разработка изделия с помощью систем автоматизированного проектирования является в полной мере проектной деятельностью, поскольку создаётся уникальный и вполне определённый объект, которого раньше не существовало.

В практике проектного управления принято использовать сетевые модели ^[2]. Под термином «сеть» в планировании и управлении проектами понимается полный комплекс работ и вех проекта с установленными между ними зависимостями. Сетевые диаграммы отображают проект как множество соответствующих работам вершин, связанных линиями, представляющими взаимосвязи между работами. Сетевые модели представляют собой ориентированный граф, изображающий все необходимые для достижения цели проекта операции в технологической взаимосвязи. Сетевые модели являются организационным инструментом управления проектом. Они позволяют осуществлять календарное планирование работ, оптимизировать использование ресурсов, сокращать или увеличивать продолжительность выполнения работ в зависимости от их стоимости, организовывать оперативное управление и контроль в ходе реализации проекта. Основными элементами сетевой модели являются: работа, событие и путь ^[3]. Работа – это минимальная единица структурной декомпозиции проекта. В сетевой модели работа изображается в виде сплошной стрелки, над которой стоит цифра, показывающая ее продолжительность (рис. 1). Работа идентифицируется номерами начального и конечного событий. В более сложных сетевых моделях на графике указываются наименование, стоимость, объём работ, ответственные исполнители, количество необходимых ресурсов. Событие – это результат выполнения одной или нескольких работ, позволяющий начинать следующую работу. Событие не является процессом и не имеет длительности. Поэтому каждое событие, включаемое в модель, должно быть полно и точно определено, его формулировка должна включать результат всех непосредственно предшествующих ему работ. Путь – это непрерывная последовательность работ от исходного события до завершающего в сетевой модели. Длина пути – суммарная продолжительность работ, лежащих на пути. Особую роль в управлении проектами играет критический путь. Критический путь – путь с наибольшей длиной. Критический путь определяет общую продолжительность проекта.

Сопоставим базовые понятия теории автоматизированного проектирования и методологии проектного управления ^[1]. Как было отмечено, любая проектная деятельность подразумевает наличие цели и задач, ограничена сроками выполнения работ и доступными для их выполнения ресурсами. Перечисленные характеристики, а также качество выполняемых работ являются важнейшими понятиями теории автоматизированного проектирования ^[5]. Продолжая сопоставление можно отметить, что дуге сетевого графика в терминах проектного менеджмента соответствует работа, а в теории проектирования – типовая проектная процедура или операция. Таким образом, в модели, называемой сетевым графиком, рассматриваемый комплекс проектных процедур изображается в виде ориентированного графа, отражающего его логическую последовательность, взаимосвязь и длительность. Дугами графа являются проектные процедуры, а его вершинами – их результаты: техническая и конструкторская документация, макеты, опытные образцы и т. п. В процессе проектирования многие проектные процедуры выполняются одновременно. Для представления параллельно выполняемых работ на сетевом графике выделяют несколько цепочек (путей) от начального события (начальной вершины ориентированного графа) до завершающего события (конечной вершины) последовательно взаимосвязанных проектных процедур, соответствующих маршрутам проектирования. Таким образом, система сетевого планирования и управления, математической основой которой является теория графов, может быть применена на различных этапах проектирования и подготовки производства.

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

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

Чтобы отображать длительности и сроки, нужно добавить к сетевой диаграмме временную шкалу, после чего она превратится в принципиально иной тип диаграммы – диаграмму Ганта, являющуюся самым наглядным способом представления проектного графика. Представление проектного графика в виде диаграммы Ганта включено во все программные средства управления проектами. Одним из самых популярных инструментов управления проектами является Microsoft Project 2010. Однако применение Microsoft Project 2010 Professional для управления проектами в САПР сдерживается по ряду причин. Во-первых, это настольная версия продукта и используется в однопользовательском режиме. Во-вторых, приложение не является бесплатным и его внедрение в масштабах предприятия достаточно дорого. В-третьих, функциональность Microsoft Project 2010 Professional избыточна для проектов подобного типа.

Для организации механизмов управления проектными работами в САПР разработано специальное приложение, основанное на применении Web-технологий ^[11]. Наличие удобного графического интерфейса, возможность использования разнообразных диаграмм и наличие средств коллективной работы над проектами позволяют сформировать на его основе систему управления проектными работами в автоматизированном проектировании. На рис. 1 представлен фрагмент процесса проектирования для сложного технического объекта. Приложение обеспечивает все основные операции, необходимые для управления проектными работами в САПР, работает в сетевом режиме и обеспечивает отчётность, необходимую для отслеживания хода выполнения работы. К основным характеристикам системы можно отнести возможность создания задач и вех, настройку календаря, назначение ресурсов, поиск и фильтрацию данных, создание дочерних и родительских задач, настройку цветовой гаммы для различных типов задач, отслеживание хода выполнения работ, формирование отчётов.