stringtranslate.com

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

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

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

История

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

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

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

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

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

Во многом доверие Джеймса Мартина к RAD было связано с подразделением информационной инженерии Dupont и его руководителем Скоттом Шульцем, а также их соответствующими отношениями с Джоном Андервудом, который возглавлял специализированную компанию по разработке RAD, которая инициировала множество успешных проектов RAD в Австралии и Гонконге.

Успешные проекты, среди которых ANZ Bank , Lend Lease , BHP , Coca-Cola Amatil, Alcan , Hong Kong Jockey Club и многие другие.

Успех, который привел к тому, что Скотт Шульц и Джеймс Мартин провели время в Австралии с Джоном Андервудом, чтобы понять методы и детали того, почему Австралия добилась непропорционально большого успеха в реализации важных для миссии проектов RAD.

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

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

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

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

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

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

К предполагаемым преимуществам RAD относятся:

Недостатки

К предполагаемым недостаткам RAD относятся:

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

Практические концепции внедрения RAD:

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

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

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

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