Для того, щоб ближче познайомитися зі стандартом IDEF0, про нього необхідно дізнатися:

1. Для побудови яких типів моделей даний стандартвикористовується.
2. Які елементи графічної мови включає нотація стандарту та які вимоги до оформлення діаграм існують у рамках стандарту.
3. Які принципи моделювання бізнес-процесів використовуються в стандарті (принцип декомпозиції, принцип обмеження складності, принцип тунелювання).
4. Як можна оцінити побудовані діаграми з погляду їх перевантаженості та збалансованості.

IDEF0 використовується для створення функціональної моделі, що відображає структуру та функції системи, а також потоки інформації та матеріальних об'єктів, що перетворюються цими функціями.

Методологія IDEF0 трохи відрізняється від класичної схеми опису бізнес-процесів DFD. Основною відмінністю є класифікація входів роботи.

Класифікація входів та виходів робіт

Стандарт пропонує наступну типізацію входів робіт:

• Вхід. Входить у роботу ліворуч і показує інформаційні та матеріальні потоки, які перетворюються на бізнес процесі.
• Управління.Входить у роботу згори і показує матеріальні та інформаційні потоки, які перетворюються у процесі, але необхідні його виконання.
• Механізм.Входить у роботу знизу і показує людей, технічні засоби, інформаційні системи тощо, з яких бізнес процес реалізується.
• Результативиходять із блоку праворуч.

Основні елементи діаграми:

Основу графічної мови IDEF0, синтаксис і семантика якого визначені з абсолютною строгістю, складають блоки і стрілки, що з'єднують їх, які формують ієрархію деталізованих діаграм.

Елемент	Графічне відображення та значення	Вимоги до оформлення
Функціональний блок	Зображується у вигляді прямокутника. Представляють функції, що визначаються як діяльність, процес, операція, дія або перетворення.	1. Має унікальний ідентифікаційний номер у правому нижньому кутку; 2. Назва має бути у віддієслівному способі.
Інтерфейснадуга (Стрілка, дуга)	Зображується як односпрямованої стрілки. Подають дані або матеріальні об'єкти, пов'язані з функціями.	1. Повинна мати унікальне найменування. 2. Найменування має бути оборотом іменника. 3.Початком та кінцем дуги можуть бути тільки функціональні блоки. 4.Джерелом може бути тільки вихідна сторона блоку, а приймачем будь-яка з трьох, що залишилися.

IDEF0 - модель:

Модель включає такі документи, які посилаються один на одного:

• Графічні діаграми— головний компонент IDEF0-моделі, який графічно, за допомогою блоків і стрілок та їх з'єднань, відображає інформацію про систему, що моделюється. Блоки становлять основні функції. Ці функції можуть бути розбиті (декомпозіровані) на складові і представлені у вигляді більш докладних діаграм. Процес декомпозиції триває до того часу, поки об'єкт нічого очікувати описаний лише на рівні деталізації, необхідному задля досягнення цілей конкретного проекту.
• Текст;
• Глосарій— Для кожного елемента діаграми створюється та підтримується набір визначень, ключових слів, пояснень, що характеризують об'єкт, який представляє цей елемент Цей набір називається глосарієм і є описом сутності даного елемента. Глосарій гармонійно доповнює наочну графічну мову, забезпечуючи діаграми необхідною додатковою інформацією.

Наприклад, для керуючої інтерфейсної дуги «розпорядження про оплату» глосарій може містити перелік полів відповідного дуги документа, необхідний набір віз тощо.

Принцип декомпозиції при побудові моделі бізнес-процесів

1. Контекстна діаграма: мета та думка

Моделювання бізнес-процесу починається з контекстної діаграми. Ця діаграма називається А-0 (А мінус нуль). На ній система представляється у вигляді одного блоку та дуг, що зображають оточення системи. За допомогою діаграми можна побачити взаємодію моделюваної системи із зовнішнім середовищем, всі її входи та виходи. Діаграма А-0 встановлює область моделювання та межі.

У тексті пояснення до контекстної діаграми повинна бути вказана метапобудови діаграми та зафіксована точка зору. Позиція визначає рівень деталізації, напрямок розвитку моделі і дозволяє розвантажити модель. Так при моделюванні можна відмовитися від деталізації та дослідження окремих елементів, які не є необхідними, виходячи з обраної точки зору на систему.

2. Деталізація

Потім блок, який відображає всю систему, деталізується іншою діаграмою.

Далі кожна функція діаграми може бути деталізована на дочірній. Кожна функція моделюється окремим блоком. Кожен батьківський блок докладно описується дочірньою діаграмою нижчому рівні. Так відбувається доти, доки не буде отримано структуру, що дозволяє відповісти на питання, сформульовані з метою моделювання.

Для досягнення структурної цілісності моделі використовуються такі правила:

• Усі інтерфейсні дуги, які входять у цей блок, чи які з нього фіксуються на дочірній діаграмі.
• При нумерації блоків цифра в правому нижньому куті прямокутника вказує на унікальний порядковий номер самого блоку на діаграмі, а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми.

Принцип тунелювання

Часто трапляються випадки, коли окремі стрілки не мають сенсу продовжувати розглядати в дочірніх діаграмах нижче за якийсь певний рівень в ієрархії, або навпаки — окремі блоки не мають практичного сенсу вище за якийсь рівень. З іншого боку, іноді виникає необхідність позбавитися окремих "концептуальних" стрілок і не деталізувати їх глибше певного рівня.

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

Принцип обмеження складності

Для того, щоб обмежити перевантаженість моделей та зробити їх зручними для сприйняття, у стандарті прийнято відповідні обмеження складності:

• обмеження кількості функціональних блоків на діаграмі трьома-шістьма. Верхня межа (шість) змушує розробника використовувати ієрархії при описі складних предметів, а нижня межа (три) гарантує, що на відповідній діаграмі достатньо деталей, щоб виправдати її створення;
• обмеження кількості підходящих до одного функціонального блоку (що виходять із одного функціонального блоку) інтерфейсних дуг чотирма.

Зрозуміло, суворо дотримуватися цих обмежень зовсім необов'язково, проте, як свідчить досвід, є дуже практичними у реальній роботі.

Кількісний аналіз діаграм: коефіцієнт збалансованості та оцінка імен

Для аналізу діаграми з погляду її перевантаженості та складності для сприйняття використовується кількісний аналіз. Для аналізу використовуються такі показники:

• кількість блоків на діаграмі N;
• рівень декомпозиції діаграми L;
• збалансованість діаграми В;
• число стрілок, що з'єднуються з блоком, А.

Коефіцієнт збалансованості

Необхідно прагнути до того, щоб кількість блоків на діаграмах нижніх рівнів була б нижчою за кількість блоків на батьківських діаграмах.

Так само діаграми мають бути збалансовані. Це означає, що в рамках однієї діаграми не повинно відбуватися ситуації, коли вхідних стрілок і стрілок управління значно більше ніж виходять.

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

Введемо коефіцієнт збалансованості діаграми:

Необхідно прагнути, щоб Кьбув мінімальний для діаграми і зменшувався зі збільшення рівня декомпозиції.

Оцінка імен

Крім аналізу графічних елементів діаграми слід розглядати найменування блоків. Для оцінки імен складається словник елементарних (тривіальних) функцій системи, що моделюється. Фактично в даний словникповинні потрапити функції нижнього рівня декомпозиції діаграм.

Наприклад, для моделі БД елементарними можуть бути функції «знайти запис», «додати запис БД», тоді як функція «реєстрація користувача» вимагає подальшого опису.

Після формування словника та складання пакета діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіги назв блоків діаграм і слів зі словника, це говорить, що достатній рівень декомпозиції досягнутий.

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

