Проєкт "Разом"

1.1. Правила побудови моделей.

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

1.3. Основні елементи і поняття IDEF0

 

1.1. Правила побудови моделей.

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

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

Ці блоки представляють основні підфункції (підмодулі) єдиного вихідного модуля.

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

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

 

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

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

принцип функціональної декомпозиції;

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

принцип контексту.

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

• Принцип обмеження складності. При роботі з IDEF0 діаграмами істотним є умова їхньої розбірливості. Суть принципу обмеження складності полягає в тому, що кількість блоків на діаграмі повинна бути не менш двох і не більш шести. Практика показує, що дотримання цього принципу приводить до того, що функціональні процеси, представлені у вигляді IDEF0 моделі, добре структуровані, зрозумілі і легко піддаються аналізу.
• Принцип контекстної діаграми. Моделювання ділового процесу починається з побудови контекстної діаграми. На цій діаграмі відображається тільки один блок - головна бізнес-функція системи. Якщо мова йде про моделювання цілого  підприємства чи навіть великого підрозділу, головна бізнес-функція не може бути сформульована як, наприклад, “продавати продукцію”. Головна бізнес-функція системи - це “місія” системи, її значення в навколишньому світі. Не можна правильно сформулювати головну функцію підприємства, не маючи представлення про його стратегію. При визначенні головної бізнес-функції необхідно завжди мати точку зору на модель. Те саме підприємство може бути описане по-різному, у залежності від того, з якого погляду його розглядають: директор підприємства і податкової інспектор бачать організацію зовсім по-різному. Контекстна діаграма грає ще одну роль у функціональній моделі. Вона “фіксує” границі бізнес- системи, визначаючи те, як система взаємодіє зі своїм оточенням. Це досягається за рахунок опису дуг, з'єднаних із блоком, що представляє головну бізнес-функцію.

 

1.3. Основні елементи і поняття IDEF0

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

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

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

Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. мал. 1) і уособлює собою деяку конкретну функцію в рамках розглянутої системи. По вимогах стандарту назва кожного функціонального блоку повинне бути сформульоване в дієслівному нахиленні (наприклад, “робити послуги”, а не “виробництво послуг”).

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

• Верхня сторона має значення “Керування” (Control); (стрілки зверху, що означають на підставі чого виконується даний процес - закони, стандарти, накази і т.д.);
• Ліва сторона має значення “Вхід” (Input); (стрілки ліворуч, - чи дані об'єкти, споживані чи змінювані процесом);
• Права сторона має значення “Вихід” (Output); (стрілки праворуч, - основні результати діяльності процесу, кінцеві продукти);
• Нижня сторона має значення “Механізм” (Mechanism). (стрілки знизу, що означають, за допомогою чого чи за допомогою кого реалізується даний процес - матеріальні і/чи кадрові ресурси, необхідні для процесу).

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

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

Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). За вимогою стандарту, найменування повинне бути іменником.

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

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

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

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