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

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е

Быстрая разработка приложений ( 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 часто используются гибкие методы и Rational Unified Process .

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

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

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

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

См. Также [ править ]

  • Программирование на основе потоков
  • Платформы разработки low-code
  • Бережливая разработка программного обеспечения
  • Платформа как услуга

Ссылки [ править ]

  1. ^ Брукс, Фред (1986). Куглер, HJ (ред.). Сущность «серебряной пули» и случайности разработки программного обеспечения (PDF) . Обработка информации '86. Elsevier Science Publishers BV (Северная Голландия). ISBN 0-444-70077-3. Проверено 2 июля 2014 .
  2. ^ a b Бём, Барри (май 1988 г.). «Спиральная модель разработки программного обеспечения» (PDF) . Компьютер IEEE . DOI : 10,1109 / 2,59 . S2CID 1781829 . Архивировано 29 марта 2018 года из оригинального (PDF) . Проверено 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. ^ Эндрю Begel, Nachiappan Nagappan (сентябрь 2007). «Использование и восприятие гибкой разработки программного обеспечения в промышленном контексте: исследовательское исследование» (PDF) . Первый международный симпозиум по эмпирической инженерии программного обеспечения и измерениям (ESEM 2007) . С. 255–264. DOI : 10.1109 / esem.2007.12 . ISBN  978-0-7695-2886-1. S2CID  1941370 .
  12. ^ Максимилиан, EM; Уильямс, Л. (2003). «Оценка разработки через тестирование в IBM». 25-я Международная конференция по программной инженерии, 2003. Труды . С. 564–569. DOI : 10.1109 / icse.2003.1201238 . ISBN 0-7695-1877-X. S2CID  16919353 .
  13. ^ Стивенс, Мэтт; Розенберг, Дуг (2003). Рефакторинг экстремального программирования: аргументы против XP . DOI : 10.1007 / 978-1-4302-0810-5 . ISBN 978-1-59059-096-6. S2CID  29042153 .

Дальнейшее чтение [ править ]

  • Стив МакКоннелл (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: за рамками шумихи о том, как на самом деле работает RAD » Тенденции разработки приложений
  • Кен Швабер (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): умный, быстрый и эффективный процесс для разработчиков программного обеспечения»