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

Концепция разработки программного обеспечения

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

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

История

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

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

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

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

Эти идеи были далее развиты и улучшены пионерами RAD, такими как Джеймс Керр и Ричард Хантер, которые вместе написали основополагающую книгу по этой теме, Inside 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 делит процесс на четыре отдельных этапа:

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

Преимущества

В современных средах информационных технологий многие системы теперь строятся с использованием некоторой степени Rapid Application Development ^[7] (не обязательно подхода Джеймса Мартина). В дополнение к методу Мартина, для разработки RAD часто используются гибкие методы и Rational Unified Process .

Предполагаемые преимущества 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

Другие похожие концепции:

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

Ссылки

1. Брукс, Фред (1986). Куглер, Х. Дж. (ред.). Сущность и случайности программной инженерии без серебряной пули (PDF) . Обработка информации '86. Elsevier Science Publishers BV (Северная Голландия). ISBN 0-444-70077-3. Получено 2 июля 2014 г.
2. Boehm, Barry (май 1988 г.). "Спиральная модель разработки программного обеспечения" (PDF) . IEEE Computer . doi :10.1109/2.59. S2CID  1781829. Архивировано из оригинала (PDF) 29 марта 2018 г. . Получено 1 июля 2014 г. .
3. Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше. McGraw-Hill. ISBN 0-07-034223-7 . 
4. Друкер, Питер (3 ноября 2009 г.). Посткапиталистическое общество. Электронные книги Harper Collins. ISBN 978-0887306204.
5. Мартин, Джеймс (1991). Быстрая разработка приложений. Macmillan. ISBN 0-02-376775-8.
6. Мартин, Джеймс (1991). Быстрая разработка приложений. Macmillan. С. 81–90. ISBN 0-02-376775-8.
7. "Распад AD: как снова собрать его воедино" (PDF) . gartner.com.br . Получено 13 апреля 2010 г. .
8. Бек, Кент (2000). Объяснение экстремального программирования. Эддисон Уэсли. С. 3–7. ISBN 0201616416.
9. Gerber, Aurona; Van Der Merwe, Alta; Alberts, Ronell (16–18 ноября 2007 г.). «Практические последствия методов быстрой разработки». Труды конференции по образованию в области компьютерных наук и информационных технологий, CSITEd-2007 . Конференция по образованию в области компьютерных наук и ИТ. Маврикий. стр. 233–245. CiteSeerX 10.1.1.100.645 . ISBN  978-99903-87-47-6.
10. Эндрю Бегел, Начиаппан Нагаппан (сентябрь 2007 г.). «Использование и восприятие гибкой разработки программного обеспечения в промышленном контексте: исследовательское исследование» (PDF) . Первый международный симпозиум по эмпирической программной инженерии и измерению (ESEM 2007) . стр. 255–264. doi :10.1109/esem.2007.12. ISBN 978-0-7695-2886-1. S2CID  1941370.
11. Максимилиан, Э. М.; Уильямс, Л. (2003). «Оценка разработки через тестирование в IBM». 25-я Международная конференция по программной инженерии, 2003. Труды . С. 564–569. doi :10.1109/icse.2003.1201238. ISBN 0-7695-1877-X. S2CID  16919353.
12. Стивенс, Мэтт; Розенберг, Дуг (2003). Рефакторинг экстремального программирования: аргументы против XP . doi :10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6. S2CID  29042153.

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

• Стив Макконнелл (1996). Быстрое развитие: укрощение диких программных графиков , Microsoft Press Books, ISBN 978-1-55615-900-8 
• Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше . McGraw-Hill. ISBN 0-07-034223-7.
• Эллен Готтесдинер (1995). «Реальность RAD: от шумихи к тому, как RAD действительно работает» Тенденции разработки приложений
• Кен Швабер (1996). Agile Project Management with 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): умный, быстрый и ценный процесс для разработчиков программного обеспечения»