Програма для створення idef0 діаграм. Знайомство з нотацією IDEF0 та приклад використання

Мета роботи:

• вивчення основних принципів методології IDEF0,
• створення нового проекту в BPWin,
• формування контекстної діаграми,
• проведення зв'язків.

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

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

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

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

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

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

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

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

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

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

Типи стрілок

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

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

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

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

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

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

Рис. 2.1Типи стрілок

У методології IDEF0 потрібно лише п'ять типів взаємодій між блоками для опису їхніх відносин: керування, вхід, зворотний зв'язок з управління, зворотний зв'язок по входу, вихід-механізм. Зв'язки з управління та входу є найпростішими, оскільки вони відображають прямі дії, які інтуїтивно зрозумілі та дуже прості.

Рис. 2.2.Зв'язок по виходу

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

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

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

Зворотний зв'язок з управління виникає тоді; коли вихід деякого блоку впливає блок із великим домінуванням.

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

Рис. 2.4.Зворотній зв'язок по входу

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

Зв'язки «вихід-механізм» притаманні розподілу джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали).

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

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

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

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

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

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

Кількісний аналіз діаграм

Для проведення кількісного аналізу діаграм перерахуємо показники моделі:

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

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

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

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

Рис. 2.7.Приклад незбалансованої діаграми

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

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

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

Після формування словника та складання пакета діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіги назв блоків діаграм і слів зі словника, це говорить, що достатній рівень декомпозиції досягнутий. Коефіцієнт, який кількісно відображає даний критерій, можна записати як L * C -добуток рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.

Інструментарій BPWin

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, в якому слід зазначити, чи буде створено модель заново, чи вона буде відкрита з репозитарію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).

Рис.2.8Діалог створення моделі

BPWin підтримує три методології - IDEF0, IDEF3 та DFD. У BPWin можлива побудова змішаних моделей, тобто модель може містити одночасно діаграми IDEF0, так і IDEF3 і DFD. Склад панелі інструментів автоматично змінюється, коли відбувається перемикання з однієї нотації на іншу.

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

приклад

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

Після вивчення вихідних документів та опитування замовників та користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи "Служба зайнятості в рамках ВНЗ", основні можливості якої були описані у лабораторній роботі №1.

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

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

Для того, щоб обслужити клієнта, необхідно зареєструвати його в системі, відкрити доступ до БД та опрацювати його запит. Як вхідні дані використовуватимуться «ім'я клієнта», «пароль клієнта», «вихідна БД», «запит клієнта». Виконання запиту веде або до отримання інформації від системи, або зміни вмісту БД (наприклад, при складанні експертних оцінок), тому вихідними даними будуть «звіти» і «змінена БД». Процес обробки запитів виконуватиме монітор системи під контролем адміністратора.

Контекстна діаграма

Отже, визначимо контекстну діаграму системи (рис. 2.9).

Рис. 2.9.Контекстна діаграма системи

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

• Визначення рівня доступу до системи.
• Вибір підсистеми.
• Звернення до підсистеми.
• Зміна БД (за потреби).

Отримаємо діаграму, зображену на рис. 2.10.

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

Рис. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"

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

Рис. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»

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

Декомпозуємо роботу «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед пошуком відповіді на запит необхідно відкрити БД (підключитися до неї). У загальному випадку БД може перебувати на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність робіт:

• Відкриття БД.
• Виконання запиту.
• генерація звітів.

Після відкриття БД необхідно повідомити систему встановлення з'єднання з БД, після чого виконати запит і згенерувати звіти для користувача (рис. 2.12).

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

Рис. 2.12.

Коригування діаграми

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

Скоригуємо діаграму, додавши до неї стрілки «Шаблони звітів» та «Запити на зміну БД» та тунельну стрілку «Клієнт системи». Тунелювання «Клієнта системи» застосовано для того, щоб не виносити стрілку на діаграму верхнього, тому що функція вибору форми звіту не є достатньо важливою для відображення її на батьківській діаграмі.

Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).

Декомпозицію роботи «Виконання запиту» доцільно провести з допомогою діаграми DFD (лабораторна робота № 3), оскільки методологія IDEF0 розглядає систему як сукупність взаємозалежних робіт, що негативно відбиває процеси обробки інформації.

Рис. 2.13.Декомпозиція роботи "Обробка запиту клієнта"

Рис. 2.14.Декомпозиція роботи «Обслуговування клієнта системи» (варіант 2)

Рис. 2.15.Контекстна діаграма системи (варіант 2)

Перейдемо до декомпозиції останнього блоку «Зміна БД». З погляду клієнта, ці системи розташовуються в одній БД. Реально в системі присутні шість БД:

