Модель быстрой разработки приложений RAD (Rapid Application Development)
Благодаря методу RAD пользователь задействован на всех фазах жизненного цикла разработки проекта – не только при определении требований, но и при проектировании, разработке, тестировании, а также конечной поставке программного продукта. Это обеспечивается наличием средств разработки графического пользовательского интерфейса и кодогенераторов. Такие инструментальные средства, как Oracle Designer/2000, JavaJbuilder 3, Linux, Visual C++, Visual Basic 6, SAS, и другие можно использовать в качестве средств для быстрой разработки приложений. Характерной чертой RAD является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком. Факторы, позволяющие создать систему за 60 дней, причем без ущерба качеству, включают в себя использование мощных инструментальных средств разработки, высокий уровень фактора повторного использования, а также осмысленные и выделенные ресурсы.
Фазы модели RAD
Модель RAD проходит через следующие фазы: ∙ этап планирования требований — сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач; ∙ пользовательское описание — совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации; ∙ фаза конструирования («до полного завершения») — эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств; ∙ перевод на новую систему эксплуатации — эта фаза включает проведение пользователями приемочных испытаний, установку системы и обучение пользователей.
Преимущества модели RAD
При использовании модели RAD относительно проекта, для которого она в достаточной степени приемлема, проявляются следующие преимущества: ∙ время цикла разработки сокращается благодаря использованию мощных инструментальных средств; ∙ требуется меньшее количество специалистов (поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области); ∙ существует возможность произвести быстрый изначальный просмотр продукта; ∙ уменьшаются затраты (благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков); ∙ благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика; ∙ обеспечивается эффективное использование имеющихся в наличии средств и структур; ∙ постоянное присутствие заказчика сводит до минимума риск неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям и надёжность программного продукта в эксплуатации; ∙ в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий); ∙ интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем; ∙ основное внимание переносится с документации на код, причем при этом справедлив принцип «получаете то, что видите» (What you see is what you get, WYSIWYG); ∙ в модели используются следующие принципы и инструментальные средства моделирования: деловое моделирование (методы передачи информации, место генерирования информационных потоков, кем и куда направляется, каким образом обрабатывается); моделирование данных (происходит идентификация объектов данных и атрибутов, а также взаимосвязей); моделирование процесса (выполняется
преобразование объектов данных); генерирование приложения (методы четвертого поколения); ∙ повторное использование компонент уже существующих программ.
Недостатки модели RAD
Если эта модель применяется для проекта, для которого она не подходит в полной мере, могут сказываться следующие недостатки: ∙ Непостоянное участие пользователя может негативно сказаться на конечном продукте (т.е. если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте); ∙ при использовании этой модели необходимо достаточное количество высококвалифицированных разработчиков, (умеющих воспользоваться выбранными инструментальными средствами разработки для ускорения времени разработки); ∙ использование модели может оказаться неудачным в случае отсутствия пригодных для повторного использования компонент; ∙ могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами; ∙ возникает потребность в системе, которая может быть смоделирована корректным образом; ∙ для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений; ∙ для обеспечения быстрой реакции на информацию, поступающую в результате налаженной обратной связи с пользователем, необходим эффективный ускоренный процесс разработки. ∙ при использовании модели «вслепую» на затраты и дату завершения работы над проектом ограничения не накладываются; ∙ команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут «затянуть» разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом; ∙ существует риск, что работа над проектом никогда не будет завершена, – в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла;
Область применения модели RAD
Менеджер проекта может быть уверен в том, что модель RAD подходит для применения в конкретной ситуации в случае, если имеются в наличии некоторые из приведенных ниже условий-причин: ∙ в системах, которые поддаются моделированию (тех которые основаны на использовании компонентных объектов), а также в масштабируемых системах; ∙ в системах, требования для которых в достаточной мере хорошо известны; ∙ в случаях, когда конечный пользователь может принимать участие в процессе разработки на протяжении всего жизненного цикла; ∙ когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств; ∙ при невысокой степени технических рисков; ∙ при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки (как правило, не более, чем за 60 дней);
Что такое RAD-разработка
В статье о каскадной разработке мы рассказали о классической модели создания больших программ: там сначала долго собирают все требования, пишут ТЗ, а потом делают всю программу в строгом соответствии с этим ТЗ. Эта модель подходит для создания больших программных комплексов, но для стартапов и небольших команд работает плохо. В 1980-х годах сотрудник IBM Джеймс Мартин придумал другой подход. Вот о нём и поговорим.
Что такое RAD
RAD — это сокращение от rapid application development, «быстрая разработка приложений». В RAD мы идём маленькими итерациями, чтобы получить рабочий продукт за короткое время и в ограниченном бюджете. При этом мы договариваемся, что функциональность приложения может меняться в процессе разработки.
В основе RAD лежат три принципа:
- Высокая скорость — нам нужно получить результат как можно быстрее, например, чтобы новая версия вышла уже на следующей неделе.
- Низкая стоимость — у нас жёстко зафиксированный бюджет, который мы не можем превысить.
- Высокое качество — всё, что мы делаем, должно работать без ошибок. Но объём сделанного может быть меньше, чем изначально планировали.
Этапы разработки
Обычно RAD-разработка проходит по таким этапам:
Сбор требований. Собираем всю информацию от заказчика — о его бизнес-процессах, клиентах, задачах, требованиях к программе, какие нужно поддерживать операционные системы и оборудование, порядок обучения и вообще всё, что нужно для проекта. Это полноценный этап, который может занимать недели и месяцы. Тут никакого волшебства.
Итерация проектирования. Программисты быстро собирают прототип и рисуют к нему дизайн. Смысл этапа в том, чтобы как можно быстрее собрать кирпичик большой программы и довести его до рабочего состояния.
Итерация тестирования. Кирпичик отправляется клиенту и тестировщикам, чтобы они проверили работоспособность этого конкретного блока. Если находят ошибки — исправляем. Допиливаем кирпичик, пока он не будет работать как положено.
Итерация деплоя. В какой-то момент из кирпичиков собирается работоспособный продукт, который можно показывать пользователям. Приложение выкатывают и потом постепенно дополняют.
Так повторяется снова и снова — программисты делают новые кирпичики, пользователи их тестируют, и после тестов они остаются в программе. Так программа постепенно обрастает нужными возможностями, а пользователи дают обратную связь.
Зачем такая сложность
Смысл RAD-подхода в том, чтобы работать с живым продуктом и иметь возможность его переделать на лету. Это особенно нужно, когда выпускают пользовательские приложения — например игры, таск-менеджеры, всякие чаты и соцсети: мы ещё не знаем, как на них отреагирует рынок, поэтому нам нужно получать обратную связь от людей и заказчиков, а не уходить в свою мастерскую на год.
Плюсы и минусы RAD
✅ Можно выпускать программы при малом или гибком бюджете. Сегодня есть деньги на один модуль — пилят его. Завтра появились деньги ещё на три — пилят их. Потом деньги кончились — а модули работают, софтом можно пользоваться. Этой стратегией часто пользуются при создании MVP.
✅ Можно менять возможности программы. В отличие от каскадной разработки, когда всё жёстко зафиксировано на старте, в RAD заказчик в любой момент может сказать «А давайте поменяем вот эту возможность, у нас новые вводные».
❌ Плохо подходит для разработки больших программных комплексов, например для управления производством. В такие программы сложно вносить изменения на ходу, потому что работа одного модуля может повлиять на работу других.
❌ Заказчик должен постоянно участвовать в обсуждении и тестировании. Если заказчик хочет сразу увидеть готовую версию и не тратить время на промежуточные результаты, то команда не сможет проверять все прототипы на соответствие задачам заказчика.
Где применяется и кому подходит
Самое подходящее место для применения RAD — это стартапы и небольшие проекты. Для стартапов будет плюсом высокая скорость разработки и мгновенная обратная связь от пользователей, поэтому большинство новых проектов делается именно так. А в небольших проектах чаще всего важнее уложиться в бюджет, поэтому RAD здесь тоже будет кстати.
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.