Similar presentations:
Методология RAD создания средств разработки программных продуктов
1.
Методология RAD созданиясредств разработки
программных продуктов
2.
ПредысторияИдея RAD (Rapid application development— быстрая
разработка приложений) зародилась в 1980-х годах как
альтернатива устаревшей методологии Waterfall.
Каскадная модель программирования уже тогда
воспринималась как перегруженная формальностями и
недостаточно гибкая.
3.
Заказчик выдавал разработчику техническое задание и не видел результата до тех пор, покапрограмма не «сходила с конвейера» уже готовой, — и ожидания пользователя зачастую не
оправдывались.
Продукт мог оказаться слишком сложным, неудобным, а мог и устареть за время разработки. В
каскадной модели на ранних этапах работы проводится тщательное планирование, но это не
помогает предусмотреть все риски и сложности. Поэтому проект дорожает, а время — уходит
впустую.
4.
В 1988 году американский инженер-программист БарриБоэм (Barry Boehm) опубликовал статью «Спиральная
модель разработки и совершенствование программного
обеспечения», в которой предложил создавать не цельную
программу, а выпускать ряд прототипов, каждый из которых
содержит
дополнительную
или
расширенную
функциональность по сравнению с предыдущим.
5.
Пользователь может изучить и попробовать в деле каждый прототип. Получая обратную связь,разработчик дорабатывает приложение, пока заказчик не получит готовый продукт, который
полностью его устраивает.
6.
Что предлагает RADRAD предлагает вести разработку так, чтобы заказчик
мог увидеть практические результаты на самых
ранних этапах — и скорректировать техническое
задание, если это будет необходимо. Очередной цикл
разработки начинается не раньше, чем пользователь
оценил результаты предыдущего.
7.
Изначально программист создает приложение в черновом варианте. Это могут быть наброскиинтерфейса и несколько пунктов меню. Если заказчика устраивает первый прототип, программа
дорабатывается: добавляются новые элементы интерфейса, функциональность. С каждой итерацией
приложение обрастает возможностями, и пользователь постоянно уточняет требования и задает
вектор развития.
8.
Методологию быстрой разработки RAD можно сравнить сработой художника. Сначала живописец делает эскиз.
Потом создает черновой вариант картины. Затем он
начинает прорабатывать элементы, добавляет детали,
исправляет недочеты.
Разумеется, не каждый заказчик способен по первому
наброску представить себе конечный продукт. Куда проще
внести исправления в эскиз, чем в завершенное полотно.
9.
БазаТри кита, на которых покоится RAD,
— это скорость разработки, качество
программного кода и дешевизна. Да,
это та самая методология, которая
предлагает не выбрать два пункта из
трех, а получить все сразу.
10.
СкоростьМетодология RAD требует, чтобы работающие прототипы
создавались максимально часто.
Продолжительность одного производственного цикла —
от выработки требований до демонстрации пользователю
(то есть одной итерации) — от одного дня до трех недель.
11.
Во многих случаях разумным вариантом будет разделить приложение на функциональные модули,каждый из которых можно создавать и тестировать отдельно.
Модули разрабатываются параллельно разными командами, но по общей схеме: от простых
прототипов к более сложным, с регулярным контролем со стороны заказчика. В конце работы или
каждой итерации модули соединяют в цельное программное решение.
12.
КачествоПользователь может определять, какую функциональность он
хочет видеть реализованной в следующей итерации. Постоянное
взаимодействие заказчика и разработчика гарантирует, что
приложение будет развиваться в нужном направлении,
интерфейс будет удобным, а функциональность востребованной.
Такая схема избавляет программиста от лишней работы и
исключает ситуации, когда часть программы приходится
переделывать с нуля из-за неверно понятых вводных.
13.
ДешевизнаВ RAD пользователь сам решает, что ему требуется в первую
очередь, и постоянно получает все более функциональные
прототипы — то есть, фактически, работающие версии
программы. Если финансирование внезапно иссякнет —
пользователь не останется у разбитого корыта.
Разработка идет быстро, и заказчик получает программу
существенно раньше — а это и экономия финансов.
14.
Этапы разработки приложения по методологииRAD
Первый — анализ и планирование. Здесь определяются цели и задачи проекта — что и для чего
будет делать приложение. Совместными усилиями заказчик и разработчик выявляют риски,
устанавливают сроки и бюджет, определяют ключевые моменты разработки.
В начале очередного цикла разработки заказчик и программист вместе формулируют требования,
которым должна соответствовать очередная версия.
15.
Затем начинается пользовательское проектирование. На этомэтапе создается серия работающих прототипов программы.
Каждый очередной прототип отличается от предыдущего
дополненной функциональностью, изменениями дизайна и
производительности. Процесс создания одного прототипа
называется итерацией. RAD не накладывает жестких
временных рамок на продолжительность одной итерации, но
рекомендует, чтобы она была максимально быстрой.
16.
Затем в дело вступают программисты. С помощью инструментовCASE они воплощают требования в виде модели, создавая
очередной прототип. Его показывают пользователю и получают
обратную связь. Уточняя пожелания и требования к программе,
заказчик фактически руководит разработкой.
Как только заказчик дал обратную связь, цикл начинается
заново. Вырабатывается план на следующую итерацию. Если
пользователя что-то не устроило в прототипе, на новом витке
цикла изменения откатывают назад и реализуют
альтернативный вариант.
17.
От прототипа к прототипу программный продукт приобретаетвид завершенного приложения. Итерации выполняются, пока
не будут реализованы последние требования.
Если заказчик принял прототип — уточняем требования к
функциональности, прорабатываем ее более детально,
планируем новую. Обговариваем визуальные элементы и
интерфейсы.
18.
Когда моделирование завершено, начинаетсяконструирование: автоматически сгенерированный код
дорабатывается и совершенствуется.
Финальный этап разработки — переключение. Готовый
программный продукт тестируют, развертывают на
пользовательских машинах, конвертируют информацию
в новый формат или «заливают» в новые базы данных,
подготавливают документацию и обучают операторов
работе в системе.
19.
Эффективные варианты применения RAD1.
Если проект легко делится на независимые или слабосвязанные модули.
2.
Если требования к программному обеспечению быстро меняются
3.
В условиях ограниченного бюджета
4.
Когда у пользователя нет ясного представления, как должен выглядеть и работать продукт.
5.
Когда у вас есть коллектив хороших разработчиков и дизайнеров
6.
Если пользователь готов активно участвовать в проекте на протяжении всей работы
20.
Преимущества RADРазработка выполняется быстро и дешево.
RAD обеспечивает приемлемый для пользователя уровень качества.
Пользователь получает в итоге именно ту функциональность,
которую хочет.
Пользователь может оперативно внести изменения в проект.
Функциональность, которая нужна заказчику «еще вчера», можно
разработать в первую очередь, и использовать, даже если
остальные части программы еще не готовы.
21.
Недостатки RADRAD применима для больших команд.
RAD зависит от вовлеченности заказчика в работу.
Если он не может принять участие в очередном
обсуждении проекта, работа может приостановиться.
22.
FinИсточник: https://gb.ru/posts/rad_methodology