• БД користувачів,
• БД студентів, (варіант 2)
• БД вакансій
• БД успішності,
• БД тестів,
• БД експертних оцінок,
• БД резюме.

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

• Визначається БД, у якій змінюватиметься інформація.
• Оператором формується тимчасовий набір даних та надається адміністратору.
• Адміністратор здійснює контроль даних та вносить їх до БД.

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

Рис. 2.16.Декомпозиція роботи «Зміна БД»

Рис. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного нарис. 2.12

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

Декомпозицію роботи «Виконання запиту» буде проведено у наступній лабораторній роботі, ілюструючи застосування діаграм DFD для опису процесів обробки інформації.

Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно з вищеописаною методикою. Розглянемо поведінку коефіцієнта у цих моделей. У батьківської діаграми «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а діаграми декомпозиції 3/3 = 1. Значення коефіцієнта зменшується, що свідчить про спрощення описи функцій зі зниженням рівня моделі.

Розглянемо зміну коефіцієнта До bу двох варіантів моделей.

для другого варіанта

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

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

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

Контрольні питання

перелік Контрольних питань:

1. Що таке модель в нотації IDEF0?
2. Що означають роботи в IDEF0?
3. Назвіть порядок найменування робіт?
4. Яка кількість робіт має бути присутня на одній діаграмі?
5. Що називається порядком домінування?
6. Як розташовуються роботи за принципом домінування?
7. Яким є призначення сторін прямокутників робіт на діаграмах?
8. Перелічіть типи стрілок.
9. Назвіть види взаємозв'язків.
10. Що називається граничними стрілками?
11. Поясніть принцип іменування стрілок, що розгалужуються і зливаються.
12. Які методології підтримуються BPWin?
13. Наведіть основні елементи головного вікна BPWin.
14. Опишіть процес створення нової моделі у BPWin.
15. Як провести зв'язок між роботами?
16. Як встановити ім'я роботи.
17. Опишіть декомпозицію роботи.
18. Як додати роботу на діаграму?
19. Як дозволити тунельовані стрілки?
20. Чи може BPWin містити діаграми кількох методологій?

Одна картинка коштує тисячі слів

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

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

Декілька слів про переваги графіки

І спершу зробимо невеликий екскурс в історію. Повернемося в далекий 1877, під час Російсько-Турецької війни. Саме тоді поліграфіст Ситін уперше застосував графіку при описі воєнних дій. Зараз для нас все це звично, при описі будь-якої битви у кожного перед очима з'являються карти зі стрілками, які наочно показують хід битви. А на той час військові дії описувалися словами. Для кожного бою - багато слів. І зрозуміти в результаті, що відбувається, було дуже складно.

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

Аналогічний приклад безпорадності словесних описів я можу навести також зі своєї практики. Один із моїх замовників дуже просив взятися за впровадження ERP-системи для його компанії. На запитання, чи є у них якесь технічне завдання, я одержав відповідь: “Так, є. Але у ньому 400 сторінок”. При цьому клієнт дуже скаржився, що мої колеги, яких він звертався раніше, або відмовлялися від проекту взагалі, або називали явно завищені ціни. Після того, як я побачив, що в технічному завданні дійсно 400 сторінок і складається воно виключно з текстового опису, я зрозумів причини поведінки розробників. Прочитати такий обсяг тексту, вникнути в нього, розібратися в усіх нюансах тільки для того, щоб зрозуміти завдання і назвати ціну - це дуже складно.

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

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

Чому це важливо для моєї роботи

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

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

Типові помилки

Використання різних кольорів

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

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

Занадто велика кількість блоків

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

Порушення структури при внесенні коригувань

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

Правила назви керуючих елементів та блоків

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

Вигоди використання IDEF0

• Найперша вигода очевидна – це наочність.Ви самі починаєте розуміти, як працює та чи інша система, і можете наочно пояснити, де в цій системі «тонкі місця» і як ваші рішення допоможуть позбутися їх.
• Взаєморозуміння та відсутність різночитань.При обговоренні роботи компанії з використанням функціональної моделі у вас є наочні та зрозумілі інтуїтивно блоки завдань із керуючими елементами. Крім того, функціональне моделювання передбачає створення у разі потреби глосарію, в якому розкриваються умовні позначення та терміни. В результаті ви з клієнтом, керівником, іншими співробітниками під час обговорення проблеми розмовляєте однією мовою.
• Простота та висока швидкість створення моделі.Звичайно, навчитися моделювання не так просто, як здається. Адже схема - це, по суті, надщільне подання інформації, що дуже добре для розуміння, але для реалізації такої подачі потрібен особливий підхід. Мозок аналітика виступає у разі як дуже потужний прес з одного боку, і фільтр – з іншого. Але з досвідом цей процес стає дуже швидким. В результаті ви отримуєте інструмент, який допоможе і самому розібратися, що відбувається в тій чи іншій системі, і за допомогою створеного в стислі терміни наочної допомоги проілюструвати важливі моменти колегам або замовникам.
• Дисципліна та відсутність помилок.Стандарт IDEF0 передбачає строгі рамки та правила. Такий підхід дисциплінує, а звичка діяти в рамках стандарту допомагає уникнути помилок через неуважність. Будь-які порушення стандарту стають відразу помітними.

