Модель RAD (Rapid Application Development) основана на прототипировании и итеративной разработке без особого планирования. Сам процесс написания программного обеспечения включает планирование, необходимое для разработки продукта.
Быстрая разработка приложений фокусируется на сборе требований клиентов с помощью семинаров или фокус-групп, раннего тестирования прототипов заказчиком с использованием итеративной концепции, повторного использования существующих прототипов (компонентов), непрерывной интеграции и быстрой доставки.
Что такое RAD?
Быстрая разработка приложений — это методология разработки программного обеспечения, которая использует минимальное планирование в пользу быстрого прототипирования. Прототип — это рабочая модель, функционально эквивалентная компоненту продукта.
В модели RAD функциональные модули разрабатываются параллельно как прототипы и объединяются, чтобы сделать полный продукт для более быстрой доставки продукта. Поскольку детального предварительного планирования нет, это облегчает включение изменений в процесс разработки.
Проекты RAD следуют итеративной и инкрементальной модели и имеют небольшие команды, состоящие из разработчиков, экспертов в области, представителей клиентов и других ИТ-ресурсов, которые постепенно работают над своим компонентом или прототипом.
Наиболее важным аспектом успеха этой модели является обеспечение возможности повторного использования разработанных прототипов.
RAD Модель Дизайн
Модель RAD распределяет фазы анализа, проектирования, сборки и тестирования на серию коротких итерационных циклов разработки.
Ниже приведены различные этапы модели RAD —
Бизнес моделирование
Бизнес-модель для разрабатываемого продукта разработана с точки зрения потока информации и распределения информации между различными бизнес-каналами. Полный бизнес-анализ выполняется, чтобы найти жизненно важную информацию для бизнеса, как ее можно получить, как и когда обрабатывается информация, и каковы факторы, влияющие на успешный поток информации.
Моделирование данных
Информация, собранная на этапе бизнес-моделирования, анализируется и анализируется для формирования наборов объектов данных, важных для бизнеса. Атрибуты всех наборов данных идентифицированы и определены. Отношения между этими объектами данных устанавливаются и детально определяются в соответствии с бизнес-моделью.
Моделирование процессов
Наборы объектов данных, определенные на этапе моделирования данных, преобразуются для установления потока деловой информации, необходимого для достижения конкретных бизнес-целей в соответствии с бизнес-моделью. Модель процесса для любых изменений или улучшений в наборах объектов данных определяется на этом этапе. Даны описания процессов для добавления, удаления, извлечения или изменения объекта данных.
Генерация приложений
Фактическая система построена, и кодирование выполняется с использованием инструментов автоматизации для преобразования моделей процессов и данных в реальные прототипы.
Тестирование и Оборот
Общее время тестирования в модели RAD сокращается, поскольку прототипы тестируются независимо на каждой итерации. Однако поток данных и интерфейсы между всеми компонентами должны быть тщательно протестированы с полным охватом тестирования. Поскольку большинство компонентов программирования уже были протестированы, это снижает риск возникновения серьезных проблем.
На следующем рисунке подробно описывается модель RAD.
Модель RAD против традиционного SDLC
Традиционный SDLC следует жестким моделям процессов с большим упором на анализ требований и сбор данных до начала кодирования. Это заставляет клиента подписывать требования до начала проекта, и клиент не ощущает продукта, так как в течение долгого времени нет работающей сборки.
Клиенту могут потребоваться некоторые изменения после того, как он увидит программное обеспечение. Тем не менее, процесс изменений довольно жесткий, и может быть нецелесообразно включать основные изменения в продукт в традиционном SDLC.
Модель RAD ориентирована на итеративную и поэтапную доставку рабочих моделей заказчику. Это приводит к быстрой доставке заказчику и участию клиента в течение всего цикла разработки продукта, снижая риск несоответствия фактическим требованиям пользователя.
Модель RAD — Применение
Модель RAD может быть успешно применена к проектам, в которых возможна четкая модульность. Если проект не может быть разбит на модули, RAD может потерпеть неудачу.
Следующие указатели описывают типичные сценарии, в которых может использоваться RAD —
-
RAD следует использовать только в том случае, если система может быть модульной, чтобы доставлять ее постепенно.
-
Его следует использовать, если существует высокая доступность дизайнеров для моделирования.
-
Его следует использовать только в том случае, если бюджет допускает использование инструментов автоматической генерации кода.
-
Модель RAD SDLC следует выбирать только в том случае, если имеются специалисты в предметной области, обладающие соответствующими деловыми знаниями.
-
Должен использоваться, когда требования изменяются во время проекта, а рабочие прототипы должны быть представлены заказчику небольшими итерациями в течение 2-3 месяцев.
RAD следует использовать только в том случае, если система может быть модульной, чтобы доставлять ее постепенно.
Его следует использовать, если существует высокая доступность дизайнеров для моделирования.
Его следует использовать только в том случае, если бюджет допускает использование инструментов автоматической генерации кода.
Модель RAD SDLC следует выбирать только в том случае, если имеются специалисты в предметной области, обладающие соответствующими деловыми знаниями.
Должен использоваться, когда требования изменяются во время проекта, а рабочие прототипы должны быть представлены заказчику небольшими итерациями в течение 2-3 месяцев.
Модель RAD — за и против
Модель RAD обеспечивает быструю доставку, поскольку сокращает общее время разработки благодаря возможности повторного использования компонентов и параллельной разработки. RAD работает хорошо, только если имеются высококвалифицированные инженеры, и заказчик также стремится к достижению целевого прототипа в заданные сроки. Если с обеих сторон не хватает обязательств, модель может потерпеть неудачу.
Преимущества модели RAD следующие:
-
Изменение требований могут быть учтены.
-
Прогресс можно измерить.
-
Время итерации может быть коротким с использованием мощных инструментов RAD.
-
Производительность с меньшим количеством людей за короткое время.
-
Сокращение времени разработки.
-
Увеличивает возможность повторного использования компонентов.
-
Быстрые начальные обзоры происходят.
-
Поощряет обратную связь с клиентами.
-
Интеграция с самого начала решает множество проблем интеграции.
Изменение требований могут быть учтены.
Прогресс можно измерить.
Время итерации может быть коротким с использованием мощных инструментов RAD.
Производительность с меньшим количеством людей за короткое время.
Сокращение времени разработки.
Увеличивает возможность повторного использования компонентов.
Быстрые начальные обзоры происходят.
Поощряет обратную связь с клиентами.
Интеграция с самого начала решает множество проблем интеграции.
Недостатки модели RAD следующие:
Зависимость от технически сильных членов команды для определения бизнес-требований.
Только система, которая может быть модульной, может быть построена с использованием RAD.
Требуются высококвалифицированные разработчики / дизайнеры.
Высокая зависимость от навыков моделирования.
Неприменимо к более дешевым проектам, так как стоимость моделирования и автоматической генерации кода очень высока.
Сложность управления больше.
Подходит для систем, основанных на компонентах и масштабируемых.
Требует участия пользователя на протяжении всего жизненного цикла.
Подходит для проекта, требующего более коротких сроков разработки.