Середовища швидкої розробки додатків. Методологія RAD - Rapid Application Development

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є методологія швидкої розробки додатків RAD (Rapid Application Development), що набула останнім часом широкого поширення. Під цим терміном зазвичай розуміється процес розробки ПЗ, що містить 3 елементи:

невелику команду програмістів (від 2 до 10 осіб);

короткий, але ретельно опрацьований виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ методології RAD складається з чотирьох фаз:

фаза аналізу та планування вимог;

фаза проектування;

фаза побудови;

фаза застосування.

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи, що розробляється, і приймається рішення про поділ ІС на підсистеми, що піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час - порядку 60 - 90 днів. За допомогою CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом цієї фази мають бути:

загальна інформаційна модель системи;

функціональні моделі системи в цілому та підсистем, що реалізуються окремими командами розробників;

точно визначені за допомогою CASE-засоби інтерфейси між підсистемами, що автономно розробляються;

збудовані прототипи екранів, звітів, діалогів.

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

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

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

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

визначається необхідність розподілу даних;

проводиться аналіз використання даних;

провадиться фізичне проектування бази даних;

визначаються вимоги до апаратних ресурсів;

визначаються способи збільшення продуктивності;

завершується розробка документації проекту.

Результатом фази є готова система, що відповідає всім узгодженим вимогам.

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

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

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

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

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

Як результат перерахуємо основні принципи методології RAD:

розробка додатків ітераціями;

необов'язковість повного завершення робіт кожному з етапів життєвого циклу;

обов'язкове залучення користувачів у процес розробки ІВ;

необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

необхідне використання генераторів коду;

використання прототипування, що дозволяє повніше з'ясувати та задовольнити потреби кінцевого користувача;

тестування та розвиток проекту, що здійснюються одночасно з розробкою;

ведення розробки нечисленною добре керованою командою професіоналів;

грамотне керівництво розробкою системи, чітке планування та контроль виконання робіт.

Вибір методик розробки додатків стає завданням № 1 за умов стрімкого зростання ринку. Згідно з дослідженням на програмне забезпечення для підприємств у 2015 році у світі було витрачено 310 млрд. доларів США. Розробка концепціїRAD (Rapid Application Development)стало основою для створення гнучкої адаптивної системи розробки додатків, яка була б противагою жорсткої «водопадної» моделі.

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 днів, бюджет - 3000 доларів.

Фаза проектування

Частина користувачів бере участь у технічному проектуванні системи під керівництвом розробників. Групи або підгрупи RAD на цій фазі зазвичай використовують комбінацію технікиз спільної розробки додатків (JAD) і CASE-інструменти для потреб користувачів у робочих моделях.

JAD (Joint Application Development) — концепція спільної розробки додатків, в рамках якої відбувається тісна взаємодія між замовником та виконавцями для максимально ефективного вирішення питань, що стосуються програмного забезпечення.

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, охарактеризував спіральну модель як на основі ризику.
Використання rapid application development дозволяє вже на ранніх стадіях зосередитись на головних факторах ризику та пристосуватися до них.
за одиницю часу виконується більше проектів у рамках бюджету- так як RAD має на увазі інкрементну модель розробки, шанси на критичні помилки, які часто трапляються у великих проектах за системою Waterfall, знижено.
Якщо в проектах по водоспадній системі реалізація проекту була можлива після шести і більше місяців аналізу та розробки, то в RAD вся необхідна інформація відкривається раніше, під час процесу створення програми.

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

Не обійшлося і без вад.

До мінусів rapid application development можна віднести:

ризик «новизни»- Для більшості IT-компаній RAD було новинкою, що потребує переосмислення звичних методик роботи. Опір новому, необхідність вивчення з нуля інструментів та техніки призводять до помилок під час перших впроваджень rapid application development.
якщо користувачі не можуть постійно брати участь у процесі розробки протягом усього життєвого циклу, це може негативно вплинути на кінцевий продукт – особливістю RAD є збільшена взаємодія користувачів та розробників на відміну від моделей Waterfall, у яких роль користувачів зводиться до визначення вимог. Далі розробники самі створюють систему.
зменшений контроль- Гнучкість, адаптивність процесу як одна з переваг RAD в ідеалі означає можливість швидко адаптуватися як до проблем, так і можливостей.
На жаль, доведеться віддати перевагу чомусь одному - гнучкості або контролю.У разі методика швидкої розробки додатків нічого очікувати життєздатною.
убогий дизайн— фокусування на прототипах у деяких випадках призводить до методики «зламування та тестування», за якою розробники постійно вносять дрібні змінив окремі елементи та ігнорують проблеми системної архітектури.
відсутність масштабованості— переважно RAD використовується маленькими та середніми проектними командами. Недоліки методології rapid application development особливо яскраво проявляються під час використання швидкої розробки додатків роботи над великими проектами.

Методологія RAD підійде вашому проекту, якщо:

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

Методологія rapid application development не підійде вашому проекту, якщо:

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

Вердикт

Концепція швидкої розробки програм (скорочено RAD від Rapid Application Development) — різновид інкреметних моделей розробки програмного забезпечення.

Ключові параметри, якими оперує RAD
швидкість та зручність програмування.

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

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

Сучасне управління
Контроль
Моніторинг

Терміново – не означає неякісно?

Розробка програм - це трудомісткий процес, який вимогливий до рівня та знань виконавця. Традиційно вважається, що якість має на увазі довгий цикл. Але чи це так насправді? Чи можливе швидко та терміново розробити ПЗ?

Щоб продукт виходив швидко - необхідна злагоджена команда професіоналів, або окремий виконавець-універсал. Зрозуміло, це не підходить до всіх програм.
Контроль якості – обов'язкова процедура. Контроль якості та вилов «багів» у процесі створення програмного забезпечення не може бути виключений з виробничого процесу, навіть для прискорення. Це необхідна умова для професійно зробленої програми.
Щоб терміновість не шкодила підсумковому продукту, потрібні виконавці, які давно освоїли та створили свій виробничий процес. Швидше за все, розробка ПЗ у таких фахівців пройде дійсно якісно і швидко.

Замовити термінові послуги розробки сьогодні може будь-хто, кому виконання необхідно швидко, терміново та професійно. Залишається відкритим питання, де знайти грамотних спеціалістів під термінове створення програм?

Пошук виконавців.

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

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

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

RAD-технологія (Rapid Application Development) – це технологія швидкого створення додатків на основі прототипування та використання графічного інтерфейсу користувача GUI (Graphical User Interface).

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

Вирішення багатьох проблем, пов'язаних з розробкою невеликих ІС, досягаються із застосуванням визнаної в усьому світі RAD-технології. Вона полягає в тому, що організується так звана RAD-група з 6-7 осіб, що складається з керівника, системного аналітика та 4-5 програмістів, яким даються чіткі плани на весь період розробки проекту з термінами від 1 до 2 тижнів.

Основою цієї технології є спіральна модель створення ІВ (рис. 6.1). Як видно на малюнку, технологія йде по спіралі, проходячи неодноразово всі 4 стадії розробки ІВ.

Рисунок 6.1 – Спіральна модель проектування на основі технології RAD

На стадії аналізукористувачі здійснюють такі дії:

визначають функції, які має виконувати система;

виділяють найпріоритетніші функції, що вимагають опрацювання в першу чергу;

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

обмежується масштаб проекту;

встановлюються часові рамки кожної з наступних стадій;

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

список розставлених за пріоритетом функцій майбутнього ПЗ;

попередні моделі ПЗ.

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

детальніше розглядаються процеси системи;

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

встановлюються вимоги щодо розмежування доступу до даних;

визначається склад необхідної документації.

Після детального визначення складу процесів оцінюється кількість так званих функціональних точок (function point) системи, що розробляється, і приймається рішення про поділ ІС на підсистеми, що піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час (до 3 місяців).

Функціональна точка – це будь-який з елементів системи, що розробляється:

вхідний елемент програми (вхідний документ чи екранна форма);