L*C

— добуток рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.

1. Функціональне моделювання інформаційної системиіз використанням CASE-технології IDEF.
2. Опис логіки взаємодії та послідовності виконання робіт.

2. План заняття

1. Контроль знань шляхом тестування (тест ІСЕ002).
2. Розробка багаторівневої моделі діяльності інформаційної системи (модель AS – IS) за допомогою CASE-засобу BPwin з використанням технологій IDEF 0і IDEF 3 :
   • Опис властивостей моделі (Model Properties).
   • Створення першого рівня функціональної моделі - розробка контекстної діаграми.
   • Створення ДРУГОГО рівня функціональної моделі – проведення деталізації контекстної роботи та розробка діаграми декомпозиції.
   • Створення третього рівня функціональної моделі – проведення деталізації роботи другого рівня, що реалізує функцію Облік діяльностіорганізації. Виконання цього етапу розробки допускає створення діаграми декомпозиції з використанням однієї з двох методологій – IDEF 0 (1 варіант) або IDEF 3 (2 варіант). За 2-м варіантом створення сценарію та діаграми послідовності виконання окремих робіт (Workflow Diagram) у процесі обліку діяльності виконується за допомогою методології IDEF 3.
3. Розробка словника робіт та словника стрілок, які дозволяють відобразити опис відповідних фрагментів моделі.

1. Функціональне моделювання інформаційної системи з використанням технології IDEFнеобхідно проводити, використовуючи CASE-засіб BPwin, яке завантажується командою Пуск/Програми/Computer Associates/BPwin 4.0/BPwin4.0 . Технологічні процеси IDEF-моделювання викладені у розділі 4 "Теоретичні відомості до практичного заняття".
2. Розробляючи контекстну діаграму, слід враховувати, що властивості моделі можна оформити наступним чином, використовуючи відомості відповідні предметної області, що моделюється:
   • Model Name : Діяльність фірми «Ім'я»;
   • Project (назва проекту): Модель діяльності фірми "Ім'я";
   • ПІБ, група;
   • Scope (область моделювання, що включає мету моделювання, тобто питання, на які побудована модель повинна дати відповідь) – наприклад, «Загальне управління бізнесом компанії: дослідження ринку, закупівля компонентів, тестування та продаж продукції» або «Технологічні, фінансові та управлінські аспекти діяльності фірми»;
   • Time Frame (тип моделі) : AS-IS;
   • Definition (визначення , призначення моделі) : Навчальна модель, що описує діяльність фірми «Ім'я»;
   • Viewpoint (точка зору – особа, чия точка зору прийнята при розробці) : Керівник підприємства та головний менеджер;
   • Status : WORKING;
   • Purpose (ціль) : Моделювати поточні бізнес-процеси фірми «Ім'я» з метою регламентації її діяльності;
   • Source (джерело інформації): Аналіз предметної галузі та аналіз вхідних документів;
   • Author Name : ПІБ.
3. При виконанні декомпозиції контекстної діаграми слід враховувати, що вона, будучи другим рівнемдекомпозиції моделі системи, являє собою підпроцес чи дочірню роботу , реалізовану у вигляді контекстної роботи, яка у цьому випадку виступає як батьківська робота, реалізована у вигляді батьківської діаграми (Parent Diagram) . Діаграма декомпозиції другого рівня повинна містити щонайменше три функціональні блоки, один з яких повинен виконувати функцію моделювання обліку діяльностіорганізації, інші повинні виконувати функцію моделювання бізнес-процесів, що реалізуються в системі.
4. На кожному кроці декомпозиції слід стежити за процесом автоматичного переміщення інтерфейсних дуг (стрілок) на нижні рівні моделі та намагатися без необхідності не допускати створення тунельованих стрілок. У разі появи слід прибирати тунелі.
5. При реалізації третього рівнядекомпозиції слід враховувати, що кожна з розроблених діаграм декомпозиції є третім рівнем декомпозиції робіт другого рівня і є підпроцесабо дочірню роботу, реалізовану у вигляді дочірньої діаграми (Child Diagram)відповідної роботи третього рівня. Усі роботи другого рівня у разі виступають як батьківські роботи, реалізовані у вигляді батьківських діаграм(Parent Diagrams).
6. Декомпозицію роботи другого рівня, що моделює функцію обліку, та створення сценарію взаємодії робіт слід виконувати, використовуючи технологію IDEF 3,яка використовує як функціональні блоки одиниціроботи (Unit of Work, UOW) , а також необхідні об'єкти посилань (Referents) , які можуть бути впроваджені в сценарій зі словника стрілок, так і створені заново.
7. Словник робіт та словник стрілок створюються на кожному рівні декомпозиції моделі, причому необхідною умовою їх розробки є наявність опису роботи (діяльність)та опис даних, зафіксованих на інтерфейсній дузі ( arrow) .
8. Результати роботи зберегти у файлі Функц_модель ІС_Ім'я_ IDEF.bp1 у своїй папці ІСЕ.
9. Приклад узагальненої функціональної моделі наведено в

4. Теоретичні відомості до практичного заняття

4.1. IDEF 0-технологія

Методологія IDEF0 призначена для моделювання діяльності організації. На початковому етапі розробки проекту створюється модель, призначена для опису існуючих бізнес-процесів та технологічних процесів на підприємстві за принципом "AS - IS" ("Як є"), причому, що важливо, вона представляє підприємство з позиції співробітників, які на ньому працюють і досконально знають усі нюанси, у тому числі й неформальні. AS-IS – «що ми робимо сьогодні», перед тим, як перестрибнути на те, «що ми робитимемо завтра».

Модель діяльностіабо, інакше кажучи, функціональна модель Функціональна модельрозглядає систему як набір дій,в якому кожна дія перетворює деякий об'єктабо набір об'єктів . Технологія IDEF 0використовує принцип функціональної декомпозиції систем (розбиття системи на фрагменти). Принцип декомпозиціїозначає, що функціональну модель слід будувати за правилом "зверху вниз" , від спільноговиду моделі до приватниммоделям. Тому зазвичай функціональна модель розв'язання задачі є сукупністю. приватних функціональних моделей .

Функціональні моделі виділяють дії у вигляді уявлення у вигляді спеціального елемента – блоку. Блок – основний структурний елемент функціональної моделі, графічним поданнямякою є діаграма . Найменування дії – віддієслівне іменник або дієслово.В результаті декомпозиції моделі створюється сукупність ієрархічно впорядкованих і взаємопов'язаних діаграм. Кожна діаграма є одиницею опису системи та розташовується на окремому аркуші.

Методологія IDEF 0заснована на чотирьох основних поняттях: функціональний блок (вузол), інтерфейсна дуга, декомпозиція, глосарій.

Функціональний блок

Фундаментальним поняттям технології IDEF 0є поняття функціонального блоку. Він призначений для подання певного виду діяльності (Activity) , яка є деякою конкретною функцію у межах аналізованої системи. Ця функція в свою чергу означає певну дію (набір дій), має фіксовану мету і веде до деякого кінцевого результату.

Функціональний блокзображується прямокутником, сторони якого мають такі значення:

• Верхня сторона – керування.
• Нижня сторона – механізм.
• Права сторона – вихід.
• Ліва сторона – вхід.

Функціональний блок має ім'я, яке задається в дієслівному способі або віддієслівним іменником. Взаємодія між дією і навколишнім світом, у тому числі і з іншими діями, відображається за допомогою інтерфейсних дуг (стрілок).

Інтерфейсна дуга

