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

ФУНКЦІОНАЛЬНЕ МОДЕЛЮВАННЯ  ЕКОНОМІЧНОЇ ДІЯЛЬНОСТІ ІЗ ЗАСТОСУВАННЯМ СПЕЦІАЛІЗОВАНИХ ПРОГРАМНИХ ПРОДУКТІВ

ПРАКТИЧНА РОБОТА № 6
Тема: “Вивчення вікна програми AllFusion Process Modeler, інструментів моделювання та основних фігур, які використовуються при моделюванні, робота зі стрілками та їх різновидами. Побудова контекстної діаграми бізнес-процесу”

Мета: Набути практичних навичок застосування інструментів для розробки контекстної діаграми бізнес-процесу.

Хід роботи

Теоретичні відомості

ПРИНЦИПИ ПОБУДОВИ МОДЕЛІ IDEF0

Методологія IDEF0 базується на підході, який був запропонований Дугласом Т. Россом ще на початку 70-х років минулого століття і знаний у всьому світі як метод структурного аналізу і проектування, англомовна назва – SADT (Structured Analysis & Design Technique). Процес моделювання  системи за методологією IDEF0 починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб’єкта моделювання, цілі і точки зору на модель.

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

Мета моделювання (Purpose) має бути визначена передусім іполягає у формуванні відповідей на такі питання:

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

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

• Що може отримати користувач?

Далі має бути визначена точка зору (Viewpoint). Хоча при побудові моделі враховуються думки різних людей, модель повинна будуватися з єдиної точки зору. Як правило, вибирається точка зору людини, відповідальної за модельовану роботу в цілому. Часто при виборі точки зору на процес важливо задокументувати додаткові альтернативні точки зору. Для цієї мети зазвичай використовують діаграми FEO (For Exposition Only).

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

Зазвичай спочатку будується модель існуючої організації роботи – AS-IS (як є). Модель AS-IS дозволяє з’ясувати, "що ми робимо сьогодні" перед тим, як перейти до питання, "що ми робитимемо завтра". Аналіз функціональної моделі дозволяє усвідомити, де знаходяться найбільш слабкі місця, в чому полягатимуть переваги нових бізнес-процесів і наскільки глибоким змінам піддасться існуюча структура організації бізнесу. Модель ТО-ВЕ потрібна для аналізу альтернативних кращих шляхів виконання роботи і документування того, як компанія функціонуватиме в майбутньому.

Слід вказати на поширену помилку при створенні моделі AS-IS – це створення моделі, що ідеалізується. Прикладом може служити створення моделі на основі знань керівника, а не конкретного виконавця робіт. В результаті виходить прикрашена, спотворена модель, яка несе помилкову інформацію і яку неможливо надалі використовувати для аналізу. Така модель називається SHOULD_BE (як повинно бути).

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

Синтаксис графічної мови IDEF0

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

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

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

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

Контекстна діаграма– цедіаграма, що має вузловий номер A-n ( n≥0) і представляє контекст моделі. Діаграма A-0, що складається з одного блоку, є необхідною (обов’язковою) контекстною діаграмою; діаграми з вузловими номерами A-1, A-2... - додаткові контекстні діаграми.

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

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

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

Мітка стрілки (ім’я) – цеіменник або іменниковий оборот, що пов’язаний із стрілкою або сегментом стрілки що визначає її призначення.

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

У IDEF0 розрізняють п’ять типів стрілок (Рис.  6.2).

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

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

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

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

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

Код ICOM –  абревіатура(Input - Вхід, Control - Управління, Output -Вихід, Mechanism – Механізм), код, що забезпечує відповідність граничних стрілок дочірньої діаграми із стрілками батьківського блоку; використовується для посилань.

Щоб увімкнути режим відображення ICOM-кодів потрібно встановити відповідний параметр  у вікні Model/Model Properties/Display.

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

СЕРЕДОВИЩЕ ALLFUSION PROCESS MODELER

AllFusion Process Modeler (AFPM) підтримує три методології – IDEF0, IDEF3 і DFD, кожна з яких вирішує свої специфічні завдання. У AFPM можлива побудова змішаних моделей, тобто модель може містити одночасно як діаграми IDEF0, так і IDEF3 і DFD. Склад панелі інструментів змінюється автоматично, коли відбувається перемикання з однієї нотації на іншу.

Робоче вікно програми AllFusion Process Modeler містить такі області:

• панель інструментів;

• головне меню;

• браузер моделі (Model Explorer) має три вкладки – Activities (), Diagrams  і Objects ().

• бланк діаграми;

• рядок стану.

Панель інструментів

На стандартній панелі інструментів розташовані елементи управління, знайомі з інших Windows-програм:

1. Створити нову модель;

2. Відкрити модель;

3. Зберегти модель;

4. Друк моделі;

5. Майстер створення звітів;

6. Вибір масштабу;

7. Масштабування;

8. Збільшення ділянки;

9. Перевірка помилок;

10. Включення і виключення навігатора моделі

Панель інструментів редактора AFPM містить:

1. Pointer Tool –  використовується для вибору і визначення позиції об’єктів доданих в діаграму;
2. Activity Box Tool – використовується для додавання робіт у діаграму;
3. Arrow Tool – використовується, щоб додавати стрілки (дуги) на діаграмі;
4. Squiggle Tool – використовується для створення тильди (squiggle), яка сполучає стрілку з її назвою;
5. Text Block Tool – використовується для створення текстових блоків;
6. Diagram Dictionary Editor – відкриває діалогове вікно Diagram Dictionary Editor, де можна перейти на яку-небудь діаграму або створити нову діаграму;
7. Go to Sibling Diagram – використовується для відображення наступної діаграми того ж рівня;
8. Go to Parent Diagram – перехід на батьківську діаграму;
9. Go to Child Diagram – використовується, щоб відобразити дочірну діаграму або декомпозувати дану роботу.