У чому складність застосування IDEF0

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

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

Ще статті на цю тему.

Основний із трьох методологій, що підтримуються BPwin, є IDEF0. IDEF0 відноситься до сімейства IDEF, яке з'явилося в кінці шістдесятих років під назвою SADT (Structured Analysis and Design Technique). IDEF0 можна використовувати для моделювання широкого класу систем. Для нових систем застосування IDEF0 має на меті визначення вимог та вказівку функцій для подальшої розробки системи, що відповідає поставленим вимогам та реалізує виділені функції. Стосовно вже існуючих систем IDEF0 може бути використана для аналізу функцій, що виконуються системою та відображення механізмів, за допомогою яких ці функції виконуються. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно впорядкованого набору діаграм, тексту документації та словників, пов'язаних один з одним за допомогою перехресних посилань. Двома найбільш важливими компонентами, з яких будуються діаграми IDEF0, є бізнес-функції або роботи (представлені на діаграмах у вигляді прямокутників) та дані та об'єкти (зображувані у вигляді стрілок), що зв'язують між собою роботи. При цьому стрілки, залежно від того, в яку грань прямокутника роботи вони входять або з якої грані виходять, діляться на п'ять видів:

Стрілки входу (входять у ліву грань роботи) - зображують дані чи об'єкти, змінювані під час виконання роботи.

Стрілки управління (входять у верхню межу роботи) - зображують правила та обмеження, згідно з якими виконується робота.

Стрілки виходу (виходять із правої межі роботи) - зображують дані чи об'єкти, які у результаті виконання роботи.

Стрілки механізму (входять у нижню грань роботи) - зображують ресурси, необхідних виконання роботи, але які змінюються у процесі роботи (наприклад, устаткування, людські ресурси…)

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

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

Малюнок 7.1. Функціональний блок та інтерфейсні дуги

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

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

Після того, як контекст описаний, проводиться побудова наступних діаграм в ієрархії. Кожна наступна діаграма є більш докладним описом (декомпозицією) однієї з робіт на діаграмі, що стоїть вище. Приклад декомпозиції контекстної роботи показано на Рис.7.2 та Рис.7.4. Опис кожної підсистеми проводиться аналітиком разом із експертом предметної області. Зазвичай експертом є людина, яка відповідає за цю підсистему і тому досконало знає всі її функції. Таким чином, вся система розбивається на підсистеми до потрібного рівня деталізації, і виходить модель, що апроксимує систему із заданим рівнем точності. Отримавши модель, що адекватно відображає поточні бізнес-процеси (так звану модель AS IS), аналітик з легкістю може побачити всі найвразливіші місця системи. Після цього з урахуванням виявлених недоліків можна будувати модель нової організації бізнес-процесів (модель TO BE).

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

На малюнку 7.2, де наведено три діаграми та їх взаємозв'язку, показано структуру IDEF0.-моделі. Кожен компонент моделі може бути декомпозований інший діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.

Рисунок 7.2 – Приклад контекстної діаграми

Як видно на Рис.7.2, BPwin дозволяє виділяти роботи та стрілки різними кольорами, а також прив'язувати імена стрілок до самих стрілок (стрілка на ім'я Звітність), що підвищує наочність і читаність діаграми.

Рисунок 7.3 – Приклад діаграми декомпозиції

Малюнок7 . 4 - Приклад контекстної діаграми

Малюнок 7.5 -Приклад діаграми декомпозиції

Ієрархія діаграм

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

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

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

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

Малюнок 7.6 – Структура SADT-моделі. Декомпозиція діаграм

Малюнок 7.7 - Відповідність має бути повною та несуперечливою

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

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

Рис. 7.8. Приклад механізму

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

Щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є верхньою діаграмою моделі. На малюнку 7.9 показано типове дерево діаграм.

Рисунок 7.9 – Ієрархія діаграм

Лекція 8. МетодологіяDFDіIDEF3

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

Рис. 3.12