Інтерфейсна дугавідображає елемент системи, який або обробляєтьсяфункціональним блоком, або вплине на інший впливна діяльність (функцію), відображену цим функціональним блоком. Інтерфейсна дугазображається у вигляді стрілки, яка позначає носія що забезпечує перенесення даних або об'єктів від однієї діяльності до іншої. Стрілки описують взаємодію робіт із зовнішнім світом і між собою, є якоюсь інформацією і називаються іменниками .

Ім'я стрілки вказує її роль (сукупність можливих ролей позначається – ICOM ):

Вхід функціонального блоку I nput .

Управління - C ontrol .

Вихід функціонального блоку – O utput .

Механізм - M echanism .

Вхід (Input) – це матеріал або інформація, які використовуються або перетворюються на роботу для отримання результату (виходу). Стрілки входу може бути.

Управління (Control)– правила, стратегії, процедури чи стандарти, якими керується робота. Воно впливає роботу, але з перетворюється роботою. Стрілка малюється як входить у верхню грань роботи. Кожен функціональний блок повинен мати щонайменше одну стрілку управління.

Часто складно визначити, чи є дані входом чи керуванням. Якщо дані у роботі змінюються чи переробляються, це, швидше за все, вхід, і якщо ні – управління. Якщо визначити статус стрілки складно, рекомендується малювати стрілку керування.

Вихід (Output)– матеріал чи інформація, які виконуються роботою. Обов'язковою є хоча б одна стрілка виходу, що виходить із правої межі роботи.

Механізм виконання (Mechanism)– ресурси, які виконують роботу (наприклад, персонал, верстати, пристрої тощо). Стрілка малюється як входить у нижню грань роботи. Стрілки механізму можуть не зображуватись. У загальному вигляді функціональний блок показано на рис. 2.1.

На рис. 2.1 всі інтерфейсні дуги показані як поіменованих стрілок. За вимогами стандарту кожен функціональний блок повинен мати принаймні один вихід і одне управління, тому що кожне завдання (процес) повинні мати хоча б один вихід і хоча б одне правило її вирішення. Інтерфейсна дуга "Механізм" може не зображуватися.

З кількох функціональних блоків, з'єднаних інтерфейсними дугами необхідним чином, будується функціональна модель

Слід звернути увагу, що стрілки можуть розгалужуватися, здійснюючи необхідні з'єднання функціональних блоків.

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

Створення діаграм у технології IDEF0

При розробці моделі діяльності організації слід використовувати три типи діаграм:

• І тип діаграми – Контекстна діаграма (може бути тільки одна) – вершина деревоподібної структури, яка є найбільш абстрактним рівнем опису системи та її взаємодією із зовнішнім середовищем. У ній визначено контекстна функція;
• II тип діаграми – діаграма декомпозиції .

Діаграми декомпозиції призначені для деталізації роботи та містять родинніроботи, тобто. дочірніроботи, що мають загальну батьківськуроботу. Роботи нижнього рівня – це те саме, що роботи верхнього рівня, але у більш детальному викладі. Діаграми створюються аналітиком у тому, щоб провести сеанс експертизи, т. е. обговорити діаграму з фахівцем предметної області.

Після кожного сеансу декомпозиції проводяться сеанси експертизи – експерти предметної галузі свідчать про відповідність реальних бізнес-процесів створеним діаграмам. Знайдені невідповідності виправляються, і лише після проходження експертизи без зауваженьможна розпочинати наступний сеанс декомпозиції. Так досягається відповідність моделі реальним бізнес-процесам на будь-якому та кожному рівні моделі.

Необхідно встановити кількість робіт не більше шести (3–6), інакше діаграма погано читається (перенасичена). Верхня межа (шість) змушує розробника використовувати ієрархії при описі складних предметів, а нижня межа (три) гарантує, що на відповідній діаграмі достатньо деталей, щоб виправдати її створення.

У діаграмі декомпозиції зліва вгорі розташовується робота найбільш важлива перша, що виконується. Послідовно вниз йдуть роботи менш важливі чи виконувані пізніше.

• ІІІ тип діаграми – Діаграма дерева вузлів показує ієрархічну залежність робіт, але з взаємозв'язку між роботами (ці діаграми може бути скільки завгодно, тому що дерево може бути побудоване на будь-яку глибину і не обов'язково з кореня).

4.2. Технологічний процес IDEF0-моделювання:

Рис. 2.2

CASE-засіб BPWin має простий та зрозумілий користувальницький інтерфейсдля побудови необхідних функціональних моделей та сценаріїв. Він залежить від використовуваної технології. На рис. 2.2 показано вікно BPWin ( Computer Associates BPWin ).

Основна панель інструментів вікна Computer Associates BPwin містить такі кнопки:

	- створіння нової моделі,
	- Відкриття наявної моделі,
	- Збереження побудованої моделі,
	- Друк моделі,
	- Вибір масштабу,
	- масштабування,
	– перевірка правопису,
	– увімкнення/вимкнення навігатора моделі,
	– увімкнення/вимкнення Model Mart.

Навігатор моделі показує склад моделі за рівнем розробки. З його допомогою можна легко та швидко переходити з рівня на рівень. Робота з навігатором моделі аналогічна роботі з Провідником Windows.

Панель спеціальних інструментів містить такі основні кнопки:

Вікно моделі є місцем створення функціональної моделі системи, що досліджується. У ньому будуються та редагуються функціональні блоки, малюються та редагуються стрілки, здійснюється декомпозиція.

Підготовка моделі

1. Натиснути кнопку створення моделі для виклику вікна діалогового вікна BPWin(рис. 2.3):

У діалоговому вікні BPWin зробити такі дії:

• вибрати Business Process (IDEF0);
• задати ім'я моделі та натиснути кнопку ОК;
• у вікні Properties for New Model зафіксувати прізвище автора моделі;
• натиснути кнопку ОК .

1. Командою Model/Model Properties викликати діалогове вікно Model Properties (рис. 4), у якому оформити властивості моделі відповідно до методичних рекомендацій, викладених у розділі 2.

Перший рівень моделювання

1. Оформити функціональний блок у вікні моделі, виконавши такі дії:
   • у контекстному меню функціонального блоку вибрати команду Name… ;
   • у діалоговому вікні Activity Properties (Мал. 2.5) в закладці Nameпоставити ім'яроботи (коротке), що міститься в даний функціональний блок, а в закладці Definitionв полі Definition описроботи;
   • в закладці Fontвстановити шрифт Arial Cyr та встановити прапорці, що дозволяють використовувати цей шрифт у всіх функціональних блоках діаграми ( All activities in this diagram, All activities in this model і Змінити всі випадки з цього font in the model ), після чого натиснути кнопку ОК.

• у діалоговому вікні Arrow Properties (Рис. 2.7), в закладці Nameзадати ім'я стрілки (коротке), а в закладці Definitionв полі Definitionвписати досить докладне описпризначення цієї стрілки;

• у контекстному меню стрілки вибрати команду Font… ;
• у діалоговому вікні Arrow Properties (Рис. 2.8), в закладці Fontвстановити шрифт Arial Cyrта встановити прапорці, які дозволяють використовувати цей шрифт для всіх стрілок діаграми ( All Arrows in this diagram, All Arrows in this model, All instances of this Arrow і Змінити всі випадки цього аркуша в моделі );

1. Оформити стрілку Вихід, лівіМежі правими;
2. Оформити стрілку Управління , навіщо повторити п. 2, замінивши лівіМежі верхніми;
3. Оформити стрілку Механізм, навіщо повторити п. 2, замінивши лівіМежі нижніми.

Другий рівень моделювання

Будь-який рівень моделювання

Для створення декомпозиції моделі на будь-якому рівні моделювання слід виконати такі дії:

• активізувати клацанням конкретний функціональний блок;
• повторити п. 3 для поточного рівня моделі.

1. Тип та стиль оформлення стрілки можна вибрати у діалоговому вікні Arrow Properties (рис. 2.9), що викликається командою Style із контекстного меню стрілки.

1. Для установки перенесення за словамислід, виділивши назву, зменшити розмір прямокутника, після чого він автоматично збільшиться донизу.
2. Кожна стрілка, намальована на діаграмі вищого рівня, має обов'язково бути присутньою на діаграмі більше низького рівня.
3. Нова стрілка, намальована на діаграмі низького рівня (невирішена ( unresolved) стрілка), поміщається у квадратні дужки (тунелі), які підкреслюють відсутність такої стрілки на вищому рівні. Щоб прибрати тунелі слід:
   • вибрати пункт меню Arrow Tunnel ;
   • у діалоговому вікні Border Arrow Editor(Редактор граничних стрілок) вибрати опцію Resolve it to Border Arrow (Дозволити як граничну стрілку). В результаті тунель на поточному рівні буде прибрано, а стрілка з'явиться на попередньому рівні, причому якщо він не перший, то вона – тунельована (рис. 2.10).

1. Щоб копіювати тунельовані стрілки з нижнього рівня на верхній слід:
   • клацнути правою кнопкою миші по квадратних дужках;
   • вибрати пункт меню Off Page Reference;
   • у діалоговому вікні Off_Page Arrow Referenceвибрати діаграму, на яку слід помістити стрілку та встановити необхідний перемикач типу стрілки (рис. 2.11);

• натиснути одну з кнопок: ОК and Go To Diagram (перейти до обраної діаграми) або ОК and Remain In Current Diagram (Залишитися в поточній діаграмі).

Неприпустиме залишення незв'язаних граничних стрілок ( unconnected border arrow) – стрілок, що автоматично переносяться в діаграму декомпозиції з батьківської діаграми (режим міграціїстрілок). Ці стрілки не стосуються робіт і повинні бути пов'язані з роботами в режимі Створення стрілок ( Precedence Arrow Tool – ).

Оформлення правильного розташування та накреслення стрілок за замовчуванням:

• виконати команду Model/Model Properties;
• у вікні Model Properties(рис. 2.12) вибрати закладку Layout ;
• встановити прапорець (опцію) Automatically space arrows у групі Arrows

1. При створенні стрілки зворотнього зв'язкуз управлінняслід встановити опцію вказівки напрямку стрілки Extra Arrowhead (з контекстного меню).
2. Якщо написи на стрілках розташовані невдало (дуже далеко тощо), слід встановити прапорець Squiggle (в контекстному меню) для винесення написи.

1. У діаграмі декомпозиції зліва вгорі розташовується функціональний блок, в якому міститься найбільш важлива перша робота, що виконується. Послідовно вниз йдуть роботи менш важливі чи виконувані пізніше.
2. Перенесення за словамиусередині робіт проводиться в режимі Name Editor… натисканням клавіші Enter.
3. Діагональ у верхньому лівому куті прямокутника означає, що відповідна робота не декомпозірована.
4. Щоб показати не тільки номери дочірніх робіт, які з'являються автоматично, а й префікси (A), слід вибрати команду Model/Model Properties, закладку Numbering, прапорець (опція) Show prefix(Рис. 2.13).

1. Щоб у дочірніх робіт показати номери робіт та номери рівнів (дво-, три-, чотиризначні номери) слід вибрати команду Model/Model Properties, закладку Numbering, прапорець (опція) Use diagram numbering format (Рис. 2.13).
2. Щоб розрізнити різні версії однієї і тієї ж діаграми, окремим версіям слід присвоїти номери (C - number), що задаються довільно в меню Diagram Propertiesна закладці Kit.

Побудова дерева моделі

• командою Diagramm/Add/Node Tree викликати діалогове вікно Node Tree Wizard_Step 1 of 2 (Рис. 2.14);
• провести діалог, вибравши потрібну кількість рівнів дерева вузлів ( Number of levels );
• натиснути кнопку Готово.

4.3. IDEF3-технологія

Технологія IDEF3– це методологія опису процесів, що розглядає послідовність виконанняі причинно-наслідкові зв'язкиміж ситуаціями та подіями. За допомогою IDEF3 описують логіку виконання робіт, черговість їх запуску та завершення.

Технологія IDEF3 використовує категорію сценаріївзадля спрощення структури описів складного багатоетапного процесу. Сценарій (Scenario) – це повторювана послідовність ситуацій чи дій, які описують типовий клас проблем, що у організації чи системі, і навіть – це опис послідовності властивостей об'єкта у межах аналізованого процесу. IDEF0-моделі пов'язані з IDEF3-сценаріями, тому що кожна IDEF0-модель може бути представлена ​​у вигляді одного або кількох IDEF3-сценаріїв.

Технологія IDEF3 призначена для забезпечення збору даних про процес та дозволяє:

• документувати наявні дані щодо технології виконання процесу, виявлені, скажімо, у процесі опитування фахівців предметної галузі;
• аналізувати існуючі процеси та розробляти нові;
• моделювати ситуації, визначаючи ситуації, які потребують прийняття рішення , що впливає на життєвий цикл процесу, наприклад, зміна конструктивних, технологічних або експлуатаційних властивостей кінцевого продукту;
• сприяти прийняттю оптимальних рішень під час реорганізації процесу.

Сценарій у IDEF3-технології

Діаграми сценаріївописують дії та події, які мають бути оброблені за заданий проміжок часу. Сценарій супроводжується описом процесів та може бути використаний для документування кожної функції системи. Отже, сценарії є частиною системного аналізу, тому що дають можливість проаналізувати ситуацію в часі та описати об'єкти, що беруть участь в одному процесі одночасно.

При використанні IDEF3-технології в основі всіх побудов лежать два типи діаграм:

1. Діаграма опису послідовності етапів процесу.
2. Діаграма стану об'єкта.

Використовуються такі стандартні умовні позначення:

	Функціональний елемент поведінки,
	Передача дії від одного функціонального елемента поведінки (попереднього) до іншого (наступного) ( Precedence ),
	Перехід потоку даних від роботи до роботи ( Object flow ),
	Зв'язок даних із роботою ( Referent ),
	Зв'язок між роботами ( Relational ),
	Стан об'єкту.

Регламентація послідовності виконання одиниць роботи здійснюється запровадженням у діаграму перехресть (Junction) різного призначення.

Символ Jперехрестя може приймати одне з наступних значень:

• & – злиття результатів всіх дій, якщо стрілки входять у перехрестя; запусквсіх дій, якщо стрілки виходять із нього;
• Про – злиттярезультатів дій, якщо хоча б одна з вхідних дій завершена; запускхоча б однієї дії;
• Х - злиттялише однієї дії з низки, що входять у перехрестя; запусклише однієї дії з тих, що виходять із нього.

Ілюстрацією використання перехрестя в діаграми опису послідовності етапів процесує рис. 2.15. З нього випливає, що перехрестя – це засіб побудови складних розгалужених технологічних процесів.

Опис технології, що розробляється або досліджується у вигляді спочатку діаграм опису послідовності етапів технологічного процесу , а потім у вигляді діаграми станів об'єктівдає повне уявлення про виконувані дії та результати їх застосування.

	Робота 3 відбувається, коли виконані Робота 1 та Робота 3
	Робота 1 та Робота 2 відбуваються разом
	Робота 3 відбувається, коли виконані Робота 1 або Робота 2, або обидві разом
	Робота 1 та Робота 2 відбуваються разом або окремо
	Робота 3 відбувається, коли виконані Робота1 або Робота2
	Відбувається робота 1 або робота 2