Опис полів бланку діаграми

Будь-яка діаграма складається з сукупності наступних об’єктів:

• робіт;
• дуг (стрілок);
• текстових блоків.

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

Поля верхньої частини рамки:

1) Used At (Використовується в) – використовується для вказівки на батьківський блок у випадку, якщо на поточну діаграму посилалися за допомогою стрілки виклику;

2) Author (Автор)– ім’я автора діаграми;

3) Date (Дата) – дата створення проекту;

4) Project (Проект)– ім’я проекту;

5) Rev (Переглянуто)– дата останнього редагування діаграми;

6) Notes 12345678910 (Зауваження) – використовується при проведенні сеансу експертизи.Експерт повинен (на паперовій копії діаграми) вказати число зауважень, викреслюючи цифру із списку кожного разу при внесенні нового зауваження;

7) Status (Статус) – статус відображає стадію створення діаграми, відображаючи всі етапи публікації:

а) Working (Робоча версія)– нова діаграма, кардинально оновлена діаграма або новий автор діаграми;

б) Draft (Ескіз)– діаграма пройшла первинну експертизу і готова до подальшого обговорення;

в) Recommended (Рекомендовано) – діаграма і всі її супроводжуючі документи пройшли експертизу, нових змін не очікується;

г) Publication (Публікація) – діаграма готова до остаточного друку і публікації.

д) Reader (Читач) – ім’я читача (експерта);

е) Date (Дата) – дата прочитання (експертизи);

8) Context (Контекст)– схема розташування робіт в діаграмі верхнього рівня. Робота, що є батьківською, зображується темним прямокутником, інші роботи – світлим пряґмокутником. На контекстній діаграмі (А-0) показується напис ТОР. У лівому нижньому куті - номер по вузлу батьківської діаграми:

Поля нижньої частини рамки:

1. Node (Вузол)– номер вузла діаграми (номер батьківського блоку);

2. Title (Назва) – ім’я діаграми; за замовчуванням – ім’я батьківського блоку;

3. Number (Номер) – C-номер, унікальний номер версії діаграми;

4. Page (Сторінка) – номер сторінки, може використовуватися як номер сторінки при формуванні теки.

У стартовому вікні користувачу пропонується вибір нотації майбутньої моделі.

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

Встановлення кольору і шрифту об’єктів. Пункти контекстного меню Font Editor і Color Editor викликають відповідні діалогові вікна для установки шрифту (зокрема його розміру і стилю) та кольору об’єкту. Крім того, AFPM дозволяє встановити шрифт за умовчанням для об’єктів певного типу на діаграмах і в звітах. Для цього слід вибрати меню Tools/Default Fonts, після чого з’являється каскадне меню, кожен пункт якого служить для встановлення шрифтів для певного типу об’єктів:

Context Activity – робота на контекстній діаграмі;

Context Arrow – стрілки на контекстній діаграмі;

Decomposition Activity – роботи на діаграмі декомпозиції;

Decomposition Arrow – стрілки на діаграмі декомпозиції;

NodeTree Text – текст на діаграмі дерева вузлів;

Frame User Text – текст, що вноситься користувачем в каркасі діаграм;

Frame System Text – системний текст в каркасі діаграм;

Text Blocks – текстові блоки;

Parent Diagram Text – текст батьківської діаграми;

Parent Diagram Title Text – текст заголовка батьківської діаграми;

Report Text – текст звітів.

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

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

Основні види робіт в компанії такі:

• прийняття замовлень клієнтів;

• групування замовлень по типах ПК;

• закупівля комплектуючих;

• збірка і тестування комп’ютерів;

• упаковка комп’ютерів згідно замовлень;

• відвантаження клієнтам їх замовлень.

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

Алгоритм виконання

1. Запустіть програму AllFusion Process Modeler (AFPM).

2. Натисніть кнопку  . З’являється діалогове вікно I would like to. Введіть у текстове поле Name ім’я моделі "Діяльність комп’ютерної компанії" та за допомогою альтернативного перемикача виберіть Type – Business Process (IDEF0).

3. Відкриється діалогове вікно Properties for New Models (Властивості нової моделі).

У текстове поле Author (Автор) необхідно ввести своє ПІБ -автора моделі- і в текстове поле Author initials назву групи. Автоматично створюється незаповнена контекстна діаграма

1. На вкладці Activities браузера моделі можна вибрати опції редагування властивостей моделі.

2. Перейдіть в меню Model/Model Properties. На вкладці General діалогового вікна Model Properties в текстове поле Model name слід ввести ім’я моделі "Діяльність комп’ютерної компанії", а в текстове поле Project ім’я проекту "Модель роботи компанії", та у текстове Time Frame (Часове охоплення) – AS-IS (Як є) (Рис.  6.10).

3. На вкладці Purpose діалогового вікна Model Properties в текстове поле Purpose (мета) внесіть дані про мету розробки моделі – "Змоделювати поточні бізнес-процеси компанії(AS-IS) ", а в текстове поле Viewpoint (точка зору) – "Керівник".

4. На вкладці Definition діалогового вікна Model Properties в текстове поле Definition (Визначення) внесіть "Це навчальна модель, що описує діяльність комп’ютеро-збиральної компанії" і в текстове поле Scope (охоплення), – "Загальне керівництво бізнесом: дослідження ринку, закупка комплектуючих, збір, контроль якості, продаж ПК".

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

6. На вкладці Definition діалогового вікна Activity Properties в текстове поле Definition (Визначення) внесіть "Існуючі бізнес-процеси компанії". Текстове поле Note (Примітки) залиште незаповненим.

7. Створіть ICOM-стрілки на контекстній діаграмі (Таблиця 1.).

Таблиця 1

Стрілки контекстної діаграми

Завдання 2. Захистіть виконану роботу.

Перелік питань до захисту практичної роботи

