Використання RUP для невеликих проектів: розширення екстремального програмування, Комерція, Різне, статті

Анотація


Rational Unified Process (RUP) являє собою цілісну методологію організації процесів розробки програмного забезпечення, яка включає в себе кілька заздалегідь сформованих реферативних реалізацій. Процеси, що організовуються на основі RUP, варіюються від найбільш простих – призначених для невеликих проектів з коротким циклом розробки – до більш складних процесів, що покривають більш широкий спектр потреб великих, можливо навіть розподілених, груп розробників. RUP успішно застосовується в проектах будь-яких типів і обсягів. Дана стаття описує, як застосовувати спрощену версію RUP в невеликих проектах. Ми описуємо ефективні способи застосування прийомів екстремального програмування (XP – eXtreme Programming) в більш широкому контексті повного циклу проекту.


Введення


Коротка історія


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


Все починалося просто чудово. Перші 6 місяців я працював в основному поодинці – довгі, приємні годинник. Моя продуктивність була просто неймовірною, і я зробив одну з кращих робіт за всю свою кар’єру. Цикли розробки були короткими, і я зазвичай випускав кілька важливих нових частин системи кожні пару тижнів. Взаємодія з користувачами було простим і безпосереднім – ми всі були учасниками однієї згуртованої команди і не звертали уваги на формальності і документи. Також мало формальностей було і в проектуванні. Код був проектом, і проект був кодом. Все було чудово!


Все було чудово. Поки що … У міру зростання системи з’являлися нові роботи. Існуючий код потрібно було змінювати у відповідності з новими проблемами, і ми переглянули наші уявлення про те, що ж нам дійсно потрібно робити. Я найняв кілька людей для допомоги в розробці. Ми працювали як єдиний організм, часто попарно займаючись різними частинами проблеми. Це спрощувало взаємодія, і ми могли відкинути формальності.


Пройшов рік


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


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


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


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


Загальні положення


Ця стаття описує, як застосовувати процеси в проектах, подібних описаному вище. Ми сконцентруємо увагу на виборі “правильного рівня” процесів. Розуміння проблем, з якими стикається команда розробників, і бізнес оточення, в якому вона працює, дозволить нам вибрати правильний рівень формалізації процесів. Як тільки ми зрозуміємо ці проблеми, ми зможемо формалізувати процеси рівно настільки, щоб зменшити ризик. Не існує процесів, спрощених чи ні, однаково підходять для будь-яких випадків. У наступних розділах ми розглянемо ідею про те, що правильний рівень процесів є функцією ризику.


Ми подивимося, як вибирати правильний рівень процесів, використовуючи дві популярні методології: RUP (Rational Unified Process) фірми Rational і XP (eXtreme Programming – екстремальне програмування). Ми покажемо, як можна застосовувати RUP в невеликих проектах, і як це вирішує багато питань, не розглядаються в XP. Комбінація дає команді розробників методику, необхідну для усунення ризиків і досягнення своїх цілей з постачання програмного продукту.


RUP – це схема процесів, розроблена в Rational Software. Це ітеративна методологія, заснована на шести визнаних в галузі кращих технологіях (див. RUP appendix). Розвертаючись у часі, проект на основі RUP проходить через чотири фази:



Кожна фаза включає одну або декілька ітерацій. На кожній ітерації ви докладаєте різні зусилля для виконання кількох завдань (або послідовностей робіт), таких як визначення вимог, аналіз та проектування, тестування і так далі. Основною метою RUP є скорочення ризиків. Методологія RUP уточнювалася в ході тисяч проектів, виконаних тисячами клієнтів і партнерів компанії Rational.

Рис. 1. Типова послідовність ітерацій.


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


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


XP це спрощений, орієнтований на кодування процес, для невеликих проектів. Це інтелектуальне дітище Кента Бека і привернуло увагу програмної індустрії в результаті виконання проекту С3 в Chrysler Corporation десь в 1997 році. Також як і RUP, ця технологія заснована на ітераціях, які об’єднують деякі прийоми, такі як невеликі релізи, просте проектування, тестування і постійна інтеграція. XP пропонує кілька підходів, які ефективні для відповідних проектів та обставин, але містить неочевидні припущення, роботи та ролі.


RUP і XP виходять з різних філософських основ. RUP – це система процесних компонент, методів і технік, які ви можете застосувати в будь-якому конкретному програмному проекті. Передбачається, що користувач буде адаптувати RUP. З іншого боку XP – більш обмежений процес, що вимагає доповнень для того, щоб відповідати повного циклу розробки проекту. Ця різниця пояснює переваги в співтоваристві розробників програмного забезпечення. Розробники великих систем розглядають RUP як вирішення своїх проблем, у той час як спільнота розробників малих систем вирішення своїх проблем бачить в XP. Наш досвід показує, що більшість програмних проектів знаходиться десь посередині – в спробі досягти правильного рівня процесів для своєї ситуації. Жодна з кордонів спектра для них не є достатньою.


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


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


Початок проекту – Inception


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


Під час первинного обстеження ви формуєте бізнес прецеденти для розробки програмного забезпечення. Ключовим артефактом, виробленим в результаті первинного обстеження, є концепція системи (Vision). Цей опис системи на верхньому рівні. Воно пояснює всім, що собою являє система, а також може визначати, хто і для чого буде її використовувати, які можливості мають в ній присутні і які існують обмеження. Концепція системи може бути дуже короткою, можливо лише один – два параграфа. Часто в концепції сформульовані критично важливі можливості програми, які повинні бути надані замовнику.


У наступному прикладі показано дуже коротка концепція, створена для проекту з реінжинірингу зовнішнього Web-сайту компанії Rational.


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