Отже, в руках менеджерів та розробників інформаційних систем з'являється сильний інструмент створення сценаріїв складних процесів управління, які вимагають вивчення та автоматизації.

4.4. Технологічний процес IDEF3-моделювання

Підготовка моделі

1. Натиснути кнопку створення моделі.
2. У діалоговому вікні BPWinвиконати такі дії:
   • вибрати Process Flow (IDEF3);
   • вказати ім'я моделі;
   • натиснути кнопку ОК;
   • у діалоговому вікні Properties for New Modelпідтвердити вказані властивості.

Оформлення дії

1. Натиснути кнопку створення дії ( Activity Box Tool ).
2. У потрібному місці вікна моделі клацнути лівою кнопкою миші.
3. У контекстному меню дії вибрати команду Name…
4. У діалоговому вікні Activity Properties, в закладці Name вказати ім'я дії (рис. 2.16).

1. У діалоговому вікні Activity Propertiesв закладці Font поставити Arial Cyr, ОК.

Оформлення даних

1. Натиснути кнопку створення даних. ( Referent Tool ).
2. У потрібному місці вікна Referentклацнути лівою клавішею миші, щоб впровадити імена даних із створеного словника сутностей (опція Entity) або зі створеного словника стрілок (опція Arrow), або створити їх заново (опція Інші) (рис. 2.17).

1. У діалоговому вікні Referent Properties (Рис. 2.18), в закладці Fontпоставити Arial Cyrвстановити потрібні прапорці та натиснути кнопку ОК.

5. Домашнє завдання до наступного заняття

1. Продумати та визначити матеріальні об'єкти або фізичні особи, Що являють собою джерела або приймачі інформації (зовнішні сутності).
2. Продумати та розробити реляційну модельданих, що обробляються інформаційною системою:
   • скласти список сутностей та їх атрибутів,
   • показати стосунки між сутностями.
3. На основі розробленого технічного завданняпродумати та запропонувати викладачеві назви окремих робіт, що реалізуються в системі у процесі виконання кожної з ключових робіт, поміщених у діаграму декомпозиції другого рівня.
4. Виконання п.п. 1–3 домашнього завдання зафіксувати у файлі з ім'ям « Інформація до 3-го заняття.doc », виконаному в Word, та подати викладачеві.
5. Розробити розділ « Теоретичні відомості до практичного заняття» практикуму з 3-го заняття.

1.6. Фрагмент діаграми дерева вузлів (Node Tree Diagram) під час виконання декомпозиції блоку облік діяльності за другим варіантом (IDEF3)

Словник робіт (Activity Dictionary)

Name	Definition
	Аналіз інформації, ліченої з БД, задоволення заданим критеріям
Аналіз документів	Аналіз супровідних та вхідних документів на відповідність нормативам
Ведення БД	Виконання операцій оновлення даних
ВИКОНАНА РОБОТА	Ім'я контекстної функції, що визначає МЕТА та КОРДОНИ моделювання
Завершальна обробка	Прийняття та формулювання рішення (ПОЗИЛЬНОГО у разі задоволення даних заданим критеріям та НЕГАТИВНОГО в іншому випадку), а також створення та оформлення необхідних документів
Контроль якості та тестування	Робота, що завершує виробничий процес чи процес розробки
Обробка даних	Виконання операцій пошуку та аналізу даних та прийняття рішення на основі проведеного аналізу
Обробка результатів контролю якості	Систематизація та аналіз результатів на відповідність стандарту
Обробка результатів тестування	Аналіз результатів на справність, надійність та живучість
Оформлення документів	Прийом документів та вибір інформації для занесення до бази даних
	Пошук даних у таблицях БД на основі запитів, створених користувачем
Поповнення БД	Занесення нових даних до таблиці БД
Прийом та реєстрація документів	Прийом та реєстрація вхідних супровідних документів
Виробництво чи розробка	Найменування ключового бізнес-процесу компанії (модель виробничої частини предметної області)
Робота на 1-му етапі бізнес-процесу1	Дія, що узагальнює технологічні операції на першій стадії виробничого процесу
Робота на 2-му етапі бізнес-процесу1	Дія, що узагальнює технологічні операції на другій стадії виробничого процесу
Робота на 3-му етапі бізнес-процесу1	Дія, що узагальнює технологічні операції на третій стадії виробничого процесу
Обробка результатів виробничої діяльності	Прийом та аналіз документів за результатами виконання поточних робіт та контролю
Редагування БД	Зміна записів у таблицях БД
ОБЛІК ДІЯЛЬНОСТІ	Обробка документації та ведення звітності (модель невиробничої частини предметної галузі)

Словник стрілок (Arrow Dictionary)

Name	Definition
	Об'єкти, які не відповідають вимогам стандарту
ВХІДНІ ДАНІ	Вхідні документи та об'єкти обробки
Вхідні дані БД	Дані для запису в таблиці БД
Вхідні документи	Документи, що супроводжують об'єкти обробки та документи, що ініціюють бізнес-процес
ВИХІДНІ ДАНІ	Вихідні документи, нові та змінені об'єкти
Вихідні документи	Документи (бланки, звіти, інструкції, відомості, договори тощо), що створюються в процесі обліку
Державний стандарт	Державний стандарт на оформлення документації
Дані таблиць БД	Дані, які зчитуються з таблиць БД
Дані, отримані в результаті аналізу	Інформація, призначена для оформлення документів, що виходять, і використовувана при прийнятті рішення
Дані, що характеризують результати роботи з документами	Інформація, що відображає реквізити (якісні та кількісні характеристики) оброблюваних об'єктів
Документи за результатами тестування та контролю	Документи, що відображають дані, отримані на етапі завершальної стадії обробки об'єктів
Посадова інструкція	Інструкція, що відображає посадові обов'язкивиконавця
Запити користувача
Нові та змінені об'єкти	Об'єкти, створені та змінені у процесі реалізації виробничого циклу
Об'єкти БД	Таблиці, форми, запити, звіти, макроси та модулі
Об'єкти обробки	Об'єкти, що змінюються на різних стадіях виконання виробничого процесу
Об'єкти, оброблені на 1-му етапі	Об'єкти, що змінюються на 1-му етапі виробничого процесу
Об'єкти, оброблені на 2-му етапі	Об'єкти, що змінюються на 2-му етапі виробничого процесу
Об'єкти, оброблені на 3-му етапі	Об'єкти, що змінюються на 3-му етапі виробничого процесу
	Відділ технічного контролю, що перевіряє об'єкт, що створюється, на задоволення вимог стандарту
Підрозділи компанії та фахівці-професіонали	Суб'єкти, що у виробничому процесі чи процесі розробки
ПРАВИЛА ВИКОНАННЯ	Правила перетворення процесів та даних
Правила обліку	Система обліку та оформлення документації, що супроводжує виробничий процес чи процес розробки
ПРИЙНЯТЕ РІШЕННЯ	Позитивне або негативне рішення, що приймається залежно від задоволення даних, що аналізуються заданим критеріям
Прийняті документи	Документи, що пройшли реєстрацію
Програмне забезпечення	Платформа, на базі якої реалізована БД, що розробляється
Результати аналізу документів	Результати, отримані після аналізу вхідних та супровідних документів на відповідність нормативам
Результати контролю якості
Результати пошуку	Інформація з таблиць БД, отримана за запитами користувача
Результати тестування	Дані, отримані на завершальному етапі обробки
Посібник користувача	Інструкції та правила для роботи з БД
Служба обліку	Підрозділи, зайняті процесом обліку та оформлення документації
Супровідні документи	Документи, що супроводжують вхідні об'єкти обробки
Фахівці-професіонали	Суб'єкти, що у виробничої діяльності
Технологічна інструкція	Послідовність операцій технологічного процесу
Запити користувача	Запити, що створюються користувачем для вибірки необхідної інформаціїз БД та для створення вихідних документів
МЕХАНІЗМ ВИКОНАННЯ	Ресурси, що виконують перетворення вхідних даних у вихідні
Нові записи	Записи у таблицях БД, що з'явилися після занесення нових даних
Корекція
	Суб'єкт, який проводить експертизу

