Швидка розробка додатків, rad.
(від англ. rapid application development) — концепція створення засобів розробки застосунків, програмних продуктів, що приділяє особливу увагу швидкості й зручності програмування, створенню технологічного процесу, що дозволяє програмістові максимально швидко створювати комп'ютерні програми. З кінця XX століття RAD одержала широке поширення й схвалення. Концепцію RAD також часто зв'язують із концепцією візуального програмування.Концепція RAD стала відповіддю на незграбні методи розробки програм 1970-х і початку 1980-х років, такі як «модель водоспаду» (англ. Waterfall model). Ці методи передбачали настільки повільний процес створення програми, що часто навіть вимоги до програми встигали змінитися до закінчення розробки. Засновником RAD вважається співробітник IBM Джеймс Мартін, який в 1980-х роках сформулював основні принципи RAD, ґрунтуючись на ідеях Баррі Бойма і Скотта Шульца. А в 1991 році Мартін опублікував відому книгу, в якій детально виклав концепцію RAD і можливості її застосування. В наш час[Коли?] RAD стає загальноприйнятою схемою для створення засобів розробки програмних продуктів. Саме засоби розробки, засновані на RAD, мають найбільшу популярність серед програмістів.
Основні принципи RAD:
Інструментарій має бути націлений на мінімізацію часу розробки.
Створення прототипу для уточнення вимог замовника.
Циклічність розробки: кожна нова версія продукту ґрунтується на оцінці результату роботи попередньої версії замовником.
Мінімізація часу розробки версії, за рахунок перенесення вже готових модулів і додавання функціональності в нову версію.
Команда розробників повинна тісно співпрацювати, кожен учасник повинен бути готовий виконувати декілька обов'язків.
Управління проектом повинне мінімізувати тривалість циклу розробки
Компонентно-орієнтована модель. Моделі якості процесів конструювання.
є розвитком спіральної моделі і теж грунтується на еволюційних стратегії конструювання. У цій моделі конкретизується зміст етапу конструювання. Воно відображає той факт, що в сучасних умовах нова розробка повинна грунтуватися на повторному використанні існуючих програмних компонентів.
Малюнок 5 - Етапи конструювання компонентно-орієнтованої моделі
Програмні компоненти, створені в реалізованих програмних проектах, зберігаються в бібліотеці. У новому проекті Програми, виходячи з вимог замовника, виявляються кандидати в компоненти. Далі перевіряється наявність цих кандидатів в бібліотеці. Якщо вони знайдені, то компоненти витягуються з бібліотеки і використовуються повторно. В іншому випадку створюються нові компоненти, які застосовуються в проекті і включаються в бібліотеку.
Переваги компонентно-орієнтованої моделі:
1) зменшує на 30% час розробки програмного продукту;
2) зменшує вартість програмної розробки до 70%;
3) збільшує продуктивність розробки.
Модель качества ПО
Качество ПО - это относительное понятие, которое имеет смысл только при учете реальных условий его применения, поэтому требования, предъявляемые к качеству, ставятся в соответствии с условиями и конкретной областью их применения. Оно характеризуется тремя аспектами: качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения (рис. 10.1).
Рис. 10.1. Основные аспекты качества ПО
Аспект, связанный с процессами ЖЦ, определяет степень формализации, достоверности самих процессов ЖЦ разработки ПО, а также верификацию и валидацию промежуточных результатов на этих процессах. Поиск и устранение ошибок в готовом ПО проводится методами тестирования, которые снижают количество ошибок и повышают качество этого продукта.
Качество продукта достигается процедурами контроля промежуточных продуктов на процессах ЖЦ, проверкой их на достижение необходимого качества, а также методами сопровождения продукта. Эффект от внедрения ПС в значительной степени зависит от знаний обслуживающего персонала функций продукта и правил их выполнения. Модель качества ПО имеет следующие четыре уровня представления.