RUP специфікує чотири важливі завдання, що вирішуються на етапі початкового обстеження:



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


Затверджені бізнес прецеденти


Зацікавлені особи отримують можливість погодитися, що з точки зору бізнесу, проект має сенс виконувати. І RUP і XP сходяться в тому, що краще якомога раніше виявити, що проект виконувати не стоїть, ніж витрачати цінні ресурси на безглуздий проект. XP, як це описано в Planning Extreme Programming, Досить гнучко ставиться до того, як проект починається і які ролі залучаються (в контексті існуючого бізнесу або системи це представляється очевидним), але в рамках своєї фази розгляду (Exploration) XP має справу з артефактами, еквівалентними одержуваних на фази початкового обстеження в RUP. Чи розглядаєте ви неформально питання предметної області в XP або формуєте артефакти бізнес прецедентів першокласного проекту в RUP, вам необхідно звернути на них увагу.


Список ризиків


Ви ведете список ризиків протягом всього проекту. Це може бути простий список ризиків з планованою стратегією їх скорочення. Ризикам присвоюються пріоритети. Всі учасники проекту можуть бачити, що представляють собою ризики, і як ви враховуєте їх в кожен конкретний момент. Кент Бек описує набір ризиків, які знижуються з допомогою XP і як забезпечується їх зниження, але не дає універсального підходу для боротьби з ризиками.


Попередній план проекту


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


План приймання проекту


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


План для початкової ітерації опрацювання проекту (Elaboration)


У проектах RUP ви детально плануєте кожну ітерацію в кінці попередньої ітерації. В кінці ітерації ви оцінюєте прогрес у відповідність до критеріїв, обраними на початковому етапі ітерації. XP пропонує деякі вдалі рішення для моніторингу та вимірювання успішності ітерації. Метрики досить прості і ви можете легко включити їх до плану ітерації і критерії оцінки.


Вихідна модель прецедентів


Незважаючи на удавану зайвим ускладненням і формалізмом, це досить просто. Набір прецедентів відповідає “історіям”, записуваних замовником в XP. Різниця полягає в тому, що модель прецедентів містить повний набір дій, ініційованих актором (кимось або чимось зовнішнім по відношенню до системи), які мають очевидну значимість. Прецедент може включати кілька історій XP. Для визначення функціональних кордонів проекту RUP рекомендує ідентифікувати прецеденти і акторів під час початкового обстеження. Концентрація уваги на повному, з точки зору користувача, наборі дій допомагає провести декомпозицію системи на частини, що мають самостійне значення. Це, в свою чергу, дає можливість спланувати реалізацію функціональності таким чином, щоб передавати користувачеві щось в кінці кожної ітерації (можливо за винятком тільки ітерацій початкового обстеження та опрацювання проекту).


Як RUP, так і XP, допомагають нам упевнитися, що ми не опинимося в ситуації, коли готово близько 80% системи, але при цьому немає нічого завершеного для передачі користувачеві. Ми завжди вважаємо за краще мати можливість розробляти системи, що приносять якусь користь замовнику.


Модель прецедентів в цей момент ідентифікує прецеденти використання і акторів з мінімальною деталізацією або взагалі без неї. Це може бути простий текст або діаграми UML (Unified Modeling Language – Універсальна мова моделювання), намальовані від руки або за допомогою графічного редактора. Така модель допомагає нам переконатися, що ми включили необхідні зацікавленим особам функції, нічого не забувши, і дозволяє легко уявити систему в цілому. Для прецедентів призначаються пріоритети на основі таких факторів як ризик, важливість для замовника і технічна складність. Жоден з артефактів початкового обстеження не повинен бути надмірно формальним або об’ємним. Робіть їх настільки простими і суворими, наскільки це вам необхідно. XP включає поради з планування приймання системи. RUP привносить дещо ще на ранніх стадіях проекту. Ці невеликі додатки можуть пріместі істотні дивіденди при обліку більш повного набору ризиків.


Опрацювання проекту – Elaboration


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


У RUP процес проектування концентрується навколо визначення архітектури системи і для систем з великою часткою програмного забезпечення – навколо архітектури програмного забезпечення. Використання компонентних архітектур – один з шести найкращих підходів до розробки програм, інкорпорованих в RUP, рекомендує приділяти більше часу на розробку і супровід архітектур. Час, витрачений на ці зусилля, скорочує ризики, пов’язані з ненадійними і негнучкими системами.


XP заміщає уявлення архітектури “метафорою”. Метафора відображає частину архітектури, тоді як решта частини є природним результатом розробки коду. В XP передбачається, що архітектура з’являється в результаті найпростішого проектування та постійного реформування (refactoring) коду.


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


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


Поряд з тим, що надмірна увага до майбутніх можливостей, які можуть ніколи і не виникнути, дійсно марно, ми віримо, що достатня увага до майбутнього – річ передбачлива. Скільки компаній можуть дозволити собі постійно переписувати або навіть переформовувати код?


У будь-якому проекті під час опрацювання проекту ви повинні вирішити, як мінімум, три завдання:



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


Фаза опрацювання проекту у версії RUP охоплює елементи фаз дослідження (Exploration) та затвердження (Commitment) за версією XP. Підхід XP до технічних ризиків, таким як новизна і складність, – це “імпульсне” рішення. Виділіть якийсь час на експерименти для оцінки витрат. Цей прийом допомагає в багатьох випадках. Коли існує більший ризик, не покриваються одним прецедентом або історією, вам необхідно докласти більше зусиль, щоб переконатися в успіху системи і точної оцінки витрат.


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



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


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*