Модель быстрой разработки приложения rad модель

Что такое быстрая разработка приложений? Полное руководство

Модель быстрой разработки приложений (Rad) — это модель разработки, которая способствует быстрому созданию прототипов и немедленной обратной связи по сравнению с длительными, затяжными циклами разработки и тестирования. С помощью моделей быстрой разработки приложений программисты могут сделать несколько итераций и модификаций программного обеспечения за короткий промежуток времени без необходимости каждый раз начинать с самого начала. Это способствует тому, чтобы конечный результат был более качественным и соответствовал потребностям конечных пользователей.

Водопадная модель ранее была наиболее распространенной техникой разработки программного обеспечения. Типичный водопадный подход к разработке программного обеспечения подчеркивает тщательное планирование. Тем не менее, он обеспечивает относительно ограниченную гибкость для учета мнения клиентов на различных этапах процесса разработки. Это часто приводит к тому, что заказчик вносит свои идеи, что, в свою очередь, заставляет переделывать этап разработки с самого начала. Модель быстрой разработки приложений исправляет все недостатки, присущие водопадному подходу.

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

В самом начале Барри Боэм, Джеймс Мартин и ряд других признали, что для разработки программного обеспечения не нужны обычные инженерные практики. Это не был одиночный ресурс, который требовал заранее определенного расположения компонентов. Оно может быть сформировано таким образом, чтобы наилучшим образом соответствовать требованиям пользователя.

Вначале модель быстрой разработки приложений была организована по спиральной модели, в которой одна или несколько моделей разработки использовались для работы над конкретным проектом или разработкой программного обеспечения. Она отличается от других моделей.

Быстрая разработка приложений (БРП) развивалась с течением времени. Она адаптировала свою структуру к требованиям времени, сохраняя при этом фундаментальные принципы своего развития. Термин Rad означает модель быстрой разработки приложений — это модель, способная производить прототипы в быстром темпе. После этого потребитель вносит свой вклад в прототипы, которые анализируются и используются для модификации, чтобы лучше соответствовать требованиям потребителя.

Основные этапы быстрой разработки приложений

Быстрая разработка приложений или модель Rad может быть разбита на четыре отдельные части. Ниже приводится описание этих этапов:

Определение необходимых требований

Члены проектной группы, включая руководителя, сотрудников ИТ-отдела и пользователей, собираются вместе, чтобы определить цели, которые включают необходимость проекта, объем проекта, потенциальные трудности, которые могут возникнуть, а также цели и потребности проекта. Чтобы сохранить адаптивность проекта, процесс разработки гарантирует, что границы требований остаются широкими.

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

Фаза строительства и пользовательский вклад работают вместе для создания конечного продукта разработки приложения или радиомодели. На этапе построения учитывается обратная связь, предоставленная пользователем на этапе ввода данных. Кодирование и тестирование являются типичными подходами, используемыми для достижения этой цели. Фаза создания и фаза ввода данных пользователем продолжаются до тех пор, пока пользователь не достигнет точки удовлетворения результатами.

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

Когда использовать модели Rad (Rapid Application Development)

• Когда на создание продукта отводится меньше времени, например, в течение нескольких дней, используется модель Rapid Application Development (Rad).
• Эта модель используется, когда уже принято решение относительно результатов и требований.
• Модели быстрой разработки приложений (Rad) могут использоваться, когда конечному пользователю или клиенту предоставляется возможность участвовать во всех фазах жизненного цикла продукта; это известно как «вовлечение клиента или пользователя».
• Эта модель может использоваться в том случае, если бюджет достаточно велик; можно нанять дизайнеров. Для разработки кода с помощью автоматизированных инструментов, которые требуют большего бюджета, необходимо иметь больший бюджет.

Проекты, в которых лучше всего использовать RAD

Модель быстрой разработки приложений (Rad) особенно полезна для проектирования программного обеспечения, которое определяется потребностями пользовательского интерфейса, хотя это не единственное приложение, в котором она может быть использована. Инструменты, которые используются для создания графических пользовательских интерфейсов, часто называют инструментами быстрой разработки приложений (rad).

Чем отличается RAD?

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

Преимущества модели быстрой разработки приложений (Rad)

Следующий список ключевых преимуществ методологии разработки приложений:

• Усовершенствованное управление рисками.
• Сокращение количества времени, затрачиваемого на разработку, и увеличение скорости доставки.
• Повышенная адаптивность и степень гибкости.
• Постоянный пользовательский ввод, актуальный и в режиме реального времени.
• Меньше необходимости в ручном кодировании, и тестирование займет меньше времени.
• Требования могут быть пересмотрены в любой момент.
• Высокий уровень производительности при сокращении рабочей силы.
• Минимальное время между прототипами и пересмотром.

Источник

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

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

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

На рисунке (рис.7), поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.

Модель включает в себя следующие фазы:

Составление требований и планирование — осуществляются с использованием, так называемого метода совместного планирования требований (планирование работ по созданию программного продукта и составление требований к программному продукту выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач;

Описание пользователя – проектирование программного продукта, выполняемое при непосредственном участии заказчика;

Создание – детальное проектирование, кодирование и тестирование программного продукта, а также поставка его заказчику;

Сопровождение – приемочные испытания, установка программного продукта и обучение пользователей.

Модель обладает следующими достоинствами:

1) Использование современных инструментальных средств позволяет сократить время цикла разработки;

2) Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;

3) Повторно используются компоненты уже существующих программ.

В то же время ей присущи и недостатки:

1) Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;

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

3) Существует риск, что работа над программным продуктом никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.

Рассмотренную RAD-модель можно применять при разработке программных продуктов, которые хорошо поддаются моделированию, когда требования к программным продуктам хорошо известны, а заказчик может принять непосредственное участие в процессе разработки.

Рис.7 Модель быстрой разработки приложений

3.6 Многопроходная модель

Многопроходная модель (рис.8) – это несколько итераций процесса построения прототипа программного продукта с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности программного продукта.

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

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

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

Многопроходная модель может быть применена, если большинство требований к программному продукту будут сформулированы заранее, а для выполнения проекта будет выделен большой период времени.

Рис.8 Многопроходная модель

Источник