Изначально методология IDEF разрабатывалась для ВВС США, затем эксплуатировалась NASA и лишь спустя некоторое время стала применяться для моделирования бизнес-процессов.

Самыми популярными разновидностями семейства IDEF, из тех, что применяются в бизнесе, являются нотации IDEF0 и IDEF3 . Отличительной особенностью нотации является возможность декомпозиции, т.е. каждый отдельный блок в процессе в свою очередь может быть представлен в виде отдельного процесса.

IDEF0

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

Несмотря на наличие дополнительных свойств, в виде «управления» процессом, нотация IDEF0 по-прежнему остается статичной и не способна отразить, как именно меняется ход выполнения процесса под воздействием этого самого «управления».

Количество блоков на схеме IDEF0 обычно жёстко ограничено инструментом для моделирования и, как правило, не превышает 9. Зачастую такого количества оказывается недостаточно, из-за чего особо крупные процессы приходится дробить на несколько диаграмм, что вызывает определенные неудобства.

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

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

Самым известным российским продуктом, поддерживающим построение процессов в нотации IDEF0 , является , поддержку данной нотации имеет также Microsoft Visio .

IDEF3

Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0 . В отличие отIDEF0 данная нотация не поддерживает отображение «механизмов» и «управления», зато отображает очередность выполнения работ персоналом. Несмотря на схожесть с нотацией FlowChart , имеет некоторые существенные отличия. Во-первых, весь процесс строится не сверху вниз, а слева направо и при этом, как правило, ограничен количеством используемых блоков на одну диаграмму. Во-вторых, нотация изначально предназначалась для технических специалистов, поэтому содержит специальные перекрёстки, такие как, «XOR», «Synchronous OR», «Asynchronous OR», «Synchronous AND» и «Asynchronous AND», знакомые программистам, но требующие дополнительное пояснения менеджерам предприятия.

Нотация IDEF3 - важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). В течение длительного
времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне - при описании работ, выполняемых в подразделениях и на рабочих местах. Следует отметить, что эта нотация была взята за основу при создании методики описания процессов ARIS еЕРС - «расширенной цепочки процесса, управляемого событиями». Предлагаем читателю ознакомиться с нотацией IDEF3 как классическим вариантом Work Flow, а затем перейти к рассмотрению более новых схем моделирования процессов.
Основные графические объекты модели, используемые в IDEF3, - четырехугольники и стрелки. Первые служат для описания функций (работ, процессов), вторые - для отражения в модели последовательности выполнения функций во времени либо последовательности выполнения функций, обусловленной потоком материальных ресурсов. Прежде чем перейти к нотации IDEF3, рассмотрим следующий пример. На рис. 2.18 представлено два варианта возможного описания потока работ.
Вариант 1 на рис. 2.18 показывает, что вначале выполняется функция 1. После ее завершения одновременно осуществляются функции 2 и 3. Стрелки в этом случае показывают, как завершение одной функции влияет на начало выполнения другой.
Вариант 2 построен по-другому. Начало выполнения функций здесь обусловлено поступлением на вход материальных ресурсов (вход функции 1), окончание - выходом материальных ресурсов (выход функции I). Потоки ресурсов определяют начало выполнения следующих функций процесса (функций 2 и 3).
В чем недостатки способов описания процессов, представленных на рис. 2.18? В том, что построенные таким образом схемы процессов невозможно прочитать однозначно. Функции 2 и 3 могут выполняться не одновременно, например, в ситуации, когда потребуется осуществить одну из двух. В этом случае выбранный способ описания процесса не позволит понять, какой вариант развития событий реализуется на самом деле. Если на структурных моделях верхнего уровня (IDEF0) синхронность и условные переходы не важны, то на уровне Work Flow эти данные весьма существенны для реальной работы и должны отражаться в модели. Вернемся к нотации IDEF3.

Рис. 2.18. Описание потоков работ

Длительность выполнения функций (график Ганта)

Alt="" />
потоком материальных объектов

Чтобы избежать неоднозначности описания, в нотации IDFE3 определены дополнительные объекты, служащие для отображения возможных вариантов ветвления и слияния потоков работ, реализующихся при определенных условиях. Указанные объекты являются логическими символами трех видов: логического «И»; логического «ИЛИ»;
-¦ исключающего логического «ИЛИ».
Виды объектов нотации IDEF3 и их назначение представлены в табл. 2.2.

Табл. 2.2. Виды объектов нотации IDEF3 и их назначение

