Визначення стрілок на контекстній діаграмі

Вибір найменування контекстного блоку

Межі моделювання

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

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

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

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

Рекомендованою послідовністю дій при побудові моделі "з нуля" є:

· формулювання мети моделювання,

· вибір точки зору,

· визначення меж моделювання.

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

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

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

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

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

Визначення механізмів виконання.Після створення входів і виходів можна приступити до розгляду механізмів виконання, або ресурсів, що відносяться до функціонального блоку. У поняття механізму виконання входять персонал, устаткування, інформаційні системи і т.п. Наприклад, функціональний блок "Зібрати деталь" може зажадати використання якого-небудь устаткування, наприклад, гайкового ключа. При прийомі іспитів на водійські права механізмом виконання є інспектор ДАІ. Як правило визначити механізми виконання для функціональних блоків досить просто.

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

• Чи узагальнює діаграма модельований бізнес-процес?

• Чи узгоджується діаграма з межами моделювання, точкою зору і метою моделювання?

• Чи підходить вибраний рівень деталізації стрілок для контекстного блоку? (Звичайно на контекстній діаграмі рекомендується рисувати не більше шести стрілок кожного типа.)

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Розгалуження і сполучення моделей	\|	Зв'язок між діаграмою і її батьківським функціональним блоком

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.003 сек.