Александрова Т.В., Голубев С.А., Колосова О.В., Туккель И.Л. и др. Управление инновационными проектами. Часть 2. Инструментальные средства и практикум управления проектами

Подождите немного. Документ загружается.

Институт инноватики http://ii.spb.ru/

– моделирования текущих операций;

– выявления причин выполнения именно этих операций;

– добавления новых требований;

– выбора границ автоматизации.

1.2. Методология E. Yourdon

Отличительные признаки:

– не рекомендуется моделировать текущую систему;

– добавлена предварительная фаза разработки, названная созданием ос-

новной модели (essential model);

– определена техника "событийного разбиения" (event partitioning), для

конструирования DFD-схемы;

– больше внимания уделяется информационному моделированию (по-

средством ER-диаграмм) и моделированию поведения (через STD-диаграмм);

– указано место прототипирования в жизненном цикле разработки;

– имеется описание семантики потоков и правила преобразования вход-

ных данных в выходные;

2. SADT-методология D. Ross.

Методология SADT выделяется среди современных методологий описа-

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

жирования результатов работ по крупным проектам, общностью охвата сис-

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

связь и исполнители. Методология принята как американский стандарт воо-

руженных сил и имеет широкую область применения: от аэрокосмического

производства до реорганизации бизнес-процессов и обучения персонала.

Отличительные признаки:

– широко используемая в крупных проектах;

– ориентирована на "технологичность" процессов и на моделирование и

создание систем вообще (в последнее время широко используется для реор-

ганизации бизнес-процессов – Business Process Reorganization BPR);

– формализованная типизация элементов схемы (вход, управление, вы-

ход, ресурс);

– динамическое моделирование и преобразование SADT-диаграмм воз-

можно в сочетании с методом цветных сетей Петри.

Выбор той или иной методологии структурного анализа напрямую зави-

сит от специфики предметной области, для которой создается модель (ориен-

тированность на технологичность процессов и создание общих систем или на

обработку потоков информации).

Однако, наиболее общим и перспективным подходом к анализу и проек-

тированию сложных систем является SADT-методология. В п. 1.4 будет дано

ее более полное описание.

Институт инноватики http://ii.spb.ru/

1.2. Технология системного проектирования

на базе типового решения.

Одним из подходов к автоматизации процесса системного проектирова-

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

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

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

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

системы и придает ей инвариантность по отношению к разнообразию но-

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

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

тельство сказывается положительно в процессе эксплуатации созданной сис-

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

Рассмотрим принцип, по которому множество характеристик конкрет-

ной реализации X

, задаваемых техническими требованиями заказчика к про-

ектируемой системе, ставится в соответствие с множеством исходных харак-

теристик проблемно-ориентированной системы Х (типовое решение) и

сформулируем теорему о существовании предметно-ориентированной систе-

мы X

как подмножества проблемно-ориентированной системы Х.

Теорема. Пусть заданы множество Х, содержащее "n" характеристик с

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

ориентированной системы, и множество X

, содержащее "n

характеристик,

описывающих технические требования к конкретному решению

Х=

и Х

i=1

Для простоты, без потери общности решения, можно положить n=n

, т.е.

привести в соответствие перечень характеристик конкретного решения к ха-

рактеристикам типового решения.

Предметно-ориентированное решение X

= X

∩ X

будет существовать и

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

сти и достаточности (рис. 1).

X X

(1)

… X

(2)

… X

(k)

Проблемно- Конкретная реализация

ориентированное

решение

Рис. 1. Проблемно-ориентированное решение, конкретная реализация и их адаптация

Институт инноватики http://ii.spb.ru/

Будем считать, что определенное число m характеристик (m<n) этих

множеств, которые назовем "паспортными", определяют рамки номенкла-

турного ряда изделий и качество модулей технического оборудования (как

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

дельных технологических модулей и средств вычислительной техники и т.п.)

и обозначим их:

C = {X

}⊂

Х, j=1,...,m — для типового решения;

= {X

}⊂

, j=1,...,m — для конкретной реализации.

Остальные "n-m" характеристики, которые назовем "технико-экономи-

ческими", будут определять предварительные технико-экономические пока-

затели (ТЭП) решений (как например, производительность, уровень автома-

тизации, общая надежность, стоимость системы, срок окупаемости и т.п.) и,

соответственно, обозначим для типового и конкретного решений:

V={V

(k)

}={X

(k)

}={X

m+1

(k)

, X

m+2

(k)

, ... , X

(k)

}⊂

Х;

= {X

}={V

m+1

, V

m+2

, ... , V

}⊂

;

где λ = m + 1,...,n , k = 1,...,K, K – натуральное число; т.е. имеем X = C