1	Модель работы (U0W)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия		1
2	Объект ссылки {Referent)	Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к функциям и перекресткам
3	Логич« т оператор «Иgt;	Оператор, позволяющий описать ветвление и слияние процесса. Оператор показывает, что после выполнения функции начинается выполнение всех последующих функций			amp;
4	огоческии оператор lt;ИЛ1	Оператор, позволяющий описать ветвление и слияние процесса. Оператор показывает, что после выполнения функции начинается выполнение какой-то одной или всех последующих функций			О
5	Логический оператор исключаю щее lt; ИЛИ»	Оператор, позволяющий описать ветвление и слияние процесса. Оператор показывает, что после выполнения функции начинает выполняться только одна из всех последующих функций			X
6	Стрелка предше- ствовани	Соединяет последовательно выполняемые функции	>
7	Стрелка отношения	Используется для привязки объектов-комментариев к функциям	>>
8	Стрелка потока объектов,	Показывает поток объектов от одной функции к другой	>

В отличие от нотации IDEF0, в нотации IDEF3 стороны четырехугольника, изображающего функцию (работу, процесс), не используются для привязки входов различного типа. Более того, в четырехугольник может входить и выходить только одна стрелка. В противном случае правила построения диаграмм в IDEF3 будут нарушены.
На рис. 2.19 показан пример применения логического оператора «И». Процесс начинается с функции, после которой стоит знак этого оператора, - перекресток. За перекрестком процесс разветвляется и одновременно начинает выполнять следующие две функции. Когда они выполнены, происходит слияние стрелок процесса при помощи значка «И». Это означает, что последняя функция процесса начинает выполняться тогда, когда закончено выполнение двух предыдущих функций.
На рис. 2.20 представлена модель с логическим оператором «ИЛИ». Такой оператор означает, что после выполнения первой функции процесса могут произойти три события: 1) выполняется функция 2; 2) выполняется функция 3; 3) выполняются функции 2 и 3 одновременно.

Рис. 2.19. Модель процесса с оператором «И»

Рис. 2.20. Модель с оператором «ИЛИ»

Рис. 2.21 иллюстрирует применение логического символа исключающего «ИЛИ». В данном случае после выполнения функции 1 может начаться выполнение либо функции 2, либо функции 3. Далее после выполнения какой-либо из этих функций мы снова попадаем на перекресток исключающего «ИЛИ». Функция 4 будет выполнена либо после окончания функции 2, либо функции 3.

Рис. 2.21. Модель с оператором исключающего «ИЛИ»
/>

В нотации IDEF3 логические операторы могут быть синхронными и асинхронными. На рис. 2.22 показана разница между синхронным и асинхронным «И».
Рис. 2.22. Модель с оператором логического «И»

При декомпозиции процессов в IDEF3 не происходит мигрирования и туннелирования стрелок. Аналитик должен сам заботиться о связности моделирования процесса, корректности декомпозиции
(если данная функция не предусмотрена программным продуктом, в котором он работает). Возможный пример декомпозиции процесса из нотации IDEF0 (рис. 2.15) на процесс в нотации IDEF3 показан на рис. 2.23. Обратим внимание, что функция «Получить вспомогательное сырье на складе» инициируется поступлением утвержденного графика производства. Этот факт отражен входящей стрелкой «График производства». Также на диаграмме процесса показана стрелка «Вспомогательное сырье». Такое ее представление - нарушение нотации описания. Но, вообще говоря, таким приемом можно пользоваться, не забывая при этом менять тип стрелки на стрелку с двумя наконечниками, отображающую поток объектов (материальных ресурсов или информации).
На рис. 2.24 приведен пример бизнес-процесса в нотации IDEF3 под названием «Обработать заявку клиента». Рассматриваемый процесс - часть более общего процесса «Сбыт готовой продукции». Процесс начинается с поступления заявки клиента, которую обрабатывает функция «Выполнить учет заказа в системе». По ходу ее реализации данные заказа клиента регистрируются в системе автоматизации (например, в файле Excel). Затем менеджер отдела сбыта осуществляет проверку на соответствие номенклатуре (функция «Выполнить анализ на соответствие номенклатуре»). Результатом этого могут быть два события: «Заказ соответствует номенклатуре изделий, производимых организацией» или «Заказ не соответствует номенклатуре изделий». Для отражения этих событий в модели процесса используется логический оператор исключающего «ИЛИ». После этого логического оператора процесс ветвится. В случае несоответствия заказа номенклатуре выполняется нижняя ветка процесса, а именно функции «Уведомить клиента о невозможности выполнения заказа» и «Внести заказ клиента в статистику неудовлетворенного спроса».
В случае если заказ клиента соответствует номенклатуре, мы начинаем движение по верхней ветке процесса. Выполняется функция «Согласовать заявку с ПЭО». К ней привязан ссылочный объект «Согласовать с ПЭО в случае соответствия заявки номенклатуре». Планово-экономический отдел организации (ПЭО) анализирует заказ и делает вывод о его реализуемости.

