Книги по разным темам Pages:     | 1 | 2 | 3 | 4 | 5 |   ...   | 11 |

C* Q C; V* Q(k) V(k), C* C*, V*(k) V*, k=1,...,K (3) д д Институт инноватики Таблица 2. Матрица условий достаточности существования решения 1 2 3 4 5 Q=C* Q=C Q=C Q=, C*QC, C*QC, (C*C), (CC*), (CC*), C*=C* C*C*d C*C*d C*= C*C*d C*C*d Q(k)=, k=1,...,K, V*(k)=V* Q(k)=V*, 2 XQ XQ XQ (V*V(k)), V*(k)= 3 XQ XQ XQ V*Q(k)V(k), V*(k)V*d V*Q(k)V(k), V*(k)V*d Q(k)=V(k), 5 XQ XQ XQ (V(k)V*), V*(k)V*d Q(k)=V(k), (V(k)V*), V*(k)V*d Следовательно, предметно-ориентированное решение как подмножество проблемно-ориентированного (типового) решения существует тогда и только тогда, когда выполняются условия (1)Ц(3).

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

XQ = QQ XQ, где QQ = Q Qпо, Qпо = Vпо V*, XQ = C Vпо = (C \ C*) (Vпо \ V*) Применение технологии системного проектирования на базе типового решения позволяет уменьшить сроки проектирования и избежать на этом этапе ошибок за счет использования отработанного проблемно-ориентированного решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Институт инноватики Прибыль Спад Рост рынка рынка 1 2 3 4 Время Жизненный цикл проекта 1 - с использованием средств автоматизации для сокращения сроков реализации этапов проекта;

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

Рис. 2. Рост прибыли за счет опережения выхода проекта на рынок Таблица 3. Инструментальные средства автоматизации фаз реализации проекта № Отличительные Project MS Time Project Prima- View Prestige Expert Project Line Workb.

характеристики vera Point 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 - Интеграция Компьютерных Институт инноватики и Промышленных Технологий). 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.

Институт инноватики Управлять компанией Планирование Собрать продукцию производства (компьютеры) 3 Вести учет Заказать Разработать Подготовить Поставить Установить комплектующих, Устранить расписание документы комплек- задачи Управлять детали на Собрать Конфигу- Теститребующих (план-график) неисправ- на отправку производству материнскую тующие складом первоочередного рировать ровать производства изделия ности использования плату 1 2 3 4 5 1 2 3 4 Рис. 3. Декомпозиция функций AA-AAAAAAAAAA13 AA1 AAAAAРис. 4. Структура IDEF0-модели Институт инноватики IDEF0-модель в отличие от обычной декомпозиции функций, представленной на рис. 3, образованной исключительно вертикальными связями, содержит горизонтальные связи между функциями. Это позволяет не просто описать структуру функций, но и их взаимодействие, придающее совокупности функции системные свойства.

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

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

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

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

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

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

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

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

Институт инноватики Стандартный бланк содержит типовой заголовок и нижний колонтитул.

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

Элементы заголовка бланка:

Поле Назначение Used At Используется для ссылок на документы, где эта диаграмма используется. Часто это поле не заполняется.

Author, Date, Содержит имя автора, создавшего диаграмму, дату создания и назваand Project ние проекта, для которого эта диаграмма и модель разрабатывались.

Notes Когда диаграмма, напечатанная на бумаге, редактируется, читатель 1 2 3 4 5 6 7 8 9 10 отмечает каждое появившееся замечание зачеркиванием цифры в этом поле. В результате видно количество замечаний к диаграмме.

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

Working Новая диаграмма, в диаграмму внесены большие изменения или старая диаграмма переработана новым автором.

Draft Диаграмма одобрена читателями. Она готова для рассмотрения руководителем проекта и для подробного комментирования.

Recommended Диаграмма и все сопровождающие ее комментарии рассмотрены и одобрены. Изменения в диаграмме не предполагаются.

Publication Диаграмма готова к печати и публикации.

Reader, Date Имя читателя и дата чтения (рецензирования).

Context Это эскиз родительской диаграммы, на которой выделяется родительский блок. Поле контекста на контекстной диаграмме содержит слово TOP, что показывает отсутствие у нее родительской диаграммы в этой модели.

Элементы нижней части бланка:

Поле Назначение Node Номер диаграммы. Он совпадает с номером декомпозируемого блока.

Title Название диаграммы, совпадающее с названием декомпозируемого блока Number Так называемый C-номер, уникальный номер, однозначно идентифицирующий ЭТУ диаграмму. Любая новая версия диаграммы будет иметь свой C-номер. Обычно C-номер содержит инициалы автора как уникальный идентификатор. Пример: JDM001. C-номера используются как номера страниц.

Если создается новая версия диаграммы, то новый вариант должен содержать ссылку на старую диаграмму, например, JDM(JDM001). Это позволяет проследить хронологию совершенствования модели.

Институт инноватики CONTEXT:

AUTHOR:Marca DATE:

11/04/ USED AT: WORKING READER DATE PROJECT: Механический цех REV:

DRAFT RECOMMENDED NOTES: 1 2 3 4 5 6 7 8 9 PUBLICATION Требования по Справочник срокам выполнения стандартов задания качества CCШтамп "Принято" Статус задания Готовая деталь Управлять IOвыполнением OРабочий заданияAкомплект Оценка степени План Чертеж завершенности выполнения задания задания Мастер Сырье и заготовки Выполнить Iзадание Законченное или незаконченное задание Станки и Aинструменты Принятое Рабочий задание Принятое, но Деталь с Брак незаконченное биркой Контролировать задание качество выполнения AКонтролер Персонал механического цеха MNODE: TITLE: NUMBER:

Pages:     | 1 | 2 | 3 | 4 | 5 |   ...   | 11 |    Книги по разным темам