Учебно-исследовательская лаборатория "Математические и программные технологии для современных компьютерных систем (Информационные технологии)" Обзор моделей жизненного цикла разработки программного обеспечения

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

Фазы модели RAD

• 
  этап планирования требований — сбор требований выполняется при использо­вании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный ана­лиз и обсуждение имеющихся коммерческих задач;
  
• 
  пользовательское описание — совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные сред­ства, обеспечивающие сбор пользовательской информации;
  
• 
  фаза конструирования ("до полного завершения") — эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генера­торов кода, экранных генераторов и других типов производственных инстру­ментальных средств;
  
• 
  перевод на новую систему эксплуатации — эта фаза включает проведение пользо­вателями приемочных испытаний, установку системы и обучение пользователей.
  

Преимущества модели RAD

• 
  время цикла разработки сокращается благодаря использо­ванию мощных инструментальных средств;
  
• 
  требуется меньшее количество специалистов (поскольку разработка системы вы­полняется усилиями команды, осведомленной в предметной области);
  
• 
  существует возможность произвести быстрый изначальный просмотр продукта;
  
• 
  умень­шаются затраты (благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков);
  
• 
  благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;
  
• 
  обеспечивается эффективное использование имеющихся в наличии средств и структур;
  
• 
  постоянное присутствие заказчика сводит до минимума риск неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям и надёжность программного продукта в эксплуатации;
  
• 
  в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);
  
• 
  интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем;
  
• 
  основное внимание переносится с документации на код, причем при этом справед­лив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);
  
• 
  в модели используются следующие принципы и инструментальные средства моделиро­вания: деловое моделирование (методы передачи информации, место генерирования информационных потоков, кем и куда направляется, каким образом обрабатывается); моделирование данных (происходит идентификация объектов данных и атрибутов, а также взаимосвязей); моделирование процесса (выполняется преобразование объек­тов данных); генерирование приложения (методы четвертого поколения);
  
• 
  повторное использование компонент уже существующих программ.
  

Недостатки модели RAD

• 
  Непостоянное участие пользователя может негативно сказаться на конечном продукте (т.е. если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конеч­ном продукте);
  
• 
  при использовании этой модели необходимо достаточное количество высоко­квалифицированных разработчиков, (умеющих воспользо­ваться выбранными инструментальными средствами разработки для ускорения времени разработки);
  
• 
  использование модели может оказаться неудачным в случае отсутствия пригодных для повторного использования компонент;
  
• 
  могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами;
  
• 
  возникает потребность в системе, которая может быть смоделирована корректным образом;
  
• 
  для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений;
  
• 
  для обеспечения быстрой реакции на информацию, поступающую в результате на­лаженной обратной связи с пользователем, необходим эффективный ускоренный процесс разработки.
  
• 
  при использовании модели "вслепую" на затраты и дату завершения работы над проектом ограничения не накладываются;
  
• 
  команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут "затянуть" разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом;
  
• 
  существует риск, что работа над проектом никогда не будет завершена, – в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла;
  

Область применения модели RAD

• 
  в системах, которые поддаются моделированию (тех которые основаны на использовании компонентных объектов), а также в масштабируемых системах;
  
• 
  в системах, требования для которых в достаточной мере хорошо известны;
  
• 
  в случаях, когда конечный пользователь может принимать участие в процессе раз­работки на протяжении всего жизненного цикла;
  
• 
  когда пользователи хотят принимать активное участие в использовании автомати­ческих инструментальных средств;
  
• 
  при невысокой степени технических рисков;
  
• 
  при выполнении проектов, разработка которых должна быть выполнена в сокра­щенные сроки (как правило, не более, чем за 60 дней);
  
• 
  в системах, которые можно поместить во временной блок с целью обеспечения функциональных возможностей на последовательной основе;
  
• 
  когда пригодные к повторному использованию части можно получить из автома­тических хранилищ программных продуктов;
  
• 
  в системах, которые предназначены для концептуальной проверки, являются не­критическими или имеют небольшой размер;
  
• 
  когда затраты и соблюдение графика не являются самым важным вопросом (например при разработке внутренних инструментальных средств);
  
• 
  в информационных системах;