RAD (программирование) (RAD (hjkijgbbnjkfguny))

RAD (от англ. rapid application development — быстрая разработка приложений) — концепция организации технологического процесса разработки программных продуктов, ориентированная на максимально быстрое получение результата в условиях сильных ограничений по срокам и бюджету и нечётко определённых требований к продукту. Эффект ускорения разработки достигается путём использования соответствующих технических средств и непрерывного, параллельного с ходом разработки, уточнения требований и оценки текущих результатов с привлечением заказчика. RAD создана в конце 1980-х как альтернатива более ранним каскадной и итеративной моделям. С конца XX века RAD получила широкое распространение.

Тот же термин используется в отношении программных инструментов быстрого прототипирования и разработки ПО. Типичными качествами таких инструментов являются максимальная автоматизация рутинных операций и широкое использование визуального программирования.

История

Создание концепции RAD явилось следствием сочетания ряда факторов.

• Неудовлетворённость методами разработки программ 1970-х и начала 1980-х годов, таких как «модель водопада» (англ. Waterfall model). Разработанные по аналогии с методами проектирования «железных» технических систем, они предусматривают поэтапное формирование требований, документирование, проектирование и реализацию. Их последовательное применение приводит к настолько медленному процессу создания программы, что зачастую даже базовые требования к программе успевают измениться до окончания разработки.
• Осознание факта отличия разработки программного продукта от традиционных видов инженерной деятельности, состоящее в гораздо большей доступности предмета разработки для сложных неоднократных модификаций.
• Появление аппаратных мощностей и программных средств разработки, позволяющих быстро создавать работоспособные прототипы программных систем и их частей и автоматизировать их документирование. При использовании таких средств альтернативой подробному проектированию и тщательному предварительному документированию системы становится быстрое создание или модификация прототипа и его непосредственная оценка заказчиком.
• Успешный опыт разработки систем, основанной на работе небольшой по численности сплочённой команды разработчиков, непосредственно взаимодействующих между собой и с представителем заказчика.

Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

Назначение

RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трёх-четырёх месяцев путём использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях — обследование организации, выработка требований к системе. Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учётом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.

Применение

Сравнение RAD и Каскадного метода

RAD-технология не является универсальной, её целесообразно применять лишь если проект отвечает всем или некоторым из условий:

1. Сжатые сроки. Требуется максимально быстро создать систему, отвечающую требованиям сегодняшнего дня. Увеличение сроков создаёт высокую вероятность настолько значительного изменения фундаментальных положений, регламентирующих автоматизируемую деятельность, что система морально устареет ещё до завершения проектирования.
2. Нечётко определённые и/или изменяющиеся по ходу разработки требования. Заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.
3. Ограниченный бюджет при готовности участия заказчика в разработке. У заказчика нет средств на оплату работы большой команды проектировщиков и разработчиков в течение длительного времени, но имеется готовность выделить специалистов для постоянного непосредственного участия в разработке и оценки её текущего состояния.
4. Небольшие объёмы либо возможность разбиения проекта на функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы её можно было разбить на небольшие части, каждая из которых обладает четкой функциональностью и минимально зависит от других. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD-групп).
5. Графический интерфейс пользователя — важнейший или один из важнейших компонентов системы. Именно в создании интерфейса RAD-технология даёт наибольшие преимущества, так как интерфейс демонстрируется непосредственно на прототипе, причём достаточно скоро после начала проекта. Возможно даже прямо привлечь представителя заказчика к проектированию интерфейса в визуальном редакторе. Этот подход позволяет избежать типичной ситуации, когда интерфейс, описанный пользователем в требованиях (как правило, без учёта технологических ограничений) ведёт себя на практике совсем не так, как рассчитывал пользователь, хотя формально система полностью соответствует документированным требованиям.
6. Низкая вычислительная сложность. Обработка данных в проекте сводится к комбинированию типовых операций, все или большинство из которых уже реализованы в виде доступных библиотек. Оригинальных алгоритмов обработки данных либо вообще не требуется, либо они достаточно просты и могут быть реализованы быстро и без особых затруднений.

Если требования к системе чётко определены и не могут меняться, вовлечение заказчика в процесс разработки не потребуется и более эффективной может быть традиционная иерархическая разработка (каскадный метод). Также RAD не даёт практически никаких преимуществ в проектах, основная сложность которых определяется необходимостью реализации сложных, нестандартных алгоритмов обработки данных, а интерфейс пользователя либо отсутствует как таковой, либо очень прост и совершенно стандартен.

Основные принципы

Add caption here

Принципы RAD технологии направлены на обеспечение трёх основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.

• Инструментарий должен быть нацелен на минимизацию времени разработки.
• Создание прототипа для уточнения требований заказчика.
• Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
• Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
• Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
• Управление проектом должно минимизировать длительность цикла разработки.

Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн.

Фазы разработки

1. Планирование — совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.

   

   Модель быстрой разработки приложений (RAD)

2. Пользовательское проектирование — на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счёте выбрать рабочую модель, отвечающую их требованиям.
3. Конструирование — этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии «реализация» в SDLC. В RAD, однако, пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование.
4. Переключение — включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.

Преимущества

Технология быстрой разработки приложений (RAD) позволяет обеспечить:

• быстроту продвижения программного продукта на рынок;
• интерфейс, устраивающий пользователя;
• лёгкую адаптируемость проекта к изменяющимся требованиям;
• простоту развития функциональности системы.

См. также

• Визуальное программирование
• Быстрое прототипирование
• Low-code