1. Як позначається робота?
2. Які види стрілок існують в IDEF0?
3. Що ми вказуємо в полі Viewpoint?
4. Яке призначення моделей As-Is?
5. Яке призначення моделей To-Be?
6. Для чого використовують Model Report?
7. Яке призначення стрілок типу Mechanism?
8. Яке призначення стрілок типу Output?
9. Яке призначення стрілок типу Control?
10. Яке призначення  стрілок типу Input?
11. Яке призначення всіх об’єктів функціональної діаграми?
12. Властивості якого об’єкта задаються у вікні Activity properties?
13. Назвіть основні елементи середовища AllFusion Process Modeler?
14. Поясніть принцип іменування стрілок, що розгалужуються і зливаються.
15. Назвіть основні елементи  вікна AllFusion Process Modeler.
16. Яке призначення сторін прямокутників робіт на діаграмах?

ПРАКТИЧНА РОБОТА № 7-8
Тема: „Розробка моделі бізнес-процесу в нотації IDEF0. Створення діаграми декомпозиції”

Мета: Набути знань і практичних навичок розробки діаграми  бізнес-процесу в нотації IDEF0.

Хід роботи

Теоретичні відомості

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

У діалоговому вікні Activity Box Count (Рис. 7.1), слід вказати нотацію нової діаграми і кількість робіт на ній (діапазон числа робіт 2-8). Декомпозувати роботи на одну роботу не має сенсу. Діаграми з кількістю робіт більше восьми виходять перенасиченими і погано читаються. Для забезпечення наочності і кращого розуміння модельованих процесів рекомендується використовувати від трьох до шести блоків на одній діаграмі.

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

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

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

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

Батьківська діаграма – та, яка містить один і більше батьківських блоки. Будь-яка не-контекстна діаграма є також дочірньою діаграмою, оскільки, за визначенням, вона детально описує деякий батьківський блок. Таким чином, будь-яка діаграма може бути як батьківською діаграмою (містити батьківські блоки), так і дочірньою (детально описувати власний батьківський блок). Аналогічно, блок може бути як батьківським (детально описуватись дочірньою діаграмою) так і дочірнім (що з’являється на дочірній діаграмі). Основне ієрархічне відношення існує між батьківським блоком і дочірньою діаграмою.

Те, що блок є дочірнім і розкриває зміст батьківського блоку на діаграмі попереднього рівня, вказується спеціальним кодом, що розміщується у нижньому правому куті блоку (Model/Model Properties/Numbering). Цей код може формуватися декількома способами, з яких найпростіший полягає в наступному: код, який починається з букви А, містить цифри, що визначаються номерами батьківських блоків.

Номер блоку -число (0-8), що розміщується в правому нижньому куті блоку і однозначно ідентифікує блок на діаграмі.

У методології IDEF0 існує шість типів відношень між блоками в межах однієї діаграми:

• домінування;
• управління;
• вихід - вхід;
• зворотний зв’язок по управлінню;
• зворотний зв’язок по входу;
• вихід – механізм.

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

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

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

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

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

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

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

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

Стрілки, поміщені в "тунель"

Тунель - дужки на початку і/або закінченні стрілки. Тунельні стрілки означають, що дані, виражені цими стрілками, не розглядаються на батьківській діаграмі і/або на дочірній діаграмі. Внесені граничні стрілки на діаграмі декомпозиції нижнього рівня зображуються в квадратних дужках і автоматично не з’являються на діаграмі верхнього рівня. Відображення стрілки із квадратними дужками у кінцевому варіанті діаграми вважається помилкою. Необхідно, щоб дана стрілка відображалась на батьківській/дочірній діаграмі або взята у круглі дужки (Поміщена в тунель) (Рис.  7.8б). Стрілка, поміщена в тунель там, де вона приєднується до блоку, означає, що дані, виражені цією стрілкою, не обов’язкові та не відображаються на наступному рівні декомпозиції.

Стрілки як обмеження

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

Паралельне функціонування

Різні роботи в моделі можуть бути виконані паралельно, якщо задовольняються необхідні обмеження (умови). Як показано на Рис. 7.10, один блок може створити дані або матеріальні об’єкти, необхідні для паралельної роботи декількох блоків.

Розгалуження і злиття сегментів стрілок

Розгалуження і злиття стрілок покликане зменшити завантаженість діаграм графічними елементами (лініями). Мітки зв’язуються з сегментами за допомогою тильд. Мітку можна присвоїти окремій гілці стрілки.

Основні правила побудови діаграм декомпозиції в нотації IDEF0

• Блоки завжди повинні містити хоча б одну управляючу і одну вихідну стрілку, але можуть не мати вхідних стрілок.
• Роботи розміщуються по діагоналі.
• Якщо одні і ті ж дані служать і для управління і для входу, будується  тільки стрілка управління. Цим підкреслюється керуючий характер даних і зменшується складність діаграми.
• Максимальна відстань між вхідними і вихідними стрілками.
• Максимальна відстань між поворотами і перетином стрілок.
• Якщо дві стрілки паралельні, їх варто об’єднати.
• Зворотній зв’язок по входу будується за допомогою нижньої петлі.
• Зворотній зв’язок по управлінню будується за допомогою верхньої петлі.
• Мінімум перетинів.
  

Розгалуження – церозділення стрілки на два і більше сегментів. Може означати "розв’язування пучка".

Сегмент стрілки – це сегмент лінії, який починається або закінчується на стороні блоку, в точці розгалуження або злиття, або на границі (незв’язаний кінець стрілки).

Злиття – цеоб’єднання двох або більшого числа сегментів стрілок в один сегмент. Може означати "в’язування пучка".

Алгоритм виконання

Завдання 1. Створення діаграми декомпозиції верхнього рівня

 Внесіть почергово імена та визначення робіт згідно даних Таблиці 7.1.

