основой методологии быстрой разработки приложений является
Технология разработки ПО
1.3 Методология RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
Ещё раз про семь основных методологий разработки
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.
Когда использовать каскадную методологию?
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
Когда использовать Agile?
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
Быстрая разработка приложений (RAD) на сейчас
Выбор методик разработки приложений становится задачей № 1 в условиях стремительного роста рынка. Согласно исследованию Gartner на программное обеспечение для предприятий в 2015 году по миру было затрачено 310 млрд. долларов США. Разработка концепции RAD (Rapid Application Development) стало основой для создания гибкой, адаптивной системы разработки приложений, которая была бы противовесом жёсткой «водопадной» модели.
RAD — модель быстрой разработки приложений, ключевыми для которой является скорость и удобство программирования.
Появление RAD
За появление быстрой разработки приложения стоит благодарить неидеальность модели семейства Waterfall при создании ПО. Всё дело в том, что изначально водопадная система разработки была основана на традиционной инженерной модели, используемой для проектирования и возведения зданий и мостов.
Если Waterfall за основу использовала жесткую структуру последовательных действий по разработке, то появление RAD стало попыткой создания гибкого процесса, в рамках которого могли быть использованы знания, полученные в течении жизненного цикла управления проектом.
Первую версию RAD создал Барри Боэм в 1986 году, который назвал её «спиральная модель». Каждый виток спирали разбит на 4 сектора и соответствует разработке фрагмента или версии ПО. С каждым новым витком идёт углубление и уточнение целей, спецификаций проекта. В результате появляется возможность выбрать обоснованный вариант.
Использовав идеи Барри, британец Джеймс Мартин разработал свою систему RAD на протяжении работы в 80-ых в IBM, и окончательно сформулировал их в книге «Быстрая разработка приложений» в 1991 г.
Правда не обошлось без путаницы в значении слова «RAD» даже среди IT-специалистов. Ведь речь шла о двух концепциях: RAD как эффективной альтернативе Waterfall и RAD как специфическому методу, разработанному Мартином. Последний был адаптирован к бизнес-системам с интенсивным использованием UI.
В дальнейшем идеи были развиты и улучшены пионерами RAD Джеймсом Керром и Ричардом Хантером в совместной книге «Внутри RAD», которая описывала путешествие проектного менеджера в процессе изучения и внедрения методологии быстрой разработки приложений в реальной жизни для реального проекта.
Эти и многие другие авторы смогли популяризировать новую методику как альтернативу традиционным системам подходов к жизненному циклу проекта.
Спиральная модель — процесс разработки ПО, комбинирующий проектирование и постадийное прототипирование.
Основы (принципы) быстрой разработки приложений
Принципы RAD сосредоточены на том, чтобы обеспечить основные преимущества методики быстрой разработки приложений:
С последним пунктом возникает больше всего проблем, потому что разработчик и заказчик видят предмет разработки по-разному.
Для устранения этой и других проблем Джеймсом Мартином и его последователями были выделены следующие принципы RAD:
Принципы RAD используются не только при реализации, а и распространяются на все этапы жизненного цикла, в частности, на стадию обследования организации, построения требований, анализ и дизайн.
Жизненный цикл программного обеспечения по RAD
В процессе RAD приложение проходит четыре фазы.
Фаза анализа и планирования требований
Определяются требования, функции приложения и их приоритетность, описываются информационные потребности. Фаза выполняется преимущественно пользователями при участии разработчиков. На этой стадии также обозначаются масштаб проекта, временные и финансовые рамки, платформы для запуска ПО.
Например, компании «Beverly Flowers» нужно приложение для онлайн-заказа цветов на дом. На создание отводится 50 дней, бюджет — 3 000 долларов.
Фаза проектирования
Часть пользователей участвует в техническом проектировании системы под руководством разработчиков. Группы или подгруппы RAD на этой фазе обычно используют комбинацию техник с овместной разработки приложений (JAD) и CASE-инструменты для воплощения потребностей пользователей в рабочих моделях.
JAD (Joint Application Development) — концепция совместной разработки приложений, в рамках которой происходит тесное взаимодействие между заказчиком и исполнителями для максимально эффективного решения вопросов, касающихся разрабатываемого ПО.
Case — комплект инструментов и методов для проектирования ПО для обеспечения высокого качества программ, отсутствия ошибок и простоты в обслуживании программных продуктов.
В результате фазы создаются:
Если в предыдущих моделях средства разработки прототипов не соответствовали реальным приложениям, и они в дальнейшем не использовались, то в RAD каждый прототип становится частью будущей системы.
В качестве платформы разработки выбрали freeware SpringToolSuite, для которой доступно большое количество сэмплов — прописанных кусочков кода.
В роли сервера — Apache Tomcat 6.0.
Фаза построения
На этой стадии происходит непосредственно быстрая разработка на основе полученных по предыдущим фазам результатов. При этом пользователи продолжают участвовать в развитии системы, предлагая изменения и улучшения приложения. Тестирование приложения тоже происходит во время разработки.
Фаза внедрения
Охватывает обучение пользователей, тестирование и замену старой системы на новую. Подготовка к этой фазе начинается с этапа проектирования.
Записав сообщение о возможности заказа через специальное приложение и разместив информационные стенды в точках продажи, за 2 недели удалось переключить часть покупателей на новый канал сбыта.
При этом доля заказов по телефону пропорционально снизилась, а значит удалось сократить штат менеджеров по работе с клиентами.
Стоит отметить, что в отличии от Waterfall, жизненный цикл проекта по методологии RAD не является жёстким. Зависимо от стартовых условий, количество фаз может уменьшаться, как и их наполнение.
Плюсы и минусы быстрой разработки приложений в вашей компании
Использовать Rapid Application Development или нет, во многом зависит от стартовых условий, требований заказчика и вида приложения.
К однозначным преимуществам RAD относятся:
Инкрементная модель разработки — формат разработки программного обеспечения, которая предусматривает деление продукта на относительно независимые компоненты. Последние разрабатываются и вводятся в эксплуатацию по отдельности.
Не обошлось и без недостатков.
К минусам rapid application development можно отнести:
Методология RAD подойдет вашему проекту, если:
Методология rapid application development не подойдёт вашему проекту, если:
Вердикт
Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.
Ключевые параметры, которыми оперирует RAD —
скорость и удобство программирования.
Методология станет отличным выбором для реализации небольших проектов с ограниченным бюджетом, разработать которые нужно в сжатые сроки. Для масштабных же систем, с высокими требованиями по контролю и планированию лучше выбрать другие модели разработки программного обеспечения.
СОДЕРЖАНИЕ
История
Эти идеи были далее развиты и усовершенствованы пионерами RAD, такими как Джеймс Керр и Ричард Хантер, которые вместе написали основополагающую книгу на эту тему Inside RAD, которая следовала за поездкой менеджера проекта RAD, когда он управлял и совершенствовал методологию RAD в реальных условиях. время на реальном проекте RAD. Эти и им подобные помогли RAD завоевать популярность в качестве альтернативы традиционным подходам к жизненному циклу системных проектов.
Джеймс Мартин чувствовал себя комфортно с RAD благодаря подразделению информационной инженерии Dupont и его руководителю Скотту Шульцу, а также их отношениям с Джоном Андервудом, который возглавлял специализированную компанию по разработке RAD, которая положила начало многим успешным проектам RAD в Австралии и Гонконге.
Успешные проекты, в том числе ANZ Bank, Lend Lease, BHP, Coca-Cola Amatil, Alcan, Hong Kong Jockey Club и многие другие.
Успех, который привел к тому, что и Скотт Шульц, и Джеймс Мартин провели время в Австралии с Джоном Андервудом, чтобы понять методы и детали того, почему Австралия оказалась непропорционально успешной в реализации важных для миссии проектов RAD.
Метод Джеймса Мартина RAD
Подход Джеймса Мартина к RAD делит процесс на четыре отдельных этапа:
Плюсы и минусы быстрой разработки приложений
Предполагаемые преимущества RAD включают:
К недостаткам РАД можно отнести:
Методологии разработки ПО: RAD
Меньше слов, больше дела!
Идея RAD зародилась в 1980-х годах как альтернатива устаревающей методологии Waterfall, о которой мы уже писали. Каскадная модель программирования уже тогда воспринималась как перегруженная формальностями и недостаточно гибкая. Заказчик выдавал разработчику техническое задание и не видел результата до тех пор, пока программа не «сходила с конвейера» уже готовой, — и ожидания пользователя зачастую не оправдывались. Продукт мог оказаться слишком сложным, неудобным, а мог и устареть за время разработки.
В каскадной модели на ранних этапах работы проводится тщательное планирование, но это не помогает предусмотреть все риски и сложности. Поэтому проект дорожает, а время — уходит впустую.
В 1988 году американский инженер-программист Барри Боэм (Barry Boehm) опубликовал статью «Спиральная модель разработки и совершенствование программного обеспечения», в которой предложил создавать не цельную программу, а выпускать ряд прототипов, каждый из которых содержит дополнительную или расширенную функциональность по сравнению с предыдущим. Пользователь может изучить и попробовать в деле каждый прототип. Получая обратную связь, разработчик дорабатывает приложение, пока заказчик не получит готовый продукт, который полностью его устраивает.
Идея оказалась перспективной. Ее проработал специалист IBM Джеймс Мартин — в 1991 году вышла его книга «Быстрая разработка приложений» с изложением оригинальной методики применения RAD или Rapid Application Development. Спустя два года Джеймс Керр и Ричард Хантер написали книгу «Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше», где проанализировали подводные камни и возможности, которые они выявили при планировании и реализации успешного проекта RAD.
Эти книги заложили фундамент для практического применения RAD, и с тех пор эта методология остается в арсенале IT-разработчиков.
Нарисуйте мне программу
Плохие программы, не отвечающие потребностям пользователей, появляются потому, что заказчик и разработчик по-разному понимают задачу. Даже если будущий пользователь заранее составит подробное техническое задание и напишет спецификации, все равно остается шанс, что программист поймет их не так, как предполагалось. Пользователь и разработчик смотрят на программу с разных сторон: снаружи и изнутри. Заказчик зачастую хорошо понимает, что именно он хочет получить, но не очень ясно представляет, как этого достичь. Программист, напротив, отлично разбирается в устройстве программы, но не имеет четкого представления, что нужно пользователю.
RAD предлагает вести разработку так, чтобы заказчик мог увидеть практические результаты на самых ранних этапах — и скорректировать техническое задание, если это будет необходимо. Очередной цикл разработки начинается не раньше, чем пользователь оценил результаты предыдущего.
Изначально программист создает приложение в черновом варианте. Это могут быть наброски интерфейса и несколько пунктов меню. Если заказчика устраивает первый прототип, программа дорабатывается: добавляются новые элементы интерфейса, функциональность. С каждой итерацией приложение обрастает возможностями, и пользователь постоянно уточняет требования и задает вектор развития.
Методологию быстрой разработки RAD можно сравнить с работой художника. Сначала живописец делает эскиз. Потом создает черновой вариант картины. Затем он начинает прорабатывать элементы, добавляет детали, исправляет недочеты. Разумеется, не каждый заказчик способен по первому наброску представить себе, как будет выглядеть готовая картина, — возможно, он вообще не имеет понятия о перспективе или композиции. Но по крайней мере художнику не придется переписывать весь холст — ведь к завершению работы уже не окажется, что клиент перепутал натюрморт с пейзажем: «Нет-нет, я имел в виду сельский вид, а не корзину с фруктами!» Куда проще внести исправления в эскиз, чем в завершенное полотно.
RAD гарантирует, что в результате заказчик получит именно то, что ему нужно, — если в ходе разработки он последовательно одобрял каждый шаг, добавленные в проект детали и функциональные модули.
Быстро, качественно, дешево — выберите три из трех
Три кита, на которых покоится RAD, — это скорость разработки, качество программного кода и дешевизна. Да, это та самая методология, которая предлагает не выбрать два пункта из трех, а получить все сразу.
Почему быстро?
Методология RAD требует, чтобы работающие прототипы создавались максимально часто. Продолжительность одного производственного цикла — от выработки требований до демонстрации пользователю (то есть одной итерации) — от одного дня до трех недель.
Во многих случаях разумным вариантом будет разделить приложение на функциональные модули, каждый из которых можно создавать и тестировать отдельно. Модули разрабатываются параллельно разными командами, но по общей схеме: от простых прототипов к более сложным, с регулярным контролем со стороны заказчика. В конце работы или каждой итерации модули соединяют в цельное программное решение.
Полезны инструменты автоматизации разработки — они помогают переводить пожелания пользователя в формализованные требования и спецификации, на основании которых формируется модель программы.
Почему качественно?
Пользователь может определять, какую функциональность он хочет видеть реализованной в следующей итерации. Постоянное взаимодействие заказчика и разработчика гарантирует, что приложение будет развиваться в нужном направлении, интерфейс будет удобным, а функциональность востребованной. Такая схема избавляет программиста от лишней работы и исключает ситуации, когда часть программы приходится переделывать с нуля из-за неверно понятых вводных.
Почему дешево?
Деньги — странный предмет: вот они есть, а вот их нет. Бывает, что их не хватает, и приходится прерывать разработку, когда написана еще далеко не вся запланированная функциональность. Что получит заказчик в этом случае?
Если разработчик использует методологию Waterfall, то техническое задание и спецификации на программу он получает в самом начале работы. Какую из задач решать в первую очередь, а что оставить «на десерт», решает сам разработчик — при этом не всегда четко понимая, что для пользователя важно, а что не очень. В итоге заказчик, у которого внезапно закончились средства на проект, может получить программу, в которой реализованы второстепенные задачи, но отсутствует ключевая функциональность.
При Rapid Application Development пользователь сам решает, что ему требуется в первую очередь, и постоянно получает все более функциональные прототипы — то есть, фактически, работающие версии программы. Если финансирование внезапно иссякнет — пользователь не останется у разбитого корыта.
Разработка идет быстро, и заказчик получает программу существенно раньше — а это и экономия финансов.
Инструментарий RAD
Методология RAD еще с конца 1980-х была нацелена на использование новейших технологий ускорения разработки — и этот фокус на инструментах автоматизации по-прежнему актуален.
Средства автоматизации разработки программ (Computer-Aided Software Engineering), или CASE-инструменты — это программные продукты для проектирования приложений. Такая система позволяет быстро создать модель программы, а затем автоматически сгенерировать программный код. Получается прототип — запускаемый модуль, который можно продемонстрировать заказчику.
От одноклеточного к развитому: эволюция программы
Разработка приложения по методологии RAD проходит в несколько этапов.
Первый — анализ и планирование. Здесь определяются цели и задачи проекта — что и для чего будет делать приложение. Совместными усилиями заказчик и разработчик выявляют риски, устанавливают сроки и бюджет, определяют ключевые моменты разработки.
Затем начинается пользовательское проектирование. На этом этапе создается серия работающих прототипов программы. Каждый очередной прототип отличается от предыдущего дополненной функциональностью, изменениями дизайна и производительности. Процесс создания одного прототипа называется итерацией. RAD не накладывает жестких временных рамок на продолжительность одной итерации, но рекомендует, чтобы она была максимально быстрой.
В начале очередного цикла разработки заказчик и программист вместе формулируют требования, которым должна соответствовать очередная версия. Преимущество RAD в том, что не надо заранее продумывать каждую мелочь: сначала разрабатывается самая общая концепция, которая на следующих итерациях будет дополняться и уточняться.
Затем в дело вступают программисты. С помощью инструментов CASE они воплощают требования в виде модели, создавая очередной прототип. Его показывают пользователю и получают обратную связь. Уточняя пожелания и требования к программе, заказчик фактически руководит разработкой.
Прототип зачастую создается на скорую руку, только для проверки концепций. Это нормально: если пользователя устраивает новая функциональность и все работает как следует, в следующей итерации разработчик «отполирует» интерфейс и код. Перфекционизм может даже вредить — на очередном этапе любую доработку пользователь может посчитать неудачной. Если программист стремится сразу сделать все идеально, его усилия окажутся напрасными.
Как только заказчик дал обратную связь, цикл начинается заново. Вырабатывается план на следующую итерацию. Если пользователя что-то не устроило в прототипе, на новом витке цикла изменения откатывают назад и реализуют альтернативный вариант.
Если заказчик принял прототип — уточняем требования к функциональности, прорабатываем ее более детально, планируем новую. Обговариваем визуальные элементы и интерфейсы.
От прототипа к прототипу программный продукт приобретает вид завершенного приложения. Итерации выполняются, пока не будут реализованы последние требования.
Когда моделирование завершено, начинается конструирование: автоматически сгенерированный код дорабатывается и совершенствуется.
Финальный этап разработки — переключение. Готовый программный продукт тестируют, развертывают на пользовательских машинах, конвертируют информацию в новый формат или «заливают» в новые базы данных, подготавливают документацию и обучают операторов работе в системе.
Когда мы рады RAD’у, а когда не рады
У методологии RAD есть и преимущества, и недостатки, а также области применения, в которых она показывает себя лучше или хуже.
Эффективные варианты применения RAD
Преимущества RAD — кратко
Недостатки RAD
RAD уже не молодая методология — ей слегка за 30, — но она по-прежнему используется в разработке программного обеспечения и сдавать свои позиции не собирается. Ведь для методологии главное — не возраст, а эффективность.
Сегодня расскажем о RAD — Rapid Application Development, или быстрой разработке приложений.
Меньше слов, больше дела!
Идея RAD зародилась в 1980-х годах как альтернатива устаревающей методологии Waterfall, о которой мы уже писали. Каскадная модель программирования уже тогда воспринималась как перегруженная формальностями и недостаточно гибкая. Заказчик выдавал разработчику техническое задание и не видел результата до тех пор, пока программа не «сходила с конвейера» уже готовой, — и ожидания пользователя зачастую не оправдывались. Продукт мог оказаться слишком сложным, неудобным, а мог и устареть за время разработки.
В каскадной модели на ранних этапах работы проводится тщательное планирование, но это не помогает предусмотреть все риски и сложности. Поэтому проект дорожает, а время — уходит впустую.
В 1988 году американский инженер-программист Барри Боэм (Barry Boehm) опубликовал статью «Спиральная модель разработки и совершенствование программного обеспечения», в которой предложил создавать не цельную программу, а выпускать ряд прототипов, каждый из которых содержит дополнительную или расширенную функциональность по сравнению с предыдущим. Пользователь может изучить и попробовать в деле каждый прототип. Получая обратную связь, разработчик дорабатывает приложение, пока заказчик не получит готовый продукт, который полностью его устраивает.
Идея оказалась перспективной. Ее проработал специалист IBM Джеймс Мартин — в 1991 году вышла его книга «Быстрая разработка приложений» с изложением оригинальной методики применения RAD или Rapid Application Development. Спустя два года Джеймс Керр и Ричард Хантер написали книгу «Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше», где проанализировали подводные камни и возможности, которые они выявили при планировании и реализации успешного проекта RAD.
Эти книги заложили фундамент для практического применения RAD, и с тех пор эта методология остается в арсенале IT-разработчиков.
Нарисуйте мне программу
Плохие программы, не отвечающие потребностям пользователей, появляются потому, что заказчик и разработчик по-разному понимают задачу. Даже если будущий пользователь заранее составит подробное техническое задание и напишет спецификации, все равно остается шанс, что программист поймет их не так, как предполагалось. Пользователь и разработчик смотрят на программу с разных сторон: снаружи и изнутри. Заказчик зачастую хорошо понимает, что именно он хочет получить, но не очень ясно представляет, как этого достичь. Программист, напротив, отлично разбирается в устройстве программы, но не имеет четкого представления, что нужно пользователю.
RAD предлагает вести разработку так, чтобы заказчик мог увидеть практические результаты на самых ранних этапах — и скорректировать техническое задание, если это будет необходимо. Очередной цикл разработки начинается не раньше, чем пользователь оценил результаты предыдущего.
Изначально программист создает приложение в черновом варианте. Это могут быть наброски интерфейса и несколько пунктов меню. Если заказчика устраивает первый прототип, программа дорабатывается: добавляются новые элементы интерфейса, функциональность. С каждой итерацией приложение обрастает возможностями, и пользователь постоянно уточняет требования и задает вектор развития.
Методологию быстрой разработки RAD можно сравнить с работой художника. Сначала живописец делает эскиз. Потом создает черновой вариант картины. Затем он начинает прорабатывать элементы, добавляет детали, исправляет недочеты. Разумеется, не каждый заказчик способен по первому наброску представить себе, как будет выглядеть готовая картина, — возможно, он вообще не имеет понятия о перспективе или композиции. Но по крайней мере художнику не придется переписывать весь холст — ведь к завершению работы уже не окажется, что клиент перепутал натюрморт с пейзажем: «Нет-нет, я имел в виду сельский вид, а не корзину с фруктами!» Куда проще внести исправления в эскиз, чем в завершенное полотно.
RAD гарантирует, что в результате заказчик получит именно то, что ему нужно, — если в ходе разработки он последовательно одобрял каждый шаг, добавленные в проект детали и функциональные модули.
Быстро, качественно, дешево — выберите три из трех
Три кита, на которых покоится RAD, — это скорость разработки, качество программного кода и дешевизна. Да, это та самая методология, которая предлагает не выбрать два пункта из трех, а получить все сразу.
Почему быстро?
Методология RAD требует, чтобы работающие прототипы создавались максимально часто. Продолжительность одного производственного цикла — от выработки требований до демонстрации пользователю (то есть одной итерации) — от одного дня до трех недель.
Во многих случаях разумным вариантом будет разделить приложение на функциональные модули, каждый из которых можно создавать и тестировать отдельно. Модули разрабатываются параллельно разными командами, но по общей схеме: от простых прототипов к более сложным, с регулярным контролем со стороны заказчика. В конце работы или каждой итерации модули соединяют в цельное программное решение.
Полезны инструменты автоматизации разработки — они помогают переводить пожелания пользователя в формализованные требования и спецификации, на основании которых формируется модель программы.
Почему качественно?
Пользователь может определять, какую функциональность он хочет видеть реализованной в следующей итерации. Постоянное взаимодействие заказчика и разработчика гарантирует, что приложение будет развиваться в нужном направлении, интерфейс будет удобным, а функциональность востребованной. Такая схема избавляет программиста от лишней работы и исключает ситуации, когда часть программы приходится переделывать с нуля из-за неверно понятых вводных.
Почему дешево?
Деньги — странный предмет: вот они есть, а вот их нет. Бывает, что их не хватает, и приходится прерывать разработку, когда написана еще далеко не вся запланированная функциональность. Что получит заказчик в этом случае?
Если разработчик использует методологию Waterfall, то техническое задание и спецификации на программу он получает в самом начале работы. Какую из задач решать в первую очередь, а что оставить «на десерт», решает сам разработчик — при этом не всегда четко понимая, что для пользователя важно, а что не очень. В итоге заказчик, у которого внезапно закончились средства на проект, может получить программу, в которой реализованы второстепенные задачи, но отсутствует ключевая функциональность.
При Rapid Application Development пользователь сам решает, что ему требуется в первую очередь, и постоянно получает все более функциональные прототипы — то есть, фактически, работающие версии программы. Если финансирование внезапно иссякнет — пользователь не останется у разбитого корыта.
Разработка идет быстро, и заказчик получает программу существенно раньше — а это и экономия финансов.
Инструментарий RAD
Методология RAD еще с конца 1980-х была нацелена на использование новейших технологий ускорения разработки — и этот фокус на инструментах автоматизации по-прежнему актуален.
Средства автоматизации разработки программ (Computer-Aided Software Engineering), или CASE-инструменты — это программные продукты для проектирования приложений. Такая система позволяет быстро создать модель программы, а затем автоматически сгенерировать программный код. Получается прототип — запускаемый модуль, который можно продемонстрировать заказчику.
От одноклеточного к развитому: эволюция программы
Разработка приложения по методологии RAD проходит в несколько этапов.
Первый — анализ и планирование. Здесь определяются цели и задачи проекта — что и для чего будет делать приложение. Совместными усилиями заказчик и разработчик выявляют риски, устанавливают сроки и бюджет, определяют ключевые моменты разработки.
Затем начинается пользовательское проектирование. На этом этапе создается серия работающих прототипов программы. Каждый очередной прототип отличается от предыдущего дополненной функциональностью, изменениями дизайна и производительности. Процесс создания одного прототипа называется итерацией. RAD не накладывает жестких временных рамок на продолжительность одной итерации, но рекомендует, чтобы она была максимально быстрой.
В начале очередного цикла разработки заказчик и программист вместе формулируют требования, которым должна соответствовать очередная версия. Преимущество RAD в том, что не надо заранее продумывать каждую мелочь: сначала разрабатывается самая общая концепция, которая на следующих итерациях будет дополняться и уточняться.
Затем в дело вступают программисты. С помощью инструментов CASE они воплощают требования в виде модели, создавая очередной прототип. Его показывают пользователю и получают обратную связь. Уточняя пожелания и требования к программе, заказчик фактически руководит разработкой.
Прототип зачастую создается на скорую руку, только для проверки концепций. Это нормально: если пользователя устраивает новая функциональность и все работает как следует, в следующей итерации разработчик «отполирует» интерфейс и код. Перфекционизм может даже вредить — на очередном этапе любую доработку пользователь может посчитать неудачной. Если программист стремится сразу сделать все идеально, его усилия окажутся напрасными.
Как только заказчик дал обратную связь, цикл начинается заново. Вырабатывается план на следующую итерацию. Если пользователя что-то не устроило в прототипе, на новом витке цикла изменения откатывают назад и реализуют альтернативный вариант.
Если заказчик принял прототип — уточняем требования к функциональности, прорабатываем ее более детально, планируем новую. Обговариваем визуальные элементы и интерфейсы.
От прототипа к прототипу программный продукт приобретает вид завершенного приложения. Итерации выполняются, пока не будут реализованы последние требования.
Когда моделирование завершено, начинается конструирование: автоматически сгенерированный код дорабатывается и совершенствуется.
Финальный этап разработки — переключение. Готовый программный продукт тестируют, развертывают на пользовательских машинах, конвертируют информацию в новый формат или «заливают» в новые базы данных, подготавливают документацию и обучают операторов работе в системе.
Когда мы рады RAD’у, а когда не рады
У методологии RAD есть и преимущества, и недостатки, а также области применения, в которых она показывает себя лучше или хуже.
Эффективные варианты применения RAD
Преимущества RAD — кратко
Недостатки RAD
RAD уже не молодая методология — ей слегка за 30, — но она по-прежнему используется в разработке программного обеспечения и сдавать свои позиции не собирается. Ведь для методологии главное — не возраст, а эффективность.