IDEF0 - методологія. Нотація, принципи моделювання. Основні методології обстеження організацій. Стандарт IDEF0 Idef0 моделі у процесі структурної декомпозиції розвиваються

У цьому розділі методику визначення, класифікації та ідентифікації процесів (розділ ____) реалізовано на основі методології функціонального моделювання IDEF0.

1. Визначення ділових процесів як IDEF0-модели

1.1. Визначення ділового процесу.

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

Примітки:

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

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

2 Загальною метою моделей у рамках цього документа є створення системи менеджменту якості, що відповідає вимогам СТБ ISO 9000-2001, СТБ ISO 9001-2001 та СТБ ISO 9004-2001.

Для того, щоб виявити ділові процеси, необхідно визначити таке:

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

Примітка: Для різних видів продукції або категорій споживачів можна розглядати різні ділові процеси.

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

Фабрика є закритим акціонерним товариством. Мета побудови моделі – створення системи менеджменту якості. На підставі цієї інформації в діяльності швейної фабрики можна виділити один діловий процес-«Виробляти жіночі пальта». Входами цього процесу є: а) зовнішня інформація, включаючи вимоги споживачів (магазинів та компаній); б) сировину та матеріали; в) ресурси. Виходами процесу є: а) партії готової продукції, що призначені для споживачів; б) інформація зовнішніх споживачів. Управління процесом складає підставі нормативних документів, що регламентують виробничі процеси на фабриці. Враховуючи, що нас цікавить процес з погляду менеджменту якості, то як зовнішнього управління розглядатимемо нормативні документи, що регламентують цю сферу, у тому числі вимоги СТБ ISO 9000. Карта ділового процесу на швейній фабриці представлена на рис. 3.

Мал. 3 Діловий процес на швейній фабриці

1.2. Опис структури ділового процесу

З другого краю етапі визначення ділового процесу необхідно описати його внутрішню структуру. Для цього необхідно визначити:

з яких процесів складається діловий процес, що моделюється;
як ці процеси взаємодіють між собою.

У моделюванні IDEF0 для опису внутрішньої структури процесу використовується механізм декомпозиції.

Відповідно до вимог методології IDEF0, щоб декомпозувати діловий процес, необхідно створити діаграму – нащадок. На цій діаграмі слід уявити процеси, з яких складається діловий процес у рамках системи менеджменту якості (СМЯ).

Розглянемо декомпозицію ділового процесу "Виробляти жіночі пальта" (рис.3).

З огляду на мету моделювання - відповідність ділового процесу вимогам СТБ ІСО 9001 - 2001 декомпозиція ділового процесу включає 4 блоки процесів, представлених на рис. 4.

Відповідно до вимог СТБ ІСО 9000 діловий процес «Виробляти жіночі пальта» включає такі процеси:

– реалізувати відповідальність найвищого керівництва з менеджменту якості;

- Здійснювати менеджмент ресурсів;

– реалізувати процеси життєвого циклу;

– здійснювати вимірювання, аналіз та поліпшення СУЯ.

Примітка – На малюнку 4 не представлені взаємодії між функціональними блоками, що становлять декомпозицію процесу «Виробляти жіночі пальта».1.3.Опис взаємодій між процесами

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

