Технология (методология) быстрой разработки приложений RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD ( Rapid Application Development
). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); .
при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком
должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств.
Члены коллектива должны также уметь трансформироват ь в рабочие прототипы предложения конечных пользователей.
по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения.
и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности.
выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз.
Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п.
должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений..
Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы.
Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально.
При необходимости для каждого элементарного процесс а создается частичный прототип : экран, диалог, отчет, Устраняющий неясности или неоднозначности.
Определяются требования разграничения доступа к данным.
происходит определение набора необходимой документации
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней.
С использованием CASE-средств проект распределяется между различными командами ( делится функциональная модель).
должны быть: ₽ общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные средства интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы.
Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте,
в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера.
частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств
. на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. :
Тестирование системы осуществляется непосредственно в процессе разработки.
каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными
, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом
. физическое проектирование системы
определяется необходимость распределения данных; производится анализ использования данных;
производится физическое проектирование базы данных; определяются требования к аппаратным ресурсам; определяются способы увеличения производительности;
завершается разработка документации проекта. .
является готовая система, удовлетворяющая всем согласованным требованиям
производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой
). достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы.
. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика..
Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками,
выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки.
Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки
для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и
приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособн ы, что в данном случае исключается.
производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.)
Подобная метрика не зависит от языка программирования, на котором ведется разработка.
, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
< 1000 функциональных элементов
1000-4000 функциональных элементов
4000 функциональных элементов на одну команду разработчиков
. ⇐ Предыдущая 3 4 5 6 7 8 9 10 11 12 Следующая ⇒ Целью данного этапа является построение моделей базы данных. Для этого необходимо: 1. Определить состав и содержание информации, используемой в данной предметной области, в том числе составить перечень задач и запросов, указать входные и выходные данные; .
2. Выявить сущности, в том числе определить атрибуты каждой сущности и требования к ним; определить ключ каждой сущности; разработать, если необходимо, классификаторы и кодификаторы сущностей; определить требования к сущностям, вытекающие из бизнес-правил предметной области ;
3. Выявить связи между сущностями. 4. Построить ER-модель данных.
5. Построить реляционную модель с учетом нормализации
Оптимально использовать «нисходящую» стратегию проектирования БД, начиная с выделения сущностей, отражающих основные бизнес-процессы, и связей между ними.
Для наглядности выделенные сущности представляют в виде ER-диаграммы
На ER-диаграмме отмечены лишь основные атрибуты сущностей. При реализации конкретного магазина может потребоваться дополнительная информация.
. Для учета этой информации необходимо будет ввести новые сущности и/или добавить атрибуты к уже имеющимся сущностям.
Детальная проработка атрибутов и будет следующим действием «нисходящей» стратегии проектирования.
Завершив определение сущностей, их атрибутов и связей между сущностями, можно переходить к описанию таблиц реляционной БД, моделирующих сущности и связи
СПАСИБО ЗА ВНИМАНИЕ
