Як створити idef0 діаграму. Курсова робота: Розробка моделі підприємства тепличного господарства, використовуючи методології проектування IDEF0, DFD та IDEF3. Діаграма декомпозиції А3

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

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

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

перевага графіки

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

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

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

Переваги IDEF0 дляIT-спеціалістів

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

Так як же доступно донести суть, не вдаючись до об'ємним текстів? Графіка! Саме вона дозволяє скоротити написане, наочно демонструючи потрібну інформацію. Адже одне зображення здатне замінити сотні слів. І стосовно до використання графіки при описі бізнес-процесів - це на 100% вірно.

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

Нотація опису бізнес-процесів: що це таке

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

IDEF0 - це ...

IDEF0 - метод функціонального моделювання, а також графічна нотація, яка використовується для опису і формалізації бізнес-процесів. Особливість IDEF0 полягає в тому, що ця методологія орієнтована на підпорядкованість об'єктів. IDEF0 була розроблена для автоматизації підприємств ще в 1981 році в США.

Функціональна модель компанії

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

типи стрілок

входятьставляться завдання.

вихіднимививодять результат діяльності.

керуючі(Стрілки зверху вниз) - це механізми управління.

механізми(Стрілки від низу до верху) використовуються для проведення необхідних робіт.

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

IDEF0 дозволяє обмінюватися інформацією, при цьому завдяки універсальності і наочності учасники обміну легко зрозуміють один одного. IDEF0 ретельно розроблявся і вдосконалювався, працювати з IDEF0 можна за допомогою різних інструментів, наприклад, ERWIN, VISIO, Bussines studio.

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

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

Як створюється функціональна модель

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

основний блокбуде так і називатиметься «Написання статті».

Те, що необхідно для написання статті, відбивається на що входять стрілках- «Досвід», «Додаткова література».

керуючі стрілкидля написання статті - «План статті», «Вимоги до оформлення», «Правила російської мови».

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

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

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

Так, весь процес написання статті можна розділити на 4 етапи:

  1. Підготувати аудиоверсию.
  2. Підготувати текст в друкованому вигляді.
  3. Редагування і підготовка тексту до друку.
  4. Публікація статті.

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

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

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

Процес створення нотаціїIDEF0

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

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

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

Другу нотацію можна назвати «Як повинно бути». Вона створюється на основі першої із змінами, внесеними згідно з поставленим завданням.

Стандарт IDEF0 і його вимоги

Про базові вимоги IDEF0 ми говорили трохи вище.

  1. Головний елемент - у верхньому лівому кутку.
  2. Кожен елемент повинен мати вхідні і вихідні стрілки. Причому входять стрілки знаходяться зліва, справа - вихідні.
  3. Зверху розташовуються керуючі елементи, знизу - механізми.
  4. При розташуванні декількох блоків на одному аркуші або екрані наступні розміщуються праворуч внизу від попереднього.
  5. Схеми слід створювати так, щоб стрілки перетиналися мінімальну кількість разів.
Природно, в стандарті IDEF0 є загальноприйняті норми, вимоги та позначення. Детально на них зупинятися не будемо, при бажанні цю інформацію нескладно знайти.

Помилки при роботі з IDEF0

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

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

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

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

Велика кількість блоків

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

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

Зміна структури при виправленні помилок

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

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

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

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

Переваги використання IDEF0

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

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

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

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

І на останок

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

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


Навчіться бачити і розуміти функціональну структуру свого бізнесу!

В даний час в Росії різко зріс інтерес до загальноприйнятих на Заході стандартам менеджменту, проте, в реальній практиці управління існує один дуже показовий момент. Багатьох керівників до сих пір можна поставити в глухий кут прямим питанням про організаційній структурікомпанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, як правило, починають креслити зрозумілі тільки їм одним ієрархічні діаграми, а й в цьому процесі зазвичай швидко заходять в глухий кут. Те ж саме стосується співробітників і керівників різних служб і функціональних підрозділів. У більшості випадків, єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень і посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов'язаних між собою і, внаслідок цього, просто припадають пилом на полицях. До пори до часу подібний підхід був виправданий, тому що під час становлення російської ринкової економіки поняття конкуренції практично було відсутнє, та й витрати вважати не було особливої ​​потреби - прибуток була гігантською. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, які виросли на початку 90-х років, поступово здають свої позиції, аж до повного виходу з ринку. Частково це обумовлено тим, що на підприємстві не були впроваджені стандарти управління, повністю відсутнє поняття функціональної моделі діяльності і місії. За допомогою моделювання різних областей діяльності можна досить ефективно аналізувати "вузькі місця" в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають тільки ті проекти, які безпосередньо приносять прибуток, тому мова про обстеження діяльності та її реорганізації зазвичай йде тільки під час відчутного кризи в управлінні компанією.

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

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

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

IDEF1 - методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру і взаємозв'язки;

