Планування проекту на основі вимог, шлях rup

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

• Початок;

• Уточнення;

• Конструювання;

• Перехід.

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

• цілі життєвого циклу (кінець фази початку, рамки проекту і його бюджет);

• архітектура життєвого циклу (кінець фази уточнення, закінчена архітектура);

• початкова працездатність (кінець фази конструювання, бета-версія продукту);

• випуск виробу (кінець фази переходу і повного циклу розробки).

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

План проекту створюється якомога раніше у початковій фазі і модифікується за необхідності. Що це означає на практиці: укрупнений план робіт складається «якомога раніше», наприклад, через місяць після початку робіт; бюджет з'являється лише до закінчення першої фази (а вона, залежно від складності проекту може тривати місяць, а може і півроку); як план, так і бюджет проекту є лише прогнозом, який може коригуватися упродовж робіт над проектом; на момент появи плану і бюджету повинен з'явитися детальний опис лише 20% ключової функціональності системи і «широкий, але неглибокий» [2] опис 80% функціональності.

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

Конкретніша інформація представлена у плані ітерації. Основні його особливості:

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

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

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

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

Таким чином, слід зазначити, що вимоги є вирішальним чинником у плануванні ітераційного проекту.

Вимоги у гнучких методологіях

На противагу прогнозуючим методологіям створення програмного забезпечення, відносно нещодавно сформувалася парадигма гнучких (agile) методологій. У лютому 2001 р. ініціативна група з 17 фахівців об'єдналася до Альянсу гнучкої розробки програмного забезпечення. Ця група розробила і прийняла Маніфест гнучкої розробки:

Індивідуальності і взаємодії ВИЩЕ процесів і інструментів;

Працююче програмне забезпечення ВИЩЕ усебічної документації;

Співпраця з клієнтами ВИЩЕ за обговорення контракту;

Реакція на зміни ВИЩЕ дотримування плану та 12 додатків нього.

Певною мірою, на противагу усьому тому, про що йшлося у попередніх темах, члени Альянсу ставлять під сумнів необхідність усебічного моделювання і документування вимог.

Зараз дуже популярно «бути гнучким». Так, опубліковані щонайменше два варіанти гнучкої трансформації для RUP; MSF опублікувало нотацію agile MSF. Що ж виступає у якості артефактів для роботи з вимогами в гнучких методологіях?

Основними засобами, що ними оперують гнучкі методології, є карти представлення системи, історії користувачів, приймальні тести і CRC - картки [3-4] тощо.

Карта представлення певною мірою замінює документ «концепція», прийнятий у прогнозуючих методологіях. На відміну від концепції, представлення – це текст розміром в 20-30 слів, що вміщується на невеликій (розміром з візитну) картці.

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

Історії користувача, окрім базового функціонала, можуть містити розширення, що дуже нагадують орієнтири RUP (див тему№9).

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

• Установка (контекст; подія, що ініціює).

• Операція (функція з кількісними характеристиками).

• Підтвердження (результати виконання функції).

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

Планування на основі вимог на прикладі XP містить наступні роботи:

1. оцінювання,

2. планування версій і ітерацій.

Оцінювання є визначенням обсягу робіт у розрізі історій користувача. Кожна історія оцінюється у пунктах. Один пункт дорівнює «ідеальному» (сорокагодинному) тижню, цілком присвяченому програмуванню. Якщо оцінка лежить у межах від 1 до 3 пунктів, він ставиться на картці історії. Якщо оцінка менше 1, на картці ставиться «0». Це, так званий, «пісок». Якщо оцінка перевищує 3 пункти, то маємо справу з «епопеєю». У цьому випадку картка позначається, як «split» і підлягає процедурі розділення. Інша стратегія роботи з такою карткою - намагатися вмістити її в оптимальний термін шляхом виключення розширень (декорацій).