Недостатки
структурной эволюционной
модели быстрого прототипирования:
- модель
может быть отклонена
из-за создавшейся среди консерваторов
репутации о ней как о "разработанном
на скорую руку" методе;
- разработанные
"на скорую руку" прототипы, в отличие
от эволюционных ускоренных прототипов,
страдают от неадекватной или недостающей
документации;
- если цели
прототипирования не согласованы заранее,
процесс может превратиться в упражнение
по созданию хакерского кода;
- с учетом
создания рабочего прототипа, качеству
всего ПО или долгосрочной эксплуатационной
надежности может быть уделено недостаточно внимания.
- иногда в
результате использования модели получают
систему с низкой рабочей характеристикой,
особенно если в процессе ее выполнения
пропускается этап подгонки;
- при использовании
модели решение трудных проблем может
отодвигаться на будущее.
В результате это приводит к тому, что
последующие полученные продукты могут
не оправдать надежды, которые возлагались
на прототип;
- если пользователи
не могут участвовать в проекте на итерационной
фазе быстрого прототипирования жизненного
цикла, на конечном
продукте могут отразиться неблагоприятные
воздействия, включая проблемы, связанные
с его качественной характеристикой;
- на итерационном
этапе прототипирования быстрый прототип
представляет собой частичную систему.
Если выполнение проекта завершается досрочно, у конечного
пользователя останется только лишь частичная
система;
- несовпадение
представлений заказчика и разработчиков
об использовании прототипа может привести
к созданию другого пользовательского
интерфейса;
- заказчик
может предпочесть получить
прототип, вместо того, чтобы ждать появления
полной, хорошо продуманной версии;
- если язык
или среда прототипирования не сочетаются
с производственным языком или окружением,
всесторонняя реализация продукционной
системы может быть задержана;
- прототипирование вызывает зависимость
и может продолжаться слишком долго. Нетренированные
разработчики могут попасть в так называемый
цикл "кодирование — устранение ошибок"
(code-and-fix cycle), что приводит к дорогостоящим
незапланированным итерациям прототипирования;
- разработчики
и пользователи не всегда понимают, что
когда прототип превращается в конечный
продукт, все еще существует необходимость
в традиционной Документации. Если она
отсутствует, модифицировать модель на
более поздних этапах может оказаться
более дорогостоящим
занятием, чем просто не воспользоваться
созданным прототипом;
- когда заказчики,
удовлетворенные прототипом, требуют
его немедленной поставки, перед менеджером
программного проекта возникает соблазн
пойти им навстречу;
- на заказчиков
могут неблагоприятно
повлиять сведения об отличии между прототипом
и полностью разработанной системой, готовой
к реализации;
- на заказчиков
может оказать негативное влияние тот
факт, что они не располагают информацией
о точном количестве итераций, которые
будут необходимы;
- на разработку
системы может быть потрачено слишком
много времени, так как итерационный процесс
демонстрации прототипа и его пересмотр
могут продолжаться бесконечно без
надлежащего управления процессом. У пользователей
может возникнуть стремление пополнять
список элементов, предназначенных для
прототипирования, до тех пор, пока проект
ни достигнет масштаба, значительно превышающего
рамки, определенные анализом осуществимости
проектного решения;
- при выборе
инструментальных средств прототипирования
(операционные системы, языки и малопродуктивные
алгоритмы) разработчики могут остановить
свой выбор на менее подходящем решении,
только чтобы продемонстрировать свои
способности;
- структурные
методы не используются, чтобы не помешать
выполнению анализа. При прототипировании
необходимо провести "реальный" анализ
требований, осуществить проектирование
и обратить внимание на качество с целью
создания программы, допускающей сопровождение,
точно так же, как и в любой другой модели
жизненного цикла (хотя на эти действия
может понадобиться меньше времени и ресурсов).
Область
применения структурной
эволюционной модели
быстрого прототипирования
Менеджер
проекта может быть уверен в необходимости
применения структурной эволюционной
модели быстрого прототипирования, если:
- требования
не известны заранее;
- требования
не постоянны или могут быть неверно истолкованы
или неудачно сформулированы;
- следует уточнить
требования;
- существует
потребность в разработке пользовательских
интерфейсов;
- нужна проверка
концепции;
- осуществляются временные демонстрации;
- построенное
по принципу структурной модели, эволюционное
быстрое прототипирование можно успешно
использовать в больших системах, в которых
некоторые модели подвергаются прототипированию,
а некоторые— разрабатываются более традиционным образом;
- выполняется
новая, не имеющая аналогов разработка
(в отличие от эксплуатации продукта на
уже существующей системе);
- требуется
уменьшить неточности в определении требований;
т.е. уменьшается риск создания системы,
которая не имеет никакой
ценности для заказчика;
- требования
подвержены быстрым изменениям, когда
заказчик неохотно соглашается на фиксированный
набор требований или если о прикладной
программе отсутствует четкое представление;
- разработчики
не уверены в том, какую оптимальную архитектуру
или алгоритмы следует применять;
- алгоритмы
или системные интерфейсы усложнены;
- требуется
продемонстрировать техническую осуществимость,
когда технический риск высок;
- задействованы
высокотехнологические
системы с интенсивным применением ПО,
где можно лишь обобщенно, но не точно
сформулировать требования, лежащие за
пределами главной характеристики;
- разрабатывается
ПО, особенно в случае программ, когда
проявляется средняя и высокая степень
риска;
- осуществляется
применение в комбинации с каскадной моделью:
на начальном этапе проекта используется
прототипирование, а на последнем — фазы
каскадной модели с целью обеспечения
функциональной эффективности системы
и качества;
- прототипирование
всегда следует
использовать вместе с элементами анализа
и проектирования, применяемыми при объектно-ориентированной
разработке. Быстрое прототипирование
особенно хорошо подходит для разработки
интенсивно используемых систем пользовательского
интерфейса, таких как индикаторные панели
для контрольных приборов, интерактивные
системы, новые в своем роде продукты,
а также системы обеспечения принятия
решений, среди которых можно назвать
подачу команд, управление или медицинскую
диагностику.
Модель
быстрой разработки
приложений RAD (Rapid Application
Development)
Благодаря
методу RAD пользователь задействован на
всех фазах жизненного цикла разработки
проекта – не только при определении требований,
но и при проектировании, разработке, тестировании,
а также конечной поставке программного
продукта.
Это
обеспечивается наличием средств разработки
графического пользовательского интерфейса
и кодогенераторов. Такие инструментальные
средства, как Oracle Designer/2000, JavaJbuilder 3, Linux,
Visual C++, Visual Basic 6, SAS, и другие можно использовать
в качестве средств для быстрой разработки
приложений.
Характерной
чертой RAD является короткое время перехода
от определения требований до создания
полной системы. Метод основывается
на последовательности итераций эволюционной
системы или прототипов, критический анализ
которых обсуждается с заказчиком. В процессе
такого анализа формируются требования
к продукту.
Разработка
каждого интегрированного продукта
ограничивается четко определенным
периодом времени, который, как правило,
составляет 60 дней и называется временным
блоком.
Факторы,
позволяющие создать систему
за 60 дней, причем без ущерба качеству,
включают в себя использование мощных
инструментальных средств разработки,
высокий уровень фактора повторного
использования, а также осмысленные
и выделенные ресурсы.
Фазы
модели RAD
Модель
RAD проходит через следующие фазы:
- этап
планирования требований — сбор требований
выполняется при использовании рабочего
метода, называемого совместным планированием
требований (Joint requirements planning, JRP), который
представляет собой структурный анализ
и обсуждение имеющихся коммерческих
задач;
- пользовательское
описание — совместное проектирование
приложения (Joint application design, JAD) используется
с целью привлечения пользователей; на
этой фазе проектирования системы, не
являющейся промышленной, работающая
над проектом команда зачастую использует
автоматические инструментальные средства,
обеспечивающие сбор пользовательской
информации;
- фаза
конструирования ("до
полного завершения")
— эта фаза объединяет в себе детализированное
проектирование, построение (кодирование
и тестирование), а также поставку программного
продукта заказчику за определенное время.
Сроки выполнения этой фазы в значительной
мере зависит от использования генераторов
кода, экранных генераторов и других типов
производственных инструментальных средств;
- перевод
на новую систему эксплуатации — эта
фаза включает проведение пользователями
приемочных испытаний, установку системы
и обучение пользователей.
Преимущества
модели RAD
При
использовании модели RAD относительно
проекта, для которого она в достаточной
степени приемлема, проявляются следующие
преимущества:
- время цикла
разработки сокращается благодаря использованию
мощных инструментальных средств;
- требуется
меньшее количество специалистов (поскольку
разработка системы выполняется усилиями
команды, осведомленной в предметной области);
- существует
возможность произвести быстрый изначальный
просмотр продукта;
- уменьшаются
затраты (благодаря сокращенному времени
цикла и усовершенствованной технологии,
а также меньшему количеству задействованных
в процессе разработчиков);
- благодаря
принципу временного блока уменьшаются
затраты и риск, связанный с соблюдением
графика;
- обеспечивается
эффективное использование имеющихся
в наличии средств и структур;
- постоянное
присутствие заказчика сводит до минимума
риск неудовлетворения продуктом и гарантирует
соответствие системы коммерческим потребностям
и надёжность программного продукта в
эксплуатации;
- в состав
каждого временного блока входит анализ,
проектирование и внедрение (фазы отделены
от действий);
- интеграции
констант предотвращают возникновение
проблем и способствуют созданию обратной
связи с потребителем;
- основное
внимание переносится с документации
на код, причем при этом справедлив принцип
"получаете то, что видите" (What you see
is what you get, WYSIWYG);
- в модели
используются следующие принципы и инструментальные
средства моделирования: деловое моделирование
(методы передачи информации, место генерирования
информационных потоков, кем и куда направляется,
каким образом обрабатывается); моделирование
данных (происходит идентификация объектов
данных и атрибутов, а также взаимосвязей);
моделирование процесса (выполняется
преобразование объектов данных); генерирование
приложения (методы четвертого поколения);
- повторное
использование компонент уже существующих
программ.
Недостатки
модели RAD
Если
эта модель применяется для проекта,
для которого она не подходит в полной
мере, могут сказываться следующие недостатки:
- Непостоянное
участие пользователя может негативно
сказаться на конечном продукте (т.е. если
пользователи не могут постоянно принимать
участие в процессе разработки на протяжении
всего жизненного цикла, это может негативно
сказаться на конечном продукте);
- при использовании
этой модели необходимо достаточное количество
высококвалифицированных разработчиков,
(умеющих воспользоваться выбранными
инструментальными средствами разработки
для ускорения времени разработки);
- использование
модели может оказаться неудачным в случае
отсутствия пригодных для повторного
использования компонент;
- могут возникать
затруднения при использовании модели
совместно с наследственными системами
и несколькими интерфейсами;
- возникает
потребность в системе, которая может
быть смоделирована корректным образом;
- для реализации
модели требуются разработчики и заказчики,
которые готовы к быстрому выполнению
действий ввиду жестких временных ограничений;
- для обеспечения
быстрой реакции на информацию, поступающую
в результате налаженной обратной связи
с пользователем, необходим эффективный
ускоренный процесс разработки.
- при использовании
модели "вслепую" на затраты и дату
завершения работы над проектом ограничения
не накладываются;
- команды,
разрабатывающие коммерческие проекты
с помощью модели RAD, могут "затянуть"
разработку программного продукта до
такой степени, что его поставка конечному
пользователю будет под большим вопросом;
- существует
риск, что работа над проектом никогда
не будет завершена, – в связи с этим менеджер
проекта должен сотрудничать как с командой
разработчиков, так и с заказчиком, что
позволит избежать появления замкнутого
цикла;
Область
применения модели RAD
Менеджер
проекта может быть уверен в том,
что модель RAD подходит для применения
в конкретной ситуации в случае, если имеются
в наличии некоторые из приведенных ниже
условий-причин:
- в системах,
которые поддаются моделированию (тех
которые основаны на использовании компонентных
объектов), а также в масштабируемых системах;
- в системах,
требования для которых в достаточной
мере хорошо известны;
- в случаях,
когда конечный пользователь может принимать
участие в процессе разработки на протяжении
всего жизненного цикла;
- когда пользователи
хотят принимать активное участие в использовании
автоматических инструментальных средств;
- при невысокой
степени технических рисков;
- при выполнении
проектов, разработка которых должна быть
выполнена в сокращенные сроки (как правило,
не более, чем за 60 дней);
- в системах,
которые можно поместить во временной
блок с целью обеспечения функциональных
возможностей на последовательной основе;
- когда пригодные
к повторному использованию части можно
получить из автоматических хранилищ
программных продуктов;
- в системах,
которые предназначены для концептуальной
проверки, являются некритическими или
имеют небольшой размер;
- когда затраты
и соблюдение графика не являются самым
важным вопросом (например при разработке
внутренних инструментальных средств);
- в информационных
системах;