40601

Подход RАD. Стадии реализации и внедрения

Лекция

Информатика, кибернетика и программирование

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

Русский

2013-10-17

19.83 KB

0 чел.

Занятие №16

Подход RАD. Стадии реализации и внедрения

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

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

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

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

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

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

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

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

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

< 1000 функциональных элементов

один человек

1000-4000 функциональных элементов

одна команда разработчиков

> 4000 функциональных элементов

4000 функциональных элементов на одну команду разработчиков

В качестве итога перечислим основные принципы методологии RAD:

  1.  разработка приложений итерациями;
  2.  необязательность полного завершения работ на каждом из этапов жизненного цикла;
  3.  обязательное вовлечение пользователей в процесс разработки ИС;
  4.  необходимое применение CASE-средств, обеспечивающих целостность проекта;
  5.  применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
  6.  необходимое использование генераторов кода;
  7.  использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
  8.  тестирование и развитие проекта, осуществляемые одновременно с разработкой;
  9.  ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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


 

А также другие работы, которые могут Вас заинтересовать

11621. Исследование напряженно-деформированного состояния стержня при поперечном изгибе 570.5 KB
  ЛАБОРАТОРНАЯ РАБОТА ПО МЕХАНИКЕ СПЛОШНЫХ СРЕД № 3 Тема:Исследование напряженно-деформированного состояния стержня при поперечном изгибе Задание Для заданной упругой системы рис. 1 исследовать напряженно-деформированное состояние при поперечном изг...
11622. Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose 2003 249 KB
  Лабораторная работа №1 Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose 2003 Работа над моделью в среде IBM Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования которая отражает функциональное назначение...
11623. Общая характеристика CASE-средства IBM Rational Rose 2003 и его функциональные возможности 302.5 KB
  Общая характеристика CASEсредства IBM Rational Rose 2003 и его функциональные возможности. Среди всех фирмпроизводителей CASEсредств именно компания IBM Rational Software Corp. до августа 2003 года Rational Software Corp. одна из первых осознала стратегическую перспективность развития объектноорие...
11624. Особенности разработки диаграмм классов в среде IBM Rational Rose 2003 176.5 KB
  Лабораторная работа №2 часть1 Особенности разработки диаграмм классов в среде IBM Rational Rose 2003 Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектноориентированной программной системы и...
11625. Добавление и редактирование атрибутов классов 163.5 KB
  Лабораторная работа №2 часть2 Добавление и редактирование атрибутов классов Из всех графических элементов среды IBM Rational Rose 2003 класс обладает максимальным набором свойств главными из которых являются его атрибуты и операции. Поскольку именно диаграмма классов исполь...
11626. Добавление отношений на диаграмму классов и редактирование их свойств 183 KB
  Лабораторная работа №2 часть3 Добавление отношений на диаграмму классов и редактирование их свойств Диаграмма классов является логическим представлением структуры модели поэтому она должна содержать столько классов сколько необходимо для реализации всего проек
11627. Определение относительной теплоемкости газа 49 KB
  ОТЧЁТ по лабораторной работе № 4 Определение относительной теплоемкости газа. Цель работы: определить теплоемкость воздуха при постоянном объеме и температуре. Схема установки и расчётная формула: 4
11628. ГЕОДЕЗИЧЕСКИЙ КОНТРОЛЬ ОСАДОК ЗДАНИЙ И СООРУЖЕНИЙ ПРОМЫШЛЕННЫХ ПРЕДПРИЯТИЙ 922.5 KB
  Наблюдения за деформациями сооружений преследуют как научные цели (обоснование правильности теоретических расчетов устойчивости сооружений), так и производственно-технические (нормальная эксплуатация сооружения и принятие профилактических мер при выявленных недопустимых величинах деформаций).
11629. Оцінка економічних результатів діяльності аптечного підприємства ООО «Євроаптека» 272.5 KB
  Важлива роль в реалізації цього завдання відводиться аналізу господарської діяльності аптечного підприємства. З його допомогою виробляються відображення і тактика розвитку підприємства, обгрунтовуються плани і управлінські рішення, здійснюється контроль за виконанням, виявляються резерви підвищення ефективності торгової діяльності, здійснюються результати діяльності підприємства, його підрозділів і працівників.