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

Еще одним примером реализации итерационной модели разработки программного обеспечения является способ так называемой «быстрой разработки приложений» — RAD (Rapid Application Development), который появился в конце 1980;х годов. Первым формальным названием этой модели было R1PP (Rapid Iterative Production Prototyping), означающее быстрое итеративное создание прототипов. Как следует из названия метода RAD, он предполагает быструю поставку системных решений.

Технология RAD основана на следующих принципах:

• • использование эволюционного прототипирования. Эволюционный прототип системы сохраняется после окончательного выявления требований и используется для создания конечного программного продукта;
• • применение CASE-средств с возможностями генерации программ и циклической разработкой с переходом от проектных моделей к программе и обратно;
• • ведение разработки немногочисленной высокопрофессиональной командой, члены которой имеют опыт в проектировании, программировании, тестировании ПО и владеющие развитыми инструментальными средствами;
• • применение «временных блоков» для строгого ограничения итераций, чтобы обеспечить контроль над созданием прототипа. Этот подход препятствует «расползанию рамок проекта»; если проект затягивается, то рамки решения сужаются, чтобы завершить проект своевременно;
• • интеграция с современным методом выявления требований JAD (Joint Application Development — совместная разработка приложений), состоящего в регулярном проведении семинаров с привлечением всех участников проекта (заказчиков и разработчиков).

Жизненный цикл программного обеспечения в соответствии с подходом RAD состоит из четырех этапов:

• • анализ и планирование требований;
• • проектирование;
• • реализация;
• • внедрение.

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

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

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

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

Это упрощает разработку интерфейса и уменьшает затраты на прототипирование системы.

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

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

Модель динамической разработки Модель динамической разработки систем DSDM (Dynamic System Development Method) отражает процесс, который представляют как «контур элементов управления для быстрой разработки приложений», не предписывающий использование конкретных методов. Метод DSDM был разработан в 1994 году консорциумом британских пользовательских организаций.

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

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

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

Рис. 2.6. Модель процесса динамической разработки систем DSDM.

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

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

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

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

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

Метод DSDM предлагает следующую классификацию моделей.

• • Коммерческие прототипы.
• • Прототипы возможностей/прототипы проекта.
• • Прототипы производительности.
• • Прототипы применимости.

Здесь отражено разделение итераций проектирования и реализации функциональных требований в жизненном цикле метода DSDM и его несовместимость с более целостными объектноориентированными подходами.

В заключение обзора моделей процесса обобщим значение их эволюции для программной инженерии.

В 1950;х годах, на первом этапе развития вычислительной техники программы разрабатывались методом «ad hoc» (специально для данного случая), и каждая программная система была уникальным, индивидуально созданным интеллектуальным продуктом.

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

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

Последующие этапы совершенствования процесса разработки программного обеспечения характеризуются разработками технологий и методов, которые являются результатом рационального сочетания усовершенствованных моделей каскадной и итерационной разработки. Самыми известными вариантами таких технологий являются RUP (Rational Unified Process), MSF (Microsoft Solution Framework) и XP (Extreme Programming).