У методології IDEF0 допустимими є 5 (п'ять) типів взаємодій між блоками в межах однієї діаграми (табл.1):

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

Таблиця 1

	Взаємозв'язок з управління: вихід одного процесу впливає виконання іншого процесу, тобто. вихідна дуга блоку 1 є керуючою для блоку 2. У СТБ ІСО 9001 така взаємодія визначає функцію управління «відповідальність керівництва» по відношенню до інших процесів
	Взаємозв'язок по входу: вихід одного процесу є входом іншого, тобто. вихідна дуга блоку 1 є вхідний для блоку 2. Ця взаємодія характерна для будь-яких процесів в організації, наприклад, для процесів життєвого циклу
	Зворотній зв'язок з управління: виходи з одного процесу впливають виконання інших процесів, виконання яких у свою чергу впливає виконання вихідного процесу. Вихідна дуга блоку 1 є керуючої блоку 2, а вихідна дуга блоку 2 є керуючої для блоку 1. У СТБ ІСО 9001 така взаємодія може визначати: - функцію управління "відповідальність керівництва"; – функцію управління «управління процесами життєвого циклу»; – функцію управління «вимірювання, аналіз та покращення»
	Зворотний зв'язок по входу: вихід із процесу є входом іншого процесу, вихід якого є йому входом, тобто. вихідна дуга блоку 2 є вхідний блоку 1, вихід якого є для нього входом. У СТБ ІСО 9001-2001 така взаємодія може визначати функцію управління «управління процесами життєвого циклу»
	Взаємозв'язок «вихід - механізм»: вихід одного процесу є механізмом іншого, тобто. вихідна дуга блоку 1 є дугою механізму блоку 2. Такий тип зв'язку відноситься найчастіше до процесів забезпечення ресурсами. У СТБ ІСО 9001 така взаємодія може визначати функцію управління "менеджмент ресурсів"

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

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

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

Розглянемо взаємодії між процесами, що становлять діловий процес «Виробляти жіночі пальта» (рис. 5).

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

Процес «Здійснювати менеджмент ресурсів» має зв'язок «вихід – механізм» з процесами «Реалізувати процеси життєвого циклу» та «Здійснювати вимірювання, аналіз та покращення СУЯ».

На діаграмі представлений контур зворотного зв'язку: вихід процесу «Здійснювати вимірювання, аналіз та покращення СМЯ» з входом процесу «Реалізувати відповідальність вищого керівництва з менеджменту якості»

Примітка – Правило повноти функціональної моделі IDEF0 точно відповідає вимогам СТБ ІСО 9001 в частині того, що кожен процес повинен забезпечуватися ресурсами (дуги механізмів у IDEF0-моделі), керуватися (дуги управління), виробляти продукцію на виході (вихідні дуги), переробляючи матеріали. та/або інформацію, що надходять на його входи (вхідні дуги).

Рис.5 – Взаємодія між процесами

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

На діаграмі А0 (рис.5) діловий процес "Виробляти жіночі пальта" представлений у вигляді 4 процесів. Діаграма А0 є першим рівнем декомпозиції (деталізації) цього процесу. Кожен із чотирьох представлених процесів у свою чергу може бути декомпозований. На рис. 6 представлена декомпозиція процесу "Реалізувати процеси життєвого циклу".

На діаграмі А3 (рис. 6) процес «Реалізувати процеси життєвого циклу» представлений у вигляді шести процесів, включаючи «Здійснювати закупівлі», який також може бути декомпозований (рис. 7).

Мал. 6.- Декомпозиція процесу «Реалізувати процеси життєвого циклу»

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

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

Наприклад, для діаграми А34 (рис. 7) фрагмент глосарію виглядатиме так.

Одна картинка коштує тисячі слів

Народна мудрість

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

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

Декілька слів про переваги графіки

Як відомо, функціональні моделі IDEF0 – це завжди графічні схеми. Вони мають свої особливості та правила складання. Про це ми поговоримо трохи згодом. А зараз я хотів би навести кілька прикладів ефективності графіки. Чому я на цьому акцентую? Швидше за все, після мого твердження про необхідність функціональної моделі роботи компанії, багато хто подумав, що це все необов'язково, можна і на словах пояснити як працює та чи інша функція в компанії. Ось про це я хочу поговорити.

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

А тому ідея Ситіна була воістину революційною - він почав друкувати літографічні копії карток із позначенням укріплень і розташувань військових частин. Називалися ці карти “Для читачів газет. Посібник". Ідея виявилася настільки актуальною, що перший тираж “Посібників” розійшовся миттєво. І потім такі програми були дуже потрібні. Причина очевидна. Графіка допомагала зрозуміти те, що з одних слів розібрати було неможливо.

Аналогічний приклад безпорадності словесних описів я можу навести також зі своєї практики. Один із моїх замовників дуже просив взятися за впровадження ERP-системи для його компанії. На запитання, чи є у них якесь технічне завдання, я отримав відповідь: “Так, є. Але у ньому 400 сторінок”. При цьому клієнт дуже скаржився, що мої колеги, яких він звертався раніше, або відмовлялися від проекту взагалі, або називали явно завищені ціни. Після того, як я побачив, що в технічному завданні дійсно 400 сторінок і складається воно виключно з текстового опису, я зрозумів причини поведінки розробників. Прочитати такий обсяг тексту, вникнути в нього, розібратися у всіх нюансах тільки для того, щоб зрозуміти завдання і назвати ціну - це дуже складно.

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

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

Чому це важливо для моєї роботи

Моя робота завжди пов'язана із внесенням змін до існуючої системи. А для того, щоб внести зміни та отримати потрібний результат, потрібно вивчити те, що існує вже зараз. І не важливо, що саме ми робимо – налаштовуємо чи встановлюємо з нуля CRM-систему, створюємо ефективну ERP-систему, займаємось інтеграцією різних систем для підвищення автоматизації роботи загалом. У будь-якому випадку, для початку необхідно отримати уявлення про існуючу схему роботи, і тільки після цього можна пропонувати якісь зміни і продумувати варіанти вирішення поставленого завдання.

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

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

Типові помилки

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

Використання різних кольорів

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

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

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

Занадто велика кількість блоків

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

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

Порушення структури при внесенні коригувань

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

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

Правила назви керуючих елементів та блоків

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

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

Вигоди використання IDEF0

Найперша вигода очевидна – це наочність.Ви самі починаєте розуміти, як працює та чи інша система, і можете наочно пояснити, де в цій системі «тонкі місця» і як ваші рішення допоможуть позбутися їх.
Порозуміння та відсутність різночитань.При обговоренні роботи компанії з використанням функціональної моделі у вас є наочні та зрозумілі інтуїтивні блоки завдань з керуючими елементами. Крім того, функціональне моделювання передбачає створення у разі потреби глосарію, в якому розкриваються умовні позначення та терміни. В результаті ви з клієнтом, керівником, іншими співробітниками під час обговорення проблеми говорите однією мовою.
Простота та висока швидкість створення моделі.Звичайно, навчитися моделювання не так просто, як здається. Адже схема - це, по суті, надщільне подання інформації, що дуже добре для розуміння, але для реалізації такої подачі потрібен особливий підхід. Мозок аналітика виступає у разі як дуже потужний прес з одного боку, і фільтр – з іншого. Але з досвідом цей процес стає дуже швидким. В результаті ви отримуєте інструмент, який допоможе і самому розібратися, що відбувається в тій чи іншій системі, і за допомогою створеного в стислі терміни наочної допомоги проілюструвати важливі моменти колегам або замовникам.
Дисципліна та відсутність помилок.Стандарт IDEF0 передбачає строгі рамки та правила. Такий підхід дисциплінує, а звичка діяти в рамках стандарту допомагає уникнути помилок щодо неуважності. Будь-які порушення стандарту стають одразу помітними.

У чому складність застосування IDEF0

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

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

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

Ще статті на цю тему.

Далі розглянемо стандартні методи системного структурного аналізу, описані серією федеральних стандартів США. Icam Definition", відповідно до . Детальну інформацію щодо всіх стандартів цієї серії можна знайти на сайті http://www.idef.com.

Стандарт IDEF0(FIPS183) призначений для створення функціональної моделі, що відображає структуру та функції системи, а також потоки інформації та матеріальних об'єктів, що пов'язують ці функції. Цей документ є оформленням (за ініціативою Міністерства оборони США) у вигляді стандарту технології аналізу складних систем SADT(Structured Analysis and Design Technique), розробленою групою американських аналітиків на чолі з Дугласом Россом у 1973 році.

Метод, запропонований стандартом IDEF0, призначений для функціонального моделювання, тобто моделювання виконання функцій об'єкта, шляхом створення описової графічної моделі, що показує, як і ким робиться в рамках функціонування підприємства. Функціональна модель є структурованим зображенням функцій виробничої системи або середовища, інформації та об'єктів, що пов'язують ці функції. Модель будується методом декомпозиції: від великих складових структур до дрібніших, найпростіших. Елементи кожного рівня декомпозиції є дії з переробки інформаційних або матеріальних ресурсів за певних умов з використанням заданих механізмів. Кожна дія розкладається більш дрібні операції з переробки певної частини інформаційних чи матеріальних ресурсів за певних умов із використанням частини заданих механізмів. Аналогічно розкладаються операції. Останній крок декомпозиції повинен призводити до отримання моделі, ступінь деталізації якої відповідає вимогам, заданим на самому початку процесу створення моделі.

Методологія IDEF0 заснована на таких положеннях:

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

2. Блокове моделювання та його графічне уявлення. Основний концептуальний принцип методології IDEF – представлення будь-якої системи, що вивчається у вигляді набору взаємодіючих і взаємопов'язаних блоків, що відображають процеси, операції, дії, що відбуваються в системі, що вивчається. У IDEF0 усе, що відбувається у системі та її елементах, прийнято називати функціями. Кожній функції ставиться у відповідність блок. На IDEF0-діаграмі (частіше говорять SADT-діаграмі), основному документі при аналізі та проектуванні систем, блок є прямокутником. Інтерфейси, за допомогою яких блок взаємодіє з іншими блоками або із зовнішнім по відношенню до моделюється системі середовищем, представляються стрілками, що входять в блок або виходять з нього. Вхідні стрілки показують, які умови повинні бути виконані, щоб функція, що описується блоком, здійснилася.

3. Суворість та формалізм. Розробка моделей IDEF0 вимагає дотримання низки строгих формальних правил, що забезпечують переваги методології щодо однозначності, точності та цілісності складних багаторівневих моделей. Ці правила описуються нижче з погляду технології SADT. Тут відзначається тільки основне з них: всі стадії та етапи розробки та коригування моделі повинні суворо, формально документуватися для того, щоб при її експлуатації не виникало питань, пов'язаних з неповнотою чи некоректністю документації.

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

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

Приклади завдань, які вирішуються на основі методології моделювання IDEF0:

Аналіз та реінжиніринг бізнес-процесів.

Розробка інформаційної системи управління даними якості.

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

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

Завдання аналізу ризиків щодо інформаційної безпеки.

Розглянемо відповідно до роботи принципи побудови діаграм за технологією SADT (IDEF0).

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

Першим із них є поняття « функціональний блок». Функціональний блок графічно зображується у вигляді прямокутника (див. рис. 3.23) і уособлює деяку конкретну функцію в рамках аналізованої системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульована у дієслівному способі (наприклад, « виробляти послуги", а не " виробництво послуг»). Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), причому: верхня сторона має значення « управління» (cont r ol); ліва сторона має значення « Вхід» ( input); права сторона має значення « вихід» ( output); нижня сторона має значення « механізм» ( mechanism). Кожен функціональний блок у рамках єдиної системи, що розглядається, повинен мати свій унікальний ідентифікаційний номер.

