Быстро, качественно, дешево — выберите три из трех

Нарисуйте мне программу

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

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 зависит от вовлеченности заказчика в работу. Если он не может принять участие в очередном обсуждении проекта, работа может приостановиться.

- пользователь должен всегда принимать участие на всех этапах разработке;

- необходимо достаточное количество высококвалифицированных и хорошо обученных разработчиков;

- жесткие временные ограничения (60-90 дней)

- существует риск, что работа над проектом никогда не будет завершена;

- RAD уже не молодая методология — ей слегка за 30, — но она по-прежнему используется в разработке программного обеспечения и сдавать свои позиции не собирается. Ведь для методологии главное — не возраст, а эффективность.

1.2 методология CDM. Ориентирована на каскадную модель ЖЦ. Технология в основном ориентирована на разработку ПО, в котором приоритетным является разработка и использование базы данных, в том числе конверсия базы данных при переходе на новое ПО.

При этом технология имеет две разновидности: CDM-сlassic и CDM-fast track. CDM-classic – это технология разработки, рассчитанная на крупномасштабные проекты с временем от восьми месяцев до трех лет, CDM fast track – для разработки маленьких проектов со временем функционирования от четырех до 16 месяцев.

CDM-classic состоит из 6 фаз (определение, анализ, дизайн, построение, передача. Работа).

CDM-fast track состоит из 4 фаз(определение, моделирование требований, дизайн и построение, передача в работу). основными характеристиками данного продукта является ориентация на быстрое получение продукта, следовательно, разработка имеет короткий цикл и должна содержать небольшой объем работ.

Обе разновидности методологии включают в себя 11 процессов.

Процессы CDM:

· определение бизнес-требований, или постановка задачи (Business Requirements Definition);

· исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспечить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений;

· определение технической архитектуры (Technical Architecture);

· проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;

· проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;

· конвертирование данных (Data Conversion). Цель этого процесса - преобразовывать, перенести и проверить согласованность и непротиворечивость данных, оставшихся в наследство от "старой" системы и необходимых для работы в новой системе;

· документирование (Documentation);

· тестирование (Testing);

· обучение (Training);

· внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации старых систем;

· поддержка и сопровождение (Post-System Support)

 Теперь проведем анализ модели ЖЦ, используемой в каждой из технологий. CDM-classic является классическим примером методологии основанной на каскадной модели ЖЦ, здесь четко определены фазы и задачи для каждой фазы, есть точки перехода на следующую фазу. Вариант технологии CDM fast track представляет собой итерационную модель с элементами спирального или инкрементального развития на каждом из этапов.

Таким образом, Методология Oracle CDM — это совокупность точно определенных процессов заказной разработки с разными режимами управления. Методология, в основе которой лежит CASE-технология, обеспечивает точное определение бизнес-требований в самом начале процесса разработки и их сохранение на протяжении всего процесса разработки. Методология CDM радикально повышает возможность успешной реализации проекта.

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

Достоинства:

- Уменьшение себестоимости разработки.

- Уменьшение количества ошибок, снижение цены ошибки.

-  Прогнозирование сроков, предсказуемость затрат и результатов.

- Снижение рисков работодателя, независимость от персоналий.

Недостатки:

- Жесткая ориентация на линейку продуктов Oracle.

- Сложна в использовании.

- Необходимость обучения методологии.

 

1.3. Методология RUP (смотри в тетрадь)

1.4. Методология DATARUN.

Одной из наиболее распространенных в мире методологий является методология проектирования данных DATARUN (компания CSA, США). Методология DATARUN создавалась для проектирования и разработки ПО и ИС для переносимых распределенных ИС, работающих по архитектуре клиент-сервер. Методология использует современные инструменты и средства моделирования, быстрой разработки и прототипирования.

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

