Понимание модели быстрой разработки приложений

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

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

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

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

Как мы объясняли ранее, RAD не работает в негибких контекстах. Не применяется в следующих ситуациях:

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

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

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

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

Этапы и методология

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

Планирование требований

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

Пользовательский дизайн

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

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

Строительство

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

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

Переключение

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

Быстрая разработка приложений против. Гибкий

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

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

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

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

Преимущества :

Снижение расходов и опасностей

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

Превосходное качество

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

Недостатки:

Плохой дизайн

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

Неспособность эффективно масштабироваться

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

Обязательства клиентов на заднем конце

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

Неспособность осуществлять контроль

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

Инструменты для быстрой разработки приложений (RAD)

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

Дизайн и прототипирование

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

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

Разработка

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

Консультационные компании, такие как Gartner и Forrester, постоянно разрабатывают новую номенклатуру, чтобы дифференцировать каждую из этих платформ. Часто включает следующее: платформы приложений с малым/без кода (LCAP), высокопроизводительные платформы приложений как услуга (HPAPaaS) и многофункциональные платформы разработки. Все это примеры различных типов платформ приложений (MXDP), которые вы можете использовать. Однако, в конце концов, каждый из них может быть классифицирован в соответствии с предполагаемой аудиторией.

Платформы с малым кодом/без кода

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

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

Embarcadero RAD Studio, ранее называвшаяся Borland Delphi, является одним из пионеров отрасли. Они хорошо известны своим визуальным дизайном пользовательского интерфейса. Borland Delphi было ее последним названием. Это было еще до появления Интернета, и его все еще можно использовать для приложений на настольных компьютерах и мобильных устройствах.

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

Вывод

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

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

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