Когда мы рады RAD’у, а когда не рады

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

Эффективные варианты применения RAD

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

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

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

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

· Когда у вас есть коллектив хороших разработчиков и дизайнеров. Задача RAD — быстро создать качественный продукт. А это могут только профессионалы.

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

 

Преимущества 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-средстве, создает все необходимые условия для быстрого создания сложных информационных систем с высоким качеством.