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

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

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

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

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

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

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

3) создание — детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику;

4) сопровождение — приемочные испытания, установка ПП и обучение пользователей.

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

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

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

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

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

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

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

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

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

Спиральная модель

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

Схема этой модели имеет вид:

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

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

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

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

Спиральная модель обладает следующими достоинствами:

1) заказчик имеет возможность увидеть разрабатываемый ПП на ранних стадиях разработки;

2) заказчики принимают активное участие в разработке ПП;

3) в модели воплощены преимущества каскадной и многопроходной моделей.

Недостатки спиральной модели:

1) усложненная структура;

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

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

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

Использование спиральной модели целесообразно, если существует хотя бы одна из следующих причин:

1) целесообразно создание прототипа;

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

3) требуется выполнять проекты со средней и высокой степенями риска;

4) заказчики не уверены в своих потребностях; требования слишком сложные; проект очень большой.