Інформаційні технології та моделювання бізнес-процесів - Томашевський О. М. - 18.5. Етапи процесу розробки бізнес-моделі

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

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

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

схема процесу розробки

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

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

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

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

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

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

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

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

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

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

Поняття ризику та його вплив на розробку моделі. Після завершення початкового етапу затвердження проекту, у фазі дослідження (рис.18.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. Які діаграми входять до складу інтегрованої моделі складної системи?

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

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

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

Схожі статті




Інформаційні технології та моделювання бізнес-процесів - Томашевський О. М. - 18.5. Етапи процесу розробки бізнес-моделі

Предыдущая | Следующая