Визначення властивостей моделі IDEF0

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

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

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

Далі задаються властивості моделі (діалог ModelProperties). Діалог містить наступні вкладки: Layout, ABCUnits, PageSetup, Header/Footer, Shapes, Drawstyle, General, Purpose, Definition, Source, Status, Numbering, Display. Вкладка Generalпризначена для завдання прізвища та ініціалів автора. Вкладка Purpose призначена для завдання меті моделювання (Purpose) і точки зору (Viewpoint).

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

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

Мета моделювання визначається з відповідей на наступні запитання:

· Чому цей процес необхідно промоделювати?

· Що повинна показувати модель?

· Що може отримати клієнт?

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

IDEF0-модель припускає наявність чітко сформульованої мети, єдиного суб'єкта моделювання і однієї точки зору. Для внесення області, мети і точки зору в моделі IDEF0 в Bpwin необхідно вибрати пункт меню Model/ModelProperties, що викликає діалог ModelProperties (рис. 4.3). У закладці Purpose слід внести мету і точку зору, а в закладку Definition - визначення моделі і опис області.

У закладці Status цього ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний тощо), час створення і останнього редагування (надалі відстежується автоматично за системною датою). У закладці Source описуються джерела інформації для побудови моделі (наприклад, "Досвід експертів предметної області і аналіз документації"). Закладка General служить для внесення назви проекту і моделі, імені автора і тимчасових рамок моделі - AS-IS і ТО-ВЕ.

Моделі AS-IS і ТО-ВЕ.

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

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

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

Результат опису моделі можна отримати в звіті ModelReport. Діалог налаштуваня звіту по моделі викликається з пункту меню Tools/Reports/ModelReport.

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

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

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

У таблиці 1 наведені основні «бідівельні блоки» для діаграм IDEF0.

Таблиця 2.1.

№	Назва	Опис елемента IDEF0 діаграми	Графічне представлення
1	Модуль поведінки (UOB)	Об’єкт служить для опису функцій (процесів, процедур, робіт), які виконуються підрозділами/співробітниками підприємства.
2	Стрілка зліва	Стрілка описує вхідні документи, інформацію, матеріальні ресурси, необхідні для виконання функції.
3	Стрілка справа	Стрілка описує вихідні документи, інформацію, матеріальні ресурси, які є результатом виконання функції.
4	Стрілка зверху	Стрілка описує керуючі впливи, наприклад, розпорядження, нормативний документ тощо. У нотації IDEF0 кожні процедура повинна обов’язково мати не менше однієї стрілки зверху, яка відображає керуючий вплив.
5	Стрілка знизу	Стрілка знизу описує т.з. механізми, тобто ресурси, необхіднідля виконання процедури, але не змінює в процесі її виконання свій стан. Приклади: співробітник, верстат тощо.
6	Стрілка вниз	Стрілка вниз відображає зв’язок між різними діаграмами або моделями, вказуючи на деяку діаграму, де дана робота розглянута детальніше.

Індивідуальне завдання

За допомогою BPWin розробити модель в стандарті IDEF0 на тему «Прокат автомобілів».

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

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

1. Вибір авто

2. Реєстрація клієнта

3. Угода/письмовий договір

4. Прокат/попередній огляд

5. Повернення/огляд/оплата (у разі чого – накладання штрафу)

Результати

Висновок

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