Подход RAD

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

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

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

• менее 1000 функциональных элементов - один человек;
• 1000 - 4000 функциональных элементов - одна команда разработчиков;
• более 4000 функциональных элементов - 4000 функциональных элементов на одну команду разработчиков.
• Итак, перечислим основные принципы методологии RAD:
• разработка приложений итерациями;
• необязательность полного завершения работ на каждом из этапов жизненного цикла;
• обязательность вовлечения пользователей в процесс разработки ИС;
• необходимость применения CASE-средств, обеспечивающих целостность проекта;
• применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
• необходимость использования генераторов кода;
• использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
• тестирование и развитие проекта, осуществляемые одновременно с разработкой;
• ведение разработки немногочисленной хорошо управляемой командой профессионалов;
• грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

 
 
 

 

       2. Применение подхода  RAD. Его отличие  

      2.1 Отличие подхода RAD от традиционного 

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

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

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

• определяется необходимость распределения данных;
• производится анализ использования данных;
• производится физическое проектирование базы данных;
• определяются требования к аппаратным ресурсам;
• определяются способы увеличения производительности;
• завершается разработка документации проекта.

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

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

      2.2. Опыт применения методологий RAD в конкретных проектах

      (на  примере Национального  Банка)

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

      Использование современных технологий разработки и сопровождения программного обеспечения (в частности подход RAD) дало новые возможности:

• Гибкость ориентации на "ролевые" функции
• Переносимость ПО на другие платформы без перепрограммирования
• Более высокая производительность в разработке и сопровождении
• Упрощение реализации новых функциональных задач без перепрограммирования

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

      Рис. 1. Архитектура информационной системы

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

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

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

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

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

      Результаты  третьего прототипа были аналогичны.  

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

      Таблица 1. Таблица характеристик проекта 

 

      Характеристики  проекта при традиционном подходе: Сложность проекта ~ 1850 ф.т. Типичная норма выработки - 18 ф.т. на человеко-месяц Проект потребует - 103 человеко-месяца 5 человек - более 20 месяцев при спиральной модели жизненного цикла: Сложность проекта ~ 1850 ф.т. Проект потребовал - 38 человеко-месяцев Норма выработки - 48,5 ф.т. на человеко-месяц. 
 
 
 
 
 

        
 
 
 
 
 
 
 
 
 
 

      Рис. 2. Структура рабочих мест группы RAD

      Высокая производительность проекта достигалась за счет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологической цепочки (мост SR-(JAM), использования средств конфигурационного управления (PVCS), средства автоматизации тестирования QualityWorks.  
 

      2.3. Применение подхода  RAD в других областях 

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

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

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

      Таблица 2. Определение размера приложения по методологии RAD