Быстрая разработка приложений
| Часть серии о |
| Разработка программного обеспечения |
|---|
Быстрая разработка приложений ( RAD ), также называемая быстрой разработкой приложений ( RAB ), является одновременно общим термином для адаптивных подходов к разработке программного обеспечения и названием Джеймса Мартина метода быстрой разработки . В целом, подходы RAD к разработке программного обеспечения уделяют меньше внимания планированию и больше внимания адаптивному процессу. Прототипы часто используются в дополнение к проектным спецификациям, а иногда даже вместо них.
RAD особенно хорошо подходит для (хотя и не ограничивается) разработки программного обеспечения , основанного на к пользовательскому интерфейсу требованиях . Конструкторы графического пользовательского интерфейса часто называют инструментами быстрой разработки приложений. Другие подходы к быстрой разработке включают адаптивную , гибкую , спиральную и унифицированную модели.
История [ править ]
Быстрая разработка приложений была ответом на каскадные процессы, основанные на планах, разработанные в 1970-х и 1980-х годах, такие как метод структурированного системного анализа и проектирования (SSADM). Одна из проблем этих методов заключается в том, что они основаны на традиционной инженерной модели, используемой для проектирования и строительства таких объектов, как мосты и здания. Программное обеспечение по своей сути представляет собой совершенно другой вид артефакта. Программное обеспечение может радикально изменить весь процесс решения проблемы. В результате знания, полученные в ходе самого процесса разработки, могут быть использованы для формирования требований и конструкции решения. [1] Подходы, основанные на плане, пытаются жестко определить требования, решение и план его реализации, а также имеют процесс, который препятствует изменениям. С другой стороны, подходы RAD признают, что разработка программного обеспечения — это наукоемкий процесс, и обеспечивают гибкие процессы, которые помогают использовать знания, полученные в ходе проекта, для улучшения или адаптации решения.
Первая подобная альтернатива RAD была разработана Барри Бёмом и была известна как спиральная модель . Бём и другие последующие подходы RAD делали акцент на разработке прототипов, а также или вместо строгих проектных спецификаций. Прототипы имели ряд преимуществ перед традиционными спецификациями:
- Сокращение рисков. Прототип может протестировать некоторые из наиболее сложных потенциальных частей системы на ранних этапах жизненного цикла . Это может предоставить ценную информацию о осуществимости проекта и помешать команде искать решения, реализация которых окажется слишком сложной или трудоемкой. Преимущество обнаружения проблем на более раннем этапе жизненного цикла, а не на более позднем этапе, было ключевым преимуществом подхода RAD. Чем раньше будет обнаружена проблема, тем дешевле обойдется ее устранение.
- Пользователи лучше умеют использовать и реагировать, чем создавать спецификации. В каскадной модели пользователь обычно подписывал ряд требований, но затем, когда ему представляли реализованную систему, он внезапно понимал, что данному проекту не хватает некоторых важных функций или он слишком сложен. В целом большинство пользователей дают гораздо более полезную обратную связь, когда они могут испытать прототип работающей системы, а не абстрактно определить, какой должна быть эта система.
- Прототипы можно использовать и превратить в законченный продукт. Один из подходов, используемый в некоторых методах RAD, заключался в построении системы в виде серии прототипов, которые развиваются от минимальной функциональности до умеренно полезной и заканчиваются окончательно завершенной системой. Преимущество этого, помимо двух вышеперечисленных преимуществ, заключалось в том, что пользователи могли получить полезные бизнес-функции гораздо раньше. [2]
Начав с идей Барри Боэма и других, Джеймс Мартин разработал подход быстрой разработки приложений в 1980-х годах в IBM и, наконец, формализовал его, опубликовав в 1991 году книгу Rapid Application Development . Это привело к некоторой путанице в отношении термина RAD даже среди ИТ-специалистов. Важно различать RAD как общую альтернативу водопадной модели и RAD как конкретный метод, созданный Мартином. Метод Мартина был адаптирован для бизнес-систем с интенсивным знанием и пользовательским интерфейсом.
Эти идеи получили дальнейшее развитие и усовершенствование такими пионерами RAD, как Джеймс Керр и Ричард Хантер, которые вместе написали основополагающую книгу на эту тему «Внутри RAD». [3] который рассказывает о путешествии менеджера проекта RAD, когда он разрабатывал и совершенствовал методологию RAD в реальном времени в реальном проекте RAD. Эти специалисты-практики и подобные им помогли RAD завоевать популярность в качестве альтернативы традиционным подходам к жизненному циклу системных проектов.
Подход RAD также получил развитие в период пикового интереса к реинжинирингу бизнеса . Идея реинжиниринга бизнес-процессов заключалась в радикальном переосмыслении основных бизнес-процессов, таких как продажи и поддержка клиентов, с учетом новых возможностей информационных технологий. RAD часто был важной частью более крупных программ реинжиниринга бизнеса. Подход RAD к быстрому прототипированию стал ключевым инструментом, помогавшим пользователям и аналитикам «мыслить нестандартно» об инновационных способах, с помощью которых технологии могут радикально переосмыслить основной бизнес-процесс. [4] [5]
Во многом доверие Джеймса Мартина к RAD было связано с подразделением информационной инженерии Dupont и его руководителем Скоттом Шульцем, а также их соответствующими отношениями с Джоном Андервудом, который возглавлял специализированную компанию по разработке RAD, которая инициировала множество успешных проектов RAD в Австралии и Гонконге.
Успешные проекты, среди которых ANZ Bank , Lend Lease , BHP , Coca-Cola Amatil, Alcan , Hong Kong Jockey Club и многие другие.
Успех, который привел к тому, что Скотт Шульц и Джеймс Мартин провели время в Австралии с Джоном Андервудом, чтобы понять методы и детали того, почему Австралия добилась непропорционально большого успеха в реализации важных для миссии проектов RAD.
Джеймса RAD Метод Мартина
Подход Джеймса Мартина к RAD делит этот процесс на четыре отдельных этапа:
- Фаза планирования требований – объединяет элементы фаз системного планирования и системного анализа жизненного цикла разработки систем (SDLC). Пользователи, менеджеры и ИТ-персонал обсуждают и согласовывают бизнес-потребности , масштаб проекта , ограничения и системные требования. Он заканчивается, когда команда согласовывает ключевые вопросы и получает разрешение руководства на продолжение.
- Этап пользовательского проектирования — на этом этапе пользователи взаимодействуют с системными аналитиками и разрабатывают модели и прототипы , которые представляют все системные процессы, входные и выходные данные . Группы или подгруппы RAD обычно используют комбинацию методов совместного проектирования приложений (JAD) и инструментов CASE для перевода потребностей пользователей в рабочие модели. Пользовательское проектирование — это непрерывный интерактивный процесс, который позволяет пользователям понимать, изменять и в конечном итоге утверждать рабочую модель системы, отвечающую их потребностям.
- Этап строительства – фокусируется на задачах разработки программ и приложений, аналогичных SDLC. Однако в RAD пользователи продолжают участвовать и по-прежнему могут предлагать изменения или улучшения по мере разработки реальных экранов или отчетов. В его задачи входит программирование и разработка приложений, кодирование , модульная интеграция и тестирование системы .
- Фаза перехода – напоминает заключительные задачи на этапе внедрения SDLC, включая преобразование данных, тестирование, переход на новую систему и обучение пользователей. По сравнению с традиционными методами, весь процесс сжат. В результате новая система будет построена, доставлена и введена в эксплуатацию гораздо быстрее. [6]
Преимущества [ править ]
В современных средах информационных технологий многие системы теперь создаются с использованием некоторой степени быстрой разработки приложений. [7] (не обязательно подход Джеймса Мартина). Помимо метода Мартина, гибкие методы и Rational Unified Process для разработки RAD часто используются .
К предполагаемым преимуществам RAD относятся:
- Лучше качество. Благодаря взаимодействию пользователей с развивающимися прототипами бизнес-функциональность проекта RAD часто может быть намного выше, чем при использовании водопадной модели. Программное обеспечение может быть более удобным в использовании и имеет больше шансов сосредоточиться на бизнес-проблемах, которые имеют решающее значение для конечных пользователей, а не на технических проблемах, представляющих интерес для разработчиков. Однако это исключает другие категории того, что обычно известно как нефункциональные требования (ограничения AKA или атрибуты качества), включая безопасность и переносимость .
- Контроль рисков. Хотя большая часть литературы по RAD сосредоточена на скорости и вовлечении пользователей, важнейшей особенностью правильно выполненной RAD является снижение рисков. Стоит вспомнить, что Бём изначально охарактеризовал спиральную модель как подход, основанный на риске. Подход RAD позволяет на ранних этапах сосредоточить внимание на ключевых факторах риска и адаптироваться к ним на основе эмпирических данных, собранных на ранней стадии процесса. Например, сложность прототипирования некоторых наиболее сложных частей системы.
- Больше проектов завершено вовремя и в рамках бюджета. Сосредоточив внимание на разработке дополнительных модулей, снижается вероятность катастрофических сбоев, которые преследуют крупные каскадные проекты. В модели «Водопад» после шести или более месяцев анализа и разработки обычно приходили к пониманию того, что требовалось радикальное переосмысление всей системы. С помощью RAD такую информацию можно обнаружить и принять меры на более раннем этапе процесса. [2] [8]
Недостатки [ править ]
К предполагаемым недостаткам RAD относятся:
- Риск нового подхода. Для большинства ИТ-отделов RAD был новым подходом, который потребовал от опытных специалистов переосмыслить методы своей работы. Люди практически всегда не склонны к переменам, и любой проект, реализованный с использованием новых инструментов или методов, с большей вероятностью потерпит неудачу с первого раза просто из-за необходимости обучения команды.
- Недостаточное внимание нефункциональным требованиям , которые часто не видны конечному пользователю при нормальной работе.
- Требует времени и ограниченных ресурсов. Практически все подходы к RAD объединяет одна вещь: на протяжении всего жизненного цикла между пользователями и разработчиками происходит гораздо больше взаимодействия. В каскадной модели пользователи определяют требования, а затем обычно уходят, когда разработчики создают систему. Пользователи RAD участвуют с самого начала и практически на протяжении всего проекта. Для этого необходимо, чтобы бизнес был готов инвестировать время экспертов в области приложений. Парадокс заключается в том, что чем лучше эксперт, чем лучше он знаком со своей областью, тем больше от него требуется для реального ведения бизнеса, и может быть трудно убедить своих руководителей инвестировать свое время. Без таких обязательств проекты RAD не будут успешными.
- Меньше контроля. Одним из преимуществ RAD является то, что он обеспечивает гибкий адаптируемый процесс. Идеал – уметь быстро адаптироваться как к проблемам, так и к возможностям. Существует неизбежный компромисс между гибкостью и контролем: больше одного означает меньше другого. Если ценности проекта (например, критически важного программного обеспечения ) контролируют больше, чем гибкость, RAD не подходит.
- Плохой дизайн. В некоторых случаях внимание к прототипам может зайти слишком далеко, что приводит к методологии «взломай и протестируй», когда разработчики постоянно вносят незначительные изменения в отдельные компоненты и игнорируют проблемы архитектуры системы, которые могут привести к улучшению общего дизайна. Это может быть особенно проблемой для таких методологий, как метод Мартина, которые так сильно фокусируются на пользовательском интерфейсе системы. [9]
- Отсутствие масштабируемости. RAD обычно фокусируется на небольших и средних проектных группах. Другие проблемы, упомянутые выше (меньшее количество проектирования и контроля), представляют собой особые проблемы при использовании подхода RAD для очень крупномасштабных систем. [10] [11] [12]
См. также [ править ]
Практические концепции внедрения RAD:
- Конструктор графического пользовательского интерфейса , где представлены основные программные инструменты для RAD.
- Язык программирования четвертого поколения , например FileMaker , 4th Dimension , dBase и Visual FoxPro.
Другие похожие концепции:
- Программирование на основе потока
- Бережливая разработка программного обеспечения
- Платформа как услуга
- Платформы разработки с низким кодом
- Платформа разработки без кода
Ссылки [ править ]
- ^ Брукс, Фред (1986). Куглер, HJ (ред.). Никакой сущности серебряной пули и несчастных случаев в разработке программного обеспечения (PDF) . Обработка информации '86. Elsevier Science Publishers BV (Северная Голландия). ISBN 0-444-70077-3 . Проверено 2 июля 2014 г.
- ^ Перейти обратно: а б Бём, Барри (май 1988 г.). «Спиральная модель разработки программного обеспечения» (PDF) . IEEE-компьютер . дои : 10.1109/2.59 . S2CID 1781829 . Архивировано из оригинала (PDF) 29 марта 2018 года . Проверено 1 июля 2014 г.
- ^ Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полнофункциональную систему за 90 дней или меньше. МакГроу-Хилл. ISBN 0-07-034223-7 .
- ^ Друкер, Питер (3 ноября 2009 г.). Посткапиталистическое общество . Электронные книги Харпер Коллинз. ISBN 978-0887306204 .
- ^ Мартин, Джеймс (1991). Быстрая разработка приложений . Макмиллан. ISBN 0-02-376775-8 .
- ^ Мартин, Джеймс (1991). Быстрая разработка приложений . Макмиллан. стр. 81–90 . ISBN 0-02-376775-8 .
- ^ «Распад AD: снова собрать воедино» (PDF) . Gartner.com.br . Проверено 13 апреля 2010 г.
- ^ Бек, Кент (2000). Объяснение экстремального программирования . Эддисон Уэсли. стр. 3–7 . ISBN 0201616416 .
- ^ Гербер, Аурона; Ван дер Мерве, Альта; Альбертс, Ронелл (16–18 ноября 2007 г.). «Практическое значение методологий быстрого развития». Материалы конференции по образованию в области компьютерных наук и информационных технологий, CSITEd-2007 . Конференция по информатике и ИТ-образованию . Маврикий. стр. 233–245. CiteSeerX 10.1.1.100.645 . ISBN 978-99903-87-47-6 .
- ^ Эндрю Бегель, Начиаппан Нагаппан (сентябрь 2007 г.). «Использование и восприятие гибкой разработки программного обеспечения в промышленном контексте: предварительное исследование» (PDF) . Первый международный симпозиум по эмпирической разработке программного обеспечения и измерениям (ESEM 2007) . стр. 255–264. дои : 10.1109/esem.2007.12 . ISBN 978-0-7695-2886-1 . S2CID 1941370 .
- ^ Максимилиан, ЕМ; Уильямс, Л. (2003). «Оценка разработки через тестирование в IBM». 25-я Международная конференция по программной инженерии, 2003. Труды . стр. 564–569. дои : 10.1109/icse.2003.1201238 . ISBN 0-7695-1877-Х . S2CID 16919353 .
- ^ Стивенс, Мэтт; Розенберг, Дуг (2003). Рефакторинг экстремального программирования: аргументы против XP . дои : 10.1007/978-1-4302-0810-5 . ISBN 978-1-59059-096-6 . S2CID 29042153 .
Дальнейшее чтение [ править ]
- Стив МакКоннелл (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). Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий , Addison-Wesley Professional, ISBN 978-0-321-45819-3
- Скотт Стинер (2016). Список Forbes: «Быстрая разработка приложений (RAD): разумный, быстрый и полезный процесс для разработчиков программного обеспечения»
