Разработка программного обеспечения

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

Рис. 5.4. V -образная модель жизненного цикла разработки ПО.

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

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

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

При использовании V-образной модели при реализации проекта, для которого она в достаточной мере подходит, обеспечивается несколько преимуществ:

· модель проста в использовании (относительно проекта, для которого она является приемлемой);

· в модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки;

· в модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;

· в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО -- перед разработкой компонентов;

· модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию;

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

В то же время при использовании V-образной модели в проектах, для которых она не является в достаточной степени приемлемой, становятся очевидными ее недостатки:

· с ее помощью непросто справиться с параллельными событиями;

· в ней не учтены итерации между фазами;

· в модели не предусмотрено внесение динамических изменений на разных этапах жизненного цикла;

· тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта;

· в модель не входят действия, направленные на анализ рисков.

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

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

5. Упрощенный процесс системного проектирования

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

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

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

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

Сначала схема системного проектирования может показаться подходящим способом разработки больших программных систем. Многие ее этапы применимы к разработке программного обеспечения:

· сбор и анализ требований;

· разработка архитектуры (определение и составление спецификаций систем);

· разработка подсистем;

· интеграция и проверка.

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

1. Классическое системное проектирование определяется документацией.

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

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

2. Интеграция является конечной, а не пошаговой операцией.

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

3. Одним из основных недостатков схемы системного проектирования являются ее часто сложные и противоречивые взаимосвязи между генеральным подрядчиком и субподрядчиками. Вместо того чтобы объединить свои усилия и направить их на получение хорошего проекта, генеральный подрядчик и субподрядчики разделяют свои обязанности по контракту. Субподрядчики отвечают за удовлетворение требований к подсистеме и не несут ответственности за то, чтобы целая система работала соответствующим образом. Некорректные спецификации являются проблемой генерального подрядчика. Неоднозначность спецификаций дает повод для того, чтобы искать виновных и перекладывать на них ответственность за неудачную разработку. Когда дела идут не так как нужно, генеральный подрядчик ждет, когда подсистема будет поставлена; субподрядчик ждет выделения средств на доработку подсистемы, вызванную некорректными спецификациями. Любое изменение требований или проекта является поводом для пересмотра условий контракта. А интеграция на завершающем этапе работ только усугубляет проблему. Расхождения могут быть не выявлены до тех пор, пока не будет потрачена большая часть средств.

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

6. Эволюционные и инкрементные модели жизненного цикла ПО

Уже десятки лет тому назад в своей книге «Мифический человеко-месяц» Фредерик Брукс писал: «В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы.

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

Следовательно, вопрос менеджмента заключается не в том, создавать или нет экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и сделаете. Единственный вопрос в том, нужно ли планировать создание продукта одноразового использования заранее или обещать поставить его заказчикам...»

В своей боле поздней работе под названием "No Silver Bullet, the Essence and Accidents of Programming" Брукс указывает на то, что большинство ошибок, возникающих при разработке ПО, все же связаны с неправильным пониманием концепции системы, а не с синтаксисом или логикой. Он подчеркивает положительный момент в применении методов быстрого прототипирования: «Самой тяжелой составляющей процесса построения программной системы является принятие однозначного решения о том, что именно необходимо построить. Ни одна из остальных составляющих работы над концепцией не представляет собой такую трудность, как определение детальных технических требований, включая все аспекты соприкосновения продукта с людьми, машинами и другими программными системами. Ни одна другая составляющая работы в такой степени не наносит ущерб полученной в результате системе, если она выполнена неправильно. Именно эту составляющую процесса разработки тяжелее всего исправить на более поздних этапах.

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

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

Уоттс Хэмфри (WattsHumphrey), который известен как вдохновитель создания модели СММ, разработанной Институтом SEI, поддерживает Брукса в его подходе к важности требований и их разработки: «В большинстве систем заключен основной принцип, который включает в себя больше, чем незначительное эволюционное изменение. Система может изменить само эксплуатационное окружение. Поскольку пользователи могут рассуждать о том или ином явлении только в рамках известного им окружения, требования к таким системам всегда формулируются в рамках текущего окружения. Следовательно, эти требования непременно будут неполными, неточными и обманчивыми. Главной задачей для системного разработчика является изобретение процесса разработки, с помощью которого можно будет обнаружить, определить и разработать реальные требования. Этого можно достичь только при максимальном включении пользователя в процесс разработки и зачастую с помощью периодического тестирования прототипов или версий, полученных на ранних этапах разработки. Оказывается, что такие процессы всегда занимают больше времени, но неизменно в конце приводят к разработке лучшей системы намного быстрее, чем при использовании какой-либо другой стратегии».

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

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

7. Модель прототипирования жизненного цикла разработки ПО

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

