Перехід від каскадної розробки до ітеративної

Зміст



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


Більшість груп розробників використовують в своїх проектах каскадний (waterfall – водоспад, каскад) процес. У чистому вигляді каскадний підхід означать виконання ряду фаз в строго визначеному порядку: аналіз вимог, проектування, виконання / інтеграція, тестування. Тестування відкладається до кінця проекту, коли проблеми накопичуються настільки, що на їх рішення потрібно багато сил і часу; ці проблеми можуть зірвати терміни виконання проекту і надовго залишити ключових членів групи без роботи.


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


Переваги ітеративного походу


При ітеративному підході, наприклад, у прийнятому компанією IBM процесі Rational Unified Process (скорочено RUP), виконується послідовність кроків, які називаються итерациями. Кожна ітерація включає в себе частину (іноді більшу) стадій розробки (збір вимог, аналіз, проектування, виконання і т. д.), показаних на рис. 1. Кожна ітерація має чітко визначений набір цілей, а її завершення забезпечує часткову робочу версію кінцевої системи. Кожна чергова ітерація будується на основі попередніх ітерацій, далі розвиває, уточнює і удосконалює систему до завершення кінцевого продукту.


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

Рис. 1. Ітеративна розробка по методології RUP. На кожній ітерації виконуються: облік вимоги, аналіз, проектування, тестування. Кожна ітерація будується на основі попередніх ітерацій; її результатом є виконуваний файл, який на один крок ближче до кінцевого продукту.


Ітеративний підхід має переваги над каскадним підходом з ряду наступних причин.



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


Чотири кроки переходу


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



Розглянемо ці кроки більш докладно.


Крок 1. Створення функціональних прототипів на ранньому етапі


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


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


Для кожного ключового технічного ризику потрібно спланувати прототип з метою зменшити цей ризик. Розглянемо наступні приклади.


Технічний ризик. У ході виконання проекту потрібно перенести існуючий додаток, щоб воно могло працювати поверх сервера IBM WebSphere Application Server. Користувачі вже скаржаться на недостатнє швидкодію додатки, тому у вас є підозра, що вищевказаний перенесення може ще більше сповільнити роботу програми.


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


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


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


Крок 2. Розподіл фаз докладного проектування, виконання та тестування на ітерації


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


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


Підхід 1. Розробка підсистем по одній або по кілька одночасно. Припустимо, у вас є дев'ять підсистем, причому в кожній безліч компонентів. Ви можете розділити фази докладного проектування, виконання та тестування на три ітерації, кожна з яких спрямована на три з дев'яти підсистем. Це добре в тому випадку, якщо залежності між підсистемами не надто великі. Наприклад, ваші дев'ять підсистем повинні надавати кінцевим користувачам чітко визначений набір можливостей. На першій ітерації можна розробити найважливіші підсистеми, на другій ітерації – менш важливі, а на третій – ще менш важливі. Такий підхід має велику перевагу: якщо ви не встигнете завершити проект до призначеного терміну, то хоча б зробите частина системи з найбільш важливими функціями, причому ця частина буде чинною.


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


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


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


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


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


Крок 3. Створення базової версії діючої архітектури на ранньому етапі


Цей крок можна розглядати як більш формальний і організований крок 1: Створення функціональних прототипів на ранньому етапі Що таке "чинна архітектура"?


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


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


Але як придумати архітектуру еволюційного прототипу? Головне – сконцентруватися на найбільш важливих варіантах використання, приблизно від 20% до 30% всіх послуг, які системи повинна надавати кінцевим користувачам. Далі наведені деякі способи для визначення найбільш важливих варіантів використання.



Першому і останньому критеріями з наведеного вище списку архітектор повинен приділити більше уваги; керівник проекту повинен зосередитися в основному на перших двох критеріях.


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


Крок 4. Застосування ітеративного процесу з керуванням на основі ризиків


Якщо ви виконали описані вище кроки 2 і 3, то дуже близько підійшли до моделі "ідеальної" ітеративної розробки. Наступний крок – об'єднати кроки 2 і 3, додавши управління розробкою на основі ризиків і ітеративну розробку. Тобто описаний у RUP ряд ітерацій.


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



Безліч способів зробити ці кроки


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


Примітки


1 Детальний опис того, як розробка за методологією RUP здійснюється на практиці, міститься в розділах 5-8 книги The Rational Unified Process Made Easy (Покрокове керівництво по Rational Unified Process), автори Per Kroll і Philippe Kruchten (Addison-Wesley, 2003).


Додаткова інформація



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


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

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

Ваш отзыв

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

*

*