Методологія IDEF0

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

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

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

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

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

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

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

Розташування блоків на сторінці відображає авторське визначення домінування. Таким чином, топологія діаграми показує, які функції мають більший вплив на інші. Щоб підкреслити це, аналітик може перенумерувати блоки відповідно до порядку їхнього домінування. Порядок домінування може позначатися цифрою, розміщеної в нижньому правому куті кожного прямокутника: 1 буде вказувати на найбільше домінування, 2 - на наступне і т.д.

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

У IDEF0 розрізняють п'ять типів стрілок.

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

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

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

Механізм- Ресурси, що виконують роботу. Стрілка механізму малюється як входить у нижню грань роботи. На розсуд аналітика стрілки механізму можуть не зображуватися на моделі.

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

Мал. 2.1Типи стрілок

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

Мал. 2.2.Зв'язок по виходу

Мал. 2.3.Зв'язок з управління

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

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

Зворотний зв'язок із управління виникає тоді; коли вихід деякого блоку впливає блок з великим домінуванням.

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

Мал. 2.4.Зворотній зв'язок

Мал. 2.5.Зворотній зв'язок з управління

Зв'язки "вихід-механізм" характерні при розподілі джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали).

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

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

непомічені гілки містять вагу об'єкти, вказані в мітці дуги перед розгалуженням;

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

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

