Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лабораторна робота № 1
"Використання діаграм стандарту IDEF0 для опису бізнес-процесу"
Мета: ознайомлення з принципами проектування на основі CASE-технології; отримання практичних навичок щодо побудови моделі з використанням стандарту IDEF0 в BPwin.
Загальні методичні рекомендації
Модель – опис системи (текстовий або графічний) з визначеним рівнем деталізації.
Об’єкт моделі – об’єкт в базі даних інструментального середовища моделювання, котрий володіє рядом атрибутів, і призначений для відображення реально існуючого об’єкта визначеного типу.
Бізнес-процес – цілеспрямована послідовність процедур, котра необхідна для отримання заданого кінцевого результату.
Процедура – впорядкована послідовність операцій, яка спрямована на отримання проміжного результату.
Бізнес-операція – ряд впорядкованих дій, розглядати які окремо в рамках моделі, що створюється, недоцільно.
Декомпозиція бізнес-процесу – детальний опис бізнес-процесу, який здійснюється шляхом розбиття процесу на декілька частин і наступного їх опису за допомогою більш докладних моделей.
Вхід бізнес-процесу – об’єкт бізнес-процесу (процедура, операція), котрий взаємодіє з зовнішніми бізнес-процесами та отримує від них інформацію (ресурси).
Вихід бізнес-процесу – об’єкт бізнес-процесу (процедура, операція), котрий взаємодіє з зовнішніми бізнес-процесами та передає їм інформацію (ресурси), які є результатом виконання бізнес-процесу.
Ініціююча подія – об’єкт моделі бізнес-процесу, котрий відображає подію, яка є управляючим впливом, що необхідне для початку виконання процедури.
Завершуюча подія – об’єкт моделі бізнес-процесу, що відображає факт завершення процедури та отриманий при цьому результат.
Для опису роботи об'єкту управління (підприємства, проекту) необхідно побудувати модель. Модель являється загальним описом предметної області. Проте модель повинна бути адекватна предметній області і містити в собі знання всіх учасників опису бізнес-процесів організації.
Найбільш зручною мовою моделювання процесів бізнесу є технологія структурного аналізу SADT (модель IDEF0).
Сутність структурного підходу до розробки ІС, проектів бізнесу полягає в її декомпозиції (розбитті) на функції, що автоматизуються: система розбивається на функціональні підсистеми, які в свою чергу діляться на підфункції, що підрозділяються на задачі і так далі. Процес розбиття триває аж до конкретних процедур. Система, що автоматизується, зберігає цілісне уявлення, в якому всі компоненти взаємопов'язані. При розробці системи "знизу-вгору" від окремих задач до всієї системи цілісність втрачається, виникають проблеми при інформаційному стикуванні окремих компонентів.
Всі найбільш поширені методології структурного підходу базуються на низці загальних принципів. Як два базові принципи використовуються наступні:
принцип "розділяй і володарюй" – принцип розв'язання складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення;
принцип ієрархічного впорядковування – принцип організації складових частин проблеми в ієрархічні деревовидні структури з додаванням нових деталей на кожному рівні.
Виділення двох базових принципів не означає, що решта принципів є другорядними, оскільки ігнорування будь-якого з них може привести до непередбачуваних наслідків (у тому числі і до провалу всього проекту). Основними з цих принципів є наступні:
принцип абстрагування – полягає у виділенні суттєвих аспектів системи і відвернення від несуттєвих;
принцип формалізації – полягає в необхідності суворого методичного підходу до вирішення проблеми;
принцип несуперечності – полягає в обґрунтованості і узгодженості елементів;
принцип структуризації даних – полягає в тому, що дані повинні бути структуровані і ієрархічно організовані.
У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, що виконуються системою і відносини між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними серед яких є наступні:
SADT (Structured Analysis and Design Technique) – моделі і відповідні функціональні діаграми (IDEF0, IDEF3);
DFD (Data Flow Diagrams) – діаграми потоків даних;
ERD (Entity-Relationship Diagrams) – діаграми "сутність-зв'язок".
На стадії проектування моделі розширюються, уточнюються і доповнюються діаграмами, що відображають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм і діаграми екранних форм.
Перераховані моделі в сукупності дають повний опис предметній області системи як інформаційної системи (ІС), так і проектів бізнесу незалежно від того, чи вони існуючі або щойно розробляються. Склад діаграм у кожному конкретному випадку залежить від необхідної повноти опису системи.
Методологія SADT є сукупністю методів, правил і процедур, призначених для побудови функціональної моделі об'єкту якої-небудь предметної області. Функціональна модель SADT відображає функціональну структуру об'єкту, тобто вироблювані їм дії і зв'язки між цими діями. Основні елементи цієї методології ґрунтуються на наступних концепціях:
графічне представлення блочного моделювання. Графіка блоків і дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси входу/виходу представляються дугами, що входять в блок і виходять з нього, відповідно. Взаємодія блоків один із одним описуються за допомогою інтерфейсних дуг, що виражають "обмеження", які в свою чергу визначають, коли і яким чином функції виконуються і управляються;
строгість і точність. Виконання правил SADT вимагає достатньої строгості і точності, не накладаючи у той же час надмірних обмежень на дії аналітика.
Правила SADT включають:
обмеження кількості блоків на кожному рівні декомпозиції (як правило, 3-6 блоків);
зв'язність діаграм (принципи нумерації блоків);
унікальність міток і найменувань (відсутність імен, що повторюються);
синтаксичні правила для графіки (блоків і дуг);
розділення входів, механізмів та управлінь (правило визначення ролі даних);
відокремлення організації від функції, тобто виключення впливу організаційної структури на функціональну модель.
Будь-яка система має межу, яка відокремлює її від зовнішнього світу (інших систем). Взаємодія системи з навколишнім світом описується як вхід (ресурс, який переробляється системою – показується з лівої сторони блоку), вихід (результат діяльності системи – показується з правої сторони блоку), управління (стратегії і процедури, під управлінням яких проводиться робота – показується з верхньої сторони блоку) і механізм (ресурси, необхідні для проведення роботи – показується з нижньої сторони блоку). Перебуваючи під управлінням, система перетворить входи у виходи, використовуючи механізми перетворення. У IDEF0 система представлена як сукупність взаємодіючих робіт або функцій. Така функціональна орієнтація є принциповою – функції системи аналізуються незалежно від об'єктів, якими вони оперують. Це дозволяє чіткіше моделювати логіку і взаємодію процесів організації.
Блоки у IDEF0 розміщуються за ступенем важливості, як її розуміє автор діаграми. Цей відносний порядок називається домінуванням. Домінування розуміється як вплив, котрий один блок здійснює на інші блоки діаграми. Наприклад, самим домінуючим блоком діаграми може бути або перший з можливих функцій, котрий є ініціюючою подією, або плануюча чи контролююча функції, котрі впливають на всі інші. Найбільш домінуючий блок зазвичай розміщується у верхньому лівому куті діаграми, а найменш домінуючий – у правому нижньому куті.
Одним з інструментів, котрий дозволяє структурно-функціональне моделювання є BPwin. Головне меню програми BPwin представлене на рис. 1.
Рис. 1. Головне меню BPwin
Опис режимів меню і елементів управління основної палітри BPwin приведені табл. 1.
Таблиця 1
Основні елементи управління основної палітри BPwin
|
Елемент управління |
Опис |
Відповідний пункт меню |
|
Створити нову модель |
File/New |
|
|
Відкрити модель |
File/Open |
|
|
Зберегти модель |
File/Save |
|
|
Надрукувати модель |
File/Print |
|
|
Створити звіт |
Tools/Report Builder |
|
|
Вибір масштабу |
View/Zoom |
|
|
Масштабування |
View/Zoom |
|
|
Перевірка правопису |
Tools/Spelling |
|
|
Включення і виключення навігатора моделі Model Explorer |
View/Model Explorer |
|
|
Включення і виключення додаткової панелі інструментів роботи з ModelMart |
ModelMart |
Основною моделлю опису процесів бізнесу в BPwin є модель IDEF0. Принципи побудови моделі на основі стандарту IDEF0 приведені далі.
Принципи побудови моделі IDEF0 у BPwin
Процес моделювання будь-якої системи в IDEF0 у BPwin починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб'єкта моделювання, мети і точки зору на модель. Під суб'єктом розуміється сама система. Основним завданням є визначення складових системи і зовнішніх дій. На визначення суб'єкта системи суттєво впливає точка зору (позиція), з якої розглядається система, і ціль моделювання, тобто спочатку необхідно визначити область моделювання. Опис області як системи в цілому, так і її компонентів, є основою побудови моделі. В процесі моделювання область може коректуватися, але сформульована вона повинна бути спочатку, оскільки область визначає напрям моделювання і критерії завершення процесу моделювання. При формулюванні області необхідно враховувати широту і глибину моделі (системи). Широта має на увазі визначення меж моделі – кількість компонент всередині і поза системою і їх зв'язком. Глибина визначає рівень деталізації моделі.
Визначення меж моделі припускає, що нові об'єкти не будуть внесені в модельовану систему, оскільки внесення нового об'єкту може змінити існуючі взаємозв'язки в системі (проблема "плаваючої області").
Ціль моделювання (Purpose). Основою проектування є системний підхід, що визначає сувору залежність цілей і задач проектування моделі. Модель не може бути побудована без чітко сформульованої мети. Мета повинна визначати предметну область проектування, задачі проектування, результати проектування. Формулювання цілі дозволяє групі аналітиків фокусувати зусилля в потрібному напрямі. Прикладами формулювання мети можуть бути наступні твердження: "Ідентифікувати і визначити поточні проблеми об'єкту управління (аналізованого об'єкту), зробити можливим аналіз потенційних поліпшень", "Визначити найбільш витратні підрозділи підприємства", "Описати організаційно-функціональну структуру підприємства з метою подальшої розробки інформаційної системи" і т.д.
Точка зору (Point view). При побудові моделі враховують думки різних фахівців, однак модель повинна будуватися згідно єдиної точки зору. Точку зору можна уявити як певний аспект моделювання. Слід зазначити, що точка зору повинна відповідати цілі моделювання. Очевидно, що опис роботи підприємства з погляду фінансиста і технолога виглядає по-різному, тому протягом процесу моделювання важливо виробити єдину точку зору. Як правило, вибирається точка зору фахівця, відповідального за процес моделювання. При виборі точки зору на модель важливим є документування альтернативних моделей, представлень предметної області. Для цієї цілі звичайно використовують діаграми (IDEF0, IDEF3).
IDEF0 модель припускає наявність чітко сформульованої мети єдиного суб'єкта моделювання і однієї точки зору. Для визначення області, цілі і точки зору в моделі IDEF0 у ВРwin слід вибрати пункт меню Model Properties, що викликає діалог Model Properties. У вкладку Рurроsе даного діалогу слід внести ціль і точку зору, а у вкладку Definition – визначення моделі і опис області.
У вкладці Status того ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний і т.д.), час створення і останнього редагування (відстежується надалі автоматично по системній даті). У вкладці Source описуються джерела інформації для побудови моделі (наприклад, "Опитування експертів предметної області і аналіз документації"). Вкладка General служить для внесення назви проекту і моделі, прізвища і ініціалів автора і тимчасових рамок моделей АS-IS і ТО-ВЕ.
Модель може містити чотири типи діаграм:
контекстна діаграма (у кожній моделі може бути лише одна контекстна діаграма);
діаграма декомпозиції;
діаграма дерева вузлів;
діаграма для експозиції (Note).
Контекстна діаграма є вершиною деревовидної структури діаграм і є найзагальнішим описом системи і її взаємодії з зовнішнім середовищем. Після опису системи в цілому проводиться розбиття її на фрагменти. Цей процес називається функціональною декомпозицією, а діаграми, які описують кожен фрагмент і взаємодію фрагментів, називаються діаграмами декомпозиції. Після декомпозиції контекстної діаграми проводиться декомпозиція кожного фрагмента системи на дрібніші і т.д., до досягнення потрібного рівня деталізації опису. Після кожного сеансу декомпозиції проводиться експертиза – експерти предметної області визначають відповідність реальних процесів бізнесу створеним діаграмам. Знайдені невідповідності виправляються, і здійснюється перехід до наступного рівня декомпозиції. Дана процедура дозволяє досягти відповідність моделі реальним процесам бізнесу на будь-якому рівні моделі. Синтаксис опису системи в цілому і кожного її фрагмента однаковий у всій моделі.
Порядок виконання роботи
Для початку роботи з BPwin необхідно зайти в пункт меню Пуск та зі списку програм вибрати Computer Associates BPwin 4.0 / BPwin 4.0 (рис. 2).
Рис. 2. Завантаження BPwin 4.0
Далі, у відповідності з попередніми настройками, Вам буде потрібно або вибрати пункт меню File / New, або вікно створення/відкриття моделі буде автоматично відкрито при завантаженні BPwin (рис. 3).
Рис. 3. Вікно створення / відкриття моделі
В цьому вікні можна вибрати наступні дії:
– Create model – створення нової моделі; при цьому необхідно обов’язково вказати ім’я моделі (Name) та вибрати один з можливих стандартів – IDEF0, IDEF3, DFD;
– Open model – відкрити існуючу модель;
– Display this dialog on startup – починати роботу BPwin з цього вікна.
Нам необхідно створити нову модель з назвою „Управління договорами” в стандарті IDEF0.
Після натискання кнопки ОК Вам буде запропоновано внести властивості для створеної моделі, а саме: Author – внести прізвище та ініціали автора моделі (розробника) – внесіть у це поле свої дані. Після цього натисніть на кнопку ОК.
При цьому буде автоматично створена контекстна діаграма з єдиною роботою, що зображає систему в цілому. Контекстна діаграма представлена процесом (роботою) верхнього рівня. Робота зображується у вигляді прямокутника (рис. 4).
Примітка: При побудові моделей дуже частим явищем є незрозуміле зображення даних, які введені кирилицею (російською, українською та іншими мовами). Для їх адекватного сприйняття необхідно зробити наступне: зайти в пункт меню Model / Default Fonts та зробити наступні настройки як мінімум в пунктах Frame User Text та Frame System Text: змінити шрифт у полі Font на Times New Roman. Після цього треба зайти в пункт меню View / Redraw Diagram або натиснути F12.
Рис. 4. Автоматично створена контекстна діаграма
Побудова контекстної діаграми включає: опис роботи (процесу верхнього рівня), проектування і опис інтерфейсних дуг (стрілок) і формування (опис) каркаса моделі (рамки).
При створенні і опису робіт слід зазначити, що вони повинні бути названі і визначені. Ім'я роботи повинно бути виражено віддієслівним іменником, що позначає дію (наприклад, "Планування постачань", "Моніторинг стану договорів" і т.д.). В нашому випадку процес буде мати ту ж саму назву, що і модель, тобто „Управління договорами”. Для внесення цієї назви необхідно двічі кликнути по лівій кнопці миші або один раз кликнути по правій кнопці та в контекстному меню, що з’явилося, вибрати пункт Name. При цьому відкривається діалог Activity Properties. Замість ім’я „Untitled Object 0” необхідно внести нове ім’я, наприклад, „Управління договорами на виробництво та постачання готової продукції”.
Рис. 5. Внесення назви бізнес-процесу
Основним роботам бізнес-процесу потрібно дати визначення – коротку характеристику. Так робота "Управління договорами на виробництво та постачання готової продукції" може мати наступне визначення: "Робота відноситься до повного циклу проходження договору на підприємстві від отримання заявки на товари підприємства та підписання договору до контролю його виконання та оплати". Для того, щоб її внести, необхідно перейти на закладку Definition діалогу Activity Properties та у відповідне поле внести вищезазначене визначення (рис. 6).
На закладці Status діалогу Activity Properties можна описати статус моделі: Working – робочий варіант, Draft – чорновий, Recommended – для редагування експертами, Publication – кінцевий варіант.
На вкладці Font цього ж діалогу треба обов’язково змінити параметри Font – на Times New Roman Cyr або Arial Cyr, можна змінити стиль тексту (жирний, курсив), кегель шрифту. Після того, як був змінений шрифт необхідно зробити наступні дії: відмітити пункти цієї закладки All activities in this diagram, All activities in this model, Change all occurrences of font in model. Це необхідно проробити, щоб для наступних робіт, інтерфейсних дуг та інших елементів моделі текст, котрий виводиться кирилицею зображувався зрозуміло користувачеві (рис. 7).
Рис. 6. Внесення визначення роботи
Рис. 7. Зміна параметрів шрифту для робіт
На вкладці Color можна змінити колір об’єктів для їх більш наочного зображення.
Для кожної моделі, як зазначалося вище, необхідно внести ціль та точку зору. Для того, щоб їх внести необхідно на робочій області моделі (будь-яка частина моделі, на якій немає об’єктів) натиснути на праву кнопку миші та з контекстного меню обрати пункт Model Properties, або обрати пункт меню Model / Model Properties. На вкладці Purpose необхідно внести ціль (Purpose) та точку зору (Viewpoint). Після цього треба натиснути на кнопку ОК (рис. 8).
Для створення і опису об'єктів на діаграмах використовуються інструменти BPwin Toolbox, які відмінні для різних моделей і стандартів (рис. 9).
У табл. 2 приведений опис призначення інструментів моделі IDEF0.
Рис. 8. Внесення мети і точки зору на модель що проектується
|
IDEF0 |
IDEF3 |
DFD |
Рис. 9. Інструментарій BPwin Toolbox
Після того, як блок бізнес-процесу описаний, можна перейти до малювання інтерфейсних дуг. Для цього обираємо інструмент Precedence Arrow Tool. Для того щоб намалювати інтерфейсну дугу „вхід” підводимо інструмент до лівої межі діаграми і коли з’явиться чорна бордюрна лінія, натискаємо один раз на ліву кнопку миші. Підводимо інструмент до лівої грані блока процесу до моменту, коли з’явиться чорний трикутник (рис. 10) та знову один раз натискаємо на ліву кнопку миші.
Таблиця 2
Опис призначення інструментів моделі IDEF0
|
Інструмент |
Найменування |
Призначення |
|
Pointer Tool |
Використовується для зміни положення вже існуючих об’єктів, зміни розмірів, або внесення даних у них |
|
|
Activity Box Tool |
Блок відображає дію (процес, роботу) в діаграмі |
|
|
Precedence Arrow Tool |
Інструмент використовується для зображення стрілки |
|
|
Squiggle Tool |
Інструмент використовується для створення „блискавки”, котра зв’язує стрілку з її ім’ям |
|
|
Text Tool |
Інструмент використовується для створення текстових коментарів на діаграмах |
|
|
Diagram Dictionary Editor |
Інструмент використовується для відкриття діалогового вікна „Редактор словника діаграм” |
|
|
Go to Parent Diagram |
Використовується для переходу на батьківську діаграму |
|
|
Go to Child Diagram |
Використовується для переходу на діаграму нижнього рівня або для декомпозиції блока процесу на діаграмі |
Аналогічним чином малюються інтерфейсні дуги управління (рис. 11) та механізму (рис. 12).
Рис. 10. Внесення інтерфейсної дуги „вхід”
Рис. 11. Внесення інтерфейсної дуги „управління”
Рис. 12. Внесення інтерфейсної дуги „механізм”
Інтерфейсна дуга „вихід” малюється навпаки. Підводимо інструмент до правої грані блока процесу до моменту, коли з’явиться чорний трикутник (рис. 13) та один раз натискаємо на ліву кнопку миші, після цього підводимо його до правої межі діаграми і коли з’явиться чорна бордюрна лінія, натискаємо ще один раз на ліву кнопку миші.
Рис. 13. Внесення інтерфейсної дуги „вихід”
Після внесення інтерфейсної дуги, необхідно дати їй назву. Наприклад, нам потрібні дві інтерфейсні дуги „вхід” з назвами „Замовлення, заявки” та „Банківська виписка”. Друга інтерфейсна дуга „вхід” малюється аналогічно першій. Для внесення назви необхідно два рази кликнути лівою кнопкою миші на інтерфейсній дузі, або один раз кликнути правою кнопкою миші та з контекстного меню обрати пункт Name. На закладці Name у полі Arrow Name треба внести назву інтерфейсної дуги та нажати кнопку ОК (рис. 14).
Рис. 14. Внесення назви інтерфейсної дуги
Після того, як внесені всі дані по контекстній діаграмі, ми отримаємо те, що наведено на рис. 15.
Рис. 15. Контекстна діаграма моделі
Для переходу на наступний рівень, потрібно провести декомпозицію контекстної діаграми. Для цього треба виділити необхідну роботу (у нашому випадку вона одна) та вибрати інструмент Go to Child Diagram. У вікні, що відкрилося (рис. 16) треба обрати стандарт, котрий буде використовуватися на наступному рівні декомпозиції та кількість робіт на ньому.
В нашому випадку обираємо стандарт IDEF0 та кількість робіт – 5. Нажимаємо на кнопку ОК.
Після цього отримаємо діаграму декомпозиції, котра зображена на рис. 17.
Рис. 16. Вікно вибору типу дочірньої діаграми
та кількості робіт на ній
Рис. 17. Автоматична декомпозиція контекстної діаграми
Роботи на діаграмах декомпозиції розташовуються по діагоналі від лівого верхнього кута до правого нижнього. Даний порядок називається порядком домінування.
Кожна з робіт на діаграмі декомпозиції може бути, у свою чергу, декомпозована. На діаграмі декомпозиції роботи нумеруються автоматично зліва направо. Номер роботи показується в правому нижньому кутку. Всі роботи моделі нумеруються. Номер складається з префікса і числа. Може бути використаний префікс будь-якої довжини, але зазвичай використовують префікс «А». Контекстна (коренева) робота дерева має номер А0. Роботи декомпозиції А0 мають номери А1, А2, АЗ і т.д. Роботи декомпозиції нижнього рівня мають номер батьківської роботи і черговий порядковий номер, наприклад, роботи декомпозиції АЗ матимуть номери А31, А32, А33, А34 і т.д. Роботи утворюють ієрархію, де кожна робота може мати одну батьківську і декілька дочірніх робіт, утворюючи дерево. Таке дерево називають деревом вузлів, а вищеописану нумерацію – нумерацією по вузлах. Є незначні варіанти нумерації, які можна настроїти у вкладці Presentation діалогу Model Property (рис. 18). BPwin. автоматично підтримує нумерацію по вузлах, тобто при проведенні декомпозиції створюється нова діаграма і їй автоматично привласнюється відповідний номер.
Рис. 18. Визначення стандарту ідентифікації блоків процесу
Як видно, на наступний рівень перенесені всі інтерфейсні дуги, котрі використовувалися на контекстній діаграмі. Необхідно дати назви всім роботам, котрі були нами додані на діаграми (найменування робіт, починаючи з контекстної діаграми і завершуючи операціями на найнижчому рівні декомпозиції, повинні бути унікальними). Для того, щоб приєднати інтерфейсні дуги до необхідних робіт, можна зробити наступне:
– перший варіант: обрати інструмент Pointer Tool, нажати лівою кнопкою миші один раз на наконечнику стрілку (для інтерфейсних дуг „вхід”, „управління” чи механізм”) та приєднати її до блоку коли з’явиться чорний трикутник, наче вона тільки що вами створена; або нажати на кінцівці стрілки (для інтерфейсної дуги „вихід”) та приєднати її до правої межі, коли з’явиться чорна бордюр на лінія.
– другий варіант: обрати інструмент Precedence Arrow Tool та виконати ту ж послідовність дій, що і для першого варіанту.
Якщо потрібно зробити розщеплення стрілок, необхідно обрати інструмент Precedence Arrow Tool, нажати лівою кнопкою миші на необхідній інтерфейсній дузі, а потім приєднати її до необхідної роботи.
Примітка: інтерфейсні дуги входу та виходу однієї й тієї ж роботи не можуть бути ідентичними, бо інакше не має сенсу виконувати роботу, яка не дала жодного результату; кожна інтерфейсна дуга повинна мати назву.
Аналогічним чином будуються всі наступні рівні декомпозиції. Приклад опису задачі для модуля „Управління договорами на виробництво та постачання готової продукції” наведений далі.
Приклад опису задачі, що моделювалася
У процесі аналізу предметної області, була складена контекстна діаграма (рис.15), для якої були визначені наступні інтерфейсні дуги:
Декомпозиція контекстної діаграми реалізована на виділенні наступних робіт: укладання договору та моніторинг стану, планування постачань, планування та облік випуску продукції, складський облік готової продукції та її відвантаження, аналіз виконання зобов’язань за договорами, що призводить до наступної діаграми 1-го рівня декомпозиції (рис. 19).
Робота 1-го рівня декомпозиції "Укладання договору та моніторинг стану" має такі інтерфейсні дуги:
Декомпозиція роботи 1-го рівня – "Укладання договору та моніторинг стану" представлена на рис. 20.
Робота 1-го рівня декомпозиції "Планування постачань" має такі інтерфейсні дуги:
Декомпозиція роботи 1-го рівня – "Планування постачань" представлена на рис. 21.
Робота 1-го рівня декомпозиції "Планування та облік випуску продукції" має такі інтерфейсні дуги:
Декомпозиція роботи 1-го рівня – "Планування та облік випуску продукції" представлена на рис. 22.
Декомпозиція роботи 2-го рівня – "Планування та облік випуску продукції" представлена на рис. 23 – 25.
Рис. 19. Декомпозиція контекстної діаграми
Рис. 20. Декомпозиція роботи «Укладання договору та моніторинг стану»
Рис. 21. Декомпозиція роботи «Планування постачань»
Рис. 22. Декомпозиція роботи «Планування та облік випуску продукції»
Рис. 23. Декомпозиція роботи «Планування портфелю замовлень»
Рис. 24. Декомпозиція роботи «Планування виробничої програми»
Рис. 25. Декомпозиція роботи «Облік випуску готової продукції»
Робота 1-го рівня декомпозиції "Складський облік готової продукції та її відвантаження" має такі інтерфейсні дуги:
Декомпозиція роботи 1-го рівня – "Складський облік готової продукції та її відвантаження" представлена на рис. 26.
Декомпозиція роботи 2-го рівня – "Складський облік готової продукції та її відвантаження" представлена на рис. 27 – 29.
Робота 1-го рівня декомпозиції "Аналіз виконання зобов’язань за договорами" має такі інтерфейсні дуги:
Декомпозиція роботи 1-го рівня – "Аналіз виконання зобов’язань за договорами" представлена на рис. 30.
Декомпозиція роботи 2-го рівня – "Аналіз виконання зобов’язань за договорами" представлена на рис. 31 – 33.
Рис. 26. Декомпозиція роботи «Складський облік готової продукції та її відвантаження»
Рис. 27. Декомпозиція роботи «Планування та облік відвантаження товару»
Рис. 28. Декомпозиція роботи «Облік готової продукції на складі»
Рис. 29. Декомпозиція роботи «Формування платіжних вимог»
Рис. 30. Декомпозиція роботи «Аналіз виконання зобов’язань за договорами»
Рис. 31. Декомпозиція роботи «Аналіз відвантажень продукції»
Рис. 32. Декомпозиція роботи «Аналіз платежів за продукцію»
Рис. 33. Декомпозиція роботи «Аналіз виконання договірних зобов’язань»
Завдання та звіт до лабораторної роботи
Необхідно побудувати контекстну діаграму і всі рівні декомпозиції з використанням стандарту IDEF0 згідно до обраної теми диплому.
На основі побудованої моделі, необхідно оформити звіт по лабораторній роботі, що включає:
1) вхідні дані виконання роботи;
2) контекстну діаграму і всі діаграми декомпозиції відповідного варіанту, представлені в стандарті IDEF0;
3) опис процесу побудови діаграми у відповідності з наведеним у лабораторній роботі прикладом.
Контрольні заптання
1. Що зображує діаграма IDEF0?
2. Перерахуйте основні елементи діаграми IDEF0.
3. Що входить в побудову контекстної діаграми?
4. Що таке бізнес-процес?
5. Що таке процедура?
6. Що таке бізнес-операція?
7. Назвіть базові принципи структурного підходу.
8. Які правила SADT використовуються для побудови моделей в стандарті IDEF0?
9. Які види інтерфейсних дуг використовуються в стандарті IDEF0? Дайте їм характеристику.