Модель эволюционно - ускоренного прототипирования (преимущества, недостатки, область применения)

МОДЕЛЬ ПРОТОТИПИРОВАНИЯ SLC

Fred Brook " The Mythical Man-Month " (1975г.)

«В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы… Следовательно, вопрос менеджмента заключается не в том, создавать или нет экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и сделаете. Единственный вопрос в том, нужно ли планировать создание продукта одноразового использования заранее или обещать поставить его заказчикам...»

"No Silver Bullet, the Essence and Accidents of Programming"

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

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

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

Эволюционным ускоренным прототипом является "легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного приложения получают физическое представление о ключевых частях системы до ее непосредственной реализации; это — легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы" Джон Коннэлл (Connell) и Линда Шафер (Shafer)

 

Этапы структурного эволюционного прототипирования

o Планирование проекта— результат: документ, описывающий в общих чертах примерные графики и результативные данные.

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

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

o Затем начинается итерационный цикл быстрого прототипирования.

· n Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование.

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

· nЭтот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования.

· nСоздание базы данных представляет собой первую из этих двух фаз.

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

o Затем модель демонстрируют пользователю с целью получения предложений по ее усовершенствованию, которые объединяются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной.

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

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

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

o При разработке производственной версии программы, может понадобиться:

· nболее высокий уровень функциональных возможностей,

· n различные системные ресурсы,

· nнеобходимых для обеспечения полной рабочей нагрузки,

· nограничения во времени.

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

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

Преимущество структурного эволюционного прототипирования

· взаимодействие заказчика с системой начинается на раннем этапе разработки;

· демонстрации разрабатываемого продукта сводит к минимуму количество неточностей в требованиях;

· в процесс разработки можно внести новые или неожиданные требования пользователя;

· модель представляет собой формальную спецификацию, воплощенную в рабочую модель.

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

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

· ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки;

· возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей;

· благодаря меньшему объему доработок уменьшаются затраты на разработку;

· обеспечивается управление рисками;

· документация сконцентрирована на конечном продукте, а не на его разработке;

Недостатки структурного эволюционного прототипирования

·  модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе;

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

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

·  при использовании модели решение трудных проблем может отодвигаться на будущее.

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

· несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса;

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

· если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;

· прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл "кодирование — устранение ошибок" (code-and-fix cycle)

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

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

·  на разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом;

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

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

· требования не известны заранее или требования подвержены быстрым изменениям, когда заказчик неохотно соглашается на фиксированный набор требований или если о прикладной программе отсутствует четкое представление;

· требования не постоянны или могут быть неверно истолкованы или неудачно сформулированы;

· существует потребность в разработке пользовательских интерфейсов;

· нужна проверка концепции;

· осуществляются временные демонстрации;

· выполняется новая, не имеющая аналогов разработка;

· требуется уменьшить неточности в определении требований;

· разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять;

· алгоритмы или системные интерфейсы усложнены;

· требуется продемонстрировать техническую осуществимость, когда технический риск высок;

·  задействованы высокотехнологические системы с интенсивным применением ПО, где можно лишь обобщенно, но не точно сформулировать требования, лежащие за пределами главной характеристики;

· осуществляется применение в комбинации с каскадной моделью: на начальном этапе - прототипирование, а на последнем - фазы каскадной модели;

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

 

Быстрая разработка приложений (RAD) (преимущества, недостатки, область применения)

Rapid Application Development, RAD

В1980г. компания IBM начала использовать метод быстрой разработки приложений (Джеймс Мартин).

Пользователь задействован на всех фазах жизненного цикла разработки проекта (при определении требований, при проектировании, разработке, тестировании, конечной поставке программного продукта).

Участие пользователя в процессе разработки становится столь активным благодаря использованию средства разработки или среды, которое позволяет дать оценку продукту на всех стадиях его разработки (средств разработки графического пользовательского интерфейса и кодогенераторов)

Характерной чертой RAD является: короткое время перехода от определения требований до создания полной системы.

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

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

Факторы:

· использование мощных инструментальных средств разработки,

· высокий уровень фактора повторного использования,

· осмысленные и выделенные ресурсы.

Этапы RAD

планирования требований — сбор требований (метод совместного планирования требований - Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

пользовательское описание — совместное проектирование приложения (Joint application design, JAD);

конструирования ("до полного завершения") — эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств;

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

Преимущества RAD

· благодаря использованию мощных инструментальных средств время цикла разработки для всего проекта можно сократить;

· требуется меньшее количество специалистов, т.к. специалисты хорошо владеют предметной областью;

· благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;

·  в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

· основное внимание переносится с документации на код, причем при этом справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);

·  в модели используются современные методы моделирования данных;

· + достоинства структурной эволюционной модели быстрого прототипирования.

Недостатки RAD

·  пользователь должен всегда принимать участие на всех этапах разработке;

· необходимо достаточное количество высококвалифицированных и хорошо обученных разработчиков;

· использование модели может оказаться неудачным в случае, если отсутствуют пригодные для повторного использования компоненты;

· жесткие временные ограничения;

· существует риск, что работа над проектом никогда не будет завершена;

Область применения RAD

· в системах, которые поддаются моделированию (основанных на использовании компонентных объектов), а также в масштабируемых системах;

· в системах, требования для которых в достаточной мере хорошо известны;

· в случаях, когда конечный пользователь может принимать участие в процессе разработки на протяжении всего жизненного цикла;

· при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки;

· когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;

· в системах, которые предназначены для концептуальной проверки, являются некритическими или имеют небольшой размер;

· когда затраты и соблюдение графика не являются самым важным вопросом;

· в системах, в которых не требуются достижение высокой производительности, особенно достигаемая посредством использования настройки интерфейсов;

· когда команде, работающей над проектом, знакома предметная область

Из ТИПСА:

Основные принципы методологии RAD

· Используется итерационная (спиральная) модель разработки.

· Полное завершение работ на каждом этапе ЖЦ не обязательно

· Обеспечивается тесное взаимодействие с заказчиками и будущими пользователями

· Применяются case средства и средства быстрой разработки

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

· Используются прототипы, позволяющие выяснить и реализовать потребности конечного пользователя

· Тестирование и разработка проекта осуществляется одновременно с разработкой

· Разработка ведется многочисленной командой

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

Ограничения методологии RAD

Методология Rad не подходит для создания нее только типовых ИС, но и сложных расчетных программ, ОС, и программ управления сложными инженерно-техническими объектами, т.е. программ, требующих написания большого объема универсального кода

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

Неприемлема для разработки систем, от которых зависит безопасность людей (система управления транспортом)