∪ V

и X

= C

∪ V

, а природу этих подмножеств определим как:

С — подмножество характеристик с неизменяемыми параметрами, за-

данными по составу средств типового решения;

V — подмножество характеристик с варьируемыми параметрами типо-

вого решения, где каждое подмножество V

(k)

⊂

V означает вариант значений

ТЭП, получаемый в процессе проектирования на базе типового решения, т.е.

при адаптации характеристик типового решения под конкретный заказ;

и V

— соответственно, подмножества характеристик с условно не-

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

заданными по техническим требованиям заказчика, но допускающими мо-

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

казчиком. Именно эта стадия должна происходить по схеме – назовем ее

схемой "параллельной кастомизации" (от англ. customization – выполнение

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

торой одновременно осуществляются этапы проектирования и утверждения-

согласования удовлетворительного проектного варианта за счет вовлечения

заказчика в процесс системного проектирования и принятия решения;

(k)

— функция от паспортных характеристик, генерирующая варианты

количественно-качественного состава технологического оборудования с со-

ответствующим набором ТЭП и с ограничениями, заданными техническими

требованиями C

и V

Можно отметить, что по сути, число K определяет уровень стратифика-

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

целесообразных вариантов решения.

Институт инноватики http://ii.spb.ru/

Условие необходимости. Возможность создания предметно-ориенти-

рованной производственной системы X

определяется наличием или отсут-

ствием пересечения множества типового решения X с множеством требуемой

конкретной реализации X

, иначе говоря, можно использовать технологию

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

внешних воздействиях U=U

на определенном интервале времени выполня-

ется условие:

∪ V} ∩ {C

∪ V

} ≠ ∅ (1)

Условие достаточности. Элементы V

(k)

подмножества V определяют

адаптационные возможности типового решения. Если варьировать подмно-

жество V различными значениями ТЭП, соответствующих функционально-

полным вариантам компоновки и комплектации так, чтобы множество харак-

теристик типового решения X покрывало согласованные с клиентом техни-

ческие требования конкретного решения X

, то область экономически доста-

точного предметно-ориентированного решения X

может быть определена.

Построим матрицу полного перебора сочетаний параметров типового

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

достаточности решения. Для этой цели введем следующие вспомогательные

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

решений:

∆

= C

\ C — доля выполнения технических требований, не охваченная

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

ствующее подмножество ∆

— допустимая заказчиком доля от C

для дос-

тижения компромиссного решения.

Аналогично, подмножество ∆

*(k)

= V

\ V

(k)

, k=1,...,K, и соответствую-

щее ∆

Q = C

∩ C

— область пересечения паспортных характеристик соответ-

ствующих систем.

(k)

= V

(k)

∩ V

— область пересечения технико-экономических характе-

ристик конкретного решения с соответствующими характеристиками k-го

варианта типового решения.

Тогда решение предметно-ориентированной системы, полученное по

допустимым значениям C и по выбранному, удовлетворяющему варианту V

по

∈ {V

(k)

} (по – предметно-ориентированное решение) из набора технико-

экономических показателей комплексов будет иметь вид

= C

∪ V

по

, (2)

Как следует из матрицы полного перебора условий (табл. 2), решение

находится под ограничениями:

⊇ Q

⊆ C; V

⊇ Q

(k)

⊆ V

(k)

, ∅ ⊇ ∆

⊆ ∆

, ∅ ⊇ ∆

*(k)

⊆ ∆

, k=1,...,K (3)

Институт инноватики http://ii.spb.ru/

Таблица 2. Матрица условий достаточности существования решения

1 2 3 4 5 6

Q=∅,

∆C

Q=C

⊆C),

∆C

=∅

⊃Q⊂C,

∆C

⊆∆C

⊃Q⊂C,

∆C

⊃∆C

Q=C