Таблиця 7.1

Роботи діаграми декомпозиції А0

Примітка: Якщо описати ім’я і властивості роботи в словнику, її можна буде внести до діаграми пізніше за допомогою кнопки на панелі інструментів. Неможливо видалити роботу із словника, якщо вона використовується на якійсь діаграмі. Якщо робота видаляється з діаграми, із словника вона не видаляється. Ім’я і визначення даної роботи може бути використане надалі. Для додавання роботи в словник необхідно перейти в кінець списку і клацнути правою кнопкою по останньому рядку. Виникає новий рядок, в якому потрібно внести ім’я і властивості роботи. Для видалення всіх імен робіт, що не використовуються в моделі, клацніть по кнопці Purge (Чистити)).

Завдання 2. Створення діаграми декомпозиції роботи А2

Декомпозуємо роботу "Збір і тестування комп’ютерів".

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

1. виробничий відділ отримує замовлення клієнтів від відділу продажів у міру їх надходження;
2. диспетчер координує роботу збиральників, сортує замовлення, групує їх і дає вказівку на відвантаження комп’ютерів, коли вони готові;
3. кожні 2 години диспетчер групує замовлення – окремо для настільних комп’ютерів і ноутбуків та направляє на збору;
4. співробітники відділу збору збирають комп’ютери згідно специфікаціям замовлення і інструкціям по збору;
5. якщо група комп’ютерів, що відповідає групі замовлень, зібрана, вона прямує на тестування;
6. тестувальники тестують кожен комп’ютер і у разі потреби замінюють несправні компоненти;
7. тестувальники направляють результати тестування диспетчерові, який на підставі цієї інформації ухвалює рішення про передачу комп’ютерів, які відповідають групі замовлень, на відвантаження.

Алгоритм виконання

Таблиця 7.2

Роботи діаграми декомпозиції А2

 Таблиця 7.3.

Стрілки діаграми декомпозиції А2

Завдання 3. Захистіть виконану роботу.

Перелік питань до захисту практичної роботи

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

ПРАКТИЧНА РОБОТА № 9
Тема: „Створення діаграми вузлів. Розділення та злиття моделей.”

Мета:набути знань і практичних навичок роботи із уже створеними діаграмами.

Час виконання роботи – 2 години

Хід роботи

Теоретичні відомості

Створення дерева вузлів

Діаграма дерева вузлів відображає ієрархію робіт в моделі і дозволяє розглянути модель в цілому, але не відображає взаємозв’язки між роботами (стрілки) (Рис. 9.1). Процес створення моделі робіт є ітераційним, отже, роботи можуть міняти своє розташування в дереві вузлів багато разів. Щоб не заплутатися і перевірити спосіб декомпозиції, слід після кожної зміни створювати діаграму дерева вузлів. Втім, AFPM має могутній інструмент навігації по моделі – Model Explorer, який дозволяє представити ієрархію робіт і діаграм в зручному і компактному вигляді, проте на цей інструмент не поширюються правила стандарту IDEF0.

Для створення діаграми дерева вузлів слід вибрати в меню  Diagram/Add Node Tree (Рис. 9.2). З’явиться діалогове вікно майстра створення діаграми дерева вузлів Node Tree Wizard.

Примітка:При створенні дерева вузлів слід вказати ім’я діаграми, оскільки, якщо в декількох діаграмах як корінь дерева вузлів використовувати одну і ту ж роботу, в цьому випадку всі ці діаграми отримають однаковий номер (номер вузла + постфікс N, наприклад AON) і в списку відкритих діаграм (пункт меню Window) їх можна буде розрізнити тільки по імені.

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

Перелік вузлів – це список, що відображає вузли моделі IDEF0 у впорядкованому вигляді.

Створення FEO-діаграм

Діаграми FEO (For Exposition Only – FEO) -"тільки для експозиції" - часто використовуються в моделі для ілюстрації інших точок зору, для відображення окремих деталей, які не підтримуються явно синтаксисом IDEF0. Діаграми FEO дозволяють порушити будь-яке синтаксичне правило, оскільки по суті є просто картинками – копіями стандартних діаграм і не включаються в аналіз синтаксису. Наприклад, робота на діаграмі FEO може не містити стрілок управління і виходу. З метою обговорення певних аспектів моделі з експертом предметної області може бути створена діаграма тільки з однією роботою і однією стрілкою, оскільки стандартна діаграма декомпозиції містить безліч деталей, що не відносяться до теми обговорення і дезорієнтують експерта. Але, якщо FEO використовується для ілюстрації альтернативних точок зору (альтернативний контекст), рекомендується все-таки дотримуватися синтаксису IDEF0. Для створення діаграми FEO слід вибрати пункт меню Diagram/Add FEO Diagram. У виникаючому вікні діалогу Add New FEO Diagram слід вказати ім’я FEO діаграми і тип батьківської діаграми.

Нова діаграма отримує номер, який генерується автоматично (номер батьківської діаграми по вузлу + постфікс F, наприклад A1F).

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

Злиття і розділення моделей

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

AFPM використовує для злиття і розгалуження моделей стрілки виклику.

Для злиття моделей необхідно виконати наступні умови:

• обидві моделі повинні бути відкриті в AFPM;
• ім’я моделі-джерела, яку приєднують до основної моделі (моделі-мети), повинно співпадати з ім’ям стрілки виклику роботи в основній моделі (Рис. 9.5);
• стрілка виклику повинна виходити з недекомпозованої роботи (робота повинна мати діагональну косу в лівому верхньому куті) (Рис. 9.6);
• імена контекстної роботи, що додається (моделі-джерела) і роботи на основній моделі, до якої ми приєднуємо модель-джерело, повинні співпадати (Рис. 9.5);
• модель-джерело повинна містити принаймні одну діаграму декомпозиції.

