<<
>>

1.6.2. RAD -технологии прототипного создания приложений

Одним из возможных подходов к разработке ПО в рам­ках спиральной модели ЖЦ является получившая в после­днее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development).
Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

♦ небольшую команду программистов (от 2 до 10 чело­век);

♦ короткий, но тщательно проработанный производствен­ный график (от 2 до б мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

♦ фазы анализа и планирования требований;

♦ фазы проектирования;

♦ фазы построения;

♦ фазы внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руко­водством специалистов-разработчиков. САБЕ-средства исполь­зуются для быстрого получения работающих прототипов при­ложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рас­сматриваются процессы системы. Анализируется и при необ­ходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный про­тотип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оцени­вается количество функциональных элементов разрабатыва­емой системы и принимается решение о разделении АИС на подсистемы, поддающиеся реализации одной командой раз­работчиков за приемлемое для ИАВ-проектов время — при­мерно 60—90 дней. С использованием CASE-средств проект распределяется между различными командами (делится фун­кциональная модель). Результатом данной фазы должны быть:

♦ общая информационная модель системы;

♦ функциональные модели системы в целом и подсис­тем, реализуемых отдельными командами разработчи­ков;

♦ точно определенные с помощью CASE-средства интер­фейсы между автономно разрабатываемыми подсисте­мами;

♦ построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

♦ определяется необходимость распределения данных;

♦ производится анализ использования данных;

♦ производится физическое проектирование базы дан­ных;

♦ определяются требования к аппаратным ресурсам;

♦ определяются способы увеличения производительности;

♦ завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетво­ряющая всем согласованным требованиям.

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

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

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

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

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

♦ разработка приложений итерациями;

♦ необязательность полного завершения работ на каж­дом из этапов жизненного цикла;

♦ обязательное вовлечение пользователей в процесс раз­работки АИС;

♦ необходимое применение САБЕ-средств, обеспечива­ющих целостность проекта;

♦ применение средств управления конфигурацией, об­легчающих внесение изменений в проект и сопровож­дение готовой системы;

♦ необходимое использование генераторов кода;

♦ использование прототипирования, позволяющего пол­нее выяснить и удовлетворить потребности конечного пользователя;

♦ тестирование и развитие проекта, осуществляемые одновременно с разработкой;

♦ ведение разработки немногочисленной хорошо управ­ляемой командой профессионалов;

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

<< | >>
Источник: Балдин К. В., Уткин В. Б.. Информационные системы в экономике: Учебник. — 5-е изд. — М.: Издательско-торго- вая корпорация «Дашков и К0», — 395 с.. 2008 {original}

Еще по теме 1.6.2. RAD -технологии прототипного создания приложений:

  1. ИСТОРИЯ СОЗДАНИЯ ИГРОВЫХ ТЕХНОЛОГИЙ
  2. Приложение 5. Бизнес-план создания реабилитационного центра
  3. 6. Технология создания и развития успешной франшизы
  4. СОЗДАНИЕ КОМАНДЫ ЛИДЕРОВ - ПАРАДОКС ИЛИ ТЕХНОЛОГИЯ?
  5. 60. ПЕДАГОГИЧЕСКИЕ ТЕХНОЛОГИИ И ТЕХНОЛОГИЯ ОБУЧЕНИЯ
  6. 78. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
  7. Резкие изменения технологии производства
  8. 4.4.2. Сервисно-ориентированные технологии
  9. приложения
  10. Приложение 4
  11. ГРУППА ПО РАЗВИТИЮ ТЕХНОЛОГИЙ
  12. Глава 1.Технологии Интернет
  13. Приложение N 4 к Листу 02
  14. Технология
  15. Создание отдела
  16. ПРИЛОЖЕНИЯ
  17. 40 ТРАНСФЕРТ ТЕХНОЛОГИЙ
  18. Отечественные социальные технологии