Рис. 2.23. Пример модели процесса в стандарте IDEF3

alt="" />

Например, может сложиться ситуация нехватки производственных мощностей из-за ремонтов, несоответствия величины заказа экономически обоснованным размерам партии и т. п. В этом случае мы снова попадаем на нижнюю ветку процесса, при этом используется логический оператор «ИЛИ». Он служит для объединения возможных входов в функцию «Уведомить клиента о невозможности заказа».
Если ПЭО считает заказ выполнимым, то проводится детальный расчет себестоимости выполнения - определяется его цена и возможные сроки выполнения (функция «Рассчитать себестоимость, цену и возможные сроки выполнения заказа»). Далее указанные выше расчетные цифры согласовываются с клиентом - выполняется функция «Согласовать условия поставки с клиентом».
Снова возможны два варианта - используется оператор логического исключающего «ИЛИ». Если клиента не устраивают финансовые условия, он отказывается от заказа, который мы вносим в статистику неудовлетворенного спроса (нижняя ветка процесса). Если клиент готов работать на наших условиях, то процесс заканчивается. Выходом процесса служат «Согласованная заявка клиента» и данные по рассчитанным параметрам заказа (на схеме процесса не показаны).
Обратите внимание, что описанный выше процесс приводится далее в виде модели в нотации ARIS еЕРС, так что читатель может сравнить возможности двух нотаций по описанию одного и того же процесса.
Анализ процесса, представленного на рис. 2.24, наводит на мысль о том, что нотацию IDEF3 целесообразно применять в случае относительно простых процессов на нижнем уровне декомпозиции, то есть на уровне рабочих мест. В этом случае схема процесса может служить основой для создания документов, регламентирующих работу исполнителей. Очевидно, что процесс в нотации IDEF3 «плоский». При помощи этой нотации достаточно сложно создавать комбинированные модели, в которых бы сочетались описания потоков работ и процессы управления ими. Этот факт становится в особенности очевидным при сравнении описаний процессов в нотации IDEF3 и IDEF0. Более подробную информацию о правилах создания моделей в нотации IDEF3 можно найти в .

Моделирование бизнес-процессов с BPwin 4.0 Маклаков Сергей Владимирович

1.4.2. Метод описания процессов IDEF3

1.4.2. Метод описания процессов IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован я документирования каждой функции.

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

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается п Ри создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

Работа в IDEF3 требует более подробного описания, чем работа в IDEF0 Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информация заносится во вкладку UOW диалога Activity Properties (рис. 1.4.4).

Рис. 1.4.4. Вкладка UOW диалога Activity Properties Пример значений свойств UOW приведен в табл. 1.4.1.

Таблица 1.4.1. Пример текстового описания компонентов UOW

ТunИспользование

NAMEПодготовка компонентов

"DefinitionПодготавливаются все компоненты компьютера согласно

спецификации заказа

"ObjectsКомпоненты: винчестеры, корпуса, материнские платы,

видиокарты, звуковые карты, дисководы CD-ROM

и флоппи, модемы, программное обеспечение

"Constrains Установка модема требует установки дополнительного пограммного обеспечения

Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 1.4.5) диалога Arrow Properties (пункт контекстного меню Style).

Рис. 1.4.5. Вкладка Style диалога Arrow Properties

Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Стрелка отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.

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

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

Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 1.4.6).

Старт работы Окончание работы Старт работы- Окончание-источника -источника цели работы -цели Старшая или поток объектов

Старт работы Старт работы- Окончание работы Окончание -источника цели -источника работы-цели "" Отношение

Старт работы Старт работы- Отношение Окончание работы -источника цели работы-цели -источника Отношение

Рис. 1.4.6. Временная диаграмма выполнения работ

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны завершены перед началом следующей работы. Различают перекрестки я слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для «ветвления. Для внесения перекрестка служит кнопка Щ (добавить ^диаграмму перекресток - Junction) в палитре инструментов. В диалоге junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.2.

Таблица 1.4.2. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.

Рис. 1.4.7. Перекрестки для слияния и разветвления типа синхронного "И". Здесь после завершения работы 1 одновременно запускаются работы 2 и 4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4

Рис. 1.4.8. Перекрестки для слияния и разветвления типа асинхронного "И". Здесь после завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное)