Для злиття моделей потрібно клацнути правою кнопкою миші на роботі із стрілкою виклику в основній моделі і в спливаючому меню вибрати пункт Merge Model.

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

Після підтвердження злиття модель-джерело приєднуються до моделі-мети, стрілка виклику зникає, а робота, від якої відходила стрілка виклику, стає декомпозованою – до неї приєднується діаграма декомпозиції першого рівня моделі-джерела. Стрілки, що стосуються роботи на діаграмі моделі-мети, автоматично не мігрують в декомпозицію, а відображаються як недозволені. Їх потрібно тунелювати вручну. На Рис. 9.7 показано, як виглядають моделі у вікні Model Explorer після злиття.

В процесі злиття модель-джерело залишається незмінною і до моделі-мети підключається фактично її копія (якщо вибрано опцію у вікні злиття Cut/Paste entire Dictonaries). Не потрібно плутати злиття моделей з синхронізацією. Якщо надалі модель-джерело редагуватиметься, ці зміни автоматично не потраплять у відповідну гілку основної моделі.

Розділення моделей проводиться аналогічно. Для розділення гілки від моделі слід клацнути правою кнопкою миші по декомпозованій роботі (ознака – робота не повинна мати діагональної косої в лівому верхньому куті) і вибрати в спливаючому меню пункт Split Model. У вікні діалогу Split Options, що з’явився, слід вказати ім’я створюваної моделі. Після підтвердження розділення в старій моделі робота стане недекомпозованою (ознака - діагональна коса в лівому верхньому куті), буде створена стрілка виклику, причому її ім’я співпадатиме з ім’ям нової моделі та буде створена нова модель, причому ім’я контекстної роботи співпадатиме з ім’ям роботи, від якої була "відірвана" декомпозиція.

Завдання 1. Побудова діаграми вузлів.

Ця робота  є логічним продовженням практичної роботи №7-8

Алгоритм виконання

1. Відкрийте розроблену у попередній роботі модель.
2. Виберіть пункт головного меню Diagram/Add Node Tree.
3. У першому діалоговому вікні майстра Node Tree Wizardвнесіть ім’я діаграми, вкажіть діаграму кореня дерева і кількість рівнів.
4. У другому діалоговому вікні майстра Node Tree Wizardвстановіть опції, як вказано на Рис.  9.9, і натисніть кнопку ОК.
5. В результаті буде створена  діаграма  дерева вузлів (Node tree Diagram).
6. Діаграму дерева вузлів можна модифікувати. Нижній рівень може бути відображений не у вигляді списку, а у вигляді прямокутників, так само як і верхні рівні. Для модифікації діаграми правою кнопкою миші клацніть по вільному місці, не зайнятому об’єктами, виберіть меню Node tree Diagram Propertiesі на вкладці Style діалогу Node Tree Properties відключіть опцію Orthogonal lines.
7. Збережіть  файл моделі як lr_9_1_Прізвище.

Завдання 2. Побудова FEO діаграм.

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

Алгоритм виконання

1. Виберіть пункт головного меню Diagram/Add FEO Diagram.
2. У діалоговому вікні Add New FEO Diagram виберіть тип і внесіть ім’я діаграми FEO.
3. Для визначення змісту діаграми перейдіть в пункт меню Diagram/Diagram Properties і на вкладці Diagram Text внесіть визначення
4. Видаліть зайві стрілки на діаграмі FEO.

Для переходу між стандартною діаграмою, деревом вузлів і FEOвикористовуйте кнопку  на панелі інструментів.

1. Збережіть файл моделі як lr_9_2_Прізвище.
2. Перейдіть на діаграму А0. Правою кнопкою миші клацніть на роботі "Збір і тестування комп’ютерів" та виберіть Split model -Розділити модель.

Завдання 3. Розділення моделі. 

1. У діалоговому вікні Split Option (Опції розділення) внесіть ім’я нової моделі "Збір і тестування комп’ютерів", встановіть опцію Сopy entire dictonaries(Копіювати повністю словник).
2. Зверніть увагу: у Model Explorerз’явилася нова модель, а на діаграмі А0 моделі "Діяльність компанії" з’явилася стрілка виклику "Збір і тестування комп’ютерів".
3. Створіть в моделі "Збір і тестування комп’ютерів" нову стрілку "Несправні компоненти".На діаграмі А0 це буде гранична стрілка виходу, на діаграмі А0 – гранична стрілка виходу від робіт "Збір настільних комп’ютерів", "Тестування комп’ютерів" і "Збір ноутбуків"
4. Збережіть файл моделі як lr_9_3_Прізвище.
5. Перейдіть на діаграму А0 моделі "Діяльність компанії".
6. Правою кнопкою миші клацніть на роботі "Збір і тестування комп’ютерів"та виберіть в контекстному меню опцію Merge model.

Завдання 4. Злиття моделей.

1. У діалоговому вікні Merge Model виберіть опцію Cut/Paste entire dictionaries.
   
2. Зверніть увагу на результат. У Model Explorer помітно, що дві моделі злилися.
   
3. Модель "Збір і тестування комп’ютерів" залишилася і може бути збережена в окремому файлі. На діаграмі А0 моделі "Діяльність компанії" зникла стрілка виклику "Збір і тестування комп’ютерів".
4. З’явилася недозволена гранична стрілка "Несправні компоненти".Направте цю стрілку на вхід роботи "Відвантаження та одержання".
5. Збережіть файл моделі як lr_9_4_Прізвище.

Перелік питань до захисту практичної роботи

