28523

Технології моделювання бізнес-процесів. Мова UML

Лекция

Информатика, кибернетика и программирование

Мова UML 1. Для побудови зазначених типів моделей використовуються як власні методи моделювання ARIS так і різні відомі методи та мови моделювання зокрема UML. Автори методу EricssonPenker створили свій профіль UML для моделювання бізнеспроцесів EricssonPenker Business Extensions ввівши набір стереотипів які описують основні категорії бізнесмоделі: процеси ресурси правила і цілі діяльності підприємства. Мова UML використовується також в методі який є частиною технології Rational Unified Process фірми IBM.

Украинкский

2013-08-20

336.5 KB

13 чел.

Лекція 8

Технології моделювання бізнес-процесів. Мова UML

 

1. Методи моделювання бізнес-процесів

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

o метод функціонального моделювання SADT (IDEF0);

o метод моделювання процесів IDEF3;

o моделювання потоків даних DFD;

o метод ARIS;

o метод Ericsson-Penker;

o метод технології Rational Unified Process.

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

Бізнес-модель відповідає таким вимогам:

o верхній рівень моделі відображає виключно контекст системи - взаємодію підприємства із зовнішнім середовищем;

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

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

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

Метод використовується для моделювання штучних систем середньої складності.

Метод моделювання IDEF3 - частина сімейства стандартів IDEF; використовується для моделювання послідовності виконання дій і їх взаємозалежностей в рамках процесу. Метод отримав визнання серед системних аналітиків як доповнення до методу функціонального моделювання IDEF0.

Основою моделі IDEF3 служить сценарій процесу, який відокремлює послідовність дій і підпроцесів системи. Як і в методі IDEF0, основною одиницею моделі є діаграма. Іншим важливим компонентом є дія або "одиниця роботи" (Unit of Work), взаємодія яких зображається за допомогою зв'язків.

Діаграми потоків даних (Data Flow Diagrams - DFD) представляють собою ієрархію функціональних процесів, що пов'язані потоками даних. Мета такого представлення полягає у демонстрації того, як кожен процес перетворює свої вхідні дані у вихідні і виявлення зв'язків між цими процесами.

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

o зовнішні об'єкти;

o системи та підсистеми;

o процеси;

o накопичувачі даних;

o потоки даних.

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

Метод ARIS (Architecture of Integrated Information System), представляє собою комплекс засобів аналізу і моделювання діяльності підприємства. Його методичну основу складає сукупність різноманітних методів моделювання, що відображають різні погляди на системи. ARIS підтримує чотири типи моделей, які віддзеркалюють різні аспекти системи, що досліджується:

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

o функціональні, які містять ієрархію цілей;

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

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

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

Автори методу Ericsson-Penker створили свій профіль UML для моделювання бізнес-процесів - Ericsson-Penker Business Extensions, ввівши набір стереотипів, які описують основні категорії бізнес-моделі: процеси, ресурси, правила і цілі діяльності підприємства.

Мова UML використовується також в методі, який є частиною технології Rational Unified Process (фірми IBM). Цей метод спрямовано насамперед на створення основи для формування вимог до ПЗ.

Передбачає побудову двох базових моделей:

o моделі бізнес-процесів (Business Use Case Model);

o моделі бізнес-аналізу (Business Analysis Model).

Модель бізнес-процесів представляє собою розширення моделі варіантів використання (Use Case) UML шляхом введення набору стереотипів - Business Actor (стереотип діючої особи) та Business Use Case (стереотип варіанту використання). Діючими особами можуть бути акціонери, замовники, постачальники, партнери, потенційні клієнти, місцеві органи влади, зовнішні системи, співробітники тих підрозділів організації, діяльність яких не враховується у моделі, тощо.

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

2. Етапи розвитку UML

