Управление инновационными проектами Учебное пособие в 2-х частях. Изд-е второе, перераб. и расширен - Александрова Т.В

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

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

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

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

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

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

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

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

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

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

–больше внимания уделяется информационному моделированию (посредством ER-диаграмм) и моделированию поведения (через STD-диаграмм);

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

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

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

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

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

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

–ориентирована на "технологичность" процессов и на моделирование и создание систем вообще (в последнее время широко используется для реор-

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

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

–динамическое моделирование и преобразование SADT-диаграмм возможно в сочетании с методом цветных сетей Петри.

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

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

10

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

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

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

Рассмотрим принцип, по которому множество характеристик конкретной реализации X*, задаваемых техническими требованиями заказчика к проектируемой системе, ставится в соответствие с множеством исходных характеристик проблемно-ориентированной системы Х (типовое решение) и сформулируем теорему о существовании предметно-ориентированной системы XQ как подмножества проблемно-ориентированной системы Х.

Теорема. Пусть заданы множество Х, содержащее "n" характеристик с дискретными и непрерывными параметрами исходной проблемноориентированной системы, и множество X*, содержащее "n*" характеристик, описывающих технические требования к конкретному решению

Для простоты, без потери общности решения, можно положить n=n*, т.е. привести в соответствие перечень характеристик конкретного решения к характеристикам типового решения.

Предметно-ориентированное решение XQ = X ∩ X* будет существовать и будет экономически оправданным, если выполняются условия необходимости и достаточности (рис. 1).

X X*

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

11

Будем считать, что определенное число m характеристик (m<n) этих множеств, которые назовем "паспортными", определяют рамки номенклатурного ряда изделий и качество модулей технического оборудования (как например, масса, габариты, материал, точность обработки, надежность отдельных технологических модулей и средств вычислительной техники и т.п.) и обозначим их:

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

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

Остальные "n-m" характеристики, которые назовем "технико-экономи- ческими", будут определять предварительные технико-экономические показатели (ТЭП) решений (как например, производительность, уровень автоматизации, общая надежность, стоимость системы, срок окупаемости и т.п.) и, соответственно, обозначим для типового и конкретного решений:

V={V(k)}={Xλ(k)}={Xm+1(k), Xm+2(k), ... , Xn(k)} Х;

V*= {X*λ}={V*m+1, V*m+2, ... , V*n} X*;

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

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

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

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

вого решения, где каждое подмножество V(k) V означает вариант значений ТЭП, получаемый в процессе проектирования на базе типового решения, т.е. при адаптации характеристик типового решения под конкретный заказ;

C* и V* — соответственно, подмножества характеристик с условно неизменяемыми и условно варьируемыми параметрами конкретного решения, заданными по техническим требованиям заказчика, но допускающими модификации в процессе разработки и согласования технического задания с заказчиком. Именно эта стадия должна происходить по схеме – назовем ее схемой "параллельной кастомизации" (от англ. customization – выполнение заказа с удовлетворением индивидуальных потребностей заказчика), – по которой одновременно осуществляются этапы проектирования и утверждениясогласования удовлетворительного проектного варианта за счет вовлечения заказчика в процесс системного проектирования и принятия решения;

Xλ(k) — функция от паспортных характеристик, генерирующая варианты количественно-качественного состава технологического оборудования с со-

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

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

12

Условие необходимости. Возможность создания предметно-ориенти- рованной производственной системы XQ определяется наличием или отсутствием пересечения множества типового решения X с множеством требуемой конкретной реализации X*, иначе говоря, можно использовать технологию системного проектирования на базе типового решения, если при одинаковых внешних воздействиях U=U* на определенном интервале времени выполняется условие:

Условие достаточности. Элементы V(k) подмножества V определяют адаптационные возможности типового решения. Если варьировать подмножество V различными значениями ТЭП, соответствующих функциональнополным вариантам компоновки и комплектации так, чтобы множество характеристик типового решения X покрывало согласованные с клиентом технические требования конкретного решения X*, то область экономически достаточного предметно-ориентированного решения XQ может быть определена.

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

∆C* = C* \ C — доля выполнения технических требований, не охваченная мощностями типового решения по паспортным характеристикам, и соответствующее подмножество ∆C*д — допустимая заказчиком доля от C* для достижения компромиссного решения.

Аналогично, подмножество ∆V*(k) = V* \ V(k), k=1,...,K, и соответствую-

щее ∆V*д.

Q = C ∩ C* — область пересечения паспортных характеристик соответствующих систем.

Q(k) = V(k) ∩ V* — область пересечения технико-экономических характеристик конкретного решения с соответствующими характеристиками k-го варианта типового решения.

Тогда решение предметно-ориентированной системы, полученное по допустимым значениям C и по выбранному, удовлетворяющему варианту Vпо{V(k)} (по – предметно-ориентированное решение) из набора техникоэкономических показателей комплексов будет иметь вид

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

C* Q C; V* Q(k) V(k), ∆C* ∆C*д, ∆V*(k) ∆V*д, k=1,...,K (3)

13

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

Следовательно, предметно-ориентированное решение как подмножество проблемно-ориентированного (типового) решения существует тогда и только тогда, когда выполняются условия (1)–(3).

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

XQ = QQ ∆XQ, где QQ = Q Qпо, Qпо = Vпо ∩ V*,

∆XQ = ∆C ∆Vпо = (C \ C*) (Vпо \ V*)

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

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

14

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

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

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

– построение иерархии целей как самого проекта, так и будущей системы, которые только в общем случае совпадают;

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

– наличие простой, ясной и насыщенной системы информационного и коммуникационного обмена между участниками проекта;

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

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

ния.

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

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

n

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

i=1

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

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

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

В табл. 3 перечисляются основные пакеты в каждом классе и их отличительные особенности. В последующих параграфах главы 1, приводится описание программных комплексов для поддержки фазы концепции (Project Expert), стадии системного проектирования (Design/IDEF) и стадии реализации

(MS Project).

15

Прибыль 1

Спад Рост рынка рынка

2

Жизненный цикл проекта

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

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

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

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

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

Методология IDEF0, изначально названная "Технология структурного анализа и проектирования" Structured Analysis and Design Technique (SADT),

была разработана компанией SofTech, Inc в начале 60-х годов как дисциплина инжиниринга для разработки относительно сложных человеко-машинных систем. На ее основе в конце 70-х ВВС США разработали методологию IDEF0 (Icam DEFinition), которая являлась основной частью программы

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

16

и Промышленных Технологий). 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.