Версія для друку

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

При побудові моделі має бути поставлена мета моделювання,що відповідає на такі питання:

· Чому цей процес повинен бути змодельований?

· Що має показувати модель?

· Що може отримати читач?

Приклади визначення мети: "ідентифікувати та визначити поточні проблеми, уможливити аналіз потенційних поліпшень", "ідентифікувати ролі та відповідальність службовців для написання посадових інструкцій", "визначити можливість автоматизації ...", "Регламентувати процес ..." і т.д.

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

Основний концептуальний принцип методології IDEF - представлення будь-якої системи, що вивчається у вигляді набору взаємодіючих і взаємопов'язаних блоків, що відображають процеси, операції, дії, що відбуваються в системі, що вивчається. У IDEF0 усе, що відбувається у системі та її елементах, прийнято називати функціями. Кожній функції ставиться у відповідність блок.

Функціональні блоки на діаграмах зображуються прямокутниками, що означають пойменовані процеси, функції, роботи або операції, які відбуваються протягом певного часу і мають результати, що розпізнаються. Усередині кожного блоку міститься його ім'я та номер. Ім'я блоку має бути активним дієсловом, дієслівним оборотом або віддієслівним іменником, що позначає дію.

Блоки IDEF0 розміщуються за рівнем важливості, як її розуміє автор діаграми. Цей відносний лад називається домінуванням. Домінування розуміється як вплив, який один блок чинить інші блоки діаграми. Найбільш домінуючий блок зазвичай розміщується у верхньому лівому куті діаграми, а найменш домінуючий – у правому кутку.

Інтерфейси, за допомогою яких блок взаємодіє з іншими блоками або із зовнішнього по відношенню до моделюється середовище, видаються стрілками, що входять до блоку або виходять із нього. Кожна сторона функціонального блоку має стандартне значення з погляду зв'язку блок/стрілка. Стандартне розташування стрілок показано на рис.1.

Рис. 1. Контекст IDEF0.

Стрілкиописують взаємодію блоків із зовнішнім світом та між собою. Стрілки є деяку інформацію і називаються іменниками або оборотами іменника.

У IDEF0 розрізняють п'ять типів стрілок:

1. Вхід - матеріал або інформація, що використовуються або перетворюється функціональним блоком для отримання результату (виходу). Допускається, що робота може мати жодної стрілки входу.

2. Управління - правила, стратегії, процедури чи стандарти, якими керується блок. Управління впливає блок, але з перетворюється ним.

3. Вихід – матеріал або інформація, що виробляються блоком. Блок без результату немає сенсу і повинен моделюватися.

4. Механізм - ресурси, що виконують блок, наприклад, персонал підприємства, верстати, пристрої тощо. На розсуд аналітика стрілки механізму можуть не зображуватися в моделі.

5. Виклик (Call) – спеціальна стрілка, що вказує на іншу модель роботи. Стрілка виклику використовується для вказівки того, що деяка робота виконується за межами системи, що моделюється.

Стрілки на контекстній діаграмі служать для опису взаємодії системи з навколишнім світом. Граничні стрілки- стрілки, які починаються біля межі діаграми, а закінчуються у роботи чи навпаки. Внутрішні стрілкизв'язують блоки між собою. Розрізняють п'ять видів зв'язків робіт.

1. Зв'язок по входу – стрілка виходу вищого блоку прямує на вхід нижчестоящого (рис. 2).

Рис. 2. Відношення "вихід-вхід".

2. Зв'язок з управління - вихід вищого блоку прямує на керування нижчестоящого (рис. 3).

Рис. 3. Відношення "вихід-управління".

3. Зворотний зв'язок з управління - вихід нижчого блоку спрямовується на управління вищого (рис. 4).

Рис. 4. Зворотній зв'язок з управління

4. Зворотний зв'язок по входу - вихід нижчого блоку прямує на вхід вищого (рис. 5).

Рис. 5. Відношення зворотного зв'язку по входу

5. Зв'язок вихід-механізм – вихід одного блоку спрямовується на механізм іншого (рис. 6).

Рис. 6 Зв'язок «вихід-механізм».

У нотації IDEF0 опис системи (модель) організовано як ієрархічно впорядкованих і взаємозалежних діаграм. Спочатку проводиться опис системи загалом та її взаємодії з навколишнім світом (контекстна діаграма). Контекстна діаграма включає тільки один блок, що характеризує всю сукупність процесів, що моделюються, без подробиць.

Рис. 7 Приклад контекстної діаграми IDEF0.

Після цього проводиться функціональна декомпозиція (рис.8) – цей блок діяльності (великий процес) поділяється на великі підпроцеси – і кожен підпроцес описується окремо (діаграми декомпозиції). Потім кожен підпроцес декомпозується більш дрібні - і так далі до досягнення необхідної деталізації опису.

Рис.8 Приклад діаграми декомпозиції IDEF0.

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

Визначення

IDEF0 (Integration Definition for Function Modeling) – методологія функціонального моделювання для опису функцій підприємства, що пропонує мову функціонального моделювання для аналізу, розробки, реінжинірингу та інтеграції інформаційних систем бізнес-процесів; або аналізу інженерії розробки програмного забезпечення (or software engineering analysis).

Методологія IDEF0 є розвитком методу структурного аналізу та проектування SADT (Structured Analysis and Design Technique).

IDEF0 як стандарт було розроблено у 1981 році в рамках програми ICAM (Integrated Computer Aided Manufacturing – інтегрована комп'ютерна підтримка виробництва).

IDEF0 – Integration DEFinition language 0 – заснований на SADT і у своїй вихідній формі включає одночасно: визначення мови графічного моделювання (синтаксис та семантику) та опис повної (comprehensive) методології розробки моделей.

Остання редакція IDEF0 була випущена у грудні 1993 року Національним Інститутом стандартів і технологій США (NIST).

У 1993 році IDEF0 була прийнята як федеральний стандарт у США, а в 2000 році – як стандарт у Російській Федерації.

Застосування IDEF0

IDEF0 використовується для створення функціональної моделітобто результатом застосування методології IDEF0 до системи є функціональна модель IDEF0.

Функціональна модель– це структурне уявлення функцій, діяльності чи процесів у межах моделируемой системи чи предметної області.

Методологія IDEF0 може бути використана для моделювання широкого спектру як автоматизованих, і неавтоматизованих систем.

Для систем IDEF0, що проектуються, може бути використана спочатку для визначення вимог і функцій і потім для реалізації, що задовольняє цим вимогам і виконує ці функції.

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

Цілі стандарту IDEF0

Основні цілі (objectives) стандарту:

задокументувати та роз'яснити техніку моделювання IDEF0 та правила її використання;

забезпечити засоби для повного та одноманітного (consistently) моделювання функцій системи або предметної області, а також даних та об'єктів, які пов'язують ці функції;

забезпечити мову моделювання, яка незалежна від CASE методів або засобів, але може бути використана за допомогою цих методів та засобів;

забезпечити мову моделювання, яка має такі характеристики:

загальний(generic) – для аналізу систем та предметних областей;

строгий та точний(rigorous and precise) – для створення коректних, придатних для використання моделей);