IDEF1X (IDEF1 Extended) - методологія побудови реляційних структур. IDEF1X відноситься до типу методологій "Сутність-взаємозв'язок" (ER - Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до даної системи;

IDEF2 - методологія динамічного моделювання розвитку систем. У зв'язку з досить серйозними труднощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. Однак в даний час присутні алгоритми і їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані на базі "розфарбованих мереж Петрі" (CPN - Color Petri Nets);

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

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

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

Історія виникнення стандарту IDEF0

Методологію IDEF0 можна вважати наступним етапом розвитку добре відомого графічного мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому в Росії невеликим тиражем вийшла однойменна книга, присвячує опису основних принципів побудови SADT-діаграм. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, яка носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = ICAM DEFinition). В процесі практичної реалізації, учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому крім вдосконаленого набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках "аналітик-фахівець". Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.

В результаті пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. C 1981 року стандарт IDEF0 зазнав кілька незначних змін, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом За стандарти і Технологій США (NIST).

Основні елементи і поняття IDEF0

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

Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. Рис. 1) і уособлює собою деяку конкретну функцію в рамках даної системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульовано в глагольном способі (наприклад, "виробляти послуги", а не "виробництво послуг").

Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

  • Верхня сторона має значення "Управління" (Control);
  • Ліва сторона має значення "Вхід" (Input);
  • Права сторона має значення "Вихід" (Output);
  • Нижня сторона має значення "Механізм" (Mechanism).

    • Кожен функціональний блок в рамках єдиної даної системи повинен мати свій унікальний ідентифікаційний номер.

    Малюнок 1. Функціональний блок.

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

    Графічним відображенням інтерфейсної дуги є односпрямованим стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування повинно бути оборотом іменника.

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

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

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

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

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


    Малюнок 2.

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


    Малюнок 3.

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

    Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

    Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

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

    Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою, і позначається ідентифікатором "А-0".

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

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

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

    У процесі декомпозиції, функціональний блок, який в контекстної діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Отримана діаграма другого рівня містить функціональні блоки, що відображають головні подфункции функціонального блоку контекстної діаграми і називається дочірньої (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірній діаграмі відповідно називається дочірнім блоком - Child Box). У свою чергу, функціональний блок - предок називається батьківським блоком по відношенню до дочірньої діаграмі (Parent Box), а діаграма, до якої він належить - батьківської діаграмою (Parent Diagram). Кожна з подфункций дочірньої діаграми може бути далі деталізована шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному разі декомпозиції функціонального блоку все інтерфейсні дуги, що входять у цей блок, або виходять з нього фіксуються на дочірньої діаграмі. Цим досягається структурна цілісність IDEF0 - моделі. Наочно принцип декомпозиції представлений на малюнку 4. Слід звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра в правому нижньому кутку прямокутника), а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми . Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.

    Часто бувають випадки, коли окремі інтерфейсні дуги не має сенсу продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії, або навпаки - окремі дуги не мають практичного сенсу вище якогось рівня. Наприклад, интерфейсную дугу, яка зображує "деталь" на вході в функціональний блок "Обробити на токарному верстаті"Не має сенсу відображати на діаграмах більш високих рівнів - це буде тільки перевантажувати діаграми і робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше деякого рівня. Для вирішення подібних завдань в стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунелю" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку - приймача означає той факт, що в дочірньої по відношенню до цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти і відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії - в такому випадку, вони спочатку "занурюються в тунель", а потім, при необхідності "повертаються з тунелю".

    Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення і підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даними елементом. Цей набір називається глосарієм і є описом суті даного елемента. Наприклад, для керуючої інтерфейсної дуги "розпорядження про оплату" глосарій може містити перелік полів відповідного дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочний графічний мову, забезпечуючи діаграми необхідної додатковою інформацією.


    Малюнок 4. Декомпозиція функціональних блоків.

    Принципи обмеження складності IDEF0-діаграм

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

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

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

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

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

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

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

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

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

    В останні рокиінтерес в Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної web-сторінці (http://www.vernikov.ru), на якій коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5 я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-засоби, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на российкие ринку ще в 1996 році, одночасно з виходом популярної книги по принципам моделювання в стандартах SADT.

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

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

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

    Що надходить до підрозділу "на вході"?

    Які функції, і в якій послідовності виконуються в рамках підрозділу?

    Хто є відповідальним за виконання кожної з функцій?

    Чим керується виконавець при виконанні кожної з функцій?

    Що є результатом роботи підрозділу (на виході)?

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

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

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

    Відома сьогодні вже не тільки у вузьких колах абревіатура IDEF0 є першою методологією, що стандартизує роботу над бізнес-процесами. Вона була розроблена в середині минулого століття в рамках аерокосмічного проекту в США і, показавши свою ефективність, стала федеральним стандартом. У нашій країні 2000 року підготовлений документ « Методологія функціонального моделювання IDEF0. керівний документ Методологія функціонального моделювання IDEF0 Керівний документ. Видання офіційне. Держстандарт Росії РД IDEF0 - 2000. Розроблено Науково-дослідним Центром CALS - технологій «Прикладна Логістика». Прийнято і введений в дію наказом Держстандарту України 2000 г. Москва», Але як стандарт він так і не був затверджений. Хоча це не завадило даної методології стати в нашій країні одним з найбільш популярних інструментів графічного моделювання бізнес-процесів. У даній статті я пропоную вам розглянути модель IDEF0 і оцінити актуальність цього підходу в даний час.

    Основні поняття і скорочення

    Розберемося трохи з назвами ключових елементів методології. Графічний стандарт IDEF0 є частиною методології SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування). IDEF - це скорочення від ICAM Definition, а ICAM утворено від Integrated Computer Aided Manufacturing, що перекладається як інтегрована комп'ютеризація виробництва. Методологія SADT - це ціле сімейство з 15 різних моделей, які в комплексі повинні були дозволити досліджувати структуру, параметри і характеристики виробничо-технічних і організаційно-економічних систем.

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

    Нотація IDEF0 - це досить сувора методика, яка спочатку була розроблена, як і стандарти технічного конструювання, для ручного моделювання. Тому там містяться вимоги щодо розміщення стрілок, формату всіх елементів, змісту інформаційної рамки до IDEF0 діаграмі тощо. Оскільки діяльність компанії - це складна багаторівнева система дій, то схем виходить завжди багато, і необхідна однозначна систематизація і навігація по всіх елементах моделі. Зараз це роблять в основному комп'ютерні системи, що підтримують моделювання в даній нотації. На території Росії найбільш відомими і доступними на сьогодні є системи AllFusion Process Modeler і Business Studio. Оглядом цих систем я планую присвятити окремі статті.

    функціональний блок

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

    Обов'язкові елементи функціонального блоку в IDEF0

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

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

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

    Для побудови функціональної моделі методологія IDEF0 вимагає дотримуватися таких правил.

    1. Входи - це ресурси, які переносять свою вартість в виходи повністю, тобто витрачаються на створення результату повністю, а механізми - це ресурси, які переносять свою вартість тільки частково (обладнання - через амортизацію, а люди - через заробітну плату).
    2. Управління - це необхідний елемент моделі, так як він прив'язує всі дії до системи регламентів компанії, чітко позначаючи, які правила і вимоги повинні бути дотримані в процесі виконання функції. Часто до цього потоку відносяться формально, але при цьому схема втрачає строгість, а іноді навіть сенс.
    3. У кожного функціонального блоку повинна бути як мінімум одна стрілка з кожного боку (так як не може бути роботи без ресурсів або результатів, а також неповної буде інструкція без виконавця або інструкції).

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

    Контекстна діаграма

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

    1. Мета - конкретна формулювання призначення моделі, по якій можна звіряти надалі точність побудови моделі.
    2. Точка зору - від чийого особи будується модель, так як модель залежна завжди від її автора і фокусу уваги. Якщо ми будуємо загальну модель підприємства, то зазвичай вона представляється з точки зору його директора.
    3. Тип моделі - це вказівка ​​на те, яка інформація відображена на схемах. Тут може бути 2 принципових варіанти: AS IS ( «як є») або TO BE ( «як буде»). Такий поділ необхідно, так як ми можемо будувати моделі як для аналізу діяльності, так і для її трансформації. Ми повинні чітко усвідомлювати те, що ми робимо, а також доносити цю інформацію до оточуючих.

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

    Основні потоки

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

    1. Матеріальний: матеріали та комплектуючі на вході і готова продукціяна виході.
    2. Клієнтський: потенційний клієнт на вході і задоволений на виході.
    3. Фінансовий: на вході це зазвичай інвестиції, платежі клієнтів (виручка), кредити та інші доходи; на виході - це платежі постачальникам, податки, платежі по кредитах і прибуток.
    4. Інформаційний: на вході це все потоки інформації про зовнішнє середовище (стан ринку, поведінку конкурентів, технологічні інноваціїта ін.), а на виході - це потік інформації, яку компанія повідомляє про себе світові (вся рекламна інформація, а так само всі види звітності перед контролюючими органами).

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

    (Натисніть для збільшення)

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

    Стрілки управління можуть бути представлені тільки 1 видом потоку - інформаційним, який можна розбити на 2 підвиди. Перший - це документи, такі як:

    • закони та норми;
    • накази, розпорядження;
    • інструкції і регламенти;
    • плани;
    • конструкторська документація та ін.

    Другий - це недокументированная інформація, до якої найчастіше ставляться вимоги власників.

    І, нарешті, механізми - тут тільки 2 види потоків: обладнання (матеріальний) і виконавці (підрозділи і люди). Тут не може бути документів, як і не може бути людей на стрілках управління!

    Для навігації в моделі передбачена наскрізна нумерація. Контекстна діаграма нумерується «А-0». Надалі кожен функціональний блок отримує свій номер, який би глибокої не була декомпозиція.

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

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

    (Натисніть для збільшення)

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

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

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

    На малюнку нижче представлена ​​діаграма декомпозиції нашого прикладу.

    (Натисніть для збільшення)

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

    Подальша робота над моделлю аналогічна першому кроці - проводиться декомпозиція кожного функціонального блоку першого рівня. Нумерація блоків буде містити при цьому номер першого рівня: А1.1 ... А1.n, A2.1 ... A2.n і т.д.

    Висновки про актуальність нотації

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

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

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

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

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

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

    6.2. Призначення і склад методології SADT (IDEF0)

    Методологія SADT (Structured Analysis and Design Technique - методологія структурного аналізу і проектування) являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі системи.

    Початок розробки даної методології було покладено Дугласом Россом (США) в середині 60-х рр. ХХ ст. З тих пір системні аналітики компанії SofTech, Inc. поліпшили SADT і використовували її в рішенні широкого кола проблем. Програмне забезпечення телефонних мереж, діагностика, довгострокове і стратегічне планування, автоматизоване виробництвоі проектування, конфігурація комп'ютерних систем, навчання персоналу, управління фінансами та матеріально-технічним постачанням - ось деякі з областей ефективного застосування SADT. Широкий спектр областей вказує на універсальність і міць методології SADT. У програмі «Інтеграції комп'ютерних та промислових технологій»(Integrated Computer Aided Manufacturing, ICAM) Міністерства оборони США була визнана корисність SADT. Це призвело до публікації її частини в 1981 р, званої IDEF0 (Icam DEFinition), в якості федерального стандартуна розробку програмного забезпечення. Під цією назвою SADT стала застосовуватися тисячами фахівців у військових і промислових організаціях. Остання редакція стандарту IDEF0 була випущена в грудні 1993р. Національним інститутом по стандартам і технологіям США (National Institute Standards and Technology, NIST).

    Дана методологія при описі функціонального аспекту інформаційної системи конкурує з методами, орієнтованими на потоки даних (DFD). На відміну від них IDEF0 дозволяє:

    Описувати будь-які системи, а не тільки інформаційні (DFD призначена для опису програмного забезпечення);

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

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

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

    Модель (AS-IS, TO-BE або SHOULD-BE) може містити 4 типи діаграм [ , ]:

    Контекстну діаграму;

    Діаграми декомпозиції;

    Діаграми дерева вузлів;

    Діаграми тільки для експозиції (for exposition only, FEO).

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

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

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

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

    6.3. Елементи графічної нотації IDEF0

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

    На наступному малюнку показані основні елементи графічної нотації IDEF0.

    Мал. 6.1. Елементи графічної нотації IDEF0

    Прямокутник є роботу (процес, діяльність, функцію або завдання) , Яка має фіксовану мета і призводить до деякого кінцевого результату. Ім'я роботи повинне виражати дію (наприклад, «Виготовлення деталі», «Розрахунок допустимих швидкостей», «Формування відомості ЦДЛ № 3»).

    Взаємодія робіт між собою і зовнішнім світом описується в вигляді стрілок. В IDEF0 розрізняють 5 видів стрілок :

    - Вхід (Англ. Input) - матеріал або інформація, які використовуються і перетворюються роботою для отримання результату (виходу). Вхід відповідає на питання «Що підлягає обробці?». В якості входу може бути як матеріальний об'єкт (сировина, деталь, екзаменаційний білет), так і не має чітких фізичних контурів (запит до БД, питання викладача). Допускається, що робота може не мати жодної стрілки входу. Стрілки входу завжди малюються входять в ліву грань роботи;

    - управління (Англ. Control) - керуючі, які регламентують і нормативні дані, якими керується робота. Управління відповідає на питання «Відповідно до чого виконується робота?». Управління впливає на роботу, але не перетворюється їй, тобто виступає в якості обмеження. Як управління можуть бути правила, стандарти, нормативи, розцінки, усні вказівки. Стрілки управління малюються входять у верхню грань роботи. Якщо при побудові діаграми виникає питання, як правильно намалювати стрілку зверху або зліва, то рекомендується її малювати як вхід (стрілка зліва);

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

    - механізм (Англ. Mechanism) - ресурси, які виконують роботу. Механізм відповідає на питання «Хто виконує роботу або за допомогою чого?». Як механізм можуть бути персонал підприємства, студент, верстат, обладнання, програма. Стрілки механізму малюються входять в нижню межу роботи;

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

    6.4. Типи зв'язків між роботами

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

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

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

    Мал. 6.2. ієрархічна зв'язок

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

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

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

    Мал. 6.7. споживча зв'язок

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

    Мал. 6.8. логічний зв'язок

    6. Колегіальна (методична) зв'язок має місце між функціями, алгоритм роботи яких визначається одним і тим же управлінням. Аналогом такого зв'язку є спільна робота співробітників одного відділу (колег), що підкоряються начальнику, який віддає вказівки і накази (керуючі сигнали). Такий зв'язок також виникає, коли алгоритми роботи цих функцій визначаються одним і тим же методичним забезпеченням (СНИП, ГОСТ, офіційними нормативними матеріалами і т. Д.), Службовцям в якості управління.

    Мал. 6.9. методична зв'язок

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

    Мал. 6.10. ресурсна зв'язок

    8. інформаційна зв'язок має місце між функціями, які використовують в якості вхідних даних одну і ту ж інформацію.

    Мал. 6.11. інформаційна зв'язок

    9. тимчасова зв'язок виникає між функціями, які повинні виконуватися одночасно до або одночасно після іншої функції.

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

    Мал. 6.12. тимчасова зв'язок

    10. Випадкова зв'язок виникає, коли конкретна зв'язок між функціями мала або повністю відсутній.

    Мал. 6.13. Випадкова зв'язок

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

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

    В IDEF0 існують угоди (правила і рекомендації) по створенню діаграм, які покликані полегшити читання і експертизу моделі [,]. Деякі з цих правил CASE-засоби підтримують автоматично, виконання інших слід забезпечити вручну.

    1. Перед побудовою моделі необхідно визначитися, яка модель (моделі) системи буде побудована. Це має на увазі визначення її типу AS-IS, TO-BE або SHOULD-BE, а також визначення позиції, з точки зору якої будується модель. «Точку зору» найкраще уявляти собі як місце (позицію) людини або об'єкта, в яке треба встати, щоб побачити систему в дії. Наприклад, при побудові моделі роботи продуктового магазину можна серед можливих претендентів, з точки зору яких розглядається система, вибрати продавця, касира, бухгалтера або директора. Зазвичай вибирається одна точка зору, найбільш повно охоплює всі нюанси роботи системи, і при необхідності для деяких діаграм декомпозиції будуються діаграми FEO, що відображають альтернативну точку зору.

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

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

    4. Блоки на діаграмі декомпозиції слід розташовувати зліва направо і зверху вниз. Таке розташування дозволяє більш чітко відобразити логіку і послідовність виконання робіт. Крім цього маршрути стрілок будуть менш заплутаними і мати мінімальну кількість перетинань.

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

    Мал. 6.14. Функція без управління і входу

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

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

    6. У кожного блоку повинен бути як мінімум один вихід.

    Мал. 6.15. Функція без виходу

    Роботи без результату не мають сенсу і не повинні моделюватися. Виняток становлять роботи, які відображаються в моделі AS-IS. Їх наявність свідчить про неефективність і недосконалість технологічних процесів. У моделі TO-BE ці роботи мають бути відсутні.

    7. При побудові діаграм слід мінімізувати кількість перетинів, петель і поворотів стрілок.

    8. Зворотні зв'язку та ітерації (циклічні дії) можуть бути зображені за допомогою зворотних дуг. Зворотні зв'язку по входу малюються «нижній» петлею, зворотний зв'язок з управління - «верхній» (див. Рис. 6.4 і 6.6).

    9. Кожен блок і кожна стрілка на діаграмах повинні обов'язково мати ім'я. Допускається використовувати розгалуження (декомпозицію) або злиття (композицію) стрілок. Це пов'язано з тим, що одні й ті ж дані або об'єкти, породжені однією роботою, можуть використовуватися відразу в декількох інших роботах. І навпаки, однакові або однорідні дані і об'єкти, породжені різними роботами, можуть використовуватися в одному місці.

    Мал. 6.16. розгалуження стрілок

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

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

    На діаграмі не допускається малювати стрілки, коли до і після розгалуження вони не іменовані. На рис. 6.17 стрілка, що входить в блок «Формування типових відомостей», не має імені до і після розгалуження, що є помилкою.

    Мал. 6.17. Неправильне іменування стрілок

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

    Мал. 6.18. туннелирование стрілок

    В даному прикладіпри побудові моделі проведення новорічного ранкумеханізм «дві сокири» не буде доступний широкому на діаграмах верхніх рівнів, при читанні яких може виникнути справедливе запитання: «А навіщо потрібні дві сокири на новорічному ранку?».

    Аналогічним чином можна виконувати туннелирование зі зворотним метою - недопущення відображення стрілки на діаграмах нижчих рівнів. В цьому випадку круглі дужки ставляться на кінці стрілки. На контекстної діаграмі (див. Рис. 6.21) затуннелірован механізм «Інженер служби колії», що входить в блок «Визначення допустимих швидкостей». Таке рішення прийнято, так як інженер безпосередньо бере участь у всіх роботах, відображених на діаграмі декомпозиції цього блоку (див. Рис. 6.22). Щоб не показувати цей зв'язок і не захаращувати діаграму декомпозиції, стрілка була затуннелірована.

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

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

    Мал. 6.19. об'єднання зв'язків

    13. Кожен блок на діаграмах повинен мати свій номер. Для того щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Блок на діаграмі верхнього рівня позначається 0, блоки на діаграмах другого рівня - цифрами від 1 до 9 (1, 2, ..., 9), блоки на третьому рівні - двома цифрами, перша з яких вказує на номер деталізіруемая блоку з батьківської діаграми, а друга номер блоку по порядку на поточній діаграмі (11, 12, 25, 63) і т. д. Контекстна діаграма має позначення «А0», діаграма декомпозиції першого рівня - «А0», діаграми декомпозиції наступних рівнів - складаються з букви « А », за якою слідує номер декомпозіруемого блоку (наприклад,« А11 »,« А12 »,« А25 »,« А63 »). На малюнку показано типове дерево діаграм (діаграма дерева вузлів) з нумерацією.

    Мал. 6.20. ієрархія діаграм

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

    6.6. Приклад побудови моделі IDEF0 для системи визначення допустимих швидкостей

    Розрахунок допустимих швидкостей руху поїздів є трудомісткою інженерним завданням. При проході поїздом якої-небудь ділянки фактична швидкістьруху поїзда не повинна перевищувати гранично допустиму. Ця гранично допустиме швидкість встановлюється виходячи з досвіду експлуатації і спеціально проведених випробувань по динаміці руху та впливу на колію рухомого складу. Неперевищення цієї швидкості гарантує безпеку руху поїздів, комфортабельні умови їзди пасажирів і т. П. Вони визначаються в залежності від типу рухомого складу (марки локомотива і типу вагонів), параметрів верхньої будови колії (типу рейок, баласту, епюри шпал) і плану (радіуса кривих, перехідних кривих, підвищення зовнішньої рейки і т. д.). Як правило, для встановлення допустимих швидкостей необхідно визначити не менше двох (на прямих) і п'яти (в кривих) швидкостей, з яких і вибирається остаточна допускається швидкість, як найменша з усіх розрахованих. Розрахунок цих швидкостей регламентуються Наказом МПС Росії № 41 від 12 листопада 2001 г. «Норми допустимих швидкостей руху рухомого складу по залізничних коліях колії 1520 (1524) мм Федерального залізничного транспорту».

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

    Контекстна діаграма для завдання визначення допустимих швидкостей показана на ріс.6.21. Для побудови моделі використовувався продукт BPwin 4.0 фірми Computer Associates.


    Мал. 6.21. Контекстна діаграма системи визначення допустимих швидкостей (методологія IDEF0)

    В якості вихідної інформації, На основі якої виконується визначення допустимих швидкостей, використовуються:

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

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

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

    Дані про результати зйомки плану шляху вагоном-шляховимірювачем;

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

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

    керуючими данимиє:

    Вказівка ​​начальника служби колії дороги або Департаменту колії та споруд ВАТ «РЖД» на розрахунок;

    Наказ № 41, що містить нормативно-довідкову інформацію, порядок і формули визначення допустимих швидкостей;

    Відомості про поточний або планованому поездопотоков (дані про марках звертаються локомотивів і типах використовуваних вагонів);

    Відомості про плановані ремонтах шляху, реконструкції та перебудові споруд і пристроїв.

    результатомроботи системи повинні бути:

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

    Відомості Наказу начальника дороги про встановлення допустимих швидкостей на перегонах і роздільних пунктах (Наказ «Н») згідно з прийнятою на дорозі формі. Затверджений Наказ «Н» офіційно закріплює допустимі швидкості руху поїздів;

    Типові форми № 1, 1а та 2, що містять плановані допустимі швидкості для розробки графіка руху поїздів.

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

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

    Діаграма декомпозиції першого рівня для даної задачі приведена на ріс.6.22. Як правило, при побудові діаграми декомпозиції початкова функція (декомпозіруемая) розбивається на 3-8 підфункцій (блоків). При цьому блоки на діаграмі декомпозиції рекомендується розташовувати зліва направо зверху вниз, щоб краще було видно послідовність і логіка взаємодії подфункций.


    Мал. 6.22. Діаграма декомпозиції першого рівня (методологія IDEF0)

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

    Введення і коректування нормативно-довідкової інформації і даних по ділянках дороги (блоки 1 і 2);

    Підготовка завдання на розрахунок (блок 3). У ньому вказується, для якої ділянки і шляхи, а також марки локомотива і типу вагонів слід виконати розрахунок;

    Розрахунок допустимих швидкостей відповідно до порядку і формулами, зазначеними в Наказі № 41 (блок 4). В якості вихідної інформації виступають дані по шляху ділянки (план, верхня будова колії і т. Д.) І нормативи, які обираються на підставі завдання на розрахунок;

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

    Формування та підготовка проекту Наказу «Н» і типових відомостей (блоки 6 і 7).

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

    6.7. ICOM-коди

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

    ICOM-коди (Абревіатура від Input, Control, Output і Mechanism) призначені для ідентифікації граничних стрілок. ICOM-код містить префікс, який відповідає типу стрілки (I, С, О або М), і порядковий номер (див. Рис.).

    Опис Діаграм бізнес процесу «Облік комп'ютерної техніки підприємства»

    Опис IDEF0 діаграми

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

    1. Контекстна

    2. Функціональна декомпозиція

    Малюнок 1 - Контекстна діаграма «Облік комп'ютерної техніки підприємства»

    На малюнку 1 представлена ​​контекстна діаграма бізнес процесу «Облік комп'ютерної техніки підприємства». Вона відображає систему в цілому і її взаємодія з основними зовнішніми потоками інформації.

    На контекстної діаграмі позначені стрілки.

    Види стрілок:

    · Вхід (вхідні матеріали: комп'ютери та комплектуючі)

    · Вихід (виходом є звіт)

    · Стрілками управління є документи і керівники

    · Стрілками механізмів є співробітники і обладнання

    Вхідна інформація для обробки:

    Комп'ютери - ПК (персональні комп'ютери) знаходяться на підприємстві

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

    Вихідні потоки:

    Звіт - готовий звіт з обліку комп'ютерної техніки підприємства

    Вхідні управління:

    Правила - умови, які необхідно дотримати, що б досягти поставленої мети.

    Накази - поставлена ​​задача підприємству (провести облік комп'ютерної техніки на підприємстві за допомогою тих чи інших інформаційних систем)

    Керівники - директора і головні керуючі підприємством.

    Вхідні ресурси:

    ПК - комп'ютери, за допомогою яких ведеться облік.

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

    На малюнку 2 представлена ​​функціональна декомпозиція, що складається з чотирьох робіт.


    Малюнок 2 - Функціональна декомпозиція «Облік комп'ютерної техніки підприємства»

    Були виділені наступні види робіт:

    1) Оформлення поставок - процес, в якому відбувається привласнення id товару, відправка на зберігання, на склад і занесення інформації про товар в програму.

    У роботу Оформлення поставок входить сім граничних стрілок (вхід, управління, механізм) і виходить внутрішня стрілка (зв'язок по входу).

    Стрілка зв'язок по входу між роботами Оформлення поставок і обслуговування комп'ютера (комп'ютер);

    Стрілки входу, виходу, управління повторюються в наступних роботах.

    2) Обслуговування комп'ютера - процес, в якому відбувається збірка, ремонт і модернізація комп'ютерів.

    У роботу Обслуговування комп'ютера входить чотири граничних стрілки (вхід, управління, механізм, вихід) і кілька внутрішніх стрілок (зв'язок по входу, зворотний зв'язок по входу).

    Стрілка управління - правила, накази, керівник;

    Стрілка зв'язок по входу між роботами Обслуговування комп'ютера і Розстановка (занесення даних в базу), між роботами Обслуговування комп'ютера і Складання звіту (занесення даних в базу);

    3) Розстановка - процес, в якому відбувається розстановка комп'ютерів по офісах (кабінетах).

    Стрілки управління - правила, накази, керівник;

    Стрілка механізму - співробітники;

    Стрілка зв'язок по входу між Розстановка і Складання звіту (привласнення id);

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

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


    На малюнку 3 представлена ​​діаграма, що показує роботу Оформлення поставок більш докладно.

    В результаті деталізації були виділені основні функції. В розділ «Оформлення поставок» входить сім головних стрілок (вхід, вихід, управління, механізм).

    Стрілка входу - комп'ютери та комплектуючі;

    Стрілками управління є правила, накази та керівник. Стрілки розгалужується;

    Стрілки механізму, розгалужується - ПК, співробітники;

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

    1) Присвоєння номера - привласнення індивідуального номера комп'ютерів та комплектуючих.

    Стрілки входу - комп'ютери та комплектуючі. Стрілка комп'ютери повторюється в наступних роботах, крім складання звіту;

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - ПК та Співробітники;

    Стрілка зв'язок по входу між роботами Присвоєння номера і Відправка товару на склад (переміщення), між «Присвоєння номера» і «Постановка на баланс» (внесення в базу);

    2) Відправлення товару на склад - оправлення товару з присвоєним номером на склад.

    Стрілка виходу - комп'ютер;

    Стрілки управління - правила, накази та керівник.

    Стрілка зв'язок по входу між роботами «Відправлення товару на склад» і «Постановка на баланс» (кількість);

    3) Постановка на баланс - занесення інформації в комп'ютер.

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - ПК та Співробітники;


    На малюнку 4 представлена ​​діаграма, що деталізує обслуговування комп'ютера більш докладно.

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

    У роботу Обслуговування комп'ютера входить 4 граничні стрілки (вхід, вихід, управління, механізм). Внутрішні стрілки (зворотний зв'язок по входу, зв'язок по входу).

    1) зі складання комп'ютерів - конфігурація комп'ютерів за індивідуальним замовленням керівників.

    Стрілка входу - комп'ютери;

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - Співробітники;

    Стрілка зв'язок по входу між роботами: «Збірка комп'ютерів» і «Ремонт комп'ютерів» (комп'ютер);

    2) Ремонт комп'ютерів - збірка затверджених до поліпшення комп'ютерів.

    Стрілка входу - комп'ютери;

    Стрілка виходу - занесення в базу;

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - Співробітники;

    Стрілки входу, виходу, управління, механізму є розгалужуються;

    Стрілка зв'язок по входу між роботами: «Ремонт комп'ютерів» і «Upgrade» (комплектуючі);

    3) Upgrade - удосконалення, поліпшення, оновлення комп'ютера.

    Стрілка виходу - занесення в базу;

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - Співробітники;

    Стрілки управління, механізму є розгалужуються;


    На малюнку 5 представлена ​​діаграма «Складання звіту» більш докладно. У декомпозицію роботи Складання звіту входить 4 граничних стрілки (вхід, вихід, управління, механізми). Внутрішні стрілки (зворотний зв'язок по входу, зв'язок по входу).

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

    1) Збір даних - збір інформації для аналізу і прийняття рішень.

    Стрілка входу - привласнення id;

    Стрілки управління - правила, накази і керівник;

    Стрілки входу, управління, механізму є розгалужуються;

    Стрілка зв'язок по входу між роботами: Збір даних і Перевірка даних (записи);

    2) Перевірка даних - перевірка інформації і відправка її на складання звіту.

    Стрілка входу - привласнення id, занесення даних в базу;

    Стрілка виходу - Звіт;

    Стрілки управління - правила, накази і керівник;

    Стрілки механізму - Співробітники, ПК;

    Стрілки входу (привласнення id), управління, механізму є розгалужуються;

    Стрілкою зворотного зв'язку по входу з «Перевірки даних» на «Збір даних» (повторна перевірка).

    Опис DFD діаграми

    У декомпозиції роботи «Обслуговування комп'ютера» Малюнок 1 визначено чотири внутрішні роботи, дві зовнішні сутності і два сховища даних.


    Малюнок 1 - Обслуговування комп'ютера

    1) Складання комп'ютера - процес складання комп'ютера з існуючих комплектуючих.

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

    3) Діагностика - перевірка на працездатність

    4) Upgrade - удосконалення, поліпшення, оновлення комп'ютера.

    Зовнішні сутності: комп'ютери та комплектуючі

    Сховища даних:

    1) Склад - місце, де зберігаються зібрані і модернізовані комп'ютери.

    2) БД - база даних, в якій зберігаються всі звіти і вся інформація про виконані роботи.

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

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

    У декомпозиції роботи «Складання звіту» Малюнок 2 визначено три внутрішні роботи, три зовнішні сутності і два сховища даних.

    1) Збір даних - збір відомостей про комп'ютери та комплектуючих.

    2) Перевірка - перевірка даних на точність.

    3) Звіт - написання звіту про виконану роботу.

    Зовнішні сутності: комплектуючі, комп'ютери, керівник.

    Сховище даних - Дані про комп'ютери та комплектуючих, дані звіту.


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

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

    Опис IDEF3 діаграми

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


    1) Ремонт - збірка комп'ютера збірними комплектуючими

    2) Збірка - приведення комп'ютера в нормальний вигляд

    3) Upgrade - модернізація комп'ютера

    4) Комп'ютери - товар після складання і модернізації

    5) Надіслати на склад - відправити на зберігання після поліпшення (збірки)

    6) Діагностика - перевірка на працездатність.

    7) Звіт - інформація про виконану роботу.

    Перехрестя - з'єднувачі:

    1) J2 - всі дії починаються одночасно.

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

    3) J7 - показано, що ці умови одночасно виконуватися не можуть.

    4) J9 - ці дії закінчуються одночасно після чого складається звіт по виконаній роботі.

    На діаграмі IDEF3 показано, що перехрестя J2 має дві розгалужується стрілки на роботи (зборка і upgrade), які починають виконуватися одночасно. Тільки після виконання цих робіт виходить готовий продукт (комп'ютер), з'єднує перехрестя J6. Після чого йде з'єднання перехрестям J7, який показує що дві роботи (відправка товару на склад і діагностика) одночасно виконуватися не можуть. Після виконання попередніх робіт йде процес складання звіту по проведеній роботі, який з'єднаний перехрестям J9.

    Схожі публікації