Быстрая разработка программного обеспечения. Быстрая разработка приложений. Технология RAD - Rapid Application Development

Выбор методик разработки приложений становится задачей № 1 в условиях стремительного роста рынка. Согласно исследованию на программное обеспечение для предприятий в 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 приложение проходит четыре фазы.

Фаза анализа и планирования требований

Определяются требования, функции приложения и их приоритетность, описываются информационные потребности. Фаза выполняется преимущественно пользователями при участии разработчиков. На этой стадии также обозначаются масштаб проекта, временные и финансовые рамки, платформы для запуска ПО.

Фаза проектирования

Часть пользователей участвует в техническом проектировании системы под руководством разработчиков. Группы или подгруппы RAD на этой фазе обычно используют комбинацию техник с овместной разработки приложений (JAD) и CASE-инструменты для воплощения потребностей пользователей в рабочих моделях.

JAD (Joint Application Development) — концепция совместной разработки приложений, в рамках которой происходит тесное взаимодействие между заказчиком и исполнителями для максимально эффективного решения вопросов, касающихся разрабатываемого ПО.

Case — комплект инструментов и методов для проектирования ПО для обеспечения высокого качества программ, отсутствия ошибок и простоты в обслуживании программных продуктов.

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

В результате фазы создаются:

• общая информационная модель приложения
• функциональные модели системы и подсистем
• рабочие прототипы экранов, отчётов и диалогов.

Если в предыдущих моделях средства разработки прототипов не соответствовали реальным приложениям, и они в дальнейшем не использовались, то в RAD каждый прототип становится частью будущей системы.

Так, в приложении «Beverly Flowers» пользователи должны иметь доступ к возможностям: «Домашняя страница», «Поиск цветов», «Посмотреть список цветов».

В качестве платформы разработки выбрали freeware SpringToolSuite, для которой доступно большое количество сэмплов — прописанных кусочков кода.
В роли сервера — Apache Tomcat 6.0.

Фаза построения

На этой стадии происходит непосредственно быстрая разработка на основе полученных по предыдущим фазам результатов. При этом пользователи продолжают участвовать в развитии системы, предлагая изменения и улучшения приложения. Тестирование приложения тоже происходит во время разработки.

Приложение «Beverly Flowers» собирается из трёх функциональных компонентов — перехода пользователя на «Домашнюю страницу», «Поиск цветов» и «Просмотреть список цветов».
Для разработки рабочей модели понадобился 1 специалист и 8 дней.

Фаза внедрения

Охватывает обучение пользователей, тестирование и замену старой системы на новую . Подготовка к этой фазе начинается с этапа проектирования.

Ранее компания «Beverly Flowers» принимала заказы непосредственно в точках сбыта и по телефону.

Записав сообщение о возможности заказа через специальное приложение и разместив информационные стенды в точках продажи, за 2 недели удалось переключить часть покупателей на новый канал сбыта.

При этом доля заказов по телефону пропорционально снизилась, а значит удалось сократить штат менеджеров по работе с клиентами.

Стоит отметить, что в отличии от Waterfall, жизненный цикл проекта по методологии RAD не является жёстким. Зависимо от стартовых условий, количество фаз может уменьшаться, как и их наполнение.

Плюсы и минусы быстрой разработки приложений в вашей компании

Использовать Rapid Application Development или нет, во многом зависит от стартовых условий, требований заказчика и вида приложения.

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

1. высокое качество. Взаимодействие пользователей с прототипами повышает функциональность проектов, выполненных в рамках быстрой разработки приложений. Такое программное обеспечение может больше отвечать потребностям заказчика (конечного пользователя), чем при использовании методик Agile/Waterfall.
2. контроль рисков — несмотря на то, что львиная часть материалов о RAD фокусируется на скорости и вовлечении пользователей как ключевым особенностям модели, нельзя исключать третье важное преимущество — снижение рисков . Интересно, но Боэм, создавший первую версию RAD, охарактеризовал спиральную модель как основанную на риске.
   Использование rapid application development позволяет уже на ранних стадиях сосредоточиться на главных факторах риска и приспособиться к ним.