Бернард Боар (BernardBoar) определил прототипирование как «метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конечной системы -- быстро и в требуемом контексте». Т.е. прототип-- это рабочая модель системы, которая используется для уточнения требований к ней. Относительно высокая скорость реализации проекта при использовании метода прототипирования обеспечивается за счет планирования работ и участия заказчика в процессе разработки.

Структурная эволюционная модель быстрого прототипирования представлена на рис. 5.6.

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

Рис. 5.6. Структурная эволюционная модель быстрого прототипирования.

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

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

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

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

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

· взаимодействие пользователя и/или заказчика с системой начинается на раннем этапе разработки;

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

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

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

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

· при использовании модели заказчикам демонстрируются постоянные, видимые признаки прогресса в реализации проекта, что дает им возможность чувствовать себя более уверенно;

· возможность возникновения разногласий при общении заказчиков с разработчиками минимизирована;

· возможность наблюдать ту или иную функцию в действии побуждает к разработке дополнительных функциональных возможностей;

· благодаря меньшему объему доработок уменьшаются совокупные затраты на разработку;

· обеспечивается управление рисками;

· документация сконцентрирована на конечном продукте, а не на процессе его разработки;

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

Недостатки структурной эволюционной модели быстрого прототипирования:

· модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о методе разработки «на скорую руку»;

· разработанные прототипы часто страдают от неадекватной или недостающей документации;

· если цели прототипирования не согласованы заранее, процесс может превратиться в упражнение по созданию хакерского кода;

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

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

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

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

· несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к необходимости создания другого пользовательского интерфейса;

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

· прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование -- устранение ошибок», что приводит к дорогостоящим и незапланированным итерациям;

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

· когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу;

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

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

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

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

Менеджер проекта может быть уверен в необходимости применения структурной эволюционной модели быстрого прототипирования, если:

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

· существует потребность в разработке пользовательских интерфейсов;

· нужна проверка концепции;

· осуществляются временные демонстрации;

· выполняется новая, не имеющая аналогов разработка (в отличие от эксплуатации продукта на уже существующей системе);

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

· алгоритмы или системные интерфейсы усложнены;

· требуется продемонстрировать техническую осуществимость, когда технический риск высок;

· при разработке ПО проявляется средняя и высокая степень риска.

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

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

8. Модель быстрой разработки приложений RAD (Rapid Application Development)

Разочарованные жесткостью водопадного метода, некоторые первопроходцы разработки программного обеспечения решили избрать другую крайность. Они сказали себе: «Давайте забудем об этих бесполезных требованиях и о документации проекта; она никогда не бывает правильной. Давайте просто создадим код». Для названия такого подхода иногда используют термин «совместная разработка прикладных систем» (свидетельствующий об участии потребителя в процессе разработки), или быстрая разработка прикладных систем (RAD -Rapid Application Development).

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

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

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

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

Возможность создания системы за 60 дней, причем без ущерба качеству, обеспечивается за счет использования мощных инструментальных средств разработки, высокого уровня повторного использования кода, а также осмысленных и выделенных ресурсов. В частности, подразумевается использование средств разработки графического пользовательского интерфейса и кодогенераторов. Такие инструментальные средства, как BorlandDelphi, BorlandC++ Builder, IBMLotus Domino Designer, Microsoft Visual Studio и другие.

Модель RAD проходит через следующие фазы (рис. 5.7):

· этап планирования требований -- сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Jointrequirementsplanning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

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

· фаза конструирования («до полного завершения») -- эта фаза объединяет в себе детальное проектирование, кодирование и тестирование, а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависят от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств;

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

Размещено на http://www.allbest.ru/

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

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

· время цикла разработки сокращается благодаря использованию мощных инструментальных средств;

· требуется меньшее количество специалистов (поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области);

· существует возможность произвести быстрый изначальный просмотр продукта;

· благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;

· обеспечивается эффективное использование имеющихся в наличии ресурсов;

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

· основное внимание переносится с документации на код, причем при этом справедлив принцип «получаете то, что видите» (Whatyouseeiswhatyouget, WYSIWYG);

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

В то же время, для проектов, для которых модель не подходит в полной мере, она не лишена недостатков:

· для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений;

· невозможность участия пользователей на протяжении всего жизненного цикла может негативно сказаться на конечном продукте;

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

· использование модели может оказаться неудачным в случае отсутствия пригодных для повторного использования компонентов;

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

Модель RAD подходит для использования в конкретном проекте в том случае, если ее применение обусловлено следующими причинами:

· в системах, которые поддаются моделированию (тех которые основаны на использовании компонентных объектов), а также в масштабируемых системах;

· в системах, требования для которых в достаточной мере известны;

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

· при невысокой степени технических рисков;

· при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки (как правило, не более чем за 60 дней);

· когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;