Уніфікована мова моделювання (UML - Unified Modeling Language) з'явилась внаслідок розвитку методів об'єктно-орієнтованого аналізу і проектування (OOA&D), що виникли наприкінці 80-х років. Мова UML поєднує в собі методи Граді Буча (Booch чи Booch'91), Джима Рамбо (Object Modeling Technique - OMT) і Айвара Джекобсона (Object-Oriented Software Engineering - OOSE), проте володіє розширеними можливостями. Мова моделювання пройшла процес стандартизації в рамках консорціуму OMG (Object Management Group) і на сьогоднішній день представляє собою фактичний стандарт OMG.

UML - це назва мови моделювання, але не методу, оскільки більшість методів містять щонайменше мову моделювання та процес. Мова моделювання - це нотація (як правило, графічна), яка використовується методами для опису проектів; процес - це рекомендація щодо етапів, які необхідно виконати при розробці проекту. Таким чином, мова моделювання є найважливішою частиною методу. Якщо проект обговорюється розробниками, всі вони повинні розуміти саме мову моделювання, а не процес, що використовується при розробці проекту. Розробниками мови UML було також створено і RUP (Rational Unified Process) - раціональний уніфікований процес. Причому, при застосуванні мови UML не висувається вимога одночасного використання RUP, оскільки вони є абсолютно незалежними. Процес RUP може використовуватись для розробки проекту в залежності від типу останнього та вимог замовника.

Розглянемо етапи розвитку галузі розробок програмного забезпечення для ілюстрації процесу становлення мови UML. Поняття об'єкту набуло практичного значення у проектуванні в 70-х - 80-х роках і стало основою методів об'єктно-орієнтованих розробок. В період з 1988 по 1992 роки з'явились наступні праці, присвячені методам об'єктно-орієнтованого аналізу і проектування:

o роботи Саллі Шлеєр (Sally Shlaer) та Стіва Меллора (Steve Mellor), що пізніше були втілені у рекурсивному проектуванні (Recursive Design);

o Пітер Коуд (Peter Coad) та Ед Йордон (Ed Yourdon) розробили неформальний та орієнтований на прототипи метод Коуда;

o Граді Буч (Grady Booch) з компанії Rational Software написав фундаментальну роботу по розробці систем на мові Ada;

 o Джим Рамбо (James Rumbaugh) очолив групу у дослідній лабораторії General Electric і розробив популярний метод Object Modeling Technique - OMT;

o Айвар Джекобсон (Ivar Jacobson) виклав свій досвід роботи з телефонними системами фірми Ericsson і вперше ввів поняття варіанту використання (Use Case).

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

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

Проте, у відповідь на пропозицію звести всі методи до єдиного стандарту, компанія OMG отримала відкритий лист із протестом від всіх авторів основних методологій. Тоді Джим Рамбо залишив General Electric і приєднався до Буча в Rational Software з наміром об'єднати їх методи та досягти стандартизації за прикладом компанії Microsoft. Всі, хто не погодився з таким рішенням, сформували анти-Бучівську коаліцію. На конференції OOPSLA'95 Буч та Рамбо представили перший опис об'єднаного методу у формі документації під робочою назвою "Unified Method 0.8". В цей самий час фірма Rational Software здійснила придбання компанії Objectory і до розробників уніфікованого методу приєднався Джекобсон. Розробка нового методу - вже під назвою UML - тривала до 1997 року, причому з відкритим несхваленням зі сторони голови OMG.

Тоді ж деякі компанії та організації побачили в мові UML стратегічний інтерес для свого бізнесу. Компанія Rational Software разом з декількома організаціями, що виявили бажання виділити ресурси для розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у який спочатку ввійшли такі фірми, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI і Unisys. Ці компанії забезпечили підтримку подальшої роботи з більш точного визначення нотації.

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

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

Наринку CASE-засобів представлені десятки програмних інструментів, що підтримують нотацію мови UML і забезпечують інтеграцію, включаючи пряму і зворотну генерацію коду програм, з найбільш розповсюдженими мовами і середовищами програмування, такими як MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.

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

3. Поняття діаграми, нотації та метамоделі

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

Діаграма (diagram) - графічне представлення сукупності елементів моделі у формі зв'язного графа, вершинам і ребрам (дугам) якого приписується визначена семантика

Нотація канонічних діаграм є основним засобом розробки моделей мовою UML.

Нотація - множина символів і правила їх застосування, що використовуються для представлення понять і зв'язків між ними

У нотації мови UML визначені наступні види канонічних діаграм:

o варіантів використання (use case diagram);

o класів (class diagram);

o кооперації (collaboration diagram);

o послідовності (sequence diagram);

o станів (statechart diagram);

o діяльності (activity diagram);

o компонентів (component diagram);

o розгортки (deployment diagram);

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

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

Рис.1. Діаграми UML як складові бізнес-моделі

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

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

Рис.2. Асоціація у визначенні нотації діаграми класів

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

Рис.3. Кратність у визначенні нотації діаграми класів

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

Рис.4. Навігація у визначенні нотації UML

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

Рис.5. Поняття залежності у визначенні нотації діаграми класів

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

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

4. Задачі аналізу і проектування

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

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

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

1. одним з найкращих способів вивчення об'єктно-орієнтованих методів є CRC-картки. Вони не входять до засобів UML, проте можуть використовуватись разом із універсальною мовою моделювання. CRC-картки були створені, головним чином, для навчання роботі з об'єктами (рис.6).

Рис.6. Структура CRC-картки

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

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

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

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

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

Найпоширенішим методом, що застосовується для досягнення цієї мети, є варіанти використання (Use Cases). Варіант використання представляє собою деякий моментальний відбиток одного з аспектів системи, що моделюється, наприклад про здійснення клієнтом операції замовлення товару (рис.7).

Рис.7. Приклад діаграми використання

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

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

Рис.8. Приклад діаграми класів

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

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

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

5. Етапи процесу розробки бізнес-моделі

Корпорація Rational Software в 1999 році випустила на ринок структуровану базу знань під назвою Rational Unified Process (RUP), яка є набором вичерпних рекомендацій для створення практично будь-яких моделей та програмних продуктів. Увібравши в себе досвід кращих розробок, RUP детально описує коли, хто і що повинен робити в проекті, щоб в результаті одержати змодельовану систему за встановлені терміни, з певною функціональністю і в рамках відведеного бюджету.

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

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

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

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

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

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

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

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

Рис.9. Схема процесу розробки

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

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

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

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

o ризики, що пов'язані із вимогами;

o технологічні ризики;

o ризики, які пов'язані із кваліфікацією персоналу.

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

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

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

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

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

Резюме

Для моделювання бізнес-процесів використовується декілька різних методів, в основі яких лежить як структурний, так і об'єктно-орієнтований підходи до моделювання: SADT (IDEF0); IDEF3; DFD; ARIS; Ericsson-Penker; Rational Unified Process, причому останні три методи використовують UML.

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

Ключові слова

Бізнес-процес, моделювання, модель, варіанти використання (Use Case), діаграма, канонічна діаграма, UML, нотація, клас, асоціація, кратність, об'єктно-орієнтований метод, процес розробки бізнес-моделі, ризики.

Запитання і завдання для обговорення та самоперевірки:

► Назвіть поширені методи моделювання бізнес-процесів.

► Опишіть характеристики бізнес-моделі, побудованої за методом SADT.

► Назвіть основну задачу моделювання потоків даних.

► Наведіть типи бізнес-моделей, що підтримує метод ARIS.

► Визначте призначення універсальної мови моделювання UML.

► Дайте означення діаграми як засобу UML. Які діаграми входять до складу інтегрованої моделі складної системи?

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

► Які є переваги об'єктно-орієнтованих методів моделювання? Опишіть етапи розробки бізнес-моделі.

► Охарактеризуйте поняття ризику.

PAGE  11


 

А также другие работы, которые могут Вас заинтересовать

31145. Состав и содержание работ на предпроектной стадии канонического проектирование ИС 127.82 KB
  Стадия формирования требований к автоматизированной системе главное на этой стадии – провести предпроектное обследование и дать техникоэкономическое обоснование целесообразности создания системы. Этап предполагает тесное взаимодействие с основными пользователями системы и бизнесэкспертами. По завершении этой стадии появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию. Сбор материалов обследования – все методы проведения обследования можно объединить в группы по следующим...
31146. Состав и содержание работ на стадиях технико-рабочего проектирование, внедрение, эксплуатации и сопровождения канонического проектирования ИС 15.66 KB
  Технический проект разрабатывается на основе технического задания и эскизного проекта. Стадия Рабочий проект – ее главное назначение – кодирование или адаптация готовых программных средств составление рабочего проекта. Большую роль для эффективного использования разработанного проекта ИС играет качественная технологическая документация входящая в состав рабочего проекта. При наличии прототипа системы стадии технического проекта и рабочей документации объединяются в одну проектную стадию.
31147. Проектирование пользовательского интерфейса 16.37 KB
  Порядок проектирования меню предусматривает следующую последовательность работ: Проектирование содержания меню; Проектирование форм меню – экранная форма. Проектирование содержания меню требует изучения предметной области и обоснования состава задач образующих функциональную часть системы и их иерархической взаимосвязи. Выбор пункта меню может завершаться: Появление на экране меню нижнего уровня; Выполнение команды; Выполнение процедуры процедура ввода вывода информации; Появление заглушки В главном меню следует предусмотреть...
31148. Проектирование системы документации ИС 16.21 KB
  Унифицированная система документации УСД – рационально организованный комплекс взаимосвязанных документов который отвечает единым правилам и требованиям и содержит информацию необходимую для оптимального управления некоторым экономическим объектам. В процессе проектирования УСД можно выделить 3 этапа работ: построение новых форм документов определение состава результатных показателей – зависит от того какие формы документов проектируются. При этом в первую очередь проектируются формы результатных документов а потом первичных....
31149. Как образуется массовое сознание 21 KB
  Фазы формирования МС: 1Фаза появления МС переживание – реальное или мнимое событие явление кот отражается в сознании индивида и рассматривается им как значимое событие в его жизни; 2фаза действия эмоций –между эмоциями и действиями нет сознательной регуляции; 3фаза рационализации внести логику в прошедшие события объяснить необъяснимое сформировать правила поведения в данной ситуации; 4выражение потребность чека делиться впечатлениями потребность в общении.
31150. Какова структура массового сознания 20.5 KB
  Структура массового сознания три уровня перевернутый треугольник 1Ядро МС – Когнитивное бессознательное нижний выражается в эмоциях чувствах спонтанных действиях инстинктивном поведении. Здесь появляются стереотипы 3Уровень выражения массового сознания – верхний – общественное мнение обществ настроение.
31151. Что такое архетип 21 KB
  Механизм действий А: Архетипы широко используются в коммерческой деятти. Люди работающие в области СО рекламы и маркетинга знают чтобы сообщение произвело впечатление на ЦА нужно чтобы в этом сообщении имел место опред архетип. Потому что чек лучше воспринимает то сообщение в кот заложен наиболее близкий ему архетип.
31152. Каковы свойства архетипов 20 KB
  Свойства: 1 Универсальность А свойственны каждому чеку; 2 Культурная обусловленность А; 3 Устойчивость.
31153. Что такое стереотип 20 KB
  Стереотип- устойчивое представление о каких-л. объектах, свойствах той или иной соц. группы. (пример: свои – чужие. Чужие – любые другие, не входящие в твою группу)