Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог до проектованої системи. За їх допомогою ці вимоги представляються у вигляді ієрархії функціональних компонентів (процесів), пов’язаних потоками даних. Головна мета такого представлення –продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відношення між цими процесами. Для побудови DFD традиційно використовуються дві різні нотації, що відповідають методам Йордана і Гейна‑Серсона. Ці нотації незначно відрізняються одна від одної графічним зображенням символів.

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

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

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

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

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

В даній магістерській роботі для побудови DFD-діаграми досліджуваної предметної області було використано середовище Bpwin. BPwin запропонований PLATINUM technology для проведення аналізу і реорганізації бізнес-процесів як CASE-засіб верхнього рівня, який підтримує методології IDEF0 (функціональна модель), IDEF3 (WorkFlow Diagram) і DFD (DataFlow Diagram). Функціональна модель призначена для опису існуючих бізнес-процесів на підприємстві (так звана модель AS-IS) і ідеального стану речей – того, до чого потрібно прагнути (модель TO-BЕ). Методологія IDEF0 специфікує побудову ієрархічної системи діаграм – одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому і її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція – система розбивається на підсистеми і кожну підсистему описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається на більш дрібні і так далі. Для досягнення потрібного ступеня деталізації. Після кожного сеансу декомпозиції проводиться сеанс експертизи: кожна діаграма перевіряється експертами предметної області, представниками замовника, людьми, що безпосередньо беруть участь у процесі. Така технологія створення моделі дозволяє побудувати модель, адекватну, предметній області на всіх рівнях абстрагування. Якщо в процесі моделювання потрібно висвітити специфічні сторони технології підприємства, BPwin дозволяє переключитися на будь-якій цілі моделі на нотацію IDEF3 чи DFD і створити змішану модель. Нотація DFD включає такі поняття, як зовнішня сутність і сховище даних, що робить її більш зручною (у порівнянні з IDEF0) для моделювання документообігу. Методологія IDEF3 включає елемент “перехрестя”, що дозволяє описати логіку взаємодії компонентів системи.

На основі моделі BPwin можна побудувати модель даних. Для побудови моделі даних PLATINUM technology пропонує могутній і зручний інструмент – ERwin. Хоча процес перетворення моделі Bpwin у модель даних погано формалізується і тому цілком не автоматизований, PLATINUM technology пропонує зручний інструмент для полегшення побудови моделі даних на основі функціональної моделі – механізм двонаправленого зв’язку BPwin – ERwin.

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

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

• Процес ідентифікації невизначеностей
• Процес аналізу та оцінки наслідків прийняття рішень
• Процес планування проектами та оперативного керування
• Процес моніторингу

Інформація, якою оперуватиме система прийняття рішень в умовах невизначеності, знаходиться в певних сховищах даних. При проектуванні було вирішено використовувати 6 сховищ, зокрема:

• Характеристики розробника.
• Портфель замовлень.
• Характеристики проектів.
• Характеристики невизначеностей.
• Стан виконання проектів.
• План виконання проектів.

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

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

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

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

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

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