3. за единицу времени выполняется больше проектов в рамках бюджета — так как RAD подразумевает инкрементную модель разработки , шансы на критические ошибки, которые часто случаются в больших проектах по системе Waterfall, снижены.
   Если в проектах по водопадной системе реализация проекта была возможна после шести и более месяцев анализа и разработки, то в RAD вся необходима информация открывается раньше, во время самого процесса создания приложения.

Инкрементная модель разработки — формат разработки программного обеспечения, которая предусматривает деление продукта на относительно независимые компоненты. Последние разрабатываются и вводятся в эксплуатацию по отдельности.

Не обошлось и без недостатков.

К минусам rapid application development можно отнести:

1. риск «новизны» — для большинства IT-компаний RAD было новинкой, требующей переосмысления привычных методик работы. Сопротивление новому, необходимость изучения с нуля инструментов и техник приводят к ошибкам во время первых внедрений rapid application development.
2. если пользователи не могут постоянно брать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно повлиять на конечный продукт — особенностью RAD является увеличенное взаимодействие пользователей и разработчиков в отличии от моделей Waterfall, в которых роль пользователей сводится к определению требований. Далее разработчики сами создают систему.
3. уменьшенный контроль — гибкость, адаптивность процесса как одно из преимуществ RAD в идеале означает возможность быстро адаптироваться как к проблемам, так и возможностям.
   К сожалению, придётся отдать предпочтение чему-то одному — гибкости или контролю. В последнем случае методика быстрой разработки приложений не будет жизнеспособной.
4. скудный дизайн — фокусирование на прототипах в некоторых случаях приводит к методике «взлом и тестирование», по которой разработчики постоянно вносят мелкие изменения в отдельные элементы и игнорируют проблемы системной архитектуры.
5. отсутствие масштабируемости — преимущественно RAD используется маленькими и средними проектными командами. Недостатки методологии rapid application development особенно ярко проявляются при использовании быстрой разработки приложений в работе над крупными проектами.

Методология RAD подойдет вашему проекту, если:

• для него важна скорость и простота разработки
• четко определены приоритетные направления разработки проекта
• разработать приложение нужно в сжатые сроки
• проект выполняется в условиях ограниченного бюджета
• главный критерий — интерфейс пользователя
• есть возможность разбить проект на функциональные компоненты.

Методология rapid application development не подойдёт вашему проекту, если:

• для него важно качество и контроль
• идет речь о создании крупномасштабного проекта — предполагаемое максимальное время разработки приложения составляет 60-90 дней, а при написании сотни тысяч строк программного кода соблюсти такое ограничение практически невозможно
• критически важным для реализации является высокий уровень планирования и жесткая дисциплина проектирования , строгое следование заранее разработанным протоколам и интерфейсам
• от приложения в определенной степени зависит безопасность людей.

Вердикт

Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.

Ключевые параметры, которыми оперирует RAD —
скорость и удобство программирования.

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

Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - рентгеновский микротомограф , мелкий - автообновление службы Windows на AWS .

Когда использовать каскадную методологию?

• Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
• Нет проблем с доступностью программистов нужной квалификации.
• В относительно небольших проектах.

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

Пример нашей работы на основе V-методологии - мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры - центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.

Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

Когда использовать Agile?

• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

6. «Iterative Model» (итеративная или итерационная модель)

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй - появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале - в мыслях, затем - на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.

Когда оптимально использовать итеративную модель?

• Требования к конечной системе заранее четко определены и понятны.
• Проект большой или очень большой.
• Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.

7. «Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

О технологиях разработки:
Ещё раз про семь основных методологий разработки .
10 главных ошибок масштабирования систем .
8 принципов планирования разработки, упрощающих жизнь .
5 главных рисков при заказной разработке ПО .

Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.

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

Модель быстрой разработки приложений (Rapid Application Development) - второй пример применения инкрементной стратегии конструирования (рис. 1.5).

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD - высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

q бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

q моделирование данных . Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;

q моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;

q генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;

q тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

Рис. 1.5. Модель быстрой разработки приложений

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

Применение RAD имеет- и свои недостатки, и ограничения.

1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).

2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

Спиральная модель