Побудова моделей

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

• Чому моделюється цей процес?
• Що виявить дана модель?
• Як ті, хто ознайомиться з цією моделлю, зможуть її застосувати?

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

• Які завдання менеджера?
• Які завдання клерка?
• Хто контролює роботу?
• Яка технологія необхідна виконання кожного кроку тощо.

Точка зору

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

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

Межі моделювання

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

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

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

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

Вибір найменування контекстного блоку

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

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

Визначення стрілок на контекстній діаграмі

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

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

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

Визначеннямеханізмів виконання. Після створення входів і виходів можна розпочати розгляд механізмів виконання або ресурсів, що належать до функціонального блоку. До поняття механізму виконання входять персонал, обладнання, інформаційні системи тощо. Наприклад, функціональний блок "Зібрати деталь" може вимагати використання будь-якого обладнання, наприклад, гайкового ключа. При прийомі іспитів на права водія механізмом виконання є інспектор ДІБДР. Як правило, визначити механізм виконання для функціональних блоків досить просто.

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

Коли контекстна діаграма є завершеною, спробуйте поставити такі питання:

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

Нумерація блоків та діаграм

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

Префікс повторюється кожного блоку моделі. Номеривикористовуються для відображення рівня декомпозиції, на якому знаходиться блок. Блок АТ декомпозується блоки Al, A2, A3 і т.д.; блок А1 - А11, А12, А13 і т.д.; блок - А11 А111, А112, А113 і т.д. Для кожного рівня декомпозиції наприкінці номера додається одна цифра.

Два підходи до початку моделювання

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

Коли зупинитися

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

За необхідності подальшої деталізації окремих процесів може бути використана методологія IDEF3.

Інші діаграми IDEF0

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

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

Презентаційні діаграми. Презентаційні діаграми (For Exposition Only diagrams - FEO diagrams) часто включають моделі, щоб проілюструвати інші погляду чи деталі, які виходять поза рамки традиційного синтаксису IDEF0. Діаграми FEO допускають порушення будь-яких правил побудови діаграм IDEF0з метою виділення важливих з погляду аналітика елементів моделі. Природно, якщо діаграма FEO включена в модель виключно для відображення іншої точки зору на систему, вона, швидше за все, виглядатиме зовні як звичайна IDEF0-діаграма, задовольняючи всі обмеження IDEF0.

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

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

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

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

IDEF0 діаграми будуються за допомогою програми BPWin. Призначені вони для графічного моделювання бізнес-процесів, що відбуваються.

Про методологію IDEF0

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

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

Елементи, що використовуються для IDEF0

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

Можливості використання IDEF0

Методологію IDEF0 можна використовуватиме опису функціонального аспекту будь-якої інформаційної системи.

Типи зв'язків між процесами IDEF0

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

1. Ієрархічний («частина» - «ціле») зв'язок.

2. Керуюча (регламентуюча, підлегла):

2) зворотний зв'язок управління.

3. Функціональна чи технологічна:

2) зворотний вхідний.

3) споживча;

4) логічна;

5) методична чи колегіальна;

6) ресурсна;

7) інформаційна;

8) тимчасова;

9) випадкова.

Побудова блоків та зв'язків у діаграмах

Методологія IDEF0 надає цілий ряд правил та рекомендацій щодо свого використання та покращення якості використання. Так, у діаграмі відображається один блок, на якому можна задати назву системи, її призначення. До блоку або блоку веде 2-5 стрілок. Можна більше або менше, але щонайменше дві стрілки необхідні для входу/виходу, а решта для додаткових робіт та їх вказівки на діаграмі. Якщо стрілок більше 5, слід подумати про оптимальність побудови моделі, і чи не можна зробити її ще більш деталізованою.

Побудова блоків у діаграмах декомпозиції

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

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

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

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

Найменування

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

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

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

Інформація про стрілки

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

Приклад реалізації методології IDEF0 на конкретній моделі

Ви вже дізналися, що таке IDEF0 діаграма, приклади та правила побудови таких діаграм частково побачили. Тепер слід звернутись і до практики. Для кращого розуміння пояснення йтиме не на якійсь «загальній» моделі, а на конкретному прикладі, який дозволить краще та повніше зрозуміти особливості роботи з IDEF0 у програмі BPWin.

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

Вихідною інформацією виступають:

1. дані про лінію шляхів;
2. паспорт усієї дистанції;
3. план шляху.

Керуючі дані:

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

Результатом моделі є:

1. Обмеження допустимих швидкостей із зазначенням причини обмеження.
2. Допустимі швидкості при русі на окремих пунктах і під час перегону поїздів.

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

Висновок

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