Differences

This shows you the differences between two versions of the page.

--- mdd:rad_techics [2026/08/29 07:53] – Bulk sync migration user
+++ mdd:rad_techics [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== RAD REALITIES: BEYOND THE HYPE TO HOW RAD REALLY WORKS ======
+Нестабильная ситуация на рынке в 1990-х вместе с развитием новых технологий, таких как клиент-сервер, объектно-ориентированные технологии и растущее число различных средств разработки приложений превратили быструю разработку приложений (далее БРП, от англ. RAD – rapid application development) в настоящий тренд. БРП описывалась как совокупность средств разработки, методологий и подходов к разработке приложений, непрерывно связанная с прототипированием и технологией совместной разработки приложений (далее СРП, от англ. JAD – joint application design), которая предполагает участие потребителя в разработке.
+Первая реализация технологии принадлежит Скотту Шульцу, который использовал средства кодогенарации вместе с новыми технологиями разработки, что, в итоге, привело к созданию методологии разработки, получившей название быстрого итеративного создания прототипа (от англ. rapid iterative production prototyping).
+БРП представляет собой интегрированный набор методов, руководящих принципов и инструментов, которые облегчают создание программного обеспечения в короткие сроки. В отличие от традиционных методов разработки, где конечный продукт появляется в конце цикла разработки, БРП предполагает некоторую эволюцию продукта на протяжении нескольких циклов разработки, каждый из которых предполагает получение обратной связи (критики и различного рода замечаний) от пользователей.
+Продукт постепенно внедряется, совершенствуясь по ходу своей эволюции, а не предстает перед конечным потребителем сразу в своем окончательном виде. Наборы, состоящие из циклов моделирования, разработки, прототипирования, тестирования и внедрения приложения, представляются некоторыми отдельными процессами (фрагментами), которые могут быть как последовательными, так и иди в параллель друг с другом. Временной отрезок, ограничивающий один фрагмент, называется временной коробкой (от англ. timebox).
+Как правило, разработка приложения, использующая технику БРП, предполагает наличие небольшой команды настоящих профессионалов (включая представителей фокус-группы), ориентированной на выполнение циклов внедрения, а не шагов и отдельных задач, как в традиционной разработке приложений. Именно по этому, успешное внедрение приложения во многом зависит от навыков и способностей команды создавать приложения, удовлетворяющие потребности потребителя. Ключевыми моментами в процессе создания приложения является умение адаптироваться под изменяющиеся потребности бизнеса в весьма ограниченные сроки.
+Рассматриваемая технология разработки предполагает наличие целого набора шагов, объединенных в некоторую последовательность. Все начинается с определения понимания того, что должен представлять из себя требуемый продукт, и планирования (включая некоторый анализ данных и оценку возможных рисков) и разделения на временные коробки, которые могут продолжаться от одного до четырех месяцев. Грамотное определение временных коробок помогает команде сфокусироваться на требованиях потребителей и видеть текущее состояние рынка.
+Как правило, сроки определяются как командой разработчиков, так и членами опрашиваемой фокус-группы, чье наличие помогает не только определить наиболее важные запросы потребителей к продукту, но и максимально объективизировать взгляды на проект.
+Внутри каждой временной коробки так же происходит выявление подзадач в рамках фрагмента, которые могут идти как в последовательном порядке, так и выполняться параллельно.
+Определение фрагментов и порядка их выполнения производятся в фазе планирования в рамках техники разработки БРП. Каждый отдельный фрагмент не является обособленной от других фрагментов задачей и тесно связан с ними. Для определения зависимостей между фрагментами необходимо тщательно продумать на этапе планирования.
+Крепкая структура приложения основана на хорошо спроектированной модели данных, процессов или объектов. Традиционно, модель данных создается внутри команды разработчиков. В качестве альтернативы может выступать модель, «зашитая» в программных средствах, используемых при разработке приложения. Последние исследования показывают, что все чаще команды разработчиков начинают использовать готовые шаблонов моделей данных, который в той или иной степени могут быть адаптированы под конкретную задачу. Благодаря этому, экономится немало времени команды от создания своей модели с нуля.
+Важной составляющей разработки приложений с использованием БРП-техники являются различные программные средства. Помимо типичных используемых для разработки больших приложения вспомогательных программных средств, таких как средства создания графического пользовательского интерфейса, используются различные программные решения для работы с моделью данных, формирования документации и создания тестов и проч.
+На данный момент не существует стандартов, которые помогали бы оценивать качество работы рассматриваемой технологии разработки приложений. Одним из возможных подходов к такому оцениванию является анализ функциональных точек.
+% надежность этой методики разработки приложений не доказана, благодаря чему существует необходимость в тестировании текущей версии приложения на всем пути эволюционирования. В качестве одной из возможных метрик тестирования может выступать количество дефектов в рамках одного фрагмента разработки. Отслеживание дефектов как в рамках одного фрагмента, так и на протяжении всей разработки приложения помогает весьма эффективно организовывать процесс исправления недочетов приложения.
+Не смотря на то, что команда состоит из малого числа людей, далеко не все члены команды разработчиков могут отлично знать и разбираться в тех или иных используемых средствах разработки, методах, стандартах и методологиях, благодаря чему разделение «на роли» является необходимостью. Организация процесса разработки с использованием БРТ-техники требует исполнения сразу нескольких ролей от каждого члена команды. Так, например, один и тот же член команды может выполнять роли архитектора приложения и администратора данных.