(C⊆C

∆C

⊆∆C

Q=C

(C⊆C

∆C

⊃∆C

(k)

=∅,

k=1,...,K,

∆V

*(k)

∅

(k)

⊆V

(k)

∆V

*(k)

=∅

∅

⊃Q

(k)

⊂V

(k)

∆V

*(k)

⊆∆V

∅

⊃Q

(k)

⊂V

(k)

∆V

*(k)

⊃∆V

∅ ∅ ∅ ∅ ∅ ∅

(k)

⊆V

∆V

*(k)

⊆∆V

∅

(k)

⊆V

∆V

*(k)

⊃∆V

∅

Следовательно, предметно-ориентированное решение как подмножество

проблемно-ориентированного (типового) решения существует тогда и только

тогда, когда выполняются условия (1)–(3).

Можно отметить, что следствием применения технологии проектирова-

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

чае ненулевой, функциональной избыточности (∆

) над мощностями, за-

данными по техническим требованиям заказчика. Оценка эффективности

достаточности решения является неформальной, договорной. Тогда выраже-

ния (2)-(3) для предметно-ориентированного решения могут быть записаны в

виде:

= Q

∪ ∆

, где Q

= Q

∪ Q

по

, Q

по

= V

по

∩ V

∆

= ∆

∪ ∆

по

= (C \ C

) ∪ (V

по

\ V

)

Применение технологии системного проектирования на базе типового

решения позволяет уменьшить сроки проектирования и избежать на этом

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

рованного решения.

Платой за совмещение подхода стандартизации (ускорение проектиро-

вания за счет использования типового решения) с подходом параллельной

кастомизации является наличие некоторой избыточности решения, которая, в

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

уже в процессе эксплуатации системы.

Институт инноватики http://ii.spb.ru/

1.3. Автоматизированные системы управления проектами

В настоящее время планирование и исполнение большого проекта пере-

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

ха достигает тот, кто владеет современными методами и технологиями

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

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

димо:

– построение иерархии целей как самого проекта, так и будущей систе-

мы, которые только в общем случае совпадают;

– состояние полного взаимопонимания и скоординированности вла-

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

полнителей;

– наличие простой, ясной и насыщенной системы информационного и

коммуникационного обмена между участниками проекта;

– наличие финансовых, материальных, интеллектуальных, физических и

временных ресурсов;

– наличие эффективных систем планирования, мониторинга и управле-

ния.

Автоматизированные системы безусловно повышают качество осущест-

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

ции, представления информации в наглядной форме.

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

ектом является время его выполнения:

∑

→

min

где

- длительность реализации i-го этапа проекта.

Фактор времени прямо влияет на экономические показатели как самого

проекта, так и изделий, которые поставляются на рынок в результате его

осуществления (рис. 2).

Существуют автоматизированные системы, ориентированные на на-

чальные этапы (как в частности, для стадии системного проектирования) и

ориентированные на реализацию (управления реализацией проекта или так

называемые Project Management). Системы типа Project Management отно-

сятся к системам предназначенным для разработки календарного плана ра-

бот и сетевого графика проекта, включая длительность и затраты по стади-

ям проекта.

В табл. 3 перечисляются основные пакеты в каждом классе и их отличи-

тельные особенности. В последующих параграфах главы 1, приводится опи-

сание программных комплексов для поддержки фазы концепции (Project Ex-

pert), стадии системного проектирования (Design/IDEF) и стадии реализации

(MS Project).

Институт инноватики http://ii.spb.ru/

1 – с использованием средств автоматизации для сокращения

сроков реализации этапов проекта;

2 – без использования средств автоматизации.

Рис. 2. Рост прибыли за счет опережения выхода проекта на рынок

Таблица 3. Инструментальные средства автоматизации фаз реализации проекта

№ Отличительные

характеристики

Project

Expert

Project

Time

Line

Project

Workb.

Prima-

vera

View

Point

Prestige

1 Оценка инвестиционных

рисков

отл. удов. удов. удов. удов. удов. удов.

2 Кол-во работ/ресурсов норм. высок. высок высок. высок. высок. высок.

3 Кол-во календарей/ планов норм. норм. норм. норм. высок. норм. высок.

4 Сетевые/иерархические

модели

удов. удов. удов. хор. удов. удов. удов.

5 Управление персоналом удов хор. удов. удов. удов. хор. хор.

6 Экспорт/импорт информ. хор. отл. отл. отл. отл. отл. отл.

1.4. Технология структурного анализа и проектирования SADT

Методология IDEF0, изначально названная "Технология структурного

анализа и проектирования" Structured Analysis and Design Technique (SADT),

была разработана компанией SofTech, Inc в начале 60-х годов как дисципли-

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

систем. На ее основе в конце 70-х ВВС США разработали методологию

IDEF0 (Icam DEFinition), которая являлась основной частью программы

ICAM (Integrated Computer-Aided Manufacturing – Интеграция Компьютерных

Жизненный цикл п

оекта

1 2

3 4

емя

Прибыль

Рост

рынка

Спад

рынка

Институт инноватики http://ii.spb.ru/

и Промышленных Технологий). IDEF0-технология быстро стала стандартом

Министерства Обороны США для разработки моделей процессов.

В 1993 году IDEF Users Group (сейчас Society of Enterprise Engineering –

SEE), вместе с National Institutes of Standards and Technology (NIST), выпол-

нили работу по созданию стандарта IDEF0 для использования во всех граж-

данских и военных отделах правительства США и их представительствах.

Этот стандарт был опубликован как Federal Information Processing Standards

(FiPS) Publication 183.

Независимо от этого, но используя большинство таких же принципов,

стала популярной методология DFD (Data Flow Diagrams –Диаграммы пото-

ков данных), которая использовалась для структурного проектирования (а за-

тем и для структурного анализа) в проектах по разработке программного

обеспечения. DFD-модели имеют много общего с IDEF0-моделями и могут

использоваться совместно. Часто DFD-диаграммы используются для уточне-

ния IDEF0-диаграмм.

Методология IDEF3 была разработана специально для проектов, финан-

сируемых Armstrong Laboratories ВВС США. Эта технология предназначена

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

специалистами в предметной области, и для разработки моделей процессов,

где очень важно четко отображать последовательность и параллельность

процессов.IDEF3 не была оформлена как стандарт FiPS, однако получила

широкое распространение при реализации проектов Министерства Обороны

США как дополнение к методологии IDEF0.

Методология моделирования IDEF0 предназначена для анализа всей

системы как множества взаимодействующих взаимосвязанных функций.

Ориентация исключительно на анализ функций позволяет рассматривать

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

подход позволяет четко отделить проблемы анализа и проектирования от

проблем реализации.

IDEF0 – наиболее подходящий метод для анализа и логического проек-

тирования. В основном он применяется на ранних стадиях проекта.

IDEF0 позволяет выполнять описание сложных объектов с помощью

простого и понятного графического языка.

Графический язык IDEF0 содержит только два символа (блоки и стрелки).

Простота синтаксиса языка сочетается с хорошо разработанным процессом

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

Описание системы по правилам IDEF0 имеет четкую структуру. IDEF0-

модель представляет собой набор иерархически упорядоченных диаграмм. Ка-

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

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

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

пример которой приведен на рис. 3, представляется иерархий диаграмм – рис. 4.

Институт инноватики http://ii.spb.ru/

Устранить

неисправ-

ности

Подготовить

документы

на отправку

изделия

Собрать

продукцию

(компьютеры)

Планирование

производства

Управлять

компанией

Заказать

комплек-

тующие

Поставить

задачи

производству

Управлять

складом

Разработать

расписание

(план-график)

производства

Вести учет

комплектующих,

требующих

первоочередного

использования

Установить

детали на

материнскую

плату

Собрать

Конфигу-

рировать

Тести-

ровать

Рис. 3. Декомпозиция функций

A-0

A21

A22

A23

A11

A12

A13

A23

A232

A233

A24

Рис. 4. Структура IDEF0-модели

Институт инноватики http://ii.spb.ru/

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

ленной на рис. 3, образованной исключительно вертикальными связями, со-

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

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

сти функции системные свойства.

Методология IDEF0 имеет много общего с процессом издания книг.

Часто набор IDEF0-моделей организуют в виде подшивки с оглавлением,

глоссарием и другими атрибутами книг. Отличие лишь в том, что для изло-

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

ный язык. Такой набор моделей в IDEF0 называется папкой.

Первый шаг в работе по созданию IDEF0-модели – определение цели

моделирования (purpose). Цель моделирования определяется набором вопро-

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

татель (пользователь) должен иметь возможность получить ответы на каж-

дый из вопросов, поставленных в начале моделирования. Список этих вопро-

сов представляет собой неотъемлемую часть документации модели. Анало-

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

Работа над моделью начинается с изложения цели, обобщающей все ос-

новные вопросы к системе.

Границы модели (scope) определяют степень детализации и глубину из-

ложения информации в модели. Границы модели накладывают ограничения на

использование специальной терминологии, на необходимость комментирова-

ния специальной информации, относящейся к предметной области модели и

т.д. Границы определяются исходя из цели моделирования, подготовленности

читателей (пользователей) модели. Подобные данные обычно содержатся и в

предисловиях книг. Для разработки модели недостаточно только списка во-

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

вопросов, с какой степенью детализации, должен получит читатель.

Точка зрения (viewpoint) – это позиция, с которой модель описывает сис-

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

ные границы (scope) и удовлетворяла бы поставленной цели. Будучи однаж-

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

всей работы с моделью. Если необходимо, то для разностороннего описания

системы можно построить несколько моделей с различными точками зрения.

Примеры точек зрения: владелец фирмы, директор фирмы, клиент, постав-

щик, служащий и т.д.

IDEF0-диаграммы

На рис. 5 изображена типичная IDEF0-диаграмма на стандартном блан-

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

(их взаимодействие). Совокупность функций в своей взаимосвязи описывают

работу другой функции. Диаграмма описывает (декомпозирует) функцию.