Методология быстрой разработки приложений rad применяется при разработке

Что такое RAD-разработка

В статье о каскадной разработке мы рассказали о классической модели создания больших программ: там сначала долго собирают все требования, пишут ТЗ, а потом делают всю программу в строгом соответствии с этим ТЗ. Эта модель подходит для создания больших программных комплексов, но для стартапов и небольших команд работает плохо. В 1980-х годах сотрудник IBM Джеймс Мартин придумал другой подход. Вот о нём и поговорим.

Что такое RAD

RAD — это сокращение от rapid application development, «быстрая разработка приложений». В RAD мы идём маленькими итерациями, чтобы получить рабочий продукт за короткое время и в ограниченном бюджете. При этом мы договариваемся, что функциональность приложения может меняться в процессе разработки.

В основе RAD лежат три принципа:

1. Высокая скорость — нам нужно получить результат как можно быстрее, например, чтобы новая версия вышла уже на следующей неделе.
2. Низкая стоимость — у нас жёстко зафиксированный бюджет, который мы не можем превысить.
3. Высокое качество — всё, что мы делаем, должно работать без ошибок. Но объём сделанного может быть меньше, чем изначально планировали.

Этапы разработки

Обычно RAD-разработка проходит по таким этапам:

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

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

Итерация тестирования. Кирпичик отправляется клиенту и тестировщикам, чтобы они проверили работоспособность этого конкретного блока. Если находят ошибки — исправляем. Допиливаем кирпичик, пока он не будет работать как положено.

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

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

Зачем такая сложность

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

Плюсы и минусы RAD

✅ Можно выпускать программы при малом или гибком бюджете. Сегодня есть деньги на один модуль — пилят его. Завтра появились деньги ещё на три — пилят их. Потом деньги кончились — а модули работают, софтом можно пользоваться. Этой стратегией часто пользуются при создании MVP.

✅ Можно менять возможности программы. В отличие от каскадной разработки, когда всё жёстко зафиксировано на старте, в RAD заказчик в любой момент может сказать «А давайте поменяем вот эту возможность, у нас новые вводные».

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

❌ Заказчик должен постоянно участвовать в обсуждении и тестировании. Если заказчик хочет сразу увидеть готовую версию и не тратить время на промежуточные результаты, то команда не сможет проверять все прототипы на соответствие задачам заказчика.

Где применяется и кому подходит

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

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

Источник

9.4.2.Методология rad — Rapid Application Development

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

Основные особенности методологии RAD

Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки прило­жений — RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.

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

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

• небольшой команде программистов (обычно от 2 до 10 человек);
• тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);
• итерационная модель разработки, основанная на тесном взаимодействии с за­казчиком — по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.

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

• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.

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

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

• определяется необходимость распределения данных;
• производится анализ использования данных;
• производится физическое проектирование базы данных;
• определяются требования к аппаратным ресурсам;
• определяются способы увеличения производительности;
• завершается разработка документации проекта.

Источник