28. Модель (точнее, методология) быстрой разработки приложений

От Андрея:

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

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

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

2. Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

3. Проект выполняется в условиях ограниченности бюджета. Разработка ведётся небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.

4. Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причём достаточно скоро после начала проекта.

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

6. Низкая вычислительная сложность ПО.

RAD-технология не является универсальной, то есть её применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объём пользовательского интерфейса невелик.

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.

• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.

• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.

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

• Тестирование: тестируются новые компоненты и интерфейсы.

Другими словами, методология быстрой разработки – это разработка с использованием средств генерации кода по UML схемам или с помощью визуального программирования (как в Delphi, например).

Из презентации Кравченко:

Этапы:

Преимущества методологии RAD:

• применение мощных инструментальных средств позволя­ет сократить время цикла разработки всего проекта;

• создание системы выполняется коллективом, знающим процессы предметной области;

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

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

• сведение к минимуму риска того, что система не будет удовлетворять требованиям предметной области;

• основное внимание уделяется не документации, а кодированию (программированию), при этом поддерживается прин­цип «получаете то, что видите» (What you see is what you get, WYSIWYG);

• использование различных стандартных методологий моделирования

Недостатки:

• низкое качество программного продукта, если заказчики не могут принимать активное участие в процессе создания системы на протяжении всего ЖЦ;

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

• необходимость наличия готовых компонентов проектируемой системы до начала проекта

Области применения методологии RAD:

• для систем, которые поддаются моделированию и основаны на использовании компонентных объектов;

• для систем, требования к которым хорошо известны;

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

• проект имеет сокращенные сроки выполнения (не более 60 дней);

• для систем, в которых функционал реализуется в виде последовательных действий;

• для систем, предназначенных для концептуальной проверки возможностей и эффективности автоматизации;

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

• когда затраты и соблюдение графика не являются самыми важными критериями процесса создания системы (например, при разработке внутренних инструментальных средств);

• при невысокой степени технических рисков;

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