1) Які основні підходи до моделювання Ви знаєте, чим вони відрізняються?

2) Що є контекстом моделі? Що є блоками, а що дугами діаграм IDEF0?

Контекст системы - описание наиболее абстрактного уровня системы в целом и окружающей среды. Контекст модели очерчивает границы моделируемого процесса и описывает его взаимосвязи с внешней средой и другими процессами, определяя модель процесс как часть целого. В контекст IDEFO-модели входит определение единственного субъекта моделирования, его полное, точное и адекватное описание, называемое целью модели, созданное с одной точки зрения на модель. Согласно IDEF0 контекст системы представляется контекстной диаграммой.3. Які види дуг IDEF0 Ви знаєте? Які види зв’язків розрізняють в IDEF0?

Блоки - поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Стрелки – обьекты, связывающее эти функции.

4) Визначити операцію тунелювання дуг. Коли вона може бути доцільною?

Часто бувають випадки, коли окремі інтерфейсні дуги не має сенсу продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії, або навпаки – окремі дуги не мають практичного сенсу вище якогось рівня. Наприклад, інтерфейсну дугу, що зображає "деталь" на вході в функціональний блок "Опрацювати на токарному верстаті" не має сенсу відображати на діаграмах більше високих рівнів – це буде тільки перевантажувати діаграми і робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше деякого рівня. Для вирішення подібних завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунеля" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку – приймача означає той факт, що в дочірньою по відношенню до цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії – в такому випадку, вони спочатку "занурюються в тунель", а потім, при необхідності "Повертаються з тунелю".

5) В чому полягає мета розгалуження моделі? Які умови накладаються на моделі для виконання злиття?

Возможность слияния и расщепления моделей обеспечивает коллективную работу над проектом. После окончания работы все подмодели могут быть слиты в единую модель. С другой стороны, отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели. BPwin использует для слияния и разветвления моделей стрелки вызова. Для слияния необходимо выполнить следующие условия: Обе модели открыты в Bpwin. Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели Стрелка вызова должна исходить из недекомпозируемой работ. Имена контекстной работы модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать Модель-источник должна иметь по крайней мере одну диаграмму декомпозиции. При слиянии моделей объединяются и словари стрелок и работ. В процессе слияния модель-источник остается неизменной и к модели-цели подключается фактически ее копия. Разделение моделей производится аналогично. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова, причем ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.

6) Визначити поняття моделі «As Is», «To be», «Should be».

Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет определить:

 наиболее слабые места  преимущества новых бизнес-процессов

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

Признаками неэффективной работы деятельности могут быть:

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

 неэффективный документооборот

 отсутствие обратных связей по управлению

 отсутствие обратных связей по входу

Найденные в модели AS-IS недостатки можно исправить при создании модели TO-BE (как будет) - модели новой организации бизнес-процессов. Модель TO-BE нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

При создании модели AS-IS разработчиком может быть допущена распространенная ошибка - создание идеализированной модели (например, модель, созданная на основе знаний руководителя, а не конкретного исполнителя работ). Такая модель несет ложную, искаженную информацию и называется SHOULD-BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, затем ее анализ и улучшение бизнес-процессов, т.е. создание модели TO-BE. И только на основе модели TO-BE строится модель данных, прототип и затем окончательный вариант ИС.

Иногда текущая AS-IS и будущая TO-BE модели различаются очень сильно, так что переход от начального состояния к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального состояния системы к конечному.