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

редактировать

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

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

Содержание

1 История
2 Метод RAD Джеймса Мартина
3 Плюсы и минусы быстрой разработки приложений
4 См. Также
5 Ссылки
6 Дополнительная литература

История

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

Первая такая альтернатива RAD была разработана Барри Боем и была известна как спиральная модель. Бем и другие последующие подходы RAD делали упор на разработке прототипов, а также на строгих проектных спецификациях или вместо них. Прототипы имели несколько преимуществ по сравнению с традиционными спецификациями:

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

Начиная с идей Барри Боэма и других, Джеймса Мартина разработал подход к быстрой разработке приложений в 1980-х в IBM и, наконец, формализовал его, опубликовав в 1991 году книгу «Быстрая разработка приложений». Это привело к некоторой путанице в отношении термина RAD даже среди ИТ-специалистов. Важно различать RAD как общую альтернативу модели водопада и RAD как особый метод, созданный Мартином. Метод Мартина был адаптирован к наукоемким бизнес-системам с интенсивным пользовательским интерфейсом.

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

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

Метод Джеймса Мартина RAD

Фазы в подходе Джеймса Мартина к RAD

Подход Джеймса Мартина к RAD делит процесс на четыре отдельных этапа:

этап планирования требований - объединяет элементы этапов планирования системы и системного анализа систем Жизненный цикл разработки (SDLC). Пользователи, менеджеры и ИТ-специалисты обсуждают и согласовывают бизнес-потребности, объем проекта, ограничения и системные требования. Он заканчивается, когда команда соглашается по ключевым вопросам и получает разрешение руководства на продолжение работы.
Этап проектирования пользователя - на этом этапе пользователи взаимодействуют с системными аналитиками и разрабатывают модели и прототипы, которые представляют все системные процессы, входные данные и выходы. Группы или подгруппы RAD обычно используют комбинацию методов совместной разработки приложений (JAD) и инструментов CASE для преобразования потребностей пользователей в рабочие модели. Пользовательский дизайн - это непрерывный интерактивный процесс, который позволяет пользователям понимать, изменять и в конечном итоге утверждать рабочую модель системы, которая соответствует их потребностям.
Этап конструирования - фокусируется на задачах разработки программ и приложений, аналогичных SDLC. Однако в RAD пользователи продолжают участвовать и по-прежнему могут предлагать изменения или улучшения по мере разработки реальных экранов или отчетов. В его задачи входят программирование и разработка приложений, кодирование, интеграция модулей и тестирование системы.
Фаза переключения - напоминает финальные задачи фазы реализации SDLC, включая преобразование данных, тестирование, переход на новую систему и пользователя подготовка. По сравнению с традиционными методами, весь процесс сжат. В результате новая система создается, доставляется и вводится в эксплуатацию намного раньше.

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

В современных средах информационных технологий многие системы теперь построены с использованием некоторой степени Быстрая разработка приложений (не обязательно подход Джеймса Мартина). Помимо метода Мартина, для разработки RAD часто используются методы Agile и Rational Unified Process.

Предполагаемые преимущества RAD включают:

Лучшее качество. Благодаря взаимодействию пользователей с развивающимися прототипами бизнес-функциональность проекта RAD часто может быть намного выше, чем та, которая достигается с помощью каскадной модели. Программное обеспечение может быть более удобным в использовании и имеет больше шансов сосредоточиться на бизнес-проблемах, которые важны для конечных пользователей, а не на технических проблемах, представляющих интерес для разработчиков. Однако это исключает другие категории того, что обычно известно как нефункциональные требования (ограничения AKA или атрибуты качества), включая безопасность и переносимость.
Управление рисками. Хотя большая часть литературы по RAD фокусируется на скорости и вовлечении пользователя, важной особенностью RAD, выполненной правильно, является снижение рисков. Следует помнить, что Бем изначально охарактеризовал спиральную модель как подход, основанный на оценке риска. Подход RAD может на раннем этапе сосредоточиться на ключевых факторах риска и адаптироваться к ним на основе эмпирических данных, собранных на ранней стадии процесса. Например, сложность прототипирования некоторых из самых сложных частей системы.
Больше проектов выполнено вовремя и в рамках бюджета. Сосредоточение внимания на разработке дополнительных устройств снижает вероятность катастрофических отказов, которые препятствовали крупным проектам водопадов. В модели Waterfall обычно приходили к осознанию того, что после шести или более месяцев анализа и разработки требовалось радикальное переосмысление всей системы. С помощью RAD такая информация может быть обнаружена и обработана на более раннем этапе процесса.

