Модель прототипирования жизненного цикла разработки ПО

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

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

Рис. 1.5. Снижение неопределенности и инкрементное расширение функциональности при итеративной организации жизненного цикла.

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

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

Рис. 1.6. Структурная эволюционная модель быстрого прототипирования.

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

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

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

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

Модель быстрого прототипирования при правильном применении обладает следующими преимуществами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· при разработке ПО проявляется средняя и высокая степень риска.

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

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