Рис. 1.4.9. Перекрестки для слияния и разветвления типа асинхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременное)

Рис. 1.4.10. Перекрестки для слияния и разветвления типа синхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание. Если запускается более одной работы, требуется их одновременный запуск. Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания. Если завершается более чем одна работа, требуется их одновременное завершение

Рис. 1.4.11. Перекрестки для слияния и разветвления типа исключающего "ИЛИ". Здесь после завершения работы 1 запускается только одна работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется завершение только одной из работ, 3 или 4

Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:

Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ" (рис. 1.4.12).

Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться.

Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" (рис. 1.4.13).

Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.

Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И"

Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.4.15). Для внесения объекта ссылки служит кнопка ШЗ (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

При внесении объектов ссылок помимо имени следует указывать л объекта ссылки. Типы объектов ссылок приведены в табл. 1.4.3.

Таблица 1.4.3. Типы объектов ссылок

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание включает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.

Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, номера декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.4.16).

Рис. 1.4.16. Номер единицы работы (UOW)

Для описания номер декомпозиции равен 1. Для сценария номер декомпозиции всегда больше 1.

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

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

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

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

Поскольку разные фрагменты модели IDEF3 могут быть созданы разными группами аналитиков в разное время, IDEF3 поддерживает простую схему нумерации работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров, работая при этом независимо. Пример выделения диапазона приведен в табл. 1.4.4.

Таблица 1.4.4. Диапазоны номеров работ

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

Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.

Из книги C++ автора Хилл Мюррей

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

Из книги Справочное руководство по C++ автора Страустрап Бьярн

2.1 Описания Прежде чем имя (идентификатор) может быть использовано в С++ программе, он должно быть описано. Это значит, что надо задать его тип, чтобы сообщить компилятору, к какого вида сущностям относится имя. Вот несколько примеров, иллюстрирующих разнообразие

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

8. Описания Описания используются для определения интерпретации, дваемой каждому идентификатору. Они не обязательно резервируют память, связанную с идентификатором. Описания имеют вид:описание: спецификаторы_описания opt список_описателей opt ; описание_имени

Из книги BPwin и Erwin. CASE-средства для разработки информационных систем автора

8.5 Описания Классов Класс есть тип. Его имя становится typedef-имя (см. #8.8), которое может быть использовано даже внутри самого спецификатора класса. Объекты класса состоят из последовтельности членов.спецификатор_класса: заголовок_класса (* список_членов opt *) заголовок_класса

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

8.10 Описания Перечислений Перечисления являются типами int с именованными констатами.enum_спецификатор: enum идентификатор opt (* enum_список *)enum_список: перечислитель enum_список, перечислительперечислитель: идентификатор идентификатор = константное_выражениеИдентификаторы в

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

14.2 Описания описание: спецификаторы_описания opt список_описателей opt ; описание_имени asm-описаниеописание_имени: сост идентификатор; enum идентификатор;сост:class struct unionasm-описание: asm (строка) ;спецификаторы_описания: спецификатор_описания спецификаторы_описания

Из книги автора

R.17.5 Описания класса спецификация-класса: заголовок-класса { список-членов opt }заголовок-класса: служебное-слово-класса идентификатор opt спец-базовых opt служебное-слово-класса имя-класса спец-базовых optслужебное-слово-класса: class struct unionсписок-членов: описание-члена

Из книги автора

1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3) 1.5.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как

Из книги автора

1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3) 1.4.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD

Из книги автора

1.4.2. Метод описания процессов IDEF3 Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более

Из книги автора

4.14.4. Модификация диаграммы IDEF3 "Сборка продукта" с целью отображения новой информации Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и установки программного обеспечения. Однако теперь в работу "Сборка продукта" включена работа "Тестирование

Из книги автора

Структурные описания Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов - сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются,

& Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.

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

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

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

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

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

Единицы работы – Unit of Work (UOW) , также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами (рис. 6.1.) и имеют имя , выраженное отглагольным существительным, обозначающим процесс действия , одиночным или в составе словосочетания, и номер (идентификатор); другое имя существительное в составе того же словосочетания, зависимое от отглагольного существительного, обычно отображает основной выход (результат) работы (например, "Изготовление изделия"}.

Рис. 6.1. Обозначение работы в диаграмме IDEF3

Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо . В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 6.2.) диалога Arrow Properties (пункт контекстного меню Style ).

Рис. 6.2. Вкладка Style диалога Arrow Properties

Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Стрелка отношения (Relational) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.

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

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

Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 6.3.).

Рис. 6.3. Временная диаграмма выполнения работ