К недостаткам RAD можно отнести:

Риск нового подхода. Для большинства ИТ-отделов RAD был новым подходом, который требовал от опытных профессионалов переосмысления своей работы. Люди практически всегда не любят изменений, и любой проект, предпринятый с использованием новых инструментов или методов, с большей вероятностью потерпит неудачу с первого раза просто из-за того, что команда должна учиться.
Недостаток внимания Не -функциональные требования, которые часто не видны конечному пользователю при нормальной работе.
Требуется время ограниченных ресурсов. Практически все подходы к RAD объединяет то, что на протяжении всего жизненного цикла существует гораздо больше взаимодействия между пользователями и разработчиками. В каскадной модели пользователи будут определять требования, а затем уходят, когда разработчики создают систему. В RAD пользователи участвуют с самого начала и практически на протяжении всего проекта. Для этого необходимо, чтобы бизнес был готов инвестировать время экспертов в области приложений. Парадокс заключается в том, что чем лучше эксперт, чем лучше они знакомы со своей областью, тем больше от них требуется для реального ведения бизнеса, и может быть трудно убедить своих руководителей вкладывать свое время. Без таких обязательств проекты RAD не будут успешными.
Меньше контроля. Одним из преимуществ RAD является то, что он обеспечивает гибкий адаптируемый процесс. В идеале уметь быстро адаптироваться как к проблемам, так и к возможностям. Между гибкостью и контролем неизбежен компромисс: больше одного означает меньше другого. Если в проекте (например, жизненно важное программное обеспечение ) значения контролируют больше, чем гибкость, RAD не подходит.
Плохой дизайн. В некоторых случаях акцент на прототипах может зайти слишком далеко, что приведет к методологии «взлома и тестирования», когда разработчики постоянно вносят незначительные изменения в отдельные компоненты и игнорируют проблемы системной архитектуры, что может привести к улучшению общего дизайна. Это может быть особенно проблемой для таких методологий, как Мартин, которые так сильно фокусируются на пользовательском интерфейсе системы.
Отсутствие масштабируемости. RAD обычно ориентирован на небольшие и средние проектные группы. Другие проблемы, упомянутые выше (меньшее проектирование и контроль), создают особые проблемы при использовании подхода RAD для очень крупномасштабных систем.

См. Также

Ссылки

Дополнительная литература

Стив МакКоннелл (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press Books, ISBN 978-1-55615-900-8
Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше. Макгроу-Хилл. ISBN 0-07-034223-7.
Эллен Готтесдинер (1995). "RAD Realities: Beyond the Hype to how RAD Really Works " Тенденции разработки приложений
Кен Швабер (1996). Гибкое управление проектами с помощью Scrum, Microsoft Press Books, ISBN 978-0-7356-1993-7
Стив МакКоннелл (2003). Профессиональная разработка программного обеспечения: более короткие графики, более качественные продукты, более успешные проекты, расширенная карьера, Addison-Wesley, ISBN 978-0-321-19367-4
Дин Леффингвелл ( 2007). Масштабирование гибкости программного обеспечения: передовой опыт для крупных предприятий, Addison-Wesley Professional, ISBN 978-0-321-45819-3
Скотт Стайнер (2016). Список Forbes: «Быстрая разработка приложений (RAD): умный, быстрый и эффективный процесс для разработчиков программного обеспечения»