вихідний елемент програми (звіт, документ, екранна форма);

запит (пара «питання/відповідь»);

логічний файл (сукупність записів даних, що використовуються всередині програми);

інтерфейс програми (сукупність записів даних, що передаються іншому додатку або одержуються від нього).

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

У разі використання CASE-засобів це поділ функціональної моделі системи (діаграми потоків даних для структурного підходу або діаграми варіантів використання об'єктно-орієнтованого підходу).

Результатом даної стадії мають бути:

загальна інформаційна модель системи;

функціональні моделі системи в цілому та підсистем, що реалізуються окремими командами розробників;

точно визначені інтерфейси між підсистемами, що автономно розробляються;

збудовані прототипи екранних форм, звітів, діалогів.

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

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

На стадії реалізаціївиконується безпосередньо сама швидка розробка програми:

розробники виробляють ітеративну побудову реальної системи на основі одержаних на попередній стадії моделей, а також вимог нефункціонального характеру (вимог до надійності, продуктивності тощо);

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

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

здійснюється аналіз використання даних та визначається необхідність їх розподілу;

провадиться фізичне проектування бази даних;

формулюються вимоги до апаратних ресурсів;

встановлюються способи збільшення продуктивності;

завершується розробка документації проекту.

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

1. "Waterfall Model" (каскадна модель або "водоспад")

Одна з найстаріших має на увазі послідовне проходження стадій, кожна з яких повинна завершитися повністю до початку наступної. У моделі Waterfall легко управляти проектом. Завдяки її жорсткості, технологія проходить швидко, вартість та термін заздалегідь визначені. Але це палиця з двома кінцями. Каскадна модель даватиме відмінний результат тільки в проектах з чітко та заздалегідь визначеними вимогами та способами їх реалізації. Немає можливості зробити крок назад, тестування починається лише після того, як розробка завершена чи майже завершена. Продукти, розроблені за цією моделлю без обґрунтованого її вибору, можуть мати недоліки (список вимог не можна скоригувати будь-якої миті), про які стає відомо лише наприкінці через сувору послідовність дій. Вартість внесення змін висока, тому що для її ініціалізації доводиться чекати на завершення всього проекту. Проте фіксована вартість часто переважує мінуси підходу. Виправлення усвідомлених у процесі створення недоліків можливе, і, на наш досвід, вимагає від однієї до трьох додаткових угод до контракту з невеликим ТЗ.

За допомогою каскадної моделі ми створили безліч проектів з нуля, включаючи розробку тільки ТЗ. Проекти, про які написано на Хабрі: середній - рентгенівський мікротомограф, дрібний - автооновлення служби Windows на AWS.

Коли використати каскадну методологію?

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

2. "V-Model"

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

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

Коли використовувати V-модель?

Якщо потрібно ретельне тестування продукту, то V-модель виправдає закладену у собі ідею: validation and verification.
Для малих та середніх проектів, де вимоги чітко визначені та фіксовані.
У разі доступності інженерів необхідної кваліфікації, особливо тестувальників.

3. «Incremental Model» (інкрементна модель)

В інкрементній моделі повні вимоги до системи поділяються на різні складання. Термінологія часто використовується для опису поетапного складання ПЗ. Є кілька циклів розробки, і разом вони становлять життєвий цикл «мульти-водоспад». Цикл розділений на дрібніші модулі, що легко створюються. Кожен модуль проходить через фази визначення вимог, проектування, кодування, впровадження та тестування. Процедура розробки по інкрементної моделі передбачає випуск першому великому етапі продукту у базової функціональності, та був вже послідовне додавання нових функцій, про «інкрементів». Процес триває доти, доки не буде створено повну систему.

Інкрементні моделі використовуються там, де окремі запити на зміну зрозумілі, можуть бути легко формалізовані та реалізовані. У наших проектах ми застосовували її для створення читалки DefView, а потім і мережі електронних бібліотек Vivaldi.

Як приклад опишемо суть одного інкременту. Мережа електронних бібліотек Vivaldi прийшла на зміну DefView. DefView підключався до одного сервера документів, а тепер може підключатися до багатьох. На майданчик закладу, який бажає транслювати свій контент певної аудиторії, встановлюється сервер зберігання, який безпосередньо звертається до документів і перетворює їх у потрібний формат. З'явився кореневий елемент архітектури - центральний сервер Vivaldi, який у ролі єдиної пошукової системи за всіма серверами зберігання, встановлених у різних установах.

Коли використати інкрементну модель?

Коли основні вимоги до системи чітко визначені та зрозумілі. У той самий час деякі деталі можуть допрацьовуватися з часом.
Потрібно раннє виведення товару ринку.
Є кілька ризикових фіч чи цілей.

4. "RAD Model" (rapid application development model або швидка розробка додатків)

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

Модель швидкої розробки додатків включає такі фази:

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

Коли використовується модель RAD?

Може використовуватися лише за наявності висококваліфікованих та вузькоспеціалізованих архітекторів. Бюджет проекту великий, щоб сплатити цих фахівців разом із вартістю готових інструментів автоматизованого збирання. RAD-модель може бути обрана за впевненого знання цільового бізнесу та необхідності термінового виробництва системи протягом 2-3 місяців.

5. "Agile Model" (гнучка методологія розробки)

У «гнучкій» методології розробки після кожної ітерації замовник може спостерігати результат і розуміти, чи задовольняє він його чи ні. Це одна з переваг гнучкої моделі. До її недоліків відносять те, що через відсутність конкретних формулювань результатів складно оцінити трудомісткість і вартість, потрібні на розробку. Екстремальне програмування (XP) є одним із найбільш відомих застосувань гнучкої моделі на практиці.

В основі такого типу – нетривалі щоденні зустрічі – «Scrum» і регулярно повторювані збори (раз на тиждень, раз на два тижні або раз на місяць), які називаються «Sprint». На щоденних нарадах учасники команди обговорюють:

звіт про виконану роботу з моменту останнього Scrum'a;
список завдань, які співробітник має виконати до наступних зборів;
складнощі, що виникли під час роботи.

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

Коли використовувати Agile?

Коли потреби користувачів постійно змінюються у динамічному бізнесі.
Зміни на Agile реалізуються за меншу ціну через часті інкременти.
На відміну від моделі водоспаду, у гнучкій моделі для старту проекту достатньо лише невеликого планування.

6. "Iterative Model" (ітеративна або ітераційна модель)

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

На діаграмі показано ітераційну «розробку» Мона Лізи. Як видно, у першій ітерації є лише малюнок Джоконди, у другій – з'являються кольори, а третя ітерація додає деталей, насиченості та завершує процес. В інкрементної моделі функціонал продукту нарощується по шматочках, продукт складається з частин. На відміну від ітераційної моделі, кожен шматочок є цілісним елементом.

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

Коли оптимально використати ітеративну модель?

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

7. "Spiral Model" (спіральна модель)

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

Спіральна модель передбачає 4 етапи для кожного витка:

планування;
аналіз ризиків;
конструювання;
оцінка результату та при задовільній якості перехід до нового витка.

Ця модель не підійде для малих проектів, вона є резонною для складних і дорогих, наприклад, таких, як розробка системи документообігу для банку, коли кожен наступний крок вимагає більшого аналізу для оцінки наслідків, ніж програмування. На проекті з розробки СЕД для ОДУ Сибіру СВ ЄЕС дві наради про зміну кодифікації розділів електронного архіву займають у 10 разів більше часу, ніж об'єднання двох папок програмістом. Державні проекти, в яких ми брали участь, розпочиналися з підготовки експертною спільнотою дорогої концепції, яка аж ніяк не завжди марна, оскільки окупається в масштабах країни.

Підсумуємо

На слайді продемонстровано відмінності двох найпоширеніших методологій.

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

Про технології розробки:
Ще раз про сім основних методологій розробки.
10 головних помилок масштабування систем.
8 принципів планування розробки, що спрощують життя.
5 основних ризиків при замовленій розробці ПЗ.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. , будь ласка.