Моделі розробки програмного забезпечення. Методологія rup – загальна модель. Конус операційних маршрутів програмного проекту.
3. RUP – Rational Unified Process розроблений у корпорації IBM, одною з дочірніх компаній, якою є Rational Software. Методологія RUP описує абстрактний загальний процес [4], на основі якого організація чи проектна команда має створити спеціалізований процес, орієнтований на її потреби.
RUP пропонує набір достатньо гнучких методів і підходів, з яких можна обрати ті, що більш за все підходять до к конкретного проекту [1].
Основні характеристики RUP:
Розробка вимог. Основою для розробки вимог у цьому процесі є так звані прецеденти використання (тобто сценарії взаємодії користувача з програмою). Повний набір прецедентів використання системи разом з логічними відношеннями між ними (прецеденти можуть включати та розширювати інші прецеденти) називається моделлю прецедентів використання, і має описати по можливості всі випадки роботи з додатком, які можуть виникнути в реальних умовах.
Ітеративність. Як вже зауважувалося вище, в основу RUP покладена ітеративна модель. Авторами рекомендується перед початком кожної ітерації виокремити ті прецеденти, які мають бути реалізовані у даний момент, але не надто збільшувати їх кількість, щоб ітерація не затягнулася.
Цикл проекту. Для зручності ітерації розділяють на так звані фази. RUP передбачає проходження чотирьох фаз: початок (необхідно визначити уявлення і границі проекту, створити економічне обґрунтування, ідентифікувати переважну частину прецедентів використання та детально описати кілька ключових прецедентів, знайти хоча б одне можливе архітектурне рішення, оцінити бюджет, графік та ризики проекту), проектування (фаза, на якій проходить детальний опис більшої частини прецедентів використання, зниження основних ризиків та уточнення бюджету й графіку проекту), побудова (розробка остаточного продукту, написання основної частини коду) і впровадження.
Рання ідентифікація та неперервне 1) усунення основних ризиків проекту, 2) забезпечення якості розробки.
Очікування змін вимог, проектних рішень і реалізація в процесі розробки.
Компонентна архітектура, яка реалізується і тестується на ранніх стадіях проекту.
Роботу над проектом у дружній команді, ключова роль в якій належить архітекторам.
Наприкінці кожної ітерації (в ідеалі тривалістю від 2 до 6 тижнів) проектна команда має досягнути запланованих на дану ітерацію цілей, створити й доопрацювати проектні артефакти й отримати проміжну, але функціональну версію кінцевого продукту. Ітеративна розробка дозволяє швидко реагувати на зміну вимог, виявляти та усувати ризики на ранніх стадіях проекту, а також ефективно контролювати якість створюваного продукту.
RUP має дозволяти встановлю-вати ступінь формалізації та ітеративності процесу розроби в залежності від особливостей проекту, який реалізується. Дана методологія позиціонується як універсальна, що підходить для більшості типів проектів – як каскадних, так і гнучких.
Але, як і все універсальне, RUP не забезпечує високої продук-тивності та зручності впровад-ження.
В той же час RUP враховує досвід великого числа розроб-ників і вміщує найбільш повний набір концепцій, які так чи інакше присутні в інших методиках
Вважається, що RUP – надто складний і формальний процес. Можливо і так, але в його загальній моделі описані етапи розробки проектів і в залежності від потреб конкретного розробника можливо виділити з нього необхідні (і необов‘язкові) для даного проекту взаємопов‘язані елементи
Конус операційних маршрутів:
Розглянемо глобально процес планування та управління складним проектом.
Контроль діяльності проекту в цілому – часто незмірно складна задача, яка потребує засобів автокорегування і спеціальних заходів
Послідовний розвиток проектів
Ітеративне нарощування можливостей системи