Мал. 2.6.Зв'язок вихід-механізм

непомічені гілки містять вагу об'єкти, зазначені у загальній мітці дуги після злиття;

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

кількість блоків на діаграмі - N;

рівень декомпозиції діаграми - L;

збалансованість діаграми - В;

число стрілок, що з'єднуються з блоком, - А

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

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

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

Мал. 2.7.Приклад незбалансованої діаграми

Введемо коефіцієнт збалансованості діаграми

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

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

Після формування словника та складання пакета діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіги назв блоків діаграм і слів зі словника, це говорить, що достатній рівень декомпозиції досягнутий. Коефіцієнт, що кількісно відображає даний критерій, можна записати як L*C -твір рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, в якому слід зазначити, чи буде створено модель заново, чи вона буде відкрита з репозиторію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).

Рис.2.8Діалог створення моделі

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

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

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

Після вивчення вихідних документів та опитування замовників та користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи "Служба зайнятості у рамках вузу", основні можливості якої були описані у лабораторній роботі №1.

Сформулюємо мету моделювання: описати функціонування системи, яке було б зрозуміле її користувачеві, не вдаючись у подробиці, пов'язані з реалізацією. Модель будуватимемо з погляду користувачів (студент, викладач, адміністратор, деканат, фірма).

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

Для того, щоб обслужити клієнта, необхідно зареєструвати його в системі, відкрити доступ до БД та обробити його запит. Як вхідні дані використовуватимуться «ім'я клієнта», «пароль клієнта», «вихідна БД», «запит клієнта». Виконання запиту веде або до отримання інформації від системи, або зміни вмісту БД (наприклад, при складанні експертних оцінок), тому вихідними даними будуть «звіти» і «змінена БД». Процес обробки запитів виконуватиме монітор системи під контролем адміністратора.

Отже, визначимо контекстну діаграму системи (рис. 2.9).

