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

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

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

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

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

1) Небольшую команду программистов.

2) Короткий, но тщательно проработанный рабочий график.

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

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

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

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

2) проектирование.

3) построение.

4) внедрение.

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

Определение требований осуществляется в основном самими пользователями под руководством специалистов-разработчиков.

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

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

Результатом данной фазы должны быть:

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

2) Функциональные модели системы и подсистемы, реализованные отдельными командами разработчиков.

3) Точно определенные с помощью case-средства интерфейс между автономно разработанной подсистемой.

4) Построение прототипов экранных отчетов диалогов.

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

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

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

Завершение физического проектирования системы:

· Определяется необходимость распределения данных;

· Производится анализ использованных данных;

· Производится физическое проектирование БД;

· Определяются требования к аппаратным ресурсам;

· Определяются способы увеличения производительности;

· Завершающая разработка документации проекта.

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

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

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

· Разрабатывается совершенно новая система;

· Уже было проведено обследование предприятия и существует модель его деятельности;

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

Но, не смотря на все перечисленное, методология RAD не может претендовать на универсальность. Она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Но эта методология не применима для построения сложных расчетных программ, ОС или программ управления космическим кораблем, т. е. программ, требующих написания большого объема уникального кода.