17

Управлять

компанией

0

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

A0

A-0

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

18

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

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

Первый шаг в работе по созданию IDEF0-модели – определение цели моделирования (purpose). Цель моделирования определяется набором вопросов, на которые модель должна отвечать. В результате изучения модели читатель (пользователь) должен иметь возможность получить ответы на каждый из вопросов, поставленных в начале моделирования. Список этих вопросов представляет собой неотъемлемую часть документации модели. Аналогия: в предисловии к книге излагается цель ее написания.

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

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

Точка зрения (viewpoint) – это позиция, с которой модель описывает систему. Точка зрения выбирается такой, чтобы модель охватывала установленные границы (scope) и удовлетворяла бы поставленной цели. Будучи однажды выбранной, точка зрения должна оставаться неизменной на протяжении всей работы с моделью. Если необходимо, то для разностороннего описания системы можно построить несколько моделей с различными точками зрения. Примеры точек зрения: владелец фирмы, директор фирмы, клиент, поставщик, служащий и т.д.

IDEF0-диаграммы

На рис. 5 изображена типичная IDEF0-диаграмма на стандартном бланке. На диаграмме изображены несколько функций и взаимосвязи между ними (их взаимодействие). Совокупность функций в своей взаимосвязи описывают работу другой функции. Диаграмма описывает (декомпозирует) функцию.

19