2.3. Методологія idef3.

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

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

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

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

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

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

2.4. Методологія dfd.

Діаграми потоків даних (Data Flow Diagrams) представляють мережу пов'язаних між собою робіт. Їх зручно використовувати для опису документообігу та обробки інформації.

DFD описує:

• функції обробки інформації (роботи);

• документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;

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

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

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

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

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