Модель быстрой разработки приложений жизненного цикла программного обеспечения
Метод быстрой разработки приложений (Rapid Application Development, RAD) был предложен компанией IBM в качестве альтернативы более формальным методам, таким как каскадная модель. В среде программистов аббревиатура RAD часто ассоциируется с RAD tools, т.е. инструментальными средствами быстрой разработки приложений, среди которых можно упомянуть Delphi, C++ Builder, Visual Studio и другие среды разработки, характерной чертой которых является наличие визуального конструктора форм, что и относит их к классу RAD tools. Однако без должного уровня организационной подготовки эти среды сводятся к инструменту создания пользовательского интерфейса. Поскольку рисование интерфейса оказывается существенно проще реализации обработчиков событий (которые могут содержать довольно сложные алгоритмы), проекты, выполняемые с использованием RAD tools имеют тенденцию превращаться в заготовки навигаторов по системным меню, кнопкам быстрого вызова, спискам и т.п. Также для подобных программ характерно наличие таких недостатков, как нереализованная или непродуманная обработка ошибок при вводе данных или доступе к файлам, отсутствие инициализации и настройки интерфейсов, отсутствие контроля возможности запуска тех или иных функций. Крайне редко в программах, разработанных в Delphi и подобных средах, реализуются новые компоненты, разработка ведется в подавляющем большинстве случаев с применением тех компонентов, которые доступны по умолчанию, либо могут быть загружены в виде готовых модулей. В то же время отмечается, что метод RAD подразумевает активное участие конечного пользователя на всех этапах разработки. При этом «решающее ролевое участие конечного пользователя заключается в перемещении процесса работы от программирования и тестирования к планированию и проектированию. Пользователям приходится справляться с большим объемом работы в начале жизненного цикла, но в награду они получают систему, построенную за более короткий промежуток времени». [1] Модель RAD включает в себя следующие этапы разработки: - этап планирования требований – сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач; - пользовательское описание – совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации; - фаза конструирования («до полного завершения») – эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависят от использования генераторов кода, экранных генераторов и других типов производственных инструментов; - перевод на новую систему эксплуатации – эта фаза включает проведение пользователями приемочных испытаний, установку системы и обучение пользователей.
Преимущества модели RAD
- время цикла разработки для всего проекта можно сократить благодаря использованию мощных инструментов; - требуется меньшее количество специалистов, поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области; - существует возможность произвести быстрый начальный осмотр продукта; - благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков уменьшаются затраты; - благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика; - модель обеспечивает эффективное использование имеющихся в наличии средств и структур; - привлечение заказчика на постоянной основе сводит до минимума риск того, что он не будет удовлетворен разработанным продуктом, кроме того, это гарантирует, что система будет соответствовать коммерческим потребностям, а сам программный продукт будет надежен в эксплуатации; - в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий); - интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем; - основное внимание переносится с документации на код, причем при этом справедлив принцип «получаете то, что видите» (WYSIWYG); - в модели используются следующие принципы и инструментальные средства моделирования: деловое моделирование (методы передачи информации, место генерирования информационных потоков, кем и куда направляется, каким образом обрабатывается); моделирование данных (происходит идентификация объектов данных и атрибутов, а также взаимосвязей); моделирование процесса (выполняется преобразование объектов данных); генерирование приложения (методы четвертого поколения); - в модели используются компоненты уже существующих программ.
Недостатки модели RAD.
Если эта модель применяется для проекта, для которого она не подходит в полной мере, могут сказываться недостатки, рассмотренные ниже. При этом оценка актуальности недостатков дается для ситуации, сложившейся в российском сегменте форт-программистов. Рассматривается порядок работы, когда Форт используется в качестве RAD tool, и разработчик программы использует модули на Форте (в их текущем состоянии комплектности) для быстрой разработки, аналогично Delphi/** Builder/ Visual Studio.
Если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте. Недостаток проявляется двумя способами, отличающимися целевым назначением разрабатываемой программы. Если с помощью модели RAD на Форте разрабатывается продукт для внутреннего применения (например, инструментальное ПО), то пользователем является разработчик или коллектив разработчиков. В этом случае участие в процессе разработки является очевидным, и недостаток не проявляется. В то же время, при использовании Форта для выпуска программ, предназначенных для продажи, пользователи в конечном итоге не вовлекаются в процесс планирования, а вместо обсуждения требований к программе и интерфейсу с пользователем обсуждается вопрос «можно ли использовать Форт».
При использовании этой модели необходимо достаточное количество высококвалифицированных и хорошо обученных разработчиков, умеющих воспользоваться выбранными инструментальными средствами разработки для ее ускорения. Сам факт использования форт-систем, существенно уступающих Delphi-подобным средам в функциональности визуальных конструкторов и генераторов кода, свидетельствует о недостаточной квалификации разработчиков, выбирающих некорректное инструментальное средство. Ускорение разработки путем ускорения конструирования интерфейсов не выделяется форт-программистами как ключевая особенность модели разработки.
Возникает потребность в системе, которая может быть смоделирована корректным образом.
При использовании в качестве RAD tool Форт, видимо, не используется в качестве средства моделирования/прототипирования, хотя сравнительный анализ Форта и Delphi-подобных средств позволяет предположить, что Форт мог бы выступать в качестве средства моделирования процессов и алгоритмов для их последующей реализации с помощью RAD tools.
Использование модели может оказаться неудачным в случае, если отсутствуют пригодные для повторного использования компоненты.
В настоящий момент наблюдается явный недостаток повторно используемых компонентов в Форте.
Могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами.
Фактор не представляется существенным ввиду простоты адаптации интерфейсов в Форте.
Для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений.
Требование потенциально несущественное, однако фокусировка на особенностях Форта переводит его в разряд критических. В действительности, в формулировке требования не упоминается, что разработчики обязаны использовать RAD tool. Четко указано, что и разработчики и заказчики должны быть готовы к быстрому выполнению действий, что вполне реализуемо и на Форте, причем возможность проблемного ориентирования языка является здесь существенным плюсом. При наличии жестких временных ограничений заказчик, как правило, не стремится наложить на разработчика дополнительные ограничения по выбираемым инструментам, стилю кодирования и т.п., поскольку одновременное выполнение нескольких условий существенно удорожает разработку. Поэтому настоятельное информирование заказчика о том, что разработка будет выполняться на Форте воспринимается им как попытка разработчика снять с себя ответственность за выбор инструмента разработки, зафиксировав в техническом задании язык программирования, нестандартный для большинства предметных областей. В конечном итоге прямые переговоры о выполнении проекта в сжатые сроки и на Форте вряд ли приведут к успешным результатам.
При использовании модели «вслепую» на затраты и дату завершения работы над проектом ограничения не накладываются.
Использование RAD tools «вслепую» и является основной организационной проблемой. Как правило, подавляющее большинство учебной и технической литературы ограничивается разъяснением особенностей программирования с помощью таких средств и описанием использования отдельных компонентов программ. При этом не разъясняется тот факт, что данные инструменты предназначены для ускорения разработки, а не для ее сквозного выполнения. Однако привлечение сторонних инструментов для моделирования, планирования и проектирования, как правило, не описывается.
Команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут «затянуть» разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом.
Существует риск, что работа над проектом никогда не будет завершена – в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла.
Существует проблема организации цикла взаимодействия как такового. Для применения модели RAD необходимо, чтобы менеджер проекта установил взаимодействие с заказчиком и определил его требования к разрабатываемой программе. После определения и согласования требований разработчик реализует их с использованием средств ускоренной разработки проекта. Однако установлению взаимодействия с заказчиком при разработке «вслепую» уделяется чрезмерно мало внимания.
Для обеспечения быстрой реакции на информацию, поступающую в результате налаженной обратной связи с пользователем, необходим эффективный ускоренный процесс разработки.
Процесс разработки на Форте может быть ускорен за счет реализации проблемно-ориентированного расширения. Однако для этого требуется налаженная обратная связь с пользователем, свободная от обсуждения вопроса «можно ли пользоваться Фортом».
Область применения модели RAD - в системах, которые поддаются моделированию (основанных на использовании компонентных объектов), а также в масштабируемых системах; - в системах, требования для которых в достаточной мере хорошо известны; - в случаях, когда конечный пользователь может принимать участие в процессе разработки на протяжении всего жизненного цикла; - когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств; - при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки, как правило, не более, чем за 60 дней; - в системах, которые можно поместить во временной блок с целью обеспечения функциональных возможностей на последовательной основе; - когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов; - в системах, которые предназначены для концептуальной проверки, являются некритическими, или имеют небольшой размер; - когда затраты и соблюдение графика не являются самым важным вопросом (например, при разработке внутренних инструментальных средств); - в системах, в которых не требуются достижение высокой производительности, особенно достигаемой посредством использования настройки интерфейсов; - при невысокой степени технических рисков; - в информационных системах; - когда команде, работающей над проектом, знакома предметная область, и она обладает достаточными навыками в использовании средств разработки и имеет высокую степень мотивации при выполнении данного проекта.
Рассмотрим теперь ситуацию, когда проект на Форте выполняется в соответствии с моделью RAD индивидуальным программистом или небольшим коллективом, но работа ведется в основном путем кодирования и тестирования. Весьма вероятно, при этом могут появиться следующие условия, препятствующие применению модели RAD: - не устанавливается взаимодействие с заказчиком; при этом либо организации или круга пользователей нет вообще, либо с ними обсуждаются не требования к программе, а возможность использования в этой программе Форта. В итоге не образуется списка требований, демонстрация выполнения которых могла бы обеспечить продвижение до очередной контрольной точки, и основы для применения RAD не возникает. - не присутствуют повторно используемые компоненты; существенным недостатком является ассоциирование повторно используемых компонентов с «повторно используемыми компонентами для организации графического интерфейса». - подразумевается, что разработчики хорошо освоили используемые инструменты и хорошо осведомлены в предметной области; независимо от используемого языка программирования, попытка использовать RAD для исследовательского проекта или освоения языка не соответствует рекомендациям для этой модели.
|