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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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