Швидка розробка програм. Методологія 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-засобів, що забезпечують цілісність проекту;

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

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

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

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

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

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

Розробка програмного продукту знає багато гідних методологій - інакше кажучи, усталених 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 етапи для кожного витка:

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

Підсумуємо


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

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

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

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

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

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

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

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

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

1. Аналізу та планування вимог;

2. Проектування;

3. Побудови;

4. Використання.


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

Результатом фази мають бути:список розставлених за пріоритетом функцій майбутньої ПС; попередня функціональна модель ПЗ; попередня інформаційна модель ПЗ.

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

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

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

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

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

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

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

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

На закінчення перерахуємо основні принципи технології RAD:

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

Ø необов'язковість повного завершення робіт на кожному етапі ЖЦ;

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

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

Ø тестування та розвиток проекту одночасно з розробкою;

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


Контрольні питаннядо глави 3:

1. Що таке стандартизація та сертифікація програмного продукту?

2. Які типи стандартів?

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

4. Що таке життєвий цикл?

5. Перерахуйте основні етапи життєвого циклу. Що таке процес, дія, завдання?

6. Які типи процесів та конкретні процеси ви запам'ятали?

7. Розкажіть про основні інженерні процеси життєвого циклу ПЗ.

8. Що таке модель життєвого циклу? Дайте визначення основних понять, пов'язаних із поняттям «модель».

9. Які типи моделей ви знаєте? У чому їх переваги, недоліки, область застосування?

10. Що ви можете сказати про особливості каскадної моделі життєвого циклу?

11.У чому відмінність узагальненої каскадної моделі від базової?

12.Что можна сказати про особливості спіральної моделі життєвого циклу?

13. Перерахуйте складові технології RAD. Для розробки яких типів програм можна використовувати технологію RAD?

14.Опишіть основні фази життєвого циклу за технологією RAD.

15. Перерахуйте основні принципи технології RAD.


СПИСОК ЛІТЕРАТУРИ

1. Аптекар М. Д., Рамазанов С. К., Фрегер Г. Є. Історія інженерної діяльності. - Київ, 2003. - 204 с. : іл.

2. Арчібальд Р. Моделі життєвого циклу високотехнологічних проектів. http://www.pmprofy.ru/content/ukr/107/1073-article.html

3. Брукс Ф. Міфічний людино-місяць або як створюються програмні системи. - СПб. : Символ-плюс, 1999. - 321 с. : іл.

4. Буч Р. Об'єктно-орієнтоване проектування з прикладами застосування. - М.: Конкорд, 1992. - 586с. : іл.

5. Буч Г. Об'єктно-орієнтований аналіз та об'єктно-орієнтоване проектування на С++. - М.: Біном, - 2001. - 558 с. : іл.

6. Вендров А. М. CASE-технології. Сучасні методита засобів проектування інформаційних систем. - М.: Фінанси та статистика, - 1999. - 256 с. : іл.

7. Вірт Н. Алгоритми + структури даних = програми: Пер. з англ. - М.: Світ, 1985. - 406 с.: Іл.

8. Дал О., Дейкстра Е., Хоор К. Структурне програмування: Пер. з англ. - М.: Світ, 1975. - 247 с. : іл.

9. Дзержинський Ф. Я., Калініченко І.М. Дисципліна програмування: концепція та досвід реалізації методичних засобів програмної інженерії. - М.: ЦНДІ інформації та техніко-економічних досліджень з атомної науки і техніки, 1988. - 245 с. : іл.

10. Жогольов Є. А. Технології програмування. - М.: Науковий світ, 2004. - 216 с. : іл.

11. Закон РФ № 149-ФЗ від 29.07.2006. «Про інформацію, інформаційних технологійта захисту інформації» // Російська газета, № 165 від 27.07.2006 р.

12. Іванова Г. С. Технологія програмування: Підручник для вузів. - 2-ге вид., Стереотип. - М.: Вид-во МДТУ ім. Н.Е.Баумана, 2003. - 320 с.: Іл.

13. Калянов Г. Н. CASE: Структурний системний аналіз (автоматизація та застосування). - М.: «Лорі», 1996. - 356 с. : іл.

14. Кораблін М. А. Програмування, орієнтоване на об'єкти: Навчальний посібник. - Самара: вид-во СДАУ, 1994. - 94 с.

15. Леоненков А. В. Самовчитель UML. - СПб: ВХВ Петербург, - 2001. - 304 с. : іл.

16. Липаєв В. В. Якість програмного забезпечення. - М.: Фінанси та статистика, 1983. - 263 с. : іл.

17. Липаєв В. В. Налагодження складних програм: Методи, засоби, технологія. -М. : Вища школа, 1993. - 384 с. : іл.