Высокая динамичность рынка требует от организаций быстрого развития информационно- технологической инфраструктуры. Одной из ее наиболее важных и дорогостоящих составляющих является информационная система, для реализации которой применяются современные технологии: архитектура клиент/сервер, распределенные базы данных, сложные сети коммуникаций, развитые интерфейсы пользователя. Все это ставит перед разработчиком проблему выбора инструментальных средств и технологий для ведения проекта.
Создание сложной информационной системы невозможно без единого интегрированного подхода к процессу разработки. Такой подход часто оформляется в виде коммерчески доступной методологии проектирования. Методология служит двум целям: 1) обеспечивает концептуальную основу для всего процесса разработки; 2) предоставляет технологию руководства проектом.
Многие методологии применялись в течение ряда лет с разной степенью успеха. Часто разнообразие используемых в них моделей приводит к получению огромного количества документации, не сосредоточенной на результатах. Множественные перекрывающиеся модели процессов и данных создают избыточность, которая преподносится как перекрестный контроль.
DATARUN - уникальная концепция в ряду методов. Эта методология гарантирует, что на каждой стадии выполняется только существенная для целей проекта работа, облегчающая быстрое создание приложений. Повторения и избыточность в спецификациях исключаются, создается управляемая, основанная на моделях форма итеративной разработки. Исходные версии объектов доступны для непосредственного использования на следующих фазах проектного цикла. Создаваемая информационная система описывается рядом последовательных моделей, каждая из которых является развитием предыдущей и наследует правила и данные, определенные в более ранних моделях. Наследование свойств позволяет многократно использовать различные спецификации на всех уровнях прикладного проекта.
Методология DATARUN ведет заказчика и разработчика информационной системы по всем этапам жизненного цикла проекта, от стадии первоначальной экономической оценки затрат на проект до выхода реального приложения. Она позволяет координировать и контролировать работу всех групп лиц, занятых в работе над проектом.
Методология DATARUN обеспечена средствами автоматизированной поддержки:

• Для управления проектной деятельностью имеется система Software Engineering Companion, позволяющая детально расписывать ведение проекта, распределять проектные роли среди исполнителей, контролировать выполнение заданий.
• Детальное изложение техник моделирования данных и бизнес-функций, проектирования баз данных, создания приложений содержится в гипертекстовой системе Software Engineering Guidelines.
• Автоматизация проведения проектных работ обеспечивается CASE-системой SILVERRUN.

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

 

Создание приложений

Из модели базы данных генерируется код для ее создания на сервере. Программируются системные процессы. При этом возможно разнесение процессов по узлам распределенной системы (часть процессов реализуется как хранимые процедуры на сервере, часть как сервисы монитора транзакций, часть - как программы клиентской части). Интерфейс приложений (обычно составляющий до 70-80% всей системы) может быть быстро создан перенесением соответствующей ему подсхемы базы данных в среду языка 4-го поколения).

Интеграция приложений

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

Подход DATARUN преследует две цели:

• определить стабильную структуру, на основе которой будет строиться ИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы организации;
• спроектировать ИС на основании модели данных.

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

1.5. методология MSF. Microsoft Solutions Framework (модель разработки приложений Microsoft) — это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять информационные системы на основе технологий и инструментальных средств Microsoft.

MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. В силу сказанного MSF не есть чисто теоретический взгляд на процесс разработки, напротив, методология предлагает не только концепции и модели, но и сугубо практические приемы и советы.

Пять «белых книг» MSF

MSF разработана как комплекс отдельных компонентов — моделей и дисциплин. Всего их пять, и они описаны в пяти «белых книгах» (white papers) MSF.

Моделей используется две:

• модель команды;
• модель процесса.

А дисциплин в MSF три:

• управление проектами;
• управление рисками;
• управление готовностью.

Рассмотрим их.

Модель команды MSF

Команда разработчиков — главный стратегический ресурс компании, определяющий успех проекта. В традиционной практике команды организованы иерархически — от руководителя до работников низшего звена, например:

Модель процесса MSF

Еще один важный компонент методологии MSF — модель процесса, то есть последовательность действий, необходимых для построения IT-решения. Модель не предписывает конкретных процедур и не содержит жестких формализованных требований к процессу — при создании MSF компания Microsoft стремилась сделать ее гибкой и адаптируемой к условиям любого проекта. В MSF объединились две концепции разработки: «Водопад» и спиральная модель.

От «Водопада» MSF досталась система вех (milestones) — особых точек в конце каждой фазы процесса, отвечающих заданным критериям завершения фазы. В этих точках команда рассматривает результаты своего труда и отвечает на вопросы «Сделали ли мы все, что планировали?», «Работает ли решение так, как нужно заказчику?», «Готовы ли мы двигаться дальше или необходимо уделить внимание доработкам?». Чтобы перейти на следующий этап, необходимо дать большинство положительных ответов.

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

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

Весь процесс разработки в MSF разбит на отдельные итерации. Каждая проходит несколько этапов (фаз).

Выработка концепции (Visioning)
2. Планирование (Planning)
3. Разработка (Developing)
4. Стабилизация (Stabilizing)
5. Внедрение (Deploying)

 

ДОСТОИНСТВА: 1)систематизация и структуризация информации в форме базы знаний;

2)нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды;