короткий(concise) – для полегшення розуміння, комунікації, згоди між зацікавленими особами та перевірки. (to facilitate understanding, communication, consensus and validation);

абстрактний(Conceptual) – для подання функціональних вимог, незалежних від фізичних чи організаційних реалізацій;

гнучкий– для підтримки різних фаз життєвого циклупроекту.

Суворість та точність(Rigor and Precision)

Правила IDEFØ вимагають достатньої строгості і точності для задоволення потреб без надмірних обмежень аналітика. IDEFØ правила включають таке:

управління деталізацією (control of the details communicated at each level) – від трьох до шести функціональних блоків кожному рівні декомпозиції;

пов'язаний контекст (Bounded Context) – не повинно бути недостатніх або зайвих, що виходять за встановлені рамки деталей;

пов'язаність інтерфейсу діаграм (Diagram Interface Connectivity) – номери вузлів, функціональних блоків, C-numbers та Detail Reference Expression);

пов'язаність структури даних. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

унікальні мітки і заголовки (Unique Labels and Titles) – відсутність назв, що повторюються;

синтаксичні правила для графіки (Syntax Rules for Graphics) - функціональні блоки та стрілки;

обмеження на розгалуження стрілок даних (Data Arrow Branch Constraint) – позначки для обмежень потоків даних на розгалуженнях;

поділ даних на Вхід та Управління (Input versus Control Separation) – правило визначення ролі даних);

маркування стрілок даних. Data Arrow Label Requirements (minimum labeling rules);

наявність управління (Minimum Control of Function) - всі функції повинні мати мінімум одне управління;

ціль і думка (Purpose and Viewpoint) – всі моделі мають формулювання мети і погляду.

Основні поняття IDEF0

В основі методології лежать чотири основні поняття:

функціональний блок;

інтерфейсна дуга;

декомпозиція;

глосарій.

Функціональний блок(Activity Box) являє собою деяку конкретну функцію в рамках системи, що розглядається.

За вимогами стандарту назва кожного функціонального блоку має бути сформульована у дієслівному способі (наприклад, "здійснювати послуги").

На діаграмі функціональний блок зображується прямокутником (рис.). Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

верхня сторона має значення "Управління" (Control);

ліва сторона має значення "Вхід" (Input);

права сторона має значення "Вихід" (Output);

нижня сторона має значення "Механізм" (Mechanism).

Рис. Функціональний блок

Інтерфейсна дуга/стрілка(Arrow) відображає елемент системи, який обробляється функціональним блоком або інший вплив на функцію, представлену даним функціональним блоком. Інтерфейсні дуги часто називають потоками чи стрілками.

За допомогою інтерфейсних дуг відображають різні об'єкти, що в тій чи іншій мірі визначають процеси, що відбуваються в системі. Такими об'єктами можуть бути елементи реального світу (деталі, вагони, співробітники тощо) або потоки даних та інформації (документи, дані, інструкції тощо).

Залежно від того, до якої зі сторін функціонального блоку підходить дана інтерфейсна дуга, вона називається «вхідною», «вихідною» або «керуючою».

Необхідно відзначити, що будь-який функціональний блок за вимогами стандарту повинен мати, принаймні, одну інтерфейсну дугу, що управляє, і одну вихідну. Це і зрозуміло – кожен процес має відбуватися за якимись правилами (відображається керуючою дугою) і повинен видавати певний результат (дуга, що виходить), інакше його розгляд не має жодного сенсу.

Обов'язкова наявність керуючих інтерфейсних дуг одна із головних відмінностей стандарту IDEF0 з інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

Декомпозиція(Decomposition) є основним поняттям стандарту IDEF0. Принцип декомпозиції застосовується при розбиття складного процесу на його функції. У цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

Декомпозиція дозволяє поступово та структуровано представляти модель системи у вигляді ієрархічної структури окремих діаграм, що робить її менш перевантаженою та легко засвоюваною.

Останнім із понять IDEF0 є глосарій(Glossary).

Для кожного з елементів IDEF0 – діаграм, функціональних блоків, інтерфейсних дуг – існуючий стандарт має на увазі створення та підтримання набору відповідних визначень, ключових слів, оповідальних викладів тощо, які характеризують об'єкт, відображений цим елементом.

Цей набір називається глосаріємє описом сутності даного елемента. Глосарій гармонійно доповнює наочну графічну мову, забезпечуючи діаграми необхідною додатковою інформацією.

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

У тексті пояснення до контекстної діаграми повинна бути вказана мета(Purpose) побудови діаграми у вигляді короткого опису та зафіксована точка зору(Viewpoint).

Визначення та формалізація ціліРозробка IDEF0-моделі є вкрай важливим моментом. Фактично ціль визначає відповідні області в досліджуваній системі, на яких необхідно фокусуватися в першу чергу.

Точка зорувизначає основний напрямок розвитку моделі та рівень необхідної деталізації. Чітке фіксування погляду дозволяє розвантажити модель, відмовившись від деталізації та вивчення окремих елементів, які є необхідними, з обраної погляду систему.

Більшість із тих, хто займається реалізацією проектів, пов'язаних із створенням чи розвитком корпоративних інформаційних систем, згодні з тезою, що замовнику потрібна інформаційна система, яка підвищує ефективність діяльності підприємства. Проте замовники та розробники інформаційних систем досі розмовляють на різних мовах: вони по-різному розуміють - що означає підвищити ефективність підприємства

Розробники інформаційних систем дуже часто під підвищенням ефективності розуміють зростання кількості робочих станцій у локальній обчислювальній мережі (ЛВС) підприємства, зростання пропускної спроможності ЛОМ, зростання кількості документів, обробка яких здійснюється на автоматизованих робочих місцях (АРМах) тощо.

Замовники під підвищенням ефективності підприємства розуміють зростання продуктивності праці, зменшення собівартості та підвищення якості вироблених продуктів та послуг. Останнім часом у життя замовників стрімко вриваються нові умови та нові поняття: стратегія розвитку, ключова компетенція, бізнес-архітектура, бізнес-правила та багато іншого.

Для того, щоб замовник та розробник інформаційної системи розуміли один одного, необхідно, щоб розробник переорієнтувався з вирішення технічних завдань щодо створення або розвитку інформаційної системи на вирішення комплексних завдань щодо підвищення ефективності діяльності підприємства замовника. При такому підході на перший план постає проблема ефективного способувивчення сфери діяльності замовника:

• обстеження існуючої бізнес-архітектури, ділових процесів, бізнес-правил, інформаційних потоків;
• ідентифікація проблем, "вузьких" місць, які негативно впливають на ефективність діяльності підприємства;
• розробка та реалізація заходів щодо усунення наявних проблем та зміни бізнес-архітектури підприємства, розбудови ділових процесів;
• розробка конкретного проекту корпоративної інформаційної системи, реалізація цього проекту та супровід у майбутньому.

У рамках такого підходу підвищити ефективність роботи розробника інформаційних систем покликані інструментальні засоби, призначені для моделювання підприємства та реінжинірингу ділових процесів. Одним із представників такого сімейства інструментальних засобів є CASE-інструменти для функціонального моделювання ділових процесів.

У цій статті наведено огляд одного класу засобів для функціонального моделювання ділових процесів, орієнтованих використання методології IDEF0.

IDEF0 – методологія функціонального моделювання