Различают перекрестки для слияния (Fan-in Junction ) и разветвления (Fan-in Junction ) стрелок. Перекресток не может использоваться одновременно для слияния и разветвления.

Для внесения перекрестка служит кнопка в палитре инструментов. В диалоге Junction Туре Editor нужно будет указать тип перекрестка (рис. 6.4.).

Рис. 6.4. Типы перекрестков

Смысл каждого типа приведен в таблице 6.1.

Таблица 6.1. Типы перекрестков

Читайте также:

Ведомые сетью инверторы на тиристорах (на примере трехфазной однополупериодной схемы, анализ, временные диаграммы).
Вопрос № 4. Фазовые равновесия в двухкомпонентных системах. Диаграммы плавкости. Правило рычага.
Выделить диаграмму, на вкладке Конструктор в группе Расположение выполнить команду Переместить диаграмму
Генераторы постоянного тока, энергетическая диаграмма. Классификация.
Графическое изображение изменения гидростатического давления вдоль стенки в зависимости от глубины называется диаграммой распределения давления или эпюрой давления.
Диаграмма направленности антенны. Способы представления: в прямоугольной системе координат; полярной системе координат; картографическое изображение.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах:

Диаграммы относящиеся к первому типу называются диаграммамиОписания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) ,
а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN) .

Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

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

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

Рисунок 1. Пример PFDD диаграммы.

На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементамиповедения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения . Каждый UOB имеет свое имя , отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления .

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Рисунок 2. Пример OSTN диаграммы

На рис.2 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

6) IDEF3-модель отвечает на вопросы "Как система это делает?" Язык IDEF3 - язык диаграмм, помогающий разработчику моделей наглядно представить моделируемые процессы. В IDEF3 входят два типа описаний:

1. процесс-ориентированные в виде последовательности операций (Process Flow Description Diagrams, PFDD);

2. объект-ориентированные, выражаемые диаграммами перехода состояний, характерными для конечно-автоматных моделей (Object State Transition Network, OSTN).

На рис. 1 представлен пример процесс-ориентированной IDEF3-диаграммы. Здесь функции (операции) показаны прямоугольниками с горизонтальной чертой, отделяющей верхнюю секцию с названием функции от нижней секции, содержащей номер функции. Связи, отражающие последовательность выполнения функций, изображаются сплошными линиями-стрелками. Пунктирные линии используются для привязки объектов-комментариев к функциям. Двойная стрелка показывает поток объектов от одной функции к другой.

Рис. 1. IDEF3-диаграмма последовательности операций

Для указания разветвлений и слияний связей (их принято называть перекрестками) используют квадраты, у которых одна или обе вертикальные стороны представлены двойными линиями, а внутри квадрата записан один из символов & , O или X . При разветвлении эти символы означают реакцию всех, некоторых или только одной из последующих функций на входное воздействие соответственно. Аналогичный смысл имеют символы & , O или X при слиянии - последующая функция начинает выполняться после окончания всех, некоторых или только одной из входных операций. Например, перекрестки рис. 2 соответствуют логической операции И, т.е. все входные процессы должны быть завершены, а все выходные процессы должны быть запущены, отличие синхронного И (рис. 2,б) от асинхронного И (рис. 2,а) состоит в том, что в асинхронном случае все выходные процессы запускаются одновременно.

Рис. 2. Перекрестки

На рис. 4 представлен пример объект-ориентированной IDEF3-диаграммы. В таких диаграммах имеются средства для изображения состояний системы, активностей, переходов из состояния в состояние и условий перехода.

Рис. 4. IDEF3-диаграмма перехода состояний

7)IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает система?", то в этих методиках детализируется ответ на вопрос: "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний. Перечисленные методики относятся к так называемым структурным методам.

IDEF4 Объектно-ориентированное проектирование

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

Object-Oriented Design - методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы.

IDEF5 Систематизация объектов приложения

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

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

IDEF6 Использование рационального опыта проектирования

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

Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF8 Взаимодействие человека и системы

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

User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 Учет условий и ограничений

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

Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF14 Моделирование вычислительных сетей

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

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

8) CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

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

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

Среди наиболее важных проблем выделяются следующие:

· достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

· внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;

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

· CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

· негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

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

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства.

CASE средства поддерживают 2 технологии:

All fusion (поддерживает структурную методологию, IDEF0, IDEF1 и т.д.) - datarun

Объектно-ориентированную методологию (UML). – RUP (рациональный унифицированный процесс)

Бизнес идеи

IDEF0

IDEF3

1.4.2. Метод описания процессов IDEF3

Вам также может понравиться