3) MSF легко масштабируется

4)минимальный размер проектной группы в MSF-проекте – 3 человека, но применять данную методологию можно для коллективов и в десятки, сотни, тысячи человек;

5) MSF не навязывает использование каких-либо конкретных инструментов и программных средств

НЕДОСТАТКИ:

Не описывает детально важнейшие роли заказчика и пользователя; не рассматриваются методы управления группой проектов

 

Нарисуйте мне программу

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

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

Изначально программист создает приложение в черновом варианте. Это могут быть наброски интерфейса и несколько пунктов меню. Если заказчика устраивает первый прототип, программа дорабатывается: добавляются новые элементы интерфейса, функциональность. С каждой итерацией приложение обрастает возможностями, и пользователь постоянно уточняет требования и задает вектор развития.

Методологию быстрой разработки RAD можно сравнить с работой художника. Сначала живописец делает эскиз. Потом создает черновой вариант картины. Затем он начинает прорабатывать элементы, добавляет детали, исправляет недочеты. Разумеется, не каждый заказчик способен по первому наброску представить себе, как будет выглядеть готовая картина, — возможно, он вообще не имеет понятия о перспективе или композиции. Но по крайней мере художнику не придется переписывать весь холст — ведь к завершению работы уже не окажется, что клиент перепутал натюрморт с пейзажем: «Нет-нет, я имел в виду сельский вид, а не корзину с фруктами!» Куда проще внести исправления в эскиз, чем в завершенное полотно.

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

 

Быстро, качественно, дешево — выберите три из трех

Три кита, на которых покоится RAD, — это скорость разработки, качество программного кода и дешевизна. Да, это та самая методология, которая предлагает не выбрать два пункта из трех, а получить все сразу.

 

Почему быстро?

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

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

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

 

Почему качественно?

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

 

Почему дешево?

Деньги — странный предмет: вот они есть, а вот их нет. Бывает, что их не хватает, и приходится прерывать разработку, когда написана еще далеко не вся запланированная функциональность. Что получит заказчик в этом случае?

Если разработчик использует методологию Waterfall, то техническое задание и спецификации на программу он получает в самом начале работы. Какую из задач решать в первую очередь, а что оставить «на десерт», решает сам разработчик — при этом не всегда четко понимая, что для пользователя важно, а что не очень. В итоге заказчик, у которого внезапно закончились средства на проект, может получить программу, в которой реализованы второстепенные задачи, но отсутствует ключевая функциональность.

При Rapid Application Development пользователь сам решает, что ему требуется в первую очередь, и постоянно получает все более функциональные прототипы — то есть, фактически, работающие версии программы. Если финансирование внезапно иссякнет — пользователь не останется у разбитого корыта.

Разработка идет быстро, и заказчик получает программу существенно раньше — а это и экономия финансов.

 

Инструментарий RAD

Методология RAD еще с конца 1980-х была нацелена на использование новейших технологий ускорения разработки — и этот фокус на инструментах автоматизации по-прежнему актуален.

Средства автоматизации разработки программ (Computer-Aided Software Engineering), или CASE-инструменты — это программные продукты для проектирования приложений. Такая система позволяет быстро создать модель программы, а затем автоматически сгенерировать программный код. Получается прототип — запускаемый модуль, который можно продемонстрировать заказчику.

 

От одноклеточного к развитому: эволюция программы

Разработка приложения по методологии RAD проходит в несколько этапов.

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

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

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

Затем в дело вступают программисты. С помощью инструментов CASE они воплощают требования в виде модели, создавая очередной прототип. Его показывают пользователю и получают обратную связь. Уточняя пожелания и требования к программе, заказчик фактически руководит разработкой.

Прототип зачастую создается на скорую руку, только для проверки концепций. Это нормально: если пользователя устраивает новая функциональность и все работает как следует, в следующей итерации разработчик «отполирует» интерфейс и код. Перфекционизм может даже вредить — на очередном этапе любую доработку пользователь может посчитать неудачной. Если программист стремится сразу сделать все идеально, его усилия окажутся напрасными.

Как только заказчик дал обратную связь, цикл начинается заново. Вырабатывается план на следующую итерацию. Если пользователя что-то не устроило в прототипе, на новом витке цикла изменения откатывают назад и реализуют альтернативный вариант.

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

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

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

Финальный этап разработки — переключение. Готовый программный продукт тестируют, развертывают на пользовательских машинах, конвертируют информацию в новый формат или «заливают» в новые базы данных, подготавливают документацию и обучают операторов работе в системе.