1. Дайте визначення дерева вузлів.
2. Дайте визначення FEO-діаграми.
3. Яка різниця між контекстною і FEO-діаграмою?
4. Які умови злиття моделей?
5. Які умови розділення моделей?
6. Як відображається декомпозована робота на діаграмі?
7. Як формується номер діаграми дерева вузлів?
8. Як формується номер FEO-діаграми?
9. Чи поширюються правила IDEF0  на діаграму дерева вузлів?
10. Чи поширюються правила IDEF0  на FEO-діаграму?
11. Для чого використовують FEO-діаграми?
12. Для чого використовують діаграми дерева вузлів?
13. Яка різниця між моделлю-джерелом і моделлю-метою?
14. Чи призводить до змін у моделі-меті внесення змін у моделі-джерелі?
15. Чи можна відокремлену модель розробляти незалежно від основної?

Завдання 5. Захистіь виколнану роботу.

ПРАКТИЧНА РОБОТА № 10
Тема: "Розробка моделі бізнес-процесу в нотації IDEF3."

Мета: Набути знань і практичних навичок розробки діаграми  бізнес-процесу в нотації IDEF3 і усвідомити мету розробки діаграми даного різновиду .

Час виконання роботи – 2 години

Хід роботи

Теоретичні відомості

Окрім діаграм IDEF0 AFPM підтримує діаграми в нотації IDEF3, які призначені для опису логіки взаємодії інформаційних потоків. IDEF3 або так звана workflowdiagramming, використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації і об’єктів, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або подій, які необхідно обробити за кінцевий час. Кожен сценарій супроводжується описом процесу і може бути використаний для документування кожної функції.

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

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

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

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

Unit of Work (UOW) (одиниці роботи) або так звані роботи (activity), є центральними компонентами моделі. В IDEF3 роботи зображаються прямокутниками з прямими кутами і мають ім’я, виражене дієслівним іменником, що позначає процес дії, одиночним або у складі фрази, і номер (ідентифікатор); інший іменник у складі тієї ж фрази зазвичай відображає основний вихід (результат) роботи (наприклад, "Виготовлення виробу"). Часто іменник в імені роботи змінюється в процесі моделювання, оскільки модель може уточнюватися і редагуватися. Ідентифікатор роботи привласнюється при створенні і не змінюється. Навіть якщо робота буде видалена, її ідентифікатор не використовуватиметься для інших робіт.

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

• Старша (Precedence) стрілка - суцільна лінія, що зв’язує одиниці робіт (UOW). Малюється зліва направо або зверху вниз. Вказує, що робота-джерело повинна закінчитися перш, ніж робота-мета почнеться.

• Відношення (Relational Link) - пунктирна лінія, що використовується для зображення зв’язків між одиницями робіт (UOW), а також між одиницями робіт і об’єктами посилань.

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

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

Найчастіше нечіткі відношення використовуються для опису спеціальних випадків зв’язків передування, наприклад для опису альтернативних варіантів тимчасового передування. Звернемося ще раз до Рис.  10.2. На Рис.  10.5 вертикальні лінії вказують початок і закінчення роботи 1 і 2. Відповідно, до рисунка внесення виправлень до роботи починається ПІСЛЯ ухвалення всіх зауважень від рецензентів.

Альтернатива зв’язку „послідовність” з Рис.  10.2 - зв’язок нечіткого відношення, представлений на Рис.  10.6. В даному випадку внесення виправлень починається у міру отримання зауважень від рецензентів, тобто до безпосереднього закінчення дії з ухвалення зауважень.

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

У випадку, зображеному на Рис.  10.8, внесення виправлень буде почато після отримання перших зауважень, проте буде закінчено перед тим, як всі зауваження від рецензентів будуть отримані і оброблені.

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

Перехрестя (Junction)

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

Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out Junction) стрілок. Перехрестя не може використовуватися одночасно для злиття і для розгалуження. Тобто не може бути одночасно декілька вхідних і вихідних зв’язків.Для внесення перехрестя служить кнопка  - (додати в діаграму перехрестя -Junction) в палітрі інструментів. У діалозі Junction Type Editor необхідно вказати тип перехрестя (рис.10.9).

Таблиця 10.1.

Типи перехресть

"І"-перехрестя. З’єднання цього типу ініціюють виконання всіх своїх кінцевих дій. Всі дії, приєднані до перехрестя злиття "І"-з’єднання, повинні завершитися, перш ніж може почати виконуватися наступна дія. На Рис.  10.10 після отримання замовлення ініціюється перевірка коштів і наявності товару, за умови виконання усіх умов проводиться оплата.

"Ексклюзивне АБО". Незалежно від кількості дій, приєднаних до згортаючого або розгортаючого з’єднання "Ексклюзивне АБО", ініційоване буде тільки одне з них, і тому тільки одне з них буде завершено перед тим, як будь-яка дія, наступна за злиттям "Ексклюзивне АБО", зможе початися.

Перехрестя "АБО". З’єднання цього типу призначені для опису ситуацій, які не можуть бути описані двома попередніми типами з’єднань. Аналогічно зв’язку нечіткого відношення,  з’єднання "АБО" в основному визначається і описується безпосередньо системним аналітиком. На Рис. 10.12 з’єднання J2 може активувати перевірку даних чеку і (або) перевірку суми готівки. Перевірка чеку ініціюється, якщо покупець бажає розплатитися чеком, перевірка суми готівки – при оплаті готівкою. І та, і інша робота ініціюється при частковій оплаті чеком і частково готівкою.

Перехрестя можуть комбінуватися для створення складніших правил розгалуження (Рис. 10.13). Комбінації перехресть слід використовувати з обережністю, оскільки переобтяжені діаграми можуть виявитися складними для сприйняття.

Правила створення перехресть.

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

