Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Л12(УЖЦИС).doc
Скачиваний:
3
Добавлен:
09.11.2018
Размер:
2.92 Mб
Скачать

2.2.3. Мoдель быстрoй разрабoтки прoграммных

прилoжений (RAD)

В 1980-х гг. компани я IBM начала применять метод быстрой

разработки приложений (Rapid Application Development, RAD).

• пользовательское описани е — выполняются сбор пользо-

вательской информаци и и построение моделей процессов пред-

метной области с использованием автоматизированных инстру-

ментальных средств при активном участии заказчиков;

• конструирование - выполняется детализированное проек-

тирование, включающее разработку (кодирование и тестирование)

системы, а также поставку программного продукта заказчику;

• перевод на новую систему эксплуатации - проведение

совместно с заказчиком приемочных испытаний , установка си-

стемы и обучение пользователей.

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

Преимущества модели RAD

Использование модели RAD при проектировании информа-

ционных систем в определенных условиях может выявить сле-

дующие преимущества:

• применение мощны х инструментальных средств позволя-

ет сократить время цикла разработки всего проекта;

• создание системы выполняется коллективом , знающи м

процессы предметной области;

• уменьшаются затраты благодаря сокращенном у времени

цикла, а также меньшему количеству задействованных разра-

ботчиков;

• уменьшается риск, связанный с соблюдением графика ра-

бот, за счет сокращенного времени цикла;

• сведение к минимуму риска того, что система не будет

удовлетворять требованиям предметной области;

• основное внимание уделяется не документации, а кодиро-

ванию (программированию), при этом поддерживается прин-

цип «получаете то, что видите» (What you see is what you get,

WYSIWYG);

• использование различных стандартных методологий мо-

делирования: моделирование потоков данных (описание мето-

дов передачи информации , источников генерирования инфор-

мационных потоков, кем и куда направляется информационный

поток, каким образом обрабатывается); моделирование данных

(выполняется идентификаци я объектов данных, их атрибутов и

взаимосвязей); моделирование бизнес-процессов (методы струк-

турного и объектно-ориентированного моделирования бизнес-

процессов); генерирование приложения (объектно-ориентиро-

ванные методы);

• повторное использование компонентов уже существующих

программ.

Недостатки модели RAD

В случае ошибочного выбора модели RAD для реализации

проекта могут проявиться следующие недостатки:

• низкое качество программного продукта, если заказчики

не могут принимать активное участие в процессе создания сис-

темы на протяжении всего ЖЦ ;

• необходимость достаточного количества высококвалифи-

цированных разработчиков, умеющих пользоваться выбранны-

ми инструментальными средствами разработки;

• необходимость наличия готовых компонентов проектиру-

емой системы до начала проекта.

Область применения модели RAD

Определим ряд условий и положений, при выполнении ко-

торых менеджеру проекта целесообразно выбрать модель RAD:

• для систем, которые поддаются моделированию и основа-

ны на использовании компонентны х объектов;

• для систем, требования к которым хорош о известны;

70

для систем, если заказчик может принимать активное уча-

процессе создания системы на протяжении всего Ж Ц и

навыки по использованию автоматизированных инстру-

ментальных средств разработки и организаци и коллективной

работы;

• проект имеет сокращенны е сроки выполнени я (не более

60 дней);

• для систем , в которых функциона л реализуется в виде

последовательных действий;

• имеется автоматизированно е хранилищ е программны х

продуктов, компоненты которых можно повторно использовать

в новых проектах;

• для систем, предназначенных для концептуальной проверки

возможностей и эффективности автоматизации;

• для систем, которые имею т небольшое количество авто-

матизируемых бизнес-процессов предметной области;

• когда затраты и соблюдение графика не являются самым и

важными критериям и процесса создания системы (например,

при разработке внутренних инструментальных средств);

• при невысокой степени технических рисков;

• когда команде, работающей над проектом, знаком а пред-

метная область и она обладает навыками в использовании средств

разработки.