Рис. 2.9.Контекстна діаграма системи

Проведемо декомпозицію контекстної діаграми, описавши послідовність обслуговування клієнта:

Визначення рівня доступу до системи.

Вибір підсистеми.

Звертання до підсистеми.

Зміна БД (за потреби).

Отримаємо діаграму, зображену на рис. 2.10.

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

Мал. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"

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

Мал. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»

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

Декомпозуємо роботу «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед пошуком відповіді на запит необхідно відкрити БД (підключитися до неї). У випадку БД може бути на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність робіт:

Відкриття БД.

Виконання запиту.

Генерація звітів

Після відкриття БД необхідно повідомити систему встановлення з'єднання з БД, після чого виконати запит і згенерувати звіти для користувача (мал. 2.12).

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

Мал. 2.12.

При аналізі отриманої діаграми постає питання, за якими правилами відбувається генерація звітів? Необхідна наявність заздалегідь сформованих шаблонів, за якими проводитиметься вибірка з БД, причому ці шаблони повинні відповідати запитам і повинні бути визначені заздалегідь. Крім того, клієнту має бути надана можливість вибору форми звіту.

Скоригуємо діаграму, додавши до неї стрілки «Шаблони звітів» та «Запити на зміну БД» та тунельну стрілку «Клієнт системи». Тунелювання «Клієнта системи» застосовано для того, щоб не виносити стрілку на діаграму верхнього, тому що функція вибору форми звіту не є достатньо важливою для відображення її на батьківській діаграмі.

Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).

Декомпозицію роботи «Виконання запиту» доцільно провести з допомогою діаграми DFD (лабораторна робота № 3), оскільки методологія IDEF0 розглядає систему як сукупність взаємозалежних робіт, що негативно відбиває процеси обробки інформації.

Мал. 2.13.Декомпозиція роботи "Обробка запиту клієнта"

Мал. 2.14.Декомпозиція роботи "Обслуговування клієнта системи" (варіант 2)

Мал. 2.15.Контекстна діаграма системи (варіант 2)

Перейдемо до декомпозиції останнього блоку "Зміна БД". З погляду клієнта, ці системи розташовуються в одній БД. Реально в системі присутні шість БД:

БД користувачів,

БД студентів, (варіант 2)

БД вакансій

БД успішності,

БД тестів

БД експертних оцінок,

БД резюме.

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

Визначається БД, у якій змінюватиметься інформація.

Оператором формується тимчасовий набір даних та надається адміністратору.

Адміністратор здійснює контроль даних та вносить їх до БД.

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

Мал. 2.16.Декомпозиція роботи «Зміна БД»

Мал. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного на рис. 2.12

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

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

Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно з вищеописаною методикою. Розглянемо поведінку коефіцієнта у цих моделей. У батьківської діаграми «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а діаграми декомпозиції 3/3 = 1. Значення коефіцієнта зменшується, що свідчить про спрощення описи функцій зі зниженням рівня моделі.

Розглянемо зміну коефіцієнта До b у двох варіантів моделей.

для другого варіанта

Коефіцієнт До b не змінює свого значення, отже, збалансованість діаграми не змінюється.

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

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

Мета роботи:

вивчення основних принципів методології IDEF0,
створення нового проекту в BPWin,
формування контекстної діаграми,
проведення зв'язків.

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

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

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

Типи стрілок

У IDEF0 розрізняють п'ять типів стрілок.

Мал. 2.1Типи стрілок

Мал. 2.2.Зв'язок по виходу

Мал. 2.3. Зв'язок з управління

Зворотний зв'язок із управління виникає тоді; коли вихід деякого блоку впливає блок з великим домінуванням.

Мал. 2.4.Зворотній зв'язок

Мал. 2.5.Зворотній зв'язок з управління

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

Мал. 2.6.Зв'язок вихід-механізм

непомічені гілки містять вагу об'єкти, зазначені у загальній меткедуги після злиття;
помічені перед злиттям гілки містять усі або деякі об'єкти з перерахованих у загальній мітці після злиття,

Кількісний аналіз діаграм

Для проведення кількісного аналізу діаграм перерахуємо показники моделі:

кількість блоків на діаграмі - N;
рівень декомпозиції діаграми - L;
збалансованість діаграми - В;
число стрілок, що з'єднуються з блоком, - А

Мал. 2.7.Приклад незбалансованої діаграми

Введемо коефіцієнт збалансованості діаграми

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

Інструментарій BPWin

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, в якому слід зазначити, чи буде створено модель заново, чи вона буде відкрита з репозитарію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).