1. Кожному перехрестю злиття повинно передувати перехрестя розгалуження.
2. Перехрестя для злиття "І" не може слідувати за перехрестям розгалуження типу "АБО" (синхронного або асинхронного). В даному випадку можливий варіант, коли умова J7 ніколи не буде виконана, відповідно такий сценарій не може реалізуватися.
3. Перехрестя для злиття "І" не може слідувати за перехрестям для розгалуження типу "Ексклюзивне АБО". Якщо в попередньому випадку Робота 4 могла бути виконана, якщо були виконані роботи 2 та 3, то в даному випадку Робота 4 ніколи не буде виконана.
4. Перехрестя для злиття типу ексклюзивне "АБО" не може слідувати за перехрестям типу "І" (Рис.  10.16). Після завершення роботи 1 запускаються обидві роботи - 2 і 3, а для запуску роботи 4 необхідно, щоб завершилася одна і лише одна робота або 2, або 3.
5. Перехрестя, що має одну стрілку на вході, повинне мати більш ніж одну стрілку на виході і навпаки.

 Об’єкт „посилання” (Referent).

Об’єкт „посилання” або „вказівник” – це спеціальні символи, які посилаються на інші розділи опису процесу. Вони виносяться на діаграму для залучення уваги читача до яких-небудь важливих аспектів моделі. Вказівник IDEF3 виражає деяку ідею, концепцію або дані, які не можна пов’язати із стрілкою, перехрестям або роботою. Для внесення об’єкту „посилання” служить кнопка Referent Tool на панелі інструментів.

Об’єкт-посилання зображається у вигляді прямокутника, схожого на прямокутник роботи. Ім’я об’єкту- посилання задається в діалозі Referent (Рис. 10.17). Як ім’я можна використовувати ім’я будь-якої стрілки з інших діаграм або ім’я сутності з моделі даних. Об’єкти- посилання повинні бути пов’язані з роботами або перехрестями пунктирними лініями.

Ім’я об’єкта-посилання зазвичай включає його тип (наприклад, ОБ’ЄКТ, UOB) і ідентифікатор. На Рис.  10.18 зображений вказівник типу ОБ’ЄКТ. Відповідно при внесенні об’єктів-посилань крім імені слід вказати тип. Типи об’єктів-посилань наведені в табл. 10.2.

Таблиця 10.2.

Типи об’єктів-посилань

Декомпозиція

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

Оскільки моделі IDEF3 можуть одночасно розроблятися декількома командами, IDEF3 підтримує просту схему резервування номерів робіт в моделі. Кожному аналітикові попередньо виділяється унікальний діапазон номерів робіт, що забезпечує їх незалежність один від одного. Номер роботи вказується у діалоговому вікні Activity Properties-Name параметр Reference Number.

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

На діаграмах IDEF3 ім’я стрілки може бути відсутнім, хоча AFPM показує відсутність імені як помилку.

Призначення сценаріїв IDEF3 аналогічне FEO діаграм. Тобто метою їх створення є ілюстрація певного сценарію розвитку події із багатьох можливих, для більшої наочності. Для створення необхідно вибрати Diagram/Add IDEF3 Scenario.

Завдання 1. Побудова діаграми IDEF3.

Ця робота  є логічним продовженням практичних робіт №7-9

Алгоритм виконання

1. Відкрийте розроблену у попередніх роботах модель.
2. Перейдіть на діаграму А2 і декомпозуйте роботу "Збір настільних комп’ютерів"
3. У діалоговому вікні Activity Box Count (Рис.  10.20) встановіть число робіт 4 і нотацію IDEF3.
4. В результаті буде створена діаграма IDEF3, що містить роботи Unit of Work (UOW). Зверніть увагу на номер діаграми. Правою кнопкою миші клацніть на роботі з номером 1, виберіть в контекстному меню Name і внесіть ім’я роботи "Підготовка компонентів".
5. Потім на вкладці Definition внесіть визначення роботи з номером 1 "Готуються всі компоненти комп’ютера згідно специфікації замовлення"
6. На вкладці UOW діалогового вікна Activity Properties внесіть властивості роботи 1 відповідно до даних Таблиці 10.3.

Таблиця 10.3.

Властивості UOW діалогового вікна Activity Properties

Таблиця 10.4

Назви робіт

Завдання 2. Створення сценарію.

1. Виберіть пункт головного меню Diagram/Add IDEF3 Scenario. Створіть діаграму сценарію "Сценарій збору настільних комп’ютерів" на основі діаграми IDEF3 "Збір настільних комп’ютерів" (А22.1), задавши параметри сценарію Copy contents of source diagram.
2. Видаліть елементи, що не входять в сценарій.
3. Проаналізуйте отриману діаграму.

Завдання 3. Захистіть виконану роботу.

Питання до захисту практичної роботи

1. Що описує діаграма IDEF3?
2. Що ми розуміємо під зовнішньою сутністю?
3. Перерахуйте складові діаграми IDEF3.
4. Що відображають об’єкти-посилання в діаграмах IDEF3?
5. Перерахуйте типи стрілок в діаграмах IDEF3.
6. Яке призначення різних типів стрілок?
7. Дайте визначення перехрестя.
8. Які види перехресть ви знаєте?
9. Які правила створення перехресть вам відомі?
10. Для чого використовується об’єкт-посилання?
11. Які типи об’єктів-посилань вам відомі?
12. Як нумеруються роботи в діаграмі IDEF3?
13. Як додати об’єкт-посилання?
14.  Де вказується тип об’єкту-посилання?
15. Яка послідовність виконання робіт для різних типів стрілок?
16. Для чого використовуються сценарії?

ПРАКТИЧНА РОБОТА № 11
Тема: "Побудова діаграм DFD. Вартісний аналіз (ABC)"

Мета: набути знань і практичних навичок розробки діаграми DFD та використання вартісного.

Хід роботи

Час виконання роботи – 2 години

Теоретичні відомості

ВАРТІСНИЙ АНАЛІЗ (АВС) ТА ЙОГО ВЛАСТИВОСТІ

