Методология RAD

1.

МЕТОДОЛОГИЯ
RAD
RAD — модель быстрой разработки
приложений, ключевыми для которой
является скорость и удобство
программирования.

2.

Почему качественно?
Пользователь может определять, какую
Почему быстро?
Методология RAD требует, чтобы
работающие прототипы создавались
максимально часто.
Продолжительность одного
производственного цикла — от
выработки требований до
демонстрации пользователю (то есть
одной итерации) — от одного дня до
трех недель.
функциональность он хочет видеть
реализованной в следующей итерации.
Постоянное взаимодействие заказчика
и разработчика гарантирует, что
приложение будет развиваться в
нужном направлении, интерфейс будет
удобным, а функциональность
востребованной. Такая схема
избавляет программиста от лишней
работы и исключает ситуации, когда
часть программы приходится
переделывать с нуля из-за неверно
понятых вводных.
Почему дешево?
Деньги — странный предмет: вот они
есть, а вот их нет. Бывает, что их не
хватает, и приходится прерывать
разработку, когда написана еще далеко
не вся запланированная
функциональность. Что получит
заказчик в этом случае?

3.

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

4.

Основы (принципы) быстрой разработки
приложений
Принципы RAD сосредоточены на том, чтобы обеспечить основные
преимущества методики быстрой разработки приложений:
1
2
3
повышенная скорость
разработки
низкая стоимость
высокое качество.

5.

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

6.

Жизненный цикл программного
обеспечения по RAD
В процессе RAD приложение проходит четыре фазы.
Фаза анализа и планирования требований
Фаза построения
Фаза проектирования
Фаза внедрения

7.

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

8.

Фаза проектирования
Часть пользователей участвует
в техническом проектировании
системы под руководством
разработчиков. Группы или
подгруппы RAD на этой фазе
обычно используют
комбинацию техник
совместной разработки
приложений (JAD) и CASEинструменты для воплощения
потребностей пользователей в
рабочих моделях.
В результате фазы
создаются:
общая информационная модель приложения
функциональные модели системы и подсистем
рабочие прототипы экранов, отчётов и диалогов.

9.

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

10.

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

11.

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

12.

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

13.

К минусам rapid
application
development можно
отнести:
1
риск «новизны» — необходимость изучения с нуля инструментов и
техник приводят к ошибкам во время первых внедрений rapid
application development.
2
если пользователи не могут постоянно брать участие в процессе
разработки на протяжении всего жизненного цикла, это может
негативно повлиять на конечный продукт.
3
4
5
уменьшенный контроль — гибкость, адаптивность процесса как
одно из преимуществ RAD в идеале означает возможность быстро
адаптироваться как к проблемам, так и возможностям.
скудный дизайн — фокусирование на прототипах в некоторых
случаях приводит к методике «взлом и тестирование», по которой
разработчики постоянно вносят мелкие изменения в отдельные
элементы и игнорируют проблемы системной архитектуры.
отсутствие масштабируемости — преимущественно RAD
используется маленькими и средними проектными командами.

14.

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

15.

Методология
rapid application
development не
подойдёт
вашему
проекту, если:
• для него важно качество и контроль
• идет речь о создании крупномасштабного проекта —
предполагаемое максимальное время разработки приложения
составляет 60-90 дней, а при написании сотни тысяч строк
программного кода соблюсти такое ограничение практически
невозможно
• критически важным для реализации является высокий уровень
планирования и жесткая дисциплина проектирования, строгое
следование заранее разработанным протоколам и интерфейсам
• от приложения в определенной степени зависит безопасность
людей.

16.

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