Спиральная модель - классический пример применения эволюционной стратегии конструирования.

Рис. 1.6. Спиральная модель: 1 - начальный сбор требований и планирование проекта;

начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход

к комплексной системе; 6 - начальный макет системы; 7 - следующий уровень макета;

8 - сконструированная система; 9 - оценивание заказчиком

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование - определение целей, вариантов и ограничений.

2. Анализ риска - анализ вариантов и распознавание/выбор риска.

3. Конструирование - разработка продукта следующего уровня.

4. Оценивание - оценка заказчиком текущих результатов конструирования.

Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.

В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.

Достоинства спиральной модели:

1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

2) позволяет явно учитывать риск на каждом витке эволюции разработки;

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

Введение

Цель курсовой работы - закрепление навыков по проектированию информационных систем.

В курсовой работе должны быть решены следующие задачи:

Анализ существующих технологий создания информационных систем (ИС)

Обоснование выбора технологии создания ИС для проекта курсовой работы

Разработка проекта ИС по выбранной технологии

Для решения поставленных задач будет применяться средства инструментального проектирования ИС (CASE - средство) Rational Rose, язык визуального объектно-ориентированного моделирования UML - Unified Modeling Language.

Анализ технологий создания программного обеспечения

Технология RAD - Rapid Application Development

Это концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD -- это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

Концепция RAD стала ответом на неуклюжие методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада» (англ. Waterfall model). Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

Назначение:

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

Применение:

Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.

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

Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

Проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.

Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

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

Низкая вычислительная сложность ПО.

RAD-технология не является универсальной, то есть её применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объём пользовательского интерфейса невелик.

Основные принципы:

Принципы RAD технологии направлены на обеспечение трех основных её преимуществ -- высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.

Инструментарий должен быть нацелен на минимизацию времени разработки.

Создание прототипа для уточнения требований заказчика.

Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.

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

Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.

Управление проектом должно минимизировать длительность цикла разработки.

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

Быстрая разработка программ

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

По-английски: Rapid Application Development

Синонимы английские: RAD

См. также: Автоматизированное программирование

• - - установление соответствия содержания образовательных программ требованиям нормативных документов, являющихся составной частью государственного стандарта в соответствующей области образования...

  Педагогический терминологический словарь

• - Быстрорастущая сельскохозяйственная культура, высаживаемая на земле, доступной только в течение короткого периода времени, например между посадками основной культуры, или – иногда – культура, высаживаемая между...

  Словарь бизнес терминов

• - выработка стратегического замыла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, состояние, обсуждение, принятие плановых, проектных,...

  Большой бухгалтерский словарь

• - ".....

  Официальная терминология

• - 1) река в Земле Войска Донского, левый приток Донца. Берет начало во 2-м Донском округе, пересекает юго-восточный угол Донецкого и в 1-м Донском округе впадает в Донец, выше Усть-Быстрянской станицы...
• - Иркутской губернии и уезда, правый приток реки Иркут, берет начало в хребте Хамар-Дабан, двумя истоками, вершины которых находятся в гранитных ущельях...

  Энциклопедический словарь Брокгауза и Евфрона

• - река в Ростовской области РСФСР, левый приток Северского Донца. Длина 218 км, площадь бассейна 4180 км2. Течёт по равнине. Питание преимущественно снеговое. В верховьях Б. и её притоки летом пересыхают...

  Большая Советская энциклопедия

• - См. forme allegro...

  Пятиязычный словарь лингвистических терминов

• - См. СТРОГОСТЬ -...
• - См....

  В.И. Даль. Пословицы русского народа

• - См. ПОРА - МЕРА -...

  В.И. Даль. Пословицы русского народа

• Словарь синонимов

• - сущ., кол-во синонимов: 2 фаст-фуд фастфуд...

  Словарь синонимов

• - сущ., кол-во синонимов: 1 чес...

  Словарь синонимов

• - сущ., кол-во синонимов: 1 игра...

  Словарь синонимов

• - сущ., кол-во синонимов: 1 река...

  Словарь синонимов

"Быстрая разработка программ" в книгах

РАЗРАБОТКА ПРОГРАММ