Тема 5. Методология RAD (Rapid Application Development)

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

Процесс разработки программного обеспечения в соответствии с методологией RAD имеет следующие особенности:

1) команда разработчиков включает от двух до десяти человек;

2) планы работ тщательно прорабатываются и обычно составляют от двух до шести месяцев;

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

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

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

1) фаза анализа и планирования требований;

2) фаза проектирования;

3) фаза построения;

4) фаза внедрения.

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

Результатом первой фазы должен быть упорядоченный список функций будущей информационной системы, а также предварительная функциональная и информационная модели системы.

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

CASE-средства позволяют быстро получить прототипы информационной системы. Пользователь непосредственно взаимодействует с разработчиками, уточняет и дополняет требования к системе, которые не были выявлены на предыдущей фазе.

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

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

1) общая информационная модель системы;

2) функциональная модель системы в целом;

3) модели подсистем, реализуемых отдельными коллективами разработчиков;

4) определяемые с помощью CASE-средств интерфейсы между системами;

5) построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

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

Результатом построения является готовая система, удовлетворяющая всем требованиям.

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

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

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

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

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

Используя методологию RAD нельзя строить системы, от которых зависит безопасность людей, поскольку она предполагает интерактивный подход к разработке системы и первые несколько версий не будут полностью работоспособны.

Оценка размеров приложения в соответствии с методологией RAD осуществляется на основе функциональных элементов. Функциональный элемент программной системы – это файл, форма, отчет или сообщение. Размер приложения определяется следующим образом. Если в программной системе имеется до 1 тыс. программных элементов, то реализация системы может выполняться 1 человеком. Если от 1 до 4 тыс. программных элементов, то разработка выполняется командой от 2 до 10 человек. Если более 4 тыс. элементов, то разработка системы осуществляется несколькими командами, каждая из которых разрабатывает до 4 тыс. функциональных элементов.