Вартісний аналіз використовується для оцінки моделі. Він заснований на роботах (Activity Based Costing, ABC) і є інструкцією про облік витрат, пов’язаних з роботами, з метою визначити загальну вартість процесу. Зазвичай АВС застосовується для того, щоб зрозуміти походження вихідних витрат і полегшити вибір потрібної моделі роботи при реорганізації діяльності підприємства (Business Process Reengineering, BPR). ABC може проводитись тільки після завершення створення моделі.

Основні елементи і їх графічне зображення.

АВС включає наступні основні поняття:

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

При проведенні вартісного аналізу в AFPM спочатку задається грошова одиниця. Щоб задати одиницю вимірювання слід викликати діалогове вікно Model Properties (меню Model/Model Properties), вкладка ABC Units.

Якщо в списку вибору відсутня необхідна валюта, її можна додати. Потім  описуються центри  витрат (cost centers). Для  внесення  центрів  витрат необхідно викликати діалог Cost Center Editor (меню Model/Cost Center Editor) Рис. 11.2. Опис центрів витрат можна також здійснювати у вікні Dictonary/Cost center.

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

Щоб задати вартості роботи (для кожної роботи на діаграмі декомпозиції),  слід клацнути правою кнопкою миші на роботі і вибрати Costs(Рис. 11.3). На вкладці Costs діалогу Activity Properties вказується частота проведення даної роботи в рамках загального процесу (Frequency) і тривалість (Duration). Потім слід вибрати в списку центр витрат і у вікні Cost задати його вартість. Аналогічно присвоюються суми по кожному центру витрат, тобто задається вартість кожної роботи по кожній статті витрат. Якщо в процесі призначення вартості виникає необхідність внесення додаткових центрів витрат, викликається діалогове вікно Cost Center Editorкнопкою Activity Cost.

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

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

Результати відображаються безпосередньо на діаграмах. У лівому нижньому куті прямокутника роботи може виводитись або вартість (за замовчуванням), або тривалість, або частота проведення роботи. Налаштування відображення здійснюється в діалоговому вікні Model Properties (меню Model/Model Properties), вкладка Display, опції ABC Data і ABC Units.

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

Результати вартісного аналізу наочно представляються у звіті Activity Cost Report (меню Tools/Report/Activity Cost Report). Звіт дозволяє документувати ім’я, номер, визначення і вартість робіт, як сумарну, так і окремо по центрах витрат (Рис.  11.5). Одержаний звіт можна зберегти та роздрукувати.

Діаграми потоків даних (Data Flow Diagrams)

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

DFD описує:

1. функції обробки інформації (роботи);
2. документи (стрілки, arrow), об’єкти, співробітників або відділи, які беруть участь в обробці інформації;
3. зовнішні посилання або сутність (external reference), які забезпечують зв’язки із зовнішніми об’єктами, що знаходяться за межами модельованої системи;
4. таблиці для зберігання документів (сховища даних, data store).

Для побудови діаграм DFD в AFPM використовується нотація Гейна-Сарсона. У таблиці 11.1 наведені типи об’єктів цієї нотації.

Таблиця 11.1

Типи об’єктів нотації Гейна-Сарсона

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

На панелі інструментів діаграми DFD відображаються нові кнопки:

 - додати в діаграму зовнішнє посилання (External Reference). Зовнішнє посилання є джерелом або одержувачем даних ззовні моделі;

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

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

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

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

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

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

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

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

Альтернативним підходом є підхід, популярний при створенні програмного забезпечення, розділення по подіях (event Partitioning), в якому різні діаграми DFD створюють модель системи. По-перше, логічна модель будується як сукупність робіт і документування того, що ці роботи повинні робити. Потім модель оточення (environment model) описує систему як об’єкт, що взаємодіє з подіями і з зовнішньою сутністю. Модель оточення зазвичай містить опис мети системи, одну контекстну діаграму і список подій. Контекстна діаграма містить один прямокутник роботи, що зображає систему в цілому, і зовнішню сутність, з якою система взаємодіє.

Модель поведінки (behavior model) показує, як система обробляє події. Ця модель складається з однієї діаграми, в якій кожен прямокутник зображає кожну подію із моделі оточення. Сховища можуть бути додані для моделювання даних, які необхідно зберігати між подіями.

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

У DFD номер кожної роботи може включати префікс, номер батьківської роботи (А) і номер об’єкту. Номер об’єкту – це  унікальний номер роботи на діаграмі. Унікальний номер мають сховища даних і зовнішнє посилання незалежно від їх розташування на діаграмі. Кожне сховище даних має префікс D і унікальний номер. Кожна зовнішнє посилання має префікс Е і унікальний номер, наприклад Е5.

Параметри відображення встановлюються уModel Properties/Numbering.

Задання 1. Використання вартісного аналізу (ABC)

Ця робота  є логічним продовженням практичної роботи №7-10

Алгоритм виконання

1. Відкрийте розроблену у попередніх роботах модель.
2. У діалоговому вікні Model Properties (викликається з меню Mode/Model Properties) на вкладці ABC Units встановіть грошову одиницю –  гривня і час – година.
3. Перейдіть в меню Dictionary/Cost Center (Словник/Центр Витрат) і у вікні Cost Center Dictionary (Словник Центру Витрат) внесіть назву і визначення центрів витрат (Таблиця 11.2). Вигляд вікна Cost Center Dictionary після внесення назва і визначення центрів витрат представлений на Рис.  11.7. Зверніть увагу, центри витрат упорядкувалися за алфавітом.

Таблиця 11.2

Центри витрат ABC

Примітка: Для відображення частоти або тривалості роботи перемкніть радіокнопки в групі ABC Units.

Таблиця 11.3.

Показники вартості робіт на діаграмі А2

Перевірте результат – вартість роботи верхнього рівня.

Завдання 2. Створення діаграми DFD.

• Перевірка і внесення клієнта;

• Оформлення замовлення.

• Маркетингові дослідження.

• Список клієнтів;

• Список продуктів;

• Список замовлень.

• Замовлення;

• Маркетингові матеріали.