18. Липаєв В. В., Філіппов Є. Н. Мобільність програм та даних у відкритих інформаційних системах. - М.: Наукова книга, 1997. - 297 с. : іл.

20. Ожегов З. І. Словник російської. - М.: Світ та освіта, 2006. - 1328 с.

21. Технологія проектування комплексів програм АСУ/В. В. Липаєв, Л. А. Серебровський, П. Г. Гаганов та ін; За ред. Ю. В. Афанасьєва, В. В. Липаєва. - М.: Радіо і зв'язок, 1983. - 256 с. : іл.

22. Хювенен Е., Сеппянен Й. Світ ЛИСПа: Пров. з фінськ. У 2 т. Т.1: Введення в мову Лісп і функціональне програмування.- М.: Світ, 1990. - 447 с. : іл.

23. Хювенен Е., Сеппянен Й. Світ ЛИСПа: Пров. з фінськ. У 2 т. Т.2: Методи та системи програмування. - М.: Світ, 1990. - 319 с. : іл.

24. Boehm B. "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol. 21, No. 5, pp. 61-72, 1988.

25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.

26. Criteria for Evaluation of Software. ISO TC97/SC7 #383.

27. Dijktra E. 1979. Programming Considered як Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Microsoft Corporation. Принципи проектування та розробки програмного забезпечення. Навчальний курс MCSD: Пров. з англ. - М.: Видавничо-торговельний будинок «Російська редакція», 2000. -608 с. : іл.

31. Parnas D., Clements P., Weiss D. 1983. Enhancing Reusability with Information Hiding. Процедури Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

32. Rechtin E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29 (10), p.66.

33. Royce W.W. Managing the Development of Large Software Systems. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1 (4).

35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press. - p.218.

36. Sommerville I. Software engineering. - Addison-Wesley Publishing Company, 1992. p.87.

37. Tesler L. August 1981. The Smalltalk Environment. Byte vol.6 (8), p.142.

38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: The MIT Press.


список термінів


Вибір методик розробки додатків стає завданням № 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 відносяться:

  1. висока якість.Взаємодія користувачів із прототипами підвищує функціональність проектів, виконаних у рамках швидкої розробки програм. Таке програмне забезпечення може більше відповідати потребам замовника (кінцевого користувача), аніж за використання методик Agile/Waterfall.
  2. контроль ризиків- незважаючи на те що левова частина матеріалів про RAD фокусується на швидкостіі залученнікористувачів як ключовим особливостяммоделі, не можна виключати третю важливу перевагу — зниження ризиків. Цікаво, але Боем, який створив першу версію RAD, охарактеризував спіральну модель як на основі ризику.
    Використання rapid application development дозволяє вже на ранніх стадіях зосередитись на головних факторах ризику та пристосуватися до них.
  3. за одиницю часу виконується більше проектів у рамках бюджету- так як RAD має на увазі інкрементну модель розробки, шанси на критичні помилки, які часто трапляються у великих проектах за системою Waterfall, знижено.
    Якщо в проектах по водоспадній системі реалізація проекту була можлива після шести і більше місяців аналізу та розробки, то в RAD вся необхідна інформація відкривається раніше, під час процесу створення програми.
Інкрементна модель розробки — формат розробки програмного забезпечення, що передбачає поділ продукту на незалежні компоненти. Останні розробляються та вводяться в експлуатацію окремо.

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

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

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


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

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

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

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

Вердикт

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

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

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

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

Концепція RAD стала відповіддю на методи розробки програм 1970-х та початку 1980-х років, такі як «модель водоспаду». Ці методи передбачали настільки повільний процес створення програми, що найчастіше навіть вимоги до програми встигали змінитись до закінчення розробки. Засновником RAD вважається співробітник IBM Джеймс Мартін, який у 1980-х роках сформулював основні принципи RAD, ґрунтуючись на ідеях Баррі Бойма та Скотта Шульца. А в 1991 Мартін опублікував відому книгу, в якій детально виклав концепцію RAD і можливості її застосування. Нині RAD стає загальноприйнятою схемою створення засобів розробки програмних продуктів.

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

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

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

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

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

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

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

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

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

опис інформаційних потреб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На стадії впровадження проводиться навчання користувачів та організаційні зміни.

Застосування технології RAD доцільно, коли:

потрібно виконання проекту у стислий термін (90 днів);

нечітко визначено вимоги до ПЗ;

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

інтерфейс користувача (GUI) є основним чинником;

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

ПЗ не має великої обчислювальної складності.

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

Рисунок 1 - Порівняння RAD та Каскадного методу



ПОХОДЖЕННЯ СТАТТІ