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

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

В своей основе Rapid Application Development имеет три ключевых принципа:

Высокая скорость.

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

Низкая стоимость.

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

Высокое качество.

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

В целом, данные требования звучат достаточно фантастично, как раз так, как не любят разработчики. Но данный метод до сих пор используется в компаниях ещё с конца 1980-х годов, когда его создал Барри Боэм. Он назвал данный подход «спиральной моделью». Каждый из завитков которой разбит на 4 сектора в соответствии с фрагментом разработки или версией программного обеспечения. В процессе движения по спирали происходит уточнение целей и спецификации проекта, что приводит к возможности выбора обоснованного варианта.

Развитие концепции Rapid Application Development не стояло на месте. Над ней работали и в 80-х и 90-х годах ХХ века. Например, когда речь идет о высоком качестве продукта, заказчики и разработчики видят это по–разному. Поэтому Джеймс Мартин и его последователи дополнили принципы RAD:

Минимизация временных затрат.

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

Прототипирование.

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

Цикличность.

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

Сотрудничество.

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

Итерации.

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

Комбинирование.

Разработка совмещается с тестированием. Это необходимо не только для ускорения процесса работы над проектом, но и для постоянного контроля качества кода. Благодаря этому удается добиться высокого качества продукта за короткие сроки.

Данные принципы действуют на всех этапах жизненного цикла разработки проекта.

В каких случаях команда может использовать методологию RAD?

• Когда проект требует простого кода, который можно быстро написать.

• При наличии четкого понимания приоритетов в разработке.

• Приложение нужно разработать в ограниченные сроки времени.

• На проект выделен ограниченный бюджет, который нельзя превышать.

• Главным критерием оценки является интерфейс для пользователей.

• Проект можно разбить на функциональные компоненты.

Для каких проектов RAD не подойдет?

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

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

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

Независимо от подхода, любая разработка делится на логические этапы, в рамках которых выполняется определенный набор задач. Шаги Rapid Application Development не сильно отличаются от остальных методов, но мы все–равно их обозначим, чтобы понять логику данной концепции.

Планирование и сбор требований к продукту.

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

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

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

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

Проектирование.

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

Кроме того, к процессу разработки могут привлекаться пользователи. Они под руководством программистов принимают участие в техническом проектировании системы. Для этого используется комбинация техник JAD и инструментов CASE.

JAD (Joint Application Development, Разработка совместного приложения) – это процесс разработки, в котором IT–специалисты вступают в эффективное взаимодействие с заказчиком, чтобы достичь целей проекта. То есть клиент предоставляет команде разработчиков все необходимые средства и ресурсы, чтобы создать приложение. Он содействует в понимании целей, помогает находить возможности для эффективной реализации проекта.

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

Итогами этого этапа является:

• Информационная модель проекта.

• Функциональные модели компонентов системы.

• Прототипы интерфейсов.

Построение.

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

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

Внедрение или деплой.

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

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

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

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

Чтобы понять, стоит ли браться за краткосрочные проекты по системе Rapid Application Development, рассмотрим достоинства и недостатки данного метода разработки.

Достоинства Rapid Application Development.

Высокий уровень качества продукта.

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

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

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

Наличие инструментов с функциями автоматизации позволяет не только оптимизировать разработку, но и проверять качество кода без участия тестировщиков.

Контроль рисков.

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

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

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

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

Больший объем работы за одну единицу времени.

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

Rapid Application Development использует инкрементную модель разработки, то есть когда продукт делится на относительно независимые друг от друга модули. Их разработка и внедрение происходит постепенно. Это позволяет снизить риск возникновения критических ошибок.

Теперь рассмотрим недостатки RAD.

Сложности во внедрении.

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

Требуется постоянное участие пользователей.

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

Сниженный уровень контроля.

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

Ограниченность дизайна.

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

Невозможность применения для крупных проектов.

Заказчики были бы этому рады, но это скорее из области фантастики. Команда, конечно, может сойти с ума и взяться за большой объем работы за небольшие деньги, но качество точно не будет соответствовать. Либо разработчики отойдут в мир иной из–за графика работы и отсутствия отдыха. Но это неоправданные жертвы.

Нередко при выборе метода разработки сравнивают между собой различные подходы. Сравнивать Rapid Application Development с традиционными методами было бы слишком очевидно, поэтому мы проведем сравнение с гибкой методологией Agile. Этот подход с каждым годом все больше набирает популярность, поэтому заслуживает внимания ничуть не меньше.

Различия между RAD и Agile заключаются в следующем:

Управление проектами.

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

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

Обратная связь с пользователями.

• Agile подразумевает участие пользователей на протяжении всего цикла разработки. Требования и ожидания заказчика являются основой для проекта.

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

Скорость разработки.

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

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

Основные принципы.

• Agile имеет собственные принципы, описанные в его Манифесте. В приоритет ставится постоянное сотрудничество, высокий уровень адаптивности и постоянное улучшение продукта.

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