RAD REALITIES: BEYOND THE HYPE TO HOW RAD REALLY WORKS

Нестабильная ситуация на рынке в 1990-х вместе с развитием новых технологий, таких как клиент-сервер, объектно-ориентированные технологии и растущее число различных средств разработки приложений превратили быструю разработку приложений (далее БРП, от англ. RAD – rapid application development) в настоящий тренд. БРП описывалась как совокупность средств разработки, методологий и подходов к разработке приложений, непрерывно связанная с прототипированием и технологией совместной разработки приложений (далее СРП, от англ. JAD – joint application design), которая предполагает участие потребителя в разработке.

Первая реализация технологии принадлежит Скотту Шульцу, который использовал средства кодогенарации вместе с новыми технологиями разработки, что, в итоге, привело к созданию методологии разработки, получившей название быстрого итеративного создания прототипа (от англ. rapid iterative production prototyping).

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

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

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

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

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

Определение фрагментов и порядка их выполнения производятся в фазе планирования в рамках техники разработки БРП. Каждый отдельный фрагмент не является обособленной от других фрагментов задачей и тесно связан с ними. Для определения зависимостей между фрагментами необходимо тщательно продумать на этапе планирования.

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

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

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

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

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