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

Rapid application development
"Инструмент RAD" и "Инструмент быстрой разработки приложений" перенаправляются сюда. Для разработки, ориентированной на создание графических пользовательских интерфейсов, см. построитель графического пользовательского интерфейса.

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ Брукс, Фред (1986). Куглер, Х.Дж. (ред.). Суть без серебряной пули и случайности разработки программного обеспечения (PDF). Обработка информации '86. Elsevier Science Publishers B.V (Северная Голландия). ISBN 0-444-70077-3. Получено 2 июля 2014.
  2. ^ а б Бем, Барри (май 1988 г.). «Спиральная модель разработки программного обеспечения» (PDF). IEEE Computer. Дои:10.1109/2.59. Архивировано из оригинал (PDF) 29 марта 2018 г.. Получено 1 июля 2014.
  3. ^ Керр, Джеймс М .; Хантер, Ричард (1993). Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше. Макгроу-Хилл. ISBN 0-07-034223-7.
  4. ^ Друкер, Питер (3 ноября 2009 г.). Посткапиталистическое общество. Электронные книги Харпера Коллинза. ISBN 978-0887306204.
  5. ^ Мартин, Джеймс (1991). Быстрая разработка приложений. Макмиллан. ISBN 0-02-376775-8.
  6. ^ https://www.technobuzz.tech/2020/10/android.html
  7. ^ Мартин, Джеймс (1991). Быстрая разработка приложений. Макмиллан. стр.81–90. ISBN 0-02-376775-8.
  8. ^ «Распад AD: снова собираем вместе» (PDF). gartner.com.br. Получено 13 апреля 2010.
  9. ^ Бек, Кент (2000). Объяснение экстремального программирования. Эддисон Уэсли. стр.3–7. ISBN 0201616416.
  10. ^ Гербер, Аурона; Ван дер Мерве, Альта; Альбертс, Ронелл (16–18 ноября 2007 г.). «Практическое значение методологий быстрой разработки». Материалы образовательной конференции по компьютерным наукам и информационным технологиям, CSITEd-2007. Конференция по компьютерным наукам и ИТ-образованию. Маврикий. С. 233–245. CiteSeerX 10.1.1.100.645. ISBN 978-99903-87-47-6.
  11. ^ Эндрю Бегель, Nachiappan Nagappan (сентябрь 2007 г.). «Использование и восприятие гибкой разработки программного обеспечения в промышленном контексте: исследовательское исследование» (PDF). Дои:10.1109 / esem.2007.12. Цитировать журнал требует | журнал = (помощь)
  12. ^ Maximilien, E.M .; Уильямс, Л. (2003). «Оценка разработки через тестирование в IBM». 25-я Международная конференция по программной инженерии, 2003 г. Труды. С. 564–569. Дои:10.1109 / icse.2003.1201238. ISBN 0-7695-1877-X.
  13. ^ Стивенс, Мэтт; Розенберг, Дуг (2003). Реорганизация экстремального программирования: аргументы против XP. Дои:10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6.

дальнейшее чтение

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