Вибір методик розробки додатків стає завданням №1 в умовах стрімкого зростання ринку. Згідно з дослідженням Gartner на програмне забезпечення для підприємств у 2015 році у світі було витрачено 310 млрд. доларів США. Розробка концепції RAD (Швидка Розробка Додатків) стала основою для створення гнучкої, адаптивної системи розробки додатків, яка стала б противагою жорсткій “водоспадній” моделі.
RAD — модель швидкої розробки додатків, ключовими для якої є швидкість і зручність програмування.
Поява RAD
За появу швидкої розробки додатків варто подякувати недосконалості моделі сімейства Waterfall при створенні ПЗ. Справа в тому, що спочатку водоспадна система розробки була заснована на традиційній інженерній моделі, що використовувалася для проектування та зведення будівель та мостів.
Якщо Waterfall за основу використовувала жорстку структуру послідовних дій по розробці, то поява RAD стала спробою створення гнучкого процесу, в рамках якого могли бути використані знання, отримані в процесі життєвого циклу управління проектом.
Першу версію RAD створив Баррі Боєм у 1986 році, який назвав її “спіральна модель”. Кожен виток спіралі розбитий на 4 сектора і відповідає розробці фрагмента або версії ПЗ. З кожним новим витком йде углублення та уточнення цілей, специфікацій проекту. У результаті з’являється можливість вибрати обґрунтований варіант.
Використавши ідеї Баррі, британець Джеймс Мартин розробив свою систему RAD протягом роботи в 80-их в IBM, і остаточно сформулював їх у книзі “Швидка розробка додатків” у 1991 р.
Правда, не обійшлося без плутанини в значенні слова “RAD” навіть серед IT-спеціалістів. Адже йшлося про дві концепції: RAD як ефективна альтернатива Waterfall і RAD як специфічний метод, розроблений Мартином. Останній був адаптований до бізнес-систем з інтенсивним використанням UI.
Далі ідеї були розвинуті та поліпшені піонерами RAD Джеймсом Керром і Річардом Хантером в спільній книзі “Всередині RAD”, яка описувала подорож проектного менеджера в процесі вивчення та впровадження методології швидкої розробки додатків у реальному житті для реального проекту.
Ці та багато інших авторів змогли популяризувати нову методику як альтернативу традиційним системам підходів до життєвого циклу проекту.
Спіральна модель — процес розробки ПЗ, що комбінує проектування та поетапне прототипування.
Основи (принципи) швидкої розробки додатків
Принципи RAD зосереджені на тому, щоб забезпечити основні переваги методики швидкої розробки додатків:
- підвищена швидкість розробки
- низька вартість
- висока якість.
З останнім пунктом виникає найбільше проблем, адже розробник і замовник бачать предмет розробки по-різному.
Для усунення цієї та інших проблем Джеймсом Мартином та його послідовниками були виділені наступні принципи RAD:
- мінімізація часових витрат — інструментарій має бути націлений на зменшення часу розробки
- прототипування - створення прототипів для конкретизації вимог замовника
- циклічність розробки - кожна нова версія продукту базується на оцінці результату роботи попередньої версії замовником
- співпраця - команда розробників повинна тісно взаємодіяти один з одним, кожен учасник має бути готовий виконувати кілька обов’язків
- ітераційний підхід до розробки
- комбінування тестування та розробки системи.
Принципи RAD використовуються не тільки під час реалізації, а й поширюються на всі етапи життєвого циклу, зокрема, на стадію огляду організації, побудови вимог, аналізу та дизайну.
Життєвий цикл програмного забезпечення за RAD
У процесі RAD додаток проходить чотири фази.
Фаза аналізу та планування вимог
Визначаються вимоги, функції додатка та їх пріоритетність, описуються інформаційні потреби. Фаза виконується переважно користувачами за участю розробників. На цій стадії також позначаються масштаб проекту, часові та фінансові рамки, платформи для запуску ПЗ.
Наприклад, компанії “Beverly Flowers” потрібно додаток для онлайн-замовлення квітів на дім. На створення відводиться 50 днів, бюджет — 3 000 доларів.Фаза проектування
Частина користувачів бере участь у технічному проектуванні системи під керівництвом розробників. Групи або підгрупи RAD на цій фазі зазвичай використовують комбінацію технік спільної розробки додатків (JAD) та CASE-інструменти для втілення потреб користувачів в робочих моделях.
JAD (Спільна Розробка Додатків) — концепція спільної розробки додатків, в рамках якої відбувається тісна взаємодія між замовником та виконавцями для максимально ефективного вирішення питань, що стосуються розроблюваного ПЗ.
CASE — комплект інструментів і методів для проектування ПЗ для забезпечення високої якості програм, відсутності помилок і простоти в обслуговуванні програмних продуктів.
На фазі проектування користувачі можуть зрозуміти, модифікувати та визначити робочу модель системи, яка відповідає їхнім потребам. Кожен процес розглядається детально і, за необхідності, створюється частковий прототип.
Внаслідок фази створюються:
- загальна інформаційна модель додатка
- функціональні моделі системи та підсистем
- робочі прототипи екранів, звітів і діалогів.
Якщо в попередніх моделях засоби розробки прототипів не відповідали реальним додаткам, і вони надалі не використовувалися, то в RAD кожен прототип стає частиною майбутньої системи.
Так, у додатку “Beverly Flowers” користувачі повинні мати доступ до можливостей: “Головна сторінка”, “Пошук квітів”, “Переглянути список квітів”.В якості платформи розробки вибрали freeware SpringToolSuite, для якої доступно велика кількість семплів — прописаних частин коду.
В ролі сервера — Apache Tomcat 6.0.
Фаза побудови
На цій стадії відбувається безпосередня швидка розробка на основі отриманих на попередніх фазах результатів. При цьому користувачі продовжують брати участь у розвитку системи, пропонуючи зміни та поліпшення додатка. Тестування додатка також відбувається під час розробки.
Додаток “Beverly Flowers” складається з трьох функціональних компонентів — переходу користувача на “Головну сторінку”, “Пошук квітів” та “Переглянути список квітів”.Для розробки робочої моделі знадобився 1 фахівець і 8 днів.
Фаза впровадження
Охоплює навчання користувачів, тестування та заміну старої системи на нову. Підготовка до цієї фази починається з етапу проектування.
Раніше компанія “Beverly Flowers” приймала замовлення безпосередньо в точках продажу та по телефону.Записавши повідомлення про можливість замовлення через спеціальне додаток і розмістивши інформаційні стенди в точках продажу, за 2 тижні вдалося переключити частину покупців на новий канал збуту.
При цьому частка замовлень по телефону пропорційно знизилася, а значить вдалося скоротити штат менеджерів з роботи з клієнтами.
Слід зазначити, що на відміну від Waterfall, життєвий цикл проекту за методологією RAD не є жорстким. Залежно від стартових умов, кількість фаз може зменшуватися, як і їх наповнення.
Плюси і мінуси швидкої розробки додатків у вашій компанії
Використовувати Rapid Application Development чи ні, у значній мірі залежить від стартових умов, вимог замовника та виду додатка.
До однозначних переваг RAD належать:
- висока якість. Взаємодія користувачів з прототипами підвищує функціональність проектів, виконаних у рамках швидкої розробки додатків. Таке програмне забезпечення може більше відповідати потребам замовника (кінцевого користувача), ніж при використанні методик Agile/Waterfall.
- контроль ризиків - незважаючи на те, що львиная частина матеріалів про RAD фокусується на швидкості та включенні користувачів як ключовим особливостям моделі, не можна виключати третє важливе перевага — зниження ризиків. Цікаво, але Боєм, який створив першу версію RAD, охарактеризував спіральну модель як основану на ризику.
Використання швидкої розробки додатків дозволяє вже на ранніх стадіях зосередитися на головних факторах ризику та адаптуватися до них. - за одиницю часу виконується більше проектів у межах бюджету — оскільки RAD передбачає інкрементну модель розробки, шанси на критичні помилки, які часто трапляються у великих проектах по системі Waterfall, знижені.
Якщо в проектах по водоспадній системі реалізація проекту була можлива після шести і більше місяців аналізу та розробки, то в RAD вся необхідна інформація відкривається раніше, під час самого процесу створення додатка.
Інкрементна модель розробки — формат розробки програмного забезпечення, яка передбачає розділення продукту на відносно незалежні компоненти. Останні розробляються та вводяться в експлуатацію окремо.
Не обійшлося і без недоліків.
До мінусів швидкої розробки додатків можна віднести:
- ризик “новизни” - для більшості IT-компаній RAD була новинкою, що вимагала переосмислення звичних методик роботи. Супротив новому, необхідність вивчення з нуля інструментів і технік приводять до помилок під час перших впроваджень швидкої розробки додатків.
- якщо користувачі не можуть постійно брати участь у процесі розробки протягом усього життєвого циклу, це може негативно вплинути на кінцевий продукт — особливістю RAD є підвищене взаємодію користувачів та розробників на відміну від моделей Waterfall, в яких роль користувачів зводиться до визначення вимог. Далі розробники самі створюють систему.
- зменшений контроль — гнучкість, адаптивність процесу як одна з переваг RAD в ідеалі означає можливість швидко адаптуватися як до проблем, так і можливостей.
На жаль, потрібно віддати перевагу чомусь одному — гнучкості або контролю. У останньому випадку методика швидкої розробки додатків не буде життєздатною. - скромний дизайн — фокусування на прототипах в деяких випадках призводить до методики “зламу і тестування”, за якою розробники постійно вносять незначні зміни в окремі елементи та ігнорують проблеми системної архітектури.
- відсутність масштабованості — переважно RAD використовується малими та середніми проектними командами. Недоліки методології швидкої розробки особливо яскраво проявляються при використанні швидкої розробки додатків у роботі над великими проектами.
Методологія RAD підійде вашому проекту, якщо:
- для нього важлива швидкість та простота розробки
- чітко визначені пріоритетні напрямки розробки проекту
- розробити додаток потрібно в стислі терміни
- проект виконується в умовах обмеженого бюджету
- головний критерій — інтерфейс користувача
- є можливість розбити проект на функціональні компоненти.
Методологія швидкої розробки не підійде вашому проекту, якщо:
- для нього важливе якість та контроль
- йдеться про створення крупномасштабного проекту — передбачуване максимальне час розробки додатка становить 60 – 90 днів, а при написанні сотень тисяч рядків програмного коду дотримання такого обмеження практично неможливо
- критично важливим для реалізації є високий рівень планування та жорстка дисципліна проектування, суворе дотримання заздалегідь розробленим протоколам та інтерфейсам
- від додатка в певній мірі залежить безпека людей.
Вердикт
Концепція швидкої розробки додатків (скорочено RAD від Rapid Application Development) — різновид інкрементних моделей розробки ПЗ.
Ключові параметри, якими оперує RAD —
швидкість і зручність програмування.
Методологія стане відмінним вибором для реалізації невеликих проектів з обмеженим бюджетом, розробити які потрібно у стислі терміни. Для масштабних же систем, з високими вимогами по контролю та плануванню краще обрати інші моделі розробки програмного забезпечення.