Область применения V-образной модели

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

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

V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность.

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

Прототип — это эквивалент экспериментальной модели или «макета» в мире аппаратного обеспечения.

Начало жизненного цикла разработки помещено в центре эллипса.

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

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

Рис. 4. Модель эволюционного прототипирования

Действия:

Создается план проекта.

Это документ, содержащий в общих чертах примерные графики работ и промежуточные результаты.

Быстрый анализ.

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

Разработка пользовательского интерфейса (меню).

Разработка функций.

Т.о., создается рабочая модель.

Итерационный цикл быстрого прототипирования.

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

Утверждение пользователем.

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

Производная разработка.

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

Подгонка.

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

Эксплуатация и сопровождение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

прототипирование вызывает зависимость и может продолжаться слишком долго.

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

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

требования не известны заранее;

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

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

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

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

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

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

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