У ході реалізації програми інтегрованої комп'ютеризації виробництва (ICAM), запропонованої свого часу ВПС для аерокосмічної промисловості США, було виявлено потребу у розробці методів аналізу взаємодії процесів у виробничих системах. Для задоволення цієї потреби було розроблено методологію IDEF0 (Integrated Definition Function Modeling), яка в даний час прийнята як федеральний стандарт США. Методологія успішно застосовувалася в різних галузях, продемонструвавши себе як ефективний засібаналізу, проектування та подання ділових процесів. Нині методологія IDEF0 широко застосовується у США, а й у світі. У Росії IDEF0 успішно застосовувався у державних установах (наприклад, у Державній Податковій Інспекції), в аерокосмічній промисловості (при проектуванні космодрому в Плесецьку), у Центральному Банку та комерційних банках Росії, на підприємствах нафтогазової промисловості та підприємствах інших галузей.

Основні поняття IDEF0

В основі методології IDEF0 лежить поняття блоку, який відображає деяку бізнес-функцію. Чотири сторони блоку мають різну роль: ліва сторона має значення "входу", права - "виходу", верхня - "управління", нижня - "механізму" (див. рис. 1).

Взаємодія між функціями IDEF0 представляється у вигляді дуги, яка відображає потік даних або матеріалів, що надходить з виходу однієї функції на вхід інший. Залежно від того, з якою стороною блоку пов'язаний потік, його називають відповідно "вхідним", "вихідним", "керуючим".

Принципи моделювання в IDEF0

У IDEF0 реалізовано три базові принципи моделювання процесів:

• принцип функціональної декомпозиції;
• принцип обмеження складності;
• принцип контексту.

Принцип функціональної декомпозиції є спосіб моделювання типової ситуації, коли будь-яка дія, операція, функція можуть бути розбиті (декомпозіровані) на більш прості дії, операції, функції. Іншими словами, складна бізнес-функція може бути представлена ​​як сукупність елементарних функцій. Представляючи функції графічно, як блоків, можна зазирнути всередину блоку і детально розглянути її структуру і склад (див. рис. 2).

Принцип обмеження складності. При роботі з IDEF0 діаграмами суттєвою є умова їх розбірливості та зручності читання. Суть принципу обмеження складності полягає в тому, що кількість блоків на діаграмі має бути не менше двох та не більше шести. Практика показує, що дотримання цього принципу призводить до того, що функціональні процеси, представлені як IDEF0 моделі, добре структуровані, зрозумілі і легко піддаються аналізу.

Принцип контекстної діаграми. Моделювання ділового процесу починається з побудови контекстної діаграми. На цій діаграмі відображається тільки один блок - головна бізнес-функція системи, що моделюється. Якщо йдеться про моделювання цілого підприємства або навіть великого підрозділу, головна бізнес-функція не може бути сформульована, як, наприклад, "продавати продукцію". Головна бізнес-функція системи - це "місія" системи, її значення у навколишньому світі. Не можна правильно сформулювати головну функціюпідприємства, не маючи уявлення про його стратегію.

При визначенні головної бізнес-функції необхідно завжди мати на меті моделювання і точку зору на модель. Те саме підприємство може бути описано по-різному, залежно від того, з якого погляду його розглядають: директор підприємства та податковий інспектор бачать організацію зовсім по-різному.

Контекстна діаграма грає ще одну роль функціональної моделі. Вона "фіксує" межі моделюється бізнес-системи, визначаючи те, як модельована система взаємодіє зі своїм оточенням. Це досягається за рахунок опису дуг, з'єднаних із блоком, що представляє головну бізнес-функцію.

Застосування IDEF0

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

Побудова моделі ЯК Є. Обстеження підприємства є обов'язковою частиною будь-якого проекту створення чи розвитку корпоративної інформаційної системи. Побудова функціональної моделі ЯК Є дозволяє чітко зафіксувати, які ділові процеси здійснюються на підприємстві, які інформаційні об'єктивикористовуються при виконанні ділових процесів та окремих операцій. Функціональна модель ЯК Є є відправною точкою для аналізу потреб підприємства, виявлення проблем та "вузьких" місць та розробки проекту вдосконалення ділових процесів.

Бізнес-правила. Модель ділових процесів дозволяє виявити та точно визначити бізнес-правила, що використовуються у діяльності підприємства.

На рис. 3 представлений фрагмент функціональної моделі документообігу. Під час виконання операції "сортувати документи" використовується бізнес-правило: "реєстрації не підлягають: документи, надіслані в копії для інформації, телеграми та листи про дозвіл відряджень та відпусток...". Це правило зафіксовано в інструкції з документообігу. Функціональна модель дозволяє не тільки ідентифікувати існування цього правила, але також визначити, при виконанні якої операції та на якому робочому місці вона має застосовуватись.

У рамках функціональної моделі бізнес-правило виглядає наступним чином: "якщо до приймальні надійшов документ, призначений керівництву, він підлягає сортуванню, внаслідок якого на підставі інструкції визначається, чи підлягає документ реєстрації чи ні".

Якщо під час розробки інформаційної системи буде враховано це бізнес-правило, то така система функціонуватиме неадекватно.

Дуже часто бізнес-правила на підприємстві не записані в інструкції: вони є, але і їх немає. В результаті спроби змінити що-небудь у діяльності підприємства або підрозділу можуть закінчитися невдачею тільки тому, що ці зміни суперечать бізнес-правилам, що склалися.

Інформаційні об'єкти. Функціональна модель дозволяє ідентифікувати всі інформаційні об'єкти, якими оперує підприємство своєї діяльності. На відміну від інформаційних моделей (Data Flow Diagrams, IDEF1X), функціональна модель IDEF0 відображає, як саме використовуються інформаційні об'єкти в рамках ділових процесів.

Побудова моделі ЯК БУДЕ. Створення та впровадження корпоративної інформаційної системи призводить до зміни умов виконання окремих операцій, структури ділових процесів та підприємства загалом. Це призводить до необхідності зміни системи бізнес-правил, які використовуються на підприємстві, модифікації посадових інструкцій працівників. Функціональна модель ЯК БУДЕ дає змогу вже на стадії проектування майбутньої інформаційної системи визначити ці зміни. Застосування функціональної моделі ЯК БУДЕ дозволяє не лише скоротити терміни впровадження інформаційної системи, а й знизити ризики, пов'язані з несприйнятливістю персоналу до інформаційних технологій.

Розподіл ресурсів. Функціональна модель дозволяє чітко визначити розподіл ресурсів між операціями ділового процесу, що дозволяє оцінити ефективність використання ресурсів.

Особливо це завдання актуальне під час створення нових ділових процесів для підприємства. Наприклад, компанія, яка спеціалізується на розробці замовного програмного забезпечення, ухвалила рішення створити власну службу збуту Функціональна модель ділового процесу з продажу програмного забезпечення дозволить керівництву компанії чітко визначити, які ресурси необхідно виділити для того, щоб забезпечити функціонування служби збуту, скільки співробітників необхідно залучити до роботи в новій службі, які функціональні обов'язки ці співробітники повинні виконувати і т.д.

Програмні системи IDEF0

В даний час існує безліч CASE засобів, що підтримують функціональне моделювання стандарту IDEF0.

ВИСНОВОК

Методологія функціонального моделювання IDEF0 є досить простим інструментом, який дозволяє розробникам корпоративних інформаційних систем вивчити сферу діяльності замовника та вирішувати завдання щодо підвищення ефективності цієї діяльності.

Застосування функціонального моделювання дозволяє вирішувати не лише технічні проблемизамовника, пов'язані з інформаційними технологіями, але також проблеми, що стосуються сфери діяльності замовника. Це дозволяє перетворити проект інформаційної системи з "пачки паперу", за яку замовник не хоче платити, на послугу, яка може принести замовнику додатковий ефект, який можна порівняти з подальшою автоматизацією.