Автор работы: Пользователь скрыл имя, 08 Января 2013 в 21:58, реферат
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:
• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.
· необходимость применения CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
·
необходимость использования
·
использование
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
·
грамотное руководство
2. Применение подхода
RAD
. Его отличие
2.1 Отличие подхода
RAD
от традиционного
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ
каждой отдельной команды
· определяется необходимость распределения данных;
· производится анализ использования данных;
· производится физическое проектирование базы данных;
· определяются требования к аппаратным ресурсам;
· определяются способы увеличения производительности;
· завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки информационных систем не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая информационная система, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
2.2. Опыт применения методологий RAD в конкретных проектах
(на примере Национального Банка)
При использовании методологии
проектирования от данных при разработке
системы надзора для
Использование современных технологий разработки и сопровождения программного обеспечения (в частности подход RAD) дало новые возможности:
· Гибкость ориентации на "ролевые" функции
· Переносимость ПО на другие платформы без перепрограммирования
·
Более высокая
· Упрощение реализации новых функциональных задач без перепрограммирования
На этапе проектирования
системы концептуальная модель данных
была преобразована в реляционную
модель данных (структуру базы данных),
создана архитектура
При создании системы была реализована спиральная модель жизненного цикла, было получено четыре прототипа системы, разработка каждого прототипа заняла четыре недели. В конце четвертого цикла прототипирования была получена полностью функциональная система, которая бала передана заказчику для опытной эксплуатации.
При создании первого прототипа
были зафиксированы внешние
В результате предъявления первого
прототипа заказчику были получены
протокол рассмотрения итогов создания
прототипа, список замечаний по составу
ролевых функций, список замечаний
по составу реализованных в базе
данных системы сущностей предметной
области, соглашение по внешнему виду
системы с приложением к
При реализации второго прототипа были зафиксированы перечень и состав ролевых функций системы и способы их реализации, структура базы данных системы, проверены выполнения требований к первому прототипу и сбор замечаний по функциональности экранов и логикам формирования отчетов.
Результатами второго прототипа явились протокол рассмотрения итогов создания 2-го прототипа, список замечаний по функциональности экранов и логикам формирования отчетов, приложение к протоколу в виде бумажных копий экранов с замечаниями на них.
Результаты третьего прототипа были аналогичны.
Перед вводом системы в опытную эксплуатацию были созданы рабочая база данных системы, рабочие места пользователей, системы автоматизированного версионного управления версиями ПО и автоматизированного сбора замечаний, проведено обучение пользователей.
Таблица 1. Таблица характеристик проекта
Объекты проекта
Общее количество
Файлы экранов
217
Файлы отчетов
74
Файлы меню
33
Файлы моделей архитектуры
41
Файлы моделей данных
18
Характеристики проекта при традиционном подходе: Сложность проекта ~ 1850 ф.т. Типичная норма выработки - 18 ф.т. на человеко-месяц Проект потребует - 103 человеко-месяца 5 человек - более 20 месяцев при спиральной модели жизненного цикла: Сложность проекта ~ 1850 ф.т. Проект потребовал - 38 человеко-месяцев Норма выработки - 48,5 ф.т. на человеко-месяц. (см. Приложение рис. 2)
Высокая производительность проекта достигалась за счет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологической цепочки (мост SR-(JAM), использования средств конфигурационного управления (PVCS), средства автоматизации тестирования QualityWorks.
2.3. Применение подхода
RAD
в других областях
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки информационных систем с максимальным повторным использованием программных компонентов, определяется следующим образом:
Таблица 2. Определение размера приложения по методологии RAD
< 1000 функциональных элементов
один человек
1000-4000 функциональных элементов
одна команда разработчиков
> 4000 функциональных элементов
4000 функциональных элементов на одну команду разработчиков
Заключение
Недостатки традиционного
(каскадного) подхода к построению
жизненного цикла программного обеспечения
хорошо известны. Жестко зафиксированные
требования к разрабатываемой системе
в самом начале жизненного цикла,
отсутствие в процессе реализации участия
конечного пользователя приводят к
тому, что проект растягивается на
годы, выходит за рамки установленного
бюджета, полученная в результате система
не удовлетворяет требованиям
Развитие информационных
технологий, появление средств
Наиболее широкое
Следует, однако, отметить, что
методология RAD, как и любая другая,
не может претендовать на универсальность,
она хороша в первую очередь для
относительно небольших проектов, разрабатываемых
для конкретного заказчика. Если
же разрабатывается типовая
В качестве итога перечислим основные принципы методологии RAD:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов жизненного цикла;
· обязательное вовлечение пользователей в процесс разработки информационных систем;
· необходимое применение CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
·
необходимое использование
·
использование
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
·
грамотное руководство
Информация о работе Программное обеспечение по методологии RAD